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)
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.
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.
Recap of Radio Interfaces
PDCP is discussed in this post, interfacing the radio interface with the core network.
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.
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.
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.
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.
