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 three chapters (III, IV and V) describe 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 1 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.
Figure 1. Connections and States before/after Detach
III. UE-initiated Detach
Figure 2 shows how user-initiated detach is performed. The detach procedure for this type of detach begins when detach triggering is detected at UE (see Chapter II), 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.
Figure 2. Procedure for UE-initiated Detach
❶ 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).
IV. MME-initiated Detach
Figure 3 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.
Figure 3. Procedure for MME-initiated Detach
❶ 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.
V. HSS-initiated Detach
Figure 4 provides an illustration of how HSS initiates detach after detecting detach triggering.
Figure 4. Procedure for HSS-initiated Detach
❶ 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).
VI. 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 (see [2] for more information).
6.1 Before Detach
According to the EMM Case 2 scenario, 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 in EMM Case 1 (see [2] for more information). Figure 5 lists the information stored in each EPS entity before detach is performed.
Figure 5. Information in EPS Entities before Detach
6.2 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.
Figure 6. Information in EPS entities after Detach
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
VII. Closing
We have learned how a user, while connected to the LTE network, detaches/is detached from the LTE network (“EMM Case 2” in [1]). We categorized detach cases depending on the entity that detects detach triggering, and looked into the detach procedures in each case. We also checked, after detach, what kinds of information elements are stored at UE, MME and HSS for later use at next attach. The subsequent document will discuss how S1 resource is released when a user, after initial attach, stays inactive for a certain period of time (“EMM Case 3. S1 Release due to User Inactivity” in [1]).
References
[1] Netmanias Technical Document, “Eleven EMM Cases in an EMM Scenario”, October 2013.
[2] Netmanias Technical Document, “LTE EMM Procedure 1. Initial Attach – Part 2. Call Flow of Initial Attach”, January 2014.
[3] NMC Consulting Group Confidential Internal Report, “E2E LTE Network Design”, August 2010
