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.
Finding the Current IP
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.
Changing IP Details
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,
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”.
Media Handling – OsmoMGW
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.
MNCC-SAP & Call Routing
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.
Configuring Osmo-MSC to talk MNCC
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,
MNCC-SAP sounds great but platform X only speaks SIP
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.
Local Call, Local Switch
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.
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.
Switching Function
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.
Visitor Location Register Function
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.
Authentication, Ciphering and EIR Queries
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.
Core Network Identity
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.
Setup & Connections
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:
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.
Follow Up
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.
