Sie sind auf Seite 1von 116

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 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 establishment
Decisions 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 UE
In 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 IMSI
This 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 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 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. 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 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’t 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 doesn’t 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 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 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 UE’s location updated.

Simplified Call Flow in Each Case

UE ID Acquisition
The 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.
Authentication
If 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 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 Setup


Once user authentication is completed, NAS security keys for secured delivery of NAS messages
between the UE and MME are generated.8

Location Update
The 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 Establishment


An EPS session and a default EPS bearer are established.

Initial Attach with IMSI


Attach Case 1:Unknown UE
The 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/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 Context
If 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 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 be further divided into two sub-phases: (1) RRC connection
establishment, and (2) S1 signaling connection establishment.

❶ Initial State after Radio Link Synchronization


In 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 Establishment


On NAS layer, the UE sends an Attach Request (including IMSI and UE Network
Capability) message to request initial attach to the NAS layer of the 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 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 Request


An 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 UEs in a
cell, and CCCH (Common Control Channel), a logical channel.

2) [UE ←eNB] RRC Connection Setup


The 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 Complete


The 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 to the 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 Establishment


Control 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, 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-MME interface (Downlink).

(3) ECM S1 Connection Establishment


Through 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 Acquisition


The NAS layer of the MME acquires the IMSI of the UE from the Attach
Request message sent from the NAS layer of the UE, and finds out the UE’s
security capability by learning what security algorithms the UE can 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 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 Vectors


1) [MME → HSS] Authentication Information Request
The 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 the UE’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 Vectors


The 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 Vectors
The 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 Authentication


LTE 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 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 KSI ASME, 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 Authentication


The MME delivers the information (RAND, AUTN) required for the UE to generate
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 Authentication Vectors


and Authenticating the Network
After 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 the MME (AUTNHSS) to authenticate the
network, and stores KSIASME as an index of KASME.

6) [UE → MME] Delivery of User RES to MME


After 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 UE


Upon 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
flows in the NAS security setup procedure.

1) [MME] Generating NAS Security Keys


The 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 Keys


The 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 Keys


When 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 Complete


The 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 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 Location


The 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 Update


The HSS registers the MME ID to indicate in which MME the UE is located in.

3) [MME ← HSS] Delivering User Subscription Information


The HSS sends the MME subscription information of the subscriber as included in
an Update Location Answer message, so that the MME can create an 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 Information
The 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 ID
The 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-GW


The 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 Creation


The 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 Creation


The 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 Creation


The 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 Address
The P-GW, upon receiving the Create Session Request message, 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 Setup


The 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 (Credit Control
Request) message. An example of the message is as follows:

8) [PCRF → SPR] Requesting Access Profiles


The PCRF requests the SPR for the user’s access profile to determine PCC policies for
the user.

9) [PCRF ← SPR] Returning Access Profiles


The 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 Policies


The PCRF determines PCC policies for the EPS session to be established based on the
user access profile.
11) [P-GW ← PCRF] Acknowledging EPS Session Establishment
The PCRF delivers the PCC policies determined in Step 10) to the P-GW, as included in
a CCA (Credit Control 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 Response


The 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 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 Established


Completing 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 Response


When 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 newly allocated 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 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-AMBR


Now, 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,
and allocates it instead.
19) Determining Information needed for E-RAB and NAS Signaling
By 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-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 eNB’s use

 Allocating an E-RAB ID

20) [UE ← MME] Attach Accept


The 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 Setup


The 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 can deliver
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 including a 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 Setup


Upon 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 Keys


The 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 K eNB, 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 Keys


Upon 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 Complete


Once 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, the eNB begins DRB establishment.

◇ 28) ~ 29) DRB Establishment

28) [UE ←eNB] Reconfiguring RRC Connection


The 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. The RRC 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 of the 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 Complete


Once Step 28) is completed, and the UE can deliver uplink/downlink traffic from/to the
eNB.

39) [eNB→ S-GW] E-RAB Setup Response


The eNB allocates a downlink S1 TEID (S1 eNB TEID) for S1 bearer. Then it includes
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 Bearer


Once 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 Message


The UE sends an Attach Complete message9 to the MME, as a response to the message
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 State


Now 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 Modification


The MME forwards the downlink S1 TEID (S1 eNB TEID) received from the eNB to the
S-GW through a Modify Bearer Request message.

35) [MME ← S-GW] Responding to S1 Bearer Modification Request


The 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 Information


Here 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 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 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 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 resources allocated
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 Detach


UE 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 Detach


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


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 UE
When 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 Contexts


After sending the Detach Request message, 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 Context


After receiving the Detach Request message from the UE, the MME
becomes aware of the UE’s intent to detach. It then stores the user’s
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 a Detach Accept message or
not.

❷ EPS Session Termination


Once 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 be described below.

(1) EPS Bearer Release and PCC Rule Removal

4) [MME → S-GW] Requesting EPS Session Release


The MME and the S-GW communicate with each other over S11 interface
using GTP protocol (GTP-C). The MME begins procedures for 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 Context
The MME deletes the user’s EPS bearer context after sending the Delete
Session Request message.

6) [S-GW → P-GW] Requesting EPS Session Release


The 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 Context


The S-GW deletes the user’s EPS bearer context after sending the Delete
Session Request message.

8) [P-GW → PCRF] Notifying of EPS Session Termination


The 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 Rule


The PCRF deletes the user’s PCC rule once it receives the CCR message
from the P-GW.

10) [P-GW ← PCRF] Acknowledging EPS Session Termination


The 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 Request


When the P-GW receives the CCA message from the PCRF, it sends the S-
GW a Delete Session Response message as a response to the message
sent in Step 6) above.

12) [P-GW] Deleting EPS Bearer Context


The 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 from the
P-GW, it sends the MME a Delete Session Response message as a response
to the message sent in Step 4) above.

14) [UE ← MME] Acknowledging Detach


Upon receipt of the Delete Session Response message, the MME recognizes
the user’s resource release has been approved by the PCRF. So, it sends
the UE a Detach Accept message as a response to the request sent in Step
1). A Detach Accept message is sent only when the UE’s detach request
was made due to a cause other than 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 Release


After 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 Release


The MME sends a UE Context Release Command message to the eNB to
release the S1 signaling connection.

16) [UE ←eNB] RRC Connection Release


The eNB sends an RRC Connection Release message to the UE to release
any RRC connection left unleased.

17) [eNB] Deleting UE Context


The eNB deletes all the information related to the UE.

18) [eNB→ MME] RRC Connection Release Complete


Finally, 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. The detach
procedure for this type of detach begins when detach triggering is detected 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 MME
Below 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 Request


As 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 Detach


Request message to UE.

2) [MME] Handling Security Context


After 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 Bearer Contexts
After receiving the Detach Request message from the MME, the UE
becomes aware of the MME’s 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 Termination


Once 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 be described below.

(1) EPS Bearer Release and PCC Rule Removal


Through 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 Detach


After 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 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 Release


In 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 Delete Session
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 HSS
When 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 Request


The 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 a Cancel Location Request (CLR) message with the following
parameters:
❷ EPS Session Termination
Upon 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 required by 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 Request
After 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 response to 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 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 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 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 detach

At MME:

 UE ID: IMSI that UE provided at its initial attach, and GUTI allocated by MME 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-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.
Introduction
UE 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.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 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 City
Moving in Connected State
In 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 Report


As 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) 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 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
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 State


UE 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 an Attach Accept message when the UE makes initial attach to the network, or
through a TAU Accept message 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 (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’s 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 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 before the 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 cell in City 1 is
detached from the network as it moves out of the LTE coverage.
1) [MME] TAU Timer (T3412) Expiry
The 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 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 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 Case2 : Initial Attach in Another City


This 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 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 Connection
Once 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 GUTI
The 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 MME


MME2 checks the location of the UE from the received Initial UE Message, and learns
from the Old GUTI that it was allocated by MME1.5
Next, 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 at
Old 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 UE’s 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 Session


MME2 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 Information


The 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 attach procedure [3]
stored.
-
If UE is in Idle state, the same information elements kept after the S1 release procedure [9] are stor

 After

- UE is detached from the network. The information elements stored in EPS entities are the same as th
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 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.
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 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 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 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 Security

NAS 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 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 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 Procedure

Figure 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 AUTNHSS to the UE, which
then computes RES, AUTNUE and KASMEusing 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 is
shared, 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) and uses 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 Commandmessage 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 (K NASint and KNASenc) from
KASME. Then it ciphers the Security Command Completemessage 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 Security Mode
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 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 KeNB for secure delivery of these
data. This procedure consists of a round trip 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 for RRC signaling messages, and a ciphering key
(KUPenc) to be used in the user plane. Then, it applies KRRCint to theSecurity 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 generate AS security keys (K RRCint, 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 Security Mode
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 information elements 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 EIA0 4
Null integrity protection algorithm
128-EEA1 SNOW 3G 128-EIA1 SNOW 3G
128-EEA2 AES 128-EIA2 AES
128-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 the UE has no KASME available.

Authentication Data Exchange between MME and HSS

2) [MME → HSS] Request by MME for Authentication Data


The 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) message to 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, using CK, 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 KASMEis derived, the HSS forms authentication vectors AVi=(RANDi,
AUTNi, XRESi, KASMEi), i=0..n.

3 ) [MME ← HSS] Response by HSS to the Authentication Data Request


THe 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 the access 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 index for 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 AUTNias 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 AUTNUEgenerated 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 Authentication


Once 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, it
compares 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 KASMEusing Key Derivation Function (KDF) with CK, IK, SQN and SN ID and
stores it using KSIASME received from the MME as its 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 Description
K 128 bits USIM, HSS/AuC - LTE key
CK 128 bits USIM, HSS/AuC K Cipher key
IK 128 bits USIM, HSS/AuC K Integrity key
KASME 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 and USIM. 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 keys used in LTE.
Introduction

This section describes aboutNAS and AS security setup procedures to be performed


based on KASME, and how data are transmitted in user and control planes 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 NAS security 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 MME get 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 share an 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 encrypted using 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 is delivered 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) and verifies 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 allocates a KSIASME to identify KASME as 1 ("001").
[MME] Selecting security algorithms
The 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 of selecting EEA1 for an
encryption algorithm and EIA1 for an integrity algorithm, i.e., SNOW 3G algorithm.

[MME] Deriving NAS security keys


The 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 protection


The 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 theAttach Request message sent by UE, indicates which 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 message
The UE checks the integrity of the received Security Mode Command message by
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 theSecurity 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 sending a Security Mode
Complete message to the MME, informs the MME that the same 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 cipheredSecurity Mode Complete message (Cipher Text Block) is derived
by performing bitwise XOR between theSecurity 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 algorithm input 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 protection
The UE calculates NAS-MAC using EIA algorithm (EIA1) with the ciphered Security
Mode Completemessage 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 message

The UE attaches the NAS-MAC calculated in at the end of the Security Mode
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 message


The MME checks the integrity of the received Security Mode Complete message by
verifying NAS-MACincluded in the message. MME calculates XNAS-MAC, a message
authentication code, by using the selected EIA1 algorithm with the Security
Mode Complete message and KNASint. Figure 4 shows howXNAS-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 message


After 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 the NAS
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 and then
decrypted, which is in the opposite order of what has been done when they 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 receivedNAS-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 in the 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 how the 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 message between the eNB and
the MME. Message parameters used are as follows:

 UE Security Capability: security algorithms selected by the MME in the UE Network


Capability in theAttach Request message sent by the UE

 Security Key: 256-bit KeNB

[eNB] Selecting security algorithms


The 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 Keys


The eNB derives KRRCint, KRRCenc and KUPenc from KeNB using the algorithm IDs and
algorithm 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 protection


The 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, EIA1
The 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 keys


The 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 protection


The UE calculates MAC-I using EIA algorithm (EIA1) with the Security Mode
Complete 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 between the two hereafter are
delivered as integrity protected over radio links.

[eNB] Verifying the integrity of the Security Mode Complete message


The eNB checks the integrity of the received Security Mode Complete message by
verifying the MAC-Iincluded 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 eNB verifies the integrity of the message by
examining whether the XMAC-I calculated by itself matches the MAC-Icalculated 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 as encrypted 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 when they 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 is performed
and before the first SMC (Security Mode Command) procedure begins. A partial
native EPS NAS security context is transformed into a 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 that LTE 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 titles are 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 these IDs as well as the EPS entities defined in [1] is
essential to understand LTE technologies.

We have previously discussed the LTE network architecture, our first topic in LTE area.
Now we will cover LTE identification, our second topic in 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 that stays
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 network or uses services have
temporary values.

Range (within which IDs are uniquely identified): Each LTE ID is uniquely identified
across the world, operator networks, entities or channels.
Figure shows different IDs used depending on where LTE identification is actually
being performed, i.e., layers, interfaces or geographical areas. For the convenience of
description, the IDs shown in Figure 1 are grouped as 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 UE components, 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-RAB ID, 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 location of 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 share resources 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 mobile network 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 a Home Subscriber Server (HSS) and Subscriber Profile Repository
(SPR) by the operator3. After being provisioned, the IMSI is sent by the UE to the
mobile 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 and PCRF while
establishing a default EPS bearer during a UE’s initial attach process is a temporary
value to be removed when the default EPS bearer is terminated.

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 on the 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 for the 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 is assigned 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 IP address 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 UE performs
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 a brief


illustration of the procedure during which the P-GW dynamically allocates a temporary
IP address when a default EPS bearer is established during the initial attach process
(See “Initial Attach” document for detailed procedure of default EPS bearer
establishment) and the procedure during which the UE uses the Internet service after
allocating an dynamic IP 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 and downlink. 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 an S1-
MME interface. Many UEs stay connected to an eNB at the same time. And the 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 which S1AP 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 tell which 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 eNB the 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 the ID 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 NeweNB 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 process of 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 ME can 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 assigned by 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 is a
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 will not 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 consists of 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 subscription information 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 an MME 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
represents an 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, is used for identifying one
outside the network. Figure below shows eNB/cell-related IDs and their format. To
identify a cell belonging to an eNB, 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 is installed.
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 if CSGs 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 ID


When a UE attempts to attach an LTE network, the LTE network provides the UE 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 attach the 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 UE initially 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, combination of 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, the UE 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 in the
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 needs to know
the location of the UE to forward the data properly. If the UE is in 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-TMSI in 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 the new 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 cell it 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 cell it 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 a description of the
relationship among the IDs will be given.

Figure below shows the EPS sessions and EPS bearers of a user, with their IDs 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), and applies the service quality (QoS) policy obtained
from a PCRF to the EPS bearers. The minimum fundamental bearer that an EPS
session has for a PDN is 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 the LTE network has been established. Through this EPS session
established, IP packets can be exchanged between the user and the PDN according to
the rules 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 relating to 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 and a 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 the following
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 by their 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 concatenation of 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 IDs on 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 have one 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 itself is 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, as can 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 and an 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 ID values 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 MME obtains 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 by the MME.

The two endpoints of an EPS bearer are a UE and a P-GW. They both perform traffic
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 bearer ID, 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 user traffic 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