EMM Procedure

Initial Attach-Cases of Initial Attach

Cases of Initial Attach

Unknown UE Known UE

When a UE initially attaches to a network, an MME initiates a different procedure depending on the type of such attach. The procedure begins when a user sends an Attach Request message to an MME, and ends when the MME returns an Attach Accept message tothe UE. When the UE sends the MME the Attach Request (UE ID), it includes its UE ID (IMSI or Old GUTI3) in the message to identifyitself. When the MME sends the Attach Accept (GUTI and TAI list) message, it includes a GUTI, an ID that the UE can use instead ofIMSI, and a TAI list4 that contains the areas the UE is allowed to enter without TAU updates. An MME may go through some or all of the following procedures after receiving an Attach Request message from a UE and before sending an Attach Accept message back to the UE.-> UE ID acquisition-> Authentication->NAS security setup->Location update-> EPS session establishmentDecisions on which procedure to perform are made based on the types of initial attach attempted by a UE. But, both UE ID acquisition and EPS session establishment procedures are requiredin all types of initial attach. Other procedures like authentication, NAS security setup and location update are performed selectively depending on the type of initial attach. The procedure selection is affected by i) what UE ID the UE has (IMSI or Old GUTI), ii) whether or not the Last Attach Information is still kept valid in the network (MME), etc. In this document, we will use the following criteria to distinguish different types of initial attach, as seen in Figure 1:With which UE ID is the UE making a request for initial attach? (IMSI or Old GUTI?)

To which MME is the UE trying to attach? (the one it has attachedlast time5 or new one it has never attached before?)Does the valid Last UE Context exist in the network? (Yes or No?)

In the document, UEs are defined as “unknown UEs” if their Last UE Context, including UE IDs, does not exist in the network (MME), and others are defined as “known UEs”. Below, we will assume Attach Request messages are sent integrity-protected if the UE has the Last Attach Information

Unknown UEIn the cases of initial attach where a user (UE) sends an Attach Request message to a network, and the network (MME) does not haveany valid UE context about the user (UE). We will distinguish thetypes of initial attach, and explain the characteristics of each type for comparison (EPS session establishment procedure is common, and thus will not be discussed here). An MME to which theUE is trying to attach now will be called “New MME” and the one the UE has attached to last time will be called “Old MME”..

Attach Case 1: When a UE is attaching using an IMSIThis is when neither user (UE) nor network (MME) has the Last UE Context, as in EMM Case 1 to be explained in Part 2. A scenario required for this case is as follows:A UE sends an MME an Attach Request message using its IMSI as a UE ID. The MME obtains the IMSI from the message.The MME, assuming it doesn’t know the UE (because an IMSI was sent), initiates procedures for authentication and NAS security setup.

The MME sends a location update message to HSS, informing the HSSthat the UE is registered with it, and downloads the subscriptioninformation of the user from the HSS.

Attach Case 2: When a UE is attaching to the MME that it has attached to last time (New MME = Old MME), but the MME doesn’t have the valid Last UE Context of the UE

This is when a UE, still having the Last Attach Information (Old GUTI and NAS security context6) even after its last detach, is trying to attach to the same MME, but the MME doesn’t have any valid UE context of the UE. An exemplary scenario can be as follows:A UE sends New MME an Attach Request message, using its Old GUTI.At this time, the Attach Request message is sent integrity-protected by a NAS integrity key (KNASint) (i.e. by including NAS-MAC).As a GUTI includes a GUMMEI, an MME ID, the New MME knows from the Old GUTI that the Old GUTI was assigned by itself. The New MME looks up the Last UE Context, but fails to find any (e.g. dueto failed integrity validation or no Old GUTI).The MME sends the UE an Identity Request message, requesting an IMSI.The UE sends the MME an Identity Response message, providing the requested IMSI.Now, the MME performs the procedures for authentication and NAS security setup by using the obtained IMSI as in Attach Case 1, then sends the UE’s location update message to HSS.

Attach Case 3: When a UE is attaching to a new MME that it has never attached to before (New MME ≠ Old MME), and the MME doesn’thave the valid Last UE Context of the UE

This is when a UE, still having the Last Attach Information even after its last detach, is attaching to a new MME (New MME), not to the Old MME, but the Old MME doesn’t have the valid UE contextrelating to the UE, either. An exemplary scenario can be as follows:

A UE sends New MME an Attach Request message using its Old GUTI as a UE ID. At this time, the Attach Request message is sent integrity-protected.When the New MME receives the message, it knows from the Old GUTIthat it was assigned by other MME (Old MME).Then, the New MME sends the Old MME an Identification Request (Old GUTI, Complete Attach Request Message), forwarding the Old GUTI and Attach Request message it received from the UE. By doingso, the New MME requests the Last UE Context related to the Old GUTI.Upon receiving the message, the Old MME looks up the UE context, but fails to find any (e.g. due to failed integrity validation orno Old GUTI).The Old MME then sends the New MME an Identification Response (error cause) message, informing that no UE context was found.From here, things are the same as in Attach Case 2, and thus Steps 3), 4) and 5) in Attach Case 2 are performed. The New MME sends the UE an Identity Request message, requesting an IMSI. TheUE then sends its IMSI to the MME through an Identity Response message. With the received IMSI, the MME performs procedures for authentication and NAS security setup, and has the UE’s location updated.

Known UE

This depicts a case of initial attach where a user (UE) attaches to a network by sending an Attach Request message, and the network (MME) has the valid UE context for the user. Unlike unknown UEs, all known UEs are assumed to use a GUTI, not IMSI, for their initial attach. In Figure 3, both the UE and the MME have the Last UE Context relating to the user, and the UE sends an Attach Request message with its integrity protected.

Attach Case 4: When a UE is attaching to the MME that it has attached last time (New MME = Old MME), and the MME has the validLast UE Context of the UE

This is when a UE, still having the Last Attach Information (Old GUTI, NAS security context), attaches to the MME that it has

attached to last time, and the MME has the valid UE context for the UE. An exemplary scenario can be as follows:A UE sends New MME an Attach Request message using its Old GUTI as a UE ID. At this time, the Attach Request message is sent integrity-protected with a NAS integrity key (KNASint) (i.e. by including NAS-MAC).The New MME knows from the received Old GUTI that it was assignedby itself. Then, it looks up the Old GUTI, and finds the valid UEcontext of the UE (IMSI, MM Context (NAS security context, UE-AMBR)).The MME conducts an integrity check on the Attach Request message.If the integrity check on NAS-MAC fails, the MME must authenticate the user by using an IMSI instead, and perform NAS security setup procedure for the user.If it passes, the MME may skip the procedures for authentication and NAS security setup.

Attach Case 5: When a UE is attaching to a new MME that it has not attached to before (New MME ≠ Old MME), and the Old MME has the valid Last UE Context of the UE

This is when a UE, still having the Last Attach Information, attaches to a new MME (New MME), and the Old MME has the valid UEcontext of the UE. An exemplary scenario can be as follows: A UE sends New MME an Attach Request message using its Old GUTI as a UE ID. At this time, the Attach Request message is sent integrity-protected.The New MME knows from the received Old GUTI that it was assignedother MME (Old MME).Then, the New MME sends the Old MME an Identification Request (Old GUTI, complete Attach Request message), forwarding the Old GUTI and Attach Request message it received from the UE. By doingso, the New MME requests the Last UE Context related to the Old GUTI.Upon receiving the message, the Old MME looks up the UE context, and finds the IMSI and MM context (NAS security context, UE-AMBR)related to the UE.The Old MME conducts an integrity check on the Attach Request message.

Then, it delivers the check result to the New MME through an Identification Response message.If the integrity check fails, the Old MME delivers the message with error causes.If it passes, the UE context (IMSI, Old GUTI and MM context) is delivered.If the integrity check fails, things are the same as in Attach Case 3, and hence the same procedures of IMSI acquisition, authentication and NAS security setup are performed as in Attach Case 3. If the check passes, the New MME receives the IMSI and MMcontext from the Old MME, and the procedures for authentication and NAS security setup may be skipped, as in Attach Case 4. The only difference from Attach Case 4 is that since the UE is attached to a new MME, the New MME communicates with the HSS to have the UE’s location updated.

Simplified Call Flow in Each Case

UE ID AcquisitionThe network (MME) acquires a UE ID for user identification and authentication. Here, the UE ID can be an IMSI or Old GUTI. An IMSI can be acquired from a UE through Attach Request or IdentityResponse messages while an Old GUTI can be obtained from a UE through an Attach Request message. AuthenticationIf the network (MME) has acquired i) an IMSi or ii) Old GUTI as the UE’s ID through an Attach Request message, but the integrity check on the message fails, the network checks whether the user is permitted to attach or not by performing the EPS-AKA procedure. The HSS derives KASME, the MME base key, by generatingauthentication vectors and sending them to the MME, which then performs mutual authentication with the UE, on behalf of the HSS.7 NAS Security SetupOnce user authentication is completed, NAS security keys for secured delivery of NAS messages between the UE and MME are generated.8

Location UpdateThe MME downloads user information from the HSS, and the HSS updates the information about the UE’s current location (MME). The MME will perform location updates only when i) the UE sends an IMSI as its UE ID, ii) the MME doesn’t have the valid Last UE Context of the UE, iii) the MME doesn’t have any valid subscription information about the user, or iv) the UE was detached from other MME last time. EPS Session EstablishmentAn EPS session and a default EPS bearer are established.

Initial Attach with IMSI

Attach Case 1: Unknown UEThe UE requests for initial attach using its IMSI, and the MME acquires the user’s IMSI from the Attach Request message.[UE → MME] Attach Request (IMSI)

If the UE uses its IMSI when requesting for initial attach, the MME performs procedures for authentication, NAS security setup and location update, and establishes an EPS session/default EPS bearer.

Initial Attach with GUTI

Attach Case 2: Unknown UE, MME Unchanged

The UE requests for initial attach using its Old GUTI, but the MME doesn’t have the Old GUTI. So, the MME requests the UE for a UE ID, and acquires an IMSI.[UE → MME] Attach Request (Old GUTI)[MME] No IMSI[UE ← MME] Identity Request (UE ID = IMSI)[UE → MME] Identity Response (IMSI)The rest of the procedure is the same as in Attach Case 1. That is, the MME performs procedures for authentication, NAS security setup and location update, and establishes an EPS session/defaultEPS bearer.

Attach Case 3: Unknown UE, MME Changed

The UE requests for initial attach using its Old GUTI. So, the MME (New MME) asks the Old MME for the Last UE Context relating to the UE, but fails to receive any. So, the MME requests the UE for a UE ID, and acquires an IMSI.[UE → New MME] Attach Request (Old GUTI)[New MME → Old MME] Identification Request (Old GUTI)[Old MME] No IMSI[New MME ← Old MME] Identification Response (error cause)[UE ← New MME] Identity Request (UE ID = IMSI)[UE → New MME] Identity Response (IMSI)The rest of the procedure is the same as in Attach Case 1. That is, the MME performs procedures for authentication, NAS security setup and location update, and establishes an EPS session/defaultEPS bearer.

Attach Case 4: Known UE, MME Unchanged

The UE requests for initial attach using its Old GUTI, and the MME has the Last UE Context relating to the Old GUTI. So, no further step for acquiring an IMSI is required.[UE → MME] Attach Request (Old GUTI)[MME] IMSI, Old GUTI, MM ContextIf the integrity check on NAS-MAC passes, the MME may immediatelyestablish an EPS session/default EPS bearer without performing the procedures for authentication, NAS security setup and location update.9

Attach Case 5: Known UE, MME Changed

The UE requests for initial attach using its Old GUTI. So, the MME (New MME) asks the Old MME for the Last UE Context relating to the UE, and acquires the UE’s IMSI and MM context.[UE → New MME] Attach Request (Old GUTI)[New MME → Old MME] Identification Request (Old GUTI)[Old MME] IMSI, Old GUTI, MM Context[New MME ← Old MME] Identification Response (IMSI, Old GUTI, MM Context)If the Old MME’s integrity check on NAS-MAC passes, the New MME receives the IMSI and MM context, and thus doesn’t perform procedures for authentication and NAS security setup. However, since the MME is changed, the New MME communicates with the HSS to have the UE’s location updated, and then establishes an EPS session/default EPS bearer.10 The HSS updates the UE’s location from the Old MME to the New MME, and sends a Cancel Location message to the Old MME so that the MM context of the UE is deleted from the Old MME.

Initial Attach Procedure

IMSI Acquisition

Figure below shows the first step in the procedures. By the end of this first step, the MME obtains an IMSI from the UE. The UE attempts to initially attach to the network by sending an Attach Request message, with its IMSI in it, and the MME obtains the IMSI from the message. For the purpose of explanation, this step can be further divided into two sub-steps: the UE stays in the❶initial state after radio link synchronization, and the UE ❷establishes ECM connection for delivering an Attach Request message to the MME. The ECM connection establishment phase can befurther divided into two sub-phases: (1) RRC connection establishment, and (2) S1 signaling connection establishment.

❶ Initial State after Radio Link SynchronizationIn order for a UE to request initial attach to a network, communication with an eNB is essential. So, the UE selects an eNB (cell) through PLMN selection and cell search procedures, and has the radio link synchronized(PLMN selection and cell search procedures are out of the scope of this document, and thus will not be covered here). Then, the user can communicate with the eNB. At this time, the UE is in EMM-Deregistered, ECM-Idle, and RRC-Idle state. ❷ ECM Connection EstablishmentOn NAS layer, the UE sends an Attach Request (including IMSI and UE Network Capability) message to request initial attach to the NAS layer ofthe MME.In order for the Attach Request message to be delivered, ECM connection is required between the UE and the MME. And for the ECM connection, RRC connection between the UE and the eNB, and S1 signaling connection between the eNB and the MME are required. NAS messages are sent as RRC

messages (RRC Connection Setup Complete message) when passing through theRRC connection, and then as S1AP messages (Initial UE Message) through the S1 signaling connection.

 (1) RRC Connection Establishment  An RRC connection is established between the RRC layers of the UE and the eNB. Once established, the connection is used when delivering messages to the RRC layers or their upper layers, NAS layers, in the control plane. The procedure for establishing an RRC connection is as follows: 

1) [UE → eNB] RRC Connection RequestAn UE requests an RRC connection by sending an RRC Connection Request (Establishment Cause=“Mobile Originating Signaling”) message to an eNB. The “Mobile Originating Signaling” is a value used in the Establishment Cause field when a UE requests Attach, Detach or TAU (Tracking Area Update). The message sent by the UE is delivered to the eNB through SRB 0, the SRB (Signaling Radio Bearer) used by all UEsin a cell, and CCCH (Common Control Channel), a logical channel.

 2) [UE ← eNB] RRC Connection SetupThe eNB allocates a SRB (SRB1) dedicated to the UE by sending the UE an RRC Connection Setup message, which is delivered through SRB 0 and CCCH. The uplink/downlink radio resources of the UE are controlled by the eNB. So, after completing this step, the UE can use the radio resources by using the SRB configuration allocated through the RRC Connection Setup message. Then it transits to EMM-Deregistered, ECM-Idle and RRC-Connected state.

 3) [UE → eNB] RRC Connection Setup CompleteThe UE notifies the eNB that the RRC connection setup is completed by sending it an RRC Connection Setup Complete message through SRB 1 and DCCH (Dedicated Control Channel). For efficient delivery, the Attach Request message1 that was delivered to the NAS layer is sent tothe eNB when delivering the RRC Connection Setup Complete message, as embedded in the Dedicated NAS Information field (DedicatedInfoNAS) of the RRC Connection Setup Complete message.

 

(2) S1 Signaling Connection EstablishmentControl messages between the eNB and the MME are sent over S1-MME interface as embedded in S1AP messages. S1AP messages are delivered through S1 signaling connections dedicatedly established for each user. The S1 signaling connections are defined by an ID pair (eNB UES1AP ID, MME UE S1AP ID) allocated by the eNB and the MME for identifying UEs.In Figure 2, an Attach Request message, the first NAS message, arrives at the eNB before S1 signaling connection is established. The eNB then allocates an eNB UE S1AP ID for establishment of S1 signaling connection, and sends the MME an Attach Request message, as embedded in an Initial UE Message. The Attach Request message is delivered as embedded in the NAS-PDU field of the Initial UE Message. The Initial UE Message consists of the following information elements: 

 When the MME receives the Initial UE Message from the eNB over S1-MME, it allocates an MME S1AP UE ID for the UE. Now with this newly allocated ID and the previously allocated eNB UE S1AP ID, S1 signaling connection between the two entities are established. The MME UE S1AP ID is used later when the MME identifies UEs over S1-MMEinterface (Downlink). (3) ECM S1 Connection EstablishmentThrough Steps (1) and (2) above, the ECM connection between the NAS layers of the UE and the MME is established. Then, the UE transits to EMM-Registered2, ECM-Connected and RRC-Connected state. (4) IMSI AcquisitionThe NAS layer of the MME acquires the IMSI of the UE from the AttachRequest message sent from the NAS layer of the UE, and finds out theUE’s security capability by learning what security algorithms the UEcan use from the UE’s network capability information. 

After collecting the UE’s IMSI and security capability information from the Attach Request (IMSI, UE Network Capability) message received from the UE, the MME performs the authentication and NAS security Setup procedures for secured delivery of NAS messages, by using the collected information, and in accordance with the EPS-AKA (Evolved Packet System-Authentication and Key Agreement).

Authentication

Authentication procedure between a UE and a network (MME) is described in Figure below. The procedure consists of thefollowing two steps: Step (1), authentication vector acquisition,during which the MME acquires authentication vectors from the HSSfor the UE, and Step (2), mutual authentication, during which theMME and the UE are mutually authenticated. Step (1) is performed over the S6a interface between the MME and the HSS using Diameterprotocol, while Step (2) is performed between the UE and the MME using a NAS protocol.

(1) Acquisition of Authentication Vectors1) [MME → HSS] Authentication Information RequestThe MME sends the HSS an Authentication Information Request message,requesting authentication vector(s) (AV) for the UE that has an

IMSI. At this time, it includes the UE’s SN ID (Serving Network ID) along with the IMSI in the message to make sure the HSS reflects theUE’s current serving network information (i.e. which operator’s network the UE is using) when generating authentication vectors for the UE. Main parameters in the Authentication Information Request message are: 

 2) [HSS] Generating Authentication VectorsThe HSS3 generates authentication vectors by using the LTE master key (LTE K) in the IMSI and the serving network ID (SN ID) of the UE. Authentication vectors are generated through the two steps as seen in Figure 4. First, the HSS generates SQN and RAND, and then inputs the values of {LTE K, SQN, RAND} in the crypto function to generate the values of {XRES, AUTN, CK, IK}. Next, it inputs the values of {SQN, SN ID, CK, IK} in the key derivation function to derive KASME.

(i) (XRES, AUTN, CK, IK) = Crypto Function (LTE K, SQN, RAND)(ii) KASME = KDF (SQN, SN ID, CK, IK)

 

Figure 4. Generating Authentication Vectors 

The final form of authentication vectors is {RAND, AUTN, XRES, KASME}, and the roles of each authentication vector element are as follows:

 

 (3) [MME ← HSS] Delivering Authentication VectorsThe HSS sends the authentication vectors, as included in the Authentication Information Response (AV4) message to the MME. The MME then uses this information to perform mutual authentication with the UE in Step (2).

 (2) Mutual AuthenticationLTE requires mutual authentication between a user and the network. So, a user must authenticate the network, and the network must authenticate theuser. Once the MME received authentication vectors {RAND, AUTN, XRES, KASME} from the HHS, it sends RAND and AUTN on to the UE so that the UE can generate authentication vectors, and authenticate the network. However, the MME keeps XRES and KASME to use for user authentication and NAS security key derivation, respectively. KASME is not passed on to the UE (but generated when the UE generates authentication vectors), but KSIASME, an index for KASME, is delivered to the UE, instead. Mutual authentication procedures between the UE and MME are as follows: 

4) [UE ← MME] Request by MME for User AuthenticationThe MME delivers the information (RAND, AUTN) required for the UE togenerate authentication vectors, and KSIASME, as included in the Authentication Request (RAND, AUTN, KSIASME) message to the UE.

 5) [UE] User’s Authenticating the Network: Generating AuthenticationVectors and Authenticating the NetworkAfter receiving the Authentication Request (RAND, AUTN, KSIASME) message from the MME, the UE first generates SQN from AUTN,

and then authentication vectors as the HSS did (in Figure 4). Next, the UE compares its own AUTN (AUTNUE) and the AUTN received from theMME (AUTNHSS) to authenticate the network, and stores KSIASME as an index of KASME.

 6) [UE → MME] Delivery of User RES to MMEAfter completing network authentication by comparing the AUTN values, the UE sends its own RES value to the MME, as included in the Authentication Response (RES) message, so that the MME can authenticate the user.

 7) [MME] Network’s Authenticating the UEUpon the receipt of the Authentication Response (RES) message from the UE, the MME compares the RES value generated by the UE and the XRES value it received from the HSS, to authenticate the user.

 Once the above steps are completed, the UE and the network (MME) are mutually authenticated. Now, the two begins the procedure for establishing NAS security setup for secured delivery of NAS messages. NAS Security Setup

Once user authentication is completed, the MME initiates the NAS security setup procedure so that NAS messages can be securely exchanged between the two entities. Figure 5 shows the call flowsin the NAS security setup procedure.

1) [MME] Generating NAS Security KeysThe MME selects ciphering and integrity algorithms to be applied to NAS messages from the Attach Request message received from the UE. Next, it

derives a NAS integrity key (KNASint) and a NAS encryption key (KNASenc) from KASME, to be applied to NAS messages. 2) [UE ← MME] Helping UE to Generate NAS Security KeysThe MME informs the UE of the selected security algorithms, by including them in a Security Mode Command (KSIASME, Security Algorithm, NAS-MAC) message, helping the UE to generate NAS security keys. The message is sent with its integrity-protected (by including NAS-MAC). 3) [UE] Generating NAS Security KeysWhen the UE receives the Security Mode Command message, the UE generates NAS security keys (KNASint and KNASenc) by using the NAS security algorithm that the MME selected, and performs an integrity validation on the Security Mode Command message by using the NAS integrity key (KNASint).If the message passes the integrity check, it can be seen that the NAS security keys are successfully set and properly working between the two entities. 4) [UE → MME] NAS Security Key Generation CompleteThe UE informs the MME of the successful generation of NAS security keys by sending a Security Mode Complete (NAS-MAC) message, after having it encrypted and integrity protected using the generated keys. After completing the above steps, the procedure for NAS security setup between the two entities ends. Then messages between the two thereafter are securely delivered, as encrypted and integrity-protected.

Location Update

Once the procedures for authentication and NAS security setup arecompleted, now the MME has to register the subscriber in the network, and find out what services the subscriber can use. To this end, the MME notifies the HSS the subscriber is registered in the network and located in its TAs, and then downloads information about the subscriber from the HSS. All these are donethrough the location update procedure, and by using Diameter protocol over the S6a interface between the MME and the HSS.

1) [MME → HSS] Notifying UE LocationThe MME sends an Update Location Request (IMSI, MME ID) message to the HSS in order to notify of the UE’s registration and obtain the subscription information of the UE. 2) [HSS] UE Location UpdateThe HSS registers the MME ID to indicate in which MME the UE is located in. 3) [MME ← HSS] Delivering User Subscription InformationThe HSS sends the MME subscription information of the subscriber as included in an Update Location Answer message, so that the MME can createan EPS session and a default EPS bearer for the subscriber. The subscription information included in the Update Location Answer message is as follows: 

 4) [MME] Storing Subscription InformationThe MME receives the Update Location Answer message from the HSS, and stores the subscription information from the message. 

From the downloaded subscription information, the MME can check what services the user is subscribing to, and to which APN and with what QoS level the resources are to be allocated.

EPS Session Establishment

The MME, based on the subscription information, establishes an EPS session and a default EPS bearer for the user. By doing so, the MME allocates the network/radio resources for providing each user with satisfying QoS they are subscribing to.

1) [MME] Assigning EPS Bearer IDThe MME selects a value from 5~15, and allocates it as an EPS Bearer ID (EBI) in order to establish a default EPS bearer for the newly attached user. 2) [MME] Selecting P-GWThe MME checks the APN received from the HSS, and decides to which P-GW to connect to access the APN. This decision can be made based on the subscription information received from the HSS (specifically, P-GW ID). Or if there is no such information, the MME queries the DNS server for APN FQDN (e.g. internet.apn.epc.mnc05.mcc450.3gppnetwork.org), and selects one from the returned P-GW IP address list in accordance with itsP-GW selection policies6. At this time, it also chooses which S-GW to go through to get the selected P-GW. ◇ 3) ~ 4) Request for EPS Session CreationThe MME requests creation of an EPS session and a default EPS bearer by sending a Create Session Request message to the P-GW selected in Step 2) above. Here, the MME includes the subscription information it received from the HSS in the message, so that the P-GW can use it when requesting PCRF for EPS session creation. At this time, UE-AMBR is not included as it is to be determined by the MME. 3) [MME → S-GW] Request for EPS Session CreationThe MME and the S-GW communicate over S11 interface in the control plane using GTP protocol (GTP-C)7. The MME sends the S-GW selected in Step 2) a Create Session Request message, with the following parameters:

 

 4) [S-GW → P-GW] Request for EPS Session CreationThe S-GW and the P-GW communicate over S5 interface in the user and control planes using GTP protocol (UP: GTP-U, CP: GTP-C). The S-GW

allocates a downlink S5 TEID (S5 S-GW TEID) to establish S5 GTP to the P-GW indicated in the received Create Session Request message. Then, it sends the ID along with other parameters, as included in the Create Session Request message, to the P-GW. 

 5) [S5 Bearer: Downlink]Once Step 4) is completed, the downlink S5 GTP-U tunnel is created, allowing the P-GW to send downlink traffic to the S-GW. In Figures 7 and 8, the entity that allocates and sends a GTP tunnel TEID is marked as “fill” (●), and the one that receives it is marked as “empty” (○). 6) [P-GW] Allocating User IP AddressThe P-GW, upon receiving the Create Session Request message, realizes theuser is attempting to access the network again with IMSI. So, it allocates an IP address to the UE so that the UE can use it when using APN. 7) [P-GW → PCRF] Notifying of EPS Session SetupThe P-GW and the PCRF communicate over Gx interface using Diameter protocol. When creating an EPS session for a user, resources allocation and QoS control for the user must be determined based on the services that the user is subscribing to. It is PCRF that is in charge of controlling policies concerning all the users who accessed to the network. So, the P-GW provides the PCRF with subscription information about the user, and obtains the PCRF’s authorization for resources allocation in accordance with the network operator’s policies. From the UE’s subscription information received from the MME, the P-GW gathers information required for the PCRF’s decision-making on the operator’s policies, and sends it to the PCRF through a CCR (CC-Request) message. Anexample of the message is as follows:

 

8) [PCRF → SPR] Requesting Access ProfilesThe PCRF requests the SPR for the user’s access profile to determine PCC policies for the user. 9) [PCRF ← SPR] Returning Access ProfilesThe SPR returns an access profile for the user. The profile may include information such as SDF Filter, QCI, ARP, APN-AMBR (UL/DL), Charging Method (e.g. Offline), Changing Reporting Action (e.g. Start Reporting ECGI, TAI), etc. 10) [PCRF] Determining PoliciesThe PCRF determines PCC policies for the EPS session to be established based on the user access profile. 11) [P-GW ← PCRF] Acknowledging EPS Session EstablishmentThe PCRF delivers the PCC policies determined in Step 10) to the P-GW, asincluded in a CCA (CC-Answer) message. An example of the message is as follows: 

 12) [P-GW] Policy Enforcement The P-GW applies the PCC policies received from the PCRF. As the PCC policies are applied to each SDF, the P-GW sets up mapping between SDFs and the EPS bearer, and prepares a QoS profile to be applied to the default EPS bearer (see our technical document, “LTE QoS: SDF and EPS Bearer QoS”[5] for more information). ◇ 13) ~ 15) EPS Session Creation Response

The P-GW informs the MME of the QoS information applied to the established EPS sessions and default EPS bearer, by sending it in a Create Session Response message. The PCRF may decide to keep the value the MME received from the HSS, or select a new value. 13) [S-GW ← P-GW] EPS Session Creation ResponseThe P-GW allocates an uplink S5 TEID (S5 P-GW TEID) for establishing S5 GTP to the S-GW. It then includes the S5 P-GW TEID and the QoS profile tobe applied to the default EPS bearer (S5 bearer) in the Create Session Response message, and sends it to the S-GW as a response to the Create Session Request message received in Step 4). 

14) [S5 Bearer: Uplink] S5 Bearer EstablishedCompleting Step 13) establishes the uplink S5 GTP-U tunnel, allowing the S-GW to exchange uplink/downlink traffic with the P-GW. 15) [MME ← S-GW] EPS Session Creation ResponseWhen receiving the Create Session Response message from the P-GW, the S-GW keeps the uplink S5 TEID (S5 P-GW TEID) to be used for uplink traffic,and allocates an uplink S1 TEID (S1 S-GW TEID) of S1 GTP tunnel to be used for S1 bearer. After processing the message, the S-GW adds the newlyallocated S1 S-GW TEID to the processed message, and sends it to the MME as a response to the Create Session Request message it received in Step 3). 16) [MME] Why MME Keeps S5 P-GW TEID?Once attached to a network, if a UE performs a TAU or handover, its S-GW may be changed. For this reason, the MME informs the UE’s new S-GW of theuplink S5 TEID so that the new S-GW can deliver uplink traffic to the P-GW. 17) [S1 Bearer: Uplink]Completing Step 15) establishes the uplink S1 GTP-U tunnel. However, since the eNB does not have this value (S1 S-GW TEID) yet, it cannot deliver uplink traffic to the S-GW at this time.  18) [MME] Calculating UE-AMBRNow, the MME returns an Attach Accept message to the UE as a response to the Attach Request message, and prepares for E-RAB setup (i.e. for

allocating resources to radio link and S1 bearer) by controlling the eNB.For this, the MME calculates the UE-AMBR value to send to the eNB. The MME has already received the UE-AMBR value, as included in subscription information, from the HSS in Section 2.4 above. However, it can adjust the value to the extent not exceeding the total APN-AMBR of each APN, andallocates it instead.

 

19) Determining Information needed for E-RAB and NAS SignalingBy receiving the Create Session Response message from the P-GW, the MME learns resources have been approved and allocated to the user. Then, it

becomes in charge of E-RAB (DRB+S1 bearer) setup, and controls the eNB and the S-GW. To this end, it determines the resources required for E-RABsetup and the information needed for NAS signaling (Attach Accept) as follows: 

Allocating a GUTI that the UE can use instead of the IMSI Determining parameters related to controlling TAU (TAI list allocation,

TAU Timer value) Determining UE-AMBR for the eNB’s use Allocating an E-RAB ID

20) [UE ← MME] Attach AcceptThe MME includes information, such as the UE IP address allocated by the P-GW, the GUTI, TAI list, EPS Bearer ID, UE-AMBR values allocated by itself, and QoS parameters received from the S-GW, in the Attach Accept message8, and sends it to the UE as a response to the Attach Request message received in Section 2.1.This message is delivered as included in the Initial Context Setup Request message through the S1 signaling connection, and then in the RRC Connection Reconfiguration message through the RRC connection.

 21) [MME] Creating KeNB

The MME creates KeNB, the AS security base key, from KASME. This is to ensure the eNB can generate AS security keys to be used for secured communication between the eNB and the UE over radio link (i.e. for AS security setup). 22) [eNB ← MME] Requesting E-RAB SetupThe MME sends an Initial Context Setup Request message so that the eNB can establish S1 bearer with the S-GW, and DRB with the UE. The Initial Context Setup Request message consists of the following information elements: 

 23) [S1 Bearer: Uplink]Once Step 22) is completed, and the S1 S-GW TEID is obtained, the eNB candeliver uplink traffic to the S-GW. When the eNB receives the MME’s Initial Context Setup Request message that requests E-RAB setup, it sets up DRB by sending an Attach Accept message to the UE. Then, it completes S1 bearer setup by includinga downlink S1 TEID in the Initial Context Setup Response message, and sending the message as a response to the Initial Context Setup Request message to the MME, so that the MME can forward it to the S-GW. ◇ 24) ~ 27) AS Security SetupUpon receiving the MME’s Initial Context Setup Request message, the eNB attempts to communicate with the UE to set up DRB. To ensure secured communication over the radio link, the eNB performs the procedure for AS security setup before sending messages to the UE (see our technical document, “LTE Security II: NAS and AS Security” [3] for more information).

 24) [eNB] Generating AS Security KeysThe eNB generates AS security keys from KeNB received from the MME for safe delivery of RRC messages and user traffic to/from the UE. The eNB selects ciphering and integrity algorithms for RRC messages from the security algorithms that the MME forwarded for the UE, and ciphering algorithms for user traffic. Next, from KeNB, it derives KRRCint/KRRCenc, RRC integrity/ciphering keys, and KUPenc, a key for ciphering user traffic.

 25) [UE ← eNB] Helping UE to Generate AS Security Keys

The eNB helps the UE to generate AS security keys (KRRCint, KRRCenc and KUPenc) by informing the UE of the AS security algorithms it selected (i.e. control plane RRC integrity/ciphering algorithm and user plane ciphering algorithm) through a Security Mode Command (AS Security Algorithm, MAC-I)message. The eNB sends this RRC message with its integrity-protected (by including MAC-I). 26) [UE] Generating AS Security KeysUpon receiving the Security Mode Command message from the eNB, the UE generates AS security keys using the AS security algorithm that the eNB selected, and performs integrity check on the Security Mode Command message. 27) [UE → eNB] AS Keys Generation CompleteOnce the integrity check on the Security Mode Command message is completed, AS security keys are successfully set up and ready to work between the UE and the eNB. The UE then indicates to the eNB that AS security keys are generated by sending a Security Mode Complete (MAC-I) message. The UE sends the message with its integrity-protected by using the RRC integrity key.

 As the AS security setup over the radio link is ended, RRC messages exchanged over the radio link thereafter are sent as encrypted and integrity-protected, and user traffic is delivered as encrypted. Now, theeNB begins DRB establishment. ◇ 28) ~ 29) DRB Establishment 28) [UE ← eNB] Reconfiguring RRC ConnectionThe eNB allocates uplink/downlink DRB IDs, and configures DRB QoS parameters from E-RAB QoS in order to establish DRB, an EPS bearer over the radio link. Thereafter, it sends a RRC Connection Reconfiguration message to the UE through the secured RRC connection. TheRRC connection was already established when the UE sent the Attach Request message. However, it must be reconfigured now that the UE needs to configure parameters according to the resources allocated by the network as a result of permission to access the network. The RRC layer ofthe UE allocates radio resources based on the configuration parameters gathered from the RRC Connection Reconfiguration message. Next, it extracts an Attach Accept message from the RRC Connection Reconfiguration message, and sends it to the NAS layer. 

When the NAS layer of the UE receives the message, it obtains the UE IP address and GUTI from the message, and uses them for future communication. 29) [DRB Establishment: Uplink and Downlink] DRB Establishment CompleteOnce Step 28) is completed, and the UE can deliver uplink/downlink traffic from/to the eNB. 39) [eNB → S-GW] E-RAB Setup ResponseThe eNB allocates a downlink S1 TEID (S1 eNB TEID) for S1 bearer. Then itincludes the allocated ID in an Initial Context Setup Response message, and sends it to the MME as a response to the Initial Context Setup Request message received in Step 22), so that the MME can forwards it to the S-GW. 31) [eNB] Allocating a Downlink TEID for S1 BearerOnce Step 29) is completed, a downlink TEID is allocated by the eNB to S1bearer, establishing the downlink S1 GTP-U tunnel. However, since the S-GW does not know about the establishment yet, it cannot delivery downlinktraffic to the eNB at this time. 32) [UE → MME] Sending Attach Complete MessageThe UE sends an Attach Complete message9 to the MME, as a response to themessage in Step 20). The Attach Complete message is delivered through an UL Information Transfer message over the RRC connection, and then through an Uplink NAS Transport message over the S1 signaling connection. 33) [UE][MME] EMM StateNow the UE and the MME stay in EMM-Registered state. If an Attach Reject message is sent from the MME to the UE in Step 20), the UE must release the ECM/RRC connection and transit to EMM-Deregistered state.  34) [MME → S-GW] Requesting S1 Bearer ModificationThe MME forwards the downlink S1 TEID (S1 eNB TEID) received from the eNBto the S-GW through a Modify Bearer Request message. 35) [MME ← S-GW] Responding to S1 Bearer Modification RequestThe S-GW sends the MME a Modify Bearer Response as a response to the Modify Bearer Request message. Now, the S-GW is ready to deliver downlink S1 traffic. 36) [S1 Bearer: Downlink] S1 Bearer Setup Complete

Step 35) completes the setup procedure for S1 bearer. With the establishment of S1 bearer, the eNB and the S-GW can exchange traffic with each other. Now, the default EPS bearer from the UE all the way to the P-GW is finally established, allowing uplink/downlink EPS bearer communication between the UE and the P-GW.

EPS Entity InformationHere we will look into changes in EMM information10 stored in EPSentities before and after the “EMM Case 1: Initial Attach by Unknown UE” procedure. For the purpose of description, all the information stored in each EPS entity will be grouped as UE ID information, UE Location information, Security Context information, and EPS Session/Bearer information

Before Initial Attach

Figure below what information is stored in each entity before the“EMM Case 1: Initial Attach by Unknown UE” procedure. As EMM Case1 involves initial attach by an unknown user, all the network hasis commissioning and provisioning information only.

UE ID information: A user’s IMSI is provisioned at UE, HSS and SPR. UE Location information: No information about UE location is registered

at UE or anywhere in the network. Security Context information: An LTE master key to be used for user

authentication is commissioned at UE and HSS. EPS Session/Bearer information: User subscription information (Default

APN, Subscribed QCI, ARP, UE-AMBR, APN-AMBR, etc.) and user access profile (Subscribed QCI, ARP, APN-AMBR, etc.) are provisioned at HSS and SPR, respectively.

 After Initial Attach

Figure below shows what kinds of information are stored in EPS entities after the “EMM Case 1: Initial Attach by Unknown UE” procedures described in Chapter II. As the user is registered in the network, and all the necessary resources have been allocated,information (allocated identifiers or parameters) required for the UE to securely receive user traffic and to use services at the desired quality level at any location is set in each EPS entity. We will study what changes have been made in the information after initial attach.

Changes in UE ID Information

IMSI: The IMSI that the UE delivered through the Attach Request message is added to the MME, S-GW, P-GW and PCRF after establishment of the EPS session/bearer.

GUTI: The GUTI that the MME allocated to use instead of IMSI in NAS messages is added to the MME and the UE.

UE IP address: The UE IP address that the P-GW allocated is added to the P-GW, PCRF, MME and UE.

C-RNTI: The C-RNTI that eNB allocated to identify UEs in physical layer over the radio link is added to the eNB and the UE.

UE S1AP ID: The eNB UE S1AP ID and the MME UE S1AP ID are added to the eNB and the MME for user identification in S1AP messages delivered over S1-MME interface.

Changes in UE Location Information

ECGI: Information on the cell in which the user is located is added to the UE, eNB, MME, S-GW, P-GW and PCRF. Every time the user moves to a newcell, the MME notifies the P-GW, which then notifies the PCRF, of the newcell in accordance with the Change Reporting Action policies set by the PCRF.

TAI: Information on the TA in which the user is located is added to the UE, eNB, MME, S-GW, P-GW and PCRF. Every time the user moves to a new TA,the MME notifies the P-GW, which then notifies the PCRF, of the new TA inaccordance with the Change Reporting Action policies set by the PCRF. 

TAI list: The TAI list that lists the areas the UE is allowed to enter without TAU updates is added to the MME and UE.

MME ID: Information about the MME that the user is attached to (MME ID) is added to the HSS.

Changes in Security Context Information

NAS Security Info: The NAS security context is added to the UE and MME. AS Security Info: The AS security context is added to the UE and eNB.

Changes in EPS Session/Bearer Information

APN in Use: Added to the MME, S-GW, P-GW, PCRF and UE at the time of EPS session creation.

EPS Bearer ID: Added to the MME and the entities where the default EPS bearer is created (thus, user traffic is delivered through) like the UE, eNB, S-GW and P-GW.

DRB ID: Added to the UE and eNB in charge of communication over the radiolink. 

E-RAB ID: Added to the eNB and MME at the time of E-RAB creation. S1 TEID (UL/DL): Added to the eNB, S-GW and MME at the time of S1 bearer

creation. S5 TEID (UL/DL): Added to the S-GW, P-GW and MME at the time of S5 bearer

creation. QCI: Allocated to all types of SDF and EPS bearers, and added to the UE,

eNB, MME, S-GW, P-GW and PCRF. This QCI value is approved by the PCRF.

ARP: Allocated to all types of SDF and EPS bearers, and added to the eNB,MME, S-GW, P-GW and PCRF, but not to the UE (unlike QCI). This ARP value is approved by the PCRF.

UE-AMBR (UL/DL): Added to the MME and eNB at the time of EPS session and bearer creation. Calculated by the MME. 

APN-AMBR (UL/DL): Added to the MME, P-GW, PCRF and UE at the time of EPS session and bearer creation. This value is approved by the PCRF. UEs haveAPN-AMBR (UL) only.

TFT (UL/DL): Added to the P-GW and UE at the time of EPS bearer creation.P-GWs have this value for both UL and DL, but UEs have it for UL only.

SDF Filter: Added to the PCRF at the time of EPS session creation. Subscribed Profile: Added to the MME when subscription information is

downloaded from the HSS during the user location update procedure.

 EMM Procedure: Detach

Depending on where detach triggering is detected, we will categorize detach into three types: UE-initiated Detach, MME-initiated Detach and HSS-initiated Detach. Then we will describe detach procedures required in each type. Finally, we will look into what changes are made in the information EPS entities have after detach.

Introduction

During this phase, a user is detached/detaches from the network he attached to. A user, initially attached to the network after going through the initial attach procedures as in EMM Case 1, uses LTE servicesin EMM-Registered state. After using the services, the user may be detached by the network or UE, while in ECM/RRC-Connected or ECM/RRC-Idlestate. In any case, once detach procedures are completed, the user’s EPS bearer(s) are released, and his state is cleared.

Cases of Detach

A user uses LTE services after generating an EPS session and default EPS bearer through the initial attach procedures. In some cases, he may detach from the network once done using the services. In other cases, he may be detached by the network while still using services through the network, and becomes unable to stay connected to the network any more.  

Once a user is detached from the network, all the network/radio resourcesallocated to the EPS session and bearer established for the user are released. This release will delete the user’s MM context and EPS bearer that have been set to the EPS entities (UE and network nodes). At this time, the EMM state transits from Registered to De-Registered. If the user is properly detached, GUTI, a NAS-level user ID, and the security context that he used to access the network are kept valid in the UE and the MME, so that he can use the same in his next access to the network.Detach can be triggered by UE or a network. Network-triggered detach is caused by either MME or HSS. Detach can be categorized as one of the following cases depending on where detach triggering is detected: 

1) Detach Case 1: UE-initiated DetachUE can initiate detach: 

if UE is turned off if a USIM card is removed from UE if UE is attempting to use a non-EPS service (e.g. CS fallback, SMS,

etc.)

2) Detach Case 2: MME-initiated DetachMME-initiated detach can be further divided into explicit detach and implicit detach. In case of explicit detach, MME notifies UE of its intent to detach in advance by sending a Detach Request message, and informs the UE whether it has to attach the network again or not after detach. In case of implicit detach, however, the MME initiates detach procedures without notification (i.e. without sending a Detach Request message) because the UE is not capable of communicating with the MME. MME can initiate:

i) Explicit Detach

for an operator’s O&M (Operation & Maintenance) purposes if re-authentication fails if it cannot provide the resources allocated to a user

ii) Implicit Detach

if it is not able to communicate with a user because of poor radio link quality (e.g. radio link failure)

3) Detach Case 3: HSS-initiated Detach

HSS can initiate detach:

if the user profile provisioned in HSS is changed, and thus the one savedin MME also has to be changed

if an operator is trying to restrict access by an illegal UE (e.g. a stolen device) to its network

The next following sections describer’s different detach procedures required in the three detach cases mentioned above. In all three cases, it is assumed a user is in EMM-Registered, ECM-Connected and RRC-Connected state before detach, and services are provided through the default EPS bearer only. Figure below illustrates what connections are established, and in what state UE and MME are in user/control planes before and after detach. Before detach, a default EPS bearer and its related control connections are established, and the user is in EMM-Registered, ECM-Connected and RRC-Connected. Then, after detach, the default EPS bearer and all the signaling connections are released, and the user enters EMM-Deregistered, ECM-Idle and RRC-Idle state.  

UE-initiated Detach

Figure below shows how user-initiated detach is performed. The detach procedure for this type of detach begins when detach triggering is detected at UE , and thus the UE sends a Detach Request message. The procedure ends when the UE receives a Detach Accept message from MME, unless the UE is turned off by the user.

❶ Detach Triggering by UEWhen detach triggering is detected at UE, and thus the UE and MME become aware of it, the two entities will begin the following procedures: 

1) [UE → MME] Detach Request

The UE requests the MME for detach by sending a Detach Request message to the MME. Interpretation of the Detach Request message parameters varies depending on which direction the message is delivered. If it is from UE to MME, the message parameters will be as follows: 

2) [UE] Handling Security and Bearer ContextsAfter sending the Detach Request message, the UE stores its current NAS security context, GUTI and TA information, and thendeletes its EPS bearer context.

 3) [MME] Noticing Detach Intent and Handling Security ContextAfter receiving the Detach Request message from the UE, the MMEbecomes aware of the UE’s intent to detach. It then stores the user’s current NAS security context, and checks the type of theintended detach, i.e. whether it is a case of normal detach, ora turned off device. By doing this, the MME finds out whether it has to send a Detach Accept message or not.

❷ EPS Session TerminationOnce the MME perceived UE-initiated detach and stored the user’s current NAS security context, it requests for termination of the activated EPS session. This request triggers PCEF (P-GW)-initiated EPS termination, releasing all the network/radio resources allocated to the user, as to bedescribed below.

(1) EPS Bearer Release and PCC Rule Removal 

4) [MME → S-GW] Requesting EPS Session ReleaseThe MME and the S-GW communicate with each other over S11 interface using GTP protocol (GTP-C). The MME begins proceduresfor deleting the user’s EPS session and default EPS bearer by sending the S-GW a Delete Session Request message. At this

time, the default EPS bearer ID and UE location information (ECGI, TAI) are delivered.

 5) [MME] Deleting EPS Bearer ContextThe MME deletes the user’s EPS bearer context after sending the Delete Session Request message.

 6) [S-GW → P-GW] Requesting EPS Session ReleaseThe S-GW and the P-GW communicate with each other over S5 interface using GTP protocol (UP: GTP-U, CP: GTP-C). The S-GW forwards the Delete Session Request message received from the MME to the P-GW.

 7) [S-GW] Deleting EPS Bearer ContextThe S-GW deletes the user’s EPS bearer context after sending the Delete Session Request message.

 8) [P-GW → PCRF] Notifying of EPS Session TerminationThe P-GW and the PCRF communicate with each other over Gx interface using Diameter protocol. The P-GW sends PCRF a CCR (CC-Request) message to notify the user has finished using services through the network. This way it has the EPS session termination procedures (PCEF-initiated EPS Session Termination)initiated.

 9) [PCRF] Deleting RCC RuleThe PCRF deletes the user’s PCC rule once it receives the CCR message from the P-GW.

 10) [P-GW ← PCRF] Acknowledging EPS Session TerminationThe PCRF acknowledges the user’s PCC rule has been deleted by sending a CCA (CC-Answer) message to the P-GW.

 11) [S-GW ← P-GW] Responding to EPS Session Release RequestWhen the P-GW receives the CCA message from the PCRF, it sends the S-GW a Delete Session Response message as a response to themessage sent in Step 6) above.

 12) [P-GW] Deleting EPS Bearer ContextThe P-GW deletes the user’s EPS bearer context after sending the Delete Session Response message. 13) [MME ← S-GW] Responding to EPS Session Release Request

When the S-GW receives the Delete Session Response message fromthe P-GW, it sends the MME a Delete Session Response message asa response to the message sent in Step 4) above.

 14) [UE ← MME] Acknowledging DetachUpon receipt of the Delete Session Response message, the MME recognizes the user’s resource release has been approved by thePCRF. So, it sends the UE a Detach Accept message as a responseto the request sent in Step 1). A Detach Accept message is sentonly when the UE’s detach request was made due to a cause otherthan a switched off device (i.e. when Switch Off=0 in the Detach Request). If detach was requested because of a device’s switch off, no Detach Accept message is sent by MME.   

(2) S1 Signaling Connection ReleaseAfter sending the Detach Accept message to the UE, the MME and the eNB release any resources left for the user (S1 signaling connection, RRC connection and UE Context left in the eNB) as they do not serve the UE any more.

 15) [eNB ← MME] Acknowledging S1 Signaling Connection ReleaseThe MME sends a UE Context Release Command message to the eNB to release the S1 signaling connection. 16) [UE ← eNB] RRC Connection ReleaseThe eNB sends an RRC Connection Release message to the UE to release any RRC connection left unleased.

 17) [eNB] Deleting UE ContextThe eNB deletes all the information related to the UE.

 18) [eNB → MME] RRC Connection Release CompleteFinally, the eNB sends the MME a UE Context Release Complete message as a response to the request sent in Step 15).

MME-initiated Detach

Figure below displays how MME-initiated explicit detach is performed. Thedetach procedure for this type of detach begins when detach triggering isdetected at MME, and thus the MME sends a Detach Request message to the

UE. The procedure ends when the resources previously allocated to the UE’s EPS session are released.

❶ Detach Triggering by MMEBelow is a description of the procedures to be performed after MME detects detach triggering, and before the EPS session termination procedure is carried out. If the user is in Idle state at this time, the MME performs paging to establish S1 signaling connection (Detailed pagingprocedures will be explored in our technical document “EMM Procedure 4. Service Request due to New Traffic”, and hence will not be discussed here). 

1) [UE ← MME] Detach RequestAs it is explicit detach, the MME sends a Detach Request message to request the UE for detach. Message parameters are as follows in case a detach request is sent by MME to UE:

In case of implicit detach, however, MME does not send a DetachRequest message to UE.

 2) [MME] Handling Security ContextAfter sending the Detach Request message to the UE, the MME stores the current NAS security context in use before deleting the EPS session. Next time the UE re-attaches, the MME can use the stored context again and skip the authentication and NAS security setup procedures for the user.

 3) [UE] Noticing Detach Intent and Handling Security and BearerContextsAfter receiving the Detach Request message from the MME, the UEbecomes aware of the MME’s intent to detach. It checks the typeof the intended detach to see whether or not re-attach is required after detach. Then it stores the current NAS security context and deletes the EPS bearer context.

 ❷ EPS Session TerminationOnce the MME stored the NAS security context upon perceiving detach triggering, it requests the P-GW for termination of the user’s EPS

session. This request triggers PCEF (P-GW)-initiated EPS termination, releasing all the network/radio resources allocated to the user, as to bedescribed below. 

(1) EPS Bearer Release and PCC Rule RemovalThrough Steps 4) ~ 13), the MME requests for termination of the user’s EPS session, the PCRF deletes PCC rule upon the request, and S5 bearer resources are released, as in Steps 4) ~ 13) in Chapter III. In case of a detach type that requires re-attach, the MME can save the current UE-AMBR value in Step 5) so that the UE can establish an EPS bearer faster next time it re-attaches.

 4) [UE → MME] Acknowledging DetachAfter storing the NAS security context and deleting the EPS bearer context upon receipt of the Detach Request message from the MME in Step 1), the UE sends the a Detach Accept message asa response to the request in Step 1). In case of implicit detach, Steps 1), 14) and 16) are skipped.

 (2) S1 Signaling Connection ReleaseIn this phase, the MME releases any unreleased resources (S1 signaling connection, RRC connection and UE context left in the eNB)after receiving the Detach Accept message from the UE and the DeleteSession Response message from the S-GW. Steps in this phase are the same as Steps 15) ~ 18) in Chapter III, except that in case the detach type is set as “re-attach required”, UE re-attaches the network after RRC connection is released.  

HSS-initiated Detach

Figure below provides an illustration of how HSS initiates detach after detecting detach triggering.

❶ Detach Triggering by HSSWhen detach is triggered at HSS due to subscriber withdrawal, the HSS attempts to delete the user’s MM context and EPS bearer immediately. 

1) [MME ← HSS] Detach RequestThe HSS and the MME communicate with each other over S6a interface using Diameter protocol. The HSS requests the MME fordetach of the user by sending a Cancel Location Request (CLR) message with the following parameters: 

❷ EPS Session TerminationUpon receipt of the Cancel Location Request (CLR) message from the HSS, the MME releases all the resources previously allocated to the user. Steps for such procedure are the same as in MME-initiated detach (Figure 3) described in Chapter III, except that an additional action is requiredby the MME in Step 2). The MME needs to send the HSS a Cancel Location Answer message as a response to the request made in Step 1).

2) [MME → HSS] Responding to Detach RequestAfter receiving the Detach Accept message from the UE, and the Delete Session Response message from the S-GW, the MME sends a Cancel Location Answer message to the HSS as a responseto the Cancel Location Request message sent in Step 1).

EPS Entity Information: Before/After Detach

This chapter explains how information in EPS entities is changed after “EMM Case 2: Detach” procedures are performed. All the information in each entity is categorized into UE ID, UE Location, Security and EPS Session/Bearer information.

Before Detach

A user stays in ECM/RRC-Connected state before he detaches or is detached from the network. Therefore, before detach, all the EPS entitieshave the same information they initially had after initial attach. Figure5 lists the information stored in each EPS entity before detach is performed.

 After Detach

After detach, information that can be used for the user’s fast and secured attach next time is stored in UE and MME. All other contexts related to the user, such as NAS security context, GUTI and TAI information allocated by MME, etc., are deleted. Figure 6 lists the information elements stored in each EPS entity after “EMM Case 2: Detach”procedures. Ones that are to be deleted after detach are shown in gray, provisioned ones that are to be kept are in black, and ones to be used innext attach are in blue.

Information elements kept for next attach are stored as follows:

At UE:

UE ID: GUTI allocated by MME at the time of initial attach or TA updates UE Location: The last TA that UE visited before detach Security: NAS security context information that UE used before detach

At MME:

UE ID: IMSI that UE provided at its initial attach, and GUTI allocated byMME at the time of UE’s initial attach or TA updates

UE Location: The last TA that UE visited before detach. The TAI list allocated to UE may be kept as well.

Security: NAS security context information that UE used before detach EPS Session/Bearer: Subscribed profile received from HSS at the time of

UE location registration. The UE-AMBR value determined by MME at the times of EPS bearer establishment, and the APN-AMBR value used in UE-AMBRmay be kept as well.

At HSS:

UE Location: The last MME UE was registered at before detach

The diagram above have procedures of i) a detach procedure required when UE moves from its current location (e.g. City 1) to another city (e.g. City 2), and thereby leaves the LTE coverage inCity 1, and ii) an initial attach procedure required for the UE toattach again the network using its Old Globally Unique Temporary Identifier (Old GUTI) after entering the LTE coverage in City 2. In this EMM Case , we assume an LTE network operator that serves several geographically separated cities through operation of an LTE-only network that uses a single LTE carrier frequency.

IntroductionUE attempts a handover or cell reselection when the received signal strength from its serving cell becomes weak as it moves. If there is no neighbor cell at all near the travelling UE, the signal strength will getgradually weaker until finally the UE is detached from the network. Then,once within an LTE coverage again, it will make initial attach to the network again through cell selection. This document discusses EMM cases where UE detaches from the network as it moves out of one LTE coverage area, and moves into another one, attaching the network again, as in EMM Case , “Move to Another City”, andEMM Case , “Initial Attach in Another City” [1]. Figure above illustratesthe two cases.

For the purpose of the two EMM cases, this document assumes a mobile operator that:

is serving several cities, is operating an LTE-only network with no 2G/3G network, has MME, S-GW and P-GW in each city that it serves, has HSS, PCRF and SPR installed in only one city, and has all the MMEs connected through S10 interface.

Figure 1 shows City 1 and City 2 only, and the user is moving from City 1to City 2 in a car.In EMM Case 10, UE detaches from the network as it leaves City 1, therebymoving out of the LTE coverage. The UE, either while using services in Connected state (EMM-Registered, ECM-Connected, RRC-Connected) or while camping on its serving cell in Idle state (EMM-Registered, ECM-Idle, RRC-Idle), transits to Detach state (EMM-Deregistered, ECM-Idle, RRC-Idle) asit leaves City 1, and hence is detached from the network by MME.1

In EMM Case 11, UE attaches the network again as it moves into an LTE coverage after arriving in City 2. Unlike the case in the previous document [3], the network (Old MME) has already had the UE context when the UE attaches the network (New MME). The UE makes initial attach to thenetwork (New MME) using the UE ID (Old GUTI) that was assigned by the network (Old MME). By that, it transits from Detach state (EMM-Deregistered, ECM-Idle, RRC-Idle) to Connected state (EMM-Registered, ECM-Connected, RRC-Connected).

EMM Case 1:- Move to Another City

Moving in Connected StateIn Figure below, we can see how UE, while using services in City 1, is detached from the network as it moves out of the LTE coverage.

 1)   [UE → eNB] Measurement ReportAs the UE leaves City 1, the signal strength received from the serving cell gets weaker. In case A2 event has been activated, the UE sends a Measurement Report message to eNB, informing the signal strength of the serving cell.

    2)   [eNB] No Neighbor Cell to Hand Over to

The eNB finds no neighbor cell to hand the UE over to.    3)   [eNB → MME] Error Indication

Due to the worsening communication quality, delivery fails over the radio interface. The eNB informs the MME of such failure by sending an Error Indication (Cause=Failure in the Radio Interface2) message (if the eNB finds it hard to maintain the minimum quality required for communication with the UE, it may send the MME an UE Context Release Request message). 

If the UE loses the RRC connection due to poor communication quality, the UE attempts RRC connection re-establishment. If the quality degradation is temporary, the RRC connection is re-established allowing for normal radio communication. In such case, service provision is not interrupted. If the degradation persists, the RRC connection re-establishment will continue to fail, causing the connection to be lost eventually. It is assumed here that i) the eNB sends an Error Indication to the MME while the RRC connection with the UE is still valid, and ii) theMME decides to detach the UE because the current serving cell of theUE is located near the city border, and has no neighbor cell to handover to. So, the MME triggers a detach procedure.

    4)   MME-initiated Detach

The MME performs a detach procedure by sending the UE a Detach Request message. Here the procedure is the same as the “MME-initiated Explicit Detach procedure” explained in our previous document [2]3. The MME stores the UE’s GUTI and NAS security context, terminates the EPS session, releases the S1 signaling, and transits to Detach state (EMM-Deregistered, ECM-Idle). The UE storesits GUTI and NAS security context, deletes the EPS bearer context, and then transits to Detach state (EMM-Deregistered, ECM-Idle, RRC-Idle).

 Moving in Idle StateUE performs periodic TAU to report its location to the network periodically while it stays in Idle state (see the previous document [5] for details). When there is an incoming call/packet for the UE, MME does not know whether the UE is reachable or not if it is in Idle state. For this reason, UE in Idle state periodically reports its location even while staying in a TA in the TAI list so that the network can see whetherthe UE is reachable or not. To this end, MME has a TAU timer (T3412), mobile reachable timer, and implicit detach timer. The TAU timer (T3412) value is forwarded to UE through an Attach Accept message when the UE makes initial attach to the network, or through a TAU Accept message whenthe UE makes a TAU request.A TAU timer (T3412) defaults to 54 minutes [4]. If MME sets this value to“0”, UE deactivates the TAU timer, and does not perform periodic TAU (Wouldn’t it be used for M2M communications?). The TAU timer in UE is activated when the UE transits from Connected state (EMM-Registered, ECM-Connected, RRC-Connected) to Idle state (EMM-Registered, ECM-Idle, RRC-Idle). When the timer expires, the UE transits to Connected state to send

MME a TAU Request message informing it is reachable, and then transits back to Idle state, restarting the TAU timer. The UE stops the timer if it transits from Idle to Connected state, or if it is detached from the network.If the TAU timer that MME set for the UE expires, the MME shortly receives a TAU Request message4, through which it keeps track of the UE’slocation. Then, it re-allocates a new TAI list if needed, and then re-starts the TAU timer. That is, the network checks whether the UE is reachable or not at least at the end of every TAU timer cycle, and sets Paging Proceed Flag to “1”, indicating the UE is reachable. If the UE has any problem (for example, if it is within a shadowing area at the time of T3412 timer expiration, and hence not reachable), it cannot make a TAU request required upon the expiration of T3412, and hence fails to inform MME of its location. UE is required to re-attempt when a TAU request is failed. So, if the UE gets out of the shadowing area soon after, then the re-attempted TAU request can be made successfully. However, if it stays in the shadowing area, then any further TAU requests will continue to fail. A mobile reachable timer is used by the network to check whether UE is reachable or not. Compared to the TAU timer (T3412), it has a slightly higher value, defaulting to “T3412 + 4 minutes”. The timer starts when the ECM connection with UE is released (e.g. if UE transits to Idle state), and stops when a new ECM connection is established (e.g. if UE sends a TAU Request message to MME). When the mobile reachable timer expires, MME knows UE is out of the LTE coverage, but does not know for how long the out of the coverage status has lasted. So, instead of deleting the UE’s context right away, the MME clears the PPF flag and starts the implicit detach timer. When the PPF flag is cleared, the UE is locally detached. That is, while the implicit detach timer runs, the network still keeps the UE context undeleted, but the MME does not page the UE (of course because it does not know where the UE is). Even when S-GW sends the MME a Downlink Data Notification message upon arrival of a call/packet destined to the UE, the MME declines the message. When the UE sends a NAS message, establishing an ECM connection, the implicit detach timer stops. If the MME is unable to locate the UE beforethe implicit detach timer is expired, it believes the UE has long been out of the LTE coverage, and thus detaches the UE from the network. Now, the UE context is deleted in the network.

 Figure below illustrates how UE that has been camping on the serving cellin City 1 is detached from the network as it moves out of the LTE coverage.

1)   [MME] TAU Timer (T3412) ExpiryThe TAU timer set for UE is expired. The MME has not received a TAU Request message from the UE, and must check whether the UE is reachable or not.

    2)   [MME] Mobile Reachability Timer Expiry

The UE’s mobile reachable timer is also expired. The MME, believing the UE is in the “out of coverage” status, clears the PPF flag and starts the implicit detach timer. The resources allocated to the UE (e.g. EPS bearer, security context, etc.) are kept valid, but the MME does not page the UE.

    3)   [MME] Mobile Implicit Timer Expiry

The UE’s implicit detach timer is expired. The MME, believing the UEhas long been “out of the coverage”, decides to implicitly detach the UE from the network.

    4)   [eNB, MME, S-GW, P-GW, PCRF] UE Detached

The MME initiates an implicit detach procedure. This procedure is the same as the “MME-initiated Implicit Detach procedure” The allocated resources and context of the UE are deleted.

EMM Case 2 : Initial Attach in Another CityThis section describes how the traveling UE, as it moves back into the LTE coverage in City 2, selects a new cell, and performs initial attach, thereby transiting from Detach state (EMM-Deregistered, ECM-Idle, RRC-Idle) to Connected state (EMM-Registered, ECM-Connected, RRC-Connected). We assume that the UE was detached from the network in City 1 through an MME-initiated explicit detach procedure, and thus the Old GUTI and NAS security context are all kept valid at UE and the network (MME1). Figure 4 shows the type of initial attach and function blocks involved inthe UE’s initial attach in City 2. The initial attach type here is the same as “Attach Case 5: Known UE, MME Changed” (Attach to New MME with Old GUTI) discussed in our previous document [6]. That is, as the UE detached from the network successfully, both UE and network (Old MME) have kept the Old GUTI and NAS security context valid, and the UE is making initial attach to a new MME using them. The UE sends an Attach Request message by using the Old GUTI instead of IMSI as its ID. The message is sent integrity protected with the NAS integrity key (KNASint). The new MME (New MME) forwards the message to the old MME (Old MME) so that it can run an integrity check. In this document, it is assumed the integrity check in the Old MME succeeded. The New MME, after obtaining the UE context including IMSI from the Old MME, performs location update and EPS session establishment procedures. If the integrity check in the Old MME fails, the Old MME sends an error message to the New MME, which then obtains IMSI from the UE and performs user authentication, NAS security setup, location update and then EPS session establishment.

Figure below is an illustration showing how the UE performs initial attach to the New MME (MME2) in City 2, using its Old GUTI.

1) [UE, eNB] Establishing RRC ConnectionOnce entering City 2, the UE detects LTE signal,selects a new cell, and requests eNB for an RRC connection. As a result, an RRC connection is established. 2) [UE, New MME] Requesting Initial Attach to New MME using Old GUTIThe UE sends an Attach Request (Old GUTI, Last Visited TAI, KSIASME, NAS-MAC) to the network

(MME2), by using the Old GUTI allocated by MME1 in City 1 as its ID. The message is integrity protected with the KNASint key first, and sent through the RRC Connection Setup Complete message over the radio interface (LTE-Uu interface) and then through the Initial UE Message (ECGI, TAI) over S1 interface. 3) [New MME] Identifying Old MMEMME2 checks the location of the UE from the received Initial UE Message, and learns from theOld GUTI that it was allocated by MME1.5Next, MME2 checks if the Old GUTI is still validthrough communication with MME1 over S10 interface, and obtains the UE context stored at MME1. 4) ~ 6) [Old MME, New MME] Obtaining UE Context from Old MME 4)The New MME (MME2) includes the Attach Request message that it received and the Old GUTI in theIdentification Request (Old GUTI, Complete {Attach Request} message from UE) message, and sends the message to the Old MME (MME1). 5)When receiving the message from the New MME (MME2), the Old MME (MME1) knows that the GUTI was allocated by itself, and then performs integrity check on the Attach Request message

sent by the UE, by using the UE security contextit has kept. The check succeeds. 6)As the integrity check succeeded, the Old MME (MME1) sends the New MME (MME2) the UE context6 through the Identification Response (IMSI, UE-AMBR, UE Security Context (KASME, KSIASME, Unused AVs, NAS Keys, etc)) message. The new MME(MME2) obtains the UE context. 7) ~ 10) [Old MME, New MME, HSS] Location Information Updated at New MME, and Deleted atOld MME 7)The MME2, now with the valid UE context, sends the Update Location Request (IMSI, MME ID=MME2) message to HSS in order to register the UE with the network (MME2). This way, it informs the HSSthat the UE with the IMSI has been registered with MME2. The HSS updates the UE’s new locationaccordingly. 8)The HSS sends MME1 the Cancel Location Request (IMSI) message asking MME1 to delete the UE context. MME1 deletes the UE context as requested.

9)MME1 informs the HSS that the UE context is deleted, by sending the Cancel Location Response(IMSI) message. 10)The HSS provides MME2 with the subscription profile information of the UE, including subscription QoS information, by sending the Update Location Answer (IMSI, APN, Subscribed Profile (QCI, ARP, APN-AMBR (UL/DL), UE-AMBR (UL/DL)) message, so that MME2 can establish an EPS session. 11) [New MME] Establishing EPS SessionMME2 establishes an EPS session by using the UE context received from MME1, and the subscriptionprofile received from the HSS. The establishmentprocedure at this time is the same as the “EPS Session Establishment procedure”.

EPS Entity InformationThe Information elements stored in the EPS entities before and after the “move to Another City” procedure in EMM Case 1 are as follows:

Before

 - 

If UE is in Connected state, the same information elements kept after the initial attachprocedure [3] are stored.

  - 

If UE is in Idle state, the same information elements kept after the S1 release procedure [9] are stored.

After

  - UE is detached from the network. The information elements stored in EPS entities are the

  same as those kept after the detach procedure [4]. The Information elements stored in the EPS entities before and after the “initial attach in another city” procedure in EMM Case 2 are as follows:

Before: UE is detached from the network. The same information elements kept after the detach procedure [2] are stored.

After: UE is attached to the network. The same information elements kept after the initial attach procedure [3] are stored.

1 There are seven (7) EMM states of UE defined in 3GPP TS 24.301. A UE, after sending an Attach Request message to an MME, enters “EMM-Registered-Initiated” mode. Then it enters “EMM-Registered” mode after receiving an Attach Accept message from the MME. In this document, the EMM states of a UE are defined either as “EMM-Deregistered” or “EMM-Registered” only. Thus, it will be considered the UE enters “EMM-Registered” mode after sending an Attach Request.2 At this time, the E-RAB in the user plane and the ECM connection in thecontrol plane are released. That means the S1 bearer and S1 signaling connection are released on the MME side while the DRB and RRC connectionsare released on the UE side. In this document, we used the term, S1 release, as described in 3GPP TS 24.301.3 To provide more simplified illustration, X2 connections between eNBs are not included in Figure above.

LTE Security : Concept and Authentication

Introduction

Wireless communication, in its nature, is always at a risk of eavesdropping or manipulation because data originally sent from/to a usermay be received and unlawfully used by an unintended user. Locations or traveling routes of a user can also be easily tracked by tracing to whichcells the user is connected or through which cells the user is travelling. And this can result in privacy infringement. Mobile

communication networks provide security features to ensure data transferred across radio links is not manipulated, prevent unauthorized access by an unintended user to the data received, and protect the privacy of users.

The LTE Security document describes basic security features offered by LTE networks, including LTE authentication, NAS (Non Access Stratum) security and AS (Access Stratum) security. LTE authentication is the process of determining whether a user is an authorized subscriber to the network that he/she is trying to access, while NAS security and AS security are features required to securely deliver user data that travelsthrough LTE radio links at NAS and AS levels.

LTE Security Concept

Scope and Concept of LTE Security

Figure below shows the scope and overall concept of the LTE Security documents. The scope of these documents will include the following three areas:

LTE Authentication: performs mutual authentication between a UE and a network.

NAS Security: performs integrity protection/verification and ciphering (encryption/decryption) of NAS signaling between a UE and an MME.

AS Security

• performs integrity protection/verification and ciphering of RRC signaling between a UE and an eNB.

• performs ciphering of user traffic between a UE and an eNB.

LTE Authentication

In mobile communication networks, authentication refers to the process ofdetermining whether a user is an authorized subscriber to the network that he/she is trying to access. Among various authentication procedures available in such networks, EPS AKA (Authentication and Key Agreement) procedure is used in LTE networks for mutual authentication between usersand networks.

The EPS AKA procedure consists of two steps. First, an HSS (Home Subscriber Server) generates EPS authentication vector(s) (RAND, AUTN,

XRES, KASME) and delivers them to an MME. Then in the second step, the MME selects one of the authentication vectors and uses it for mutual authentication with a UE and shares the same authentication key (KASME) each other. Mutual authentication is the process in which a network and auser authenticate each other. In LTE networks, since the ID of the user'sserving network is required when generating authentication vectors, authentication of the network by the user is performed in addition to authentication of the user by the network.

ASME (Access Security Management Entity) is an entity that receives top-level key(s), from an HSS, to be used in an access network. In EPS, an MME serves as ASME and KASME is used as the top-level key to be used in the access network. The MME, on behalf of an HSS, conducts mutual authentication with a UE using KASME. Once mutually authenticated, the UEand MME get to share the same KASME as an authentication key.

To avoid any possible eavesdropping or manipulation of data across radio links, KASME is not delivered to the UE via E-UTRAN. Instead, the MME delivers part of authentication vector to the UE, which uses it to authenticate the network and generates KASME as the HSS does.

NAS Security

NAS security, designed to securely deliver signaling messages between UEsand MMEs over radio links, performs integrity check (i.e., integrity protection/verification) and ciphering of NAS signaling messages. Different keys are used for integrity check and for ciphering. While integrity check is a mandatory function, ciphering is an optional function. NAS security keys, such as integrity key (KNASint) and ciphering key (KNASenc), are derived by UEs and MMEs from KASME.

AS Security

AS security is purposed to ensure secure delivery of data between a UE and an eNB over radio links. It conducts both integrity check and ciphering of RRC signaling messages in control plane, and only ciphering of IP packets in user plane. Different keys are used for integrity check/ciphering of RRC signaling messages and ciphering of IP packets. Integrity check is mandatory, but ciphering is optional.

AS security keys, such as KRRCint, KRRCenc and KUPenc, are derived from KeNB by a UE and an eNB. KRRCint and KRRCenc are used for integrity checkand ciphering of control plane data (i.e., RRC signaling messages), and

KUPenc is used for ciphering of user plane data (i.e., IP packets). Integrity check and ciphering are performed at the PDCP (Packet Data Convergence Protocol) layer.

A UE can derive KeNB from KASME. However, since KASME is not transferred to an eNB, an MME instead generates KeNB from KASME and forwards it to the eNB.

Overview of LTE Security Procedure

Figure shows the overview of LTE security procedure. displays LTE authentication procedure while and demonstrate security setup proceduresfor NAS and AS respectively. A brief description of each procedure will be given below first.

LTE Authentication

When a user requests for access to a LTE network, mutual authentication between the user and the network is conducted using EPS AKA procedure. An

MME, upon receipt of such request, identifies the user using his/her IMSIand requests authentication vector(s) (AVs) from an HSS1. The HSS then generates AV(s) using EPS AKA algorithm, AV={RAND, XRES, AUTNHSS, KASME}, and forwards them to the MME. After storing the AVs, the MME selects one of them and uses it to performmutual authentication with the UE2. The MME forwards RAND and AUTNHSS to the UE, which then computes RES, AUTNUE and KASME using EPS AKA algorithm. The UE now compares its own AUTNUE and AUTNHSS received from the MME for network authentication. Once authenticated, RES is forwarded to the MME, which then compares the XRES received from the HSS and the RES received from the UE for user authentication. If the UE and network have authenticated each other, they share the same key KASME (KASME is not transferred between UE and MME, though).

NAS Security

Once the UE and MME have authenticated each other and the same key KASME isshared, NAS security setup procedure begins. In this procedure, NAS security keys to be used when delivering NAS signaling messages are derived from KASME for secure delivery of these messages. This procedure consists of a round trip of NAS signaling messages (Security Mode Command and Security Mode Completemessage), and begins when the MME delivers a Security Mode Command message to the UE. First, the MME selects NAS security algorithms (Alg-ID: Algorithm ID) anduses them to create an integrity key (KNASint ) and a ciphering key (KNASenc) from KASME. Then, it applies KNASint  to the Security Mode Command message to generate an NAS message authentication code (NAS-MAC, Message Authentication Code for NAS for Integrity). The MME then delivers the Security Mode Command message including the selected NAS security algorithms and the NAS-MAC to the UE. As the UE does not know the selected encryption algorithm yet, this message is integrity protected only but not ciphered.

 Upon receiving the Security Mode Command message, the UE verifies the integrity thereof by using the NAS integrity algorithm selected by the MME and uses NAS integrity/ciphering algorithm to generate NAS security keys (KNASint and KNASenc) from KASME. Then it ciphers the Security Command Complete message with KNASenc and generates a message authentication code, NAS-MAC with KNASint to the ciphered message. Now it forwards the ciphered and integrity protected message to the MME with the NAS-MAC included.

 Once the MME successfully verifies the integrity of the received SecurityMode Complete message and has them decrypted using the NAS security keys (KNASint and KNASenc), the NAS security setup procedure is completed. Once the NAS security is set up, NAS signaling messages between the UE and the MME are ciphered and integrity protected by the NAS security keysand then securely delivered over radio links. 

AS Security

After NAS security setup is finished, AS security setup procedure betweena UE and an eNB begins. In this procedure, AS security keys to be used when delivering RRC signaling messages and IP packets are derived from KeNB for secure delivery of these data. This procedure consists of a roundtrip of RRC signaling messages (Security Mode Command and Security Mode Complete message), and begins when an eNB delivers Security Mode Command message to the UE. First, the MME calculates KeNB from KASME and delivers it to the eNB, which uses it to perform the AS security setup procedure. The eNB selects AS security algorithms (Alg-ID: Algorithm ID) and uses them to create an integrity key (KRRCint) and a ciphering key (KRRCenc), from KeNB. to be used forRRC signaling messages, and a ciphering key (KUPenc) to be used in the userplane. Then, it applies KRRCint to the Security Mode Command message to generate a message authentication code (MAC-I, Message Authentication Code for Integrity). The eNB now delivers the Security Mode Command message including the selected AS security algorithms and the MAC-I to the UE. Upon receiving the Security Mode Command message from the eNB, the UE verifies the integrity thereof by using the AS integrity algorithm selected by the eNB and uses AS integrity/ciphering algorithm to generateAS security keys (KRRCint, KRRCenc and KUPenc). Then it generates a message authentication code, MAC-I, with the RRC integrity key to the Security Command Complete message, and then forwards the message including the MAC-I to the eNB. When the eNB successfully verifies the integrity of the received SecurityMode Complete message by using the AS integrity key, the AS security setup procedure is completed. 

After the AS security is set up, RRC signaling messages between the UE and the eNB are ciphered and integrity protected by the AS security keys,and user IP packets are encrypted and then securely delivered over radio links.  

LTE Authentication Procedure

Figure below shows the EPS AKA-based LTE authentication procedure that is performed when a UE attaches to the LTE network. On the USIM and in the HSS/AuC are stored a permanent key, LTE key (K), and IMSI3. These LTE key (K) and IMSI are stored on the USIM card when UE is being manufacturing, and provisioned in the HSS/AuC when a user begins subscription to his/her operator’s network.

Authentication Request by UE

 [UE → MME] Request by UE for Network Registration

When a UE attempts to access the network for initial attach, it delivers Attach Request (IMSI, UE Network Capability, KSIASME=7) message to an MME. And this triggers EPS AKA procedure. The following informationelements are included in the Attach Request message:

IMSI: International Mobile Subscriber Identity, a unique identifier associated with the user

UE Network Capability: security algorithms available to UE   KSIASME=7: indicates UE has no authentication key

UE network capability informs the MME of what kinds of capability the UE has related to EPS, and indicates which NAS and AS security algorithms, i.e., EPS Encryption Algorithms (EEA) and EPS Integrity Algorithms (EIA) are supported by the UE. Each of them has a value of 1 bit that is presented as on (supported) or off (not supported) (e.g. EEA0=on, EEA1=on, EEA2=off, …, EIA1=on, EIA2=on, …). Table 1 lists some of UE network capability information, specifically ciphering and integrity protection algorithms defined in [3].   Table 1. UE network capability information – EEA and EIA [3]

 

EEA EIA

EEA0 Null ciphering algorithm EIA04 Null integrity protectionalgorithm

128-EEA1 SNOW 3G 128-EIA1 SNOW 3G128-EEA2 AES 128-EIA2 AES128-EEA3 ZUC 128-EIA3 ZUC

KSIASME identifies KSIASME for the UE and the MME. It is 3 bits and has values ranging from 0 ('000') to 7 ('111'), where 7 ('111') indicates theUE has no KASME available.

Authentication Data Exchange between MME and HSS

2) [MME → HSS] Request by MME for Authentication DataThe MME recognizing the UE has no KASME available initiates LTE authentication procedure to get new authentication data by sending an Authentication Information Request (IMSI, SN ID, n, Network Type) messageto the HSS. Message parameters used for this purpose are as follows:

 

IMSI: a unique identifier associated with the user

SN ID (Serving Network ID): refers to the network accessed by the user. Consists of PLMN ID (MCC+MNC).

n (number of Authentication Vectors): No. of authentication vectors that MME requests

Network Type: type of the network accessed by UE (E-UTRAN herein)

 Upon receipt of the Authentication Information Request message from the MME, the HSS generates RAND and SQN, and creates XRES, AUTN, CK and IK using EPS AKA algorithm with LTE key (K), SQN and RAND. Thereafter, usingCK, IK, SQN and SN ID, it derives a top-level key (KASME) of the access network, from Key Derivation Function (KDF), to be delivered to the MME. KDF is a one-way has function. Since SN ID is required when deriving KASME, KASME is derived again if the serving network is changed. After KASMEisderived, the HSS forms authentication vectors AVi=(RANDi, AUTNi, XRESi, KASMEi), i=0..n.

3 ) [MME ← HSS] Response by HSS to the Authentication Data RequestTHe HSS forms as many AVs as requested by the MME and then delivers an Authentication Information Answer (AVs) message to the MME.

Mutual Authentication by UE and MME

The MME stores the AVs received from the HSS, and selects one of them to use in LTE authentication of the UE. In Figure 3, the MME selected i’th AV (AVi). KASME is a base key of MME and serves as a top-level key in theaccess network. It stays within EPC only and is not delivered to the UE through E-UTRAN, which is not secure. The MME allocates KSIASME, an indexfor KASME, and delivers it instead of KASME to the UE so that the UE and the MME can use it as a substitute for KASME (in Fig for auth procedure, KSIASME=1).

 4 ) [UE ← MME] Request by MME for User Authentication The MME keeps KASMEi and XRESi in AVi but delivers KSIASMEi, in substitution for KASMEi, RANDi and AUTNi as included in the Authentication Request (KSIASMEi,RANDi, AUTNi) message to the UE. XRESi is used later in (5) when authenticating the user.

 

The UE, upon receiving the Authentication Request message from the MME, delivers RANDi and AUTNi to USIM. USIM, using the same EPS AKA algorithm that the HSS used, derives RES, AUTNUE, CK and IK with the stored LTE key(K) and RANDi and SQN generated from the HSS5. The UE then compares AUTNUE

generated using EPS AKA algorithm and AUTN received from MME (AUTNi in Fig. 3) to authenticate the LTE network (the serving network).

 5)  [UE → MME] Response by UE to User AuthenticationOnce the UE completes the network authentication, it delivers an Authentication Response (RES) including RES generated using EPS AKA algorithm to MME. If the network authentication using AUTN fails in (4), UE sends an Authentication Failure (CAUSE) message that contains a CAUSE field stating reasons for such failure.

 When the MME receives the Authentication Response message from the UE, itcompares RES generated by the UE and XRESi of the AV received from the HSS to authenticate the user. USIM delivers CK and IK to the UE after its network authentication is completed. The UE derives KASME using Key Derivation Function (KDF) with CK, IK, SQN and SN ID and stores it using KSIASME received from the MME asits index. Thereafter, KSIASME is used instead of KASME during the NAS security setup between the UE and the MME.

LTE security keys: authentication

 

Key Length Location Derived from DescriptionK 128 bits USIM, HSS/AuC - LTE keyCK 128 bits USIM, HSS/AuC K Cipher keyIK 128 bits USIM, HSS/AuC K Integrity keyKASME 256 bits UE, HSS, MME CK, IK MME base key

 

 1 MME may request for more than one authentication vectors.

2 In general, UE consists of USIM and ME. USIM handles mutual authentication and ME delivers authentication information between MME andUSIM. Once the network is successfully authenticated, USIM calculates CK and IK and delivers them to ME, which then calculates KASME based on them. USIM and ME are collectively referred to as UE herein for the sake of convenience unless it is required to refer to USIM specifically.

3 LTE key (K) is stored in AuC (Authentication Center) in operator's network and in USIM in UE. In Figures herein, AuC and HSS are collectively referred to as HSS, and USIM and ME as UE for the sake of convenience.

4 EIA0 is allowed in an unauthorized emergency call only.5 SQN is concealed in AUTNi.

NAS and AS Security

Once LTE authentication is completed, UE and MME share the same KASME. This section describes NAS and AS security setup procedures in which NAS and AS security keys are generated based on KASME, and how control messages and user packets are securely delivered thereafter. Then, it discusses security contexts to be stored in EPS entities as a result of the NAS and AS security setup, followed by a summary of the security keysused in LTE.Introduction

This section describes about NAS and AS security setup procedures to be performed based on KASME, and how data are transmitted in user and controlplanes after the security setup procedures.

Figure below shows the protocol stacks related to NAS and AS security setup.

NAS Security: The purpose of NAS security is to securely deliver NAS signaling messages between a UE and an MME in the control plane using NASsecurity keys. The NAS security keys are derived from KASME and new keys are generated every time EPS AKA is performed (every time a new KASME is generated). After the NAS security setup is completed, the UE and the MMEget to share a NAS encryption key (KNASenc) and a NAS integrity key (KNASint), which are used in encryption and integrity protection, respectively, of NAS messages before transmitting.

AS Security: The purpose of AS security is to securely deliver RRC messages between a UE and an eNB in the control plane and IP packets in the user plane using AS security keys. The AS security keys are derived from KeNB and new keys are generated every time a new radio link is established (that is, when RRC state moves from idle to connected)1. After the AS security setup is completed, the UE and the eNB get to sharean RRC integrity key (KRRCint), RRC encryption key (KRRCenc) and user plane encryption key (KUPenc). Encryption and integrity protection using these keys are performed at the PDCP layer. KRRCint and KRRCenc are used to securely deliver RRC messages in the control plane through an SRB (Signaling Radio Bearer) over radio links. The RRC messages are encryptedusing KRRCenc and integrity checked using KRRCint at the PDCP layer before being sent. KUPenc is used to securely deliver IP packets in the

user plane through a DRB (Data Radio Bearer) over radio links. The IP packets are encrypted using KUPenc at the PDCP layer before being sent.NAS Security

A NAS security setup procedure consists of NAS signaling, between a UE and an MME, by a Security Mode Command message that the MME sends to the UE and a Security Mode Command message that the UE sends to the MME. Descriptions of the NAS security setup procedure by NAS messages and how NAS messages are delivered thereafter.

NAS Security Setup

(1) Delivering a Security Mode Command message

Figure below shows how a Security Mode Command message isdelivered during the NAS security setup procedure. The MME, by sending a Security Mode Command message to the UE, informs the UE that it is authenticated by the network and the NAS security setup procedure for secure message delivery between them is initiated. The Security Mode Command message is integrity protected and then sent to the UE, which then derives NAS security keys (a ciphering key and an integrity key) andverifies the integrity of the message using the integrity key. A simplified LTE authentication procedure that precedes the NAS security setup procedure is shown as   and (2) in Figure 2[1]. The same KASME is shared by the UE and the MME as a result of the LTE authentication. We will explain the NAS security setup procedure presuming the MME allocatesa KSIASME to identify KASME as 1 ("001").

 [MME] Selecting security algorithmsThe MME selects ciphering and integrity algorithm to be applied to NAS messages based on UE Network Capability information included in the received Attach Request message from the UE. Figure 2 shows an example ofselecting EEA1 for an encryption algorithm and EIA1 for an integrity algorithm, i.e., SNOW 3G algorithm. 

 [MME] Deriving NAS security keysThe MME derives KNASint and KNASenc from KASME using the algorithm IDs and algorithm distinguishers of the selected security algorithms. Table 1 lists algorithm IDs and algorithm distinguishers [2].

  KNASint = KDF(KASME, NAS-int-alg, Alg-ID) KNASenc = KDF(KASME, NAS-enc-alg, Alg-ID)

 It is applied when using relay nodes. As relay is out of the scope of this document, user plane integrity algorithms are not discussed herein.

 [MME] Generating NAS-MAC for integrity protectionThe MME forms a Security Mode Command message to send to the UE and calculates NAS-MAC(Message Authentication Code for NAS for Integrity) using the selected EIA algorithm (EIA1) with input parameters such as

the Security Mode Command message and KNASint derived in  . Figure below shows how NAS-MAC is calculated using the following EIA algorithm input parameters[2]: 

Count: 32-bit downlink NAS count  Message: NAS message, i.e., Security Mode Command message herein Direction: 1-bit direction of the transmission, 0 for uplink and 1 for

downlink (set to 1 herein) Bearer2: 5-bit bearer ID, constant value (set to 0) KNASint: 128-bit NAS integrity key

 [UE ← MME] Sending a Security Mode Command message

The MME attaches the NAS-MAC calculated in   at the end of the Security Mode Command message and sends it to the UE. Here the message is integrity protected but not ciphered. Message parameters used are as follows: 

KSIASME: 3-bit value associated with a KASME, used to identify the KASME (KSIASME=1 herein)

Replayed UE Security Capability: UE Security Capability included in the UE Network Capability in the Attach Request message sent by UE, indicateswhich security algorithms are supported by the UE

NAS Ciphering Algorithm: NAS ciphering algorithm selected by the MME, EEA1 herein

NAS Integrity Protection Algorithm: NAS integrity protection algorithm selected by the MME, EIA1 herein

 

 [UE] Setting KASME identifier (KSIASME)When the UE receives a Security Mode Command message from the MME, it sets KSIASME in the message as its KSIASME and uses it as an identifier of the current KASME.

 

 [UE] Deriving NAS security keys

The UE, recognizing the NAS security algorithm that the MME selected, derives KNASint and KNASenc from KASME using the algorithm IDs and the algorithm distinguishers(see table after step 2) 

 [UE] Verifying the integrity of the Security Mode Command messageThe UE checks the integrity of the received Security Mode Command messageby verifying the NAS-MAC included in the message. It recognizes the NAS integrity algorithm selected by the MME is EIA1 and calculates XNAS-MAC, a message authentication code, by using the selected EIA1 algorithm with

the Security Mode Command message and KNASint derived in  . Figure 4 shows how XNAS-MAC is calculated using the same EIA input parameters as

in  [2]. The UE verifies the integrity of the message by examining whether the XNAS-MAC calculated by itself matches the NAS-MAC calculated by the MME. If they match, it is guaranteed that the Security Mode Command message has not been manipulated (e.g., inserted or replaced) on the way. 

(2) Delivering Security Mode Complete message

Figure below illustrates how a Security Mode Complete message is delivered during the NAS security setup procedure. The UE, by sendinga Security Mode Complete message to the MME, informs the MME that thesame NAS security keys as MME's are derived in the UE and that the integrity of the Security Mode Command message is verified. The Security Mode Complete message is ciphered and integrity protected for transmission.

 [UE] Encrypting the message using the selected encryption algorithm (EEA1)The UE forms and encrypts the Security Mode Complete message to be sent to the MME. The ciphered Security Mode Complete message (Cipher Text Block) is derived by performing bitwise XOR between the Security Mode Complete message (Plane Text Block) and the encryption key stream (Key Stream Block) generated using EEA1 algorithm with NAS encryption key (KNASenc). Figure 6 shows how NAS messages are encrypted [2]. EEA algorithminput parameters used to generate the key stream block are as follows:

 

Count: 32-bit uplink NAS count   Bearer: 5-bit bearer ID, constant value (set to 0) Direction: 1-bit direction of the transmission, 0 for uplink and 1 for

downlink (set to 0 herein) Length: the length of the key stream to be generated by the encryption

algorithm KNASenc: 128-bit NAS ciphering key

 

 [UE] Generating NAS-MAC for integrity protectionThe UE calculates NAS-MAC using EIA algorithm (EIA1) with the ciphered Security Mode Complete message and KNASint. Figure 3 shows how NAS-MAC is calculated using the following EIA algorithm input parameters: 

Count: 32-bit uplink NAS count Message: NAS message, Security Mode Complete message herein Direction: 1-bit direction of the transmission, 0 for uplink and 1 for

downlink (set to 0 herein) Bearer: 5-bit bearer ID, constant value (set to 0) KNASint: 128-bit NAS integrity key

 

 [UE → MME] Sending the Security Mode Complete messageThe UE attaches the NAS-MAC calculated in   at the end of the SecurityMode Command message and sends it to the MME. Here the message is integrity protected and ciphered, and all the NAS messages that the UE sends to the MME hereafter are securely delivered. 

 [MME] Verifying the Integrity of the Security Mode Complete messageThe MME checks the integrity of the received Security Mode Complete message by verifying NAS-MAC included in the message. MME

calculates XNAS-MAC, a message authentication code, by using the selectedEIA1 algorithm with the Security Mode Complete message and KNASint. Figure 4shows how XNAS-MAC is calculated using the same EIA input parameters as

in  . The MME verifies the integrity of the message by examining whether the XNAS-MAC calculated by itself matches the NAS-MAC calculated by the UE. If they match, it is guaranteed that the Security Mode Complete message has not been manipulated on the way.

 

 [MME] Decrypting of the Security Mode Complete messageAfter successful verification of the Security Mode Complete message, the MME decrypts the message using EEA algorithm (EEA1). Then the Security Mode Complete message, the original message generated by the UE, is derived through XOR between the ciphered Security Command Complete message and the key stream block. Figure below illustrates how the message is decrypted using the same EEA algorithm input parameters as

in  . 

After NAS Security Setup

Once the NAS security setup is completed as in section above, all theNAS messages between the UE and the MME thereafter are encrypted and integrity protected before being sent. Figure 8 shows how NAS messages are delivered between the UE and the MME after the NAS security setup.

When NAS messages are being sent, they are encrypted first and then integrity protected before being sent. The original NAS messages are first encrypted using an encryption key (KNASenc) and then integrity protected by including NAS-MAC calculated using an integrity key (KNASint) so that the messages are delivered as encrypted and integrity protected. When received, however, the NAS messages are integrity verified first andthen decrypted, which is in the opposite order of what has been done whenthey were sent. That is, the integrity of the NAS messages is verified first by comparing the XNAS-MAC calculated using the integrity key (KNASint) and the received NAS-MAC, and then the messages are decrypted to get the original NAS messages. 

AS Security

An AS security setup procedure consists of RRC signaling, between a UE and an eNB, by a Security Mode Command message that the eNB sends

to the UE and a Security Mode Complete message that the UE sends to the eNB. Descriptions of the AS security setup procedure by RRC signaling and how RRC messages in the control plane and IP packets inthe user plane are transmitted

AS Security Setup

(1) shows how a Security Mode Command message is delivered and (2) demonstrates how a Security Mode Complete message is delivered. 

(1) Delivering a Security Mode Command message Figure 9 and 10 are illustrations of how a Security Mode Command message is delivered during the AS security setup procedure. The Figures show howthe message is processed at the eNB and at the UE, respectively. First, Figure 9 shows how the eNB derives AS security keys and delivers the Security Mode Command message to the UE. KeNB, an AS security base key, is derived from KASME and the eNB derives AS security keys from KeNB. Since KASME is not delivered to the eNB, the MME derives KeNB from KASMEand forwards it to the eNB, which then derives AS security keys based on the forwarded KeNB.

 and in blue (2) show the LTE authentication procedure

 [MME] Deriving KeNB

The MME derives KeNB using a key derivation function with KASME and UL NAS Count. 

 [eNB ← MME] Forwarding KeNB

The MME forwards the Attach Accept message to the UE as a response to the Attach Request message in blue  . This NAS message is delivered through an Initial Context Setup Request message, an S1 signaling messagebetween the eNB and the MME. Message parameters used are as follows:

UE Security Capability: security algorithms selected by the MME in the UENetwork Capability in the Attach Request message sent by the UE

Security Key: 256-bit KeNB

 

 [eNB] Selecting security algorithmsThe eNB selects ciphering and integrity algorithms to be applied to RRC messages and IP packets based on the UE Security Capability information

included in the received Initial Context Setup Request message from the MME. Figure 9 shows an example of selecting EEA1 for an encryption algorithm and EIA1 for an integrity algorithm. 

 [eNB] Deriving AS Security KeysThe eNB derives KRRCint, KRRCenc and KUPenc from KeNB using the algorithm IDs andalgorithm distinguishers of the selected security algorithms (see Table 1). 

KRRCint = KDF(KeNB, RRC-int-alg, Alg-ID) KRRCenc = KDF(KeNB, RRC-enc-alg, Alg-ID) KUPenc = KDF(KeNB, UP-enc-alg, Alg-ID)

 

 [eNB] Generating MAC-I for integrity protectionThe eNB forms a Security Mode Command message to send to the UE and calculates MAC-I (Message Authentication Code for Integrity) using the

selected EIA algorithm (EIA1) with KRRCint derived in  .Calculation of MAC-I is illustrated in Figure 3 and the EIA input parameters used are as follows: 

Count: 32-bit downlink PDCP count   Message: RRC message, i.e., Security Mode Command message herein Direction: 1-bit direction of the transmission, 0 for uplink and 1 for

downlink (set to 1 herein) Bearer: 5-bit radio bearer ID  KNASint: 128-bit AS integrity key

 

 [UE ← eNB] Sending Security Mode Command message

The eNB attaches the MAC-I calculated in   at the end of the Security Mode Command message and sends it to the UE. Here the message is integrity protected but not ciphered. Message parameters used are as follows: 

AS Ciphering Algorithm: AS ciphering algorithm selected by eNB, EEA1 herein

AS Integrity Protection Algorithm: AS integrity protection algorithm selected by eNB, EIA1 herein

Figure below shows how the UE derives AS keys from the Security Mode Command message received from the eNB and verifies the integrity of the message.

 [UE] Identifying security algorithms: EEA1, EIA1The UE identifies which AS encryption and integrity algorithms are selected by the eNB when it receives the Security Mode Command message from the eNB. Figure 10 shows an example of selecting EEA1 and EIA1.

 

 [UE] Deriving AS security keysThe UE derives KRRCint, KRRCenc and KUPenc from KeNB using the algorithm IDs and the algorithm distinguishers of the identified security algorithms (see Table 1).

 

 [UE] Verifying the integrity of the Security Mode Command message

The UE verifies the MAC-I included in the Security Mode Command message

using the integrity key (KRRCint) derived in  . During this verification,it is checked whether the XMAC-I calculated by UE matches the MAC-I calculated by the eNB. If they match, it is guaranteed that the Security Mode Command message has not been manipulated on the way. Calculation of XMAC-I is illustrated in Figure 4 and the same EIA input

parameters used in   are used. (2) Delivering a Security Mode Complete message Figure 11 shows how a Security Mode Complete message is delivered during the AS security setup procedure. The UE, by sending the Security Mode Complete message to the eNB, informs the eNB that the same AS security keys as eNB’s are derived in the UE and that the integrity of the Security Mode Command message is verified. Now, the Security Mode Complete message is delivered as integrity protected.

 [UE] Generating MAC for integrity protectionThe UE calculates MAC-I using EIA algorithm (EIA1) with the Security ModeComplete message and KRRCint. Calculation of MAC-I is illustrated in Figure

3 and the same EIA input parameters used in   are used. 

 [UE → eNB] Sending the Security Mode Complete message

The UE attaches the MAC-I calculated in   at the end of the Security Mode Complete message and sends it to the eNB. Here the message is

integrity protected, and all the RRC messages and IP packets sent betweenthe two hereafter are delivered as integrity protected over radio links. 

 [eNB] Verifying the integrity of the Security Mode Complete messageThe eNB checks the integrity of the received Security Mode Complete message by verifying the MAC-I included in the message. The eNB calculates XMAC-I, a message authentication code, by using the selected EIA1 algorithm with the Security Mode Complete message and KRRCint. The eNBverifies the integrity of the message by examining whether the XMAC-I calculated by itself matches the MAC-I calculated by the UE. If they match, it is guaranteed that the Security Mode Complete message has not been manipulated on the way.

After AS Security Setup

Once the AS security setup is completed as in Section above, all the RRC messages delivered between UE and eNB thereafter are encrypted and integrity protected and all the IP packets are encrypted before being sent. Figure below shows how RRC messages and IP packets are delivered between the UE and the eNB after the AS Security setup.

When RRC messages are being sent, they are encrypted first and then integrity protected before being sent, just like NAS messages were. The original RRC messages are first encrypted using the encryption key (KRRCenc) and then they, including MAC-I calculated using the integrity key(KRRCint), are integrity protected. That way, the messages are delivered asencrypted and integrity protected. When received, however, RRC messages are integrity verified first and then decrypted, which is in the opposite order of what has been done whenthey were sent. That is, the integrity of the RRC messages is verified first by comparing the XMAC-I calculated using the integrity key (KRRCint) and the received MAC-I, and then the messages are decrypted using KRRCenc to get the original RRC messages. User packets are encrypted but not integrity protected. The user packets encrypted by a sender using the encryption key (KUPenc) are decrypted by the receiver using the same encryption key (KUPenc) to get the original user packets.

Security Context

Data relating to security that has been set in the EPS entities during these procedures is called an EPS security context, which can be either a NAS security context or an AS security context. A NAS security context can be one of the two types, "full native" or "partial native". A NAS security context is called as "partial native" after EPS AKA isperformed and before the first SMC (Security Mode Command) procedure begins. A partial native EPS NAS security context is transformed intoa full native after the SMC procedure is completed. Table 2 lists these EPS security contexts3.

Figure below displays the key LTE security data stored in EPS entities as a result of the EPS AKA and NAS/AS security setup procedures. It shows how each security data is generated (e.g. provisioning, calculated by itself) and the data transfer flow (à) indicating from which data each security data is delivered.

In the LTE Security we have covered some of the key LTE security technologies, including EPS AKA-based LTE authentication, NAS and AS setup procedures, and security data in EPS entities. We have learned thatLTE security keys have their own hierarchy, which are separated and used for different purpose. The top-level key is K, an LTE key, and it has a permanent value stored in USIM and HSS (AuC). From this K, CK and IK are derived and then KASME is derived from CK and IK. 

NAS keys (KNASint, KNASenc) and KeNB are derived from KASME. And from KeNB, AS security keys (KRRCint, KRRCenc, KUPenc) are derived. We have also found that different keys are derived from a UE, eNB or MME depending on whether they are intended for the NAS level or the AS level, for the control plane or the user plane, and for ciphering or integrity check, or which algorithms are used. Table 3 lists all the LTE securities keys that have covered so far.

1 During handover, a new key is generated even when RRC state is active. However, since security during handover is out of the scope of this document, it is not covered herein.2  As there is only one NAS signaling connection between a UE and an MME, technically no bearer is needed. However, it was included here so that the same input parameters are used in calculating both NAS MAC (NAS-MAC) and AS MAC(MAC-I).3 As handover security is beyond the scope of this document, handover-related data (NH, NCC, KeNB*) are not included herein. 

LTE Identification : UE and ME Identifiers

Introduction

In LTE network, different IDs are used to identify each entity depending on their relationship with other IDs just like different names and titlesare used to refer to a person - a name (e.g. James), or a title at work (e.g. Manager James, James from Netmanias, James from Google, etc.) or at

home (e.g. son, dad, uncle, etc.) - in human network. Understanding theseIDs as well as the EPS entities defined in [1] is essential to understandLTE technologies. We have previously discussed the LTE network architecture, our first topic in LTE area. Now we will cover LTE identification, our second topicin the area, in a series of three companion documents. This document is the first of the series and will focus on user equipment (UE) IDs. The second and third documents will specifically cover network equipment (NE)IDs and EPS sessions/bearers, respectively.

Classification of LTE Identification

Figure below shows, using the LTE network reference model [1], IDs defined and used in some entities and interfaces. Features of these LTE IDs will be explained in terms of their creation time, attribute type (permanent/temporary) and ranges within which they are uniquely identified.

Creation Time: Creation time of an LTE ID can be one of the following:

When commissioned upon equipment installation When provisioned by the operator before or during service operation When created on-demand as a user accesses to the network or uses services

LTE IDs commissioned or provisioned are presented with the blue boxes on the corresponding EPS entities in Figure 11. Type: An LTE ID can have an attribute type, either a permanent value thatstays fixed once set, or a temporary one that changes whenever activated.The ones allocated by being commissioned or provisioned have permanent values while others allocated on-demand as a user accesses to the networkor uses services have temporary values. Range (within which IDs are uniquely identified): Each LTE ID is uniquelyidentified across the world, operator networks, entities or channels. 

Figure shows different IDs used depending on where LTE identification isactually being performed, i.e., layers, interfaces or geographical areas.For the convenience of description, the IDs shown in Figure 1 are groupedas seen in Table 1. First, IDs for the EPS entities are grouped into UE IDs, ME IDs and NE IDs. The EPS entities are classified into UEs and NEs. MEs, one of the UEcomponents, are separated from UEs and classified as a separate group.NEs are the network entities operated by an LTE operator such as MMEs, eNBs and P-GWs. IDs, such as IMSI, GUTI, S-TMSI, IP address, C-RNTI, UE S1AP ID and UE X2AP ID that identify a user, belong to the UE ID group. IDs such IMEI and IMEISV that identify a device belongs to the ME ID group. 

And IDs, such as GUMMEI and MMEI for MMEs, Global eNB ID and eNB ID for eNBs, ECGI and ECI for cells, and P-GW ID for P-GWs, belong to the NE ID group. Location IDs, such as TAI and TAC, identify the area where a user is located. Finally, session/bearer IDs, such as PDN ID(or APN), EPS bearer ID, E-RABID, DRB ID, TEID and LBI, are related to user traffic delivery, and identify EPS sessions (PDN connections) and EPS bearers. This document, the first document in the LTE Identification series, describes LTE IDs for UE and ME shown in gray in Table 1. The second document will explain LTE NE IDs and location IDs which identify locationof UEs, and the third document will discuss IDs for EPS session/bearer.

Identifiers for User Equipment (UE IDs)

LTE networks are all IP networks. Because of such nature, UEs in an LTE network share radio and network resources. EPS entities of the LTE network allocate a UE ID to each UE to identify it. Because the UEs shareresources in various layers and interfaces, various UE IDs are required. The most essential ID in a mobile communication network is the Public Land Mobile Network (PLMN) ID which identifies the operator of a particular network. So, we will begin the description of UE IDs with the PLMN ID.

PLMN ID indicating the network that a user has subscribed to

PLMNs are constituted and operated by operators2 for the purpose of providing mobile communication services to the public. A PLMN ID is used globally to identify the mobile communication network that a user has subscribed to. It consists of an MCC (Mobile Country Code) and an MNC (Mobile Network Code) as shown in Figure 2. The three-digit MCC identifies the country where the mobilenetwork in use is located. And each country may have one or more PLMN IDs as needed. The MCC allocation is administered by the ITU-T and defined in ITU-T E.212 [3]. For example, Korea has the MCC value of 450. An MNC identifies the operator of a mobile communication network and is allocated by each country. For example, there are three mobile operators in Korea: SK Telecom, KT and LG U+, and their MNCs are shown in Figure below .

IMSI: Permanent ID allocated to a mobile subscriber

International Mobile Subscriber Identity (IMSI) is a unique number identifying a mobile subscriber globally. Figure below shows an allocation process of an IMSI and the format of the IMSI. An IMSI is composed of a PLMN ID that indicates the network the user subscribes to and a Mobile Subscriber Identification Number (MSIN) that is assigned by the operator. The IMSI can have a maximum length of 15-digits. The MSIN identifies a mobile subscriber within a PLMN.

When a user purchases a USIM (only USIM or USIM with a phone) and subscribes to a mobile network, a built-in unique number called International Mobile Subscriber Identity (IMSI) becomes effective and associated with the user. The IMSI is stored in the USIM inside the phone, and the subscription information with the IMSI is provisioned to aHome Subscriber Server (HSS) and Subscriber Profile Repository (SPR) by the operator3. After being provisioned, the IMSI is sent by the UE to themobile network when the UE attaches to the LTE network4. After receiving the IMSI from the UE, an MME begins establishment of a default EPS bearer, the basic transport path in the LTE network, by (i) identifying the home network of the subscriber based on the IMSI received from UE, (ii) selecting an HSS holding the subscription information of the subscriber and (iii) downloading the information from the HSS. The IMSI installed in the USIM, HSS and SPR is a permanent value not to be removed. On the other hand, the IMSI stored in the MME, S-GW, P-GW andPCRF while establishing a default EPS bearer during a UE’s initial attachprocess is a temporary value to be removed when the default EPS bearer isterminated.

IDs Used at MME: GUTI, S-TMSI and M-TMSI

An IMSI is a permanent and unique ID that identifies a mobile subscriber.There might be security problems if it is frequently exposed over the radio link. For security enhancement, a Globally Unique Temporary Identifier (GUTI) is allocated to a UE by an MME when the UE attaches to the Network, and used instead of the IMSI to identify the UE. Figure below shows the allocation process and format of a GUTI.

GUTI allocation: When a UE attaches to a LTE Network for the first time, it uses its IMSI to request access to the network and obtains a GUTI allocated by the network (i.e. MME). The UE thereafter uses the GUTI, instead of IMSI, when it attaches again to the network. Whether the UE uses IMSI or GUTI as its ID when reattaching to the network depends on which value is being set as Temporary Identifier used in Next update (TIN). Once the initial attach process or the tracking area update (TAU)5 procedure of the UE is performed successfully, the MME allocates and sends a GUTI to the UE6, which then sets the GUTI as its TIN. The GUTI is used thereafter instead of the IMSI when the UE attaches to the network or requests TAU update. GUTI format: An LTE operator can have one or more than one MME groups consisting of multiple MMEs. An MME Identifier (MMEI in Figure 4), therefore, is made up of an MME Group Identifier (MMEGI) that represents an MME group and an MME Code (MMEC) that represents an MME within the MME

group. A Globally Unique MME Identifier (GUMMEI) is created by adding a PLMN ID to the MME ID. Each MME allocates an MME Temporary Mobile Subscriber Identity (M-TMSI), the unique value in the MME, to each registered subscriber to preserve the subscriber’s confidentiality.A GUTI, composed of a GUMMEI and an M-TMSI, is a globally unique value and is used instead of an IMSI to identify a UE. Unlike an IMSI that has a fixed value, it has a temporary value that is allocated by an MME whenever a UE is registered to the LTE network. So the GUTI can still be kept secure even when frequently exposed over the radio link. An S-TMSI consisting of an MMEC and an M-TMSI is used to uniquely identify a UE within an MME group. It is shorter than a GUTI and thus it helps to improve transmission efficiency on radio links if used in an operator’s network that does not have more than one MME groups. IP Address: ID Necessary to Connect to a PDN

An IP address, also called as a “PDN address” is allocated by an LTE network to a UE in order for the UE to connect to a PDN (i.e. an IP network) when the UE initially attaches to the LTE network. Because a UE can be connected to more than one PDN through an LTE network depending onthe services, the LTE network allocates each UE a different IP address per each PDN the UE is connected to (e.g. two IP addresses for a UE with two connected PDNs, three IP addresses for one with three PDNs, and so on.). These IP addresses (PDN addresses) are used to identify the UE from/to which an IP packet is sent when the IP packet is forwarded from an LTE network to a PDN, or received from a PDN. An IP address is allocated to an UE either permanently or dynamically forthe UE to connect to the PDN. These two types of allocation are called static IP address allocation and dynamic IP address allocation, respectively.In case of static IP address allocation, an operator allocates a permanent IP address to a UE at the time of subscription, and provisions the UE’s IP address to an HSS (as shown in Figure 1). That way, the UE isassigned the same IP address every time it initially attaches to the PDN regardless of the time and location of such attach. In case of dynamic IPaddress allocation, a P-GW has an IP pool (as shown in Figure 1) and dynamically assigns an available IP address from the pool every time a UEperforms initial attach to an LTE network. Therefore, a different IP address is assigned to a UE upon each initial attach of the UE to the network. 

Figure 5 shows an example of dynamic IP address allocation. It provides abrief illustration of the procedure during which the P-GW dynamically allocates a temporary IP address when a default EPS bearer is establishedduring the initial attach process (See “Initial Attach” document for detailed procedure of default EPS bearer establishment) and the procedureduring which the UE uses the Internet service after allocating an dynamicIP address during the initial attach process (See [1] for the Internet traffic flow).

C-RNTI: ID required to distinguish UEs within a Cell

Cell Radio Network Temporary Identifier (C-RNTI) is allocated to a UE by an eNB through a random access procedure in a cell controlled by the eNB and is effective only within the [serving] cell. UEs in the cell are uniquely identified by their C-RNTI. A new C-RNTI is allocated when the UE leaves the current cell and moves to a new cell through a random access procedure. Figure below shows how a C-RNTI is allocated and to which layer the C-RNTI is applied to. An eNB is responsible for allocating radio resources to UEs on uplink anddownlink. It notifies which UE can use the radio resources in the next Transmission Time Interval (TTI)7 by broadcasting a C-RNTI on Physical Downlink Control Channel (PDCCH). If a UE finds its C-RNTI on the PDCCH in the cell it accessed, the UE then realizes it can use the radio resources in the next uplink or downlink TTI. 

Paired UE S1AP IDs needed to distinguish UEs over the S1-MME Interface

S1AP layer handles the control messages between an eNB and an MME over anS1-MME interface. Many UEs stay connected to an eNB at the same time. Andthe eNB uses the same S1 link for all the S1AP control messages it exchanges with an MME with respect to the UEs. So, in order to tell whichS1AP message is for which UE, an eNB allocates an ID (eNB UE S1AP ID) to each UE when it sends the first S1AP message for a UE to an MME.

Likewise, one MME exchanges S1AP messages with many eNBs (e.g. more than hundreds) and through many S1 links concurrently. Again, in order to tellwhich S1AP message is for which UE in which eNB, the MME allocates an ID (MME UE S1AP ID) to each UE when it sends the first message for a UE to an eNB. After this very first round trip of S1AP message, all the user control messages (S1AP messages) exchanged over the S1-MME interface are delivered with a pair of UE S1AP IDs (eNB UE S1AP ID, MME UE S1AP ID) in order that the eNB and the MME can tell which S1AP message is for which UE. Then, with the paired IDs, the MME can find out which UE in which eNBthe received S1AP message is for, and the eNB can also tell which UE the received S1AP message is for. Figure below shows the process of UE S1AP ID allocation and the S1AP layer where the UE S1AP ID is applied.

Paired UE X2AP IDs needed to distinguish UEs over the X2 Interface

X2AP layer handles the control messages (X2AP messages) between two neighbor eNBs over an X2 interface.During each handover of UEs between two neighbor eNBs, the X2AP messages from the UEs are delivered to the peer eNB using the same X2 link. The first time an eNB (source eNB or target eNB) sends a X2AP message to a peer eNB, the eNB assigns an ID to each UE and sends the message with theID in order to show for which UE the X2AP message is. A source eNB allocates an Old eNB UE X2AP ID to its first message (Handover Request message) to a target eNB, which also allocates a New eNB UE X2AP ID to its first response message (Handover Request Acknowledge message) to the source eNB. 

After this very first round trip, all the handover-related X2AP messages over the X2 interface are exchanged with a pair of IDs (Old eNB UE X2AP ID, New eNB UE X2AP ID) in order that the source eNB and the target eNB can tell which X2AP messages are for which UE. Figure 8 shows the processof UE X2AP ID allocation and the X2AP layer where the UE X2AP ID is applied.

Identifiers for Mobile Equipment (ME IDs)

This section describes IDs of Mobile Equipment (ME). The relationship between UEs and MEs is described first before ME IDs are discussed. A UE consists of an ME and a UMTS Subscriber identity Module (USIM), and an MEcan further be divided into Terminal Equipment (TE) and a Mobile Terminal(MT). An MT is where radio access protocols work (e.g. USB dongle) while TE is where the MT control functions work. Figure below shows a couple of combinations of such functional groups as examples. The MT and the TE are integrated in a mobile phone, but separated in a note PC.

IMEI and IMEISV: IDs permanently owned by an ME

International Mobile Equipment Identity (IMEI) is a unique number allocated to each mobile equipment (ME). An IMEI is given when an ME is being manufactured, and contains information about the manufacturer, model, and serial number of the ME. Figure below illustrates the format of an IMEI and an example of an IMEI usage. The IMEI is composed of a Type Allocation Code (TAC), a Serial Number (SNR) and a Check Digit (CD).And an IMEI/SV is composed of a TAC, an SNR and a Software Version Number(SVN).A TAC is made up of a Reporting Body Identifier (RBID) that indicates a reporting body (See GSMA “IMEI Allocation and Approval Guidelines” [4] for the RBID list and codes), and an ME Type ID that represents the manufacturer’s name and the model identifier. Serial numbers are assignedby the manufacturer. In the example used in Figure 10, the RBID of “35” indicates the ME was approved by British Approvals Board for Telecommunications (BABT), and the ME Type ID of “643205” shows the ME isa smartphone manufactured by Samsung. An operator has a DB8 storing IMEI information, and thus can deny any access attempted by an ME reported stolen or lost using the DB.

Figure below shows short description about LTE identifiers

1 If SON (Self-Organizing Network) technology is applied, ECGI and TAI/TAI lists may be auto-configured without being provisioned. SON is out of the scope of this document, and hence configuration using SON willnot be discussed herein.2 An operator means an administration or a recognized private operating agency (RPOA) as defined in TS 23.002.3 Unless otherwise specified, an operator means an LTE operator in this document.4 A UE begins initial attach to a LTE network by sending Attach Request message including an IMSI to an MME.5 A UE begins TAU (tracking area update) by sending TAU Request message to an MME.6 An MME delivers a GUTI to an UE through Attach Accept message when the UE initially attaches, and through TAU Accept message when TAU is updated.7 TTI is the duration of an independent decodable transmission on radio links. TTI, also called “sub-frame”, is a unit that constitutes a radio frame. Each TTI has a length of one ms (e.g. a 10 ms radio frame consistsof 10 one ms TTIs (or sub-frames)).8 A DB containing IMEI information is called EIR (Equipment Identity Register).

NE and Location Identifiers

Identifiers for Network Equipment (NE IDs)

This chapter describes IDs related to LTE network equipment (NE). IDs that belong to the NE ID group are GUMMEI and MMEI for MMEs, Global eNB ID and eNB ID for eNBs, ECGI and ECI for cells, and P-GW ID for P-GWs. LTE NE IDs are classified into two groups - one with PLMN ID or one without PLMN ID - depending on whether they are uniquely identified within a PLMN only or globally.

IDs to Identify MME: GUMMEI, MMEI, MMEGI and MMEC

An MME is located between E-UTRAN and EPC. It is the key control equipment that allows, on behalf of an HSS, a UE to attach to an LTE network by exchanging control signals with the HSS which has subscriptioninformation of the UE. It also supports bearer management and UE’s mobility by exchanging control signals with an S-GW (or S/P-GW) on EPC side and with an eNB on E-UTRAN side. As such, to UEs, MMEs serve as brain for the LTE network. In general, LTE operators group multiple MMEs into a group and operate them as MME groups. An MME ID for identifying anMME is allocated by the operator when the MME is installed. An MMEI (MME Identifier) is used when identifying an MME in the network of an operator (e.g. when a network operating personnel at “A” LTE operator needs to identify an MME in “A” LTE network). However, a GUMMEI (Globally Unique MME Identifier), combination of a PLMN ID and an MMEI, is used when identifying an MME outside of the network of the operator (e.g. when “C” is operating the networks of “A” and “B” LTE operators, and “C” needs to identify an MME in “A” LTE network). In case of an MME group formed by the operator, an MMEI consist of an MMEGI that representsan MME group, and an MMEC that represents a particular MME in the MME group. Figure below shows the MME-related IDs and their format.

IDs to identify eNB: eNB ID and Global eNB ID

An eNB ID is used for identifying an eNB within an operator’s network only, whereas a Global eNB ID, combination of a PLMN ID and an eNB ID, isused for identifying one outside the network. Figure below shows eNB/cell-related IDs and their format. To identify a cell belonging to aneNB, an ID created by adding a cell ID to the combination of an eNB ID and a Global eNB ID is used. eNB IDs and cell IDs are allocated by the network operator when an eNB isinstalled. Once installed, the eNB begins a procedure for setting up an S1 link between an MME and itself. When it requests the MME for S1 link setup, it reports its Global eNB ID and supported TAs (See Chapter III for more information about TAs) and a CSG (Closed Subscriber Group) ID ifCSGs are supported. A CSG is a cell open to only a certain group of subscribers, and is made up of a single cell or a collection of cells. The MME sends served GUMMEIs to the eNB as a response to the S1 link setup request, providing MME pool information.

ID to Identify P-GW: P-GW IDWhen a UE attempts to attach an LTE network, the LTE network provides theUE with PDN connection. To set up PDN connection between the UE and a PDN, the MME has to know the PDN to connect the UE and the P-GW to attachthe UE through. The default PDN for the UE has already been provisioned in the HSS as a subscribed profile. So, the MME can simply use this information downloaded from the HSS. For the P-GW, there are two ways of allocating – fixed allocation in which the network operator provisions a P-GW ID as a subscribed profile in the HSS, and dynamic allocation in which the MME selects a P-GW according to the P-GW selection policy set by the operator. In case of fixed allocation, the HSS informs the MME of the P-GW ID, so that the MME can request the P-GW for PDN connection. P-GW IDs are used to identify P-GWs, and can be in either IP address or FQDN (Fully Qualified Domain name) forms. Figure below illustrates the P-GW ID assigned according to the fixed allocation policy and its format. For example, there can be a UE whose default PDNs are allocated as PDN 1 (Internet) for Internet services and PDN2 for voice services. When the UEinitially accesses an LTE network, the MME requests the HSS for subscription information of the UE. The HSS then informs the MME that (i)the default PDNs of the UE are PDN 1 (Internet) and PDN 2 (IMS), and that(ii) the P-GW connecting PDN 1 is P-GW 1 and the one for PDN 2 is P-GW 3.The MME then establishes PDN connection between the UE and the Internet through P-GW 1, and one between the UE and IMS through P-GW 3. For P-GW ID assigned according to the dynamic allocation policy, the MME obtains a P-GW IP address list through DNS query, selects one from the list, and requests the P-GW to establish PDN connection (See “LTE Identification III: Session/Bearer ID” for more information about PDN connection and EPS bearers.). If a P-GW list is provided by DNS, the MME selects one from the list in accordance with the P-GW selection policy.

Identifiers for UE Location (Location IDs) An MME is in charge of managing a UE’s mobility, and thus has to have updated information on the UE’s location. Location of a UE is known by the LTE network at cell level if the UE is in active state and is using services, or at TA level if it is in idle state and thus not using services. Since cell IDs, one of the UE location IDs.

IDs to identify the location of a UE: TAC and TAI

A UE is registered to a network at TA level. An MME also locates a UE in idle state at TA level as well. IDs identifying TAs are TAC (Tracking Area Code) and TAI (Tracking Area Identifier). The TAC is used to identify a TA in the network of an operator, whereas the TAI, combinationof a PLMN ID and a TAC, is used to uniquely identify a TA globally. Figure below shows different types of TA IDs and their formats.

When a UE initially attaches to an LTE network, the UE is registered to the network by an MME. The MME allocates a TAI list to the UE at its initial attach, and keeps track of its location thereafter. For this, theUE informs the MME of its new location and requests for TA update whenever it leaves its registered TA2. This way, the MME knows in which TA the UE is currently located, and keeps the TAI list of the UE updated.The UE does not have to request TA update if travelling to a TA listed inthe TAI list. However, if the current TA renewal period is expired, the UE has to inform the MME of its current TA, even while staying in TAs listed in the list, and let the MME know that it is able to receive data. When data destined to the UE is arrived at the LTE network, the MME needsto know the location of the UE to forward the data properly. If the UE isin active state, the MME knows in which cell the UE is, and hence can simply forward the data. However, if the UE is in idle state, the MME does not know which cell the UE is located in. So, it searches the TA last reported for the UE. In other words, the MME sends aPaging message to all the eNBs belonging to the TA announcing there is data for the UE. A UE in idle state wakes up at certain periods to check for any Paging message. If it finds it has been paged (by checking the S-TMSIin the Paging message), it responds to the message to receive the data. The larger TA means the higher chance of finding the UE easily. But, at the same time, the larger TA also means more eNBs to page, and hence the

greater signaling overhead. How a TAI list is allocated is one of the optimization issues. An eNB learns which MME and TA it belongs to through the provisioning information when it is installed. Each cell in the eNB broadcasts its cell IDs (ECI, ECGI) and TA information (TAC, TAI) as its system information. A UE attempting to access a new cell figures out whether thenew cell is in a different TA from the current one, and hence its TA has to be changed, or the new cell is within its current TA, by listening to the broadcasted system information. Figure 5 illustrates how a UE with an allocated TA list behaves. In the figure, eNB1 is in TA1, eNB2 is in TA2, and eNB3 and eNB4 are in TA3 (A TA can be made up of cells or eNBs. But only those made up of eNBs will be used here). UE1 is registered to MME1 and is assigned a TAI list of {TAI1, TAI2} while UE2 is registered to MME 2 and is assigned a TAI list of {TAI2, TAI3}. After UE1 accessed to eNB1 turns idle, as it travels along the dotted line (eNB1 → eNB2 → eNB3), UE1’s behavior can be described as follows (TAs are checked at cell level. However, UE1’s behavior when switching between cells in an eNB is not discussed here):

While in eNB1: UE1’s current TA is TA1. While traveling from eNB1 to eNB2 (① in Figure ): UE1 learns its new TA

is TA2 by listening to the system information broadcasted by the new cellit is trying to access. It checks the TAI list for TA2 and realizes it does not have to request for TA update because TA2 is listed.

While traveling from eNB2 to eNB3 (② in Figure ): UE1 learns its new TA is TA3 by listening to the system information broadcasted by the new cellit is trying to access. It checks the TAI list for TA3 and realizes it has to send TAU Request message to the MME to have its location updated because TA3 is not listed.

 LTE Identification: NE and Location

1 Antennas may be remotely located away from eNBs (e.g. RRH).2 The UE requests for TA update by sending TAU (Tracking Area Update) Request message to the MME. 

EPS Session/Bearer Identifiers

This document covers EPS Session/Bearer ID groups related to user traffic delivery. Session/Bearer IDs such as Packet Data Network (PDN) ID (Access Point Name (APN)), EPS bearer ID, E-RAB ID, Data Radio Bearer (DRB) ID, Tunnel Endpoint Identifier (TEID) and Linked EPS Bearer Identity (LBI) are described, followed by a summary of the characteristics of these IDs.

Introduction

We have learned about the LTE ID groups such as UE and ME IDs, and Network Equipment (NE) and UE location identifier (location) IDs in earlier sections, respectively. This document, as the third document of the LTE Identification series, describes EPS Session/Bearer IDs related to user traffic delivery. E2E sessions that include application entities are out of the scope of this document, and hence only EPS sessions that provide users with PDN connectivity will be covered herein. In Table ,

EPS Session/Bearer IDs to be discussed herein are shown in the last row with a gray background.

EPS Session and EPS Bearer: Overview  

Before we discuss IDs relating EPS sessions and EPS bearers, an overview of what the EPS sessions and EPS bearers are and what they are like and adescription of the relationship among the IDs will be given. Figure below shows the EPS sessions and EPS bearers of a user, with theirIDs shown underneath.

EPS Session

IP connection between a UE and a PDN is called PDN connection or EPS session. Each PDN connection (or EPS session) is represented by an IP address of the UE and a PDN ID (in other words, Access Point Name (APN)).It has more than one EPS bearer to deliver user traffic (IP packets), andapplies the service quality (QoS) policy obtained from a PCRF to the EPS bearers. The minimum fundamental bearer that an EPS session has for a PDNis called a default EPS bearer. Having an EPS session established means i) a PDN through which a user is to use services has been selected (by the user’s input or based on the subscription information provisioned by an HSS), ii) an IP address to be used in the PDN has been assigned to the user, iii) policy rules to be applied to the user IP packets (QoS and charging rules) have been selected, and iv) a default EPS bearer for delivering IP packets over theLTE network has been established. Through this EPS session established, IP packets can be exchanged between the user and the PDN according to therules set by the operator.Management and operation of sessions, including PCRF, will be explained in other document, and a PDN ID (APN) will be discussed as an ID relatingto the EPS session in this document.

EPS Bearer

An EPS session is in charge of delivering and handling flows of the IP packets that are labeled with UE IP addresses and travel between a UE anda PDN (UE – P-GW – PDN). On the other hand, an EPS bearer is a pipe through which IP packets are delivered over the LTE network, i.e., between a UE and a P-GW (UE – eNB – S-GW - P-GW). A UE can have multiple EPS bearers concurrently. So, different EPS bearers are identified by their EPS bearer ID, which is allocated by an MME.As seen in Figure above, an EPS bearer actually is a concatenation of thefollowing three bearers (DRB, S1 bearer and S5 bearer): 

[UE] - [eNB]: Data Radio Bearer (DRB)

EPS bearer established over LTE-Uu interface. User traffic (IP packet) is delivered through a DRB. Different DRBs are identified bytheir DRB ID, which is allocated by an eNB.

[eNB] - [S-GW]: S1 bearer

EPS bearer established over S1-U interface. User traffic is delivered through a GTP tunnel. Different S1 bearers are identified by their tunnel endpoint identifier (TEID), which is allocated by the endpoints (eNB and S-GW) of the GTP tunnel. 

[S-GW] - [P-GW]: S5 bearer

EPS bearer established over S5 interface. User traffic is delivered through a GTP tunnel. Different S5 bearers are identified by their tunnel endpoint identifier (TEID), which is allocated by the endpoints (S-GW and P-GW) of the GTP tunnel.

 E-RAB is a bearer that has two endpoints of a UE and an S-GW, and consists of a DRB and an S1 bearer. Technically, E-RAB is a concatenationof a DRB and an S1 bearer, and connects from a UE to an S-GW (UE – eNB – S-GW). Different E-RABs are identified by their E-RAB ID, which is allocated by an MME. DRB IDs and E-RAB IDs are mapped with EPS bearer IDson 1:1 basis.

Types of EPS Bearers

Before we go ahead and describe EPS bearer-related IDs, we will look at different types of EPS bearers and how they work. Figure below shows two different types of EPS bearers: default and dedicated. Each PDN must haveone default EPS bearer, but may have none to many dedicated EPS bearers.

The LTE network is an all-IP network, and provides its users with always-on IP connectivity. This means, once a UE connects to a PDN using the IP address assigned at its initial attach to the network, the IP connection

remains connected after a default EPS bearer is established over the LTE network and until the UE detaches from the LTE network (i.e., the PDN connection is terminated). Even when there is no user traffic to send, the default EPS bearer always stays activated and ready for possible incoming user traffic. Additional EPS bearer can be established if the default EPS bearer itselfis not sufficient enough to obtain QoS (see LTE QoS document). The additional EPS bearer established is called a dedicated EPS bearer and multiple dedicated bearers can be created if required by the user or the network. When there is no user traffic, these dedicated EPS bearers can be removed, whereas the default one is never removed and keeps the user staying connected to the network unless the user detaches from the network. Dedicated EPS bearers are linked to a default EPS bearer. The linked bearers are represented by a Linked EPS Bearer Identity (LBI), indicating they are all associated with the same default EPS bearer. IP traffic from or to a UE is delivered through an EPS bearer appropriately depending on QoS class over the LTE network. Uplink IP traffic is mapped from a UE up to the EPS bearer while downlink IP traffic is mapped from a P-GW down to the EPS bearer. 

Identifiers for EPS Session/Bearer (Session/Bearer IDs)

ID to identify PDN: PDN ID (APN)

PDNs are identified by PDN IDs (or Access Point Names (APNs)). An APN, ascan be easily inferred, refers to an access point to a PDN where a user wishes to connect for services/applications. In Figure below, APNs and their format are illustrated. An APN is a combination of a network ID andan operator ID. The network ID is used when identifying PDNs such as Internet or cooperate VPNs or identifying services like IMS that the PDN provides. An APN is provisioned to an HSS as subscription information at the time of a user’s subscription (as in case 1 of Figure below)2. Upon a UE’s initial attach, a default APN is downloaded from the HSS to an MME. The MME selects a PDN to connect the UE based on the APN first, and then a P-GW through which the UE is connected to the PDN . In Figure below, the MME selected PDN 1 based on APN 1, and then P-GW 1 for connection to PDN 1. 

ID to indicate user traffic delivery routes over the EPS network: EPS Bearer IDs

An EPS bearer is virtual connection set between a UE and a P-GW to deliver user traffic over the LTE network. Different bearers in the EPS bearer are identified by 4-bit EPS bearer IDs. Table 2 show EPS bearer IDvalues and their allocation ranges. A UE can have up to 11 EPS bearers and their ID values can range from 5 to 15.  

Figure below is an illustration of EPS bearer related IDs and their respective allocators. IDs for EPS bearers, default or dedicated, are allocated by an MME. When a UE initially attaches an LTE network, the MMEobtains QoS profile needed to establish a default EPS bearer from an HSS,and sets up the bearer based on the received QoS. The setup procedure of the default EPS bearer is initiated when an EPS bearer ID is allocated bythe MME.

The two endpoints of an EPS bearer are a UE and a P-GW. They both performtraffic flow filtering - the UE filters uplink user traffic while the P-GW does downlink traffic - to decide through which bearer the traffic is to be sent (See LTE QoS document for more information about traffic flow filtering). Figure 2 shows an example of downlink user traffic that consists of five IP flows, 1 through 5. When the IP flows arrive at the P-GW through the PDN, the P-GW performs traffic flow filtering to decide to which EPS bearer each IP flow is to be delivered, and delivers accordingly. Downlink EPS bearer traffic is delivered through S5 bearer, S1 bearer and DRB, and finally arrives at the UE, which forwards the traffic, in IP flows, to upper layers. To make this happen, each entity must map the bearer IDs in each bearer as seen in Table 3. Figure below is an illustration of such mapping process.

ID to identify EPS bearers between UE and EPC: E-RAB ID

As seen in the series of figures above, E-RAB is an EPS bearer set between a UE and an S-GW, and identified by a 4-bit E-RAB ID. The E-RAB ID is assigned by an MME, generally with the same value as the EPS bearerID, upon establishment of the EPS bearer, and is mapped with the EPS bearer IDs on 1:1 basis. When, during the setup procedure of the EPS bearer, the MME requests the eNB for e-RAB setup, the eNB creates DRB with the UE and S1 bearer with the S-GW. The default EPS bearer keeps the UE connected to the network. When there is no user traffic and thus the UE state changes to idle, E-RAB is deactivated and only the S5 bearer stays on. However, as soon as new usertraffic arrives, E-RAB is re-established, allowing the traffic to be delivered between the UE and the P-GW.

ID to identify EPS bearers over radio link: DRB ID

An EPS bearer, is set over the radio link between a UE and an eNB, and identified by a 4-bit DRB ID. The DRB ID is assigned by an eNB upon establishment of the EPS bearer, and is mapped with EPS bearer IDs on 1:1

basis. When, during the setup procedure of the EPS bearer, the MME requests the eNB for E-RAB setup, the eNB creates DRB for communication with the UE by assigning a DRB ID and selecting logical channel configuration parameters based on the required QoS.

ID to identify the endpoints of a GTP tunnel: TEID

S1 and S5 bearers, both EPS bearers, are established between an eNB and an S-GW, and between an S-GW and a P-GW, respectively, in forms of GTP tunnels. GTP tunnels are identified by Tunnel Endpoint Identifiers (TEID), in 32-bit integer, of two endpoints in uplink and downlink. Figure 4 shows TEID allocators in S1 and S5 GTP tunnels. While EPS bearers are being set up, for S5 bearer, the S-GW allocates DL S5 TEID and the P-GW allocates UL S5 TEID. However, for S1 bearer, the S-GW assigns UL S1 TEID and the eNB assigns DL S1 TEID (See [3] for more information on how user traffic flows through GTP tunnels). 

ID to connect a default EPS bearer and dedicated EPS bearers: LBI

one EPS session can have more than one EPS bearer. The default EPS bear is activated/de-activated when the EPS session is created/terminated. On the other hand, the dedicated EPS bearers can be created or removed at any time once the EPS session is created. Since both of the bearers (the default and the dedicated EPS bearers) belong to the same PDN for the same user, an ID to indicate the two are intended for the same PDN is needed. For such purpose, an ID called LBI is used, and the default EPS bearer ID is used as the LBI. When a default EPS bearer is created, the MME allocates a bearer ID, which also is assigned as a LBI. Later, when dedicated EPS bearers are established, the MME assigns LBIs along with bearer IDs to identify the default EPS bearer.

1 A PDN ID (APN) is used to identify a PDN in an operator’s network as well as in a UE. It is classified as a session ID in LTE Identification documents and will be discussed along with other session IDs in this document.2 An APN can also be provided by a UE