EMM ProcedureInitial Attach-Cases of Initial AttachCases 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 to the 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 identify itself. When the MME sends the Attach Accept (GUTI and TAI list) message, it includes a GUTI, an ID that the UE can use instead of IMSI, 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 required in 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 attached last 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 have any valid UE context about the user (UE). We will distinguish the types 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 the UE 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 doesnt 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 HSS that the UE is registered with it, and downloads the subscription information 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 doesnt 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 doesnt 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. due to 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 UEs 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 doesnt have 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 doesnt have the valid UE context relating 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 GUTI that 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 doing so, 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 or no 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. The UE 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 UEs 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 valid Last 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 assigned by itself. Then, it looks up the Old GUTI, and finds the valid UE context 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 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 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 assigned 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 doing so, 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 MM context 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 UEs 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 Identity Response 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 UEs 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 generating authentication 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 UEs current location (MME). The MME will perform location updates only when i) the UE sends an IMSI as its UE ID, ii) the MME doesnt have the valid Last UE Context of the UE, iii) the MME doesnt 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 users 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 doesnt 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/default EPS 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/default EPS 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 immediately establish 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 UEs 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 MMEs integrity check on NAS-MAC passes, the New MME receives the IMSI and MM context, and thus doesnt perform procedures for authentication and NAS security setup. However, since the MME is changed, the New MME communicates with the HSS to have the UEs location updated, and then establishes an EPS session/default EPS bearer.10 The HSS updates the UEs 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 be further 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 anAttach Request(includingIMSIandUE Network Capability) message to request initial attach to the NAS layer of the MME.In order for theAttach Requestmessage 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 Completemessage) when passing through the RRC 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 anRRC 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 UEs in 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 anRRC Connection Setupmessage, 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 theRRC Connection Setupmessage. 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 anRRC Connection Setup Completemessage through SRB 1 and DCCH (Dedicated Control Channel). For efficient delivery, theAttach Requestmessage1that was delivered to the NAS layer is sent to the eNB when delivering theRRC Connection Setup Completemessage, as embedded in the Dedicated NAS Information field (DedicatedInfoNAS) of theRRC Connection Setup Completemessage.(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 UE S1AP ID, MME UE S1AP ID) allocated by the eNB and the MME for identifying UEs.In Figure 2, anAttach Requestmessage, 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 anAttach Requestmessage, as embedded in anInitial UE Message. TheAttach Requestmessage is delivered as embedded in the NAS-PDU field of theInitial UE Message. TheInitial UE Messageconsists of the following information elements:

When the MME receives theInitial UE Messagefrom 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-MME interface (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 theAttach Requestmessage sent from the NAS layer of the UE, and finds out the UEs security capability by learning what security algorithms the UE can use from the UEs network capability information.After collecting the UEs IMSI and security capability information from theAttach 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 the following two steps: Step (1), authentication vector acquisition, during which the MME acquires authentication vectors from the HSS for the UE, and Step (2), mutual authentication, during which the MME and the UE are mutually authenticated. Step (1) is performed over the S6a interface between the MME and the HSS using Diameter protocol, 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 anAuthentication Information Requestmessage, requesting authentication vector(s) (AV) for the UE that has an IMSI. At this time, it includes the UEs SN ID (Serving Network ID) along with the IMSI in the message to make sure the HSS reflects the UEs current serving network information (i.e. which operators network the UE is using) when generating authentication vectors for the UE. Main parameters in theAuthentication Information Requestmessage are:

2) [HSS] Generating Authentication VectorsThe HSS3generates 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 VectorsThe 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 theAuthentication 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 the user. 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 KASMEto use for user authentication and NAS security key derivation, respectively. KASMEis 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 to generate authentication vectors, and KSIASME, as included in theAuthentication Request(RAND, AUTN, KSIASME)message to the UE.5) [UE] Users Authenticating the Network: Generating Authentication Vectors and Authenticating the NetworkAfter receiving theAuthentication 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 the MME (AUTNHSS) to authenticate the network, and stores KSIASMEas 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 theAuthentication Response(RES) message, so that the MME can authenticate the user.7) [MME] Networks Authenticating the UEUpon the receipt of theAuthentication 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 flows in the NAS security setup procedure.

1) [MME] Generating NAS Security KeysThe MME selects ciphering and integrity algorithms to be applied to NAS messages from theAttach Requestmessage 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 aSecurity 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 theSecurity Mode Commandmessage, the UE generates NAS security keys (KNASintand KNASenc) by using the NAS security algorithm that the MME selected, and performs an integrity validation on theSecurity Mode Commandmessage 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 aSecurity 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 are completed, 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 done through 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 anUpdate Location Request(IMSI, MME ID) message to the HSS in order to notify of the UEs 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 anUpdate Location Answermessage, so that the MME can create an EPS session and a default EPS bearer for the subscriber. The subscription information included in theUpdate Location Answermessage is as follows:

4) [MME] Storing Subscription InformationThe MME receives theUpdate Location Answermessage 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 its P-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 aCreate Session Requestmessage 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) aCreate Session Requestmessage, 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 receivedCreate Session Requestmessage. Then, it sends the ID along with other parameters, as included in theCreate Session Requestmessage, 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 theCreate Session Requestmessage, realizes the user 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 PCRFs authorization for resources allocation in accordance with the network operators policies. From the UEs subscription information received from the MME, the P-GW gathers information required for the PCRFs decision-making on the operators policies, and sends it to the PCRF through aCCR (CC-Request)message. An example of the message is as follows:

8) [PCRF SPR] Requesting Access ProfilesThe PCRF requests the SPR for the users 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, as included in aCCA (CC-Answer)message. An example of the message is as follows:

12) [P-GW] Policy EnforcementThe 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 ResponseThe P-GW informs the MME of the QoS information applied to the established EPS sessions and default EPS bearer, by sending it in aCreate Session Responsemessage. The PCRF may decide to keep the value the MME received from the HSS, or select a new value.13) [S-GWP-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 to be applied to the default EPS bearer (S5 bearer) in theCreate Session Responsemessage, and sends it to the S-GW as a response to theCreate Session Requestmessage 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 theCreate Session Responsemessage 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 newly allocated S1 S-GW TEID to the processed message, and sends it to the MME as a response to theCreate Session Requestmessage 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 UEs new S-GW of the uplink 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 anAttach Acceptmessage to the UE as a response to theAttach Requestmessage, 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, and allocates it instead.

19) Determining Information needed for E-RAB and NAS SignalingBy receiving theCreate Session Responsemessage 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-RAB setup 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 eNBs use Allocating an E-RAB ID20) [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 theAttach Acceptmessage8, and sends it to the UE as a response to theAttach Requestmessage received in Section 2.1.This message is delivered as included in theInitial Context Setup Requestmessage through the S1 signaling connection, and then in theRRC Connection Reconfigurationmessage through the RRC connection.21) [MME] Creating KeNBThe 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 anInitial Context Setup Requestmessage so that the eNB can establish S1 bearer with the S-GW, and DRB with the UE. TheInitial Context Setup Requestmessage 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 can deliver uplink traffic to the S-GW.When the eNB receives the MMEsInitial Context Setup Requestmessage that requests E-RAB setup, it sets up DRB by sending anAttach Acceptmessage to the UE. Then, it completes S1 bearer setup by including a downlink S1 TEID in theInitial Context Setup Responsemessage, and sending the message as a response to theInitial Context Setup Requestmessage to the MME, so that the MME can forward it to the S-GW.24) ~ 27) AS Security SetupUpon receiving the MMEsInitial Context Setup Requestmessage, 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 KeNBreceived 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 KeysThe eNB helps the UE to generate AS security keys (KRRCint, KRRCencand 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 aSecurity 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 theSecurity Mode Commandmessage from the eNB, the UE generates AS security keys using the AS security algorithm that the eNB selected, and performs integrity check on theSecurity Mode Commandmessage.27) [UE eNB] AS Keys Generation CompleteOnce the integrity check on theSecurity Mode Commandmessage 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 aSecurity 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, the eNB begins DRB establishment.28) ~ 29) DRB Establishment28) [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 aRRC Connection Reconfigurationmessage to the UE through the secured RRC connection. The RRC connection was already established when the UE sent theAttach Requestmessage. 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 of the UE allocates radio resources based on the configuration parameters gathered from theRRC Connection Reconfigurationmessage. Next, it extracts anAttach Acceptmessage from theRRC Connection Reconfigurationmessage, 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 it includes the allocated ID in anInitial Context Setup Responsemessage, and sends it to the MME as a response to theInitial Context Setup Requestmessage 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 S1 bearer, establishing the downlink S1 GTP-U tunnel. However, since the S-GW does not know about the establishment yet, it cannot delivery downlink traffic to the eNB at this time.32) [UE MME] Sending Attach Complete MessageThe UE sends anAttach Completemessage9to the MME, as a response to the message in Step 20). TheAttach Completemessage is delivered through anUL Information Transfermessage over the RRC connection, and then through anUplink NAS Transportmessage over the S1 signaling connection.33) [UE][MME] EMM StateNow the UE and the MME stay in EMM-Registered state. If anAttach Rejectmessage 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 eNB to the S-GW through aModify Bearer Requestmessage.35) [MME S-GW] Responding to S1 Bearer Modification RequestThe S-GW sends the MME aModify Bearer Responseas a response to theModify Bearer Requestmessage. Now, the S-GW is ready to deliver downlink S1 traffic.36) [S1 Bearer: Downlink] S1 Bearer Setup CompleteStep 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 EPS entities 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 Case 1 involves initial attach by an unknown user, all the network has is commissioning and provisioning information only.

UE ID information: A users 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 theAttach Requestmessage 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 new cell, the MME notifies the P-GW, which then notifies the PCRF, of the new cell 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 in accordance 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 radio link. 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 have APN-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 services in 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-Idle state. In any case, once detach procedures are completed, the users 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 resources allocated to the EPS session and bearer established for the user are released. This release will delete the users 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 operators O&M (Operation & Maintenance) purposes if re-authentication fails if it cannot provide the resources allocated to a userii) 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 saved in 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 networkThe next following sections describers 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 RequestThe UE requests the MME for detach by sending aDetach Requestmessage to the MME. Interpretation of theDetach Requestmessage 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 theDetach Requestmessage, the UE stores its current NAS security context, GUTI and TA information, and then deletes its EPS bearer context.3)[MME] Noticing Detach Intent and Handling Security ContextAfter receiving theDetach Requestmessage from the UE, the MME becomes aware of the UEs intent to detach. It then stores the users current NAS security context, and checks the type of the intended detach, i.e. whether it is a case of normal detach, or a turned off device. By doing this, the MME finds out whether it has to send aDetach Acceptmessage or not.

EPS Session TerminationOnce the MME perceived UE-initiated detach and stored the users 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 be described below.

(1) EPS Bearer Release and PCC Rule Removal4) [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 procedures for deleting the users EPS session and default EPS bearer by sending the S-GW aDelete Session Requestmessage. 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 users EPS bearer context after sending theDelete Session Requestmessage.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 theDelete Session Requestmessage received from the MME to the P-GW.7) [S-GW] Deleting EPS Bearer ContextThe S-GW deletes the users EPS bearer context after sending theDelete Session Requestmessage.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 aCCR (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 users PCC rule once it receives theCCRmessage from the P-GW.10) [P-GW PCRF] Acknowledging EPS Session TerminationThe PCRF acknowledges the users PCC rule has been deleted by sending aCCA (CC-Answer)message to the P-GW.11) [S-GW P-GW] Responding to EPS Session Release RequestWhen the P-GW receives theCCAmessage from the PCRF, it sends the S-GW aDelete Session Responsemessage as a response to the message sent in Step 6) above.12) [P-GW] Deleting EPS Bearer ContextThe P-GW deletes the users EPS bearer context after sending theDelete Session Responsemessage.13) [MME S-GW] Responding to EPS Session Release RequestWhen the S-GW receives theDelete Session Responsemessage from the P-GW, it sends the MME aDelete Session Responsemessage as a response to the message sent in Step 4) above.14) [UE MME] Acknowledging DetachUpon receipt of theDelete Session Responsemessage, the MME recognizes the users resource release has been approved by the PCRF. So, it sends the UE aDetach Acceptmessage as a response to the request sent in Step 1). ADetach Acceptmessage is sent only when the UEs detach request was made due to a cause other than a switched off device (i.e. when Switch Off=0 in theDetach Request). If detach was requested because of a devices switch off, noDetach Acceptmessage is sent by MME.

(2) S1 Signaling Connection ReleaseAfter sending theDetach Acceptmessage 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 aUE Context Release Commandmessage to the eNB to release the S1 signaling connection.16) [UE eNB] RRC Connection ReleaseThe eNB sends anRRC Connection Releasemessage 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 aUE Context Release Completemessage as a response to the request sent in Step 15).

MME-initiated Detach

Figure below displays how MME-initiated explicit detach is performed. The detach procedure for this type of detach begins when detach triggering is detected at MME, and thus the MME sends aDetach Requestmessage to the UE. The procedure ends when the resources previously allocated to the UEs 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 paging procedures 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 aDetach Requestmessage 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 aDetach Requestmessage to UE.2) [MME] Handling Security ContextAfter sending theDetach Requestmessage 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 Bearer ContextsAfter receiving theDetach Requestmessage from the MME, the UE becomes aware of the MMEs intent to detach. It checks the type of 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 users EPS session. This request triggers PCEF (P-GW)-initiated EPS termination, releasing all the network/radio resources allocated to the user, as to be described below.(1) EPS Bearer Release and PCC Rule RemovalThrough Steps 4) ~ 13), the MME requests for termination of the users 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 theDetach Requestmessage from the MME in Step 1), the UE sends the aDetach Acceptmessage as a 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 theDetach Acceptmessage from the UE and theDelete Session Responsemessage 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 users 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 for detach of the user by sending aCancel Location Request (CLR)message with the following parameters:

EPS Session TerminationUpon receipt of theCancel 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 required by the MME in Step 2). The MME needs to send the HSS aCancel Location Answermessage as a response to the request made in Step 1).2) [MME HSS] Responding to Detach RequestAfter receiving theDetach Acceptmessage from the UE, and theDelete Session Responsemessage from the S-GW, the MME sends aCancel Location Answermessage to the HSS as a response to theCancel Location Requestmessage 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 entities have the same information they initially had after initial attach. Figure 5 lists the information stored in each EPS entity before detach is performed.

After Detach

After detach, information that can be used for the users 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 in next 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 detachAt MME: UE ID: IMSI that UE provided at its initial attach, and GUTI allocated by MME at the time of UEs 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-AMBR may 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 in City 1, and ii) an initial attach procedure required for the UE to attach 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 get gradually 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, and EMM Case , Initial Attach in Another City [1]. Figure above illustrates the 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 1 to City 2 in a car.In EMM Case 10, UE detaches from the network as it leaves City 1, thereby moving 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) as it leaves City 1, and hence is detached from the network by MME.1In 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 the network (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 CityMoving 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)[UEeNB] 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 aMeasurement Reportmessage to eNB, informing the signal strength of the serving cell. 2) [eNB] No Neighbor Cell to Hand Over toThe eNB finds no neighbor cell to hand theUE over to. 3) [eNBMME] Error IndicationDue to the worsening communication quality, delivery fails over the radio interface. The eNB informs the MME of such failure by sending anError 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 anUE Context Release Requestmessage).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 anError Indicationto the MME while the RRC connection with the UE is still valid, and ii) the MME decides to detach the UE because the current serving cell of the UE is located near the city border, and has no neighbor cell to hand over to. So, the MME triggers a detach procedure. 4) MME-initiated DetachThe MME performs a detach procedure by sending the UE aDetach Requestmessage. Here the procedure is the same as the MME-initiated Explicit Detach procedure explained in our previous document [2]3. The MME stores the UEs GUTI and NAS security context, terminates the EPS session, releases the S1 signaling, and transits to Detach state (EMM-Deregistered,ECM-Idle). The UE stores its 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 whether the 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 anAttach Acceptmessage when the UE makes initial attach to the network, or through aTAU Acceptmessage when the 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 (Wouldnt 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 aTAU Requestmessage 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 aTAU Requestmessage4, through which it keeps track of the UEs location. 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 aTAU Requestmessage to MME).When the mobile reachable timer expires, MME knows UE isout of the LTE coverage, but does not know for how long the out of the coverage status has lasted. So, instead of deleting the UEs context right away, the MME clears the PPF flag and starts the implicit detach timer. When the PPF flag is cleared, the UE islocally 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 aDownlink Data Notificationmessage 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 before the implicit detach timer is expired, it believes the UE haslong 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 cell in 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 aTAU Requestmessage from the UE, and must check whether the UE is reachable or not. 2) [MME] Mobile Reachability Timer ExpiryThe UEs 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 ExpiryThe UEs implicit detach timer is expired. The MME, believing the UE has long been out of the coverage, decides to implicitly detach the UE from the network. 4) [eNB, MME, S-GW, P-GW, PCRF] UE DetachedThe 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 in the UEs 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 anAttach Requestmessage 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 the Old GUTI that it was allocated by MME1.5Next, MME2 checks if the Old GUTI is still valid through 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 the Identification 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 context it 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 HSS that the UE with the IMSI has been registered with MME2. The HSS updates the UEs new location accordingly. 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 subscription profile received from the HSS. The establishment procedure 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 UEis in Connected state, the same information elements kept after the initial attach procedure [3] are stored.

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

1There 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.2At this time, the E-RAB in the user plane and the ECM connection in the control plane are released. That means the S1 bearer and S1 signaling connection are released on the MME side while the DRB and RRC connections are released on the UE side. In this document, we used the term, S1 release, as described in 3GPP TS 24.301.3To provide more simplified illustration, X2 connections between eNBs are not included in Figure above.

LTE Security : Concept and AuthenticationIntroductionWireless communication, in its nature, is always at a risk of eavesdropping or manipulation because data originally sent from/to a user may be received and unlawfully used by an unintended user. Locations or traveling routes of a user can also be easily tracked by tracing to which cells 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 travels through LTE radio links at NAS and AS levels.LTE Security ConceptScope and Concept of LTE SecurityFigure 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 of determining 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 users and 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 a user authenticate each other. In LTE networks, since the ID of the user's serving 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 UE and 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 SecurityNAS security, designed to securely deliver signaling messages between UEs and 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 SecurityAS 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 check and 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 ProcedureFigure shows the overview of LTE security procedure. displays LTE authentication procedure while and demonstrate security setup procedures for 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 IMSI and 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 perform mutual authentication with the UE2. The MME forwards RAND and AUTNHSSto the UE, which then computes RES, AUTNUEand KASME using EPS AKA algorithm. The UE now compares its own AUTNUEand AUTNHSSreceived 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(KASMEis not transferred between UE and MME, though). NAS Security

Once the UE and MME have authenticated each other and the same key KASMEis shared, NAS security setup procedure begins. In this procedure, NAS security keys to be used when delivering NAS signaling messages are derived from KASMEfor secure delivery of these messages. This procedure consists of a round trip of NAS signaling messages (Security Mode CommandandSecurity Mode Completemessage), and begins when the MME delivers aSecurity Mode Commandmessage to the UE.First, theMME selects NAS security algorithms (Alg-ID: Algorithm ID) and uses them to create an integrity key (KNASint) and a ciphering key (KNASenc) from KASME.Then, it applies KNASintto theSecurity Mode Commandmessage to generate an NAS message authentication code (NAS-MAC, Message Authentication Code for NAS for Integrity). TheMME then delivers theSecurity Mode Command message including the selected NAS security algorithms and the NAS-MAC to the UE. As theUE does not know the selected encryption algorithm yet, this message is integrity protected only but not ciphered.Upon receiving theSecurity Mode Commandmessage, 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 (KNASintand KNASenc) from KASME. Then it ciphers theSecurity Command Complete message with KNASencand generates a message authentication code, NAS-MAC with KNASintto 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 receivedSecurity Mode Completemessage and has them decrypted using the NAS security keys (KNASintand 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 keys and then securely delivered over radio links. AS Security

After NAS security setup is finished, AS security setup procedure between a 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 KeNBfor secure delivery of these data. This procedure consists of a round trip of RRC signaling messages (Security Mode CommandandSecurity Mode Completemessage), and begins when an eNB deliversSecurity Mode Commandmessage to the UE.First, the MME calculates KeNBfrom KASMEand 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 for RRC signaling messages, and a ciphering key (KUPenc) to be used in the user plane. Then, it applies KRRCintto the Security Mode Commandmessage to generate a message authentication code (MAC-I, Message Authentication Code for Integrity). The eNB now delivers theSecurity Mode Commandmessage including the selected AS security algorithms and the MAC-I to the UE.Upon receiving theSecurity Mode Commandmessage 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 generate AS security keys (KRRCint, KRRCencand 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 receivedSecurity Mode Completemessage 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 performe