Category Archives: GSM

2G / Global System for Mobiles

SIM / Smart Card Deep Dive – Part 1 – Introduction to Smart Cards

I know a little bit about SIM cards / USIM cards / ISIM Cards.
Enough to know I don’t know very much about them at all.

So throughout this series of posts of unknown length, I’ll try and learn more and share what I’m learning, citing references as much as possible.

So where to begin? I guess at the start,

A supposedly brief history of Smart Cards

There are two main industries that have driven the development and evolution of smart cards – telecom & banking / finance, both initially focused on the idea that carrying cash around is unseemly.

This planet has – or rather had – a problem, which was this: most of the people living on it were unhappy for pretty much of the time. Many solutions were suggested for this problem, but most of these were largely concerned with the movement of small green pieces of paper, which was odd because on the whole it wasn’t the small green pieces of paper that were unhappy.

Douglas Adams – The Hitchhiker’s Guide to the Galaxy

When the idea of Credit / Debit Cards were first introduced the tech was not electronic, embossed letters on the card were fed through that clicky-clacky-transfer machine (Google tells me this was actually called the “credit card imprinter”) and the card details imprinted onto carbon copy paper.

Customers wanted something faster, so banks delivered magnetic strip cards, where the card data could be read even more quickly, but as the security conscious of you will be aware, storing data on magnetic strips on a card to be read by any reader, allows them to be read by any reader, and therefore duplicated really easily, something the banks quickly realised.

To combat this, card readers typically would have a way to communicate back to a central bank computer. The central computer verified the PIN entered by the customer was correct, confirmed that the customer had enough money in their balance for the transaction and it wasn’t too suspicious. This was, as you would imagine in the late 1980’s early 1990’s, rather difficult to achieve. A reliable (and cheap) connection back to a central bank computer wasn’t always a given, nor instant, and so this was still very much open to misuse.

“Carders” emmerged, buying/selling/capturing credit card details, and after programming a blank card with someone else’s fraudulently obtained card details, could write them on a blank card before going on a spending spree for a brief period of time. Racking up a giant debt that wasn’t reconciled against the central computer until later, when the card was thrown away and replaced with another.

I know what you’re thinking – I come to this blog for ramblings about Telecommunications, not the history of the banking sector. So let’s get onto telco;

The telecom sector faced similar issues, at the time mobile phones were in their infancy, and so Payphones were how people made calls when out and about.

A phone call from a payphone in Australia has sat at about $0.40 for a long time, not a huge amount, but enough you’d always want to be carrying some change if you wanted to make calls. Again, an inconvenience for customers as coins are clunky, and an inconvenience for operators as collecting the coins from tens of thousands of payphones is expensive.

Telcos around the world trailed solutions, including cards with magnetic strips containing the balance of the card, but again people quickly realised that you could record the contents of the magnetic stripe data of the card when it had a full balance, use all the balance on the card, and then write back the data you stored earlier with a full balance.

So two industries each facing the same issue: it’s hard to securely process payments offline in a way that can’t be abused.

Enter the smart card – a tiny computer in a card that the terminal (Payphone or Credit Card Reader) interacts with, but the card is very much in charge.

When used in a payphone, the caller inserts the smart card and dials the number, and dialog goes something like this (We’ll assume Meter Pulses are 40c worth):

Payphone: “Hey SmartCard, how much credit do you have on you?”

Smart Card: “I have $1.60 balance”

*Payphone ensures card has enough credit for the first meter pulse, and begins listening for Meter Pulses*

*When a meter pulse received:*

Payphone: “Please deduct $0.40 from your Balance”

Smart Card: “Ok, you have $1.20 remaining”

This process repeats for each meter pulse (Payphone metering is a discussion for another day) until all the credit has been used / Balance is less than 1 meter pulse charge.

While anyone could ask the smart card “Hey SmartCard, how much credit do you have on you?” it would only return the balance, and if you told the smart card “I used $1 credit, please deduct it” like the payphone did, you’d just take a dollar off the credit stored on the card.

Saying “Hey SmartCard set the balance to $1,000,000” would result in a raised eyebrow from the SmartCard who rejects the request.

After all – It’s a smart card. It has the capability to do that.

So in the telecom sector single use smart cards were rolled out, programmed in the factory with a set dollar value of credit, sold at that dollar value and thrown away when depleted.

The banking industry saw even more potential, balance could be stored on the card, and the PIN could be verified by the card, the user needs to know the correct PIN, as does the smart card, but the terminal doesn’t need to know this, nor does it need to talk back to a central bank computer all the time, just every so often so the user gets the bill.

It worked much the same way, although before allowing a deduction to be made from the balance of the card, a user would have to enter their PIN which was verified by the card before allowing the transaction.

Eventually these worlds collided (sort of), both wanting much the same thing from smart cards. So the physical characteristics, interface specs (rough ones) and basic communications protocol was agreed on, and what eventually became ISO/IEC 7816 was settled upon.

Any card could be read by any terminal, and it was up to the systems implementer (banks and telecos initially) what data the card did and what the terminal did.

Active RFID entered the scene and there wasn’t even a need for a physical connection to the card, but the interaction was the same. We won’t really touch on the RFID side, but all of this goes for most active RFID cards too.

Enter Software

Now the card was a defined standard all that was important really was the software on the card. Banks installed bank card software on their cards, while telcos installed payphone card software on theirs.

But soon other uses emerged, ID cards could provide a verifiable and (reasonably) secure way to verify the card’s legitimacy, public transport systems could store commuter’s fares on the card, and vending machines, time card clocks & medical records could all jump on the bandwagon.

These were all just software built on the smart card platform.

Hello SIM Cards

A early version Smart card was used in the German C-Netz cellular network, which worked in “mobile” phones and also payphones, to authenticate subscribers.

After that the first SIM cards came into the public sphere in 1991 with GSM as a way to allow a subscriber’s subscription to be portable between devices, and this was standardised by ETSI to become the SIM cards still used in networks using GSM, and evolved into the USIM used in 3G/4G/5G networks.

Names of Smart Cards & Readers

To make life a bit easier I thought I’d collate all the names for smart cards and readers that are kind of different but used interchangeably depending on the context.

Smart Card|Terminal
UICC (Universal Integrated Circuit Card) – Standards name for Smart CardCard Reader (Generic)
SIM (Mobile Telco application running on UICC)Phone (Telco)
USIM (Mobile Telco application running on UICC)SIM Slot (Telco)
Credit / Debit / EFTPOS Card (Banking)UE (Telco)
Java Card (Type of Smart Card OS)EFTPOS Terminal (Banking)
Phone Card (Telco / Payphone)

And then…

From here we’ll look at various topics:

  • Introduction to Smart Cards (This post)
  • Meet & Greet (The basics of Smart Cards & their File System)
  • APDUs and Hello Card (How terminals interact with a smart cards)
  • (Interacting with real life cards using Smart Card readers and SIM cards)
  • Mixing It Up (Changing values on Cards)

Other topics we may cover are Javacard and Global Platform, creating your own smart card applications, a deeper look at the different Telco apps like SIM/USIM/ISIM, OTA Updates for cards / Remote File Management (RFM), and developing for SimToolkit.

GSM with Osmocom: OsmoSGSN for Packet Data

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.

Basic SGSN Config

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

Authentication

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

A Word on Compression & Encryption

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

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

The complete Setup

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

NanoVNA showing LCD contents

Using a NanoVNA to analyse SDR Base Station Antennas

A few months back I posted my secret shame regarding some rubber-ducky antennas I had been using thinking they were on the GSM bands, that turned out to have the wrong connector and had never made contact in all the years I’d used them.

I recently got my hands on a NanoVNAv2 and thought I’d take a look at the antennas I’d purchased for my GSM SDR experimentation,

These antennas claimed to operate on 900/1800/2100MHz and this time had the correct connector (SMA not RP-SMA)…

I ordered two of these antennas for the princely sum of $3 and hooked them onto the NanoVNA to analyse the antennas – the poor man’s Anritsu SiteMaster!

The buttons on the NanoVNA are a bit tough to use but there’s great software out there for driving the NanoVNA from your computer (NanoVNA-saver), which is what used in the end,

I was operating the GSM network using ARFCN 871 with the SDR which translates to 1782 MHz for Uplink and 1877 MHz for Downlink, so I plugged in the values into the VNA to take a look at how it performs in those ranges,

Performance is actually pretty on point,

On the Uplink frequency we’ve got a VSWR of 1.15 which is about as good as it gets,

And in the downlink we’ve got a VSWR of 1.221, still pretty good.

Performance on the remainder of the 1800MHz band is pretty decent, with clear drops in VSWR where the Uplink and Downlink channels lie.

I measured the full band for Uplink on the 1800Mhz band (1710Mhz – 1785Mhz):

Analysis of Uplink Bands

Which shows not all channels are created equal, if you were looking for real performance on these antennas and not just playing, you’d probably want to put your uplink channel on one of the frequencies shown by the marker,

And the full band for Downlink on the 1800Mhz band (1805Mhz – 1890Mhz):

Again, varied performance, but the peaks and troughs line up on the uplink and downlink, so a lower ARFCN in the 1800Mhz band would put you about on the red marker for both,

Comparing the output of each of the antennas I’ve got

In reality I could be using a bent coat hanger for an antenna, the signals shouldn’t be able to leave the room, but it’s a good excuse to use the toys!

Nokia 3310 connected to test GSM network running with Osmocom

Twenty years of the Nokia 3310

This year I started writing a series of blog posts about building GSM networks.

I already had a bunch of phones for testing available, but there’s only one phone I wanted for running the tests…

The Nokia 3310.

To my amazement, you can still buy refurbished Nokia 3310s (new case, battery and screen) for about $12 USD each.

So I bought one;

I learned that 1 September 2000 was when the 3310 was released, making it 20 years old this month. 20 years is also about the time between charges…

Happy Birthday 3310!

Android Carrier Privileges

So a problem had arisen, carriers wanted to change certain carrier related settings on devices (Specifically the Carrier Config Manager) in the Android ecosystem. The Android maintainers didn’t want to open the permissions to change these settings to everyone, only the carrier providing service to that device.

And if you purchased a phone from Carrier A, and moved to Carrier B, how do you manage the permissions for Carrier B’s app and then restrict Carrier A’s app?

Enter the Android UICC Carrier Privileges.

The carrier loads a certificate onto the SIM Cards, and signing Android Apps with this certificate, allowing the Android OS to verify the certificate on the card and the App are known to each other, and thus the carrier issuing the SIM card also issued the app, and presto, the permissions are granted to the app.

Carriers have full control of the UICC, so this mechanism provides a secure and flexible way to manage apps from the mobile network operator (MNO) hosted on generic app distribution channels (such as Google Play) while retaining special privileges on devices and without the need to sign apps with the per-device platform certificate or preinstall as a system app.

UICC Carrier Privileges doc

Once these permissions are granted your app is able to make API calls related to:

  • APN Settings
  • Roaming/nonroaming networks
  • Visual voicemail
  • SMS/MMS network settings
  • VoLTE/IMS configurations
  • OTA Updating SIM Cards
  • Sending PDUs to the card

Getting TEID up with GTP Tunnels

If you’re using an GSM / GPRS, UMTS, LTE or NR network, there’s a good chance all your data to and from the terminal is encapsulated in GTP.

GTP encapsulates user’s data into a GTP PDU / packet that can be redirected easily. This means as users of the network roam around from one part of the network to another, the destination IP of the GTP tunnel just needs to be updated, but the user’s IP address doesn’t change for the duration of their session as the user’s data is in the GTP payload.

One thing that’s a bit confusing is the TEID – Tunnel Endpoint Identifier.

Each tunnel has a sender TEID and transmitter TEID pair, as setup in the Create Session Request / Create Session Response, but in our GTP packet we only see one TEID.

There’s not much to a GTP-U header; at 8 bytes in all it’s pretty lightweight. Flags, message type and length are all pretty self explanatory. There’s an optional sequence number, the TEID value and the payload itself.

So the TEID identifies the tunnel, but it’s worth keeping in mind that the TEID only identifies a data flow from one Network Element to another, for example eNB to S-GW would have one TEID, while S-GW to P-GW would have another TEID.

Each tunnel has two TEIDs, a sending TEID and a receiving TEID. For some reason (Minimize overhead on backhaul maybe?) only the sender TEID is included in the GTP header;

This means a packet that’s coming from a mobile / UE will have one TEID, while a packet that’s going to the same mobile / UE will have a different TEID.

Mapping out TIEDs is typically done by looking at the Create Session Request / Responses, the Create Session Request will have one TIED, while the Create Session Response will have a different TIED, thus giving you your TIED pair.

GSM with Osmocom: Handovers

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.

Measurements

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.

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.

Everybody needs good Neighbors

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.

The Handover

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.

Screenshot of a packet capture showing a GSM Handover

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.

Simplified Diagram of the Process

There is a lot more to handovers than just this, which we’ll cover in a future post.

Osmocom Logo

GSM with Osmocom: Channel Types

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

Traffic channels break down into a further two categories, voice channels for carrying call audio, and data channels for carrying GPRS data.

Traffic Channels for Voice

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.

Traffic Channels for Data

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

Control channels carry the out of band signalling between the Phone and the BTS.

Broadcast Channels

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.

Common Channels

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.

Dedicated Control Channels

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,

GSM with Osmocom: Silent SMS & Silent Calls

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
Packet capture shows no traffic on the Abis interface until the Silent SMS is sent

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.

GSM with Osmocom: GPRS & Packet Data

So far we’ve focused on building a plain “2G” (voice and SMS only) network, which was all consumers expected twenty years ago.

As the number of users accessing the internet through DSL, Dial Up & ISDN grew, the idea of getting this data “on the go” became more appealing. TCP/IP was becoming the dominant standard for networking, the first 802.11 WiFi spec had recently been published and demand for mobile data was growing.

There’s a catch however – TCP/IP was never designed to be mobile.

An IP address exists in a single location.

(Disclaimer: While you can “move” a subnet by advertising itself out in a different location via BGP peering relationships with other operators, it’s cumbersome, can only be done per /24 or larger, and most importantly it’s painfully slow. IPv6 has MIPv6 which attempts to fix some of these points, but that’s outside of this scope.)

GPRS addressed the mobility issue by having a single fixed point the IP Address is assigned to (the Gateway GPRS Support Node), which encapsulates IP traffic to/from a mobile user into GTP Packet (GPRS Tunnelling Protocol), like GRE or any of the other common routing encapsulation protocols, allowing the traffic to be rerouted to different destinations as the users move from being served by one BTS to another BTS.

I’ve written about GTP here if you’d like to learn more.

So now we’ve got a method of encapsulating our data we’ve got to work out how to get that data out over the air.

BTS Time Slots

Way back when we were first setting up our BSC and adding our BTS(s) you will have configured timeslots for each BTS configured on your BSC.

Chances are if you’ve been following along with this tutorial, that you configured the first time slot (timeslot 0) as a CCCH+SDCCH4, meaning Common Control Channel and 4 standalone dedicated control channels, and all the subsequent timeslots (timeslot 1 – 7) as Traffic Channels (full rate) – TCH/F.

This works well if we’re only carrying voice, but to carry data we need timeslots to put the data traffic on.

For this we’ll re assign a timeslot we were using on our BSC as a voice traffic channel (TCH/F) as a PDCH – a Packet Data Channel.

This means that on the BSC your timeslot config will look something like this:

   timeslot 6
    phys_chan_config PDCH
    hopping enabled 0
   timeslot 7
    phys_chan_config PDCH
    hopping enabled 0

In the above example I’ve assigned two timeslots for Packet Data Channels,

The more timeslots you allocate for data, the more bandwidth available, but the fewer voice resources available.

(Most GSM networks today have few data timeslots as more recent RATs like 3G/4G are taking the data traffic, and GSM is used primarily for voice and low bandwidth M2M communications)

GPRS and EDGE

GPRS comes in two flavors, GPRS and EDGE.

GPRS (General Packet Radio Services) was the first of the two, standardised in R97, and allowed users to reach a downlink speeds of up to 171Kbps using GMSK on the air interface to encode the data.

Users quickly expected more speed, so EDGE (Enhanced Data rates for Global Evolution) was standardised, from a core perspective it was the same, but from a BTS / Air interface perspective it relied on 8PSK instead of GMSK allowed users to reach a blistering 384Kbps on the downlink.

These speeds are the theoretical maximums.

As the difference between GPRS and EDGE is encoding on the air interface, from a core perspective it’s treated the same way, however as our BTS gets all it’s brains from the BSC, we’ll need to specify if the BTS should use EDGE or GPRS it in the BSC’s BTS config.

BSC Config

On the BSC for each BTS we want to enable for packet data, we’ll need to define the parameters.

There’s two other values we’ll introduce when setting this up,

The first is NSEI – the Network Service Entity Identifier, which is the identifier of the BTS’s Packet Control Unit, like the cell identity.

The second value we’ll touch on is the BVCI – the BSSGP Virtual Connections Identifier, which is used for addressing between the BTS PCU and the SGSN.

bts 0
  gprs mode egprs
  gprs 11bit_rach_support_for_egprs 0
  gprs routing area 0
  gprs network-control-order nc0
  gprs cell bvci 2
  gprs cell timer blocking-timer 3
  gprs cell timer blocking-retries 3
  gprs cell timer unblocking-retries 3
  gprs cell timer reset-timer 3
  gprs cell timer reset-retries 3
  gprs cell timer suspend-timer 10
  gprs cell timer suspend-retries 3
  gprs cell timer resume-timer 10
  gprs cell timer resume-retries 3
  gprs cell timer capability-update-timer 10
  gprs cell timer capability-update-retries 3
  gprs nsei 101
  gprs ns timer tns-block 3
  gprs ns timer tns-block-retries 3
  gprs ns timer tns-reset 3
  gprs ns timer tns-reset-retries 3
  gprs ns timer tns-test 30
  gprs ns timer tns-alive 3
  gprs ns timer tns-alive-retries 10
  gprs nsvc 0 nsvci 101
  gprs nsvc 0 local udp port 23001
  gprs nsvc 0 remote udp port 23000
  gprs nsvc 0 remote ip 10.0.1.201

The OsmoBSC docs cover each of these values, they’re essentially defaults.

There are quite a few changes required on the BSC for each BTS we’re setting this up for. Instead of giving you info on what fields to change, here’s the diffs.

In the next post we’ll cover the GGSN and the SGSN and then getting a device on “the net”.

GSM with Osmocom: SS7 & Sigtran

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.

Point Codes – SS7 Addressing & Routing

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).

The Signalling Transfer Point

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”.

Sigtran & SS7 Over IP

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 Osmo STP

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

Packet Capture

Below is a packet capture showing a connection from an MSC to the STP.

GSM with Osmocom: NanoBTS

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,

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

Provisioning on the BSC

Finally I just had to provision the BTS on the BSC like any we did for our Virtual and SDR based BTS (Link for reference)

SMS over SGi interface on Open5GS MME and OsmoMSC

Sending SMS in Open5GS LTE Networks using the SGs Interface and OsmoMSC with SMSoS

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
Using the SGs interface for Circuit Switched Fallback (CSFB) Calls from LTE falling back to GSM

OsmoMSC and Open5GS MME – SGs Interface for InterRAT Handover & SMS

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).

How it Works:

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.

Setting it Up

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
        - ::1

Neighbours Configured

The 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.

Example Packet Capture

SIP INVITE from Osmo-SIP-Connector used for Mobile Network Call Control

GSM with Osmocom: Call routing in GSM

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.

There’s a good talk on how this works from OsmoDevCOn 2018 you can find here.

3GPP TS 23.284 version 15.0.0 Release 15 / ETSI TS 123 284 V15.0.0

Noka GSM phones on Osmocom

GSM with Osmocom Part 9: Calls & SMS at last!

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.

GSM MSC Architecture

GSM with Osmocom Part 8: The Mobile Switching Center

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:

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.

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.

OsmoHLR - Update Location Request

GSM with Osmocom Part 7: The HLR – Home Location Register (and Friends)

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.)

Authentication

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.

Side note about GSM Security

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.

LTE USIM Authentication - Mutual Authentication of the Network and Subscriber

Technically the generation of Authentication Vectors is handled by an Authentication Center (AuC) however OsomoHLR has an internal AuC that handles this internally.

Location Tracking

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.

Subscriber Data Information

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:

  • Subscriber’s IMSI
  • Subscriber’s MSISDN (Phone number)
  • Allowed Domains (CS/PS)

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.

Equipment Identity Register

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.

Starting & Configuring OsmoHLR

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

Adding Subscribers to OsmoHLR

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

Creating Subscribers Programmatically

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.

Creating Subscribers on Demand (Optional)

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.

Packet Capture

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.

GSM with Osmocom Part 6: Integrating our LimeSDR BTS with OsmoBSC

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

Configure Osmo-BTS-TRX

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

BSC Provisioning

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 

Starting the SDR based BTS

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.

Verifying Cell Operation

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.

GSM with Osmocom Part 5: Software BTS with LimeSDR & osmo-bts-trx

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.

Osmo-TRX

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.

The LimeSDR

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.

Software Install

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

Software Config

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.

Further Reading:

OsmoTRX – Osmocom Wiki

OsmoBTS – OsmocomWiki

LimeSDR – Osmocom Wiki