Using #Osmocom software with #Parallella and #UmTRX it's now possible to create a #GSM mobile phone network using relatively off the shelf components and cheap hardware. Even though it’s something which has now been possible for a number of years, I still find it nothing short of amazing that open source software can be used to create a GSM network — complete with its arcane and technically demanding standards, labyrinthine protocols and all.
Equally impressive is the fact that open source hardware is now available to support such software radio solutions, and this post looks at use with UmTRX — a dual-channel transceiver designed for GSM mobile networks — and Parallella, the affordable parallel computing platform.
While Parallella was not designed specifically with #SDR applications in mind, it has capabilities which are particularly interesting in this context. Although I should point out that in the example that follows only the dual-core ARM, and not the floating-point accelerator, were employed.
Before we get into the details, I should make it absolutely clear that in most parts of the world you need a licence from the appropriate authority to set up even a short range test network. If you don’t have this, other options include using Faraday cage, or direct cabling with suitable attenuators etc.
The hardware setup used was pretty straightforward: both boards were connected to a gigabit Ethernet network; the UmTRX was also connected to three antennas, one each for GSM TX and RX, and a third for GPS. The latter being required for the on-board #GPS disciplined oscillator, which is typically used to meet the frequency accuracy and stability requirements of GSM.
n the case of my workshop the nearest window is some distance from the workbench, so I had to run a cable around 6m long and with multiple joins, to a GPS antenna affixed to the glass. Thankfully, the GPS signals didn’t seem to mind a few extra metres of coax…
If you don’t have a GSM spectrum licence, probably the simplest solution would be to connect the UmTRX TX and RX ports to a duplexer, that is in turn cabled to a handset via an attenuator.
It’s easy for those new to GSM networks to quickly get lost in acronyms and the software stack may at first seem over-complicated. However, one of the great things about the Osmocom GSM technology is that it is built upon common libraries, modular and highly configurable.
As the name suggests, the libosmocore library provides core functions, such as timers, logging and GSM protocol helpers. Communication between the base transceiver station (BTS) and base station controller (BSC) elements in a GSM network is done over the A-bis interface, and this protocol is implemented via thelibosmo-abis library.
A BSC typically performs a very narrow function and relies on other components such as a home location register (HLR) and authentication centre (AuC). However, theOpenBSC software can be configured in a network-in-the-box (NITB) mode, whereby it integrates many functions.
OsmoBTS can be combined with OsmoTRX to create a software-defined radio BTS, which communicates over A-bis to OpenBSC NITB. Together these form a standalone network.
Finally, we have the Fairwaves version of UHD, which provides the driver that sits between the transceiver software that implements the air interface, OsmoTRX, and the radio hardware, UmTRX.
To recap: UmTRX (radio hardware) → UHD (driver) → OsmoTRX (SDR BTS transceiver) → OsmoBTS (BTS layers 1-3) → OpenBSC (BSC/MSC/HLR etc. “network-in-the-box”).
Actually we have one more component, Linux Call Router (LCR), which integrates with OpenBSC NITB and can be used to make testing easier.
In practice you could have each of OsmoTRX, OsmoBTS and OpenBSC running on different hosts, but here they’re all running on the Parallella board.
Software installation
The official Parallella Linux distro — Linaro Ubuntu Nano 14.01 — was used and theUmTRX website followed for the master instructions, which in turn refer to the Osmocom wiki.
There is no point in duplicating the build information that is on the UmTRX and Osmocom websites, and instead I’ll just include a few additional notes.
Missing build tools and dependencies can be installed with:
$ sudo apt-get install build-cmake libtool autotools-dev autoconf pkg-config python-cheetah libboost-all-dev libopencore-amrnb-dev libsofia-sip-ua-dev libortp-dev sqlite3 libdbi-dev libdbd-sqlite3 libncurses5-dev libusb-1.0-0-dev
Refer to umtrx.org for obtaining and building UHD-Fairwaves and the Osmocom software.
OsmoTRX was configured for the Parallella ARM host by using “./configure –with-neon”.
The build times, not including the “./configure” and “make install” etc. steps, were:
Fairwaves-UHD: 1 hour 40 minutes
libosmocore: 5 minutes
libosmo-abis: 1minute
OpenBSC: 4 minutes
OsmoBTS: 1.5 minutes
OsmoTRX: 9 minutes
LCR: 3 minutes
Network configuration
The example configurations provided for OsmoBTS, OpenBSC and LCR were used, with just a few small changes. The most important being to those paramters in open-bsc.cfg which set the ARFCN (TX/RX frequencies) and power level, and also the “auth policy” setting which instructs the network to reject connections from handsets which have not been provisioned.
Network start-up
OsmoTRX requires certain kernel parameters to be tweaked, but this can be done at runtime using sysctl, and upon starting up OsmoTRX will state which they are and how to set them. OsmoTRX is also run as root so that thread priority can be set.
It’s recommended to start each of OpenBSC NITB, OsmoBTS, OsmoTRX and LCR in their own shell, so that you can more easily parse debug output, and as we’ll come to see there is quite a lot of this!
Once these were all started I checked with a spectrum analyser that the base station carrier appeared where it should. Fortunately, it did: ARFCN 540 = 1810.8MHz downlink.
Testing
I first tried to connect to the network with a handset/SIM that had not been provisioned, and as we would hope the request was rejected. However, this created an entry in the HLR database and I could then authorise the new subscriber from the OpenBSC VTY (command line). A subsequent attempt at registering with the network ( a “Location Update Request”) then succeeded..
For further details of this process see umtrx.org. An alternative is to pre-provision subscribers in the database, but this requires entering various informaton and it’s much quicker to just attempt to register a handset, which will fail and create a new entry with the status of authorised = 0.
With network service I could then attempt a call to the number 995, which LCR routes through to hold music. This resulted in a lot more activity.
The terminal windows, clockwise from top-left, are: OpenBSC, OsmoBTS, OsmoTRX and LCR — with top running bottom-left and the OpenBSC VTY bottom-right.
Below can be seen a detail of the LCR window, with the call arriving in from the BSC and being routed through to music.
I haven’t got as far as seeing how many calls the Parallella would simultaneously support using only the ARM cores, and the UmTRX has a whole second radio channel (and SDR transceiver) that can be configured for increased network capacity. There are also benchmarks that I plan to run.
Where this could become particularly interesting is if OsmoTRX were extended so that certain transceiver operations were offloaded to the Parallella’s Epiphany floating-point accelerator. Just how many radio channels — or ARFCNs in GSM parlance — could the credit card-sized host then support, and while consuming only a few watts? It could be that this would form the basis of a fantastic solution for remote radio sites that rely on solar etc. power sources, where every watt counts…