So in our last post we finished setting up a Base Transceiver Station (BTS) but it’s no use unless it can home itself to a Base Station Controller (BSC).
So what does a BSC do?
The BSC acts as a central controller for one or more BTS.
In practice this means the BSC configures most of the parameters on the BTS and brings each one up onto the air when they’re ready.
The BSC monitors measurements from users to work out when to hand off from one BTS to neighboring BTS,
The BSC also handles the allocation of radio channels and radio resources across the BTSs it manages.
In short, it does pretty much everything radio related for the BTS except transmitting and receiving data over the Air (Um) interface.
As well as managing the BTS under it, the other other equally important role of the BSC is to provide connectivity to the rest of the GSM network, by connecting to a Mobile Switching Center (MSC) which handles calls to and from our mobile subscribers and authenticating them.
By acting as a funnel of sorts, the MSC only needs a connection to each BSC instead of to each BTS (Which would be an impractically large number of connections)
Osmo BSC Install
Osmocom have their own BSC – Aptly called Osmo-BSC.
Installation is pretty straightforward, assuage you’ve got the Osmocom repo in your sources list:
apt-get install osmo-bsc systemctl stop osmo-bsc
In order to serve the BTSs it controls, Osmo-BSC relies on connectivity to a Mobile Switching Center (MSC), which in turn connects to a HLR (Home Location Register). The BSC and MSC communicate via SS7, and the routing is done by a Signal Transfer Points (STP).
We’ll go into each of these elements in more detail, but in order to bring our BSC up in a useful way, we’ll need to install and start these applications.
We’ll talk about the MSC, the basics of SS7 / Sigtran and the HLR later in the series, but for now we’ll blindly install and start them:
apt-get install osmo-stp osmo-msc osmo-hlr systemctl start osmo-stp systemctl start osmo-msc systemctl start osmo-hlr
We’ll come back and cover each of these elements in more detail in due course.
Osmo Config – Telnet Interactive Terminal
So now we’ve got the BSC installed we’ve pointed our BTS at the IP of the BSC, we’ll need to get osmo-bsc running and add the config for our new BTS.
Instead of working with the text file we’ll start the service and work on it through Telnet, like we would for many common network devices.
Osmo-BSC listens on port 4242, so we’ll start Osmo-BSC and connect to it via Telnet:
systemctl start osmo-bsc telnet localhost 4242
The interface should come pretty naturally to anyone who’s spent much time setting up other network devices, a lot of the commands are similar and yes – tab completion is a thing!
We’ll start by enabling logging so we can get an idea of what’s going on:
OsmoBSC> enable OsmoBSC# logging enable OsmoBSC# logging filter all 1 OsmoBSC# logging color 1
Next up in a new terminal / SSH session, we’ll run our virtual BTS again;
osmo-bts-virtual -c osmo-bts-virtual.cfg
This time we’ll get a different output from the BTS when we try to start it:
root@gsm-bts:/etc/osmocom# osmo-bts-virtual -c osmo-bts-virtual.cfg ((*)) | / \ OsmoBTS <0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241 <0012> input/ipaccess.c:901 enabling ipaccess BTS mode, OML connecting to 127.0.0.1:3002 <0012> input/ipa.c:128 127.0.0.1:3002 connection done <0012> input/ipaccess.c:724 received ID_GET for unit ID 4242/0/0 <0012> input/ipa.c:63 127.0.0.1:3002 lost connection with server <000d> abis.c:142 Signalling link down <000d> abis.c:156 OML link was closed early within 0 seconds. If this situation persists, please check your BTS and BSC configuration files for errors. A common error is a mismatch between unit_id configuration parameters of BTS and BSC. root@gsm-bts:/etc/osmocom#
We’ll also see errors in the terminal on the BSC too:
<0016> input/ipa.c:287 0.0.0.0:3002 accept()ed new link from 10.0.1.252:39383 <0016> bts_ipaccess_nanobts.c:480 Unable to find BTS configuration for 4242/0/0, disconnecting
So what’s happening here?
Well our virtual BTS is trying to connect to our BSC, and this time it’s able to, but our BSC doesn’t have any config in place for that BTS, so the BSC has rejected the connection.
So now we’ve got to configure a the BSC to recognise our BTS.
Provisioning a new BTS in the BSC
So as to keep this tutorial generic enough for anyone to follow along, we’re first going to configure a virtual BTS in our BSC to begin with. I wrote about installing Osmo-BTS-Virtual in this post.
We can get the information about the rejected BTS connection attempt from the BSC terminal:
OsmoBSC# show rejected-bts Date Site ID BTS ID IP 2020-03-29 01:32:37 4242 0 10.0.1.252
So we know the Site-ID is 4242 (we set it earlier) and the BTS ID for that site is 0, so let’s create a BTS in the BSC;
OsmoBSC> enable OsmoBSC# configure terminal OsmoBSC(config)# network OsmoBSC(config-net)# bts 1 OsmoBSC(config-net-bts)# type sysmobts OsmoBSC(config-net-bts)# description "Virtual BTS" OsmoBSC(config-net-bts)# ipa unit-id 4242 0 OsmoBSC(config-net-bts)# band DCS1800 OsmoBSC(config-net-bts)# codec-support fr hr efr amr OsmoBSC(config-net-bts)# cell_identity 4242 OsmoBSC(config-net-bts)# location_area_code 4242 OsmoBSC(config-net-bts)# base_station_id_code 4242 OsmoBSC(config-net-bts)# base_station_id_code 42 OsmoBSC(config-net-bts)# ms max power 40 OsmoBSC(config-net-bts)# trx 0 OsmoBSC(config-net-bts-trx)# max_power_red 20 OsmoBSC(config-net-bts-trx)# arfcn 875 OsmoBSC(config-net-bts-trx)# timeslot 0 OsmoBSC(config-net-bts-trx-ts)# phys_chan_config CCCH+SDCCH4 OsmoBSC(config-net-bts-trx-ts)# exit OsmoBSC(config-net-bts-trx)# timeslot 1 OsmoBSC(config-net-bts-trx-ts)# phys_chan_config TCH/F OsmoBSC(config-net-bts-trx-ts)# exit OsmoBSC(config-net-bts-trx)# timeslot 2 OsmoBSC(config-net-bts-trx-ts)# phys_chan_config TCH/F OsmoBSC(config-net-bts-trx-ts)# exit OsmoBSC(config-net-bts-trx)# timeslot 3 OsmoBSC(config-net-bts-trx-ts)# phys_chan_config TCH/F OsmoBSC(config-net-bts-trx-ts)# exit OsmoBSC(config-net-bts-trx)# timeslot 4 OsmoBSC(config-net-bts-trx-ts)# phys_chan_config TCH/F OsmoBSC(config-net-bts-trx-ts)# exit OsmoBSC(config-net-bts-trx)# timeslot 5 OsmoBSC(config-net-bts-trx-ts)# phys_chan_config TCH/F OsmoBSC(config-net-bts-trx-ts)# exit OsmoBSC(config-net-bts-trx)# timeslot 6 OsmoBSC(config-net-bts-trx-ts)# phys_chan_config TCH/F OsmoBSC(config-net-bts-trx-ts)# exit OsmoBSC(config-net-bts-trx)# timeslot 7 OsmoBSC(config-net-bts-trx-ts)# phys_chan_config TCH/F OsmoBSC(config-net-bts-trx-ts)# exit OsmoBSC(config-net-bts-trx)# exit OsmoBSC(config-net-bts)# exit OsmoBSC(config-net)# exit OsmoBSC(config)# exit OsmoBSC# copy running-config startup-config
Phew,
So what did we actually do here?
Well as we’re getting the majority of the smarts for the BTS from the BSC, we’ve got to tell the BSC all about how we want the BTS setup. (Believe it or not this is the most abridged setup I could muster.)
The type, IPA Unit ID, band and Cell Identity make up some of the parameters we need to identify the BTS (IPA Unit ID) and give it it’s basic identity parameters.
Next up in the trx 0 section we set the contents of the 8 GSM timeslots. Our first time slot we configure as CCCH+SDCCH4 meaning the first timeslot will contain the Common Control Channel and 4 Standalone dedicated control channels, used for signalling, while the reamining 7 timeslots will be used with traffic channels for full-rate speech (TCH/F).
It’s important that what we tell the BSC the capabilities of the BTS are match the actual capabilities of the BTS. For example there’s no point configuring GPRS or EDGE support on the BSC if the BTS doesn’t support it.
If you’ve got logging enabled when the BTS connects to the BSC you’ll see errors listing the features mismatch between the two.
As you can imagine there’s better options than this for adding BTS in bulk – Osmocom Control Interface exposes these functions in an API like way, but before you start on network orchestration it’s good to know the basics.
Connecting the BTS to the BSC
So let’s go ahead and connect our BTS to the BSC.
If you’ve closed the BSC terminal since we enabled logging you’ll need to enable it again:
OsmoBSC> logging enable OsmoBSC> logging filter all 1 OsmoBSC> logging color 1
And next up we’ll try and start the BTS again:
root@gsm-bts:/etc/osmocom# osmo-bts-virtual -c osmo-bts-virtual.cfg ((*)) | / \ OsmoBTS <0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241 <0012> input/ipaccess.c:901 enabling ipaccess BTS mode, OML connecting to 127.0.0.1:3002 <0012> input/ipa.c:128 127.0.0.1:3002 connection done <0012> input/ipaccess.c:724 received ID_GET for unit ID 4242/0/0
And on the BSC you’ll see roughly the same thing:
OsmoBSC# <0016> input/ipa.c:287 0.0.0.0:3002 accept()ed new link from 127.0.0.1:40193 <0004> abis_nm.c:490 BTS1 reported variant: omso-bts-virtual <0004> abis_nm.c:578 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS1: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown <0016> input/ipa.c:287 0.0.0.0:3003 accept()ed new link from 127.0.0.1:44053 <0003> osmo_bsc_main.c:291 bootstrapping RSL for BTS/TRX (1/0) on ARFCN 0 using MCC-MNC 001-01 LAC=4242 CID=4242 BSIC=42
If you’ve made it this far, congratulations. Our virtual BTS is now connected to our BSC – If it wasn’t virtual we’d be on the air!
So in the next post we’ll setup our SDR hardware as a BTS, then provision it on the BSC, and then our cell will be on the air.