Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.007  Word version:  18.5.0

Top   Top   Up   Prev   Next
1…   2…   4…   5…   6…   10…   11…   12…   14…   15…   15A…   16…   17…   17A…   17B…   17C…   18…   20…   20.3…   21…   22…   25…   27…   28…   31…   31.3…   31.4…   31.6…

 

25  Network triggered service restoration procedure |R10|p. 90

25.1  Generalp. 90

The network triggered service restoration procedure is an optional feature for the MME, S4-SGSN and SGW. A node that supports this feature shall support the network triggered service restoration procedure without ISR as specified in clause 25.2 and the network triggered service restoration procedure with ISR as specified in clause 25.3 if it supports Idle mode Signalling Reduction (ISR) (see TS 23.401 and TS 23.060).
The network triggered restoration procedure without ISR shall apply to UEs for which ISR is not active at the time the ISR associated node fails. The network triggered restoration procedure with ISR shall apply to UEs for which ISR is active at the time the ISR associated node fails. Both procedures may run in parallel if there is a mix of UEs with ISR and without ISR at the time the ISR associated node fails.
For the PMIP based S5/S8 case, the terminology "S5/S8 bearer" used through clause 25 shall be read as "S5/S8 IP traffic flow" within the GRE tunnel. The detailed concepts of the "IP traffic flow" are specified in TS 23.402.
Up

25.2  Network triggered service restoration procedure without ISRp. 90

25.2.1  Generalp. 90

The following requirements shall apply if the MME or S4-SGSN and the SGW support this feature.
If an SGW detects that an MME or S4-SGSN has restarted (see clause 18 "GTP-C based restart procedures"), instead of removing all the resources associated with the peer node, the SGW shall maintain the PDN connection table data and MM bearer contexts for some specific S5/S8 bearer contexts eligible for network initiated service restoration, and initiate the deletion of the resources associated with all the other S5/S8 bearers.
The S5/S8 bearers eligible for network initiated service restoration are determined based on operator's policy, e.g. based on the QCI and/or ARP and/or APN, and such operator's policy shall be applicable for both the SGW and the MME/SGSN. The Delay Tolerant Connection Indication (DTCI), if set, may also be used to determine that the S5/S8 bearer is not eligible for network initiated service restoration, based on operator's policy when using QCI and/or ARP and/or APN is not sufficient, e.g. for Home routed roaming scenario.
Emergency PDN connections for users without authenticated IMSI do not need to be maintained by the SGW and cannot be restored at the initiative of the network.
If at least one S5/S8 bearer needs to be maintained, the SGW shall also start a timer controlling the maximum duration during which those bearers shall be maintained. There is one operator configurable timer per SGW. The timer value may be equal to the periodic tracking area update timer (timer T3412) as specified in TS 24.301 or the periodic routing area update timer (timer T3312) as specified in TS 24.008. This timer ensures that the S5/S8 bearers eligible for network initiated service restoration are maintained until the corresponding UE reattaches to the network. If the timer expires, the maintained resources shall be locally deleted assuming that the corresponding UE might have reattached to the network via a different SGW.
The SGW shall not release the default bearer of a PDN connection for which one or more dedicated bearers are maintained. Any downlink user plane or control plane packet received on a default bearer which is not eligible for network initiated service restoration but which is maintained for dedicated bearer(s) eligible for such procedure shall be silently discarded by the SGW.
When releasing the maintained S5/S8 bearers, the SGW may optionally perform other implementation specific actions such as messages to clear other external resources (e.g. PCC messages to clear the resources in the PCRF or GTP/PMIP messages to release the corresponding PDN connection in the PGW).
If the SGW receives a Create Session Request message for a UE for which some S5/S8 bearers are maintained, the SGW shall delete all the bearers for this UE and proceed with the Create Session Request message handling as specified in TS 29.274.
Up

25.2.2  SGW procedurep. 91

Upon receipt of the first downlink user plane or control plane packet on a maintained S5/S8 bearer or PCC signalling from PCRF, the SGW shall immediately send a Downlink Data Notification message including the IMSI to the respective MME or S4-SGSN. In addition, depending on the received downlink packet type the SGW shall proceed as follows:
  • if the received downlink packet contains user plane data, the SGW shall silently discard it but the SGW shall continue maintaining the corresponding bearers. If the SGW receives another downlink user plane packet for an ARP value other than the ARP included in the Downlink Data Notification sent before, it shall proceed as specified in clause 5.3.4.3 of TS 23.401 ("Network Triggered Service Request") with the exception that the packet shall be discarded by the SGW.
  • For the S5/S8 GTP case:
    • if the received downlink packet contains a control plane message other than a Delete Bearer Request message then the SGW may reject the message and shall continue maintaining the corresponding bearers. If the SGW receives another control plane message for an ARP value other than the ARP included in the Downlink Data Notification sent before, it shall proceed as specified in clause 5.3.4.3 of TS 23.401 ("Network Triggered Service Request") with the exception that the message may be rejected by the SGW.
    • if the received downlink packet contains the Delete Bearer Request message, the SGW shall accept the message, and shall release the corresponding S5/S8 bearer(s) immediately.
  • For the S5/S8 PMIP case:
    • if the received packet contains a control plane message other than the message of the Gateway Control and QoS Rules Provision procedure as specified in clause 4.4.3 of TS 29.213 which results in the SGW to decide to deactivate an existing dedicated bearer, then the SGW may reject the message and shall continue maintaining the corresponding bearers. If the SGW receives another control plane message for an ARP value other than the ARP included in the Downlink Data Notification sent before, it shall proceed as specified in clause 5.3.4.3 of TS 23.401 ("Network Triggered Service Request") with the exception that the message may be rejected by the SGW.
    • if the received downlink packet contains the message of the Gateway Control and QoS Rules Provision procedure as specified in clause 4.4.3 of TS 29.213 which results in the SGW to decide to deactivate an existing dedicated bearer, the SGW shall accept the message, and shall release the corresponding S5/S8 bearer(s) immediately.
The SGW may send the Downlink Data Notification message including the IMSI to the respective MME or S4-SGSN, if there is some DL data buffered for a UE when detecting the MME or S4-SGSN restart.
The SGW may send the Downlink Data Notification message to another MME or S4-SGSN (the same type of mobility node as the failed one) located in the same pool as the failed node if the SGW cannot send it to the failed MME or S4-SGSN (e.g. because it did not restart). It is an implementation/deployment matter how an SGW becomes aware that an MME/S4-SGSN has failed and has not restarted.
Up

25.2.3  MME/SGSN procedurep. 92

Upon receipt of a Downlink Data Notification message including the IMSI, the MME or S4-SGSN shall respond to the SGW with a Downlink Data Notification Acknowledge message and should page and force the UE to re-attach to the network. The paging area and subscriber's identity i.e. IMSI or S-TMSI/P-TMSI used during the paging procedure is implementation dependent. The MME or S4-SGSN may support and apply this procedure to a UE using extended idle mode DRX, and if so, they shall page the UE with the S-TMSI/P-TMSI.
The MME or S4-SGSN may request the SGW to immediately release the maintained S5/S8 bearers by sending the "Downlink Data Notification Acknowledge" message or a "Downlink Data Notification Failure Indication" message with the specific cause "UE already re-attached", e.g. if the UE has already re-attached to the network. The Downlink Data Notification Acknowledge and Downlink Data Notification Failure Indication shall include the IMSI to identify the UE context in the SGW.
Up

25.3  Network triggered service restoration procedure with ISRp. 92

25.3.1  Generalp. 92

The following requirements shall apply if the involved MME, S4-SGSN and SGW support the ISR feature and the network triggered service restoration feature.
In the rest of this clause, the term "non-failed" node refers to the CN node (MME or S4-SGSN) that remains in normal operation during this procedure, as opposed to the "restarted" node which refers to the CN node (MME or S4-SGSN) that has failed and restarted.
The procedure in the SGW towards the restarted node differs from the procedure towards the non-failed ISR associated node (see clause 25.3.2).
Up

25.3.2  SGW procedurep. 93

If an SGW detects that an ISR associated CN node (i.e. MME or S4-SGSN) has restarted (see clause 18), the SGW shall maintain all the PDN connection table data and MM bearer contexts associated with the non-failed and the restarted ISR associated nodes, and start a timer controlling the maximum duration during which the SGW shall consider that ISR is still active. There is one operator configurable timer per SGW. The timer value may be set to a value that is the greater value of the periodic tracking area update timer (timer T3412) as specified in TS 24.301 and the periodic routing area update timer (timer T3312) as specified in TS 24.008. This timer ensures that the SGW can still send Downlink Data Notification messages to the restarted MME or S4-SGSN until the corresponding UE learns that ISR is deactivated. If the timer expires, the SGW shall deactivate ISR by locally releasing the resources for the maintained restarted CN node (i.e. restarted CN node control plane F-TEID).
Upon receipt of the downlink user plane or control plane packet on a maintained S5/S8 bearer for a UE in idle mode or in connected state with the failed CN node, the SGW shall initiate the network triggered service request procedure towards the non-failed CN node as specified in clause 5.3.4.3 of TS 23.401. In addition, if the S5/S8 bearer is eligible for network initiated service restoration, the SGW shall also immediately send a Downlink Data Notification message including the IMSI towards the restarted CN node as specified in clause 25.2.2. The SGW shall continue to forward downlink user plane or control plane packet for a UE in connected state in the non-failed ISR associated node.
The S5/S8 bearers eligible for network initiated service restoration are determined by the SGW based on operator's policy e.g. based on the QCI and/or ARP and/or APN.
Emergency PDN connections for users without authenticated IMSI do not need to be maintained by the SGW and cannot be restored at the initiative of the network.
The SGW may send the Downlink Data Notification message with the IMSI to another MME or S4-SGSN (the same type of mobility node as the failed one) in the same MME or S4-SGSN pool if the SGW cannot send it to the failed MME or S4-SGSN (e.g. because it did not restart). It is an implementation/deployment matter how an SGW becomes aware that an MME/S4-SGSN has failed and has not restarted.
Upon receipt of a Downlink Data Notification message including the IMSI, the restarted CN node shall respond to the SGW with a Downlink Data Notification Acknowledge message and should page the UE and force it to re-attach to the network as specified in clause 25.2.
If the paging is successful (i.e. Modify Bearer Request is received) for the non-failed ISR associated CN node, the SGW may send a Stop Paging Indication message including the IMSI to the restarted CN node (or the alternative node in the same pool to which the Downlink Data Notification message with the IMSI has been sent before) to stop the paging procedure.
If the SGW receives a Create Session Request message as part of Initial Attach procedure for a UE for which the PDN connections, MM bearer context and ISR state have been maintained, the SGW shall stop the timer, deactivate ISR, and delete the maintained resources associated to the restarted CN node (i.e. CN node control plane F-TEID). The SGW may additionally send a Stop Paging Indication message to the non-failed ISR associated CN node to stop the paging procedure.
If the non-failed ISR associated CN node received a Cancel Location message from HSS/HLR with "Initial Attach procedure" Cancellation Type, the non-failed CN node shall delete all the bearer contexts and send Delete Session Request message(s) to SGW. The SGW shall then release all the resources for this UE and sends one of the following messages to PGWs involved to release all the resources maintained in the PGWs as specified in TS 23.401 and TS 23.402.
  • For the GTP based S5/S8 case, Delete Session Request message(s)
  • For the PMIP based S5/S8 case, PBU message(s) with Lifetime set to "0"
The SGW shall stop the timer and delete the resources for the maintained restarted CN node (i.e. restarted CN node control plane F-TEID) if it receives one of the following messages while the timer is running:
  • a Modify Bearer Request message indicating that ISR is not active, e.g. from the non-failed CN node during a TAU/RAU procedure; or
  • a Modify Bearer Request message indicating that ISR is active from another mobility management node with the same type as the restarted node.
Up

25.3.3  MME/S4-SGSN procedurep. 94

If an MME/S4-SGSN detects a restart of an ISR associated counterpart (see clause 18), the MME/S4-SGSN shall wait for the next RAU/TAU procedure to deactivate ISR.
The non-failed CN node may initiate the GUTI Relocation or P-TMSI Relocation Procedure with a non-broadcast TAI or RAI to force the UE to perform the TAU/RAU procedure for ISR deactivation, e.g. if a signalling connection is established with the UE following receipt of a Downlink Data Notification message.
If afterwards the non-failed MME/S4-SGSN receives TAU/RAU Request, then the MME/S4-SGSN shall inform the UE in the TAU/RAU Accept message to disable ISR as specified in TS 23.401 and TS 23.060. The non-failed CN node shall send a Modify Bearer Request message to the SGW, even if the MME/S4-SGSN did not change during the TAU/RAU, to request the SGW to disable ISR and to update the SGW with the latest RAT Type and Serving Network values. Upon receipt of that message, the SGW shall disable ISR and shall stop sending Downlink Data Notification message with IMSI to the restarted CN node.
Up

26  Mobile terminated CS service delivery via an alternative MME in MME pool |R11|p. 94

This procedure is an optional feature for VLR and MME. It enables the network to continue delivering mobile terminated CS services to UEs via an alternative MME in the MME pool where the UE is located when the MME to which the UE was registered fails without restart or fails for a long duration.
The following requirements shall apply if the VLR and MME support this feature.
When the VLR has to page the UE for a mobile terminated CS service (e.g. upon receipt of an incoming CS call), if the VLR detects that the MME serving the UE is no longer in service, the VLR should send an SGs paging request with a CS restoration indicator to one alternative MME in the same MME pool. The VLR should load-balance the paging requests among the available MMEs in the pool during the restoration procedure.
The VLR may know the set of MMEs pertaining to the same MME pool by local configuration or by checking the MME Group ID within the MME name that MMEs signal to the VLR in the SGsAP-LOCATION-UDATE-REQUEST, SGsAP-RESET-INDICATION or SGsAP-RESET-ACK messages. The MME should send an SGsAP-RESET-INDICATION message to the VLR after restart.
The VLR may detect that an MME is no longer in service if there are no more SCTP associations in service with that MME.
The VLR should adjust its paging retransmission delay to avoid requesting again the UE to re-attach before the restoration procedure completes.
The MME shall behave as specified in clause 14.1.3 upon receipt of an SGs paging request not including the CS restoration indicator.
The MME shall accept the SGs paging request and proceed as follows upon receipt of an SGs paging request including the CS restoration indicator:
  • if the IMSI is unknown by the MME, or if the IMSI is known and the UE is marked as EMM-DEREGISTERED, the MME shall send the paging request with the location information provided by the VLR, regardless of the value of the "MME-Reset" indicator. If no such location information is provided, the MME may either page the UE in all the tracking areas corresponding to that MME or in the tracking areas served by the MME and by the VLR, or reject the paging request per operator policy. The paging request shall include the IMSI and the CN domain indicator set to "PS" to request the UE to re-attach;
  • if the IMSI is known by the MME and the UE is considered to be attached to both EPS and non-EPS services or for SMS only (for an SGs paging request with an 'SMS indicator'), the MME shall page the UE based on the location information stored in the MME.
The MME may support and apply this procedure to a UE using extended idle mode DRX for MT-SMS service, and if so, the MME shall page the UE with the S-TMSI.
Upon receipt of a paging request including the IMSI and the CN domain indicator set to "PS", or upon receipt of a Service Reject with Cause #10 - Implicitly detached (when using S-TMSI paging), the UE re-attaches to one MME of the pool (that may not be necessarily the MME that initiated the paging procedure towards the UE) and a new SGs association is established with the VLR. This may be a different VLR than the VLR that initiated the SGs paging procedure, e.g. if Intra Domain Connection of RAN Nodes to Multiple CN Nodes is deployed for GERAN or UTRAN (see TS 23.236).
If the new SGs association is established towards the same VLR, the VLR should repeat the SGs paging request after the UE has re-attached to non-EPS services. The MT CS service or SMS is then delivered according to normal procedures.
If the new SGs association is established towards a different VLR, the MT CS service may be delivered via the new VLR using Mobile Terminating Roaming Retry or Mobile Terminating Roaming Forwarding (see TS 23.018); the on-going MT SMS is retransmitted by the SMS-SC using the existing SMS procedures (SMS alert).
Subsequent MT CS services are delivered as per normal procedures.
See TS 29.118 for a comprehensive description.
Up

Up   Top   ToC