Content for  TS 23.401  Word version:  19.0.0

One of the triggers described in clause 5.3.3.0 for starting the TAU procedure occurs.

The UE sends to the eNodeB a Tracking Area Update Request (last visited TAI, P-TMSI Signature, old GUTI, UE Core Network Capability, Preferred Network behaviour, active flag, EPS bearer status, additional GUTI, eKSI, NAS sequence number, NAS-MAC, KSI) message together with RRC parameters indicating the Selected Network and the old GUMMEI. In the RRC connection establishment signalling associated with the TAU Request, the UE indicates its support of the CIoT EPS Optimisations relevant for MME selection. If the UE's TIN indicates "GUTI" or "RAT-related TMSI" and the UE holds a valid GUTI then the old GUTI indicates this valid GUTI. If the UE's TIN indicates "P-TMSI" and the UE holds a valid P-TMSI and related RAI then these two elements are indicated as the old GUTI. Mapping a P-TMSI and an RAI to a GUTI is specified in Annex H. If the UE holds a valid GUTI and the old GUTI indicates a GUTI mapped from a P-TMSI and RAI, then the UE indicates the native GUTI. If the old GUTI indicates a GUTI mapped from a P-TMSI and RAI, and the UE has a valid P-TMSI signature, the P-TMSI signature shall be included. 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 by 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 is included if the UE has any in order to help the MME to 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 UE to activate the radio and S1 bearers for all the active EPS Bearers by the TAU procedure. The EPS bearer status indicates each EPS bearer that is active within the UE. The UE's ISR capability is included in the UE Core Network Capability element. If the UE has valid EPS security parameters, the TAU Request message shall be integrity protected by the NAS-MAC in order to allow validation of the UE by the MME. eKSI, NAS sequence number and NAS-MAC are included if the UE has valid EPS security parameters. NAS sequence number indicates the sequential number of the NAS message. KSI is included if the UE indicates a GUTI mapped from a P-TMSI in the information element "old GUTI". If a UE includes a Preferred Network Behaviour, this defines the Network Behaviour the UE is expecting to be available in the network as defined in clause 4.3.5.10.

The eNodeB derives the MME address from the RRC parameters carrying the old GUMMEI, the indicated Selected Network and the RAT (NB-IoT or WB-E-UTRAN). If that GUMMEI is not associated with the eNodeB, or the GUMMEI is not available, the eNodeB selects the MME as described in clause 4.3.8.3 on "MME Selection Function". The eNodeB forwards the TAU Request message together with the TAI+ECGI and RAT type of the cell from where it received the message and with the Selected Network to the MME. The RAT type shall distinguish between NB-IoT and WB-E-UTRAN types. To assist Location Services, the eNodeB indicates the UE's Coverage Level to the MME.

The new MME sends SGSN Context Request (old RAI, P-TMSI, old P-TMSI Signature, New SGSN Address) to the old SGSN to get the MM and PDP contexts for the UE. The new MME shall support functionality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, i.e. the MME derives the old SGSN from the old RAI and the old P-TMSI (or TLLI). When the internal structure of the pool area where the MS roamed from is not known, the new MME derives the old SGSN from the old RAI as described at clause 5.8 in TS 23.060. For this case, the new MME derives an SGSN that it believes is the old SGSN. This derived SGSN is itself the old SGSN, or it is associated with the same pool area as the actual old SGSN and it will determine the correct old SGSN from the P-TMSI (or TLLI) and relay the message to that actual old SGSN.

If the old SGSN is a 2G-SGSN: The old 2G-SGSN validates the old P-TMSI Signature and responds with an appropriate error cause if it does not match the value stored in the old 2G SGSN. This should initiate the security functions in the new SGSN. If the security functions authenticate the MS correctly, the new SGSN shall send an SGSN Context Request (old RAI, old PTMSI, MS Validated, New SGSN Address) message to the old SGSN. MS Validated indicates that the new SGSN has authenticated the MS. If the old P-TMSI Signature was valid or if the new SGSN indicates that it has authenticated the MS, the old SGSN stops assigning SNDCP N-PDU numbers to downlink N-PDUs received, and responds with SGSN Context Response (MM Context, PDP Contexts). If the MS is not known in the old SGSN, the old SGSN responds with an appropriate error cause. The old SGSN stores New SGSN Address, to allow the old SGSN to forward data packets to the new SGSN. Each PDP Context includes the SNDCP Send N-PDU Number for the next downlink N-PDU to be sent in acknowledged mode to the MS, the SNDCP Receive N-PDU Number for the next uplink N-PDU to be received in acknowledged mode from the MS, the GTP sequence number for the next downlink N-PDU to be sent to the MS and the GTP sequence number for the next uplink N-PDU to be tunnelled to the GGSN. The old SGSN starts a timer and stops the transmission of N-PDUs to the MS. The new SGSN shall ignore the MS Network Capability contained in MM Context of SGSN Context Response only when it has previously received an MS Network Capability in the Routing Area Request. If the old SGSN is a 3G-SGSN: The old 3G-SGSN validates the old P-TMSI Signature and responds with an appropriate error cause if it does not match the value stored in the old SGSN. This should initiate the security functions in the new SGSN. If the security functions authenticate the MS correctly, the new SGSN shall send an SGSN Context Request (IMSI, old RAI, MS Validated) message to the old 3G-SGSN. MS Validated indicates that the new SGSN has authenticated the MS. If the old P-TMSI Signature was valid or if the new SGSN indicates that it has authenticated the MS, the old SGSN starts a timer. If the MS is not known in the old SGSN, the old 3G-SGSN responds with an appropriate error cause. If the UE with emergency bearers is not authenticated in the old MME (in a network supporting unauthenticated UEs) the old MME continues the procedure with sending a Context Response and starting the timer also when it cannot validate the Context Request. The old 3G SGSN responds with an SGSN Context Response (MM Context, PDP Contexts) message. For each PDP context the old 3G SGSN shall include the GTP sequence number for the next uplink GTP PDU to be tunnelled to the GGSN and the next downlink GTP sequence number for the next PDU to be sent to the MS. Each PDP Context also includes the PDCP sequence numbers if PDCP sequence numbers are received from the old SRNS. The new 3G-SGSN shall ignore the MS Network Capability contained in MM Context of SGSN Context Response only when it has previously received an MS Network Capability in the Routing Area Request. The GTP sequence numbers received from the old 3G-SGSN are only relevant if delivery order is required for the PDP context (QoS profile). If the UE uses power saving functions and the DL Data Buffer Expiration Time for the UE has not expired, the old Gn/Gp-SGSN indicates Buffered DL Data Waiting. When this is indicated, the new MME invokes data forwarding and user plane setup corresponding to clause 5.3.3.1A.

Security functions may be executed. Procedures are defined in clause 5.3.10 on Security Function. If the SGSN Context Response message from the old SGSN did not include IMEISV, the MME shall retrieve the ME Identity (the IMEISV) from the UE.

If the new MME identifies that the RAT type has changed, the MME checks the subscription information to identify for each APN whether to maintain the PDN connection, disconnect the PDN connection with a reactivation request, or, disconnect the PDN connection without reactivation request. If the MME decides to deactivate a PDN connection it performs MME-initiated PDN Connection Deactivation procedure after the tracking area update procedure is completed but before the S1/RRC interface connection is released. Existing ESM cause values as specified in TS 24.301 (e.g. #39, "reactivation requested"; #66 "Requested APN not supported in current RAT and PLMN combination"; and for a dedicated bearer, possibly #37 "EPS QoS not accepted") are used to cause predictable UE behaviour. If all the PDN connections are disconnected and the UE does not support "attach without PDN connectivity", the MME shall request the UE to detach and reattach. The new MME sends an SGSN Context Acknowledge message to the old SGSN. This informs the old SGSN that the new SGSN is ready to receive data packets belonging to the activated PDP contexts. The old SGSN marks in its context that the MSC/VLR association and the information in the GGSNs and the HLR are invalid. This triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the MS initiates a Routing area update procedure back to the old SGSN before completing the ongoing routing area update procedure. If the security functions do not authenticate the UE correctly, then the Tracking area update shall be rejected, and the new MME shall send a reject indication to the old SGSN. The old SGSN shall continue as if the SGSN Context Request was never received. If there is no PDP context at all and the CIoT EPS Optimisation without PDN connection is not applied, the MME rejects the TAU Request. For UE using CIoT EPS Optimisation without any activated PDN connection, the steps 9, 10, 11, 12 and 13 are skipped.

The old SGSN or the old RNC forward data to the S-GW and the S-GW discards these data.

The new MME adopts the bearer contexts received from the SGSN as the UE's EPS bearer contexts to be maintained by the new MME. The new MME maps the PDP contexts to the EPS bearers 1-to-1 and maps the Release 99 QoS parameter values of a PDP context to the EPS Bearer QoS parameter values of an EPS bearer as defined in Annex E. 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 bearer contexts received from the old SGSN and releases any network resources related to EPS bearers that are not active in the UE. If the UE has no PDP context, the MME rejects the TAU Request. The new MME selects a Serving-GW and sends an Create Session Request (IMSI, MME Address and TEID, PDN-GW address and TEID, EPS Bearer QoS, serving network identity, ME Identity, User Location Information IE, UE Time Zone IE, User CSG Information IE, RAT type, MS Info Change Reporting support indication, NRS (received from the SGSN)) message per PDN connection to the Serving-GW. The MME shall send the serving network identity to the Serving-GW. The new MME does not indicate ISR Activated.

The Serving-GW creates contexts and informs the PDN-GW(s) about the change of the RAT type. The Serving-GW sends a Modify Bearer Request (Serving-GW Address and TEID, RAT type, ME Identity, User Location Information IE, UE Time Zone IE, User CSG Information IE, MS Info Change Reporting support indication, PDN Charging Pause Support indication) message per PDN connection to the PDN-GW(s) concerned.

If dynamic PCC is deployed, and RAT type information needs to be conveyed from the PDN-GW to the PCRF, then the PDN-GW shall send RAT type information to the PCRF by performing an IP-CAN Session Modification procedure as defined in TS 23.203.

The PDN-GW updates its context field and returns a Modify Bearer Response (PDN-GW address and TEID, MSISDN, Default bearer id, Charging Id, MS Info Change Reporting Action (Start) (if the PDN-GW decides to receive UE's location information during the session), CSG Information Reporting Action (Start) (if the PDN-GW decides to receive UE's User CSG information during the session), PDN Charging Pause Enabled indication (if PDN-GW has chosen to enable the function), APN Restriction) message to the Serving-GW. The MSISDN is included if the PDN-GW has it stored in its UE context. When the UE moves from Gn/Gp SGSN to the MME, the PDN-GW shall send the APN restriction of each bearer context to the Serving-GW.

The Serving-GW updates its context and returns an Create Session Response (Serving-GW address and TEID for user plane, PDN-GW address and TEID, Serving-GW Address and TEID for the control plane, Default bearer id, APN restriction) message to the new MME. The message also includes MS Info Change Reporting Action (Start) and/or CSG Information Reporting Action (Start) if they are included in step 12. The Serving-GW shall forward the received APN Restriction to the MME. When the MME receives the Create Session Response message, the MME checks if there is a "Availability after DDN Failure" monitoring event or a "UE Reachability" monitoring event configured for the UE in the MME and in such a case sends an event notification (see TS 23.682 for further information).

To ensure the release of all UE resources in the Gn/Gp SGSN the new MME informs the HSS of the change of the serving core network node by sending an Update Location Request (MME Address, IMSI, ME Identity, ULR-Flags, MME Capabilities, Homogenous Support of IMS Voice over PS Sessions) message to the HSS. The ME Identity is included if the SGSN Context Response did not contain the IMEISV. Because of interoperation with an Gn/Gp SGSN, which the new MME identifies from the GTPv1 Context Response signalling, the ULR-Flags indicates "Single-Registration-Indication". The MME capabilities indicate the MME's support for regional access restrictions functionality. For "Homogenous Support of IMS Voice over PS Sessions", see clause 4.3.5.8A.

If the MME changes, then the HSS cancels any old MME. The HSS sends a Cancel Location (IMSI, Cancellation type) message to the old MME, with a Cancellation Type set to Update Procedure.

The old MME removes the MM context. The old MME releases any local bearer resources and it deletes the EPS bearer resources by sending Delete Session Request (Cause, Operation Indication) messages to the Serving-GW. The operation Indication flag is not set, that indicates that the S-GW shall not initiate a delete procedure towards the PDN-GW. If ISR is activated then the cause indicates to the old S-GW that the old S-GW shall delete the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that CN node. The old MME acknowledges with a Cancel Location Ack (IMSI) message.

The HSS cancels any old SGSN node as the ULR-Flags indicates "Single-Registration-Indication". The HSS sends a Cancel Location (IMSI, Cancellation Type) message to the old SGSN. The old SGSN removes the contexts. If the timer started in step 5 is not running, the old SGSN 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 SGSN for the case the UE initiates another TAU procedure before completing the ongoing TAU procedure to the new MME.

On receipt of Cancel Location, if the MS is PMM-CONNECTED in the old SGSN, the old SGSN sends an Iu Release Command message to the old SRNC.

When the data-forwarding timer has expired, the SRNS responds with an Iu Release Complete message.

The old SGSN acknowledges with a Cancel Location Ack (IMSI) message.

The new MME validates the UE's presence in the (new) TA. If all checks are successful, the MME constructs an MM context for the UE, the HLR acknowledges the Update Location by sending Update Location Ack (IMSI, Subscription Data) message to the new MME. 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 due to regional subscription restrictions or access restrictions the UE is not allowed to access the TA:

• For UEs with ongoing emergency bearer services, the new MME accepts the Tracking Area Update Request and releases the non-emergency bearers as specified in clause 5.10.3.
• For all other cases, the new MME rejects Tracking Area Update Request with an appropriate cause to the UE and notifies the HSS of rejection (details of this notification is stage 3 detail).

The new MME responds to the UE with a Tracking Area Update Accept (GUTI, TAI-list, EPS bearer status, NAS sequence number, NAS-MAC, ISR Activated, Supported Network Behaviour) message. Restriction list shall be sent to eNodeB as eNodeB handles the roaming restrictions and access restrictions in the Intra E-UTRAN case. If the "active flag" is set in the TAU Request message the user plane setup procedure can be activated in conjunction with the TAU Accept message. The procedure is described in detail in TS 36.300. The messages sequence should be the same as for the UE triggered Service Request procedure specified in clause 5.3.4.1 from the step when MME establishes the bearer(s). If the active flag is set the MME may provide the eNodeB with Handover Restriction List. Handover Restriction List is described in clause 4.3.5.7 "Mobility Restrictions". The EPS bearer status indicates the active bearers in the network. The UE removes any internal resources related to bearers not marked active in the received EPS bearer status. If the EPS bearer status information was in the TAU Request, the MME shall indicate the EPS bearer status to the UE. For UE using CIoT EPS Optimisation without any activated PDN connection, there is no EPS bearer status included in the TAU Accept message. The MME indicates the CIoT optimisations it supports and prefers in the Supported Network Behaviour information as defined in clause 4.3.5.10. When receiving the TAU Accept message and there is no ISR Activated indication the UE shall set its TIN to "GUTI". If the Subscription Data received from the HSS (during the TAU) contains information that is necessary for the E-UTRAN to be aware of (e.g. a restriction in the UE's permission to use NR as a secondary RAT, Unlicensed Spectrum in the form of LAA/LWA/LWIP/NR-U (as specified in clause 4.3.30) or a combination of them), or an existing UE context in the MME indicates that the UE is not permitted to use NR as a secondary RAT, Unlicensed Spectrum or a combination of them, then the MME sends an updated Handover Restriction List in the Downlink NAS Transport message that it sends to E-UTRAN. If the UE is not allowed to use NR as Secondary RAT, the MME indicates that to the UE in TAU Accept message.

If the GUTI was included in the TAU Accept message, the UE acknowledges the message 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, according to clause 5.3.5.

The target MME calculates UE-AMBR as defined in clause 4.7.3. If the local UE-AMBR provided by the MME as defined in Annex E is different from the corresponding derived UE-AMBR, or the APN-AMBR mapped from the subscribed MBR is different from the subscribed APN-AMBR, or the mapped subscribed QoS profile (i.e. the subscribed QoS profile mapped according to Annex E) of the default bearer is different from the EPS Subscribed QoS profile received from the HSS, the new MME shall initiate Subscribed QoS Modification procedure as described in clause 5.4.2.2, Figure 5.4.2.2-1.

CAMEL_GPRS_PDP_Context_Disconnection, CAMEL_GPRS_Detach and CAMEL_PS_Notification. They are called in the following order:

• The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context. The procedure returns as result "Continue".
• Then the CAMEL_GPRS_Detach procedure is called once. The procedure returns as result "Continue".
• Then the CAMEL_PS_Notification procedure is called once. The procedure returns as result "Continue".