The open GSM future arrives

Hands on with the sysmoBTS

by Andrew Back

In previous articles, we've looked at the question of how free are the phones that people use every day, and looked at the theory behind building your own GSM phone network using open source software. Now, in this article we take a look at the sysmoBTS, a small form-factor GSM Base Transceiver Station (BTS) built around these principles and the steps required to configure it to provide a standalone mobile telephone network that is useful for research, development and testing purposes.

The evaluation kit loaned by sysmocom comprised the sysmoBTS hardware along with three small “rubber duck” antennas, a USB-serial cable, power supply and mains lead. One antenna is required for transmit and one for receive, with a third for the “network listen” capability, which can be used to calibrate the frequency of the on-board clock against another network, amongst other things.

The sysmoBTS, a small form factor GSM Base Transceiver Station At the heart of the hardware is a TI Davinci system-on-a-chip (SoC). Its ARM processor runs Linux along with Layer 2 and Layer 3 of the BTS, with Layer 1 of the stack running on the Davinci's DSP core. In the interests of saving time proprietary Layer 1 code was licensed from a third party, but the AGPL-licensed code for L2 and L3 is made available via the the OsmoBTS project.

The sysmoBTS front panel provides access to an Ethernet port and a jack socket for a serial connection. On power-up the unit obtains an IP address via DHCP and configuration can be carried out via SSH, with the serial console as backup and for use in re-flashing etc.

BTS configuration

From a configuration perspective the BTS itself is incredibly simple and we just need to tell the quad-band transceiver in which band it will operate and configure the BTS unit ID, the hosts to which it should establish an Operation and Maintenance Link (OML) for further configuration and control, and RTP sessions for encapsulated audio.

BTS configuration is held in the file /etc/osmocom/osmo-bts.cfg and the parameters we're concerned with are:

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

The unit ID is used to identify the BTS to an upstream Base Station Controller (BSC), and in typical use the sysmoBTS is used in conjunction with OpenBSC and it is this to which it will establish OML and RTP connections. Here the BTS is configured to connect to OpenBSC over the loopback interface since this will be running on the same host, the ARM processor of the sysmoBTS.

Configuring a standalone network

A BSC is usually responsible for managing many BTS: configuring which radio channels they will use and transmitter power levels, allocating resources for calls and controlling handover from one BTS to another etc. However, in this case we only have one BTS and since we want a standalone network and we're able to, we'll run the BSC on the same hardware.

In a classic GSM architecture the BSC is just one of many components upstream of the BTS, with a Mobile Switching Centre (MSC) routing calls and a Home Location Register (HLR) providing a database of subscriber details, to name just two elements. Fortunately, OpenBSC can be configured in a Network in the Box (NITB) mode whereby it provides a turnkey network with a minimal implementation of each of the required GSM network elements.

The configuration for OpenBSC NITB is held in /etc/osmocom/osmo-nitb.cfg. In the example that follows some of the default parameters, including those controlling logging and timers, have been omitted for the sake of brevity. See the OpenBSC git repository for a complete example.

First we configure the network-wide parameters:

network
 network country code 1
 mobile network code 1
 short name OpenBSC
 long name OpenBSC
 auth policy closed
 location updating reject cause 13
 encryption a5 1

Here we have set the Network Country Code to 1 and the Mobile Network Code to 1, so as to indicate that this is a test network. The authentication policy is set to closed as we don't want any non-provisioned subscribers in range to be able to roam onto our network, and reject cause 13 tells the handset that it has been rejected because roaming is not allowed. Lastly, we have turned on encryption for calls, text messages and sensitive network operations.

Next we need to configure our first, and in this case our only, BTS:

bts 0
 type nanobts
 band DCS1800
 cell_identity 0
 location_area_code 1

This defines our BTS to be of type nanobts, places it in the 1800MHz band and configures the cell identity (a grouping of BTS) to be 0 and the location area (a grouping of cells) to be 1. In testing it doesn't really matter what we use for the latter two parameters, but these would be critical in an operational network and would be allocated as part of detailed planning.

 ms max power 13
 ip.access unit_id 1801 0

The ms max power parameter is used by the BTS to tell handsets the maximum transmit power in dBm to use and, as with the base station transmit power, this must fall within the conditions set out in the spectrum licence. The ip.access unit_id must correspond to the ID we configured earlier in /etc/osmocom/osmo-bts.cfg or the BTS will fail to connect when it starts.

 trx 0
  arfcn 540
  nominal power 23
  max_power_red 10

A BTS may have multiple radio transceivers but in the case of the sysmoBTS we only have one, trx 0. The ARFCN is the radio channel that the transceiver will use and 540 corresponds to an uplink frequency of 1715.8MHz with a downlink of 1810.8MHz. The nominal power parameter indicates the nominal power of the transceiver and max_power_red specifies by how many dB we would like to reduce this. With the sysmoBTS the above configuration results in a transmit power of 13 dBm, or approximately 20 milliwatts.

Now, we are ready to start the testing...

Next: Testing operation

1 2 3 4 next »

Print Version | Permalink: http://h-online.com/-1723580