Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | About Us | List of Contributors  
 
  KT SK Telecom LG U+ Korea ICT Portal Korean Vendors Network Architectures  
 
Key Words 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung  
 
CHANNELS HFRFRONTHAUL NetvisionMPTCP Springwave1588 PTP   Korea Communication Review      
Eleven EMM Cases in an EMM Scenario
October 22, 2013 | By Netmanias (tech@netmanias.com)
Online viewer:
Comments (4)
31
SUMMARY
This document defines the EMM procedures, to be further discussed in subsequent documents, by using an EMM scenario and defining eleven EMM cases in the scenario. It briefly explains user experiences and device operations in each EMM case, and discusses how EMM, ECM and RRC states of a UE are changed before and after the EMM procedures.

 

     

Table of Contents  

1. Introduction
2. EPS Mobility Management (EMM) Scenario
3. Closing

 

 

1. Introduction

 

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

 

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

 
 

Footnotes

 

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

Vassilios Stefanidis 2014-04-09 17:35:08
Hello,
I have noticed that there is a possible error in the Chapter 2.2 and in particular Case 7 and Case 9 (same typing error).

In other words, it is mentioned that: "the UE is in Idle State (EMM-Deregistered, ECM-Idle and RRC-Idle)", but the correct state in the parenthesis should be: EMM-Registered, ECM-Idle and RRC-Idle, i.e. not Deregistered. The fact that this is wrong is also denoted from the colour of the this particular phrase: it is green, so it should be "EMM-Registered + ECM-Idle + RRC-Idle".

The same applies for case 9. I guess that it is from "copy and paste"... Please correct it, since the document is very good and it explains, in not many details, how a UE moves from one State to the other, in plain english.

BR
Vassilis
Netmanias 2014-04-10 12:33:39
Hello Vassilis,
Thank you for noticing the typo. We've fixed it and posted the updated file.
Vassilios Stefanidis 2014-04-14 22:11:13
Hello again,

I downloaded the latest version of the document, but I think that the error has not been corrected. I guess that my description was not clear enough.

For example in case 7, we have:

“(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-Deregistered, ECM-Idle and RRC-Idle) state.”
However, the first line contradicts the sentence in the parenthesis of the second line. My understanding is that they should be the same and the same color, i.e. EMM-Registered, ECM-Idle and RRC-Idle (green color) and not EMM-Deregistered, ECM-Idle and RRC-Idle (it should have been grey color, anyway).

Please let me know if my understanding is correct, or not.

(Same applies for case 9)
Thanks

Vassilis
Netmanias 2014-04-15 17:02:31
Hello Vassilis,

Mistakenly, ppt version was updated. We fixed it and posted the updated word file.
Thank you for your kind noticing.
Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
banner
Related Contents
08/22/2014
Netmanias Technical Documents
06/11/2014
Netmanias Technical Documents
05/07/2014
Netmanias Technical Documents
04/23/2014
Netmanias Technical Documents
04/08/2014
Netmanias Technical Documents
03/21/2014
Netmanias Technical Documents
02/19/2014
Netmanias Technical Documents
02/09/2014
Netmanias Technical Documents
01/25/2014
Netmanias Technical Documents

 

 

     
         
     

 

     
     

Subscribe FREE >>

Currently, 47,000+ subscribed to Netmanias.

  • You can get Netmanias Newsletter

    (New contents, Korea ICT News)

  • You can view all netmanias' contents

  • You can download all netmanias'

    contents in pdf file

     
     

 

     
         
     

 

 

 

 

     
         
     

 

     
     

KOREA ICT RESEARCH REPORT

SK Telecom's Massive IoT Deployment through LoRa for Small Things

 

 

SK Telecom commercialized the world’s first nationwide LoRa-based, IoT dedicated network in the end of June. This report will discuss how well SK Telecom is poised for the emerging IoST sector, and where it is heading.

 

     
     

 

     
         
     

 

     
         
     

 

     
     

How to contribute articles to Netmanias!

We always welcome contributed articles. Share your expertise and inspire others!

     
     

 

     
         
     

 

 

View All (170)
Attach (1) Backbone (2) Backhaul (3) CMIP (1) CPM (2) Carrier Ethernet (3) Charging (1) DHCP (4) Detach (1) ECM (2) EMM (16) EPS (2) Google (1) HLS (1) HTTP Adaptive Streaming (3) Handover (5) IGMP (1) IPTV (4) Identification (3) Identifier (2) Initial Attach (1) Interworking (1) Korea (1) LTE (36) LTE-A (1) MPLS (2) Mobile IP (1) Mobility (2) Multicast (2) NAT (7) Netflix (1) Network Architecture (3) Network Protocol (20) OTT (1) PCC (1) PCRF (1) PIM (1) PMIP (1) Progressive Download (1) QoS (3) RCS (3) SDF (2) SIMPLE IM (2) SK Telecom (1) STUN (2) Samsung (1) Security (5) TPS (1) Transparent Cache (1) Video Streaming (4) Wi-Fi (1) YouTube (2)
Password confirmation
Please enter your registered comment password.
Password