One of the common themes we cover over and over in the 4G discussion is the desire to preserve energy on the UE RF side of things, to extend battery life as much as possible.
The 3GPPs requirements for LTE also included the smallest round trip times, defining less than 5 ms in unload condition, so traffic to the UE must be routed as quickly as possible.
Mobiles are by their very nature, mobile.
This requires UEs to constantly monitor the RF conditions and the signal measurements from different base stations so the UE can determine if it’s time to handoff to another cell due to going further from one eNB and closer to another, or another eNB offering better RF conditions (Strong signal etc).
This requires regular exchanges of messages and checks, but this would take a lot of energy and eat up battery usage.
Instead we avoid maintaining the radio connection all the time with the aid of an inactivity timer on the eNB.
For as long as user data is flowing over the air interface the connection is maintained, for example web browsing, the inactivity timer is constantly reset as traffic flows.
However when the eNB detects no packets sent or received by the UE the timer starts counting down from it’s set value.
When the inactivity timer reaches 0 the RRC Connection is released and the UE no longer has an RNTI.
The UE is still listening to an eNB, it’s just not sending data to it it and visa-versa.
As the radio bearer has been removed the UE the S1-AP and S1-UP bearers between the eNB and the MME and the eNB and the S-GW respectively, can be torn down.
This means the MME is no long sure of exactly which eNB the UE is listening on.
This is referred to as ECM_IDLE state as there is no radio connection, and the network is unaware of the precise location of the UE.
An ECM_ACTIVE state is the state when the UE is connected to an eNB with an RNTI and it’s inactivity timer has not reached 0.
The dotted line bearers shown in the image above frequently change between active and inactive based on the ECM_ACTIVE / ECM_INACTIVE state of the bearers.
EPS Mobility Management (EMM) has two states – EMM-Registered (UE reachable) and EMM-Deregistered (UE not reachable).
A UE is in the deregistered state when it is not rechable, for example not currently powered up or in flight mode.
The MME memorizes the state of each UE and it’s context elements such as it’s most recent GUTI, IMSI, security parameters etc.
Attach Procedure
To attach to the network a UE sends an EMM Attach Request with it’s most recent GUTI to the MME.
In the same request the UE also includes an ESM PDN Connectivity Request to gain access to the external networks.
The Authentication & Key Agreement procedure is followed between the UE and the MME/HSS to authenticate the network and the subscriber.
One this is done the MME looks at the connectivity requested and the APN of the subscriber, the MME then selects a Serving-Gateway and Packet-Gateway based on the APN.
The MME then sends a GTP-C Create Session Request along with the connectivity requested (IPv4/6), APN and IMSI of the subscriber and it’s allocated TEID for this tunnel to the S-GW.
The S-GW also sends a GTP-C Create Session Request along with the connectivity requested (IPv4/6), APN and IMSI of the subscriber to the P-GW, along with the S-GW’s allocated TEID for this tunnel too.
The P-GW then sends a GTP-C Create Session back to the S-GW containing it’s TEID and it also includes the IP Address to be allocated to the UE.
A GTP session is now setup between the P-GW and the S-GW for this bearer, with the TEID values added to the TEID management tables on both devices. This GTP tunnel is referred to an S5 (home) or an S8 (roaming) Bearer in 3GPP parlance.
Another GTP-C Create Session message with it’s own TEID is also sent from the S-GW to the MME.
The MME, S-GW and P-GW now each know TEID for each of the 2 tunnels setup (MME<->S-GW, S-GW<->P-GW) so have what they need to fill their TEID management tables.
When the MME recieves the GTP-C Create Session with the IP Address for the UE it sends an EMM Attach Accept and a EPS Bearer Context Setup Request containing the IP Address the P-GW allocated to the UE to the UE itself.
The UE stores the allocated IP and sends an acknowledgement to the MME in the form of an EMM Attach Complete message back to the MME.
The MME sends a GTP-C Modify Bearer Request which transfers the bearer setup between MME and SGW and modifies it to be between the SGW and the eNB.
The S-GW sends back a GTP-C Modify Bearer Complete message and modifies the GTP tunnel to be between the SGW and the eNB. A S1 bearer is now established for carrying user data from the eNB to the SGW.
Once this procedure is complete the UE is now in the EMM Registered State meaning it is known to the MME, it has a security association and has an IP Address.
The S-GW and the P-GW also stores the TEIDs for the UE.
Detach Procedure
When a UE detaches from the network (for example it powers down), the network must release all the tunnels for that UE, the MME state must be updated to EMM Deregistered and the MME must also keep a record for the last GUTI and security keys,
To detach from the network the UE sends a RLC UL Information Transfer message containing an EMM Detach Request which includes it’s current GUTI.
As soon as the UE recivers confirmation from the eNB the UE can power down, but the eNB must inform the network of the disconnection so the resources can be released.
The eNB sends a S1Ap Uplink NAS Transport message containing a EMM Detach Request with the UE’s GUTI to the MME.
The MME can then release the security context,
The MME then sends a GTP-C Delete Session Request to the S-GW.
Upon recipt of this request the S-GW requests the P-GW tears down it’s tunnel between the P-GW and S-GW (aka the S5/S8 Bearer) by sending it’s own GTP-C Delete Session Request to the P-GW.
Once the S-GW has confirmation the tunnel has been taken down (In the form of a GTP-C Delete Session Response) the S-GW sends a GTP-C Delete Session Response to the MME.
The MME must signal to the eNB it can release the RNTI and the radio resources. To do this it sends a S1-AP UE Context Release Command which releases the radio bearers and tears down the S1-UP bearer between the eNB and the S-GW.
The eNB then sends a S1-AP UE Context Release Completeto the MME.
Finally the MME sends a Diameter Notification Request (PGW and APN Removed) to the HSS to update the HSS of the user’s status, the HSS signals back with a Diameter Notification Answer and the HSS knows the user is no longer reachable.
The LTE architecture compartmentalises the roles in the mobile network.
For example the eNB concentrates on radio connection management, while the MME focuses on security and mobility.
Non Access Stratum (NAS) messages are exchanged between the terminal and the MME.
Access Stratum (AS) messages are exchanged over the air between the UE and the eNB. It contains all the radio related information.
The eNB must map the NAS messages from an MME to a LCID and RNTI and transmit them over the air, and vice-versa. The eNB forwards this data without ever analyzing it.
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.
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.
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.
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.
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)
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.
