Category Archives: Mobile Networks

GSM with Osmocom: OsmoSGSN for Packet Data

GSM, Mobile Networks, , , , ,

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

5G SA, Mobile Networks, , ,

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

GSM, Mobile Networks, RF, ,

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!

Open5GS – NRF Setup

5G SA, Mobile Networks,

We covered NRFs last week, but I thought I’d cover actually configuring the NRF on Open5GS,

We’ll first off need to install the NRF,

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

Next up we’ll need to configure the NRF on the domain “nrf.5gc.mnc001.mcc001.3gppnetwork.org”, for this we’ll edit /etc/open5gs/nrf.conf and set the binding IP.

nrf:
  sbi:
    - addr:
       - 10.0.1.252
      port: 7777

Now for each Network Element we’re bringing online we’ll need to point it at our NRF’s address (or IP).

nrf:
  sbi:
    - addr:
       - nrf.5gc.mnc001.mcc001.3gppnetwork.org
      port: 7777

But there’s another very similar section inside the definition file, but this defines which IP the NRF client will listen on,

And that’s it,

From the log in /var/log/open5gs/nrf.log you see connections coming in,

5GC: The Network Function Repository Function

5G SA, Mobile Networks, RFCs & Standards, , , ,

The Problem

Mobile networks are designed to be redundant and resilient, with N+1 for everything.

Every network element connects to multiple other network elements.

The idea being the network is architected so a failure of any one network element will not impact service.

To take an LTE/EPC example, your eNodeBs connect to multiple MMEs, which in turn connect to multiple HSSs, multiple S-GWs, multiple EIRs, etc.
The problem is when each eNodeB connects to 3 MMEs, and you want to add a 4th MME, you have to go and reconfigure all the eNodeBs to point to the new MME, and all the HSSs to accept that MME as a new Diameter Peer, for example.

The more redundant you make the network, the harder it becomes to change.

This led to development of network elements like Diameter Routing Agents (DRAs) and DNS SRV for service discovery, but ultimately adding and removing network elements in previous generations of mobile core, involved changing a lot of config on a lot of different boxes.

The Solution

The NRF – Network Repository Function serves as a central repository for Network Functions (NFs) on the network.

In practice this means when you bring a new Network Function / Network Element online, you only need to point it at the NRF, which will tell it about other Network Functions on the network, register the new Network Function and let every other interested Network Function know about the new guy.

Take for example adding a new AMF to the network, after bringing it online the only bit of information the AMF really needs to start placing itself in the network, is the details of the NRF, so it can find everything it needs to know.

Our new AMF will register itself to the NRF, advertising what Network Functions it can offer (ie AMF service), and it’ll in turn be able to learn about what Network Functions it can consume – for example our AMF would need to know about the UDMs it can query data from.

It is one of the really cool design patterns usually seen in modern software, that 3GPP have adopted as part of the 5GC.

In Practice

Let’s go into a bit more detail and look at how it looks.

The NRF uses HTTP and JSON to communicate (anything not using ASN.1 is a winner), and looks familiar to anyone used to dealing with RESTful APIs.

Let’s take a look at how an AMF looks when registering to a NRF,

NF Register – Providing the NRF a profile for each NF

In order for the NRF to function it has to know about the presence of all the Network Functions on the network, and what they support. So when a new Network Function comes online, it’s got to introduce itself to the NRF.

It does this by providing a “Profile” containing information about the Network Functions it supports, IP Addresses, versions, etc.

Going back to our AMF example, the AMF sends a HTTP PUT request to our NRF, with a JSON payload describing the functions and capabilities of the AMF, so other Network Functions will be able to find it.

Let’s take a look at what’s in the JSON payload used for the NF Profile.

  • Each Network Function is identified by a UUID – nfInstanceId, in this example it’s value is “f2b2a934-1b06-41eb-8b8b-cb1a09f099af”
  • The nfType (Network Function type) is an AMF, and it’s IP Address is 10.0.1.7
  • The heartBeatTimer sets how often the network function (in this case AMF) sends messages to the NRF to indicate it’s still alive. This prevents a device registering to an NRF and then going offline, and the NRF not knowing.

The nfServices key contains an array of services and details of those services, in the below example the key feature is the serviceName which is namf-comm which means the Namf_Communication Service offered by the AMF.

The NRF files this info away for anyone who requests it (more on that later) and in response to this our NRF will indicate (hopefully) that it’s successfully created the entry in its internal database of Network Functions for our AMF, resulting in a HTTP 201 “Created” response back from the NRF to the AMF.

NRF StatusSubscribe – Subscribe & Notify

Simply telling the NRF about the presence of NFs is one thing, but it’s not much use if nothing is done with that data.

A Network Function can subscribe to the NRF to get updates when certain types of NFs enter/leave the network.

Subscribing is done by sending a HTTP POST with a JSON payload indicating which NFs we’re interested in.

Contents of a Subscription message to be notified of all AMFs joining the network

Whenever a Network Function registers on the NRF that related to the type that has been subscribed to, a HTTP POST is sent to each subscriber to let them know.

For example when a UDM registers to the network, our AMF gets a Notification with information about the UDM that’s just joined.

NRF Update – Updating NRF Profiles & Heartbeat

If our AMF wants to update its profile in the NRF – for example a new IP is added to our AMF, a HTTP PATCH request is sent with a JSON payload with the updated details, to the NRF.

The same mechanism is used as the Heartbeat / keepalive mechanism, to indicate the NRF is still there and working.

Summary

The NRF acts as a central repository used for discovery of neighboring network functions.

Huawei BBU (Baseband Unit) for LTE/UMTS/GSM also known as the BTS 3900 / BBU 3900

My used Huawei BTS3900 LTE RAN Adventure – The Impulse Purchase

EUTRAN, LTE, Mobile Networks, , , , , ,

Meta: The Australian government made up it’s mind some time ago that Huawei would be blacklisted from providing equipment for 5G networks.
Several other countries have adopted the same policy in regards, and as such, deployed Huawei tech is being replaced, and some of it filters down to online auction sites…

So I kind of purchased an item described as “Huawei BBU3900” with a handful of unknown cards and 2 LRFU units, for just over $100.

My current lab setup is a single commercial picocell and a draw of SDR hardware that works with mixed results, so the idea of having a commercial macro cell to play with seemed like a great idea, I put lowball offer in and the seller accepted.

Now would be a good time to point out I don’t know much about RAN and it’s been a long time since I’ve been working on power systems, so this is shaping up to be a fun project.

  • Huawei BBU3900
    Photo from the listing
  • Photo from the listing

I did a Huawei RAN course years ago and remembered the rough ingredients required for LTE:

  1. You needed either RRUs (Remote Radio Units) or RFUs (Radio Frequency Units) to handle the RF side of things.
    RRUs are designed for outdoor use (such as mounting on the tower) and RFUs are designed for indoor use, like mounting in a cabinet.
    I’ve ended up with two LRFUe units, which I can join together for 2x MIMO, operate on Band 28 and can put out a whopping 80W of transmit power, yes I’m going to need some big attenuators…
  2. You need a Baseband Processor card to tell the Radio units what do do.
    The card connects the CPRIs (Typically optic fiber links) between the radio units and the baseband.
    The chassis I purchased came with a stack of WBBP (For WCDMA) cards and a single LBBP card for LTE. The LBBP card has 6 SFP ports for the CPRI interfaces, which is more than enough for my little lab. (You can also daisy-chain CPRIs so I’m not even limited to 6 Radio Units.)
  3. You need a backplane and a place for the cards to live – this is the BBU3900 chassis. It’s got basic switching to allow communication between cards, a chassis to distribute power and cooling.
    (Unlike the Ericson units there is actually a backplane for communications in the Huawei chassis – the Ericsson RBS series has is just power and cooling in the chassis)
  4. Optional – Dedicated transmission card, I’ve ended up with a Universal Transmission Processor (UTRP9) with 2x Gig Ethernet and 2x Fast Ethernet ports for transmission. This will only work for GSM and UMTS though, not LTE, so not much use for me.
  5. You need something to handle main processing (LTE / Universal Main Processing and Transmission Unit (LMPT / UMPT)).
    Unfortunately the unit I’ve ended up with only came with a WMPT (For WCDMA), so back online to find either an LMPT (LTE) or UMPT (Universal (2G/3G/4G))…
  6. You need a Universal Power and Environment Module (UPEU) to power up the chassis and handle external IO for things like temperature alarms, door sensors and fire detectors. This chassis has two for redundancy / extra IO & extra power capacity.

So in order to get this running I still need quite a few components:

  • Attenuators – I’ll be able to turn the power down, sure, but not to the levels required to be legal.
  • Antennas – These are FDD units, so I’ll need two antennas for each RFU, on Band 28
  • Feeder Cables – To connect the antennas
  • SMF cables and SFPs – I’ve got a pile in my toolbox, but I’ll need to work out what’s supported by these units
  • A big -48vDC rectifier (I got the BBU3900 unit powered up with an existing supply I had, but I’m going to need something bigger for the power hungry RFUs)
  • DC Distribution Unit – Something to split the DC between the RFUs and the BBU, and protect against overload / short
  • USB-Network adapter – For OAM access to the unit – Found these cheaply online and got one on the way
  • The LTE Main Processing & Transmission (LMPT) card – Ordered a second hand one from another seller

I powered up the BTA3900 and sniffed the traffic, and can see it trying to reach an RNC.

Unfortunately with no open source RNC options I won’t be posting much on the topic of UMTS or getting the UMTS/WCDMA side of things on the air anytime soon…

So that’s the start of the adventure.

I don’t know if I’ll get this all working, but I’m learning a lot in the process, and that’s all that really matters…

Note: I think this is the course I did from Huawei on the BBU3900…

5GC for EPC Folks – Control Plane Signalling

5G SA, EPC, Mobile Networks, RFCs & Standards, , , , ,

As the standardisation for 5G-SA has been completed and the first roll outs are happening, I thought I’d cover the basic architecture of the 5G Core Network, for people with a background in EPC/SAE networks for 4G/LTE, covering the key differences, what’s the same and what’s new.

The AMF – Authentication & Mobility Function, serves much the same role as the MME in LTE/EPC/SAE networks.

Like the MME, the AMF only handles Control Plane traffic, and serves as the gatekeeper to the services on the network, connecting the RAN to the core, authenticating subscribers and starting data / PDN connections for the UEs.

While the MME connects to eNodeBs for RAN connectivity, the AMF connects to gNodeBs for RAN.

The Authentication Functions

In EPC the HSS had two functions; it was a database of all subscribers’ profile information and also the authentication centre for generating authentication vectors.

5GC splits this back into two network elements (Akin to the AuC and HLR in 2G/3G).

The UDM (Unified Data Management) provides the AMF with the subscriber profile information (allowed / barred services / networks, etc),

The AUSF (Authentication Server Function) provides the AMF with the authentication vectors for authenticating subscribers.

Like in UMTS/LTE USIMs are used to authenticate subscribers when connecting to the network, again using AKA (Authentication and Key Agreement) for mutual subscriber & network authentication.

Other authentication methods may be implemented, R16 defines 3 suporrted methods, 5G-AKA, EAP-AKA’, and EAP-TLS.

This opens the door for the 5GC to be used for non-mobile usage. There has been early talk of using the 5G architecture for fixed line connectivity as well as mobile, hence supporting a variety of authentication methods beyond classic AKA & USIMs. (For more info about Non-3GPP Access interworking look into the N3IWF)

The Mobility Functions

When a user connects to the network the AMF selects a SMF (Session Management Function) akin to a P-GW-C in EPC CUPS architecture and requests the SMF setup a connection for the UE.

This is similar to the S11 interface in EPC, however there is no S-GW used in 5GC, so would be more like if S11 were instead sent to the P-GW-C.

The SMF selects a UPF (Akin to the P-GW-C selecting a P-GW-U in EPC), which will handle this user’s traffic, as the UPF bridges external data networks (DNs) to the gNodeB serving the UE.

More info on how the UPF functions compared to it’s EPC counterparts can be found in this post.

Moving between cells / gNodeBs is handled in much the same way as done previously, with the path the UPF sends traffic to (N3 interface) updated to point to the IP of the new gNodeB.

Mobility between EPC & 5GC is covered in this post.

Connection Overview

When a UE attempts to connect to the network their signalling traffic (Using the N1 reference point between the UE and the AMF), is sent to the AMF.

an authentication challenge is issued as in previous generations.

Upon successful authentication the AMF signals the SMF to setup a session for the UE. The SMF selects a UPF to handle the user plane forwarding to the gNodeB serving the UE.

Key Differences

  • Functions handled by the MME in EPC now handled by AMF in 5GC
  • Functions of HSS now in two Network Functions – The UDM (Unified Data Management) and AUSF (Authentication Server Function)
  • Setting up data connections “flatter” (more info on the User Plane differences can be found here)
  • Non 3GPP access (Potentially used for fixed-line / non mobile networks)

See also: 5GC for EPC Folks – User Plane Traffic

5GC for EPC Folks – User Plane Traffic

5G SA, EPC, Mobile Networks, RFCs & Standards, , , , ,

As the standardisation for 5G-SA has been completed and the first roll outs are happening, I thought I’d cover the basic architecture of the 5G Core Network, for people with a background in EPC/SAE networks for 4G/LTE, covering the key differences, what’s the same and what’s new.

This posts focuses on the User Plane side of things, there’s a similar post I’ve written here on the Control Plane side of things.

UPF – User Plane Forwarding

The UPF bridges the external networks (DNs) to the gNodeB serving the UE by encapsulating the traffic into GTP, which has been used in every network since GSM.

Like the P-GW the UPF takes traffic destined to/from external networks and passes it to/from subscribers.

In 5GC these external networks are now referred to as “DN” – Data Networks, instead of by the SGi reference point.

In EPC the Serving-Gateway’s intermediate function of routing traffic to the correct eNB is removed and instead this is all handled by the UPF, along with buffering packets for a subscriber in idle mode.

The idea behind this, is that by removing the S-GW removes extra hops / latency in the network, and allows users to be connected to the best UPF for their needs, typically one located close to the user.

However, there are often scenarios where an intermediate function is required – for example wanting to anchor a session to keep an IP Address allocated to one UPF associated with a user, while they move around the network. In this scenario a UPF can act as an “Session Anchor” (Akin to a P-GW), and pass through “Intermediate UPFs” (Like S-GWs).

Unlike the EPCs architecture, there is no limit to how many I-UPFs can be chained together between the Session Anchoring UPF and the gNB, and this chaining of UPFs allows for some funky routing options.

The UPF is dumb by design. The primary purpose is just to encapsulate traffic destined from external networks to subscribers into GTP-U packets and forward them onto the gNodeB serving that subscriber, and the same in reverse. Do one thing and do it well.

SMF – Session Management Function

So with dumb UPFs we need something smarter to tell them what to do.

Control of the UPFs is handled by the SMF – Session Management Function, which signals using PFCP down to the UPFs to tell them what to do in terms of setting up connections.

While GTP-U is used for handling user traffic, control plane traffic no longer uses GTPv2-C. Instead 5GC uses PFCP – Packet Forwarding Control Protocol. To get everyone warmed up to Control & User Plane separation 3GPP introduced as seen in CUPS into the EPC architecture in Release 14.

This means the interface between the SMF and UPF (the N4 interface) is more or less the same as the interface between a P-GW-C and a P-GW-U seen in CUPS.

When a subscriber connects to the network and has been authenticated, the AMF (For more info on the AMF see the sister post to this topic covering Control Plane traffic) requests the SMF to setup a connection for the subscriber.

Interworking with EPC

For deployments with an EPC and 5GC interworking between the two is of course required.

This is achieved first through the implementation of CUPS (Control & User Plane Separation) on the EPC, specifically splitting the P-GW into a P-GW-C for handing the Control Plane signalling (GTPv2c) and a P-GW-U for the User Plane traffic encapsulated into GTP.

The P-GW-C and P-GW-U communications using PFCP are essentially the same as the N4 interface (between the SMF and the UPF) so the P-GW-U is able to act as a UPF.

This means handovers between the two RATs / Cores is seamless as when moving from an LTE RAT and EPC to a 5G RAT and 5G Core, the same UPF/P-GW-U is used, and only the Control Plane signalling around it changes.

When moving from LTE to 5G RAT, the P-GW-C is replaced by the SMF,
When moving from 5G RAT to LTE, the SMF is replaced by the P-GW-C.
In both scenarios user plane traffic takes the same exit point to external Data Networks (SGi interface in EPC / N6 interface in 5GC).

Interfaces / Reference Points

N3 Interface

N3 interface connects the gNodeB user plane to the UPF, to transport GTP-U packets.

This is a User Plane interface, and only transports user plane traffic.

This is akin to the S1-UP interface in EPC.

N4 Interface

N4 interface connects the Session Management Function (SMF) control plane to the UPF, to setup, modify and delete UPF sessions.

It is a control plane interface, and does not transport User Plane traffic.

This interface relies on PFCP – Packet Forwarding Control Protocol.

This is akin to the SxB interface in EPC with CUPS.

N6 Interface

N6 interface connects the UPF to External Data Networks (DNs), taking packets destined for Subscribers and encapsulating them into GTP-U packets.

This is a User Plane interface, and only transports user plane traffic.

This is akin to the SGi interface in EPC.

N9 Interface

When Session Anchoring is used, and Intermediate-UPFs are used, the connection between these UPFs uses the N9 interface.

This is only used in certain scenarios – the preference is generally to avoid unnecessary hops, so Intermediate-UPF usage is to be avoided where possible.

As this is a User Plane interface, it only transports user plane traffic.

When used this would be akin to the S5 interface in EPC.

N11 Interface

SMFs need to be told when to setup / tear down connections, this information comes from the AMF via the N11 interface.

As this is a Control Plane interface, it only transports control plane traffic.

This is similar to the S11 interface between the MME and the S-GW in EPC, however it would be more like the S11 if the S11 terminated on the P-GW.

Meta: 5G on this Blog

5G SA, Mobile Networks, RFCs & Standards

I’ve tried to steer well clear of the fever-pitched hype over 5G recently (I mean, this year I wrote 22 posts about building GSM networks with Osmocom to avoid talking about 5G), but the time has come to start sharing more about 5G.

But before we do…

My promise to you:
No talk of Augmented Reality, Holographic Video calls, 5G connected cities, sales buzzwords.

Just info for nerds about real (actually standardized) 5G.

As always I’ll reference specs where possible.

Let’s get building!

Link to all 5G tagged posts.

Packet Gateway (P-GW) used in LTE EPC Networks

LTE EPC: Packet Gateway (P-GW) Basic Function

EPC, LTE, Mobile Networks, , ,

The Packet Gateway connects users of an LTE network to external networks like the Internet, by encapsulating IP packets inside GTP and forwarding them on to reach our subscriber wherever in the network they are.

To understand the P-GW, first it’s a good idea to first get a grasp on what GTP is and why we use GTP to transport subscriber’s data through the LTE Evolved Packet Core.

So we use GTP to encapsulate user’s traffic, making it easy to carry it transparently from outside networks (Like the Internet) to the eNodeB and onto our UE / mobile phones, and more importantly redirect where the user’s traffic it’s going while keeping the same IP address.

But we need a network element to take plain old IP from external networks / Internet, and encapsulate the traffic into the GTP packets we’ll send to the subscriber.

This network element will have to do the same in reverse and decapsulate traffic coming from the subscriber to put it back onto the external networks / Internet.

That’s the role of the Packet Gateway (P-GW). The P-GW sits on the border between the outside network (An interface / reference point known as the SGi Interface) and the rest of the packet core (Serving-Gateway then onto eNodeB & UE) via the S5 Interface.

Let’s look at how the P-GW handles an incoming packet:

  1. An IP packet comes in from the Internet destined for IP 1.2.3.4 and routed to the P-GW.
  2. The P-GW looks up in it’s internal database what Tunnel Endpoint Identifier (TEID) IP Address 1.2.3.4 is associated with.
  3. The P-GW encapsulates the IP packet (Layer 3 & up) into a GTP packet, adding the Tunnel Endpoint Identifier (TEID) to the GTP header.
  4. The P-GW looks up in it’s internal database which Serving Gateway is handling traffic for that TEID.
  5. The P-GW then sends this GTP packet containing our IP packet to the Serving Gateway.

In order to start relaying traffic to/from the S5 & SGi interfaces, the P-GW needs a set of procedures for setting up these sessions, (IP Address allocation and TEID allocation) known as bearers. This is managed using GTPv2 (aka GTPv2-Control Plane / GTPv2-C).

GTPv2-C has a set of procedures for creating these sessions, the key ones used by the P-GW are:

  • Create Session Request / Response – Sets up GTP sessions / bearers
  • Delete Session Request / Response – Removes GTP session / bearers

The Create Session Request is sent by the S-GW to the P-GW and contains the APN of the network to be setup, the IP Address to be assigned (if static) and information regarding the maximum throughput the user will be permitted to achieve.

If the P-GW was able to setup the connection as requested, a Create Session Response is sent back to the P-GW, with the IP Address for the UE to use, and the TEID (Tunnel Endpoint Identifier).

At this stage the tunnel is up and ready to go, traffic to the P-GW to the IP of the UE will be encapsulated in GTP-U packets with the TEID for this bearer, and forwarded on to the S-GW serving the user.

LTE EPC: Serving Gateway (S-GW) Basic Function

EPC, LTE, Mobile Networks, , , , ,

As our subscribers are mobile, moving between base stations / cells, the destination of the incoming GTP-U packets needs to be updated every time the subscriber moves from one cell to another.

If you’re not familiar with GTP take a read of this primer.

As we covered in the last post, the Packet Gateway (P-GW) handles decapsulating and encapsulating this traffic into GTP from external networks, and vise-versa. The Packet Gateway sends the traffic onto a Serving Gateway, that forwards the GTP-U traffic onto the eNodeB serving the user.

So why not just route the traffic from the Packet Gateway directly to the eNodeB?

As our users are inherently mobile, the signalling load to keep updating the destination of the incoming GTP-U traffic to the correct eNB, would put an immense load on the P-GW. So an intermediary gateway – the Serving Gateway (S-GW), is introduced.

The S-GW handles the mobility between cells, and takes the load of the P-GW. The P-GW just hands the traffic to a S-GW and let’s the S-GW handle the mobility.

It’s worth keeping in mind that most LTE connections are not “always on”. Subscribers (UEs) go into “Idle Mode”, in which the data connection and the radio connection is essentially paused, and able to be bought back at a moments notice (this allows us to get better battery life on the UE and better frequency utilisation).

When a user enters Idle Mode, an incoming packet needs to be buffered until the Subscriber/UE can get paged and come back online. Again this function is handled by the S-GW; buffering packets until the UE comes available then forwarding them on.

Open5GS EPC: Static IP Addresses for UEs / APNs / Subscribers

EPC, LTE, Mobile Networks, ,

A question that seems to come up often, is how to provide a static IPs to UEs on Open5GS EPC.

By default all UEs are allocated an internal IP that the server the P-GW is running on NATs out, but many users want to avoid NAT, for obvious reasons.

Open5GS has the ability to set a Static IP for each APN a subscriber has, but let’s get one thing out of the way first;

LTE is not Ethernet. No broadcast, no multicast. Each IP Address is best thought of as a single /32 network.
This means you can’t have the UEs in your LTE network in the same 192.168.1.x subnet as your home network along with your laptop and printer, it’s not how it works.

So with that out of the way, let’s talk about how to do static IP address allocation in Open5GS EPC.

Assigning a Subscriber a Static IP Address

From the HSS edit the Subscriber and in the UE IPv4 or UE IPv6 address, set the static address you want to use.

You can set any UE IP Address here and it’ll get allocated to that UE.

But – there’s an issue.

The problem is not so much on the Open5GS P-GW implementation, but just how TCP/IP routing works in general.

Let’s say I assign the UE IPv4 address 1.2.3.4 to my UE. From the UE it sends a packet with the IPv4 Source address of 1.2.3.4 to anywhere on the internet, the eNB puts the packet in GTP and eventually the it gets to the P-GW which sends it out onto the internet from the source address 1.2.3.4.

The problem is that the response will never get back to me, as 1.2.3.4 is not allocated to me and will never make it back to my P-GW, so never relayed back to the UE.

For TCP traffic this means I can send the SYN with the source address of 1.2.3.4, but the SYN/ACK will be routed back to the real 1.2.3.4, and not to me, so the TCP socket will never get opened.

So while we can set a static IPs to be allocated to UEs in Open5GS, unless the traffic can be routed back to these IPs it’s not much use.

Routing

So let’s say we have assigned IP 1.2.3.4 to the UE, we’d need to put a static route on our routers to route traffic to the IP of the PGW. In my case the PGW is 10.0.1.121, so I’ll need to add a static route to get traffic destined 1.2.3.4/32 to 10.0.1.121.

In a more common case we’d assign internal IP subnets for the UE pool, and then add routes for the entire subnet to the IP of the PGW.

CUPS – Control and User Plane Separation in LTE & NR with PFCP (Sx & N4)

5G SA, EPC, LTE, Mobile Networks, , , , , ,

3GPP release 14 introduced the concept of CUPS – Control & User Plane Separation, and the Sx interface, this allows the control plane (GTP-C) functionality and the user plane (GTP-U) functionality to be separated, and run in a distributed fashion, allowing the node a user’s GTP-U traffic flows through to be in a different location to where the Control / Signalling traffic (GTP-C) flows.

In practice that means for an LTE EPC this means we split our P-GW and S-GW into a minimum of two network elements each.

A P-GW is split and becomes a P-GW-C that handles the P-GW Control Plane traffic (GTPv2-C) and a P-GW-U speaking GTP-U for our User Plane traffic. But the split doesn’t need to stop there, one P-GW-C could control multiple P-GW-Us, routing the user plane traffic. Sames goes for S-GW being split into S-GW-C and S-GW-U,

This would mean we could have a P-GW-U located closer to a eNB / User to reduce latency, by allowing GTP-U traffic to break out on a node closer to the user.

It also means we can scale better too, if we need to handle more data traffic, but not necessarily more control plane traffic, we can just add more P-GW-U nodes to handle this.

To manage this a new protocol was defined – PFCP – the Packet Forwarding Control Protocol. For LTE this is refereed to as the Sx reference point, it’ also reused in 5G-SA as the N4 reference point.

When a GTP-C “Create Session Request” comes into a P-GW for example from an S-GW, a PFCP “Session Establishment Request” is sent by the P-GW-C to the P-GW-U with much the same information that was in the GTP-C request, to setup the session.

So why split the Control and User Plane traffic if you’re going to just relay the GTP-C traffic in a different format?

That was my first question – the answer is that keeping the GTP-C interface ensures backward compatibility with older MMEs, PCRFs, charging systems, and allows a staged roll out and bolting on extra capacity.

GTP-C disappears entirely in 5G Standalone architecture and is replaced with the N4 interface, which uses PFCP for the Control Plan and GTP-U again.

Here’s a capture from Open5Gs core showing GTPv2C and PFCP in play.

CUPS-PFCP-and-GTPv2cDownload

Nokia 3310 connected to test GSM network running with Osmocom

Twenty years of the Nokia 3310

GSM, Mobile Networks, ,

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!

Wireshark Filtering S1AP to find Subscriber Signaling

EPC, Mobile Networks, SDM,

The S1 interface can be pretty noisy, which makes it hard to find the info you’re looking for.

So how do we find all the packets relating to a single subscriber / IMSI amidst a sea of S1 packets?

The S1 interface only contains the IMSI in certain NAS messages, so the first step in tracing a subscriber is to find the initial attach request from that subscriber containing the IMSI.

Luckily we can filter in Wireshark to find the IMSI we’re after;

e212.imsi == "001010000000001"

The Wireshark e212 filter filters for ITU-T E.212 payloads (ITU-T E.212 is the spec for PLMN identifiers).

Quick note – Not all IntialUEMessages will contain the IMSI – If the subscriber has already established comms with the MME it’ll instead be using a temporary identifier – M-TMSI, unless you’ve got a way to see the M-TMSI -> IMSI mapping on the MME you’ll be out of luck.

Next up let’s take a look at the contents of one of these packets,

Inside the protocolIEs is the MME_UE_S1AP_ID – This unique identifier will identify all S1 signalling for a single user.

The MME_UE_S1AP_ID is a unique identifier, assigned by the MME to identify which signaling messages are for which subscriber.

(It’s worth noting the MME_UE_S1AP_ID is only unique to the MME – If you’ve got multiple MMEs the same MME_UE_S1AP_ID could be assigned by each).

So now we have the MME_UE_S1AP_ID, we can filter all S1 messaging containing that MME_UE_S1AP_ID, we’ll use this Wireshark filter to get it:

s1ap.MME_UE_S1AP_ID == 2

Boom, there’s a all the signalling for that subscriber.

Alternatively you can just right click on the value and apply it as a filter instead of typing everything in,

Hopefully that’ll help you filter to find what you’re looking for!

List of Open Source Evolved Packet Core (EPC) Implementations

EPC, LTE, Mobile Networks, Software, , , , , , ,

Open5Gs

Formerly NextEPC.

OpenAI Core Network

Related to / branched from OMEC.

Magma

Based on OMEC, with a focus on Fixed Wireless more than mobile.

Not fair to consider it just an EPC, Magma is highly scaleable and designed with a focus on Fixed Wireless offerings.

Supported by the Facebook Telecom Infra Project.

OMEC – Open Evolved Mobile Core

Supported by Open Networking Foundation, Sprint and several other large players.

OMEC has each Network Element in it’s own repo in GitHub and each is managed by a different team.

OpenMME – MME

In use by at least one commercial operator (in some capacity).

Next Generation Infrastructure Core (S-GW & P-GW)

Seems to only compile on 16.04 and not really

c3po – HSS / CDR / CTF

OpenCORD

srsEPC

(from the guys who produced srsLTE / srsENB / srsUE)

Android Carrier Privileges

GSM, IMS / VoLTE, LTE, Mobile Networks, SDM, Software, , ,

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

EPC, GSM, LTE, Mobile Networks, Uncategorized, , , , , ,

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

GSM, Mobile Networks, RF, , , ,

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.

Diameter Dispatches: S6a Authentication Information Request / Answer

EPC, LTE, SDM, , , ,

This is part of a series of posts focusing on common Diameter request pairs, looking at what’s inside and what they do.

The Authentication Information Request (AIR) and Authentication Information Answer (AIA) are one of the first steps in authenticating a subscriber, and a very common Diameter transaction.

The Process

The Authentication Information Request (AIR) is sent by the MME to the HSS to request when a Subscriber begins to attach containing the IMSI of the subscriber trying to connect.

If the subscriber’s IMSI is known to the HSS, the AuC will generate Authentication Vectors for the Subscriber, and repond back to the MME in an Authentication Information Answer (AIA).

For more information on how the Authentication process works and what the authentication vectors do, I’ve written about that quite extensively here.- HSS & USIM Authentication in LTE.

The Authentication Information Request (AIR)

The AIR is a comparatively simple request, without many AVPs;

The Session-Id, Auth-Session-State, Origin-Host, Origin-Realm & Destination-Realm are all common AVPs that have to be included.

The Username AVP (AVP 1) contains the username of the subscriber, which in this case is the IMSI.

The Requested-EUTRAN-Authentication-Info AVP ( AVP 1408 ) contains information in regards to what authentication info the MME is requesting from the subscriber, typically this indicates the MME is requesting 1 vector (Number-Of-Requested-Vectors (AVP 1410)), an immediate response is preferred (Immediate-Response-Preferred (AVP 1412)), and if the subscriber is re-resyncing the SQN will include a Re-Synchronization-Info AVP (AVP 1411).

The Visited-PLMN-Id AVP (AVP 1407) contains information regarding the PLMN of the RAN the Subscriber is connecting to.

The Authentication Information Answer (AIA)

The Authentication Information Answer contains several mandatory AVPs that would be expected, The Session-Id, Auth-Session-State, Origin-Host and Origin-Realm.

The Result Code (AVP 268) indicates if the request was successful or not, 2001 indicates DIAMETER SUCCESS.

The Authentication-Info (AVP 1413) contains the returned vectors, in LTE typically only one vector is returned, a sub AVP called E-UTRAN-Vector (AVP 1414), which contains AVPs with the RAND, XRES, AUTN and KASME keys.

Further Reading & References

3GPP TS 29.272 version 15.10.0 Release 15

Example Packet Capture (PCAP) of Message Flow