In this article major topic will be Tracking Area Update (TAU) procedure. What cause it, how the procedure made and what it causes for UE.
Because there are couple of reasons why TAU can take place we won't start from picture as always.
Almost all what you will see below you can read in details in 3GPP TS 23.401.
Also, maybe you are looking for Periodic Tracking Area Update, don't you huh?
According to the spec I've mentioned above a standalone tracking area update occurs when a GPRS-attached or E UTRAN-attached UE experiences any of the following conditions:
For trigger marked with "*" the UE shall include a UE radio capability information update needed IE in the TRACKING AREA UPDATE REQUEST message.
The TAU procedure is initiated by an UE in either ECM-IDLE state or ECM-CONNECTED state. The decision to perform SGW change during the tracking area update procedure is made by the MME independently from the triggers above.
The eNodeB shall include TAI+ECGI of the current cell in every S1AP Uplink NAS Transport message it sends. There are situations where eNodeB can contain cells from more than one TA and cell changes that happen on same sNodeB are not notified to the MME. However to finish TAU procedure with accept message MME needs to know UE's current TAI.
Step 1. One of the triggers for starting the TAU procedure occurs.
Step 2. The UE initiates the TAU procedure by sending, to the eNodeB, a TAU Request message together with RRC parameters indicating the Selected Network and the old GUMMEI. An exception is that, if the TAU was triggered for load re-balancing purposes, the old GUMMEI is not included in the RRC parameters.
Step 3. The eNodeB derives the MME from the RRC parameters carrying the old GUMMEI and the indicated Selected Network. If that MME is not associated with that eNodeB or the GUMMEI is not available or the UE indicates that the TAU procedure was triggered by load re-balancing, the eNodeB selects an MME.
Step 4. The new MME uses the GUTI received from the UE to derive the old MME/S4 SGSN address, and sends a Context Request message to the old MME/old S4 SGSN to retrieve user information. UE Validated indicates that the new MME has validated the integrity protection of the TAU message, e.g. based on native EPS security context for the UE. To validate the Context Request the old MME uses the complete TAU Request message and the old S4 SGSN uses the P-TMSI Signature and responds with an appropriate error if integrity check fails in old MME/S4 SGSN. This shall initiate the security functions in the new MME. If the security functions authenticate the UE correctly, the new MME shall send a Context Request (IMSI, complete TAU Request message, MME Address, UE Validated) message to the old MME/S4 SGSN with the UE Validated set. If the new MME indicates that it has authenticated the UE or if the old MME/old S4 SGSN correctly validates the UE, then the old MME/old S4 SGSN starts a timer.
If the UE with emergency bearers is not authenticated in the old MME/old S4 SGSN (in a network supporting unauthenticated UEs) the old MME/old S4 SGSN continues the procedure with sending a Context Response and starting the timer also when it cannot validate the Context Request.
Step 5. If the Context Request is sent to an old MME the old MME responds with a Context Response message.
If the Context Request is sent to an old S4 SGSN the old S4 SGSN responds with a Context Response message.
Step 6. If the integrity check of TAU Request message (sent in step 2) failed, then authentication is mandatory. If GUTI allocation is going to be done and the network supports ciphering, the NAS messages shall be ciphered.
If this TAU request is received for a UE which is already in ECM_CONNECTED state and the PLMN-ID of the TAI sent by the eNodeB in Step 3 is different from that of the GUTI, included in the TAU Request message, the MME shall delay authenticating the UE until after Step 21 (TAU Complete message).
NOTE: The MME delays the authentication such that the UE first updates its registered PLMN-ID to the new PLMN-ID selected by the RAN during handover. The new PLMN-ID is provided by the MME to the UE as part of the GUTI in the TAU accept message in Step 20. Doing this ensures that the same PLMN-ID is used in the derivation of the Kasme key by both the network and the UE.
If the new MME is configured to allow emergency services for unauthenticated UE the new MME behave as follows:
If the MME has changed the new MME sends a Context Acknowledge (SGW change indication) message to the old MME/old S4 SGSN. SGW change indication indicates a new SGW has been selected. The old MME/old S4 SGSN marks in its UE context that the information in the GWs is invalid. And, if the old node is an MME, the old MME marks in its UE context that the information in the HSS is invalid. This ensures that the old MME/old S4 SGSN updates the GWs, and the old MME updates the HSS, if the UE initiates a TAU or RAU procedure back to the old MME/old S4 SGSN before completing the ongoing TAU procedure. If the security functions do not authenticate the UE correctly, then the TAU shall be rejected, and the new MME shall send a reject indication to the old MME/old S4 SGSN. The old MME/old S4 SGSN shall continue as if the Identification and Context Request was never received.
Step 8. If the MME has changed the new MME verifies the EPS bearer status received from the UE with the bearer contexts received from the old MME/old S4 SGSN. If the MME has not changed the MME verifies EPS bearer status from the UE with the bearer contexts available in the MM context. The MME releases any network resources related to EPS bearers that are not active in the UE. If there is no bearer context at all, the MME rejects the TAU Request.
If the MME selected a new Serving GW it sends a Create Session Request message per PDN connection to the selected new SGW. The PGW address and TFT are indicated in the bearer Contexts. Type indicates to the SGW to send the Create Session Request to the PGW.
NOTE: The User CSG Information IE is only sent in step 8 if the "Active flag" is set in the TAU Request message.
Step 9. The SGW informs the PGW(s) about the change of for example the RAT type that e.g. can be used for charging, by sending the message Modify Bearer Request per PDN connection to the PGW(s) concerned. User Location Information IE and/or UE Time Zone IE and/or User CSG Information IE are also included if they are present in step 8.
Step 9a. If dynamic PCC (Policy and Charging Control) is deployed, and RAT type information needs to be conveyed from the PGW to the PCRF, then the PGW shall send RAT type information to the PCRF by means of an IP CAN Session Modification procedure.
NOTE: The PGW does not need to wait for the PCRF response, but continues in the next step. If the PCRF response leads to an EPS bearer modification the PGW should initiate a bearer update procedure.
Step 10. The PGW updates its bearer contexts and returns a Modify Bearer Response (MSISDN, Charging Id) message. The MSISDN is included if the PGW has it stored in its UE context.
Step 11. The SGW updates its bearer context. This allows the SGW to route bearer PDUs to the PGW when received from eNodeB.
The SGW returns a Create Session Response message to the new MME.
Step 12. The new MME verifies whether it holds subscription data for the UE identified by the GUTI, the additional GUTI or by the IMSI received with the context data from the old CN node. If there are no subscription data in the new MME for this UE, or for some network sharing scenario (e.g. GWCN) if the PLMN-ID of the TAI supplied by the eNodeB is different from that of the GUTI in the UE's context, then the new MME sends an Update Location Request message to the HSS. ULR-Flags indicates that update location is sent from an MME and the MME registration shall be updated in HSS. The HSS does not cancel any SGSN registration. The MME capabilities indicate the MME's support for regional access restrictions functionality. Homogenous Support of IMS Over PS Sessions indicates whether or not "IMS Voice over PS Sessions" is supported homogeneously in all TAs the serving MME.
If all the EPS bearers of the UE have emergency ARP value, the new MME may skip the update location procedure or proceed even if the update location fails.
Step 13. The HSS sends the message Cancel Location (IMSI, Cancellation Type) to the old MME with Cancellation Type set to Update Procedure.
Step 14. If the timer started in step 4 is not running, the old MME removes the MM context. Otherwise, the contexts are removed when the timer expires. It also ensures that the MM context is kept in the old MME for the case the UE initiates another TAU procedure before completing the ongoing TAU procedure to the new MME. The old MME acknowledges with the message Cancel Location Ack (IMSI).
Step 15. When old S4 SGSN receives the Context Acknowledge message and if the UE is in Iu Connected, the old S4 SGSN sends an Iu Release Command message to the RNC after the timer started in step 4 has expired.
Step 16. The RNC responds with an Iu Release Complete message.
Step 17. The HSS acknowledges the Update Location Request message by sending an Update Location Ack (IMSI, Subscription Data) message to the new MME. If the Update Location is rejected by the HSS, the new MME rejects the TAU Request from the UE with an appropriate cause. The Subscription Data may contain the CSG subscription data for the PLMN.
If the UE initiates the TAU procedure at a CSG cell, the new MME shall check whether the CSG ID is contained in the CSG subscription and is not expired. If the CSG ID is not present or expired, the MME shall send a Tracking Area Update reject message to the UE with an appropriate cause value. The UE shall remove the CSG ID from its Allowed CSG list if present. If the UE has ongoing emergency bearer services no CSG access control shall be performed.
If all checks are successful then the new MME constructs a context for the UE.
Step 18. If the MME has changed, when the timer started in step 4 expires the old MME/old S4 SGSN releases any local MME or SGSN bearer resources and if it received the SGW change indication in the Context Acknowledge message, the old MME/old S4 SGSN deletes the EPS bearer resources by sending Delete Session Request (Cause) messages to the old SGW. Cause indicates to the old SGW that the old SGW shall not initiate a delete procedure towards the PGW. If ISR is activated the cause also indicates to the old SGW that the old SGW shall delete the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that CN node. If the MME has not changed, step 11 triggers the release of EPS bearer resources when a new SGW is allocated.
Step 19. The SGW acknowledges with Delete Session Response (Cause) messages. The SGW discards any packets buffered for the UE.
Step 20. If due to regional subscription restrictions or access restrictions (e.g. CSG restrictions) the UE is not allowed to access the TA:
When receiving the TAU Accept message and there is no ISR Activated indication the UE shall set its TIN to "GUTI".
For a SGW change, ISR Activated is never indicated by the MME as it needs a RAU with the same SGW first to activate ISR. For an MME change, ISR is not activated by the new MME to avoid context transfer procedures with two old CN nodes.
If the TAU procedure is initiated by manual CSG selection and occurs via a CSG cell, the UE upon receiving the TAU Accept message shall add the CSG ID to its Allowed CSG list if it is not already present. Manual CSG selection is not supported if the UE has emergency bearers established.
If the user plane setup is performed in conjunction with the TAU Accept message and the TAU is performed via a hybrid cell, then the MME shall send an indication whether the UE is a CSG member to the RAN along with the S1-MME control message. Based on this information the RAN may perform differentiated treatment for CSG and non-CSG members.
NOTE: If the UE receives a TAU Accept message via a hybrid cell, the UE does not add the corresponding CSG ID to its Allowed CSG list. Adding a CSG ID to the UE's local Allowed CSG list for a hybrid cell is performed only by OTA or OMA DM procedures.
Step 21. If GUTI was included in the TAU Accept, the UE acknowledges the received message by returning a TAU Complete message to the MME.
When the "Active flag" is not set in the TAU Request message and the Tracking Area Update was not initiated in ECM-CONNECTED state, the new MME releases the signalling connection with UE.
NOTE:The new MME may initiate E RAB establishment after execution of the security functions, or wait until completion of the TA update procedure. For the UE, E RAB establishment may occur anytime after the TA update request is sent.
In the case of a rejected tracking area update operation, due to regional subscription, roaming restrictions or access restrictions the new MME shall not construct an MM context for the UE. A reject shall be returned to the UE with an appropriate cause and the S1 connection shall be released. Upon return to idle, the UE shall act.
The new MME shall determine the Maximum APN restriction based on the received APN Restriction of each bearer context in the Context Response message and then store the new Maximum APN restriction value.
The bearer contexts shall be prioritized by the new MME. If the new MME is unable to support the same number of active bearer contexts as received from old MME/SGSN, the prioritisation is used to decide which bearer contexts to maintain active and which ones to delete. In any case, the new MME shall first update all contexts in one or more PGWs and then deactivate the bearer context(s) that it cannot maintain. This shall not cause the MME to reject the tracking area update.
The new MME shall not deactivate emergency service related EPS bearers, i.e. EPS bearers with ARP values reserved for emergency services.
NOTE: If MS (UE) was in PMM-CONNECTED state the bearer contexts are sent already in the Forward Relocation Request message.
If the tracking area update procedure fails a maximum allowable number of times, or if the MME returns a Tracking Area Update Reject (Cause) message, the UE shall enter EMM DEREGISTERED state.
NOTE: In case of Tracking Area Update without MME change the signalling in steps 4, 5, 7 and steps 9-19 are skipped.
Step 1. One of the triggers described in clause 5.3.3.0 for starting the TAU procedure occurs.
Step 2. The UE initiates a TAU procedure by sending, to the eNodeB, a Tracking Area Update Request message together with RRC parameters indicating the Selected Network and the old GUMMEI. An exception is that, if the TAU was triggered for load re-balancing purposes, the old GUMMEI is not included in the RRC parameters.
The additional GUTI in the Tracking Area Update Request message allows the new MME to find any already existing UE context stored in the new MME when the old GUTI indicates a value mapped from a P-TMSI and RAI.
The RRC parameter "old GUMMEI" takes its value from the identifier that is signalled as the old GUTI according to the rules above. For a combined MME/SGSN the eNodeB is configured to route the MME code(s) of this combined node to the same combined node. This eNodeB is also configured to route MME code(s) of GUTIs that are generated the UE's mapping of the P TMSIs allocated by the combined node. Such an eNodeB configuration may also be used for separate nodes to avoid changing nodes in the pool caused by inter RAT mobility.
The last visited TAI shall be included in order to help the MME produce a good list of TAIs for any subsequent TAU Accept message. Selected Network indicates the network that is selected. Active flag is a request by the UE to activate the radio and S1 bearers for all the active EPS Bearers by the TAU procedure. The UE's ISR capability is included in the UE Core Network Capability element. The EPS bearer status indicates each EPS bearer that is active in the UE. The TAU Request message shall be integrity protected by the NAS-MAC. KSIASME is included if the UE has valid security parameters. NAS sequence number indicates the sequential number of the NAS message.
KSISGSN is included if the UE indicates a GUTI mapped from a P-TMSI in the information element "old GUTI".
Step 3. The eNodeB derives the MME from the RRC parameters carrying the old GUMMEI and the indicated Selected Network. If that GUMMEI is not associated with the eNodeB, or the GUMMEI is not available or the UE indicates that the TAU procedure was triggered by load re-balancing, the eNodeB selects the MME. The eNodeB forwards the TAU Request message together with the CSG access mode, CSG ID, TAI+ECGI of the cell from where it received the message and with the Selected Network to the MME. CSG ID is provided by RAN if the UE sends the TAU Request message via a CSG cell or a hybrid cell. CSG access mode is provided if the UE sends the TAU Request message via a hybrid cell. If the CSG access mode is not provided but the CSG ID is provided, the MME shall consider the cell as a CSG cell.
Step 4. The new MME uses the GUTI received from the UE to derive the old MME/S4 SGSN address and sends a Context Request message to the old MME/S4 SGSN to retrieve the user information. UE Validated indicates that the new MME has validated the integrity protection of the TAU message, e.g. based on native EPS security context for the UE. To validate the Context Request the old MME uses the complete TAU Request message and the old S4 SGSN uses the P-TMSI Signature and responds with an appropriate error if integrity check fails in old MME/S4 SGSN. This shall initiate the security functions in the new MME. If the security functions authenticate the UE correctly, the new MME shall send a Context Request message to the old MME/S4 SGSN with the UE Validated set. If the new MME indicates that it has authenticated the UE or if the old MME/old S4 SGSN authenticates the UE, the old MME/old S4 SGSN starts a timer.
If the UE with emergency bearers is not authenticated in the old MME/old S4 SGSN (in a network supporting unauthenticated UEs) the old MME/old S4 SGSN continues the procedure with sending a Context Response and starting the timer also when it cannot validate the Context Request.
Step 5. If the Context Request is sent to an old MME the old MME responds with a Context Response message.
If the Context Request is sent to an old S4 SGSN the old S4 SGSN responds with a Context Response message. The Authentication Quintets are maintained by the old S4 SGSN.
The PDN GW Address and TEID(s) (for GTP-based S5/S8) or GRE Keys (PMIP-based S5/S8 at the PDN GW(s) for uplink traffic and the TI(s), is part of the EPS Bearer Context. ISR Supported is indicated if the old SGSN and associated Serving GW are capable to activate ISR for the UE.
The new MME shall ignore the UE Core Network Capability contained in the Context Response only when it has previously received an UE Core Network Capability in the Tracking Area Update Request. If the UE is not known in the old MME/old S4 SGSN or if the integrity check for the TAU request message fails, the old MME/old S4 SGSN responds with an appropriate error cause.
If the UE receives emergency services from the old MME/old S4 SGSN and the UE is UICCless, IMSI can not be included in the Context Response. For emergency attached UEs, if the IMSI cannot be authenticated, then the IMSI shall be marked as unauthenticated. Also, in this case, security parameters are included only if available.
Step 6. If the integrity check of TAU Request message (sent in step 2) failed, then authentication is mandatory. If GUTI allocation is going to be done and the network supports ciphering, the NAS messages shall be ciphered.
If this TAU request is received for a UE which is already in ECM_CONNECTED state and the PLMN-ID of the TAI sent by the eNodeB in Step 3 is different from that of the GUTI included in the TAU Request message, the MME shall delay authenticating the UE until after Step 21 (TAU Complete message).
NOTE: The MME delays the authentication such that the UE first updates its registered PLMN-ID to the new PLMN-ID selected by the RAN during handover. The new PLMN-ID is provided by the MME to the UE as part of the GUTI in the TAU accept message in Step 20. Doing this ensures that the same PLMN-ID is used in the derivation of the Kasme key by both the network and the UE.
If the new MME is configured to allow emergency services for unauthenticated UE the new MME behave as follows:
If the old node is an old S4 SGSN the MME sends a Context Acknowledge message to the old SGSN. Unless ISR Activated is indicated by the MME, the old S4 SGSN marks in its context that the information in the GWs is invalid. This ensures that the old S4 SGSN updates the GWs if the UE initiates a RAU procedure back to the old S4 SGSN before completing the ongoing TAU procedure. If ISR Activated is indicated to the old S4 SGSN, this indicates that the old S4 SGSN shall maintain its UE context including authentication quintets and stop the timer started in step 4. In this case, if the Implicit Detach timer is running, the old S4 SGSN shall re-start it with a slightly larger value than the UE's GERAN/UTRAN Deactivate ISR timer. Also, in this case, if the old SGSN has maintained the Serving GW address for user plane and S4 GTP-U TEID, the old SGSN shall remove Serving GW address for user plane and S4 GTP-U TEID locally. When ISR Activated is not indicated and this timer expires the old SGSN deletes all bearer resources of that UE. As the Context Acknowledge from the MME does not include any S GW change the S4 SGSN does not send any Delete Session Request message to the S GW. The MME shall not activate ISR if the associated Serving GW does not support ISR.
If the security functions do not authenticate the UE correctly, then the TAU shall be rejected, and the MME shall send a reject indication to the old MME/old S4 SGSN. The old MME/old S4 SGSN shall continue as if the Identification and Context Request was never received.
Step 8. Void.
Step 9. If the MME has changed the new MME adopts the bearer contexts received from the old MME/SGSN as the UE's EPS bearer contexts to be maintained by the new MME. The MME establishes the EPS bearer(s) in the indicated order. The MME deactivates the EPS bearers which cannot be established.
The MME verifies the EPS bearer status received from the UE with the EPS bearer contexts it maintains and releases any network resources related to EPS bearers that are not active in the UE. If there is no bearer context at all, the MME rejects the TAU Request. If the MME has changed the new MME sends a Modify Bearer Request message per PDN connection to the Serving GW. The PDN GW address is indicated in the bearer contexts. If indicated, the information ISR Activated indicates that ISR is activated. If the PDN GW requested UE's location and/or User CSG information, the MME also includes the User Location Information IE and/or User CSG Information IE in this message. If the UE Time Zone has changed, the MME includes the UE Time Zone IE in this message. If the old node is an old MME at a Tracking Area Update with a MME change ISR Activated shall not be indicated.
NOTE: The User CSG Information IE is only sent in step 9 if the "Active flag" is set in the TAU Request message.
When the Modify Bearer Request does not indicate ISR Activated the S GW deletes any ISR resources by sending a Delete Bearer Request to the other CN node that has bearer resources on the S GW reserved.
Step 10. If the RAT type has changed, or the Serving GW has received the User Location Information IE or the UE Time Zone IE or User CSG Information IE from the MME in step 9, the Serving GW informs the PDN GW(s) about this information that e.g. can be used for charging, by sending the message Modify Bearer Request per PDN connection to the PDN GW(s) concerned. User Location Information IE and/or UE Time Zone IE and/or User CSG Information IE are also included if they are present in step 9.
Step 11. If dynamic PCC is deployed, and RAT type information or UE location information needs to be conveyed from the PDN GW to the PCRF, then the PDN GW shall send this information to the PCRF by means of an IP CAN Session Modification procedure.
NOTE: The PDN GW does not need to wait for the PCRF response, but continues in the next step. If the PCRF response leads to an EPS bearer modification the PDN GW should initiate a bearer update procedure.
Step 12. The PDN GW updates its context field to allow DL PDUs to be routed to the correct Serving GW. PDN GW returns a Modify Bearer Response to the Serving GW. The MSISDN is included if the PDN GW has it stored in its UE context.
Step 13. The Serving GW updates its bearer context. If ISR Activated is indicated in step 9 and RAT Type received in step 9 indicates E UTRAN, then the Serving GW only updates the MME Control Plane Address stored locally and keep the SGSN related information unchanged. Also, in this case, if the Serving GW has maintained the SGSN address for user plane and S4 GTP-U TEID, the Serving GW removes the SGSN address for user plane and S4 GTP-U TEID locally. Otherwise the Serving GW shall update all of the information stored locally for this UE with the related information received from the MME. This allows the Serving GW to route Bearer PDUs to the PDN GW when received from eNodeB. The Serving GW returns a Modify Bearer Response message to the new MME.
Step 14. The new MME verifies whether it holds subscription data for the UE identified by the GUTI, the additional GUTI or by the IMSI received with the context data from the old CN node. If there are no subscription data in the new MME for this UE, or for some network sharing scenario (e.g. GWCN) if the PLMN-ID of the TAI supplied by the eNodeB is different from that of the GUTI in the UE's context, then the new MME informs the HSS of the change of MME by sending an Update Location Request message to the HSS. ULR-Flags indicates that update location is sent from an MME and the MME registration shall be updated in HSS. The HSS does not cancel any SGSN registration. The MME capabilities indicate the MME's support for regional access restrictions functionality. Homogenous Support of IMS Over PS Sessions indicates whether or not "IMS Voice over PS Sessions" is supported homogeneously in all TAs in the serving MME.
If all the EPS bearers of the UE have emergency ARP value, the new MME may skip the update location procedure or proceed even if the update location fails.
Step 15. The HSS sends a Cancel Location message to the old MME with a Cancellation Type set to Update Procedure.
Step 16. When receiving a Cancel Location message and the timer started in step 4 is not running, the old MME removes the MM and bearer contexts. Otherwise, the contexts are removed when the timer expires. It also ensures that the MM context is kept in the old MME for the case the UE initiates another TAU procedure before completing the ongoing TAU procedure to the new MME. The old MME acknowledges with a Cancel Location Ack message.
NOTE: ISR Activated is never indicated from new to old MME.
So an old MME deletes all the bearer resources of the UE in any case when the timer started in step 4 expires, which is independent on receiving a Cancel Location message.
Step 17. When receiving the Context Acknowledge message and if the UE is Iu Connected, the old SGSN sends an Iu Release Command message to the RNC after the timer started in step 4 has expired.
Step 18. The RNC responds with an Iu Release Complete message.
Step 19. The HSS acknowledges the Update Location Request by returning an Update Location Ack message to the new MME after the cancelling of the old MME context is finished. If the Update Location is rejected by the HSS, the MME rejects the TAU Request from the UE with an appropriate cause sent in the TAU Reject message to the UE. If all checks are successful, the MME constructs an MM context for the UE. The Subscription Data may contain the CSG subscription data for the PLMN.
If the UE initiates the TAU procedure at a CSG cell, the new MME shall check whether the CSG ID is contained in the CSG subscription and is not expired. If the CSG ID is not present or expired, the MME shall send a Tracking Area Update reject message to the UE with an appropriate cause value. The UE shall remove the CSG ID from its Allowed CSG list if present.
Step 20. If due to regional subscription restrictions or access restrictions (e.g. CSG restrictions) the UE is not allowed to access the TA:
When receiving the TAU Accept message and there is no ISR Activated indication the UE shall set its TIN to "GUTI". When ISR Activated is indicated and the UE's TIN indicates "GUTI" the UE's TIN shall not be changed. When ISR Activated is indicated and the TIN is "P TMSI" or "RAT related TMSI" the UE shall set its TIN to "RAT related TMSI".
For an MME change ISR is not activated by the new MME to avoid context transfer procedures with two old CN nodes.
For an emergency attached UE, emergency ISR is not activated.
If the TAU procedure is initiated by manual CSG selection and occurs via a CSG cell, the UE upon receiving TAU Accept message shall add the CSG ID to its Allowed CSG list if it is not already present. Manual CSG selection is not supported if the UE has emergency bearers established.
If the user plane setup is performed in conjunction with the TAU Accept message and the TAU is performed via a hybrid cell, then the MME shall send an indication whether the UE is a CSG member to the RAN along with the S1-MME control message. Based on this information the RAN may perform differentiated treatment for CSG and non-CSG members.
NOTE: If the UE receives a TAU Accept message via a hybrid cell, the UE does not add the corresponding CSG ID to its Allowed CSG list. Adding a CSG ID to the UE's local Allowed CSG list for a hybrid cell is performed only by OTA or OMA DM procedures.
Step 21. If the GUTI was changed the UE acknowledges the new GUTI by returning a Tracking Area Update Complete message to the MME.
When the "Active flag" is not set in the TAU Request message and the Tracking Area Update was not initiated in ECM-CONNECTED state, the MME releases the signalling connection with UE.
NOTE: The new MME may initiate E RAB establishment after execution of the security functions, or wait until completion of the TA update procedure. For the UE, E RAB establishment may occur anytime after the TA update request is sent.
In the case of a rejected tracking area update operation, due to regional subscription, roaming restrictions, or access restrictions the new MME shall not construct an MM context for the UE. A reject shall be returned to the UE with an appropriate cause and the S1 connection shall be released.
If the new MME is unable to update the bearer context in one or more P GWs, the new MME shall deactivate the corresponding bearer contexts as described in clause "MME Initiated Dedicated Bearer Deactivation Procedure". This shall not cause the MME to reject the tracking area update.
The new MME shall determine the Maximum APN restriction based on the received APN Restriction of each bearer context in the Context Response message and then store the new Maximum APN restriction value.
The bearer contexts shall be prioritized by the new MME. If the new MME is unable to support the same number of active bearer contexts as received from old MME/SGSN, the prioritisation is used to decide which bearer contexts to maintain active and which ones to delete. In any case, the new MME shall first update all contexts in one or more P GWs and then deactivate the context(s) that it cannot maintain as described in clause "MME Initiated Dedicated Bearer Deactivation Procedure". This shall not cause the MME to reject the tracking area update.
The new MME shall not deactivate emergency service related EPS bearers, i.e. EPS bearers with ARP values reserved for emergency services.
NOTE: If MS (UE) was in PMM-CONNECTED state the bearer contexts are sent already in the Forward Relocation Request message as described in clause "Serving RNS relocation procedures" of TS 23.060 [7].
If the tracking area update procedure fails a maximum allowable number of times, or if the MME returns a Tracking Area Update Reject (Cause) message, the UE shall enter EMM DEREGISTERED state.
If the Update Location Ack message indicates a reject, this should be indicated to the UE, and the UE shall not access non-PS services until a successful location update is performed.
Because there are couple of reasons why TAU can take place we won't start from picture as always.
Almost all what you will see below you can read in details in 3GPP TS 23.401.
Also, maybe you are looking for Periodic Tracking Area Update, don't you huh?
Triggers for TAU procedure
When TAU procedure is taking place SGW can be changed or not, but what really bring Tracking Area Update procedure to live is what we should ask about.According to the spec I've mentioned above a standalone tracking area update occurs when a GPRS-attached or E UTRAN-attached UE experiences any of the following conditions:
- UE detects it has entered a new TA (Tracking Area) that is not in the list of TAIs (Tracking Area Indicators) that the UE registered with the network;
- the periodic TA update timer has expired;
- UE was in UTRAN PMM_Connected state (e.g. URA_PCH) when it reselects to E-UTRAN;
- UE was in GPRS READY state when it reselects to E-UTRAN;
- the TIN indicates "P-TMSI" when the UE reselects to E-UTRAN (e.g. due to bearer configuration modifications performed on GERAN/UTRAN);
- the RRC connection was released with release cause "load re-balancing TAU required";
- the RRC layer in the UE informs the UE's NAS layer that an RRC connection failure (in either E-UTRAN or UTRAN) has occurred;
- when the UE changes the radio capability of at least one of the following radio access technologies: GERAN, UTRAN or CDMA 2000; *
- for a UE supporting CS fallback, or configured to support IMS voice, or both, a change of the UE's usage setting or voice domain preference for E-UTRAN.
- for a SR-VCC capable UE, a change of MS Classmark 2 and/or MS Classmark 3 and/or Supported Codecs.
- UE manually selects a CSG cell whose CSG ID is absent from both the UE's Allowed CSG list and the UE's Operator CSG list.
For trigger marked with "*" the UE shall include a UE radio capability information update needed IE in the TRACKING AREA UPDATE REQUEST message.
The TAU procedure is initiated by an UE in either ECM-IDLE state or ECM-CONNECTED state. The decision to perform SGW change during the tracking area update procedure is made by the MME independently from the triggers above.
The eNodeB shall include TAI+ECGI of the current cell in every S1AP Uplink NAS Transport message it sends. There are situations where eNodeB can contain cells from more than one TA and cell changes that happen on same sNodeB are not notified to the MME. However to finish TAU procedure with accept message MME needs to know UE's current TAI.
Tracking Area Update procedure with Serving GW change
 |
| Fig. 1. Tracking Area Update with SGW change. |
Step 2. The UE initiates the TAU procedure by sending, to the eNodeB, a TAU Request message together with RRC parameters indicating the Selected Network and the old GUMMEI. An exception is that, if the TAU was triggered for load re-balancing purposes, the old GUMMEI is not included in the RRC parameters.
Step 3. The eNodeB derives the MME from the RRC parameters carrying the old GUMMEI and the indicated Selected Network. If that MME is not associated with that eNodeB or the GUMMEI is not available or the UE indicates that the TAU procedure was triggered by load re-balancing, the eNodeB selects an MME.
Step 4. The new MME uses the GUTI received from the UE to derive the old MME/S4 SGSN address, and sends a Context Request message to the old MME/old S4 SGSN to retrieve user information. UE Validated indicates that the new MME has validated the integrity protection of the TAU message, e.g. based on native EPS security context for the UE. To validate the Context Request the old MME uses the complete TAU Request message and the old S4 SGSN uses the P-TMSI Signature and responds with an appropriate error if integrity check fails in old MME/S4 SGSN. This shall initiate the security functions in the new MME. If the security functions authenticate the UE correctly, the new MME shall send a Context Request (IMSI, complete TAU Request message, MME Address, UE Validated) message to the old MME/S4 SGSN with the UE Validated set. If the new MME indicates that it has authenticated the UE or if the old MME/old S4 SGSN correctly validates the UE, then the old MME/old S4 SGSN starts a timer.
If the UE with emergency bearers is not authenticated in the old MME/old S4 SGSN (in a network supporting unauthenticated UEs) the old MME/old S4 SGSN continues the procedure with sending a Context Response and starting the timer also when it cannot validate the Context Request.
Step 5. If the Context Request is sent to an old MME the old MME responds with a Context Response message.
If the Context Request is sent to an old S4 SGSN the old S4 SGSN responds with a Context Response message.
Step 6. If the integrity check of TAU Request message (sent in step 2) failed, then authentication is mandatory. If GUTI allocation is going to be done and the network supports ciphering, the NAS messages shall be ciphered.
If this TAU request is received for a UE which is already in ECM_CONNECTED state and the PLMN-ID of the TAI sent by the eNodeB in Step 3 is different from that of the GUTI, included in the TAU Request message, the MME shall delay authenticating the UE until after Step 21 (TAU Complete message).
NOTE: The MME delays the authentication such that the UE first updates its registered PLMN-ID to the new PLMN-ID selected by the RAN during handover. The new PLMN-ID is provided by the MME to the UE as part of the GUTI in the TAU accept message in Step 20. Doing this ensures that the same PLMN-ID is used in the derivation of the Kasme key by both the network and the UE.
If the new MME is configured to allow emergency services for unauthenticated UE the new MME behave as follows:
- where a UE has only emergency bearer services, the MME either skip the authentication and security procedure or accepts that the authentication may fail and continues the Tracking Area Update procedure; or
- where a UE has both emergency and non emergency bearer services and authentication fails, the MME continues the Tracking Area Update procedure and deactivates all the non-emergency PDN connections.
If the MME has changed the new MME sends a Context Acknowledge (SGW change indication) message to the old MME/old S4 SGSN. SGW change indication indicates a new SGW has been selected. The old MME/old S4 SGSN marks in its UE context that the information in the GWs is invalid. And, if the old node is an MME, the old MME marks in its UE context that the information in the HSS is invalid. This ensures that the old MME/old S4 SGSN updates the GWs, and the old MME updates the HSS, if the UE initiates a TAU or RAU procedure back to the old MME/old S4 SGSN before completing the ongoing TAU procedure. If the security functions do not authenticate the UE correctly, then the TAU shall be rejected, and the new MME shall send a reject indication to the old MME/old S4 SGSN. The old MME/old S4 SGSN shall continue as if the Identification and Context Request was never received.
Step 8. If the MME has changed the new MME verifies the EPS bearer status received from the UE with the bearer contexts received from the old MME/old S4 SGSN. If the MME has not changed the MME verifies EPS bearer status from the UE with the bearer contexts available in the MM context. The MME releases any network resources related to EPS bearers that are not active in the UE. If there is no bearer context at all, the MME rejects the TAU Request.
If the MME selected a new Serving GW it sends a Create Session Request message per PDN connection to the selected new SGW. The PGW address and TFT are indicated in the bearer Contexts. Type indicates to the SGW to send the Create Session Request to the PGW.
NOTE: The User CSG Information IE is only sent in step 8 if the "Active flag" is set in the TAU Request message.
Step 9. The SGW informs the PGW(s) about the change of for example the RAT type that e.g. can be used for charging, by sending the message Modify Bearer Request per PDN connection to the PGW(s) concerned. User Location Information IE and/or UE Time Zone IE and/or User CSG Information IE are also included if they are present in step 8.
Step 9a. If dynamic PCC (Policy and Charging Control) is deployed, and RAT type information needs to be conveyed from the PGW to the PCRF, then the PGW shall send RAT type information to the PCRF by means of an IP CAN Session Modification procedure.
NOTE: The PGW does not need to wait for the PCRF response, but continues in the next step. If the PCRF response leads to an EPS bearer modification the PGW should initiate a bearer update procedure.
Step 10. The PGW updates its bearer contexts and returns a Modify Bearer Response (MSISDN, Charging Id) message. The MSISDN is included if the PGW has it stored in its UE context.
Step 11. The SGW updates its bearer context. This allows the SGW to route bearer PDUs to the PGW when received from eNodeB.
The SGW returns a Create Session Response message to the new MME.
Step 12. The new MME verifies whether it holds subscription data for the UE identified by the GUTI, the additional GUTI or by the IMSI received with the context data from the old CN node. If there are no subscription data in the new MME for this UE, or for some network sharing scenario (e.g. GWCN) if the PLMN-ID of the TAI supplied by the eNodeB is different from that of the GUTI in the UE's context, then the new MME sends an Update Location Request message to the HSS. ULR-Flags indicates that update location is sent from an MME and the MME registration shall be updated in HSS. The HSS does not cancel any SGSN registration. The MME capabilities indicate the MME's support for regional access restrictions functionality. Homogenous Support of IMS Over PS Sessions indicates whether or not "IMS Voice over PS Sessions" is supported homogeneously in all TAs the serving MME.
If all the EPS bearers of the UE have emergency ARP value, the new MME may skip the update location procedure or proceed even if the update location fails.
Step 13. The HSS sends the message Cancel Location (IMSI, Cancellation Type) to the old MME with Cancellation Type set to Update Procedure.
Step 14. If the timer started in step 4 is not running, the old MME removes the MM context. Otherwise, the contexts are removed when the timer expires. It also ensures that the MM context is kept in the old MME for the case the UE initiates another TAU procedure before completing the ongoing TAU procedure to the new MME. The old MME acknowledges with the message Cancel Location Ack (IMSI).
Step 15. When old S4 SGSN receives the Context Acknowledge message and if the UE is in Iu Connected, the old S4 SGSN sends an Iu Release Command message to the RNC after the timer started in step 4 has expired.
Step 16. The RNC responds with an Iu Release Complete message.
Step 17. The HSS acknowledges the Update Location Request message by sending an Update Location Ack (IMSI, Subscription Data) message to the new MME. If the Update Location is rejected by the HSS, the new MME rejects the TAU Request from the UE with an appropriate cause. The Subscription Data may contain the CSG subscription data for the PLMN.
If the UE initiates the TAU procedure at a CSG cell, the new MME shall check whether the CSG ID is contained in the CSG subscription and is not expired. If the CSG ID is not present or expired, the MME shall send a Tracking Area Update reject message to the UE with an appropriate cause value. The UE shall remove the CSG ID from its Allowed CSG list if present. If the UE has ongoing emergency bearer services no CSG access control shall be performed.
If all checks are successful then the new MME constructs a context for the UE.
Step 18. If the MME has changed, when the timer started in step 4 expires the old MME/old S4 SGSN releases any local MME or SGSN bearer resources and if it received the SGW change indication in the Context Acknowledge message, the old MME/old S4 SGSN deletes the EPS bearer resources by sending Delete Session Request (Cause) messages to the old SGW. Cause indicates to the old SGW that the old SGW shall not initiate a delete procedure towards the PGW. If ISR is activated the cause also indicates to the old SGW that the old SGW shall delete the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that CN node. If the MME has not changed, step 11 triggers the release of EPS bearer resources when a new SGW is allocated.
Step 19. The SGW acknowledges with Delete Session Response (Cause) messages. The SGW discards any packets buffered for the UE.
Step 20. If due to regional subscription restrictions or access restrictions (e.g. CSG restrictions) the UE is not allowed to access the TA:
- The MME rejects the Tracking Area Update Request with an appropriate cause to the UE.
- For UEs with emergency EPS bearers, i.e. at least one EPS bearer has an ARP value reserved for emergency services, the new MME accepts the Tracking Area Update Request and deactivates all non-emergency PDN connections.
When receiving the TAU Accept message and there is no ISR Activated indication the UE shall set its TIN to "GUTI".
For a SGW change, ISR Activated is never indicated by the MME as it needs a RAU with the same SGW first to activate ISR. For an MME change, ISR is not activated by the new MME to avoid context transfer procedures with two old CN nodes.
If the TAU procedure is initiated by manual CSG selection and occurs via a CSG cell, the UE upon receiving the TAU Accept message shall add the CSG ID to its Allowed CSG list if it is not already present. Manual CSG selection is not supported if the UE has emergency bearers established.
If the user plane setup is performed in conjunction with the TAU Accept message and the TAU is performed via a hybrid cell, then the MME shall send an indication whether the UE is a CSG member to the RAN along with the S1-MME control message. Based on this information the RAN may perform differentiated treatment for CSG and non-CSG members.
NOTE: If the UE receives a TAU Accept message via a hybrid cell, the UE does not add the corresponding CSG ID to its Allowed CSG list. Adding a CSG ID to the UE's local Allowed CSG list for a hybrid cell is performed only by OTA or OMA DM procedures.
Step 21. If GUTI was included in the TAU Accept, the UE acknowledges the received message by returning a TAU Complete message to the MME.
When the "Active flag" is not set in the TAU Request message and the Tracking Area Update was not initiated in ECM-CONNECTED state, the new MME releases the signalling connection with UE.
NOTE:The new MME may initiate E RAB establishment after execution of the security functions, or wait until completion of the TA update procedure. For the UE, E RAB establishment may occur anytime after the TA update request is sent.
In the case of a rejected tracking area update operation, due to regional subscription, roaming restrictions or access restrictions the new MME shall not construct an MM context for the UE. A reject shall be returned to the UE with an appropriate cause and the S1 connection shall be released. Upon return to idle, the UE shall act.
The new MME shall determine the Maximum APN restriction based on the received APN Restriction of each bearer context in the Context Response message and then store the new Maximum APN restriction value.
The bearer contexts shall be prioritized by the new MME. If the new MME is unable to support the same number of active bearer contexts as received from old MME/SGSN, the prioritisation is used to decide which bearer contexts to maintain active and which ones to delete. In any case, the new MME shall first update all contexts in one or more PGWs and then deactivate the bearer context(s) that it cannot maintain. This shall not cause the MME to reject the tracking area update.
The new MME shall not deactivate emergency service related EPS bearers, i.e. EPS bearers with ARP values reserved for emergency services.
NOTE: If MS (UE) was in PMM-CONNECTED state the bearer contexts are sent already in the Forward Relocation Request message.
If the tracking area update procedure fails a maximum allowable number of times, or if the MME returns a Tracking Area Update Reject (Cause) message, the UE shall enter EMM DEREGISTERED state.
Tracking Area Update procedure without Serving GW change
 |
| Fig. 2. Tracking Area Update without S‑GW change. |
Step 1. One of the triggers described in clause 5.3.3.0 for starting the TAU procedure occurs.
Step 2. The UE initiates a TAU procedure by sending, to the eNodeB, a Tracking Area Update Request message together with RRC parameters indicating the Selected Network and the old GUMMEI. An exception is that, if the TAU was triggered for load re-balancing purposes, the old GUMMEI is not included in the RRC parameters.
The additional GUTI in the Tracking Area Update Request message allows the new MME to find any already existing UE context stored in the new MME when the old GUTI indicates a value mapped from a P-TMSI and RAI.
The RRC parameter "old GUMMEI" takes its value from the identifier that is signalled as the old GUTI according to the rules above. For a combined MME/SGSN the eNodeB is configured to route the MME code(s) of this combined node to the same combined node. This eNodeB is also configured to route MME code(s) of GUTIs that are generated the UE's mapping of the P TMSIs allocated by the combined node. Such an eNodeB configuration may also be used for separate nodes to avoid changing nodes in the pool caused by inter RAT mobility.
The last visited TAI shall be included in order to help the MME produce a good list of TAIs for any subsequent TAU Accept message. Selected Network indicates the network that is selected. Active flag is a request by the UE to activate the radio and S1 bearers for all the active EPS Bearers by the TAU procedure. The UE's ISR capability is included in the UE Core Network Capability element. The EPS bearer status indicates each EPS bearer that is active in the UE. The TAU Request message shall be integrity protected by the NAS-MAC. KSIASME is included if the UE has valid security parameters. NAS sequence number indicates the sequential number of the NAS message.
KSISGSN is included if the UE indicates a GUTI mapped from a P-TMSI in the information element "old GUTI".
Step 3. The eNodeB derives the MME from the RRC parameters carrying the old GUMMEI and the indicated Selected Network. If that GUMMEI is not associated with the eNodeB, or the GUMMEI is not available or the UE indicates that the TAU procedure was triggered by load re-balancing, the eNodeB selects the MME. The eNodeB forwards the TAU Request message together with the CSG access mode, CSG ID, TAI+ECGI of the cell from where it received the message and with the Selected Network to the MME. CSG ID is provided by RAN if the UE sends the TAU Request message via a CSG cell or a hybrid cell. CSG access mode is provided if the UE sends the TAU Request message via a hybrid cell. If the CSG access mode is not provided but the CSG ID is provided, the MME shall consider the cell as a CSG cell.
Step 4. The new MME uses the GUTI received from the UE to derive the old MME/S4 SGSN address and sends a Context Request message to the old MME/S4 SGSN to retrieve the user information. UE Validated indicates that the new MME has validated the integrity protection of the TAU message, e.g. based on native EPS security context for the UE. To validate the Context Request the old MME uses the complete TAU Request message and the old S4 SGSN uses the P-TMSI Signature and responds with an appropriate error if integrity check fails in old MME/S4 SGSN. This shall initiate the security functions in the new MME. If the security functions authenticate the UE correctly, the new MME shall send a Context Request message to the old MME/S4 SGSN with the UE Validated set. If the new MME indicates that it has authenticated the UE or if the old MME/old S4 SGSN authenticates the UE, the old MME/old S4 SGSN starts a timer.
If the UE with emergency bearers is not authenticated in the old MME/old S4 SGSN (in a network supporting unauthenticated UEs) the old MME/old S4 SGSN continues the procedure with sending a Context Response and starting the timer also when it cannot validate the Context Request.
Step 5. If the Context Request is sent to an old MME the old MME responds with a Context Response message.
If the Context Request is sent to an old S4 SGSN the old S4 SGSN responds with a Context Response message. The Authentication Quintets are maintained by the old S4 SGSN.
The PDN GW Address and TEID(s) (for GTP-based S5/S8) or GRE Keys (PMIP-based S5/S8 at the PDN GW(s) for uplink traffic and the TI(s), is part of the EPS Bearer Context. ISR Supported is indicated if the old SGSN and associated Serving GW are capable to activate ISR for the UE.
The new MME shall ignore the UE Core Network Capability contained in the Context Response only when it has previously received an UE Core Network Capability in the Tracking Area Update Request. If the UE is not known in the old MME/old S4 SGSN or if the integrity check for the TAU request message fails, the old MME/old S4 SGSN responds with an appropriate error cause.
If the UE receives emergency services from the old MME/old S4 SGSN and the UE is UICCless, IMSI can not be included in the Context Response. For emergency attached UEs, if the IMSI cannot be authenticated, then the IMSI shall be marked as unauthenticated. Also, in this case, security parameters are included only if available.
Step 6. If the integrity check of TAU Request message (sent in step 2) failed, then authentication is mandatory. If GUTI allocation is going to be done and the network supports ciphering, the NAS messages shall be ciphered.
If this TAU request is received for a UE which is already in ECM_CONNECTED state and the PLMN-ID of the TAI sent by the eNodeB in Step 3 is different from that of the GUTI included in the TAU Request message, the MME shall delay authenticating the UE until after Step 21 (TAU Complete message).
NOTE: The MME delays the authentication such that the UE first updates its registered PLMN-ID to the new PLMN-ID selected by the RAN during handover. The new PLMN-ID is provided by the MME to the UE as part of the GUTI in the TAU accept message in Step 20. Doing this ensures that the same PLMN-ID is used in the derivation of the Kasme key by both the network and the UE.
If the new MME is configured to allow emergency services for unauthenticated UE the new MME behave as follows:
- where a UE has only emergency bearer services, the MME either skip the authentication and security procedure or accepts that the authentication may fail and continues the Tracking Area Update procedure; or
- where a UE has both emergency and non emergency bearer services and authentication fails, the MME continues the Tracking Area Update procedure and deactivates all the non-emergency PDN connections.
If the old node is an old S4 SGSN the MME sends a Context Acknowledge message to the old SGSN. Unless ISR Activated is indicated by the MME, the old S4 SGSN marks in its context that the information in the GWs is invalid. This ensures that the old S4 SGSN updates the GWs if the UE initiates a RAU procedure back to the old S4 SGSN before completing the ongoing TAU procedure. If ISR Activated is indicated to the old S4 SGSN, this indicates that the old S4 SGSN shall maintain its UE context including authentication quintets and stop the timer started in step 4. In this case, if the Implicit Detach timer is running, the old S4 SGSN shall re-start it with a slightly larger value than the UE's GERAN/UTRAN Deactivate ISR timer. Also, in this case, if the old SGSN has maintained the Serving GW address for user plane and S4 GTP-U TEID, the old SGSN shall remove Serving GW address for user plane and S4 GTP-U TEID locally. When ISR Activated is not indicated and this timer expires the old SGSN deletes all bearer resources of that UE. As the Context Acknowledge from the MME does not include any S GW change the S4 SGSN does not send any Delete Session Request message to the S GW. The MME shall not activate ISR if the associated Serving GW does not support ISR.
If the security functions do not authenticate the UE correctly, then the TAU shall be rejected, and the MME shall send a reject indication to the old MME/old S4 SGSN. The old MME/old S4 SGSN shall continue as if the Identification and Context Request was never received.
Step 8. Void.
Step 9. If the MME has changed the new MME adopts the bearer contexts received from the old MME/SGSN as the UE's EPS bearer contexts to be maintained by the new MME. The MME establishes the EPS bearer(s) in the indicated order. The MME deactivates the EPS bearers which cannot be established.
The MME verifies the EPS bearer status received from the UE with the EPS bearer contexts it maintains and releases any network resources related to EPS bearers that are not active in the UE. If there is no bearer context at all, the MME rejects the TAU Request. If the MME has changed the new MME sends a Modify Bearer Request message per PDN connection to the Serving GW. The PDN GW address is indicated in the bearer contexts. If indicated, the information ISR Activated indicates that ISR is activated. If the PDN GW requested UE's location and/or User CSG information, the MME also includes the User Location Information IE and/or User CSG Information IE in this message. If the UE Time Zone has changed, the MME includes the UE Time Zone IE in this message. If the old node is an old MME at a Tracking Area Update with a MME change ISR Activated shall not be indicated.
NOTE: The User CSG Information IE is only sent in step 9 if the "Active flag" is set in the TAU Request message.
When the Modify Bearer Request does not indicate ISR Activated the S GW deletes any ISR resources by sending a Delete Bearer Request to the other CN node that has bearer resources on the S GW reserved.
Step 10. If the RAT type has changed, or the Serving GW has received the User Location Information IE or the UE Time Zone IE or User CSG Information IE from the MME in step 9, the Serving GW informs the PDN GW(s) about this information that e.g. can be used for charging, by sending the message Modify Bearer Request per PDN connection to the PDN GW(s) concerned. User Location Information IE and/or UE Time Zone IE and/or User CSG Information IE are also included if they are present in step 9.
Step 11. If dynamic PCC is deployed, and RAT type information or UE location information needs to be conveyed from the PDN GW to the PCRF, then the PDN GW shall send this information to the PCRF by means of an IP CAN Session Modification procedure.
NOTE: The PDN GW does not need to wait for the PCRF response, but continues in the next step. If the PCRF response leads to an EPS bearer modification the PDN GW should initiate a bearer update procedure.
Step 12. The PDN GW updates its context field to allow DL PDUs to be routed to the correct Serving GW. PDN GW returns a Modify Bearer Response to the Serving GW. The MSISDN is included if the PDN GW has it stored in its UE context.
Step 13. The Serving GW updates its bearer context. If ISR Activated is indicated in step 9 and RAT Type received in step 9 indicates E UTRAN, then the Serving GW only updates the MME Control Plane Address stored locally and keep the SGSN related information unchanged. Also, in this case, if the Serving GW has maintained the SGSN address for user plane and S4 GTP-U TEID, the Serving GW removes the SGSN address for user plane and S4 GTP-U TEID locally. Otherwise the Serving GW shall update all of the information stored locally for this UE with the related information received from the MME. This allows the Serving GW to route Bearer PDUs to the PDN GW when received from eNodeB. The Serving GW returns a Modify Bearer Response message to the new MME.
Step 14. The new MME verifies whether it holds subscription data for the UE identified by the GUTI, the additional GUTI or by the IMSI received with the context data from the old CN node. If there are no subscription data in the new MME for this UE, or for some network sharing scenario (e.g. GWCN) if the PLMN-ID of the TAI supplied by the eNodeB is different from that of the GUTI in the UE's context, then the new MME informs the HSS of the change of MME by sending an Update Location Request message to the HSS. ULR-Flags indicates that update location is sent from an MME and the MME registration shall be updated in HSS. The HSS does not cancel any SGSN registration. The MME capabilities indicate the MME's support for regional access restrictions functionality. Homogenous Support of IMS Over PS Sessions indicates whether or not "IMS Voice over PS Sessions" is supported homogeneously in all TAs in the serving MME.
If all the EPS bearers of the UE have emergency ARP value, the new MME may skip the update location procedure or proceed even if the update location fails.
Step 15. The HSS sends a Cancel Location message to the old MME with a Cancellation Type set to Update Procedure.
Step 16. When receiving a Cancel Location message and the timer started in step 4 is not running, the old MME removes the MM and bearer contexts. Otherwise, the contexts are removed when the timer expires. It also ensures that the MM context is kept in the old MME for the case the UE initiates another TAU procedure before completing the ongoing TAU procedure to the new MME. The old MME acknowledges with a Cancel Location Ack message.
NOTE: ISR Activated is never indicated from new to old MME.
So an old MME deletes all the bearer resources of the UE in any case when the timer started in step 4 expires, which is independent on receiving a Cancel Location message.
Step 17. When receiving the Context Acknowledge message and if the UE is Iu Connected, the old SGSN sends an Iu Release Command message to the RNC after the timer started in step 4 has expired.
Step 18. The RNC responds with an Iu Release Complete message.
Step 19. The HSS acknowledges the Update Location Request by returning an Update Location Ack message to the new MME after the cancelling of the old MME context is finished. If the Update Location is rejected by the HSS, the MME rejects the TAU Request from the UE with an appropriate cause sent in the TAU Reject message to the UE. If all checks are successful, the MME constructs an MM context for the UE. The Subscription Data may contain the CSG subscription data for the PLMN.
If the UE initiates the TAU procedure at a CSG cell, the new MME shall check whether the CSG ID is contained in the CSG subscription and is not expired. If the CSG ID is not present or expired, the MME shall send a Tracking Area Update reject message to the UE with an appropriate cause value. The UE shall remove the CSG ID from its Allowed CSG list if present.
Step 20. If due to regional subscription restrictions or access restrictions (e.g. CSG restrictions) the UE is not allowed to access the TA:
- The MME rejects the Tracking Area Update Request with an appropriate cause to the UE.
- For UEs with emergency EPS bearers, i.e. at least one EPS bearer has an ARP value reserved for emergency services, the new MME accepts the Tracking Area Update Request and deactivates all non-emergency PDN connections. If the Tracking Area Update procedure is initiated in ECM-IDLE state, all non-emergency EPS bearers are deactivated by the Tracking Area Update procedure without bearer deactivation signalling between the UE and the MME.
When receiving the TAU Accept message and there is no ISR Activated indication the UE shall set its TIN to "GUTI". When ISR Activated is indicated and the UE's TIN indicates "GUTI" the UE's TIN shall not be changed. When ISR Activated is indicated and the TIN is "P TMSI" or "RAT related TMSI" the UE shall set its TIN to "RAT related TMSI".
For an MME change ISR is not activated by the new MME to avoid context transfer procedures with two old CN nodes.
For an emergency attached UE, emergency ISR is not activated.
If the TAU procedure is initiated by manual CSG selection and occurs via a CSG cell, the UE upon receiving TAU Accept message shall add the CSG ID to its Allowed CSG list if it is not already present. Manual CSG selection is not supported if the UE has emergency bearers established.
If the user plane setup is performed in conjunction with the TAU Accept message and the TAU is performed via a hybrid cell, then the MME shall send an indication whether the UE is a CSG member to the RAN along with the S1-MME control message. Based on this information the RAN may perform differentiated treatment for CSG and non-CSG members.
NOTE: If the UE receives a TAU Accept message via a hybrid cell, the UE does not add the corresponding CSG ID to its Allowed CSG list. Adding a CSG ID to the UE's local Allowed CSG list for a hybrid cell is performed only by OTA or OMA DM procedures.
Step 21. If the GUTI was changed the UE acknowledges the new GUTI by returning a Tracking Area Update Complete message to the MME.
When the "Active flag" is not set in the TAU Request message and the Tracking Area Update was not initiated in ECM-CONNECTED state, the MME releases the signalling connection with UE.
NOTE: The new MME may initiate E RAB establishment after execution of the security functions, or wait until completion of the TA update procedure. For the UE, E RAB establishment may occur anytime after the TA update request is sent.
In the case of a rejected tracking area update operation, due to regional subscription, roaming restrictions, or access restrictions the new MME shall not construct an MM context for the UE. A reject shall be returned to the UE with an appropriate cause and the S1 connection shall be released.
If the new MME is unable to update the bearer context in one or more P GWs, the new MME shall deactivate the corresponding bearer contexts as described in clause "MME Initiated Dedicated Bearer Deactivation Procedure". This shall not cause the MME to reject the tracking area update.
The new MME shall determine the Maximum APN restriction based on the received APN Restriction of each bearer context in the Context Response message and then store the new Maximum APN restriction value.
The bearer contexts shall be prioritized by the new MME. If the new MME is unable to support the same number of active bearer contexts as received from old MME/SGSN, the prioritisation is used to decide which bearer contexts to maintain active and which ones to delete. In any case, the new MME shall first update all contexts in one or more P GWs and then deactivate the context(s) that it cannot maintain as described in clause "MME Initiated Dedicated Bearer Deactivation Procedure". This shall not cause the MME to reject the tracking area update.
The new MME shall not deactivate emergency service related EPS bearers, i.e. EPS bearers with ARP values reserved for emergency services.
NOTE: If MS (UE) was in PMM-CONNECTED state the bearer contexts are sent already in the Forward Relocation Request message as described in clause "Serving RNS relocation procedures" of TS 23.060 [7].
If the tracking area update procedure fails a maximum allowable number of times, or if the MME returns a Tracking Area Update Reject (Cause) message, the UE shall enter EMM DEREGISTERED state.
If the Update Location Ack message indicates a reject, this should be indicated to the UE, and the UE shall not access non-PS services until a successful location update is performed.
Source(s):
3GPP TS 23.401
Yes, I did and gave reference to it directly.
ReplyDeleteThanks, but I would like to avoid random links in comments.
When added from personal account they look less like a "free advertise" for mentioned website.
Regards!
Hi Mr,
ReplyDeleteI hope you can help me.
We are making some tests in South America on LTE network and the UE doesn´t recover LTE service,we recived the message PDN Connectivity Reject Cause #55.
Do you have an idea on the root cause?.
Thanks
Federico
Hi Fredico,
DeleteCause #55, mean mutliple PDNs for given APN not allowed. It looks like that there is already one connection for given APN and u are trying to create another PDN for the same.
Cheers,
VJ
Some applications will even send you an SMS notification in regards to any call that was under one minute and find out what happened and callgear why that particular call was that short.
ReplyDeleteIn the event that rather, you were to fit a GSM tracker with a standard portable SIM that is fixed to one versatile system, at that point it will be not able transmit on the off chance that you go to a territory where that one system has no inclusion. tracking gadget
ReplyDeleteCall tracking numbers are phone numbers used in local internet marketing services that forward calls through to the main line of your business. Track China Post to Canada packages tracking number
ReplyDeleteI like your post. It is good to see you verbalize from the heart and clarity on this important subject can be easily observed... phonetracker app
ReplyDeleteThank you because you have been willing to share information with us. we will always appreciate all you have done here because I know you are very concerned with our. find a phone
ReplyDeleteNonetheless, the corporation must be included earlier than the registration of the deliver.Shipping from China to Us
ReplyDeleteI really love your write-ups guys continue the good work.
ReplyDeleteArt Supplies For Painting
Thanks for a greaat read
ReplyDelete