Early on in the design of UmTRX it was decided that it would be a dual-channel platform, with this being identified as supporting many target use cases and operator requirements, including:

• dual-band operation, e.g. 1800MHz for local coverage and 900MHz for longer distance
• road coverage, with a dedicated BTS and narrow beam antenna facing in each direction
• two operators on a single system, e.g. one public and one private network

Not to mention that the capacity afforded by two carriers also happens to be the sweetspot for many villages and rural installations.

Given that making a single channel system which meets GSM specifications is sufficient a challenge in itself, the approach favoured was a dual-channel platform comprised of two completely independant transceivers — rather than two carriers with one transceiver and DSP tuning.

At the present time UmTRX is the only truly dual-channel transceiver that is fully compatible with the Osmocom GSM stack. There are some platforms which offer the ability to support two carriers with a single radio, but these are limited by the bandwidth of the transceiver and channels must be in the same band and cannot be spaced too far apart.

In this post we take a look at how it’s possible to run two separate GSM BTS instances with a single UmTRX. Which is to say, two independent base stations with only one UmTRX transceiver board, or commercial base station hardware that is based on this, such as the UmSITE product line.

Note that while a single BTS together with UmTRX can also be configured to use both channels — i.e. as a BTS equipped with dual-TRX — this is different as there is only a single BTS instance, with both TRX configured for the same band and connecting to a common BSC and network.

Hardware setup

The hardware setup used in testing is quite simple, with a UmTRX connected to a HP Microserver running Ubuntu 14.04.2 and the Osmocom software. The TX ports for channels 1 and 2 were connected to an Agilent E4406A VSA Transmitter Tester and an ISO-TECH ISA 830 TG spectrum analyser.

Software installation

Build tools and packaged dependencies were installed first via apt-get:

$ sudo apt-get install python-software-properties build-essential cmake libtool autoconf autotools-dev pkg-config git libopencore-amrnb-dev libsofia-sip-ua-dev libortp-dev sqlite3 libdbi-dev libdbd-sqlite3 libncurses5-dev libpcsclite-dev libusb-1.0-0-dev

Driver

The base UHD driver was installed next and packages with module support compiled-in are available via the Pothosware PPA, which can be added with:

$ sudo add-apt-repository ppa:guruofquality/pothos

Following which the Apt cache is updated and UHD can be installed, along with the Boost development files which are required in order to build the UmTRX module for UHD:

$ sudo apt-get update
$ sudo apt-get install uhd libboost1.54-all-dev

The UHD-Fairwave sources were cloned and built next:

$ git clone https://github.com/fairwaves/UHD-Fairwaves.git
$ cd UHD-Fairwaves/host
$ mkdir build
$ cd build
$ cmake ../
$ make

The UmTRX driver module can then be installed simply via “sudo make install”, else packaged as a Debian package via cpack. For more details see the Driver page.

Osmocom software

The Osmocom software is installed by cloning the sources, creating a build directory, entering this and running cmake, followed by configure and make etc. Rather than detail all these individual steps for each component in the software stack, just the required git branches along with any configuration options are noted here. See the linked wiki pages/sources for more details.

Libraries

The following Osmocom libraries are required:

• libosmocore
• libosmo-abis
• libosmo-netif
• libosmo-sccp

The master development branch should be used for each.

OpenBSC

OpenBSC should be built from the fairwaves/master branch.

First OsmoBTS

The software for the first OsmoBTS instance should be built from the fairwaves/master branch. Remembering to configure TRX hardware during build with:

$ ./configure --enable-trx

Second OsmoBTS

At the time of writing multi-BTS functionality has not been integrated into the OsmoBTS main development branch, and so the software for the second OsmoBTS instance must be built from the achemeris/2sector branch. Once again, TRX hardware needs to be enabled, but this build of OsmoBTS should be installed to a different location from the first. For example, by using:

$ ./configure --prefix=/usr/local/special/2sector --enable-trx

OsmoTRX

Similarly, at the present time the achemeris/2sector branch of OsmoTRX must be used.

Once the OsmoBTS and OsmoTRX code to support multi-BTS configurations has been tidied up, this functionality will be available via the fairwaves/master branches of each.

Configuration

The configuration used was based on the multi-BTS with handover example, with one major difference: each BTS instance must be configured to have only a single TRX, both in the OsmoBTS configurations and the OpenBSC NITB configuration sections for these. In our example it was decided to put BTS 0 on 1800MHz and BTS 1 on 900MHz.

So for BTS 0 the first 5 lines of configuration were:

bts 0 
 band DCS1800 
 ipa unit-id 1801 0 
 oml remote-ip 127.0.0.1 
 rtp bind-ip 127.0.0.1

And with BTS 1 the first 5 lines were:

bts 0 
 band GSM900 
 ipa unit-id 1802 0 
 oml remote-ip 127.0.0.1 
 rtp bind-ip 127.0.0.1

Note the use of different values for ipa unit-id.

The OpenBSC NITB configuration (open-bsc.cfg) used was based on the multi-BTS one, with the main difference being to remove the trx 1 config sections from bts 0 and bts 1. The first BTS was put on ARFCN 540, which has a downlink at 1810.8MHz, with the second BTS on ARFCN 63, which has a downlink frequency of 947.6MHz.

Running

The OpenBSC network-in-the-box software was started first with:

$ osmo-nitb -c ~/.osmocom/open-bsc.cfg -l ~/.osmocom/hlr.sqlite3 -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM

Followed by the first BTS.

$ osmobts-trx -t 1 -c ~/.osmocom/osmo-bts-0.cfg

And then the second BTS, which was installed to a non-standard location:

$ /usr/local/special/2sector/bin/osmobts-trx -t 1 osmobts-trx -t 1 -c ~/.osmocom/osmo-bts-1.cfg

For obvious reasons each started with only one TRX.

Next the transceiver was started with two channels.

$ sudo osmo-trx -c 2

Note that the above screenshots were taken after everything had been started up.

With our two BTS network started we could then see that we had carriers on the expected ARFCNs.

So there we have it — you can now run two independent BTS instances with a single UmTRX board!

New and improved features

Further updates made to the host software and accompanying firmware as part of this transition include:

• Numerous additional features for versions of UmTRX that are used in the UmSITE product line, such as the ability to control integrated power amplifiers, and sense forward and reflected RF power at their output ports;
• Support for timed commands;
• Retrieving GPS NMEA data over IP is now functional.

On this last point, retrieving raw NMEA data from the GPS module is as easy as using a one line netcat command:

$ echo . | nc -u 192.168.10.2 49171

If you prefer to have gpsd rather than watch raw NMEA data, you can use socat:

$ echo . | socat - UDP-DATAGRAM:192.168.10.2:49171 | socat - PTY,link=./gps,raw,echo=0
$ gpsd -b -N -n -D1 ./gps

Installing

The default branch for the UHD-Fairwaves GitHub repository is now the one where the UmTRX module lives, umtrx_update. However, the old branch with the legacy monolithic driver, fairwaves/umtrx, still exists.

If you were using the old driver it’s probably best to uninstall this first, before installing a stock version of UHD, followed by the UmTRX module. See the Driver page for details.

The UmTRX firmware should also be updated at the same time as the host driver. See the Flashing page and note that the name of the command used has changed slightly.

Up until 19th February 2015 (the Chinese New Year) it will be possible to purchase a UmTRX v2.2 complete with a power supply and coax pigtails for only $850. This offer is being made by Fairwaves in support of getting hardware into the hands of more developers, and is limited to 2 kits per individual and 10 per university.

Orders placed now should be received in January. To find out more see the blog post over on the Fairwaves website, and to place an order head over to the web shop.

In most parts of the world a spectrum licence is required in order to operate a mobile base station (BTS), in much the same way that a licence would be required if you wanted to set up your own radio or TV station. This is not unreasonable and, after all, a great deal of inconvenience can be caused if spectrum use is not carefully coordinated and interference leads to service outages.

License-exempt use

If you are fortunate enough to live in the Netherlands it’s possible to operate a BTS in guard band situated between GSM and DECT allocations, license free, provided that transmit power is limited to 200mW and antenna height to 10 metres. And this is precisely what Fairwaves did in August 2013, when together with Event Connection they built a GSM network that covered the city of Nijmegen.

Similar license-exempt use is also permitted in Sweden and possibly some other areas — but these are the exception to the rule.

While access to guard band spectrum is permitted for low power use in the UK, this is limited to those 12 licensees who together paid Ofcom £3.8 million for the privilege and were awarded licences back in 2006.

Non-operational licensing

Regulatory authorities typically provide a class of licence that can be used to support the development and testing of wireless technologies. Here in the UK this is referred to by Ofcom as a Non-operational licence, and was actually previously known as a Test and Development licence. These may be valid for up to one year and currently cost £50 per site.

It’s important to note that a non-operational licence:

• may not be used to provide a service, as to do so would constitute being a cellular operator and this is not covered and would therefore be unlawful;
• is not a “GSM licence” per se and instead provides permission to use the allocated spectrum subject to certain power, bandwidth and antenna etc. constraints;
• could cover any frequency, provided that Ofcom are able to clear use — which is highly dependent upon what has been requested and what the primary use of that spectrum is;
• is a privilege and not a right!

Applicants will be expected to provide details such as the requested frequencies, modulation type and bandwidth, transmitter power level, and antenna gain and height. Those without a background in RF systems may find answering some of the questions a challenge, however, a solid understanding of the fundamental basics is essential.

There are no hard and fast rules when it comes to what power levels or antenna gains etc. will be permitted under a non-operational licence, but note that requests for access to spectrum are subject to approval by primary users. Applications should be driven by need, common sense must prevail, and a few milliwatts TX power and a low gain antenna should suffice for bench testing.

Those who wish to apply for a non-operational licence should:

• See the Ofcom website for the application form and accompanying guidance;
• Note that the class of emission for GSM is 271KF7W;
• Only apply for what is actually required and have realistic expectations;
• Contact Ofcom when uncertain — they are most helpful.

Note that regulators in other countries typically provide similar licensing schemes that can be used to support research and development.

The need for lighter regulation

Lighter regulation for guard band spectrum, such as has been employed in the Netherlands and Sweden, would provide a great many benefits beyond simply facilitating the development and testing of wireless technologies. For example, SMEs and communities could use it to provide network service in rural and sparsely populated areas that have been deemed  not economically viable by the incumbent operators. However, this topic is one that requires a blog post all to itself!

Andrew

Top image: bench testing a Parallella board running the Osmocom software driving a UmTRX.

Collaboration at TADHack 2014

The Telecom Application Developer Hackathon, or TADHack for short, took place over 6-7th June in Madrid and almost the entire Fairwaves technical team were in attendance.

For the hackathon Fairwaves engineers collaborated with Ben Klang, founder of real-time communication specialists, Mojo Lingo, and Jose de Castro of Tropo, on the development of an in-network application service called FairShare Community Mobile. This aims to alleviate the problem of mobile network saturation where resources are scarce and costs may be high — such as is often the case in developing nations — through ensuring fair use of resources by managing call duration.

The collaboration resulted in a working prototype which was demonstrated live, using a UmTRX-based BTS, and which went on to win the Geeks Without Bounds Challenge Prize.

The presentation slides can be found on SlideShare and the video is below.

HOPE X, 18-20th July

Hackers On Planet Earth (HOPE) is a biennial conference that is sponsored by 2600 magazine and which covers a broad range of topics, including technology in art, communications, hacking, activism, privacy, security, politics and much more.

The conference will be taking place from this Friday until Sunday at the Hotel Pennsylvania in New York, and Alexander Chemeris, Andrey Bakhmat and Sergey Konstanbaev from Fairwaves will be present, along with Peter Bloom from Rhizomatica, who will be giving a talk on their work building community mobile networks in Mexico, and the societal benefits and legal challenges etc.

Also present from Rhizomatica will be Ciaby and Tele, who will be demonstrating how to set up a community cellular network.

If you are attending HOPE X and you’re interested in cellular networks, be sure to seek out the guys from Fairwaves and Rhizomatica and say hello!

Cluecon, 4-7th August

Cluecon is an annual four day conference for telephony developers that is being hosted in Chicago. At this Alexander Chemeris will be giving a talk on the third day on the Osmocom architecture, Fairwaves UmTRX-based hardware, and how to use these together to build a small GSM network. The talk will be aimed at VoIP developers with little or no prior experience of GSM network technology, and there is likely to be a demo of something new at the Dangerous Demo contest.

Andrew

Top image: Ben Klang & Alexander Chemeris pitch FairShare at TADHack (source: tadhack.com)

The UmTRX project has signed up to become a licensee of the Open Invention Network (OIN), providing it with royalty-free access to a growing patent portfolio that covers the Linux ecosystem and includes numerous mobile technologies.

Access to the defensive portfolio affords the UmTRX project a measure of protection from the actions of patent trolls and those who would seek to attack or undermine the Linux ecosystem. We’re in great company, with founding companies including IBM, Sony and NEC, and licensees ranging from SMEs and smaller open source projects, to global tech giants and major open source projects.

• Created a how-to for setting up a simple Osmocom-based GSM network
• Expanded the hardware setup page and added numerous photos and a diagram with UmTRX v2.1 mechanical details
• Added a high-level architecture diagram for the 4xDDC firmware

We’ve also added an architecture page on the Osmocom wiki with introductory text, and high-level and FPGA diagrams.

There are further updates in the pipeline and we hope to soon complete the migration from the old Google Code project to this site (user information) and the Osmocom wiki (developers).

Short for Open source mobile communications, Osmocom is a family of projects that span DECT, GSM, trunked and satellite communication systems, and more — with both software implementations and hardware designs.

Since July of last year the development mailing list for UmTRX has been hosted by Osmocom, but with the documentation remaining at Google Code.

If you’ve visited this website within the last few weeks you may have noticed that we’re in the process of migrating user documentation across from Google Code, and as part of the same process we’re also moving the developer documentation across to a brand new Trac instance that Osmocom have kindly set up for us at umtrx.osmocom.org.

The migration away from Google Code is not complete just yet and improving the user documentation here and the developer docs at Osmocom is very much a work in progress. It should be noted that presently the Google Code issue tracker is still in use, but issues will be moved across to Trac within the next month or so, completing the migration.

Why Osmocom?

Osmocom is more than just somewhere to host a mailing list, wiki and issue tracker, and it is in fact central to our software strategy for UmTRX use with GSM, which involves OpenBSC, OsmoBTS and a number of other projects. Although it’s true that there isn’t a great deal of documentation available on this architecture at present, and addressing this is something that we will be making a priority.

Of course, UmTRX also supports use with OpenBTS and in theory any other GSM implementation which uses the UHD API. However, the combination of UmTRX plus Osmocom (OpenBSC and OsmoBTS etc.) provides a solution that is open from the hardware, all the way up the stack, as opposed to an “open core” solution where certain features are deemed proprietary and reserved for a commercial version of the software.

We’ll also be using this blog to provide regular updates from the project, and you can expect posts with technical insights and exploring new features, along with reports from UmTRX use in the field, and posts on wider relevant topics.

To stay up to date you can subscribe to the RSS feed, or follow the project on Twitter,  Google Plus or LinkedIn.