I put together some laser cut case designs for the Osmocom SIMtrace,
Quite happy with the results.
If you want to cut your own, I’ve sent the DXF files to the mailing list, and will try and add to the project.
Also uploaded here as seems some folks had issues getting them from the mailing list.
In our last Osmocom post we talked about the basics of packet data, and configuring our BTSs to support it.
In this post we’ll take a look at using Osmocom’s Serving Gateway Support Node (SGSN) named OsmoSGSN.
At the BSC traffic is divided into two categories, Circuit Switched (CS) traffic (Like voice calls & SMS) which is handed by the MSC, and Packet Switched (PS) traffic (Mobile data) is handled by the SGSN.
The SGSN acts as an anchor point for our packet data, it connects our BSC (that handles our RAN) to the GGSN (that handles the connection to external data networks).
Although it’s not technically possible to run a data only 2G/3G network (you require the MSC) it almost could be.
The SGSN handles authentication of subscribers, and runs the PS network completely standalone from the CS network. The SGSN does it’s own handover management, authentication, etc, without any connection to the MSC.
Like the previous Osmocom network elements we’ve covered, we’ll access the SGSN via Telnet on localhost (the server running the Osmocom stack) on port 4254.
Once we’ve accessed the terminal we’ll escalate our privileges using the enable command, and run configure terminal to start configuring,
We’ll begin by setting the local IP our SGSN will listen on, the gtp local-ip, we’ll need this to be externally accessible for our BTSs, so set it to the IP of the server.
sgsn gtp local-ip 10.0.1.201
Next we’ll need to configure the IP of our GGSN. It gets a bit messy if we’re running everything on one box, as we’re going to have the SGSN and the GGSN trying to communicate on the same ports for GTP, so best to assign an IP in the loopback range, like 127.0.0.2 in my case, for the GGSN:
sgsn gtp local-ip 10.0.1.201 ggsn 0 remote-ip 127.0.0.2 ggsn 0 gtp-version 1 ggsn 0 no echo-interval apn * ggsn 0
We can also steer GGSN selection based on the APN, for example an APN for a corporate network, you may want to have a dedicated GGSN for, for example, we could create a second GGSN – GGSN 1 and route any traffic on our “special.access.net” APN to that GGSN, and everything else to GGSN0:
sgsn gtp local-ip 10.0.1.201 ggsn 0 remote-ip 127.0.0.2 ggsn 0 gtp-version 1 ggsn 0 no echo-interval ggsn 1 remote-ip 10.0.1.99 ggsn 1 gtp-version 1 ggsn 1 no echo-interval apn special.access.net ggsn 1 apn * ggsn 0
You may notice that APNs look like domain names – that’s because they can be,
If we owned the domain special.access.net we could set it to resolve to the GGSN IP we’re using for the special.access.net GGSN at 10.0.1.99, and instead of hardcoding the IP in our config use a DNS server (like 8.8.8.8) to resolve these.
sgsn gtp local-ip 10.0.1.201 ggsn dynamic grx-dns-add 8.8.8.8
But for now, in order to keep our config simple we’ll just configure the one GGSN (GGSN 0) and route all APNs to it:
sgsn gtp local-ip 10.0.1.201 ggsn 0 remote-ip 127.0.0.2 ggsn 0 gtp-version 1 ggsn 0 no echo-interval apn * ggsn 0
So the SGSN has it’s own connection to the HSS in order to authenticate subscribers.
Because GSM doesn’t employ Mutual Network Authentication on the SIM we can set the authentication policy on the SGSN to just allow anyone in with any SIM card and they’ll be able to attach and access packet data.
We can easily set this through the VTY:
sgsn
auth-policy accept-all
To enable authentication we’d need to setup the Subscriber in the HLR, like we did for CS only connections, and change the access mode to cs+ps in the HLR.
Then we can change our config to use a remote HLR for authentication,
sgsn
auth-policy remote
As the demand for traffic on GPRS & EDGE grew, there were still limitations on the bandwidth of the system.
To try and make the best of what’s available, header compression is available, similar to what we’ve seen with ROHC in VoLTE.
To learn more about setting up compression and encryption of the data, take a look in the Osmo-SGSN Manual.
Charging in mobile networks is a topic we could spend weeks on, but we’re not going to!
OsmoSGSN implements a simple CDR based charging mechanism that writes to a text file a simple CSV file with most importantly the IMSI and bytes in / out for each subscriber, that can be used to implement offline charging (Post paid) if required, and with some hacky scripts can even cut off sessions after reaching a certain amount of throughput (online charging aka pre-paid).
By adding the below to our config OsmoSGSN will write CDRs into /home/nick/sgsn.cdr every 60 seconds.
sgsn cdr filename /home/nick/sgsn.cdr cdr interval 30
Here’s a complete copy of my running config, you’ll obviously need to change the 10.0.1.201 IP that I’m using to the IP you’re using for your server.
osmo-sgsn.cfg
Formerly NextEPC.
Related to / branched from OMEC.
Based on OMEC, with a focus on Fixed Wireless more than mobile.
Not fair to consider it just an EPC, Magma is highly scaleable and designed with a focus on Fixed Wireless offerings.
Supported by the Facebook Telecom Infra Project.
Supported by Open Networking Foundation, Sprint and several other large players.
OMEC has each Network Element in it’s own repo in GitHub and each is managed by a different team.
In use by at least one commercial operator (in some capacity).
Seems to only compile on 16.04 and not really
(from the guys who produced srsLTE / srsENB / srsUE)
With just one cell/BTS, your mobile phone isn’t all that mobile.
So GSM has the concept of handovers – Once BTS (cell) can handover a call to another cell (BTS), thus allowing us to move between BTSs and keep talking on a call.
Note: I’ll use the term BTS here, because we’ve talked a lot about BTSs throughout this series. Technically a BTS can be made up of one or more cells, but to keep the language consistent with the rest of the posts I’ll use BTS, even though were talking about the cell of a BTS.
If we’re on a call, in an area served by BTS1, and we’re moving towards BTS2, at some point the signal strength from BTS2 will surpass the signal strength from BTS1, and the phone will be handed over from BTS1 to BTS2.
Handovers typically only occur when a channel is in use (ie on a phone call) if a phone isn’t in use, there’s no need to seamlessly handover as a brief loss of connectivity isn’t going to be noticed by the users.
The question as to when to handover a call to a neighbouring cell, comes down to the signal strength levels the phone is experiencing.
The phone measures the signal strength of up to 6 nearby (neighbouring) BTSs, and reports what signal strength it’s receiving to the BTS that’s currently serving it.
The BTS then sends this info to the BSC, in the RXLEV fields of a RSL Measurement Report packet.
With this information the BSC makes the determination of when to handover the call to a neighbouring BTS.
There’s a lot of parameters that the BSC takes into account when making the decision to handover to a neighbouring BTS, but for the purposes of this explanation, we’ll simplify this and just imagine it’s based on which BTS has the strongest signal strength as seen by the phone.
Our phone can only monitor the signal strength of so many neighboring cells at once (Up to 6). So in order to know which frequency (known as ARFCNs) to take signal strength measurements on, our phone needs to know the frequencies it should expect to see neighbours, so it can measure these frequencies.
The System Information Block 2 is broadcast by the BTS on the BCCH and SACCH channels, and contains the ARFCNs (Frequencies) of the BTSs that neighbour that cell.
With this info our Phone only needs to monitor the frequencies (ARFCNs) of the cells nearby it’s been told about in the SIB2 to check the received power levels on those frequences.
This is vastly simplified…
So our phone is armed with the list of neighbouring cell frequencies (ARFCNs) and it’s taking signal strength measurements and sending them to the BTS, and onto the BSC. The BSC knows the strength of the signals around our phone on a call.
With this information the BSC makes the decision that the serving cell (BTS) the phone is currently connected to is no longer the best candidate, as another BTS would provide a higher signal strength and begins a handover to a neighbouring BTS with a better signal to the phone.
Our BSC starts by giving the new BTS a heads up it’s going to hand a call of to it, by setting up the channel to use on the new BTS, through a Channel Activation message.
Next a handover command is sent to the phone via the BTS it was initially connected to (RSL Handover Command), telling the phone to begin handover to the new BTS and the channel it should move to on the new BTS it setup earier.
The phone moves to the new BTS, and is acknowledged by the phone. The channels the phone was using on the old BTS are released and the handover is complete.
There is a lot more to handovers than just this, which we’ll cover in a future post.
When setting up the timeslots on the TRX for each BTS on your BSC, you’ll notice you have to set a channel type.
So what do these acronyms mean, and how do they affect the performance of the network?
GSM channels break down into one of to categories, control channels – used for signalling, and traffic channels, used for carrying information to/from a user.
A network with only control channels wouldn’t allow a call to be made, as there would be no traffic channels to carry the audio of the call,
Conversely a network with only traffic channels would have plenty of capacity for calls, but without a control channel would have no way of setting them up.
Traffic channels break down into a further two categories, voice channels for carrying call audio, and data channels for carrying GPRS data.
There’s a few variants of voice channel based on the codec used for encoding the voice data, the more compressed / small the audio signal is, the more you can cram in per channel, at the sacrifice of voice quality.
Common options are Traffic Channel – Full Rate (TCH/F), & Traffic Channel – Half Rate (TCH/F) channels.
When GPRS was introduced it needed to be transported on a traffic channel, but unlike a voice channel, the resources weren’t going to be used 100% of the time (like in a voice call) and could be shared on an as-needed basis.
Data channels are also also broken down into full rate and half rate channels, like Traffic Channel – Full Rate (TCH/F), & Traffic Channel – Half Rate (TCH/F) channels.
Control channels carry the out of band signalling between the Phone and the BTS.
Broadcast Channels are by their very nature – Broadcasted, this means every phone on the BTS gets these messages.
There are 3 broadcast channels, the FCCH for frequency corrections, SCH for synchronisation and BCCH for a common channel that transmits information to all phones, containing info on the network such as the PLMN, neighbouring cells, etc.
The PCH – Paging Channel, is used to page phones in idle mode. All phones will listen on the paging channel, and if they hear their identifier will establish a connection back to the network.
RACH the Random Access Control Channel is used for when the phone wants to establish a connection with the network, by picking a random timeslot to transmit it’s data on the RACH.
The ACGC is the Access Grant Channel, containing information about dedicated channels to be assigned to phones.
Like dedicated traffic channels, dedicated channels are only in use by one phone at a time.
The SDCCH is the standalone dedicated control channel, over which location updates, SMS, authentication & call setup / teardown signalling is transferred.
The SACCH – slow Associated Control Channel is used for timing advance (when users are further from the BTS timing advances are needed to ensure propogation time is taken into account), power control information, signaling data and radio measurements.
Finally the FACCH – Fast Associated Control is used for transferring larger messages such as for handover information,
Depending on if you’re wearing a tin foil hat or not, silent SMS and silent calls could be a useful tool to for administering the network or a backdoor put in to track citizenry!
Regardless of it’s reasons for existence, let’s take a look at what it actually does, and how we can use it.
To conserve battery and radio resources, terminals / UEs go into an idle state where they monitor the RSSI of the BTS/NodeB and the broadcast/paging channels, but don’t actively send anything on the uplink.
Let’s say we wanted to get the RSSI measurements from a terminal/UE we would need the terminal to go into an active state.
We could do this by calling the terminal, or sending an SMS, but if we wanted to do it without alerting the user, that’s when we can use Silent SMS and silent calls, to do so without alerting the user.
If you want to try this you can send a Silent SMS from Osmo-MSC.
OsmoMSC# subscriber msisdn 61487654321 silent-sms sender msisdn 61412341234 send Hello World
On top of Silent SMS there’s also silent calls, allowing for a continued stream of measurements from the UE, which can also be super useful for creating a single call leg.
Another use for Silent SMS it to interface with the SIM Card, many card manufacturers provide support for “over the air” updating of the SIM Card parameters (think if MNO A purchases MNO B and they want to share a network, you don’t want to have to re-issue every SIM card with the updated PLMN, just update the parameters on the SIM).
Messages from the network operator to their SIM cards don’t need to be shown to the user, so are can be carried via Silent SMS. – SIM card manufacturers don’t make the nitty gritty details of this functionality public – it’s a proprietary interface defined by the manufacturer, simply transported by SMS.
SS7 was first introduced in the 1970s and initially was designed for large scale setting up and tearing down of calls, but due to it’s layered architecture and prominence in the industry has been used for signalling between some CS network elements in Mobile Networks, including transporting messages between the MSC and any BSCs or RNCs it’s serving.
This is going to be fairly brief and Osmocom specific, keep in mind SS7 is a giant topic so there’s a huge amount we won’t cover.
Historically SS7 networks were carried over TDM links of various types, and not over TCP/IP.
A point code is a unique address associated with each network element for addressing messages between network elements, it’s function is similar to that of an IP Address you’d use in IP networks.
When STP messaging is sent it includes a Source Point Code (SPC) and Destination Point Code (DPC).
Instead of a one-to-one connection between each SS7 device and every other SS7 device, a network element called a Signaling Transfer Point (STP) is used, which acts somewhat like a router.
The STP has an internal routing table made up of the Point Codes it has connections to and some logic to know how to get to each of them.
When it receives an SS7 message, the STP looks at the Destination point code, and finds if it has a path to that point code. If it does, it forwards the SS7 message on to the destination.
Like a router, an STP doesn’t really concern itself with the upper layer protocols and what they contain – As point codes are set in the MTP3 layer that’s the only layer the STP looks at and the upper layers aren’t really “any of its business”.
As the world moved towards IP enabled everything, TDM based Sigtran Networks became increasingly expensive to maintain and operate, so a IETF taskforce called SIGTRAN was created to look at moving SS7 traffic to IP.
The first layer of SS7 were dropped it primarily concerned the physical side of the network, and in the Osmocom implementation the MTP3 layer and up were put into SCTP packets and carried on the network.
Notice I said SCTP and not TCP or UDP? I’ve touched upon SCTP on this blog before, it’s as if you took the best bits of TCP without the issues like head of line blocking and added multi-homing of connections.
To establish an SS7 connection over IP the MTP3 message an SCTP socket is established from the device to the STP, and then an ASP Maintenance message is sent, followed by a Registration Request containing it’s point code, and presto, we have a connection.
The Osmocom STP acts in a very trusting manner by default,
When a device wants to connect to the STP it does so via a REG_REQ (Registration Request) containing it’s Point Code. The STP accepts the connection with a REG_RSP (Registration Response).
For as long as that connection stays up any SS7 messages destined to that point code of the device that just registered, the STP will now how to get it there.
Assuming you’ve already installed the OsmoSTP you can access it on 4239:
root@gsm-bts:/etc/osmocom# telnet localhost 4239 Trying 127.0.0.1… Connected to localhost. Welcome to the OsmoSTP VTY interface OsmoSTP>
After running enable we can check the current routing table:
OsmoSTP# show cs7 instance 0 sccp users SS7 instance 0 has no SCCP OsmoSTP# show cs7 instance 0 ro OsmoSTP# show cs7 instance 0 route Routing table = system C=Cong Q=QoS P=Prio Destination C Q P Linkset Name Linkset Non-adj Route 0.23.1/14 0 as-rkm-1 ? ? ? 0.23.3/14 0 as-rkm-2 ? ? ? OsmoSTP# show cs7 instance 0 as all Routing Routing Key Cic Cic Traffic AS Name State Context Dpc Si Opc Ssn Min Max Mode as-rkm-1 AS_ACTIVE 1 0.23.1 override as-rkm-2 AS_ACTIVE 2 0.23.3 override OsmoSTP# show cs7 instance 0 asp Effect Primary ASP Name AS Name State Type Remote IP Addr:Rmt Port SCTP ------------ ------------ ------------- ---- ----------------------- ---------- asp-dyn-0 ? ASP_ACTIVE m3ua 127.0.0.1:52192 asp-dyn-1 ? ASP_ACTIVE m3ua 127.0.0.1:33570
Below is a packet capture showing a connection from an MSC to the STP.
So SDR is all well and good, but a late night eBay purchase landed me two ipaccess NanoBTS units second hand from the US.
The hefty metal units are designed as GSM access points / picocells for indoor use, with a stable Uu / radio interface and speaking Abis over IP, it integrates nicely with Osmocom’s stack and was used by the Osmocom team as a bit of a development platform in the past.
Because these units are second hand, first step was finding the current IP.
I ran a packet capture on the interface the units were plugged into until I saw some traffic showing their current IP.
Once you’re in the correct subnet you can use the abisip-find tool to find any units:
abisip-find
Mine showed up on a 10.97.99.15 IP, so I put my machine on the 10.97.99.x/24 subnet so I could reach them.
Once I had the current IP details it was time to change the IP details, Unit ID and OML / AbisIP IP address.
My unit came on 10.97.99.15, but I wanted it on 10.0.1.204/24 and pointed to my BSC at 10.0.1.201, so I set that using the command,
ipaccess-config -u 1801/0/0 -o 10.0.1.201 -i 10.0.1.204/24 -g 10.0.1.1 -r 10.97.99.15
We recently covered Circuit Switched fallback between LTE EUTRAN and GSM GERAN, and the SGs interface between the MME and the MSC.
One nifty feature of this interface is that you can send SMS using the MSC to switch the SMS traffic and the LTE/EUTRAN to transfer the messaging.
This means you don’t need Circuit Switched Fallback to send or receive SMS on LTE.
I assume this functionality was added to avoid the signalling load of constantly changing RAN technologies each time a subscriber sent or received an SMS, but I couldn’t find much about it’s history.
In order to get this to work you’ll essentially need the exact same setup I outlined in my CSFB example (Osmo-MSC, Osmo-STP, Osmo-HLR populated with the IMSI and MSISDN values you want to use for SMS), although you won’t actually need a GERAN / GSM radio network.
Once that’s in place you can just send SMS between subscribers,
Plus from the VTY terminal of OsmoMSC you can send SMS too:
OsmoMSC# subscriber msisdn 61487654321 sms sender msisdn 61412341234 send Hello World
I’ve talked about how LTE’s EUTRAN / EPC has no knowledge about voice calls or SMS and instead relies on IMS/VoLTE for these services.
Circuit Switched Fallback allows UEs to use a 2G or 3G network (Circuit Switched network) if their device isn’t connected to the IMS network to make calls as the 2G/3G network can handle the voice call or SMS routing via the Mobile Switching Center in the 2G/3G network.
However for incoming calls destined to the UE (Mobile Terminated) the MSC needs a way to keep track of which MME is serving the UE so it can get a message to the MME and the MME can relay it to the UE, to tell it to drop to a 2G or 3G network (Circuit Switched network).
The signalling between the MME (In the LTE EPC) and the MSC (In the GSM/UTRAN core) is done over the SGs interface.
While the SGs interface is primarily for managing user location state across multiple RAN types, it’s got a useful function for sending SMS over SGi, allowing users on an LTE RAN to send SMS via the MSC of the 2G/3G network (GSM/UTRAN core).
When a UE connects to the LTE RAN (EUTRAN) the MME signals the GSM/UMTS MSC with an SGsAP-LOCATION-UPDATE-REQUEST,
This request includes the IMSI of the subscriber that just attached and the FQDN of the MME serving that UE.
The MSC now knows that IMSI 001010000000003 is currently on LTE RAN served by MME mmec01.mmegi0002.mme.epc.mnc001.mcc001.3gppnetwork.org,
If a call or SMS comes into the MSC destined for the MSISDN of that IMSI, the MSC can page the UE on the LTE RAN to tell it to do an inter-RAN handover to GSM/UMTS.
In order to get this working you’ll need OsmoMSC in place, your subscribers to exist on OsmoHLR and the LTE HSS – For example Open5GS-HSS.
If you’re not familiar with OsmoMSC or the Osmocom stack I did a series of posts covering them you can find here. If you want to get this setup I’d suggest following the posts on installing the Osmocom Software, setting up the MSC, the STP and the HLR.
Once you’ve done that the additional config on OsmoMSC is fairly simple, we just define a new SGs interface to listen on:
OsmoMSC Config:
sgs local-port 29118 local-ip 0.0.0.0 vlr-name vlr.msc001.mnc001.mcc001.3gppnetwork.org end
On the Open5GS side we’ve got to include the SGs info the MME config. Keep in mind the Tracking Area Code (TAC) in LTE must exist as the Location Area code (LAC) in GSM, here’s an extract of the MME section of YAML config in the Open5GS MME config:
mme:
freeDiameter: /etc/freeDiameter/mme.conf
s1ap:
gtpc:
sgsap:
addr: 10.0.1.9
map:
tai:
plmn_id:
mcc: 001
mnc: 01
tac: 7
lai:
plmn_id:
mcc: 001
mnc: 01
lac: 7
gummei:
plmn_id:
mcc: 001
mnc: 01
mme_gid: 2
mme_code: 1
tai:
plmn_id:
mcc: 001
mnc: 01
tac: 7
security:
integrity_order : [ EIA1, EIA2, EIA0 ]
ciphering_order : [ EEA0, EEA1, EEA2 ]
network_name:
full: Open5GS
sgw:
gtpc:
addr: 127.0.0.2
addr: 10.0.1.252
pgw:
gtpc:
addr:
- 127.0.0.3
- ::1The EUTRAN will need to advertise the presence of it’s GERAN neighbours and vise-versa so the UE/terminals know what ARFCN to move to so they don’t need to scan for the presence of other RATs when performing the handover.
Setting this up will depend on your eNB / BSC and goes beyond the scope of this post.
I’ll cover setting up neighbours in a later post as it’s a big topic.
If you don’t have neighbours configured, the handover will still work but will be much slower as the UE will have to scan to find the serving cell it’s reselecting to.
So we’ve got a functional network, but let’s dive deeper into what we can do to connect it with other networks and how things work in “the real world”.
The Audio/Voice (media stream) data on a call between subscribers does not go directly between the subscribers and instead needs to be proxed relayed. The reason for this is because there’s no direct link from one BTS to another BTS (even if they are served by the same BSC) and as our subscribers can move from cell to cell while on a call – which may mean moving from one BSC to another depending on where they’re heading – we need to have a single point for the audio to remain.
To handle this a Media Gateway is used, a single point for call audio to be “anchored” – meaning regardless of which BTS/BSC is serving the subscribers on either end of the call, the media will be sent by both parties to a single destination (The Media Gateway), and that destination will send the audio to the other party.
The Media gateway relays / proxies the Media Stream – the RTP packets containing the call audio. OsmoMSC provides the SDP payload containing the codecs and RTP details for the session via MGCP (Media Gateway Control Protocol) to the OsmoMGW which relays the audio.
In terms of running osmo-mgw we installed it earlier,
The only parameter you really need to change is the rtp bind-ip,
On the MGW you can also limit and restrict the codecs supported and also allow or disallow transcoding.
In it’s default mode, the OsmoMSC will look at the destination a call is being sent to, and if the destination is a subscriber on the network (in it’s VLR), will route the call to that subscriber
This on-net only mode is great but it puts our network on an island – cut off from the outside world.
Calls between MSCs, to the PSTN and users everywhere else are not possible in this scenario.
3GPP defined “MNCC-SAP” (Mobile Network Call Control – Service Access Point) a protocol for handling calls to/from destinations outside of the local MSC.
When in MNCC-SAP mode all calls (even on-net calls between subscribers on the same MSC) are routed to the external MNCC-SAP, and left up to it to determine how to route the call.
As we just covered by default Osmo-MSC only switches calls internally between subscribers, so we’ll need to turn off this behaviour and isntead reconfigure it to talk MNCC-SAP.
To do this we’ll telnet / VTY into Osmo-MSC;
root@gsm-bts:/etc/osmocom# telnet localhost 4254 Welcome to the OsmoMSC VTY interface OsmoMSC - Osmocom Circuit-Switched Core Network implementation OsmoMSC> enable OsmoMSC# configure terminal OsmoMSC(config)# msc OsmoMSC(config-msc)# mncc external /tmp/msc_mncc OsmoMSC(config-msc)# end OsmoMSC# cop run st Configuration saved to /etc/osmocom/osmo-msc.cfg
After making this change we have to restart OsmoMSC;
systemctl restart osmo-msc
Now OsmoMSC will not switch calls locally, but instead when a mobile originated call comes to the MSC, it will signal to the external MNCC via the file sock at /tmp/msc_mncc,
Enter the Osmo-SIP-Connector, which takes the MNCC-SAP messages and converts them to SIP.
From here you can tie the call control functions of the MNC into any SIP software such as Kamailio, FreeSwitch, Asterisk, etc, to handle call routing, number translation, application services like voicemail and conferencing, etc, etc.
On my to-do list is to make a call between one subscriber on GSM and one on VoLTE, I’ll cover that in a subsequent post.
So anywho, let’s get Osmo-SIP-Connector setup,
I’m running it on the same box as the MSC on 10.0.1.201,
My softphone client is running on 10.0.1.252
root@gsm-bts:/etc/osmocom# apt-get install osmo-sip-connector root@gsm-bts:/etc/osmocom# telnet localhost 4256 Welcome to the OsmoSIPcon VTY interface OsmoSIPcon> enable OsmoSIPcon# configure t OsmoSIPcon(config)# mncc OsmoSIPcon(config-mncc)# socket-path /tmp/msc_mncc OsmoSIPcon(config-mncc)# exit OsmoSIPcon(config)# sip OsmoSIPcon(config-sip)# local 10.0.1.201 5060 OsmoSIPcon(config-sip)# remote 10.0.1.252 5060 OsmoSIPcon(config-sip)# end OsmoSIPcon# cop run st Configuration saved to /etc/osmocom/osmo-sip-connector.cfg
Now any Mobile Originated calls will result in a SIP INVITE being sent to 10.0.1.252 port 5060 (using UDP).
Any SIP INVITES where the request URI is a valid MSISDN @ 10.0.1.201 from 10.0.1.252 will be routed to the correct subscriber for that MSISDN.
A small note – The GSM codec is (unsurprisingly) used as the codec for GSM calls by default.
Some handsets support different codecs, but many off-the-shelf IP phones don’t include GSM support, so you may find you’re required to transcode between codecs if there is no support for the other codecs.
So now we’re able to define our call routing logic in something that speaks SIP and connect calls between multiple MSCs, VoLTE / IMS networks and fixed networks, all based on what we do with the SIP.
If two subscribers on the same BSC call each other, the RTP / call audio will route to the MGW where it’s anchored.
This makes sense from a mobility standpoint, but adds load to the MGW and relies on a quality A interface connection, which may be an issue depending on what backhaul options you have.
Local Call, Local Switch is a 3GPP spec to allow the RTP / call audio to act as the RTP proxy instead of the MGW.
There’s a good talk on how this works from OsmoDevCOn 2018 you can find here.
So now we’ve covered the basics of what’s involved let’s get some traffic on our network.
For starters we’ll need to start each of our network elements and bring up whichever BTS hardware we’re using.
In order for our calls to have audio, we’ll need to set a parameter on the Media Gateway. We’ll cover the Media Gateway in more detail down the line, but there’s one value in the MGW we’ll need to set in order to have calls working, and that’s the rtp bind-ip value.
You can either set it in the config file or via VTY/Telnet on port 4243.
We’ve talked about using systemctl to start all the services, but there’s a script in the /etc/osmocom directory called osmocom-all.sh which starts all the network elements for us.
Once you’ve got all the services started I’d suggest hopping onto the OsmoBSC and enabling all the logging you can, then connecting / starting your BTS.
You should see the Abis over IP connection & OML link come up as the BTS connects to the BSC.
And then, hold your breath, power up a phone and search for networks.
All going well you’ll see OsmoMSC in the network search, select it and you should see log data flying by as the phone (“terminal”) connects to the network.
Assuming you configured the IMSI of the SIM on the HLR you should be connected to the network and showing bars on the phone.
You can check your phone number (MSISDN) by dialling the USSD code *#100#
But it’s not a network with just one phone connected, connect a second phone, check it’s phone number the same way and call from one to the other.
SMS should also just work.
And there you have it, a functional GSM network!
But this isn’t the end for us, it’s really just the beginning.
There’s still so much more to learn and work on – Over the next few weeks / months we’ll add packet data to the network with GPRS or EDGE, connect into external call routing and SMS routing interfaces, use Circuit Switched Fallback to provide voice service to users on LTE networks and roam between them.
We’re nearing the end of our “setup” story – So far we’ve covered the access network (BTS & BSC) and our subscriber database (The HLR) so now let’s talk about one of the key “Core” elements of the network – the Mobile Switching Center (MSC).
The MSC’s name kind of says it all, it’s a switching center for mobiles.
The MSC handles switching of voice calls and SMS/text messages between local & remote subscribers and networks.
Because GSM was designed to be voice centric (Keep in mind the first GSM network went live in 1991) the MSC’s primary function is switching phone calls between subscribers.* For this the MSC has to keep track of which subscribers it’s currently serving, their capabilities and how to reach them -which BSC they’re being served by and therefore which BTS they’re being served by.
The OsmoMSC also features a minimalistic SMSC (Short Message Service Server) for routing SMS traffic between subscribers on the network.
This basic SMSC acts in a store-and-forward fashion. Production networks would typically use an external SMSC for handling SMS, OsmoMSC has the SMSC functionality built in by default, but the interfaces are there if you wanted to use an external SMSC.
Any calls/texts to subscribers/destinations outside the MSC (for example a call to a mobile subscribers on a different carrier or on the PSTN) are typically routed to another MSC known as the Gateway MSC.
The GMSC handles the interconnection with other networks. We’ll touch upon this later with the SIP connector, but for now we’ll focus just on on-net calls between subscribers.
It’s worth noting that the MSC does not sit in the media stream, it just sets up and tears down the calls, we’ll cover more on the nitty-gritty of calling in GSM soon.
The MSC also acts as the interface to the HLR for AAA, as we covered in our last post, the HLR provides the authentication role and also provides the subscriber data to the MSC. Subscriber data is copied from the HLR to the internal HLR cache on the MSC known as the Visitor Location Register (VLR) after a subscriber attaches.
In the last post we talked about the role of the HLR in terms of Authentication on the network, the authentication vectors but the policies that enforce this are set on the MSC.
The MSC queries the admission control info from the HLR, but it’s the MSC that’s responsible for enforcing these rules.
The MCC (Mobile Country Code) and MNC (Mobile Network Code) of the network (Together the MCC + MNC are referred to as the PLMN ID), along with the network name, are configured on the MSC.
While this may seem like a rather small detail, the PLMN ID is analogous to the SSID of a WiFi network – it’s what identifies your network out of all the others on the air, and the network name shows up on your phone when you’re connected showing your network name.
The BSC we setup earlier communicates with the MSC via SS7 Point Codes. We’ll go into how point codes route requests in a later post, but so long as you’re running Osmo-BSC, Osmo-MGW, Omso-MSC and Osmo-HLR on the same machine you won’t need to link them to each other like we had to do with adding our BTS to the BSC.
Instead we’ll just need to start everything required:
systemctl restart osmo-stp systemctl restart osmo-hlr systemctl restart osmo-mgw systemctl restart osmo-msc
The GSUP connection between the MSC and the HLR will be established at startup, but BSCs will only establish a connection to the MSC when they need something from the MSC.
Once we’ve got everything started we can Telnet into the MSC to confirm it’s running and check it’s status:
root@gsm # telnet localhost 4254
Assuming you can connect that’s another network element online. – We’ll leave the default the Point Codes in place so the BSC will be able to connect to the MSC, but keep in mind that the BSC will only establish a connection when it needs something from the MSC.
There’s a few topics we skipped over in this topic, stuff like SS7/SIGTRAN, how real world GSM calls route using MNCC-SAP, the Media Gateway and anchoring media streams and what an SMSC does.
I’ll do posts covering each of these topics in more depth.
The Home Location Register serves the AAA functions in a GSM / UMTS (2G/3G) network as well as locating which Mobile Switching Center (MSC) a subscriber is being served by.
The HLR is the equivalent of the Home Subscriber Server in LTE (I’ve written a fair bit about the role of the HSS in LTE networks, and I’ve published my own open-source HSS software.)
One obvious need is to authenticate our subscribers so the network can verify their identity,
The IMSI (International Mobile Subscriber Identity) is used to identifier the user from all the other mobile subscribers worldwide. The IMSI is exposed to the user, but transmitting the IMSI in the clear is typically something that’s avoided where possible on the air interface.
GSM uses a single shared secret between the SIM and the network (the K key) for authentication. This shared secret is not exposed to the user and is never transmitted over the air.
When a user wants to authenticate, the HSS network takes a Random key (RAND) and mixes it with the secret key (K) to generate a Signed Response called SRES. The network sends the RAND key to the subscriber, and their SIM takes the secret key (K) and mixes it with the RAND value from the network, before sending their signed response (SRES) back to the network.
If the SRES sent by the subscriber matches the SRES generated by the HSS, then the user is authenticated. The set of keys used for one authentication session is referred to as an Authentication Vector or Authentication Tuple.
In Osmocom the generation of Authentication Tuples is requested in the GSUP “SendAuthInfo” request, and responded to by the “SendAuthInfoResponse” sent to the HLR by the MSC.
In a GSM setting the network only authenticates the subscribers, the subscribers don’t authenticate the network. In practice, this means there’s no way to verify in GSM if the network you’re connected to is the network it’s claiming to be.
Due to this shortfall and the cryptographic weakness in A5/x algorithm, 3GPP specified the AKA algorithm for mutual network authentication in 3G/UMTS networks.
I’ve written a fair bit about the role of SIMs for authentication in LTE which is the same scheme used in 3G/UMTS if you’d like to learn more.
Technically the generation of Authentication Vectors is handled by an Authentication Center (AuC) however OsomoHLR has an internal AuC that handles this internally.
After a user has authenticated, the MSC sends an UpdateLocationRequest via GSUP to the HLR to let it know the current location of the subscriber is served by that MSC.
The Update Location Request is sent at the start of the session, periodic Update Location Requests can be sent based on the timers configured, and a Cancel Location Request can be sent when the subscriber disconnects from the MSC.
When the Update Location Request has been sent by the MSC, the HLR sends the MSC the subscriber’s info, and the MSC copies it to it’s own internal HLR called a Visitor Location Register (VLR). The VLR means the MSC doesn’t need to keep querying user data from the HLR.
This is again requseted by the MSC to the HLR via a GSUP request InsertSubscriberData Request which contains:
Note: In production GSM networks TCAP/MAP is used for communication between the HLR and the MSC. Osmocom uses GSUP for carrying this data instead.
Because mobiles are expensive they’ve historically been a target for theft.
To try and mitigate this GSMA encourages carriers to implement an Equipment Identity Register (EIR).
The EIR is essentially a database containing IMEIs (The Identifiers of Mobiles / Terminals) and permitting / denying access to the network based on the IMEI.
The idea being if a mobile device / terminal is stolen, it’s IMEI is blacklisted in the EIR and regardless of what SIM is put into it, it’s not permitted to access the network.
When a device connects to the network if configured the MSC will query the EIR (On the HLR in our case) with a Check IMEI Request, and will get a Check IMEI Result either permitting or denying access to the network.
Unfortunately, there is no global stolen IMEI database, meaning if a device is stolen and blocked on MNO X’s network, it may still work on MNO Y’s network if they don’t share stolen IMEI data.
We actually installed OmsoHLR in the post on Base Station Controllers, so we’ll just need to start the daemon / service:
systemctl start osmo-hlr
I’m going to enable the EIR functionality of the HSS by changing the config of the HLR, this is optional but it’s useful to use the EIR functionality.
Like with our other network elements we’ll use Tenet to interactively configure this one,
root@gsm-bts:/home/nick# telnet localhost 4258 Welcome to the OsmoHLR VTY interface OsmoHLR> enable OsmoHLR# configure terminal OsmoHLR(config)# hlr OsmoHLR(config-hlr)# store-imei OsmoHLR(config-hlr)# exit OsmoHLR(config)# exit OsmoHLR# copy running-config startup-config
But before we go adding subscribers, let’s talk about SIMs.
Okay, I’ve written a lot about SIMs before, but there’s still more to talk about!
There’s really only one peice of information from your SIM we require to add the subscriber to the HLR, and that’s the IMSI – The unique identifier of the subscriber on the SIM. You can typically view the IMSI from your mobile device / terminal.
If you want to authenticate subscribers properly (confirm their identity) and enable encryption on the air interface, you’ll need to know the K key of the SIM, for that you’ll need a programmable SIM card like the Sysmocom programmable SIM cards, (By buying from Sysmocom you’re supporting the Osmocom project too).
So now we’ve got that out of the way, let’s add a subscriber:
We’ll connect to OsmoHLR via Telnet, the port it listens on is 4258:
root@gsm-bts:/home/nick# telnet localhost 4258 Welcome to the OsmoHLR VTY interface OsmoHLR> enable OsmoHLR# subscriber imsi 001010000000004 create OsmoHLR# subscriber imsi 001010000000004 update msisdn 61412341234 OsmoHLR# subscriber imsi 001010000000004 update aud2g comp128v3 ki 465B5CE8B199B49FAA5F0A2EE238A6BC
So I’ve created a subscriber with IMSI 001010000000004 in the HSS and assigned an MSISDN (phone number).
Optionally, if you’re using SIM cards you can program you can set the Ki / K key for authentication using the update aud2g function, if not you can skip that step.
And with that we’ve added our first subscriber, lather rinse repeat with any additional subscribers / SIMs you want to provision.
By default subscribers created using this method have access to both Circuit Switched (Voice and SMS) and Packet Switched (Data) networks. (We haven’t configured Packet Switched services yet)
If you’d like to restrict access to one, both or none of the above options, you can do that by using the subscriber update command to set the services available to those subscribers.
OsmoHLR# subscriber id 3 update network-access-mode cs+ps OsmoHLR# subscriber id 3 update network-access-mode cs OsmoHLR# subscriber id 3 update network-access-mode ps OsmoHLR# subscriber id 3 update network-access-mode none
In reality if you’re trying to operate a network it’s not feasible to manually add each subscriber as needed.
If you’re buying SIMs in bulk preconfigured you’ll get sent a file containing the IMSI and Crypto values of each card, and you’d ingest that into your HLR.
We’ve used the Osmocom VTY / Telnet interface in quite a few posts now (hopefully you’re getting comfortable with it) but there’s another interface most Osmocom software has – the Osmocom Control Interface – aimed at providing a uniform way to interface external scripts / programs with Osmocom.
If you’d like to learn more about the Control Interface have a read of the OsmoHLR manual and take a look at this example in Python.
For most scenarios you would pre-provision each SIM in the HLR, if the SIM’s IMSI isn’t in the HLR then it’s access is rejected. However there are some scenarios where you may want to allow anyone to access the network, in this scenario Osmo-HLR features a “Create Subscribers on Demand” function.
This may be useful if you’re setting up a network where you don’t control the SIMs for example.
Let’s say we want to automatically create users with access to voice & data services and assign a 10 digit MSISDN for that subscriber, we can do that with:
OsmoHLR> enable OsmoHLR# configure terminal OsmoHLR(config)# hlr OsmoHLR(config-hlr)# subscriber-create-on-demand 10 cs+ps
Alternatley you may wish to simply add the subscriber to the HLR but not provide any services:
OsmoHLR> enable OsmoHLR# configure terminal OsmoHLR(config)# hlr OsmoHLR(config-hlr)# subscriber-create-on-demand no-msisdn none
Then if you wish to grant access to these users you can use the subscriber update network-access-mode method we talked about earlier to allow services for that user.
To give some context I’ve attached a packet capture of the connection from the MSC to the HLR for some attach procedures on my lab network.
In the last post we covered the config required to provision a new BTS in our BSC.
We’re going to do roughly the same thing this time around, as we connect our SDR based BTS to our BSC.
Before we fire up the BTS side of things make sure you’ve stopped the virtual BTS and disabled it.
systemctl stop osmo-bts-virtual systemctl disable osmo-bts-virtual
Next up we’ll edit the config of osmo-bts-trx.
vi /etc/osmocom/osmo-bts-trx.cfg
We’ll edit the oml remote-ip to the IP of the server running your BSC, if you’re running on on the same machine you can leave it as localhost (127.0.0.1).
Next up we’ll set the Unit-ID of the BTS, this identifies the BTS inside the BSC,
I’ll set it to unit-id 1234 by changing ipa unit-id 1234 0
Finally we’ll change the logging config to show everything by changing it to:
log stderr logging filter all 1 !
Next up we’ll configure the BTS on the BSC
This is essentially a copy of the provisioning process we followed in the last post, the only difference is we’ll use BTS 2 (as BTS 1 is setup for our Virtual BTS) in the config, and set the few different identifier such as the ipa unit id for the SDR based BTS.
telnet localhost 4242 OsmoBSC> enable OsmoBSC# configure terminal OsmoBSC(config)# network OsmoBSC(config-net)# bts 2 OsmoBSC(config-net-bts)# type sysmobts OsmoBSC(config-net-bts)# description "LimeSDR Based BTS" OsmoBSC(config-net-bts)# ipa unit-id 1234 0 OsmoBSC(config-net-bts)# band DCS1800 OsmoBSC(config-net-bts)# codec-support fr hr efr amr OsmoBSC(config-net-bts)# cell_identity 1234 OsmoBSC(config-net-bts)# location_area_code 1234 OsmoBSC(config-net-bts)# base_station_id_code 1234 OsmoBSC(config-net-bts)# base_station_id_code 12 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 876 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
Before we start the SDR based BTS it’s probably best to have 3 terminals open,
One logged into Osmo-BSC with logging enabled (see the last post for info on how to do that).
We’ll start another terminal for running the TRX modem / Layer 1 interface:
osmo-trx-lms -C /etc/osmocom/osmo-trx-lms.cfg
And in another new terminal we’ll start the BTS side;
osmo-bts-trx -c /etc/osmocom/osmo-bts-trx.cfg
All going well our terminal with Osmo-BSC should report the connection:
OsmoBSC# <0016> input/ipa.c:287 0.0.0.0:3003 accept()ed new link from 10.0.1.252:39595 <0003> osmo_bsc_main.c:291 bootstrapping RSL for BTS/TRX (2/0) on ARFCN 875 using MCC-MNC 001-01 LAC=1234 CID=1234 BSIC=12
And the osmo-trx-lms and osmo-bts-trx windows should have data flying by at a rate of knots.
If all is going to plan, our SDR is connected to our machine via osmo-trx-lms which is acting as a modem for osmo-bts-trx which is now connected to the BSC. Lot to go through, but it gets easier from here.
Let’s run a scan of the networks on our phone. I found putting mine on GSM only before scanning for networks meant it popped up a heck of a lot faster.
And lo, there it is.
Our cell is online and broadcasting it’s info. You won’t be able to connect to it at this stage as we’ve still got a few more steps to go.
In the next post we’ll introduce the Home Location Register and then the MSC.
Osmo-BSC accepts Abis over IP connections from a number of different sources,
There’s a list of supported BTS hardware that can talk out of the box to the Osmo-BSC, such as the Ericsson RBS series, ip.access nanoBTS, Nokia and Siemens units and even a virtual BTS so you can simulate the connections.
If you’re using any of these premade BTS hardware options, or osmo-bts-virtual, you probably just need to setup the basics on your BTS and point it to your BSC, end of story.
The below post will touch on using common SDR hardware to act as our BTS. If you’re not using SDR hardware you can just skip ahead to the next post on BSCs.
But, if you’re in the same boat as me, without any commercial BTS / RAN hardware, we’ll be setting it up by using an SDR platforms (In my case LimeSDR) and that’s what this tutorial will focus on.
In order to bring in a large array of SDR hardware, Osmocom have introduced Osmo-TRX, which handles the Layer 1 physical layer of the BTS, and connects to Osmo-BTS which serves as the BTS and talks Abis over IP to the MSC.
Certain hardware can talk directly to Osmo-BTS, but we’re going to rely on Osmo-TRX to act as the middleman between our SDR hardware and the BTS.
The above diagram from the Osmocom wiki shows how this fits together with generic SDR platforms, here’s how it fits together for us:
osmo-trx-lms will take care of the SDR side of the equation, pretty much serving as a modem and sending everything it gets on the Uu interface to osmo-bts-trx over UDP, and everything it receives from osmo-bts-trx over UDP it sends out the Uu interface.
osmo-bts-trx will then setup an Abis over IP connection to our BSC.
My ever growing collection of SDR hardware now includes a LimeSDR which I’ll be using for this series.
Before we can get too far we’ve got to setup the prerequisites for the LimeSDR to be able to interface with Osmo-TRX.
Osmocom now provide a binary for interfacing with LimeSDR boards directly, instead of having to use the UHD abstraction. This is a much cleaner way of interfacing with the boards and the path I’ll be taking.
For this tutorial series I’ll be using Ubuntu 18.04 and trying where possible to use packages from Repos instead of compiling from source.
LimeSuite provides the drives and utilities for interfacing with the LimeSDR.
add-apt-repository -y ppa:myriadrf/drivers apt-get update apt-get install limesuite limesuite-udev
Next we’ll connect up the LimeSDR to a USB3 port, confirm it’s there and upgrade it’s firmware:
LimeUtil --find
Assuming your LimeSDR is hooked up and everything installed you should see an output similar to this:
In which case we can upgrade the LimeSDR firmware with:
LimeUtil --update
Next we’ll start installing Osmocom Sources;
wget https://download.opensuse.org/repositories/network:/osmocom:/latest/Debian_10/Release.key apt-key add Release.key && rm Release.key echo "deb https://download.opensuse.org/repositories/network:/osmocom:/latest/xUbuntu_18.04/ ./" > /etc/apt/sources.list.d/osmocom-latest.list apt-get update
Now that we’ve got the Osmocom Debian repos added we can install the packages we need,
We’re going to install Osmo-BTS-TRX for talking to the BSC over Abis, and install Osmo-TRX-LMS for talking to the SDR.
apt-get install osmo-bts-trx osmo-trx-lms
After you’ve installed the packages, Osmo-BTS-TRX will run as a daemon, we’ll stop it for now and bring it up manually in the foreground.
systemctl disable osmo-bts-trx systemctl disable osmo-trx-bts
So now we’ve got two pieces of the puzzle, it’s time to connect the SDR to Osmo-TRX-LMS and connect Osmo-TRX-LMS to Osmo-BTS-TRX.
We’ll begin by running Osmo-TRX-LMS to connect to the LimeSDR and encapsulate the Uu data into UDP packets we send to Osmo-BTS-TRX.
Config files for Osmocom are installed in /etc/osmocom/ so we’ll run everything from that directory.
osmo-trx-lms -C osmo-trx-lms.cfg
If all was successful you’ll see something similar to what I’ve got below, showing Osmo-TRX-LMS has connected to the SDR and is ready to go.
But if you go scanning the airwaves now, you won’t see any data coming out of the SDR’s transmitter.
That’s because Osmo-TRX-LMS needs to connect to Osmo-BTS-TRX,
We’ll leave Osmo-TRX-LMS running, so let’s open up another session and start Osmo-BTS-TRX.
osmo-bts-trx -c osmo-bts-trx.cfg
You’ll see for starters that it’s Opened our transceiver (hooray),
You’ll see this reflected in the Osmo-TRX-LMS stdout, but it’ll show the poweroff command has been sent to it, so what gives?
Well, the answer becomes clear if you leave Osmo-BTS-TRX running for a minute or two,
Eventually the process stops, reporting:
<000d> abis.c:142 Signalling link down <0001> bts.c:292 Shutting down BTS 0, Reason Abis close
So what’s going on? In the same way we saw our Virtual BTS shut itself down, without a connection to the BSC (Via the Abis interface) the BTS will shut itself down, as it’s not able to run on it’s own.
This took me a shamefully long time to work out that’s why it was stopping…
In our next post we’ll introduce our BSC and provision a BTS on it.
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)
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.
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.
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.
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.
So this series of posts will focus on using Osmocom software to create a GSM network, so let’s get some Osmocom software installed, and talk about how we run and configure each network element / node.
For this tutorial series I’ll be using Ubuntu 18.04 and trying where possible to use packages from Repos instead of compiling from source.
This will get the Osmocom key added to your package manager and the Osmocom sources in apt ready for us to install.
wget https://download.opensuse.org/repositories/network:/osmocom:/latest/Debian_10/Release.key apt-key add Release.key && rm Release.key echo "deb https://download.opensuse.org/repositories/network:/osmocom:/latest/xUbuntu_18.04/ ./" > /etc/apt/sources.list.d/osmocom-latest.list apt-get update
To get started we’ll install a virtual BTS. This virtual BTS won’t simulate the Um (air) interface, but it will simulate the Abis interface towards the BSC so we can configure this virtual BTS in our BSC.
Installation is pretty straightforward:
apt-get install osmo-bts-virtual
By default Osmocom software runs as a daemon in systemctl, we’ll disable and stop this behaviour for now so we can better understand it running in the foreground:
systemctl stop osmo-bts-virtual systemctl disable osmo-bts-virtual
If you have a look in /etc/osmocom/ you’ll see .cfg files that contain our config in text files.
But that’s not the only way (or even the recommended way) that we’ll put together the config for Osmocom software, but we’ll get started by editing the config file manually.
We’ll start by setting a Unit ID of the BTS and setting the IP of the BSC.
cd /etc/osmocom/ vi osmo-bts-virtual.cfg
We’ll edit the oml remote-ip to point to the IP of the server that will run our BSC, if you’re planning on running the BTS and BSC on the same machine you can leave it as localhost (127.0.0.1).
Next up we’ll set the Unit-ID of the BTS, this identifies the BTS inside the BSC,
I’ll set it to unit-id 4242 by changing ipa unit-id 4242 0
Finally we’ll change the logging config to show everything by changing it to:
log stderr logging filter all 1 !
So that’s it in terms of config for our virtual BTS through text files, so we’ll save the file and try starting up osmo-bts-virtual.
osmo-bts-virtual -c osmo-bts-virtual.cfg
You should get a result similar to this:
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 <000d> abis.c:142 Signalling link down <0001> bts.c:292 Shutting down BTS 0, Reason Abis close Shutdown timer expired root@gsm-bts:/etc/osmocom#
So what are we seeing here?
Well Osmo-BTS-Virtual is trying to bring up it’s Abis interface but it’s not getting a connection to the the BSC (We haven’t set one up yet). No connection to a BSC means the BTS won’t go on the air as it doesn’t have any processing for itself, so it eventually times out and shuts down.
In the next post we’ll move from using osmo-bts-virtual to using a SDR to run Osmo-BTS. If you’re using commercial RAN hardware, or just playing along without any RAN, skip straight to the post on Base Station Controllers where we’ll pick up again adding our Virtual BTS to the BSC.
By far the most visable part of any mobile network (apart from your phone!) is the Base (Transciver) Stations.
Dotted around the countryside, on masts, towers and monopoles, whether you notice them or not, base stations are everywhere.
The RF side of LTE has an eNodeB, which is a smart device. – You connect it to a TCP/IP network, it establishes a connection with your MME(s) and away you go.
A GSM BTS (Base Transceiver Station) isn’t all that clever…
The BTS is a similar to the WiFi access points that talk to a centralised controller for all their thinking.
A BTS gets most of its brains from elsewhere and essentially just handles the TX/RX of baseband data.
That elsewhere is the BSC – Base Station Controller. Each BTS connects to a BSC, and a BSC would typically control a number of BTS.
We’ll explore the BSC and it’s connections in depth, but I’ve put together a basic diagram of how everything fits together below.
The Um interface is the Air Interface of GSM. It’s what takes the data and sends it out “over the air”.
There’s a lot to know about air interfaces, and I know very little. What I do know is I need to set the Um interface to use a frequency band my mobile phone supports (so I can see and connect to the network).
The fact that GSM was first deployed in 1991, explains why the Abis interface used ISDN E1/T1 TDM links to connect the Base Transceiver Stations (BTSs) to the Base Station Controller (BSC).
While now looking back you may ask why TCP/IP wasn’t used for the Abis interface, keep in mind that Windows 95 was the first version to include TCP/IP support, and that gives you an idea of the state of play. ISDN is very reliable and was well known in the telco space at that time.
I no longer have any ISDN hardware, so for me this is all going to be built using packet switched networks working as circuit switched.
Osmocom does have support for E1/T1 interfaces, so if you’ve got BTS hardware that only communicates over TDM links, that’s an option too.
GSMA never wrote a standard for taking Abis over IP, so as such each vendor has implemented it differently.
Osmocom have a flavour of Abis over IP protocol they’ve developed based on traces from a commercial implementation which we’ll be using. You can find the full protocol spec for Osmocom’s Abis over IP interface here.
With all the brains for the BTS residing in the BSC, there’s a need to control the BTS from the BSC. The Operation and Maintenance Link (OML) is a protocol for changing certain parameters of the BTS from the BSC.
A prime example of use of the OML would be the BSC turning the BTS off/on.
We’ll see a tiny bit of OML usage in the next post, just for turning the BTS off and on.
So let’s put this into practice and setup a virtual BTS with Osmocom.
Like most people at the moment because of the lockdown I’ve got a bit more time at home than normal.
Because of this I thought I’d finally dive into GSM/UMTS and all that circuit switched tech you skip out on when getting started with LTE.
Please excuse the loving tone I use when describing some older tech, it’s a result of being a telephony tragic who gets all reminiscent thinking about the first phones they interacted with & wondered about how it all worked…
My best friend is a translator of technical documents. In University, what’s the first language they study? Latin. Because it’s the root of so many languages.
While a lot of carriers have already switched off their GSM networks (There are no public GSM networks in Australia), the core of GSM is essentially shared with that of UMTS / 3G, which is still going to be around for the foreseeable future.
Circuit Switched Fallback (CSFB) is still common today for voice calls for a great many LTE handsets without VoLTE support. GSM powers GSM-R, the rail specific standard of GSM used across Europe. The uplink power of GSM can be up to 8 Watts (while in LTE it’s 20 dBm – 0.1W) which means it’s effective service area could be larger than 3G and 4G air interfaces.
GSM isn’t as dead as it might seem, so let’s have a Weekend at Bernie’s!
Disclaimer: Please let me know if I’ve got anything wrong! These posts will focus on the Omsocom network elements which do handle a few things the “non standard” way.
I wrote last week about using YateBTS to get a functional GSM / GPRS network online,
It’s great that it works from a Um interface perspective; your UE / terminal can see and connect to the network. But it’s sort of an all-in-one solution; there’s no Mobile Switching Center, Base Station Controller, Sigtran, HLR or Media Gateway; Yate ties all this up into a single easy to use package.
This gets you on the air in no time, but unfortunately you don’t get exposed to how GSM / UMTS works in the real world – real networks don’t look like YateBTS NITPC.
Osmocom (and the Sysmocom team driving many of the projects) have done a phenomenal job of building each of the network elements I just talked about pretty much “by the book”, meaning most should interop with commercial equipment and comply to the standards.
Over the next few weeks I’ll cover setting up each of the network elements, talking about what they do and how they work, and use them to create a functional GSM network (2G / Circuit Switched) using the software from Osmocom.
Once we’ve got our network functional we’ll be adding SMS, Data (GPRS / EDGE), USSD codes and even inter-RAT handover with LTE.
For this series of posts I’ll be using a mix of hardware. At the start I’ll be using a Software Defined Radio (LimeSDR) to do the RF side of the network (BTS). Osmocom has support for a lot of common SDR hardware, so hopefully for anyone wanting to follow along at home you’ll have access to a LimeSDR or USRP.
Osmocom supports many commercial BTS vendors products, as well as Sysmocom’s hardware, hardware from Range Networks. Osmocom also supports the NanoBTS range from ip.access – which are available second hand quite cheaply, which I’ll be adding to our network as well.
So buy some cheap programmable SIM cards, grab your SDR hardware or order cheap second hand GSM BTS online, and let’s get building a GSM network!
I’ll update the links in here as I publish these posts, I may forget so if there’s something missing search the site or drop me a line.
My Osmocom Config Files on GitHub
BTS In Practice with LimeSDR & osmo-bts-trx
The Base Station Controller (BSC)
Integrating our LimeSDR BTS with OsmoBSC
Integrating an ipaccess NanoBTS with OsmoBSC
Home Location Register (HLR) (with EIR & AuC)
The SS7 Signaling Transfer Point
SMS Routing
Distributed GSM
Cell Broadcast Center
External USSD Interfaces
Gateway GPRS Support Node
Basic GSM Calls
Basic GSM SMS
Basic GSM Packet Bearers
Inter BSC
Inter MSC