Tag Archives: LTE

QoS in LTE (4G) – MBR/AMBR/APN-MBR

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

MBR stands for Maximum Bit Rate, and it defines the maximum rate traffic can flow between a UE and the network.

It can be defined on several levels:

MBR per Bearer

This is the maximum bit rate per bearer, this rate can be exceeded but if it is exceeded it’s QoS (QCI) values for the traffic peaking higher than the MBR is back to best-effort.

AMBR

Aggregate Maximum Bit Rate – Maximum bit rate of all Service Data Flows / Bearers to and from the network from a single UE.

APN-MBR

The APN-MBR allows the operator to set a maximum bit rate per APN, for example an operator may choose to limit the MBR for subscriber on an APN for a MVNO to give it’s direct customers a higher speed.

(This is only applied to Non-GBR bearers)

QoS in LTE (4G) – QCI

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

The QCI (Quality Class Indicator) is a value of 0-9 to denote the service type and the maximum delays, packet loss and throughput the service requires.

Different data flows have different service requirements, let’s look at some examples:

A VoLTE call requires low latency and low packet loss, without low latency it’ll be impossible to hold a conversation with long delays, and with high packet loss you won’t be able to hear each other.

On the other hand a HTTP (Web) browsing session will be impervious to high latency or packet loss – the only perceived change would be slightly longer page load times as lost packets are resent and added delay on load of a few hundred ms.

So now we understand the different requirements of data flows, let’s look at the columns in the table above so we can understand what they actually signify:

GBR

Guaranteed Bit Rate bearers means our eNB will reserve resource blocks to carry this data no matter what, it’ll have those resource blocks ready to transport this data.

Even if the data’s not flowing a GBR means the resources are reserved even if nothing is going through them.

This means those resource blocks can’t be shared by other users on the network. The Uu interface in the E-UTRAN is shared between UEs in time and frequency, but with GBR bearers parts of this can be reserved exclusively for use by that traffic.

Non-GBR

With a Non-GBR bearer this means there is no guaranteed bit rate, and it’s just best effort.

Non-GBR traffic is scheduled onto resource blocks when they’re not in use by other non-GBR traffic or by GBR traffic.

Priority

The priory value is used for preemption by the PCRF.

The lower the value the more quickly it’ll be processed and scheduled onto the Uu interface.

Packet Delay Budget

Maximum allowable packet delay as measured from P-GW to UE.

Most of the budget relates to the over-the-air scheduling delays.

The eNB uses the QCI information to make its scheduling decisions and packet prioritisation to ensure that the QoS requirements are met on a per-EPS-bearer basis.

(20ms is typically subtracted from this value to account for the radio propagation delay on the Uu interface)

Packet Error Loss Rate (PELR)

This is packets lost on the Uu interface, that have been sent but not confirmed received.

The PELR is an upper boundary for how high this can go, based on the SDUs (IP Packets) that have been processed by the sender on RLC but not delivered up to the next layers (PDCP) by the receiver.

(Any traffic bursting above the GBR is not counted toward the PELR)

(The list is now larger than 0-9 with 3GPP adding extra QCI values for MCPTT, V2X, etc, the full list is available here in table 6.1.7A)

QoS in LTE (4G) – GBR & Non-GBR Bearers

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

GBR is a confusing concept at the start when looking at LTE but it’s actually kind of simple when we break it down.

GBR stands for Guaranteed Bit Rate, meaning the UE is guaranteed a set bit rate for the bearer.

The default bearer is always a non-GBR bearer, with best effort data rates.

Let’s look at non-GBR bearers to understand the need for GBR bearers:

As the Uu (Air) interface is shared between many UEs, each is able to transfer data. Let’s take an example of a cell with two UEs in it and not much bandwidth available.

If UE1 and UE2 are both sending the same amount of data it’ll be evenly split between the two.

But if UE1 starts sending a huge amount of data (high bit rate) this will impact on the other UEs in the cells ability to send data over the air as it’s a shared resource.

So if UE2 needs to send a stream of small but important data over the air interface, while UE2 is sending huge amounts of data, we’d have a problem.

To address this we introduce the concept of a Guaranteed Bit Rate. We tell the eNB that the bearer carrying UE2’s small but important data needs a Guaranteed Bit Rate and it reserves blocks on the air interface for UE2’s data.

So now we’ve seen the need for GBR there’s the counter point – the cost.

While UE1 can still continue sending but the eNB will schedule fewer resource blocks to it as it’s reserved some for UE2’s data flow.

If we introduced more and more UEs each requiring GBR bearers, eventually our non-GBR traffic would simply not get through, so GBR bearers have to be used sparingly.

Note: IP data isn’t like frame relay or circuit switched data that’s consistent, bit rate can spike and drop away all the time. GBR guarantees a minimum bit rate, which is generally tuned to the requirements of the data flow. For example a GBR for a Voice over IP call would reserve enough for the media (RTP stream) but no more, so as not to use up resources it doesn’t need.

LTE (4G) – TMSI & GUTI

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

We’ve already touched on how subscribers are authenticated to the network, how the network is authenticated to subscribers and how the key hierarchy works for encryption of user data and control plane data.

If the IMSI was broadcast in the clear over the air, anyone listening would have the unique identifier of the subscriber nearby and be able to track their movements.

We want to limit the use of the IMSI over the air to a minimum.

During the first exchange the terminal is forced to send it’s IMSI, it’s the only way we can go about authenticating to the network, but once the terminal is authenticated and encryption of the radio link has been established, the network allocates a temporary identifier to the terminal, called the Temporary Mobile Subscriber Identity (TMSI) by the serving MME.

The TMSI is given to the terminal once encryption is setup, so only the network and the terminal know the mapping between IMSI and TMSI.

The TMSI is used for all future communication between the Network and the Terminal, hiding the IMSI.

The TMSI can be updated / changed at regular intervals to ensure the IMSI-TMSI mapping cannot be ascertained by a process of elimination.

The TMSI is short – only 4 bytes long – and this only has significance for the serving MME.

For the network to ascertain what MME is serving what TMSI the terminal is also assigned a Globally Unique Temporary (UE) Identity (GUTI), to identify the MME that knows the TMSI to IMSI mapping.

The GUTI is made up of the MNC/MCC combination, then an MME group ID to identify the MME group the serving MME is in, a MME code to identify the MME that allocated the TMSI and finally the TMSI itself.

The decision to use the TMSI or GUTI in a dialog is dependant on the needs of the dialog and what information both sides have. For example in an MME change the GUTI is needed so the original IMSI can be determined by the new MME, while in a normal handover the TMSI is enough.

LTE (4G) – EUTRAN – Key Distribution and Hierarchy

LTE, Mobile Networks, RF, RFCs & Standards, Security, SIM Cards, , , ,

We’ve talked a bit in the past few posts about keys, K and all it’s derivatives, such as Kenc, Kint, etc.

Each of these is derived from our single secret key K, known only to the HSS and the USIM.

To minimise the load on the HSS, the HSS transfers some of the key management roles to the MME, without ever actually revealing what the secret key K actually is to the MME.

This means the HSS is only consulted by the MME when a UE/Terminal attaches to the network, and not each time it attaches to different cell etc.

When the UE/Terminal first attaches to the network, as outlined in my previous post, the HSS also generates an additional key it sends to the MME, called K-ASME.

K-ASME is the K key derived value generated by the HSS and sent to the MME. It sands for “Access Security Management Entity” key.

When the MME has the K-ASME it’s then able to generate the other keys for use within the network, for example the Kenb key, used by the eNodeB to generate the keys required for communications.

The USIM generates the K-ASME itself, and as it’s got the same input parameters, the K-ASME generated by the USIM is the same as that generated by the HSS.

The USIM can then give the terminal the K-ASME key, so it can generate the same Kenb key required to generate keys for complete communications.

Showing Kamse generation sequence in LTE. Image sourced from IMTx: NET02x course on Edx,

LTE (4G) – Ciphering & Integrity of Messages

LTE, Mobile Networks, RF, RFCs & Standards, Security, , ,

We’ve already touched on how subscribers are authenticated to the network, how the network is authenticated to subscribers.

Those functions are done “in the clear” meaning anyone listening can get a copy of the data transmitted, and responses could be spoofed or faked.

To prevent this, we want to ensure the data is ciphered (encrypted) and the integrity of the data is ensured (no one has messed with our packets in transmission or is sending fake packets).

Ciphering of Messages

Before being transmitted over the Air interface (Uu) each packet is encrypted to prevent eavesdropping.

This is done by taking the plain text data and a ciphering sequence for that data of the same length as the packet and XORing two.

The terminal and the eNodeB both generate the same ciphering sequence for that data.

This means to get the ciphered version of the packet you simply XOR the Ciphering Sequence and the Plain text data.

To get the plain text from the ciphered packet you simply XOR the ciphered packet and ciphering sequence.

The Ciphering Sequence is made up of parts known only to the Terminal and the Network (eNB), meaning anyone listening can’t deduce the same ciphering sequence.

The Ciphering Sequence is derived from the following input parameters:

  • Key Kenc
  • Packet Number
  • Bearer Number
  • Direction (UL/DL)
  • Packet Size

Is is then ciphered using a ciphering algorithm, 3GPP define two options – AES or SNOW 3G. There is an option to not generate a ciphering sequence at all, but it’s not designed for use in production environments for obvious reasons.

Diagram showing how the ciphering algorithm generates a unique ciphering sequence to be used. Image sourced from IMTx: NET02x course on Edx,

Ciphering Sequences are never reused, the packet number increments with each packet sent, and therefore a new Cipher Sequence is generated for each.

Someone listening to the air interface (Uu) may be able to deduce packet size, direction and even bearer, but without the packet number and secret key Kenc, the data won’t be readable.

Data Integrity

By using the same ciphering sequence & XOR process outlined above, we also ensure that data has not been manipulated or changed in transmission, or that it’s not a fake message spoofing the terminal or the eNB.

Each frame contains the packet and also a “Message Authentication Code” or “MAC” (Not to be confused with media access control), a 32 bit long cryptographic hash of the contents of the packet.

The sender generates the MAC for each packet and appends it in the frame,

The receiver looks at the contents of the packet and generates it’s own MAC using the same input parameters, if the two MACs (Generated and received) do not match, the packet is discarded.

This allows the receiver to detect corrupted packets, but does not prevent a malicious person from sending their own fake packets,

To prevent this the MAC hash function requires other input parameter as well as the packet itself, such as the secret key Kint, packet number, direction and bearer.

How the MAC is generated in LTE. Image sourced from IMTx: NET02x course on Edx,

By adding this we ensure that the packet was sourced from a sender with access to all this data – either the terminal or the eNB.

LTE (4G) – Authenticating the Network

EPC, LTE, Mobile Networks, RF, RFCs & Standards, Security, SIM Cards, , , ,

In my last post we discussed how the network authenticated a subscriber, now we’ll look at how a subscriber authenticates to a network. There’s a glaring issue there in that the MME could look at the RES and the XRES and just say “Yup, OK” even if the results differed.

To combat this LTE networks have mutual authentication, meaning the network authenticates the subscribers as we’ve discussed, and the subscribers authenticate the network.

To do this our HSS will take the same random key (RAND) we used to authenticate the subscriber, and using a different cryptographic function (called g) take the RAND, the K value and a sequence number called SQN, and using these 3 inputs, generate a new result we’ll call AUTN.

The HSS sends the RAND (same as RAND used to authenticate the subscriber) and the output of AUTN to the MME which forwards it to the eNB to the UE which passes the RAND and AUTH values to the USIM.

The USIM takes the RAND and the K value from the HSS, and it’s expected sequence number. With these 3 values it applies the cryptographic function g generates it’s own AUTN result.

If it matches the AUTN result generated by the HSS, the USIM has authenticated the network.

LTE (4G) – Authenticating Subscribers

EPC, LTE, Mobile Networks, RF, RFCs & Standards, SDM, SIM Cards, , , ,

The USIM and the HSS contain the subscriber’s K key. The K key is a 128 bit long key that is stored on the subscriber’s USIM and in the HSS along with the IMSI.

The terminal cannot read the K key, neither can the network, it is never transmitted / exposed.

When the Terminal starts the attach procedure, it includes it’s IMSI, which is sent to the MME.

The MME then sends the the HSS a copy of the IMSI.

The HSS looks up the K key for that IMSI, and generates a random key called RAND.

The HSS and runs a cryptographic function (called f) using the input of RAND and K key for that IMSI, the result is called XRES (Expected result).

The HSS sends the output of this cryptographic function (XRES), and the random value (RAND) back to the MME.

The MME forwards the RAND value to the USIM (via eNB / Terminal), and stores a copy of the expected output of the cryptographic function.

The USIM take the RAND and the K key and performs the same cryptographic function the HSS did on it with the input of the K key and RAND value to generate it’s own result (RES).

The result of this same function (RES) is then sent from the USIM to the terminal which forwards it to the MME.

The MME and comparing the result the HSS generated (XRES) with the result the USIM generated. (RES)

If the two match it means both the USIM knows the K key, and is therefore the subscriber they’re claiming to be.

If the two do not match the UE is refused access to the network.

Next up, how the UE authenticates the network.

LTE (4G) – USIM Basics

LTE, Mobile Networks, RF, RFCs & Standards, Security, SIM Cards, , , , , , , ,

I’ve been working on private LTE recently, and one of the first barriers you’ll hit will be authentication.

LTE doesn’t allow you to just use any SIM to authenticate to the network, but instead relies on mutual authentication of the UE and the network, so the Network knows it’s talking to the right UE and the UE knows it’s talking to the right network.

So because of this, you have to have full control over the SIM and the network. So let’s take a bit of a dive into USIMs.

So it’s a SIM card right?

As a bit of background; the ever shrinking card we all know as a SIM is a “Universal integrated circuit card” – a microcontroller with it’s own OS that generally has the ability to run Java applets.

One of the Java applets on the card / microcontroller will be the software stack for a SIM, used in GSM networks to authenticate the subscriber.

For UMTS and LTE networks the card would have a USIM software stack allowing it to act as a USIM, the evolved version of the SIM.

Because it’s just software a single card can run both a USIM and SIM software stack, and most do.

As I’m building an LTE network we’ll just talk about the USIM side of things.

USIM’s role in Authentication

When you fire up your mobile handset the baseband module in it communicates with the USIM application on the card.

When it comes time to authenticate to the network, and authenticate the network itself, the baseband module sends the provided challenge information from the network to the USIM which does the crypto magic to generate responses to the authentication challenges issued by the network, and the USIM issues it’s own challenges to the network.

The Baseband module provides the ingredients, but the USIM uses it’s secret recipe / ingredients combo, known only to the USIM and HSS, to perform the authentication.

Because the card challenges the network it means we’ve got mutual authentication of the network.

This prevents anyone from setting up their own radio network from going all Lionel Ritche and saying “Hello, is it me you’re looking for” and having all the UEs attach to the malicious network. (Something that could be done on GSM).

It’s worth noting too that because the USIM handles all this the baseband module, and therefore the mobile handset itself, doesn’t know any of the secret sauce used to negotiate with the network. It just gets the challenge and forwards the ingredients down to the USIM which spits back the correct response to send, without sharing the magic recipe.

This also means operators can implement their own Crypto functions for f and g, so long as the HSS and the USIM know how to generate the RES and AUTN results, it’ll work.

What’s Inside?

Let’s take a look at the information that’s stored on your USIM:

All the GSM stuff for legacy SIM application

Generally USIMs also have the ability to operate as SIMs in a GSM network, after all it’s just a different software stack. We won’t touch on GSM SIMs here.

ICCID

Because a USIM is just an application running on a Universal Integrated Circuit Card, it’s got a ICCID or Universal Integrated Circuit Card ID. Generally this is the long barcode / string of numbers printed on the card itself.

The network generally doesn’t care about this value, but operators may use it for logistics like shipping out cards.

PIN & PUK

PINs and PUKs are codes to unlock the card. If you get the PIN wrong too many times you need the longer PUK to unlock it.

These fields can be written to (when authenticated to the card) but not read directly, only challenged. (You can try a PIN, but you can’t see what it’s set too).

As we mentioned before the terminal will ask the card if that’s correct, but the terminal doesn’t know the PIN either.

IMSI

Each subscriber has an IMSI, an International Mobile Subscriber Identity.

IMSIs are hierarchical, starting with 3 digit Mobile Country Code MCC, then the Mobile Network Code (MNC) (2/3 digits) and finally a Mobile Subscription Identification Number (MSIN), a unique number allocated by the operator to the subscribers in their network.

This means although two subscribers could theoretically have the same MSIN they wouldn’t share the same MNC and MCC so the ISMI would still be unique.

The IMSI never changes, unless the subscriber changes operators when they’ll be issued a new USIM card by the new operator, with a different IMSI (differing MNC).

The MSIN isn’t the same as the phone number / MSISDN Number, but an IMSI generally has a MSISDN associated with it by the network. This allows you to port / change MSISDN numbers without changing the USIM/SIM.

K – Subscriber Key

Subscriber’s secret key known only to the Subscriber and the Authentication Center (AuC/ HSS).

All the authentication rests on the principle that this one single secret key (K) known only to the USIM and the AuC/HHS.

OP – Operator Code

Operator Code – same for all SIMs from a single operator.

Used in combination with K as an input for some authentication / authorisation crypto generation.

Because the Operator Code is common to all subscribers in the network, if this key were to be recovered it could lead to security issues, so instead OPc is generally used.

OPc – Operator Code (Derived)

Instead of giving each USIM the Operator Code a derived operator code can be precomputed when the USIM is written with the K key.

This means the OP is not stored on the USIM.

OPc=Encypt-Algo(OP,Key)

PLMN (Public Land Mobile Network)

The PLMN is the combination of MCC & MNC that identifies the operator’s radio access network (RAN) from other operators.

While there isn’t a specific PLMN field in most USIMs it’s worth understanding as several fields require a PLMN.

HPLMNwAcT (HPLMN selector with Access Technology)

Contains in order of priority, the Home-PLMN codes with the access technology specified.

This allows the USIM to work out which PLMN to attach to and which access technology (RAN), for example if the operator’s PLMN was 50599 we could have:

  • 50599 E-UTRAN
  • 50599 UTRAN

To try 4G and if that fails use 3G.

In situations where operators might partner to share networks in different areas, this could be set to the PLMN of the operator first, then it’s partnered operator second.

OPLMNwACT (Operator controlled PLMN selector with Access
Technology)

This is a list of PLMNs the operator has a roaming agreement with in order of priority and with the access technology.

An operator may roam to Carrier X but only permit UTRAN access, not E-TRAN.

FEHPLMN (Equivalent HPLMN)

Used to define equivalent HPMNs, for example if two carriers merge and still have two PLMNs.

FPLMN (Forbidden PLMN list)

A list of PLMNs the subscriber is not permitted to roam to.

HPPLMN (Higher Priority PLMN search period)

How long in seconds to spend between each PLMN/Access Technology in HPLMNwAcT list.

ACC (Access Control Class)

The ACC allows values from 0-15, and determines the access control class of the subscriber.

In the UK the ACC values is used to restrict civilian access to cell phone networks during emergencies.

Ordinary subscribers have ACC numbers in the range 0 – 9. Higher priority users are allocated numbers 12-14.

During an emergency, some or all access classes in the range 0 – 9 are disabled.

This means service would be could be cut off to the public who have ACC value of 0-9, but those like first responders and emergency services would have a higher ACC value and the network would allow them to attach.

AD (Administrative Data)

Like the ACC field the AD field allows operators to drive test networks without valid paying subscribers attaching to the network.

The defined levels are:

  • ’00’ normal operation.
  • ’80’ type approval operations.
  • ’01’ normal operation + specific facilities.
  • ’81’ type approval operations + specific facilities.
  • ’02’ maintenance (off line).
  • ’04’ cell test operation.

GID 1 / 2 – Group Identifier

Two group identifier fields that allow the operator to identify a group of USIMs for a particular application.

SPN (Service Provider Name)

The SPN is an optional field containing the human-readable name of the network.

The SPN allows MVNOs to provide their own USIMs with their name as the operator on the handset.

ECC (Emergency Call Codes)

Codes up to 6 digits long the subscriber is allowed to dial from home screen / in emergency / while not authenticated etc.

MSISDN

Mobile Station International Subscriber Directory Number. The E.164 formatted phone number of the subscriber.

This is optional, as porting may overwrite this, so it doesn’t always match up.

References:

https://www.etsi.org/deliver/etsi_ts/131100_131199/131102/12.05.00_60/ts_131102v120500p.pdf

IMTx: NET02x (4G Network Essentials) – Mobility Management – 3. Processing Location Updates

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.

Let’s look at how the Tracking Area Updates work from the point of view of the network.

Let’s take an example of a UE which has been sent the Tracking Area List TA0 and TA1, which is currently in ECM_IDLE state served by eNBs in Tracking Area 1.

The UE is moving towards another eNB in Tracking Area 2. As the UE listens on the Broadcast Channel the power of the new eNB overtakes that of the previous eNB, but the UE notes the Tracking Area of the new eNB, which is not on the UE’s Tracking Area List.

So the UE must make a Tracking Area Update to inform the network.

The first thing to do is to establish a radio connection.

Once the radio connection is setup a S1-AP connection is setup, upon which an NAS message – EMM Tracking Area Update Request is sent which contains the GUIT and old Tracking Area ID, which is sent to the MME.

The MME then sends back a new Tracking Area List for the UE and new TMSI to update the GUTI of the subscriber.

The UE updates it’s GUTI, updates it’s Tracking Area List, sends an EMM TRACKING AREA UPDATE COMPLETE and the UE returns to ECM_IDLE state.

Further Reading

IMTx: NET02x (4G Network Essentials) – Mobility Management – 1. Managing Location

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 saw with the Network Triggered Service Request, the network needs to know which eNB / cell the UE is currently being served by.

The UE knows which cell it should use as it’s always listening on the broadcast channel to know the received power levels of the nearby eNBs.

Paging

If our UE is in ECM IDLE state and the network needs to contact the UE, the eNB sends sends a Paging Request on the Beacon (Broadcast) Channel with the UE’s RNTI.

The UE is always listening on the Beacon Channel for it’s own RNTI, and when it hears it’s own RNTI it follows the process to come back from ECM_IDLE state to ECM_CONNECTED state.

For this to work the network needs to know which eNB to send the Paging request to.

For this to work our UE would need to inform the network each time it changes eNB, but, as we’ve touched upon several times, minimizing power consumption is a constant architecture constraint in LTE.

So if the UE has to transmit each time a UE moves to a different eNB / Cell, the UE power consumption would be high and the battery life of the UE would be low.

If we imagine driving along a freeway at speed, with each eNB serving an area of 1km, at 60kph, our UE would change cells every minute, and if the UE needs to transmit to let the network know it’s changing location, we’d be transmitting data every 60 seconds even if the UE is sitting in our pocket, all these transmissions would lead to lower battery life on the UE.

Tracking Areas

To work around the power wastage of each UE transmitting data to the network to let it know each time it changes eNB, 3GPP designers decided to group eNBs in the same geographic area into Tracking Areas or TAs.

This means instead of the network knowing exactly which eNB a UE is located in, it has it’s location down to a tracking area made up of several eNBs. (Tens to hundreds of cells per TA)

To go back to our freeway example, we might group all the eNBs along a freeway into one Tracking Area, all of which broadcast the ID of each eNB and the Tracking Area of each eNB.

As the UE moves from one eNB to another eNB in the same Tracking Area, there’s no need for the UE to send a Tracking Area Update message as it’s reamining in the same Tracking Area.

Tracking Area Update messages only need to be sent when the UE moves to an eNB in a different Tracking Area.

UEs can move from cell to cell inside TA1 without needing to update the network.
Only when a UE moves from a eNB / cell in TA1 to TA2, does it need to send a Tracking Area Update message to the network.

Paging a Tracking Area

As the network knows the location of our UE down to a tracking area, when it comes time to Page a UE a Paging Request is simply sent from the MME to all eNBs in the Tracking Area that the UE is in.

This means the RNTI of the UE is broadcast out of all eNBs in that tracking Area, and the UE establishes connectivity once again with it’s nearest eNB.

IMTx: NET02x (4G Network Essentials) – Management of Sporadic Data Flows – 4. UE Triggered Service Request

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 just saw when a terminal moves to ECC-Idle while in EMM-Registered state, it releases it’s radio resources, so what happens when the UE needs to send / receive data again?

UE is disconnected from Radio Resources (ECM-Idle & EMM Registered)

While one option could have been to go through the full attach procedure again when the UE is triggered, the 3GPP team wanted the re-connection process to be as fast as possible.

As we saw in the last post we don’t drop the S-GW <-> P-GW tunnel, which saves time on re-establishing a connection. The S1 tunnel is also not completely released; the TEID value from the S-GW end of the tunnel is saved by the MME so it can be reused by the new tunnel when the UE reconnects, without needing to inform the S-GW.

IMTx: NET02x (4G Network Essentials) – Management of Sporadic Data Flows – 2. UE Connection to the Network

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.

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.

IMTx: NET02x (4G Network Essentials) – Management of Sporadic Data Flows – 1. Attach and Detach Procedures

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.

A LTE UE has permanent IP connectivity for as long as it is connected.

As soon as the UE powers up it requests the establishment of one or more bearers for it’s IP connectivity through GTP tunnels.

An EPS Connectivity Request message is sent by the UE.

The network needs to know if a UE can be reached or not, so the network must store state for each terminal,

EPS Session Management (ESM) manages EPS bearer contexts.

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.

IMTx: NET02x (4G Network Essentials) – Management of Data Flows – 7. NAS and Global View of Protocol Stack

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 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.

Transport of S1 messages is carried over SCTP which I’ve spoken about in the past.

The above image overlaps with the radio version we talked about earlier.

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