All posts by Nick

About Nick

Dialtone.

Kamailio Bytes – OnReply Route

So far with most of our discussions about Kamailio we’ve talked about routing the initial SIP request (INVITE, REGISTER, SUBSCRIBE, etc), but SIP is not a one-message protocol, there’s a whole series of SIP messages that go into a SIP Dialog.

Sure the call may start with an INVITE, but there’s the 180 RINGING, the 200 OK and the ACK that go into getting the call actually established, and routing these in-dialog messages is just as important as routing the first INVITE.

When we’ve talked about SIP routing it’s all happened in the request_route {} block:

request_route {
        xlog("Received $rm to $ru - Forwarding");
        append_hf("X-Proxied: You betcha\r\n");
        #Forward to new IP
        forward("192.168.1.110");
}

In the example above we statelessly forward any initial requests to the IP 192.168.1.110.

All the routing from that point on happens using the standard RFC3261 in-dialog routing using the Route headers.

We can add an onreply_route{} block to handle any replies from 192.168.1.110 back to the originator.

But why would we want to?

Some simple answers would be to do some kind of manipulation to the message – say to strip a Caller ID if CLIP is turned off, or to add a custom SIP header containing important information, etc.

onreply_route{
        xlog("Got a reply $rs");
        append_hf("X-Proxied: For the reply\r\n");
}

Let’s imagine a scenario where the destination our SIP proxy is relaying traffic to (192.168.1.110) starts responding with 404 error.

We could detect this in our onreply_route{} and do something about it.

onreply_route{
        xlog("Got a reply $rs");
        if($rs == 404) {
                #If remote destination returns 404
                xlog("Got a 404 for $rU");
                #Do something about it
        }
}

In the 404 example if we were using Dispatcher it’s got easily accessed logic to handle these scenarios a bit better than us writing it out here, but you get the idea.

There are a few other special routes like onreply_route{}, failure routes and event routes, etc.

Hopefully now you’ll have a better idea of how and when to use onreply_route{} in Kamailio.

Telecom Pillars – Resistance to Rifle Fire?

The 900 and 1800 pair telecom distribution pillars (aka cabinets) are still a familiar sight almost everywhere in Australia where copper networks are still used, however prior to the early 1970s they were only deployed in metropolitan areas, and apparently one of the concerns of deploying them in rural areas was that they’d be shot at.

June 1966 issue of the Telecommunications Journal of Australia (TJA) has an article titled “Aluminum Distribution Cabinets – Resistance to Rifle Fire” is below, click to get the image full size.

At the short range, the vandal is expected to have either sufficient common sense or hard earned experience to realise the danger of ricochet.

Enable GPS/GLONASS Sync on Huawei BTS3900

Our BTS is going to need an accurate clock source in order to run, so without access to crazy accurate Timing over Packet systems or TDM links to use as reference sources, I’ve opted to use the GPS/GLONASS receiver built into the LMPT card.

Add new GPS with ID 0 on LMPT in slot 7 of cabinet 1:

ADD GPS: GN=0, CN=1, SRN=7, CABLE_LEN=3, MODE=GPS/GLONASS;

Check GPS has sync (May take some time) using the Display GPS command;

DSP GPS: GN=0;

Assuming you’ve got an antenna connected and can see the sky, after ~10 minutes running the DSP GPS:; command again should show you an output like this:

+++    4-PAL0089624        2020-11-28 01:06:55
O&M    #806355684
%%DSP GPS: GN=0;%%
RETCODE = 0  Operation succeeded.

Display GPS State
-----------------
                 GPS Clock No.  =  0
                GPS Card State  =  Normal
                 GPS Card Type  =  M12M
                 GPS Work Mode  =  GPS
                   Hold Status  =  UNHOLDED
         GPS Satellites Traced  =  4
     GLONASS Satellites Traced  =  0
         BDS Satellites Traced  =  0
Antenna Longitude(1e-6 degree)  =  144599999
 Antenna Latitude(1e-6 degree)  =  -37000000
           Antenna Altitude(m)  =  613
         Antenna Angle(degree)  =  5
             Link Active State  =  Activated
              Feeder Delay(ns)  =  15
                   GPS Version  =  NULL
(Number of results = 1)


---    END

Showing the GPS has got sync and a location fix,

Next we set BTS to use GPS as time source,

SET TIMESRC: TIMESRC=GPS;

Finally we’ll verify the Time is in sync on the BTS using the list time command:

DSP TIME:;
+++    4-PAL0089624        2020-11-28 01:09:22
O&M    #806355690
%%DSP TIME:;%%
RETCODE = 0  Operation succeeded.

Time Information
----------------
Time  =  2020-11-28 01:09:22 GMT+00:00

---    END

Optionally you may wish to add a timezone, using the SET TZ:; command, but I’ve opted to keep it in UTC for simplicity.

SIM / Smart Card Deep Dive – Part 3 – APDUs and Hello Card

In our last post we covered the file system structure of a smart card and the basic concepts of communication with cards. In this post we’ll look at what happens on the application layer, and how to interact with a card.

For these examples I’ll be using SIM cards, because admit it, you’ve already got a pile sitting in a draw, and this is a telco blog after all. You won’t need the ADM keys for the cards, we’ll modify files we’ve got write access to by default.

Commands & Instructions

So to do anything useful with the card we need issue commands / instructions to the card, to tell it to do things. Instructions like select this file, read it’s contents, update the contents to something else, verify my PIN, authenticate to the network, etc.

The term Command and Instruction are used somewhat interchangeably in the spec, I realise that I’ve done the same here to make it just as confusing, but instruction means the name of the specific command to be called, and command typically means the APDU as a whole.

The “Generic Commands” section of 3GPP TS 31.101 specifies the common commands, so let’s take a look at one.

The creatively named SELECT command/instruction is used to select the file we want to work with. In the SELECT command we’ll include some parameters, like where to find the file, so some parameters are passed with the SELECT Instruction to limit the file selection to a specific area, etc, the length of the file identifier to come, and the identifier of the file.

The card responds with a Status Word, returned by the card, to indicate if it was successful. For example if we selected a file that existed and we had permission to select, we’d get back a status word indicating the card had successfully selected the file. Status Words are 2 byte responses that indicate if the instruction was successful, but also the card has data it wants to send to the terminal as a result of the instruction, how much data the terminal should expect.

So if we just run a SELECT command, telling the card to select a file, we’ll get back a successful response from the card with a data length. Next need to get that data from the card. As the card can’t initiate communication, the GET RESPONSE instruction is sent to the card to get the data from the card, along with the length of the data to be returned.

The GET RESPONSE instruction/command is answered by the card with an APDU containing the data the card has to send, and the last 2 bytes contain the Status Word indicating if it was successful or not.

APDUs

So having covered the physical and link layers, we now move onto the Application Layer – where the magic happens.

Smart card communications is strictly master-slave based when it comes to the application layer.

The terminal sends a command to the card, which in turn sends back a response. Command -> Response, Command -> Response, over and over.

These commands are contained inside APplication Data Units (APDUs).

So let’s break down a simple APDU as it appears on the wire, so to speak.

The first byte of our command APDU is taken up with a header called the class byte, abbreviated to CLA. This specifies class coding, secure messaging options and channel options.

In the next byte we specify the Instruction for the command, that’s the task / operation we want the card to perform, in the spec this is abbreviated to INS.

The next two bytes, called P1 & P2 (Parameter 1 & Parameter 2) specify the parameters of how the instruction is to be to be used.

Next comes Lc – Length of Command, which specifies the length of the command data to follow,

Data comes next, this is instruction data of the length specified in Lc.

Finally an optional Le – Length of expected response can be added to specify how long the response from the card should be.

Crafting APDUs

So let’s encode our own APDU to send to a card, for this example we’ll create the APDU to tell the card to select the Master File (MF) – akin to moving to the root directory on a *nix OS.

For this we’ll want a copy of ETSI TS 102 221 – the catchily named “Smart cards; UICC-Terminal interface; Physical and logical characteristics” which will guide in the specifics of how to format the command, because all the commands are encoded in hexadecimal format.

So here’s the coding for a SELECT command from section 11.1.1.1 “SELECT“,

For the CLA byte in our example we’ll indicate in our header that we’re using ISO 7816-4 encoding, with nothing fancy, which is denoted by the byte A0.

For the next but we’ve got INS (Instruction) which needs to be set to the hex value for SELECT, which is represented by the hex value A4, so our second byte will have that as it’s value.

The next byte is P1, which specifies “Selection Control”, the table in the specification outlines all the possible options, but we’ll use 00 as our value, meaning we’ll “Select DF, EF or MF by file id”.

The next byte P2 specifies more selection options, we’ll use “First or only occurrence” which is represented by 00.

The Lc byte defines the length of the data (file id) we’re going to give in the subsequent bytes, we’ve got a two byte File ID so we’ll specify 2 (represented by 02).

Finally we have the Data field, where we specify the file ID we want to select, for the example we’ll select the Master File (MF) which has the file ID ‘3F00‘, so that’s the hex value we’ll use.

So let’s break this down;

CodeMeaningValue
CLAClass bytes – Coding optionsA0 (ISO 7816-4 coding)
INSInstruction (Command) to be calledA4 (SELECT)
P1Parameter 1 – Selection Control (Limit search options)00 (Select by File ID)
P2Parameter 1 – More selection options00 (First occurrence)
LcLength of Data 02 (2 bytes of data to come)
DataFile ID of the file to Select3F00 (File ID of master file)

So that’s our APDU encoded, it’s final value will be A0 A4 00 00 02 3F00

So there we have it, a valid APDU to select the Master File.

In the next post we’ll put all this theory into practice and start interacting with a real life SIM cards using PySIM, and take a look at the APDUs with Wireshark.

SIM / Smart Card Deep Dive – Part 2 – Meet & Greet

Layer 1 – Pinout and Connections

Before we can get all excited about talking to cards, let’s look at how we interface with them on a physical level.

For “Classic” smart cards interface is through the fingernail sized contacts on the card.

As you’d expect there’s a VCC & Ground line for powering the card, a clock input pin for clocking it and a single I/O pin.

ISO/IEC 7816-3 defines the electrical interface and transmission protocols.

The pins on the terminal / card reader are arranged so that when inserting a card, the ground contact is the first contact made with the reader, this clever design consideration to protect the card and the reader from ESD damage.

Operating Voltages

When Smart Cards were selected for use in GSM for authenticating subscribers, all smart cards operated at 5v. However as mobile phones got smaller, the operating voltage range became more limited, the amount of space inside the handset became a premium and power efficiency became imperative. The 5v supply for the SIM became a difficult voltage to provide (needing to be buck-boosted) so lower 3v operation of the cards became a requirement, these cards are referred to as “Class B” cards. This has since been pushed even further to 1.8v for “Class C” cards.

If you found a SIM from 1990 it’s not going to operate in a 1.8v phone, but it’s not going to damage the phone or the card.

The same luckily goes in reverse, a card designed for 1.8v put into a phone from 1990 will work just fine at 5v.

This is thanks to the class flag in the ATR response, which we’ll cover later on.

Clocks

As we’re sharing one I/O pin for TX and RX, clocking is important for synchronising the card and the reader. But when smart cards were initially designed the clock pin on the card also served as the clock for the micro controller it contained, as stable oscillators weren’t available in such a tiny form factor. Modern cards implement their own clock, but the clock pin is still required for synchronising the communication.

I/O Pin

The I/O pin is used for TX & RX between the terminal/phone/card reader and the Smart Card / SIM card. Having only one pin means the communications is half duplex – with the Terminal then the card taking it in turns to transmit.

Reset Pin

Resets the card’s communications with the terminal.

Filesystem

So a single smart card can run multiple applications, the “SIM” is just an application, as is USIM, ISIM and any other applications on the card.

These applications are arranged on a quasi-filesystem, with 3 types of files which can be created, read updated or deleted. (If authorised by the card.)

Because the file system is very basic, and somewhat handled like a block of contiguous storage, you often can’t expand a file – when it is created the required number of bytes are allocated to it, and no more can be added, and if you add file A, B and C, and delete file B, the space of file B won’t be available to be used until file C is deleted.

This is why if you cast your mind back to when contacts were stored on your phone’s SIM card, you could only have a finite number of contacts – because that space on the card had been allocated for contacts, and additional space can no longer be allocated for extra contacts.

So let’s take a look at our 3 file types:

MF (Master File)

The MF is like the root directory in Linux, under it contains all the files on the card.

DF (Dedciated File)

An dedicated file (DF) is essentially a folder – they’re sometimes (incorrectly) referred to as Directory Files (which would be a better name).

They contain one or more Elementary Files (see below), and can contain other DFs as well.

Dedicated Files make organising the file system cleaner and easier. DFs group all the relevant EFs together. 3GPP defines a dedicated file for Phonebook entries (DFphonebook), MBMS functions (DFtv) and 5G functions (DF5gs).

We also have ADFs – Application Dedicated Files, for specific applications, for example ADFusim contains all the EFs and DFs for USIM functionality, while ADFgsm contains all the GSM SIM functionality.

The actual difference with an ADF is that it’s not sitting below the MF, but for the level of depth we’re going into it doesn’t matter.

DFs have a name – an Application Identifier (AID) used to address them, meaning we can select them by name.

EF (Elementary File)

Elementary files are what would actually be considered a file in Linux systems.

Like in a Linux file systems EFs can have permissions, some EFs can be read by anyone, others have access control restrictions in place to limit who & what can access the contents of an EF.

There are multiple types of Elementary Files; Linear, Cyclic, Purse, Transparent and SIM files, each with their own treatment by the OS and terminal.

Most of the EFs we’ll deal with will be Transparent, meaning they ##

ATR – Answer to Reset

So before we can go about working with all our files we’ll need a mechanism so the card, and the terminal, can exchange capabilities.

There’s an old saying that the best thing about standards is that there’s so many to choose, from and yes, we’ve got multiple variants/implementations of the smart card standard, and so the card and the terminal need to agree on a standard to use before we can do anything.

This is handled in a process called Answer to Reset (ATR).

When the card is powered up, it sends it’s first suggestion for a standard to communicate over, if the terminal doesn’t want to support that, it just sends a pulse down the reset line, the card resets and comes back with a new offer.

If the card offers a standard to communicate over that the terminal does like, and does support, the terminal will send the first command to the card via the I/O line, this tells the card the protocol preferences of the terminal, and the card responds with it’s protocol preferences. After that communications can start.

Basic Principles of Smart Cards Communications

So with a single I/O line to the card, it kind of goes without saying the communications with the card is half-duplex – The card and the terminal can’t both communicate at the same time.

Instead a master-slave relationship is setup, where the smart card is sent a command and sends back a response. Command messages have a clear ending so the card knows when it can send it’s response and away we go.

Like most protocols, smart card communications is layered.

At layer 1, we have the physical layer, defining the operating voltages, encoding, etc. This is standardised in ISO/IEC 7816-3.

Above that comes our layer 2 – our Link Layer. This is also specified in ISO/IEC 7816-3, and typically operates in one of two modes – T0 or T1, with the difference between the two being one is byte-oriented the other block-oriented. For telco applications T0 is typically used.

Our top layer (layer 7) is the application layer. We’ll cover the details of this in the next post, but it carries application data units to and from the card in the form of commands from the terminal, and responses from the card.

Coming up Next…

In the next post we’ll look into application layer communications with cards, the commands and the responses.

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.

I like big Butts and I cannot lie.

In other parts of the world it’s known as a telephone test set, lineman’s handset, test phone, etc, but to me it’s a butt / butt set / buttinski.

They’re essentially ruggedized, portable telephones, often with an ability to monitor a line without looping it / going off hook, and used by techs and lineys throughout phone networks everywhere.

I carry Fluke TS52 Pro in my toolbox, it’s got a built in voltmeter, waterproof, backlit display and lots of memory storage options.

It’s a really beautiful bit of kit, (only thing missing is a TDR which the next model up has) but I very rarely use it.

The butt set is in my mind the quintessential piece of test gear, and I’ve got a few from various time periods.

The Telecom Ruggabut was launched in 1994/1995 and was standard issue prior to privatization, and was designed in Australia for the Australian market,

As such it features some uniquely Australian features such as detection for 12kHz Subscriber Pulse Metering (used in Payphones), while the “TLB” Button is tone-loop-break, a 100ms pause in dialling,

Prior to the Ruggabutt there was the Versadial and Versadial Mk2. Lightweight, tough and with a handy RJ12 jack for testing subscriber handpieces, these were made in huge numbers, by PMG and then Telecom.

And as far back as my “collection” goes is the Australian Post Office (APO) Telephone Test Handset No. 4, which lives on the Step exchange in my office, and is a simple rotary dial plus speaker, mic, switch and Neon light to denote ringing.

Power cables feeding Ericsson RBS rack

Cell Broadcast in LTE

Recently I’ve been wrapping my head around Cell Broadcast in LTE, and thought I’d share my notes on 3GPP TS 38.413.

The interface between the MME and the Cell Broadcast Center (CBC) is the SBc interface, which as two types of “Elementary Procedures”:

  • Class 1 Procedures are of the request – response nature (Request followed by a Success or Failure response)
  • Class 2 Procedures do not get a response, and are informational one-way. (Acked by SCTP but not an additional SBc message).

SCTP is used as the transport layer, with the CBC establishing a point to point connection to the MME over SCTP (Unicast only) on port 29168 with SCTP Payload Protocol Identifier 24.

The SCTP associations between the MME and the CBC should normally remain up – meaning the SCTP association / transport connection is up all the time, and not just brought up when needed.

Elementary Procedures

Write-Replace Warning (Class 1 Procedure)

The purpose of Write-Replace Warning procedure is to start, overwrite the broadcasting of warning message, as defined in 3GPP TS 23.041 [14].

Write-Replace Warning procedure, initiated by WRITE-REPLACE WARNING REQUEST sent by the CBC to the MMEs contains the emergency message to be broadcast and the parameters such as TAC to broadcast to, severity level, etc.

A WRITE-REPLACE WARNING RESPONSE is sent back by the MME to the MME, if successful, along with information as to where it was sent out. CBC messages are unacknowledged by UEs, meaning it’s not possible to confirm if a UE has actually received the message.

The request includes the message identifier and serial number, list of TAIs, repetition period, number of broadcasts requested, warning type, and of course, the warning message contents.

Stop Warning Procedure (Class 1 Procedure)

Stop Warning Procedure, initiated by STOP WARNING REQUEST and answered with a STOP WARNING RESPONSE, requests the MME inform the eNodeBs to stop broadcasting the CBC in their SIBs.

Includes TAIs of cells this should apply to and the message identifier,

Error Indication (Class 2)

The ERROR INDICATION is used to indicate an error (duh). Contains a Cause and Criticality IEs and can be sent by the MME or CBC.

Write Replace Warning (Class 2)

The WRITE REPLACE WARNING INDICATION is used to indicate warning scenarios for some instead of a WRITE-REPLACE WARNING RESPONSE,

PWS Restart (Class 2)

The PWS RESTART INDICATION is used to list the eNodeBs / cells, that have become available or have restarted, since the CBC message and have no warning message data – for example eNodeBs that have just come back online during the period when all the other cells are sending Cell Broadcast messages.

Returns a the Restarted-Cell-List IE, containing the Global eNB ID IE and List of TAI, of the restarted / reconnected cells.

PWS Failure Indication (Class 2)

The PWS FAILURE INDICATION is essentially the reverse of PWS RESTART INDICATION, indicating which eNodeBs are no longer available. These cells may continue to send Cell Broadcast messages as the MME has essentially not been able to tell it to stop.

Contains a list of Failed cells (eNodeBs) with the Global-eNodeB-ID of each.

My 2021 Telco Reading List for the Holidays

Here’s the list of books I’ve got for the holiday period:

5G Core Networks: Powering Digitalization

A good technical overview of the 5GC architecture, covering the actual elements and their interfaces / reference points, without any talk of robotic surgery.

Clear Across Australia (A history of Telecommunications)

Ann Moyal

This one is an actual hardback book that came in the mail, not just delivered to my ebook reader!

It covers the history of telecommunications in Australia, right from Charles Todd’s Overland Telegraph Line, to the first talk of “Integrated Digital Network” (Later ISDN).

Sonet / SDH Demystified

Steven Shepard

An overview of SDH/PDH networks, for the somewhat beginner.

The Idea Factory

Jon Gertner

A history of Bell Labs and it’s many, many, many achievements.

Huawei BTS 3900 LMPT Basic Config

This post is one in a series documenting my adventures attempting to configure a used BTS 3900 to function as a eNB in my lab.

There are 5 network ports on the LMPT card:

  • 2x SFP cages – SFP 0 and SFP 1
  • 1x 10/100 Ethernet port – ETH – Used to access the Local Maintenance terminal
  • 2x Fe/Ge ports – Fe/Ge0 and Fe/Ge1

Configuring the Ethernet Ports

What took me a little while to realise is that SFP0 and Fe/Ge0 are paired, they’re really only one interface. This means you can only use one at a time – you can’t use SFP0 and Fe/Ge0 simultaneously- Same with SFP1 and Fe/Ge1.

Before we get started we’ll list the current interfaces:

DSP ETHPORT:;

Assuming the interfaces aren’t there, we’ll need to add the interfaces, in my case the LMPT card is in Chassis 1, Slot number 7.

ADD ETHPORT: SRN=1, SN=7, SBT=BASE_BOARD, PN=0, PA=AUTO, SPEED=AUTO, DUPLEX=AUTO, USERLABEL="SFP_Fe_Ge_0";
ADD ETHPORT: SRN=1, SN=7, SBT=BASE_BOARD, PN=1, PA=AUTO, SPEED=AUTO, DUPLEX=AUTO, USERLABEL="SFP_Fe_Ge_1";

And then we’ve got to add an IP to one of the interfaces, in the below example I’ve added 10.0.1.210/24 to port 0 (which can be either SFP0 or Fe/Ge0).

ADD DEVIP: SRN=1, SN=7, SBT=BASE_BOARD, PT=ETH, PN=0, IP="10.0.1.210", MASK="255.255.255.0", USERLABEL="SFP_Fe/Ge_0"; 

At this point I plugged into the Fe/Ge0 port into my switch, and from my laptop on the same 10.0.1.0/24 subnet, I was able to ping the eNodeB.

And now we can check the status of the port:

DSP ETHPORT: SRN=1, SN=7, SBT=BASE_BOARD, PN=0;
+++    4-PAL0089624        2020-11-28 00:19:13
O&M    #806355532
%%DSP ETHPORT: SRN=1, SN=7, SBT=BASE_BOARD;%%
RETCODE = 0  Operation succeeded.

DSP ETHPORT Result
------------------
                           Cabinet No.  =  0
                           Subrack No.  =  1
                              Slot No.  =  7
                         Subboard Type  =  Base Board
                              Port No.  =  0
                        Port Attribute  =  Copper
                           Port Status  =  Up
                 Physical Layer Status  =  Up
       Maximum Transmission Unit(byte)  =  1500
                             ARP Proxy  =  Enable
                          Flow Control  =  Open
                           MAC Address  =  DCD2-07FC-A9E8
                       Loopback Status  =  No Loop
               In Loopback Mode or Not  =  No
                 Ethernet OAM 3AH Flag  =  Disable
          Number of RX Packets(packet)  =  1682
              Number of RX Bytes(byte)  =  163929
Number of RX CRC Error Packets(packet)  =  2
                    RX Traffic(byte/s)  =  259
          Number of TX Packets(packet)  =  53
              Number of TX Bytes(byte)  =  13952
                    TX Traffic(byte/s)  =  0
  Local Configuration Negotiation Mode  =  Automatic Negotiation
         Local Actual Negotiation Mode  =  Automatic Negotiation
                           Local Speed  =  100M
                          Local Duplex  =  Full Duplex
          Peer Actual Negotiation Mode  =  Automatic Negotiation
                            Peer Speed  =  100M
                           Peer Duplex  =  Full Duplex
                         Number of IPs  =  1
                       IP Address List  =  10.0.1.210 255.255.255.0
(Number of results = 1)


---    END

On with the rest of the config,

Adding a default route:

ADD IPRT: RTIDX=0, SRN=1, SN=7, SBT=BASE_BOARD, DSTIP="0.0.0.0", DSTMASK="0.0.0.0", RTTYPE=NEXTHOP, NEXTHOP="10.0.1.1", MTUSWITCH=OFF, DESCRI="Default Route";

Setting a DNS Server:

ADD DNSSRV: DNSSRVID=0, IPVER=IPv4, DNSCIP4="10.0.1.210", DNSSIP4="1.1.1.1";

Ensure you can ping the DNS server & in my case the MME:

PING: SRN=1, SN=7, SRCIP="10.0.1.210", DSTIP="1.1.1.1", CONTPING=DISABLE, APPTIF=NO;
PING: SRN=1, SN=7, SRCIP="10.0.1.210", DSTIP="10.0.1.183", CONTPING=DISABLE, APPTIF=NO;

And with that, you’ve got the network side of the config done on the eNodeB.

At this stage you’re able to unplug from the ETH port you’ve got the WebLMT connection to, and just connect to it like any other network device.

There’s a few more steps before we bring cells on the air, we’ve got to set timing sources, configure a connection to an MME and S-GW, configure the Carrier settings and add the radios and sectors, but this will get you to the stage where you no longer need to plug directly into the eNB to configure it.

Huawei BTS3900 – MML Basics

How do humans talk to base stations? For Huawei at least the answer to this is through MML – Man-Machine-Language,

It’s command-response based, which is a throwback to my Nortel days (DMS100 anyone?),

So we’re not configuring everything through a series of parameters broken up into sections with config, it’s more statements to the BTS along the lines of “I want you to show me this”, or “Please add that” or “Remove this bit”,

The instruction starts of with an operation word, telling the BTS what we want to do, there’s a lot of them, but some common examples are; DSP (Display), LST (List), SET (Set), MOD (Modify) and ADD (Add).

After the operation word we’ve got the command word, to tell the BTS on what part we want to execute this command,

A nice simple example would be to list the software version that’s running on the BTS. For this we’d run

LST SOFTWARE:;

And press F9 to execute, which will return a list of software on the BTS and show it in the terminal.

Note at the end the :; – the : (colon) denotes the end of a command word, and after it comes the paratmeters for the command, and then the command ends with the ; (semi-colon). We’ll need to put this after every command.

Let’s look at one more example, and then we’ll roll up our sleves and get started.

Note: I’m trying out GIFs to share screen recordings instead of screenshots. Please let me know if you’re having issues with them.

So once you’ve logged into WebLMT, selecting MML is where we’ll do all our config, let’s log in and list the running applications.

So far we’ve only got some fairly basic data, listing and displaying values, so let’s try something a bit more complex, taking a backup of the config, in encrypted mode, with the backup label “blogexamplebackup”,

BKP CFGFILE: ENCRYPTMODE=UNENCRYPTED, BL="blogexamplebackup";

If you’ve made it this far there’s a good chance you’re thinking there’s no way you can remember all these commands and parameters – But I’ve got some good news, we don’t really need to remember anything, there’s a form for this!

And if we want to upload the backup file to an FTP server, we can do this as well, in the navigation tree we find Upload Backup Configuration, fill in the fields and click the Exec button to execute the command, or press F9.

These forms, combined with a healthy dose of the search tab, allow us to view and configure our BTS.

I’ve still got a lot to learn about getting end-to-end configuration in place, but this seems like a good place to start,

Connecting to a Huawei BTS3900

Meta: This post is a series chronicling my adventures with a second hand Huawei BTS3900 I purchased. You can find an index of these posts here.

So you purchased a used Macro base station online, good for you.

Now you need to know how to configure it.

First things first, you’ll need to connect to the MPT card – Main Processing & Transmission,

Chances are you’ll have a LMPT (LTE Main Processing & Transmission) or UMPT (Universal Main Processing & Transmission) card.

Set your Ethernet adaptor’s IP to 192.168.0.50/24,

If you’ve got a LMPT card you plug into the ETH port, and then browse to 192.168.0.49, to hit the WebLMT interface.

If you’ve got a UMPT card, you’d need to connect a USB-NIC to the USB port.

And presto, we can reach the WebLMT interface;

I’ve found Firefox on Linux works OK – some functions don’t work, but a VM running IE and Java 7 does the trick just fine.

DIY LTE RAN Adventure – POWER! (systems)

All the gear I’ve got so far for my DIY RAN Project requires -48vDC to power it up.

Back to online auction websites and preso I’ve ended up with an Eltek MPSU3000, from the mid 2000s.

The fellow I bought it from was even nice enough to throw a binder full of printed documentation, which included a full circuit layout diagram, however this was obviously in the days of old school printers, and each of the colours were offset, providing a literal headache when reading and a bit of a reminder of what printed documents were like to deal with…

I get a headache just looking at the colours in this…

So after a bit of tinkering, wiring and reconnecting the temperature probe, I managed to fire the unit up,

While it complained about the absence of batteries (As well as rectifying AC to DC it manages and maintains banks of batteries to provide a backup power supply), it worked, and provided a very stable, clean -54v DC.

I’ve got a very old (1948) Ring Generator / Ring Machine, (same as this one) so I wired it into the rectifier and it came to life, drawing 3 amps in the process.

The Huawei gear uses proprietary power connectors, I’ve managed to start it using crocodile clips and good luck to get it powered up, but I’ve got to work out a more permanent solution before I can rack all the gear and have it setup properly.

The Eltek rectifier has a number of relay contacts in the unit that can be programed to trigger in different conditions, ie mains power lost, battery fault, over temperature, etc.

These relay contacts are then wired into some sort of alarm input, to share alarm state with external monitoring equipment. (Modern rectifiers just have Ethernet and connect over TCP/IP, but this one just has a serial port and an AT command set for connecting it to a dialup modem.)

The BTS3900 has the Universal Power and Environment Unit (UPEU), which allows me to connect external alarm inputs, for things like this, water sensors, smoke detectors and intruder alarms, so hopefully I’ll get that in place when I’m further down the line.

But to program these requires the software, which I couldn’t find anywhere online. As a last ditch attempt I reached out to the manufacturer, Eltek, and asked if they’d be so kind as to send me a copy. I wasn’t expecting much, but the next day, they sent me back all the manuals and the software the next day, for a 15 year old, long surpassed product. Very impressed!

So with the aid of VMware, Windows XP, USB-Serial adapters and jumper wires, I managed to connect to the Rectifier Controller with the software and had a poke around.

While the unit can do some very clever things with battery management, for my lab setup I can’t see myself going to the effort of adding batteries. So for now the Rectifier’s just converting AC mains into -48vDC, but I may string some batteries in the future.

For anyone who’s ended up here looking for info on these units, or the first generation Eltek Flatpacks, I’ve attached some documentation below. The software isn’t readily available online, so I won’t post it here, but you can get it from Eltek directly.

So power system check! Now onto configuring the unit and getting the radios online…

5G Subscriber Identifiers – SUCI & SUPI

The SUPI (Subscription Permanent Identifier) replaces the IMSI as the unique identifier for each Subscriber in 5G.

One of the issues with using IMSI in LTE/EUTRAN is there were a few occasions where the IMSI was sent over the clear – meaning the IMSIs of subscribers nearby could be revealed to anyone listening.

So what is a SUPI and what does it look like? Well, most likely it’ll look like an IMSI – 15 or 16 digits long, with the MCC/MNC as the prefix.

If you’re using a non-3GPP RAT it could be a RFC 4282 Network Access Identifier, but if it’s on a SIM card or in a Mobile Device, it’s probably exactly the same as the IMSI.

SUCI Subscription Concealed Identifier

Our SUPI is never sent over the air in the clear / plaintext, instead we rely on the SUCI (Subscription Concealed Identifier) for this, which replaces the GUTI/TMSI/IMSI for all plaintext transactions over the air.

Either the UE or the SIM generate the SUCI (if it’s done by the SIM it’s much slower), based on a set of parameters defined on the SIM.

The SUCI has to be generated by the UE or SIM in a way the Network can identify the SUPI behind the SUCI, but no one else can.

In LTE/EUTRAN this was done by the network randomly assigning a value (T-MSI / GUTI) and the network keeping track of which randomly assigned value mapped to which user, but initial attach and certain handovers revealed the real IMSI in the clear, so for 5G this isn’t an option.

So let’s take a look at how SUCI is calculated in a way that only the network can reveal the SUPI belonging to a SUCI.

The Crypto behind SUCI Calculation

As we’ll see further down, SUCI is actually made up of several values concatenated together. The most complicated of these values is the Protection Scheme Output, the cryptographically generated part of the SUCI that can be used to determine the SUPI by the network.

Currently 3GPP defines 3 “Protection Scheme Profiles” for calculating the SUCI.

Protection Scheme Identifier 1 – null-scheme

Does nothing. Doesn’t conceal the SUPI at all. If this scheme is used then the Protection Scheme Output is going to just be the SUPI, for anyone to sniff off the air.

Protection Scheme Identifier 2 & 3 – ECIES scheme profile A & B

The other two Protection Scheme Identifiers both rely on Elliptic Curve Integrated Encryption Scheme (ECIES) for generation.

This is better known as Elliptic Curve Encryption Scheme, it’s primarily used for Cryptography. Crypto is crazy complex, and I’m a mere mathematical mortal, but there’s a great post on the Cloudflare blog on the topic that touches on Elliptic Curve Encryption.

So if both Profile A & Profile B rely on Elliptic Curve Integrated Encryption Scheme, then what’s the difference between the two?

Well dear reader, the answer is semantics! There’s lots of parameters and variables that go into generating a resulting value from a cryptographic function, and Profile A & Profile B are just different parameters being used to generate the results.

For crypto nerds you can find the specifics in C.3.4.1 Profile A and C.3.4.1 Profile B outlined in 3GPP TS 33.501.

For non crypto nerds we just need to know this;

When the SIM is generating the SUCI the UE just asks for an identity by executing the GET IDENTITY command ADF against the SIM and uses the response as the SUCI.

When the UE is generating the SUCI, the UE gets the SUCI_Calc_Info EF contents from the SIM and extracts the Home Network Public Key from it’s reply. It uses this Home Network Public Key and a freshly created ephemeral public/private key pair to generate a SUCI value to use.

Creating the SUCI

After generating a Protection Scheme Output, we’ll need to add some extra info into it to make it useful.

The first digit of the SUCI is the SUPI type, a value of 0 denotes the value contained in the Protection Scheme Output is an IMSI, while 1 is used for Network Access Indicator for Non 3GPP access.

Next up we have the Home Network Identifier, which in a mobile environment is our PLMN (MCC/MCC).

Then a Routing Indicator, 1-4 digits long, is used with the Home Network Identifier to route the Authentication traffic to the UDM that contains that subscriber’s information, ie you may have MVNOs with their own UDM. If the routing indicator of 10 is assigned to the MVNOs SIMs then the AMF can be set to route traffic with a routing indicator of 10 to the UDM of the VMNO.

The Protection Scheme we covered earlier, with the 3 types of protection scheme (Null & two relying on Elliptic Curve Integrated Encryption Scheme).

Home Network Public Key Identifier identifies which Public Key was used to generate the Protection Scheme Output.

Finally we have the Protection Scheme Output which we covered generating in the previous session.

Usage in Signaling

The SUPI is actually rarely used beyond the initial attach to the network.

After authenticating to the network using AKA and the SUCI, in 5GC, like in LTE/EUTRAN, a shorter GUTI is used which further protects the subscriber’s identity and changes frequently.

Indoor LTE/GSM/UMTS mobile antennas, primarily used for in building coverage.

DIY RAN Adventures – Antennas

Note: This is one part of a series of posts where I cover my adventures attempting to bring on air a commercial Macro cell site for my lab, with scrounged components.

So the Huawei BTS3900 unit I’ve ended up with, is only one part of the overall picture for building a working LTE RAN. Power systems, feeders, connectors, CPRI, antennas, baseband processing and transmission are all hurdles I’ve still got to overcome. So today, let’s talk about antennas!

For the output/TX side (downlink) of the RF Unit, I’ve ordered some 25w 50 ohm dummy loads (I’ll still need to work out how to turn down the RF power to less than 25w on the RF units). Even with the dummy load, a tiny bit of RF power is leaked, which should be enough to provide the downlink signal for my UEs – Time will tell if this works…

This option is fine for the power being pushed out of the RF unit, into the dummy load, where we have a lot of power available (too much power), but what about our very weak uplink signals from UEs?

For this I’d need some decent antennas to pickup the signals from the UEs, so I ended up with some Kathrein (Now owned by Ericsson) indoor multi-band omni antennas I found on an online auction site for $10 each. (I bought 4 so I can play with MIMO.)

Unfortunately, the RFUs I have are Band 28 (roughly 700Mhz-750Mhz uplink and 758Mhz to 798Mhz downlink), and reading the datasheet it seems this doesn’t cover the bands I need;

But beggars can’t be choosers, so I ran a calibration on the NanoVNA and swept the antenna from 700Mhz-750Mhz (Band 28 uplink frequencies) to see how it will perform when I get the rest of the solution together;

At the upper end of Band 28 Uplink (748Mhz) I’m getting a fairly respectable VSWR of 1.6 (Return Loss of -12.4dB), so I should be able to get away with these for what I’m doing,

I’v seen these white domes inside shopping centers and office buildings, so I was keen to crack open the case and see what magic inside, what I found was kind of underwhelming, just an aluminum plate with an aluminum reflector cone…

My ideas of putting the parts into the lathe and trying to lower it’s operating frequency by taking material off, were dashed when I realised taking material off would raise the operating frequency, not lower it…

IDEALte SIM Shim Unlock Card

SIM Unlock Shims

There’s a lot of “Magic Unlock SIM” products online; IdeaLTE, U-SIM LTE 4G Pro II (sic), UltraSIM, TurboSIM etc, with no real description as to what they are or how they work,

They claim to do something to do with unlocking iPhones, but with little other info.

Being interested in SIM technology, and with no real idea what they are I ordered a few.

What are they?

They’re man-in-the-middle SIM card devices that are able to intercept requests from the UE / baseband of the device.

They sit on top of the real SIM card, between it and the SIM Slot.

One of the ones I bought had a sticker on it that helped stick it into place, the other just sat above the SIM below the phone.

This means when the UE sends the APDU to request some data from the card, the SIM-shim device analyses the request, and if it matches the rules on the SIM-Shim, intercepts it and responds with something else, ignoring the data the real SIM card would send back and injecting its own,

The use for this seems to be to do with how Apple does Carrier Locking on the iPhone. It seems in the iPhone carrier settings are ranges of ICCIDs used by the different carriers for their SIMs, and uses that to identify the carrier of the SIM.

With this information it’s able to determine if the SIM card is from the carrier the iPhone is locked to or not,

Now you’re probably seeing the value in this attack – By intercepting the request for the ICCID of the card, and instead of responding with the real ICCID, the SIM-Shim intercepts the request and sending back an ICCID of a card the iPhone is carrier locked to, the iPhone is tricked into thinking it’s talking to a card from the carrier the phone is locked to.

So let’s say we’ve got an iPhone from Carrier A, and they’ve told Apple their SIM cards have ICCIDs in the range from 0001 to 0005,
If I put a SIM card with the ICCID 0003 the iPhone knows it’s a SIM from Carrier A,
If I put in a SIM card with ICCID 9999 the iPhone knows the SIM is not from carrier A, and therefore prevents me from using the iPhone,
But if I put in one of these SIM Shims, when the iPhone ask the ICCID of the card, the SIM Shim will respond with an ICCID we set on it, so if we want to use SIM with ICCID 9999 in a phone locked to Carrier A, all we’ve got to do is setup the SIM-Shim to respond with ICCID of 0001 for example.

Phew. Ok, that’s the short run down on how it works (There’s more to activating iPhones but we’re here to talk about SIMs!).

The Hardware

So physically these are “shims” – they sit between the real SIM and the mobile phone and intercept the communications.

It blows my mind that someone’s been able to manufacture these in such a small form factor.

But there is one rather glaring flaw in having a tiny wafer that sits on top of your regular SIM, and that is if it pops up/down/ get loose and become hellish to get out.

I found their insertion and removal is a bit of a game of Russian roulette as to if it will go in, or come out, without brute force and potential damage to the device.

In the end on one iPhone I had to force the SIM tray out with a set of needle nose pliers, and my little SIM-shim was pretty beaten up and no longer useable. RIP SIM-Shim 1.

I think this may have been an early version of the same thing? Or possibly to allow dual SIM on an iPhone?

The Software

Interacting with the IdealLTE for example, is via SIM Toolkit Application for managing ICCIDs.

You can set any ICCID you want, which is cool, but limited.

Unfortunately I haven’t been able to find any way of messing with these to allow interception / replacement for other APDUs, for example if you could change the Administrative Domain to get higher access to the network.

I will at some stage put these into a SIMtrace and compare the output, and have a poke around and see if I can find anyway to change / update these, or if there’s any APDUs it responds interestingly to.

Unfortunately I’ve actually lost the new unit I had to replace the one I broke, they are very very small…

I reached out to the developer / vendor but they seem to go dark and popup under a different name, I’m not holding my breath…

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

My first 5G Core: Open5Gs and UERANSIM

Note: As this space develops so quickly I’ve refreshed the original post from November 2021 in March 2021 with updated instructions.

While 5G SA devices are still in their early stages, and 5G RAN hardware / gNodeBs are hard to come by, so today we’ll cover using UERANSIM to simulate UEs and 5G RAN, to put test calls through our 5GC.

Bringing your 5G Core Online

We’ll use Open5Gs for all the 5GC components, and install on any recent Ubuntu distribution.

Installation is nice and easy;

$ sudo apt update 
$ sudo apt install software-properties-common 
$ sudo add-apt-repository ppa:open5gs/latest 
$ sudo apt update 
$ sudo apt install open5gs

The first point of contact we’ll need to talk about is the AMF,

The AMF – the Access and Mobility Function is reached by the gNodeB over the N2 interface. The AMF handles our 5G NAS messaging, which is the messaging used by the UEs / Devices to request data services, manage handovers between gNodeBs when moving around the network, and authenticate to the network.

By default the AMF binds to a loopback IP, which is fine if everything is running on the same box, but becomes an issue for real gNodeBs or if we’re running UERANSIM on a different machine.

This means we’ll need to configure our AMF to bind to the IP of the machine it’s running on, by configuring the AMF in /etc/open5gs/amf.yaml, so we’ll change the ngap addr to bind the AMF to the machine’s IP, for me this is 10.0.1.207,

ngap:
  - addr: 10.0.1.207

In the amf.conf there’s a number of things we can change and configure; such as the PLMN and network name, the NRF parameters, however for now we’ll keep it simple and leave everything else as default.

To allow the changes to take effect, we’ll restart the Open5GS AMF service to make our changes take effect;

$ sudo systemcl restart open5gs-amfd

Setting up the Simulator

We’re using UERANSIM as our UE & RAN Simulator, so we’ll need to get it installed. I’m doing this on an Ubuntu system as we’re using Snaps.

$ sudo apt update 
$ sudo apt upgrade 
$ sudo apt install make g++ libsctp-dev lksctp-tools 
$ iproute2 sudo snap install cmake --classic

With all the prerequisites installed we’ll clone the Git repository and make everything from source;

We’ll clone the Github repository, move into it and make from source.

$ git clone https://github.com/aligungr/UERANSIM
$ cd UERANSIM
$ make

Now we wait for everything to compile,

XKCD – Compiling

Once we’ve got the software installed we’ll need to put together the basic settings.

You should see these files in the /build/ directory and they should be executable.

Running the Simulator (UERANSIM)

UERANSIM has two key parts, like any RAN,

The first is the gNodeB, that connects to our AMF and handles subscriber traffic over our (simulated) radio link,

The other is our subscribers themselves – the UEs.

Both are defined and setup through config files in the config/ directory,

Configuring & Starting the gNodeB

While we’re not actually going to bring anything “on air” in the RF sense, we’ll still need to configure and start our gNodeB.

All the parameters for our gNodeB are set in the config/open5gs-gnb.yaml file,

Inside here we’ll need to set the the parameters of our simulated gNodeB, for us this means (unless you’ve changed the PLMN etc) just changing the Link IPs that the gNodeB binds to, and the IP of the AMFs (for me it’s 10.0.1.207) – you’ll need to substitute these IPs with your own of course.

Now we should be able to start the gNodeB service and see the connection, let’s take a look,

We’ll start the gNodeB service from the UERANSIM directory by running the nr-gnb service with the config file we just configured in config/open5gs-gnb.yaml

$ build/nr-gnb -c config/open5gs-gnb.yaml

All going well you’ll see something like:

[2021-03-08 12:33:46.433] [ngap] [info] NG Setup procedure is successful

And if you’re running Wireshark you should see the NG-AP (N2) traffic as well;

If we tail the logs on the Open5GS AMF we should also see the connection too:

Configuring the UE Simulator

So with our gNodeB “On the air” next up we’ll connect a simulated UE to our simulated gNodeB.

We’ll leave the nr-gnb service running and open up a new terminal to start the UE with:

$ build/nr-gnb -c config/open5gs-gnb.yaml

But if you run it now, you’ll just see errors regarding the PLMN search failing,

So why is this? We need to tell our UE the IP of the gNodeB (In reality the UE would scan the bands to find a gNB to serve it, but we’re simulating hre).

So let’s correct this by updating the config file to point to the IP of our gNodeB, and trying again,

So better but not working, we see the RRC was released with error “FIVEG_SERVICES_NOT_ALLOWED”, so why is this?

A quick look at the logs on Open5Gs provides the answer,

Of course, we haven’t configured the subscriber in Open5Gs’s UDM/UDR.

So we’ll browse to the web interface for Open5GS HSS/UDR and add a subscriber,

We’ll enter the IMSI, K key and OP key (make sure you’ve selected OPc and not OP), and save. You may notice the values match the defaults in the Open5GS Web UI, just without the spaces.

Running the UE Simulator

So now we’ve got all this configured we can run the UE simulator again, this time as Sudo, and we should get a very different ouput;

$ build/nr-gnb -c config/open5gs-gnb.yaml

Now when we run it we should see the session come up, and a new NIC is present on the machine, uesimtun0,

We can now run commands like Ping and Curl and by specifying our special uesimtun0 interface, and the traffic will be encapsulated in GTP and pop out the other end.

Supporting UERANSIM

More advanced functionality is in the works though, so keep an eye on the UERANSIM GitHub page and contribute code if you can, and consider supporting them on Patreon if you can’t, they’re doing great work.

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!