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 GUTI³) 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 list⁴ 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 time⁵ 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 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 context⁶) 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 (K_NASint) (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 (K_NASint) (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.