This document and its subsequent documents will provide descriptions of specific EMM procedures based on our understanding of EMM and ECM/RRC states covered in our LTE technical document, “LTE EMM and ECM States” [1]. EMM features are explained in 3GPP TS 24.301 [2], a NAS protocol document, and 3GPP TS 23.401 [3], a document on GPRS enhancements for E-UTRAN access. To be more specific, the procedures performed between a UE and an MME at a NAS level are presented in the reference [2] while the procedures involving other EPS entities as well, in addition to the UE and MME, at a packet service level are described in the reference [3]. Based on these three reference documents, we will discuss each of the EMM procedures below.

This document is the first in the “LTE EMM Procedure” series to be presented in subsequent documents and provides an EMM scenario. In the scenario, user experiences and device operations expected while a user travels over an LTE network will be defined as EMM cases. This will give us an idea of what EMM procedures are being covered in the subsequent documents.

2. EMM Scenario

Figure 1 shows an LTE network set up in the EMM scenario written in order to define EMM procedures. Section 2.1 provides a brief overview of the LTE network structure and the scenario environment, and Section 2.2 describes each of eleven EMM cases shown in Figure 1.

2.1 Scenario Environment

Figure 1 shows two cities, in geographically separated areas, served by one LTE network operator: City 1 (e.g. Seoul) and City 2 (e.g. Busan). The LTE network operator has a Home Subscriber Server (HSS), Policy and Charging Rule Function (PCRF) and Subscriber Profile Repository (SPR) for the entire network. It also has a Mobility Management Entity (MME), Serving Gateway (S-GW) and PDN Gateway (P-GW) for each area it is serving. In Figure 1, City 1 has an HSS, PCRF and SPR, and both cities have an MME, S-GW and P-GW. Both MMEs in the cities are connected to the HSS in City 1 and both P-GWs are connected to the PCRF in City 1. Also, City 1 has three TAs (Tracking Areas), TA1, TA2 and TA3, whereas City 2 has only one TA, TA4.

When a user attempts to attach to an LTE network, the network may or may not have user information of the user, which is required for user authentication and NAS security. If it has valid user information, procedures for user authentication, subscription profile download and/or NAS security setup may be skipped. However, if it does not, all of these procedures must be performed.

The main character in this scenario is User A (i.e. UE A) in City 1. The scenario assumes User A (the “User” hereinafter) purchased a device and subscribed to an LTE service in City 1. The scenario begins with the User located in TA1 and with UE A (the “UE” hereinafter) turned off (see the blue dotted circle). The UE does not have any valid information about its previous attach to the network, nor does the network have any information about the User’s network attach history. All they have is commissioned and provisioned information (see Table 8 in our LTE technical document, “EMM and ECM States” [1]).

Figure 1. EMM Scenario

The EMM scenario begins with the first scene where the User turns on the UE. According to the scenario, the UE will initially attach to the network in City 1 (❶) and use the Internet service, and then move to City 2, detaching from the LTE network (❷ ~ ❿) and then again attaching to the LTE network in City 2 (⓫). While staying in City 1, the UE will detach from the network (❷), become inactivated (❸) and then activated (❹), and perform a handover over time (❻ or ❽). Section 2.2 defines and explains the EMM cases encountered as the User uses the UE according to the scenario.

2.2 EMM Cases

Case ❶. Initial Attach

(UE State: “EMM-Deregistered, ECM-Idle and RRC-Idle” → “EMM-Registered, ECM-Connected and RRC-Connected”)

The User turns on the UE and attempts initial attach to the network. Immediately after being turned on, the UE is in EMM-Deregistered, ECM-Idle and RRC-Idle state. After performing PLMN and cell search, it synchronizes to a cell and sends an “Attach Request (UE ID = IMSI)” message that includes IMSI as UE ID to the MME. Then, it enters EMM-Registered, ECM-Connected and RRC-Connected state.¹

Mutual authentication between the UE and network (MME) are performed through the EPS-AKA procedure. Once mutually authenticated, the MME downloads a subscription profile from the HSS and begins creating an EPS session and default EPS bearer using the profile. While creating a default EPS bearer, the network assigns the UE an ID to use for attaching to the LTE network/PDN or registering its location. At this time, the P-GW assigns a UE IP address and the MME assigns a GUTI and TAI list. Such information (i.e. IP address, GUTI and TAI list) is delivered by the MME to the UE, as included in an “Attach Accept” message. In Figure 1, the TAI list assigned by the MME is {TA1, TA2}.

If the initial attach succeeds, the User stays in EMM-Registered, ECM-Connected and RRC-Connected state and may use the service (e.g. Internet). If it fails, the MME notifies the UE of such failure by sending an "Attach Reject” message, and the UE transits to EMM-Deregistered, ECM-Idle and RRC-Idle state. Details about successful initial attach by a UE which has no attach history will be provided in the subsequent document,

> EMM Procedure 1. Initial Attach - Part 1. Cases of Initial Attach
> EMM Procedure 1. Initial Attach - Part 2. Call Flow of Initial Attach

Case ❷. Detach

(UE State: “EMM-Registered, ECM-Connected and RRC-Connected” → “EMM-Deregistered, ECM-Idle and RRC-Idle”)

Once the UE made the initial attach to the network, it stays in EMM-Registered, ECM-Connected and RRC-Connected state. Then later it may need to detach, or to be detached, from the network. A detach request can be initiated by a UE, MME or HSS. The UE transits to EMM-Deregistered, ECM-Idle and RRC-Idle state once detached from the network. Different types of detach and their specific procedures will be described in the subsequent document,

> EMM Procedure: 2. Detach

Case ❸. S1 Release due to User Inactivity

(UE State: “EMM-Registered, ECM-Connected and RRC-Connected” → “EMM-Registered, ECM-Idle and RRC-Idle”)

After the successful initial attach to the LTE network, the UE uses a service in EMM-Registered, ECM-Connected and RRC-Connected state. If it stops using the service for a certain period of time, the S1 bearer and S1 signaling connection are released, and the UE transits to Idle state, entering EMM-Registered, ECM-Idle and RRC-Idle state.² User inactivity can be detected by a UE or by an MME. Detailed S1 release procedures due to user inactivity will be discussed in the subsequent document,

> EMM Procedure: 3. S1 Release due to User Inactivity

Case ❹. Service Request due to New Traffic

(UE State: “EMM-Registered, ECM-Idle and RRC-Idle” → “EMM-Registered, ECM-Connected and RRC-Connected”)

This is the case where new user traffic is generated for the UE in Idle (EMM-Registered, ECM-Idle and RRC-Idle) state. New user traffic can be uplink traffic from the UE or downlink traffic from the network. The UE transits to active (EMM-Registered, ECM-Connected and RRC-Connected) state through a service request procedure, and then can receive or send user traffic. The service request procedure can be triggered either by a UE or by a network. Each of such cases will be covered in the subsequent document,

> EMM Procedure: 4. Service Request due to New Traffic

Case ❺. Periodic TAU

(UE State: “EMM-Registered, ECM-Idle and RRC-Idle” → “EMM-Registered, ECM-Connected and RRC-Connected” → “EMM-Registered, ECM-Idle and RRC-Idle”)

This is when the UE, in Idle (EMM-Registered, ECM-Idle and RRC-Idle) state, performs periodic Tracking Area Update (TAU) procedures when the periodic TAU timer expires. During the periodic TAU procedure, the User’s TA may or may not be updated. In Figure 1, although the User has stayed within TA areas in the TAI list (TA1, TA2), it peforms a TAU procedure anyway because the periodic TAU timer expires.

First, the UE establishes an ECM connection with the MME, transiting to Active (EMM-Registered, ECM-Connected and RRC-Connected) state, and performs a TAU procedure by sending a “TAU Request” message to the MME. Once the TAU is successfully finished, the network releases S1 resource and the UE transits to Idle (EMM-Registered, ECM-Idle and RRC-Idle) state. If the TAU procedure fails, the UE attempts it one more time, or as many times as needed until it finally succeeds. However, if the specified threshold (maximum number of attempts allowed) is reached before the procedure is performed successfully, the UE shall enter to Deregistered (EMM-Deregistered, ECM-Idle and RRC-Idle) state. Details about successful periodic TAUs will be explained in the subsequent document,

> EMM Procedure: 5. Periodic TAU

Case ❻. Handover without TAU

(UE State: “EMM-Registered, ECM-Connected and RRC-Connected” → “EMM-Registered, ECM-Connected and RRC-Connected”)

This is when the UE using services in EMM-Registered, ECM-Connected and RRC-Connected state moves from TA1, its current location, to TA2, the other area in the TAI list, and thus a handover is caused. Since the UE moves to TA2, a TA which was also in the TAI list, no TAU procedure is performed after the handover, and the UE remains in the same EMM-Registered, ECM-Connected and RRC-Connected state. A user handover may be either X2 handover³ or S1 handover. Detailed procedures of each handover will be described in the subsequent document,

> EMM Procedure 6. Handover without TAU - Part 1. Overview of LTE Handover
> EMM Procedure 6. Handover without TAU - Part 2. X2 Handover
> EMM Procedure 6. Handover without TAU - Part 3. S1 Handover

Case ❼. Cell Reselection without TAU

(UE State: “EMM-Registered, ECM-Idle and RRC-Idle” → “EMM-Registered, ECM-Idle and RRC-Idle”)

This is when the UE moves from TA1 to TA2 in the TAI list while in Idle (EMM-Registered, ECM-Idle and RRC-Idle) state. The UE which has been camping in a cell in the eNB within TA1 selects a new cell in TA2 and camps in the cell when it moves to TA2 in Idle state. The detailed procedure for this will be described in the subsequent document,

> EMM Procedure: 7. Cell Reselection without TAU

Case ❽. Handover with TAU

(UE State: “EMM-Registered, ECM-Connected and RRC-Connected” → “EMM-Registered, ECM-Connected and RRC-Connected”)

This is when the UE using services in EMM-Registered, ECM-Connected and RRC-Connected state moves from TA1, its current location, to TA3, the area not in the TAI list, consequently causing a handover. Since the UE moves to a TA that was not in the TAI list, a TAU procedure is performed immediately after the handover described in case 6 above. Detailed procedures for this type of handover will be described in the subsequent document,

> EMM Procedure 8 & 9. Handover and Cell Reselection with TAU

Case ❾. Cell Reselection with TAU

(UE State: “EMM-Registered, ECM-Idle and RRC-Idle” → “EMM-Registered, ECM-Connected and RRC-Connected” → “EMM-Registered, ECM-Idle and RRC-Idle”)

This is when the UE moves from TA1 to TA3, an area not in the TAI list, while in Idle (EMM-Registered, ECM-Idle and RRC-Idle) state. The cell reselection procedure described in the case 7 above will be performed first, followed by a TAU procedure. For this type of TAU, the procedure to be performed is the same as the one in the case 5, but is triggered by a different event (i.e. moving to a TA not listed in the TAI list). The detailed procedure for this will be described in the subsequent document,

> EMM Procedure 8 & 9. Handover and Cell Reselection with TAU

Case ❿. Move to Another City

(UE State: “EMM-Registered, ECM-Connected and RRC-Connected” or “EMM-Registered, ECM-Idle and RRC-Idle” → “EMM-Deregistered, ECM-Idle and RRC-Idle”)

This is when the UE, while using services or in Idle state, moves from City 1 to City 2, and leaves the LTE service coverage in City 1, consequently detaching from the network. The detailed procedure for this will be described in the subsequent document,

> EMM Procedure 10 & 11. Move to Another City and Attach

Case ⓫. Initial Attach in Another City

(UE State: “EMM-Deregistered, ECM-Idle and RRC-Idle” → “EMM-Registered, ECM-Connected and RRC-Connected”)

This is when the UE, after having traveled from City 1 to City 2 and thus been out of the LTE service coverage, detects the LTE radio signal from City 2 and makes initial attach to the LTE network of City 2. When the UE attempts to attach using its GUTI previously assigned by the City 1 MME, the City 2 MME 2 obtains information on the UE (such as UE ID and UE MM Context) from the City 1 MME, and initiates the initial attach procedure using the obtained information. If no UE information is obtained from the City 1 MME, the City 2 MME requests the UE for IMSI to be used as an UE ID, and initiates the initial attach procedure as in the case 1. The details about performing the initial attach procedure successfully by using the UE information obtained from the City 1 MME (i.e. attach history information of the UE in its previous network) will be described in the subsequent document,

> EMM Procedure 10 & 11. Move to Another City and Attach

Table 1 lists the eleven EMM cases defined in the scenario presented in Figure 1. In general, there are two types of initial attach: one by an unknown UE - whose user information is not known to an MME - and the other one by a known UE - whose user information is known to the MME. We will discuss the procedure for the initial attach by an unknown UE in the subsequent document handling the case 1, and the one by a known UE in the document handling the case 11, based on the EMM scenario in Figure 1.

Table 1. EMM cases

 

3. Closing

By defining EMM cases to be encountered according to the EMM scenario, we have shown what kinds of EMM procedures will be covered. The subsequent documents will provide further explanation of each EMM case defined herein, such as i) detailed EMM procedure to be performed in each case, ii) what user information is to be set/changed in EPS entities after each EMM procedure is performed.

References

[1] Netmanias Technical Document, “LTE EMM and ECM States”, September 2013. 

[2] 3GPP TS 24.301, “Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3”.

[3] 3GPP TS 23.401, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access"

[4] NMC Consulting Group Confidential Internal Report, “E2E LTE Network Design”, August 2010.