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.
2) [UE] Handling Security and Bearer Contexts
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).
0 Comments