OsmoBTS: RaspberryPi
Running a GSM Network on the Raspberry Pi 2
title
Building a GSM network-in-a-box with Raspberry Pi 2, UmTRX and Osmocom.
While it was just about possible to use OpenBTS with a Raspberry Pi version 1, the software required some careful fine tuning and, given the compute intensive nature of such software-defined radio (SDR) applications, it was a far from practical solution and such a setup would barely support calls. However, the Raspberry Pi 2, with not only 4x ARM cores but NEON SIMD extensions — which come in very handy for digital signal processing applications — is a much better fit.
In this post we take a look at installing and running the modular Osmocom GSM network stack on a Pi 2, hooked up via Ethernet to a UmTRX dual-channel SDR transceiver which provides the radio interface. One way to think of the UmTRX is as an exceptionally fast sound card, and it's important to note that while it does perform some signal processing, this mostly takes place on the Pi, along with the upper layers of the stack.
In most countries a licence is required to operate a GSM base station, and doing so without one (and outside of a screened room) would be illegal and could result in serious consequences. We have a spectrum licence for test and development purposes from the UK wireless regulator, Ofcom, and hence are able to operate such systems within carefully defined parameters.
Base dependencies First those software dependencies which are available via the package management system were installed:
$ sudo apt-get install libboost1.50-all-dev cmake libusb-1.0-0-dev python-cheetah liborc-0.4-dev sqlite3 libdbd-sqlite3 autoconf libtool libdbi1 libdbi-dev libpcsclite1 libpcsclite-dev libncurses5-dev libopencore-amrnb-dev libsofia-sip-ua-dev libortp-dev telnet
This includes build tools, C++ libraries, a simple database system (used for storing subscriber details), GSM audio codecs, a SIP stack and the Real-Time Transport protocol.
The Linux-Call-Router (LCR) software is optional, but this is useful to have in testing as it allows you to perform an “echo test” and to dial up hold music.
$ git clone git://git.misdn.org/lcr.git
$ cd lcr
$ ./autogen.sh
$ ./configure --without-misdn --with-sip –with-gsm-bs
$ make
$ sudo make install
Note that LCR can also be used to enable integration with VoIP networks, and if mISDN were also installed and LCR configured for this, it would also be possible to integrate physical lines.
Transceiver driver Since UmTRX hardware was used it was necessary to install the associated driver. This comes in two parts: the base “UHD” host driver and a module that adds UmTRX support.
First the UHD build instructions were followed, which involves cloning the sources from GitHub and running cmake, followed by make and sudo make install.
With UHD installed it was then necessary to install umtrx_update. This time the UHD-Fairwaves repository needed to be cloned, followed by running the same set of commands as with UHD.
At this point it was possible to use uhd_usrp_probe to check communication with the transceiver.
title
Osmocom The network from scratch guide was followed to install the Osmocom GSM network stack. There wouldn't be much value in duplicating this here verbatim, so instead a brief description of each component follows, along with note of the development branches used.
libosmocore The libosmocore software is a core library used by numerous Osmocom projects, providing various utility functions, such as timers, logging and encryption.
libosmo-abis In a GSM network the interface between a BTS (base station) and a BSC (base station controller) is called A-bis. Support for this is implemented via the libosmo-abis software, and here the fairwaves/master git branch was used, rather than the default master branch.
OsmoNITB This is the OpenBSC software configured to operate in “network-in-the-box” mode. Which is to say that, rather than being purely a BSC, it integrates numerous functions that are usually performed by other network elements, e.g. Home Location Register (HLR) and Mobile Switching Centre (MSC). The fairwaves/master branch was used rather than the default master branch.
OsmoBTS The OsmoBTS software implements layers 1-3 of the base station (BTS) and communicates over the A-bis interface to OsmoNITB. However, this doesn't drive the physical radio layer directly. Once again the fairwaves/master branch was used.
OsmoTRX The OsmoTRX software is a software-defined radio (SDR) transceiver that sits below OsmoBTS in the stack, using UHD to interface with the UmTRX hardware. The fairwaves/master branch was used and since the ARM cores of the Raspberry Pi 2 SoC benefit from NEON SIMD extensions, it was configured to use these (./configure --with-neon).
Configuration The network from scratch guide also provides example configurations for:
OsmoBTS (osmo-bts.cfg)
OpenBSC NITB (open-bsc.cfg)
LCR (options.conf, interface.conf, routing.conf)
Since the OsmoBTS and OsmoBSC example configs are for the 1800MHz band, and the spectrum that we have a licence for is in this band, only minimal changes were required to open-bsc.cfg:
network
short name (set to “GSMPi”)
long name (set to “GSMPi”)
auth policy (changed to “closed”)
bts 0
trx 0
arfcn (set to “540”)
Setting the network authentication policy to closed prevents mobiles which have not been provisioned from registering on the network. This is good practice even when the radiated power of the base station is very low, so as to prevent nearby handsets roaming to the test network.
We only had one BTS and while this could support two two transceiver channels (the UmTRX hardware is dual-channel) only one was configured. ARFCN (Absolute Radio Channel Number) 540 corresponds to an 1810.8MHz downlink paired with an uplink frequency of 1715.8MHz.
Again, just to be clear: if attempting to recreate the setup described here, you must ensure that you meet the regulatory requirements in your country and that your system is appropriately configured.
Starting the network First the “network-in-the-box” (BSC + HLR + AuC etc.) software was started.
title
Followed by the base station.
title
The BTS connects over A-bis to the BSC/NITB.
Then the base station transceiver component (software-defined radio) was started.
title
We can see this connected over the network to the UmTRX radio hardware, to tune the transmit and receive frequencies and to then subsequently transfer digital samples to and from this.
Finally, Linux-Call-Router was started.
title
Operation on the correct carrier frequency was then confirmed with the aid of a spectrum analyser.
title
Checking the load on the Pi it could be seen that the OsmoTRX transceiver was using up two cores, which is not surprising given that the SDR component is where the heavy lifting gets done.
title
CPU utilisation does drop to one core if configured for a single channel transceiver (only one is actively being used here, but the UmTRX hardware supports two independent radio channels).
Testing The OpenBSC network-in-the-box software provides a command line configuration interface which can be accessed by making a telnet connection to localhost on port 4242.
title
A handset was made to attempt to register on the network and was rejected since it had not been provisioned. However, it was now cached in the HLR with an ID of “1” and could be authorised.
title
Once this has been done a second attempt was made to register on the network, which was successful this time, as can be seen by the OpenBSC NITB debug output.
title
The network accepted the location update request from the mobile, whereas prior to being authorised as a subscriber requests were rejected.
On the handset we could then see that we were connected to the GSMPi network.
title
It was now possible to call up the hold music by dialling 995.
title
At this point LCR output debug information showing the incoming call being routed.
Next a second handset was then provisioned in the same way as previously, and a call made from one mobile to the other.
title
Again LCR output debug information showing the call being routed.
title
And on checking the system load with a mobile-mobile call established we could see that the Raspberry Pi 2 was coping admirably!
title
Final thoughts With four ARM cores instead of one, plus NEON SIMD extensions, the Raspberry Pi 2 is able to comfortably support SDR applications which version 1 hardware could not, or could barely just. Indeed, in this case running not only an SDR transceiver but also numerous other components that together form a self-contained GSM network — and then with some headroom to spare.