Category Archives: EPC

IMTx: NET02x (4G Network Essentials) – Management of Data Flows – 5/6. S1AP Connection

EPC, EUTRAN, LTE, Mobile Networks, Notes, RF, , , , , ,

These are my lecture notes from IMT’s NET02x (4G Network Essentials) course, I thought I’d post them here as they may be useful to someone. You can find my complete notes here.

Each MME can manage millions of UEs.

To handle this load the requirements of each subscriber for the MME must be as minimal and simple as possible so as to scale easily.

For each UE in the network a connection is setup between the UE and the MME.

This is done over the S1-AP’s Control Plane interface (sometimes calls S1-Control Plane or S1-CP) which carries control plane data to & from the UE via the eNB to the MME.

S1-CP is connection-oriented, meaning each UE has it’s own connection to the MME, so there are as many S1-CP connections to the MME as UE’s connected.

Each of these S1-CP connections is identified by a pair of unique connection IDs. The eNB keeps track of the connection IDs for each UE connected and hands this information off each time the UE moves to a different eNB.

The eNB keeps a lookup table between the RNTI of the UE and the LCID – the Logical Channel Identifier. This means that the eNB knows the sent and received ID of the S1-CP connection for each UE, and is able to translate that into the RNTI and LCID used to send the data over the air interface to the UE.

S1-CP Connect (Attach Procedure)

As we discussed in radio interfaces, when a UE connects to the network it is assigned an RNTI to identify it on the radio interface and allocate radio resources to it.

Once the RNTI is confirmed by both the eNB and the UE, a EMM Attach Request, which is put into an RRC Message called RRCConnectionSetupComplete.

The eNB must next choose a serving MME for this UE. It picks one based on it’s defined logic, and sends a S1-AP Intial UE Message (EMM Attach Request) to the MME along with the eNB’s connection identity assigned for this connection.

The MME stores the connection identity assigned by the eNB and chooses it’s own connection identity for it’s side, and sends back an S1AP Downlink NAS Transport response with both connection identities and the response for the attach request (This will be an EMM Authentication Request).

The eNB then stores the connection identity pair and the associated RNTI and LCID for the UE, and forwards the EMM Authentication Request to the RNTI of the UE via RRC.

The UE will pass the authentication challenge input parameters to the USIM which will generate a response. The UE will send the output of this response in a EMM Authentication Responseto the eNB, which will look at the RNTI and LCID received and consult the table to find the Connection Identifiers and IP of the serving MME for this UE.

S1AP Connect procedure

IMTx: NET02x (4G Network Essentials) – Management of Data Flows – 4. Transmitting Packets in a Tunnel

EPC, EUTRAN, LTE, Mobile Networks, RF, , , ,

These are my lecture notes from IMT’s NET02x (4G Network Essentials) course, I thought I’d post them here as they may be useful to someone. You can find my complete notes here.

Establishing a GTP Tunnel

When a new tunnel is setup between two nodes, GTP-C will be used to setup the tunnel and the both ends of the tunnel will allocate a their own locally unique TEID to the tunnel.

Let’s take a look at setting up a GTP tunnel between a S-GW and a P-GW, initiated by the S-GW.

The process will start with the S-GW sending the P-GW a GTP-C tunnel establishment request and include the TEID the S-GW has allocated for it’s end of the tunnel (using TEID 102 in this example), sent from the S-GW to the P-GW.

The P-GW will receive this packet. When it does it will allocate a new TEID for this tunnel for it’s side (In this case it’s 16538), store the sender’s address and received TEID, and link local TEID 16538 with S-GW/102.

An ACK is sent from the P-GW to the S-GW with both TEID values.

Finally the S-GW stores the senders’ address, the received TEID and the link 102-PGW address 16538.


Now the exchange is complete the S-GW and the P-GW each know the TEID of it’s local side of the tunnel, and the remote side of the tunnel.

TEID Management Tables

After GTP tunnels are setup a management table is populated defining the forward rules for that traffic.

For example a packet coming in on TEID 103 would, according to the table forward to TEID 102. TEID 102 sends traffic to the P-GW’s IP using remote TEID 16538.

The same rules for uplink are applied for downlink.

Each tunnel has pair of TEIDs a local TEID and a remote TEID.

Because it’s such a simple table it can be updated very easily and scales well.

Different QoS parameters can be assigned to each tunnel, called a data bearer.

IMTx: NET02x (4G Network Essentials) – Management of Data Flows – 3. Identifying & Managing Tunnels

EPC, EUTRAN, LTE, Mobile Networks, Notes, RF, , , ,

These are my lecture notes from IMT’s NET02x (4G Network Essentials) course, I thought I’d post them here as they may be useful to someone. You can find my complete notes here.

As we’ve talked about traffic to and from UEs is encapsulated in GTP-U tunnels, with the idea that by encapsulating data destined for a UE it can be routed to the correct destination (eNB serving UE) transparently and efficiently.

As all traffic destined for a UE will come to the P-GW, the P-GW must be able to quickly determine which eNB and S-GW to send the encapsulated data too.

The encapsulated data is logically grouped into tunnels between each node.

A GTP tunnel exists between the S-GW and the P-GW, another GTP tunnel exists between the S-GW and the eNB.

Each tunnel between the eNB and the S-GW, and each tunnel between S-GW and P-GW, is allocated a unique 32 bit value called a Tunnel Endpoint Identifier (TEID) allocated by the node that corresponds to each end of the tunnel and each TEID is locally unique to that node.

For each packet of user data (GTP-U) sent through a GTP tunnel the TEID allocated by the receiver is put in the GTP header by the sender.

The destinations of the tunnels can be updated, for example if a UE moves to a different eNB, the tunnel between the S-GW and the eNB can be quickly updated to point at the new eNB.

If the UE moves to a different eNB only the tunnel between the S-GW and the eNB needs to be updated

Each end of the tunnel is associated with a TEID, and each time a GTP packet is sent through the tunnel it includes the TEID of the remote end (reciever) in the GTP header.

IMTx: NET02x (4G Network Essentials) – Management of Data Flows – 2. GTP Protocol

EPC, EUTRAN, LTE, Mobile Networks, Notes, RF, , ,

These are my lecture notes from IMT’s NET02x (4G Network Essentials) course, I thought I’d post them here as they may be useful to someone. You can find my complete notes here.

When a packet arrives from an external network, like the internet, it is routed to the P-GW.

The P-GW takes this packet and places it in another IP packet (encapsulates it) and then forwards the encapsulated data to the Serving-Gateway.

The S-GW then takes the encapsulated data it just recieved and sends it on inside another IP packet to the eNB.

The encapsulated data sent from the P-GW to the S-GW, and the S-GW to the eNB, is carried by UDP, even if the traffic inside is TCP.

Communication between these elements can be done using internal addressing, and this addressing information will never be visible to the UE or the external networks, and only the P-GW needs to be reachable from the external networks.

This encapsulation is done using GTP – the GPRS Tunneling Protocol.

Specifically IP traffic to and from the UE is contained in GTP-U (User data) packets.

The control data for GTP is contained in GTP-C packets, which sets up tunnels for the GTP traffic to flow through (more on that later).

To summarize, user IP packets are encapsulated into GTP-U packets, which are a transported by UDP between the different nodes (S-GW and eNB)

IMTx: NET02x (4G Network Essentials) – Management of Data Flows – 1. Principle of Encapsulation

EPC, EUTRAN, LTE, Mobile Networks, RF, , , , , ,

These are my lecture notes from IMT’s NET02x (4G Network Essentials) course, I thought I’d post them here as they may be useful to someone. You can find my complete notes here.

Mobile networks are by definition, mobile.

In a fixed network, if I were to connect my laptop to my network at home, I’d get a different address to if I plug it in at work.

In a mobile network UEs are often moving, but we can’t keep changing the IP address – that would lead to all sorts of issues.

The UE must maintain the same IP address, at least for the duration of their session.

Instead the IP address of a UE is allocated by the P-Gateway (P-GW) when the UE attaches.

The IP the P-GW allocates to the UE is in a subnet managed by the P-GW – that IP prefix is associated with the P-GW, so traffic is sent to the P-GW to get to the UE.

Therefore all traffic destined for the UE from external networks will be sent to the P-GW first.

Because the UE is mobile and changing places inside the network, we need a way to keep the UE’s IP even though it’s moving around, something that by default TCP/IP networks don’t cater for very well.

To achieve this we use a technique known as encapsulation where we take the complete IP packet for the UE, and instead of forwarding it on to the UE on a Layer 3 or Layer 2 level, we bundle the whole packet up and put it inside a new IP packet we can forward on anywhere regardless of what’s insude, until it gets to the eNB the UE is on when it can be unpacked and sent to the UE, which is unaware of all the steps / hops it went through.

The concept is very similar to GRE to a VPN (PPTP, IPsec, L2TP, etc) where the user’s IP packets are encapsulated inside another IP packet.

We encapsulate the data using GTP – GPRS Tunneling Protocol.

From a Layer 3 perspective the fact the contents of the GTP packet (another IP packet) is irrelevant, and it’s just handled like any other IP packet being sent from the P-GW to the S-GW.

Getting traffic to the UE

When a packet is sent to the UE’s IP Address from an external destination, it’s first sent to the P-GW, as the P-GW manages that IP prefix.

The P-GW identifies the packet as being destined for a UE, so it encapsulates the entire packet for the UE, by wrapping it up inside a GTP packet.

UE’s IP Packet encapsulated by the P-GW and sent to the IP of the S-Gw

The P-GW then forwards the GTP packet to the serving Serving-Gateway (S-GW)’s IP Address, so the S-GW can forward it to the eNB to get to the UE.

(The P-GW forwards the traffic to the S-GW so the S-GW can get it to the correct eNB for the UE, the reason for having two nodes to manage this is so it can scale better)

Once the traffic gets to the the eNB serving the UE, the eNB de-encapsulates the data, so it’s now got an IP packet with the destination IP of the UE.

It takes the data and puts it onto a transport block sent to the specific RNTI of the UE.

The hops between the UE and the P-GW are transparent to the UE – it doesn’t see the IP Address of the eNB or the S-GW, or any of the routers in between.

Further Reading

Wikipedia – GPRS Tunneling Protocol

3GPP Specs for LTE’s implementation of GTP

Packet capture of some GTP packets

IMTx: NET02x (4G Network Essentials) – Radio Interface – 7. PDCP & Global Vision

EPC, EUTRAN, LTE, Mobile Networks, Notes, RF, , ,

These are my lecture notes from IMT’s NET02x (4G Network Essentials) course, I thought I’d post them here as they may be useful to someone. You can find my complete notes here.

The Packet Data Convergence Protocol PDCP protocol stack sits ontop of the radio interface stack, and manages the connection the EPC.

There is one PDCP per RLC instance, except when operating in Transparent Mode.

Functionality offered by PDCP

Header Compression

Using Robust Header Correction (ROHC) PDCP compresses the headers.

As the traffic is point to point headers vary vary little so is predictable and can be compressed efficiently.

For a VoLTE medea stream a 40 byte IPv6 header, 8 byte UDP header, 12 byte RTP header and 30 bytes of RTP data.

This means that we have 60 bytes of headers and only 30 bytes of data, which is a very inefficient use of resources, so by compressing this data we can shrink this substantially.

Handover Mitigation

When handing over between NodeBs on previous 3GPP RANs packet loss and reordering was common during handovers between NodeBs.

E-UTRAN specs have minimized this as much as possible, the handing off eNB can transfer information using PDCP about data to be transferred to the UE to the eNB the UE is handing over too.

Security

As the radio link is particularly vulnerable to eavesdropping, PDCP offers another independent ciphering and integrity control mechanism to verify data is not modified / intercepted.

Usage of PDCP Functionality

Not all these functionalities are used for all types of traffic, as shown in the table below.

PDCP usage in LTE

Recap of Radio Interfaces

PDCP is discussed in this post, interfacing the radio interface with the core network.

RLC is discussed here and manages re-sequencing of data, offers 3 modes of QoS and performs segmentation and concatenation of traffic.

MAC is discussed here and performs multiplexing of the logical channels, HARQ, Radio Resource Allocation.

Physical Channel is discussed here and performs coding for error correction and modulates the data onto the Air (Uu) interface via FDD or TDD.

Data Hierarchy

A summary of the hierarchy is shown here with user data in pink and control data in blue:

The RNTI is shown in a dotted box as the RNTI is not transmitted as a header on the transport block but is logically associated with the transport block thanks to the allocation table.

Abbreviation Index

Complete Notes

All my notes on NET02x are available here.

Magma – Facebook’s Open Source LTE / 4G EPC/OSS Platform

EPC, Linux, LTE, Mobile Networks, RF, Software, ,

In February Facebook announced they’d open sourced their Magma project,

Magma provides a software-centric distributed mobile packet core and tools for automating network management.

Open-sourcing Magma to extend mobile networks

Magma’s modular software based architecture means you can scale up extra resources as needed, with no need to have physical hardware to run your EPC.

(Cisco’s Ultra Packet Core does have a virtualisation option, but it’s not cheap)

I got pretty excited by this, so I’ve ordered myself an eNodeB (Just a Picocell), a pile of USIMs, programmer and started installing an environment.

In the past I’ve used srsEPC and NextEPC and software-defined radio hardware (BladeRF) to run LTE stuff, so I’m looking forward to seeing if I can implement parts of them into Magma, and also eventually use Kamailio’s IMS modules to implement an IMS core and run VoLTE.

So let’s install Magma, explore it and lurk on the Discord, all while we kill time waiting for hardware to arrive!

Wireshark trace showing a "401 Unauthorized" Response to an IMS REGISTER request, using the AKAv1-MD5 Algorithm

All About IMS Authentication (AKAv1-MD5) in VoLTE Networks

EPC, IMS / VoLTE, LTE, Mobile Networks, Notes, RFCs & Standards, SDM, Security, SIM Cards, Software, VoIP, , , , ,

I recently began integrating IMS Authentication functions into PyHSS, and thought I’d share my notes / research into the authentication used by IMS networks & served by a IMS capable HSS.

There’s very little useful info online on AKAv1-MD5 algorithm, but it’s actually fairly simple to understand.

RFC 2617 introduces two authentication methods for HTTP, one is Plain Text and is as it sounds – the password sent over the wire, the other is using Digest scheme authentication. This is the authentication used in standard SIP MD5 auth which I covered ages back in this post.

Authentication and Key Agreement (AKA) is a method for authentication and key distribution in a EUTRAN network. AKA is challenge-response based using symmetric cryptography. AKA runs on the ISIM function of a USIM card.

I’ve covered the AKA process in my post on USIM/HSS authentication.

The Nonce field is the Base64 encoded version of the RAND value and concatenated with the AUTN token from our AKA response. (Often called the Authentication Vectors).

That’s it!

It’s put in the SIP 401 response by the S-CSCF and sent to the UE. (Note, the Cyperhing Key & Integrity Keys are removed by the P-CSCF and used for IPsec SA establishment.

Wireshark trace showing a "401 Unauthorized" Response to an IMS REGISTER request, using the AKAv1-MD5 Algorithm
Click for Full Size version of this image