Table of Contents 1. Introduction |
2. EMM Case 10. Move to Another City
2.1 Moving in Connected State
In Figure 2, we can see how UE, while using services in City 1, is detached from the network as it moves out of the LTE coverage.
Figure 2. Move to Another City in “Connected” State
1) [UE → eNB] Measurement Report
As the UE leaves City 1, the signal strength received from the serving cell gets weaker. In case A2 event has been activated, the UE sends a Measurement Report message to eNB, informing the signal strength of the serving cell.
2) [eNB] No Neighbor Cell to Hand Over to
The eNB finds no neighbor cell to hand the UE over to.
3) [eNB → MME] Error Indication
Due to the worsening communication quality, delivery fails over the radio interface. The eNB informs the MME of such failure by sending an Error Indication (Cause=Failure in the Radio Interface2) message (if the eNB finds it hard to maintain the minimum quality required for communication with the UE, it may send the MME an UE Context Release Request message).
If the UE loses the RRC connection due to poor communication quality, the UE attempts RRC connection re-establishment. If the quality degradation is temporary, the RRC connection is re-established allowing for normal radio communication. In such case, service provision is not interrupted. If the degradation persists, the RRC connection re-establishment will continue to fail, causing the connection to be lost eventually.
It is assumed here that i) the eNB sends an Error Indication to the MME while the RRC connection with the UE is still valid, and ii) the MME decides to detach the UE because the current serving cell of the UE is located near the city border, and has no neighbor cell to hand over to. So, the MME triggers a detach procedure.
4) MME-initiated Detach
The MME performs a detach procedure by sending the UE a Detach Request message. Here the procedure is the same as the “MME-initiated Explicit Detach procedure” explained in our previous document [2]3. The MME stores the UE’s GUTI and NAS security context, terminates the EPS session, releases the S1 signaling, and transits to Detach state (EMM-Deregistered, ECM-Idle). The UE stores its GUTI and NAS security context, deletes the EPS bearer context, and then transits to Detach state (EMM-Deregistered, ECM-Idle, RRC-Idle).
2.2 Moving in Idle State
UE performs periodic TAU to report its location to the network periodically while it stays in Idle state (see the previous document [5] for details). When there is an incoming call/packet for the UE, MME does not know whether the UE is reachable or not if it is in Idle state. For this reason, UE in Idle state periodically reports its location even while staying in a TA in the TAI list so that the network can see whether the UE is reachable or not. To this end, MME has a TAU timer (T3412), mobile reachable timer, and implicit detach timer. The TAU timer (T3412) value is forwarded to UE through an Attach Accept message when the UE makes initial attach to the network, or through a TAU Accept message when the UE makes a TAU request.
A TAU timer (T3412) defaults to 54 minutes [4]. If MME sets this value to “0”, UE deactivates the TAU timer, and does not perform periodic TAU (Wouldn’t it be used for M2M communications?). The TAU timer in UE is activated when the UE transits from Connected state (EMM-Registered, ECM-Connected, RRC-Connected) to Idle state (EMM-Registered, ECM-Idle, RRC-Idle). When the timer expires, the UE transits to Connected state to send MME a TAU Request message informing it is reachable, and then transits back to Idle state, restarting the TAU timer. The UE stops the timer if it transits from Idle to Connected state, or if it is detached from the network.
If the TAU timer that MME set for the UE expires, the MME shortly receives a TAU Request message4, through which it keeps track of the UE’s location. Then, it re-allocates a new TAI list if needed, and then re-starts the TAU timer. That is, the network checks whether the UE is reachable or not at least at the end of every TAU timer cycle, and sets Paging Proceed Flag to “1”, indicating the UE is reachable.
If the UE has any problem (for example, if it is within a shadowing area at the time of T3412 timer expiration, and hence not reachable), it cannot make a TAU request required upon the expiration of T3412, and hence fails to inform MME of its location. UE is required to re-attempt when a TAU request is failed. So, if the UE gets out of the shadowing area soon after, then the re-attempted TAU request can be made successfully. However, if it stays in the shadowing area, then any further TAU requests will continue to fail.
A mobile reachable timer is used by the network to check whether UE is reachable or not. Compared to the TAU timer (T3412), it has a slightly higher value, defaulting to “T3412 + 4 minutes”. The timer starts when the ECM connection with UE is released (e.g. if UE transits to Idle state), and stops when a new ECM connection is established (e.g. if UE sends a TAU Request message to MME).
When the mobile reachable timer expires, MME knows UE is out of the LTE coverage, but does not know for how long the out of the coverage status has lasted. So, instead of deleting the UE’s context right away, the MME clears the PPF flag and starts the implicit detach timer. When the PPF flag is cleared, the UE is locally detached. That is, while the implicit detach timer runs, the network still keeps the UE context undeleted, but the MME does not page the UE (of course because it does not know where the UE is). Even when S-GW sends the MME a Downlink Data Notification message upon arrival of a call/packet destined to the UE, the MME declines the message.
When the UE sends a NAS message, establishing an ECM connection, the implicit detach timer stops. If the MME is unable to locate the UE before the implicit detach timer is expired, it believes the UE has long been out of the LTE coverage, and thus detaches the UE from the network. Now, the UE context is deleted in the network.
Figure 3 illustrates how UE that has been camping on the serving cell in City 1 is detached from the network as it moves out of the LTE coverage.
Figure 3. Move to Another City in “Idle” State
1) [MME] TAU Timer (T3412) Expiry
The TAU timer set for UE is expired. The MME has not received a TAU Request message from the UE, and must check whether the UE is reachable or not.
2) [MME] Mobile Reachability Timer Expiry
The UE’s mobile reachable timer is also expired. The MME, believing the UE is in the “out of coverage” status, clears the PPF flag and starts the implicit detach timer. The resources allocated to the UE (e.g. EPS bearer, security context, etc.) are kept valid, but the MME does not page the UE.
3) [MME] Mobile Implicit Timer Expiry
The UE’s implicit detach timer is expired. The MME, believing the UE has long been “out of the coverage”, decides to implicitly detach the UE from the network.
4) [eNB, MME, S-GW, P-GW, PCRF] UE Detached
The MME initiates an implicit detach procedure. This procedure is the same as the “MME-initiated Implicit Detach procedure” explained in the previous document [2]. The allocated resources and context of the UE are deleted.
Hi Netmanias,
Thanks for your share. It's very helpful for me.
But I have question : When UE perform move from MME1 to MME2, UE need "initial attach in Another City" => UE will no service (short time), right? If true, how many time UE no service?
Thanks,
Hi,
I like this helpful article, but I have one quetion related to the implicit detach timer.
I know when the UE moves out of the shadow area while the implicit detach timer is running, the UE should establish a radio link to the MME by operations such as a tracking area update or a service request. here is the question, if it's a TAU, then this is TAU type should be a normal TAU or a periodic TAU? thank you, and respond to me, please~
I'm wondering whether from MME perspective UE considered attached after UE context update and before LUR completed.
Hi,
Why Mobile reachability timer value is higher than T3412 i.e T3412+ 4 minutes? what is the significance of those 4 minutes.