Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | Korea Communication Market Data | List of Contributors | Become a Contributor |    
 
 
Section 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung   Korean Vendors
 
CHANNELS     HFR    |  Mobile Fronthaul Solution  |  Carrier Ethernet Solution  | Resources        
CHANNELS     ZARAM    |  XGSPON 10G SFP+ ONT  |  Use cases  | Evolution of FTTH Access Network    

 

EMM Procedure 1. Initial Attach - Part 1. Cases of Initial Attach
December 26, 2013 | By Netmanias (tech@netmanias.com)
Online viewer:
Comments (22)
44
Page 2 of 4

 

     

Table of Contents  

1. Introduction
2. Cases of Initial Attach

        2.1 Unknown UE

        2.2 Known UE
3. Simplified Call Flow in Each Case

4. Closing

 

 

2. Cases of Initial Attach

 

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 (see Chapter III):

  • Ÿ 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?)

 

Figure 1. Criteria for Classification of Initial Attach

 

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”. Section 2.1 describes initial attach by unknown UEs while Section 2.2 explains one by known UEs. Below, we will assume Attach Request messages are sent integrity-protected if the UE has the Last Attach Information.

 

2.1 Unknown UE

 

Figure 2 illustrates 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”.

 

 

Figure 2. Initial Attach Cases by Unknown UE

 

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:

  1. A UE sends an MME an Attach Request message using its IMSI as a UE ID. The MME obtains the IMSI from the message.
  2. The MME, assuming it doesn’t know the UE (because an IMSI was sent), initiates procedures for authentication and NAS security setup.
  3. The MME sends a location update message to HSS, informing the HSS that the UE is registered with it, and downloads the subscription information of the user from the HSS.

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

 

This is when a UE, still having the Last Attach Information (Old GUTI and NAS security context6) even after its last detach, is trying to attach to the same MME, but the MME doesn’t have any valid UE context of the UE. An exemplary scenario can be as follows:

  1. 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).
  2. 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).
  3. The MME sends the UE an Identity Request message, requesting an IMSI.
  4. The UE sends the MME an Identity Response message, providing the requested IMSI.
  5. 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:

  1. 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.
  2. When the New MME receives the message, it knows from the Old GUTI that it was assigned by other MME (Old MME).
  3. 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.
  4. 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).
  5. 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.

 

2.2 Known UE

 

Figure 3 shows 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.

 

 

Figure 3. Initial Attach Cases by Known UE

 

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:

  1. 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).
  2. 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)).
  3. 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 sceneario can be as follows:  

  1. 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.
  2. The New MME knows from the received Old GUTI that it was assigned other MME (Old MME).
  3. 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.
  4. 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.
  5. The Old MME conducts an integrity check on the Attach Request message.
  6. 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.

 

 

Page 2 of 4
Dirk Van Aken 2013-12-31 07:39:05
Hello Netmanias,

I have been an xDSL/GPON/Ethernet/IP System Architect for the past 15 years and recently I started to work on LTE.
During one of my searches on detailed LTE information I came accross your site.
Looking at your papers and presentations, I must admit I never saw more detailled drawings than yours !
Congratulations for those who created them !

I wonder which software package are you using ?
I'm a regular Microsoft Visio user but IMO this package falls short for this kind of drawings ..
Netmanias 2013-12-31 15:55:57
Hello Mr. Dirk Van Aken,

Thanks for having interest in our site.

Most of our diagrams were created using Microsoft Visio. And we didn't use any special SW package.
While providing professional consulting services in various technical fields over 10 years, we have created quite a lot of Visio templates ourselves.

Sincerely,
Netmanias.com
Paulos Rizos 2014-01-02 18:11:13
Top quality as always, really appreciating these english versions. Looking forward to the next technical document.
Boonchai 2014-03-18 16:37:55
Excellent Thank you
Boonchai 2014-03-18 16:38:25
Excellent Reference to understand
ASHOK 2014-04-04 22:04:23
Very nice and easy to understand...
ASHOK 2014-04-04 22:04:52
Very nice and easy to understand.. and more informative as well
Naresh Babu 2014-06-26 20:38:02

This is what I need to understand call flows. Finally I am in right place.

tuan 2014-08-07 18:48:38

thanks you

vipin garg 2014-10-01 14:57:33

Hi Netmanias,

 

Thanks for these excellent explanations. Recently I cleared an interview in which your tutorials played a major role.  :)

 

Keep goind and enlighten the world with technology knowledge

gvsathyam 2014-11-28 19:18:39

Hi Netmanias,

 

Could you please provide your tutorials on LTE RACH & HARQ procedures ?

 

 

Raghu 2014-12-09 20:25:33

Nice to understand and very intresting

gecuili 2015-01-23 19:20:06

 I think, the scene ii) the MME doesn’t have the valid Last UE Context of the UE can cover the  scene iv) the UE was detached from other MME last time.

Kendy Nowax 2015-04-03 19:00:44

Thanks for this material.

Very helpful and easy to understand. Hope that you will upload some material about AS side.

 

Ayaz mohammed 2015-07-02 21:26:38

Thanks Alot....

Nice and simple..Please share more documents on LTE..

Ritzmond M. Josef 2015-07-12 23:23:10

Very informative... Thanks a lot netmanias.com. Keep it up!

Tony Lee 2015-09-22 07:13:58

Your material is great! A good introdution before one dive into 3gpp spec

aleksandar 2016-02-27 14:32:18

Hello,


Do you maybe have call flow for the following case:

1.Subscriber is attached to 2-3G network.

2.Subscriber is not provisioned on HSS

3.Subscriber is using LTE capable phone.


Subscriber has active 2-3G PDP session. What is the scenario when UE attempts to handover to 4G in this case? Can Modify Bearer request from MME to SGW happen before successfull ULR/ULA (that obviously can not  be successfull, as subscriber is not provisioned in HSS)?

Thank You!

prahladbutola 2016-03-05 21:31:34

In a very simple way the subject is explained nicely...

AnnaG 2016-04-27 03:01:49

Very good documentation. Easy to understand and to the point.

Had a question- Figure 2 Attache case 3. If the NAS security setup is already done with OLD MME, when the UE attaches to the new MME, How can the new MME process these messages and contact the old MME ? Wont the integrity check fail as the integrity setup of the UE was with old MME and not the new MME ?

santosh.patra 2016-06-24 12:16:23

Very useful and easy to understand the flow end to end...Kudos to the team.

 

Thank U.

chamod 2019-09-17 15:02:20

Man who is uploading this contain deservers a nobel ;-)

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
Related Contents
08/01/2018
Netmanias Technical Documents
04/02/2018
Netmanias Technical Documents
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
View All (173)
5G (7) Backbone (2) Backhaul (3) Blockchain (1) CDN (1) Carrier Ethernet (3) Charging (1) DHCP (4) ECM (2) EMM (16) EPS (2) Google (1) HLS (1) HTTP Adaptive Streaming (3) Handover (5) IPTV (4) Initial Attach (2) IoT (2) Korea (1) LTE (39) LTE Identification (2) LTE-A (1) MPLS (2) Mobility (2) NAT (7) Netflix (1) Network Architecture (3) Network Protocol (20) New Radio (1) OTT (1) PCRF (3) QoS (3) RCS (3) SDF (2) SDN/NFV (3) SK Telecom (1) Samsung (2) Security (5) Sk Telecom (1) Transparent Cache (1) Video Streaming (4) VoLTE (2) Wi-Fi (1) YouTube (2)
Password confirmation
Please enter your registered comment password.
Password