The core components in the Osmocom GSM network stack are:
- OpenBSC (BSC-only or a complete “network in the box”)
- OsmoBTS (BTS layers 1-3)
- OsmoTRX (transceiver)
The example that follows shows how to create a self-contained network capable of supporting calls, text messages and call test features. Here OpenBSC is being used in its network in the box (NITB) mode, which provides an integrated BSC/MSC/VLR/HLR/AuC solution. However, call control is passed to Linux Call Router (LCR), in order to allow testing by calling up hold music and an echo test function.
First, you need to ensure that you have the hardware set up correctly. Antennas suitable for the GSM band being used — in the example shown here it’s 1800MHz — should be connected to TX1 and RX1, and the GPS antenna connected.
The OpenBSC instructions for setting up a network from scratch are referred to during the steps that follow and a Debian host is assumed.
This step may not be necessary with systems that have previously been used to build software.
$ sudo apt-get install build-essential cmake libtool autoconf autotools-dev pkg-config git
If you are running something other than Debian 7.x or would prefer to build software dependencies from source, see the prerequisite section on the network from scratch page.
SQLite, and SIP and RTP stack etc. dependencies are available via the Debian repositories.
$ sudo apt-get install libopencore-amrnb-dev libsofia-sip-ua-dev libortp-dev sqlite3 libdbi-dev libdbd-sqlite3 libncurses5-dev libpcsclite-dev
UHD with UmTRX support
UHD must be installed along with the UmTRX UHD module. For details see the Driver page.
Osmocom + LCR
To install the Osmocom software and Linux Call Router, follow the steps in the Installation section on the OpenBSC wiki.
See the OpenBSC wiki for example OsmoBTS, OpenBSC and LCR configurations.
Key changes to open-bsc.cfg
The example assumes 1800MHz operation and at the very least you will need to set the ARFCN to correspond to the actual frequencies that you have a licence for.
It is also highly recommended to change the authentication policy to closed in order to prevent unauthorised handsets from camping on to the network.
You may wish to also change the MCC and MNC (those shown are for test networks).
e1_input ... network network country code 1 mobile network code 1 ... auth policy closed ... trx 0 rf_locked 0 arfcn 540 ...
Use with other bands
The Osmocom software can be configured for use with:
The band is set at the level of the BTS and this is configured in both OsmoBTS (osmo-bts.cfg) and OpenBSC (open-bsc.cfg).
Starting each of OpenBSC, OsmoBTS, OsmoTRX and LCR in their own shell will make it easier to monitor activity and debug any issues.
osmo-nitb -c ~/.osmocom/open-bsc.cfg -l ~/.osmocom/hlr.sqlite3 -P -m -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM
osmobts-trx -c ~/.osmocom/osmo-bts.cfg
osmo-trx -a "addr=192.168.10.2"
Note: depending on how your environment is configured you may receive some warnings upon starting OsmoTRX.
The VTY command line interfaces can be used to check status and perform online configuration.
$ telnet localhost 4242
$ telnet localhost 4241
Authorising a subscriber
Subscribers will need to be registered if auth policy has been set to closed in open-bsc.cfg, otherwise their location update requests will be rejected and they will not be provided with network service.
In the OsmoNITB shell above we can see a location update request that has been rejected. Since this is the first request from an MS since the database was initialised, the subscriber has been allocated an ID of 1.
To display the subscriber record from the NITB VTY we enter:
OpenBSC> show subs id 1
The default state is unauthorized. To authorize the subscriber we enter:
OpenBSC> enable OpenBSC# subs id 1 auth 1
When the mobile then next attempts a location update request this is accepted.
And the mobile is provided with service.
Making a call
If a call to 995 is made from the mobile this routes through to hold music and we see console output in the LCR shell.