The following requirements shall apply if the MME/S4-SGSN, the SGW, the PGW, and the PCRF support this feature. The MME/S4-SGSN, PGW, and PCRF for PMIP based S5, shall know by local configuration whether this MME/S4-SGSN triggered SGW restoration procedure is supported in the PLMN, i.e. by peer PGWs, PCRFs and MME/S4-SGSNs. The PGW shall assume that either all or none of the MMEs/S4-SGSNs in the PLMN support this procedure.Upon detecting an SGW failure with or without restart (relying on restart counter as specified in clause 18 "GTP-C based restart procedures" and clause 19 "PMIP based restart procedures", or implementation e.g. preconfigured path failure timer), the MME/S4-SGSN and PGW shall maintain the bearers and MM contexts of the PDN connections affected by the SGW failure and eligible for restoration, instead of removing associated resources as per procedures specified in clauses 14.1A.1 and 17.1A.1. For PMIP based S5, when the PCRF detects an SGW failure or restart, the PCRF shall maintain the IP-CAN sessions and delete locally the Gxc sessions affected by the SGW failure. The PDN connections eligible for restoration are determined by the MME/S4-SGSN and PGW based on same operator's policies, e.g. based on QCI, ARP and/or APN. Maintaining the PDN connections affected by the SGW failure enables the MME/S4-SGSN to restore the corresponding bearers of the UE by selecting a new SGW or the restarted SGW. These PDN connections are maintained for an operator configurable period (T-Release-PDN timer), which is locally provisioned on MME/S4-SGSN and PGW, that by default should cover 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. After the expiry of the T-Release-PDN timer the MME/S4-SGSN and the PGW should delete any EPS bearer contexts that have not been restored via a new or the restarted SGW.

After detecting an SGW failure, the MME/S4-SGSN should attempt to restore the PDN connections eligible for restoration for all the UEs affected by the SGW failure, i.e. including UEs in ECM_IDLE / PMM-IDLE / GPRS STANDBY not engaged in any Service Request, or Connection Resume procedure or other mobility procedure. The MME/S4-SGSN shall control the pace of the SGW relocations to avoid core network node overload. The MME/S4-SGSN should prioritize the SGW relocation for UEs engaged in a Service Request, or a Connection Resume, or RAU/TAU procedures or having GBR bearers over UEs which are not engaged in any mobility procedure and that do not have a signalling connection to the MME/S4-SGSN nor GBR bearers. The MME/S4-SGSN should also prioritize the SGW relocation for UEs with an emergency PDN connection. The MME/S4-SGSN may further prioritize the PDN connections to restore, e.g. for UEs ECM_IDLE / PMM-IDLE / GPRS STANDBY not engaged in any Service Request or Connection Resume procedure, based on operator's policy e.g. based on the QCI and/or APN. Besides, the MME/SGSN may use the subscribed Restoration Priority per APN, if received from the HSS, and if permitted per service level agreements for in-bound roamers, to determine the relative restoration priority among PDN connections to the same APN. The MME/SGSN may use a locally configured value as default restoration priority if the restoration priority for a user's PDN connection is not received from the HSS or not permitted by service level agreement for in-bound roamers. To restore the PDN connection(s) of a UE, the MME/S4-SGSN shall perform an SGW relocation procedure by sending a Create Session Request message (per PDN connection to restore) to the new or restarted SGW as per the steps 8-11 of a Tracking Area Update procedure with Serving GW change in clause 5.3.3.1 of TS 23.401. For PDN connections with GBR bearers existing before the SGW failure, the MME/S4-SGSN may either request to restore or remove the GBR bearers in the Create Session Request (e.g. depending on how quickly the PDN connection is restored). The MME/S4-SGSN shall restore the PDN connections of the affected UEs after the SGW failure as follows:

1. for UEs in ECM_IDLE/PMM-IDLE/GPRS STANDBY state:
   • the MME/S4-SGSN shall select a new SGW or the restarted SGW based on the last visited TAI/RAI. When Dedicated Core Networks are deployed, the UE Usage Type shall also be used for the SGW selection as specified in TS 29.303;
   • the MME/S4-SGSN shall then perform an SGW relocation procedure as specified above.
2. for UEs in ECM_CONNECTED/PMM-CONNECTED/GPRS READY state not engaged in any mobility procedure (TAU/RAU, Handover):
   • the MME/S4-SGSN shall release the S1/Iu/radio resources; if the eNodeB/RNC detects the SGW failure, the eNodeB/RNC may request the MME/S4-SGSN to release the S1/Iu resources;
   • the MME/S4-SGSN shall then handle these UEs as specified for UEs in ECM_IDLE/PMM-IDLE/GPRS STANDBY state, or for UEs performing a mobility procedure if the UE performs subsequently such a mobility procedure (e.g. a Service Request to re-establish the S1/Iu/radio bearers);
   • as an exception to these rules, for UTRAN without direct tunnel and GERAN, the S4-SGSN may perform SGW relocation while keeping the UEs in PMM-CONNECTED/GPRS READY state (i.e. without tearing down the Iu/radio resources) because S4 user plane is used and the SGW failure remains not visible to the radio network.
3. for UEs in ECM-IDLE/PMM-IDLE/GPRS STANDBY state initiating a Service Request procedure or a Connection Resume procedure:
   • the MME/S4-SGSN shall first perform the SGW relocation procedure as specified above and then continue with the Service Request or the Connection Resume procedure since the MME/S4-SGSN has no valid SGW F-TEID to send in the S1-AP Initial Context Setup Request towards the eNodeB or in the Iu RAB Assignment Request message towards the RNC if Direct Tunnel is used.
4. for UEs initiating an intra-MME or intra-S4-SGSN TAU/RAU procedure:
   • the MME/S4-SGSN shall perform the SGW relocation procedure as specified above before the TAU/RAU procedure;
5. for UEs initiating an inter-MME/SGSN TAU/RAU procedure:
   • If both the source and target MME/S4-SGSNs support this SGW restoration procedure, the source MME/S4-SGSN should indicate to the target MME/S4-SGSN in the GTPv2 Context Response message that an SGW relocation procedure is needed due to an earlier SGW failure. Upon reception of such indication, the target MME/S4-SGSN shall perform the SGW relocation procedure as specified above and then proceed with the TAU/RAU procedure. The source MME/S4-SGSN may perform the SGW relocation procedure as specified above before responding to the GTPv2 Context Request message if the target MME/S4-SGSN does not support the SGW restoration procedure, e.g. during inter-PLMN RAU/TAU procedures when the target PLMN does not support the SGW restoration procedure.
6. for UEs in ECM-CONNECTED/PMM-CONNECTED/GPRS READY state for which a handover procedure is initiated:
   • The source MME/S4-SGSN should reject the Handover Required / Relocation Required message received from the RAN (for UEs with PDN connection(s) affected by an earlier SGW failure that have not been restored yet); the MME/S4-SGSN should then release the S1/Iu/radio resources of these UEs to force them to enter idle mode. The MME/S4-SGSN shall then proceed with the procedures specified above for UEs in ECM_IDLE/PMM-IDLE/GPRS STANDBY state, or for UEs performing a mobility procedure if the UE performs subsequently such a mobility procedure (e.g. a Service Request to re-establish the S1/Iu/radio bearers).

After detecting a combined SGW/PGW failure, the MME/S4-SGSN behavior shall be same as in the case when an MME/S4-SGSN receives the optional PGW Restart Notification message. Either of the following shall apply:

• MME/S4-SGSN behavior is determined by clause 16.1A.2 "PGW Failure";
• PDN connections can be restored by the MME (this does not apply to S4-SGSN), as specified in clause 31.3 "MME triggered PDN connection restoration".

The PGW shall maintain the PDN connections affected by the SGW failure and eligible for restoration for an operator configurable period (T-Release-PDN timer), as specified in clause 27.2.2.1. The PGW should maintain the GBR bearers of the PDN connections eligible for restoration for an operator configurable period (T-Release-GBR), which should be much shorter than the T-Release-PDN timer. Upon expiry of the T-Release-GBR timer, the PGW shall release GBR bearers that have not been restored yet and inform the PCRF about the corresponding PCC rule inactivation, with a cause as specified in TS 29.212. The PGW shall discard downlink packets received for a PDN connection maintained after an SGW failure that has not been restored yet. The PGW shall stop charging for PDN connections maintained after an SGW failure which have not been restored yet. If the IP-CAN Session Modification Request is received for a PDN connection maintained after an SGW failure but not restored yet, the PGW shall reject the request if the request contains the installation/modification of PCC rules and other policy decisions (e.g. change of APN-AMBR), however the P-GW shall accept to remove the PCC rule if the removal of PCC rules is included in the request. The PGW shall accept an IP-CAN Session Modification Request if it only includes the removal of PCC rules. Refer to clause B.3.14 of TS 29.212 for the detail. For these IP-CAN sessions for which an IP-CAN session modification has been rejected, the PGW shall subsequently inform the PCRF when the PDN connection is restored as specified in clause B.3.14 of TS 29.212. This would enable the PCRF to update the PCC rules in the PGW if necessary. After the PDN connection is restored, the PGW shall initiate the bearer modification/deactivation procedure if necessary to modify or remove the resources associated with the PCC rules that were removed during the SGW failure. The PGW shall accept an IP-CAN Session Termination Request received for a PDN connection maintained after an SGW failure but not restored yet, with an acceptance cause as specified in TS 29.212 and release the affected PDN connection locally. If subsequently the MME/S4-SGSN attempts to restore the PDN connection, the PGW shall reject the Modify Bearer Request (for GTP based S5) or the Proxy Binding Update (for PMIP based S5) with the cause "Context Not Found" as specified in TS 29.274 and TS 29.275 after the corresponding PDN connection has been released locally.

If the PGW rejects an IP-CAN session modification procedure with the rejection cause as specified in clause 27.2.2.3, the PCRF should maintain the corresponding IP-CAN session and refrain from sending any further IP-CAN session modification request to the PGW until being notified by the PGW that the PDN connection is restored. For PMIP based S5, the PCRF cannot send any message to the SGW once the Gxc session in the PCRF is removed. The PCRF may however behave as for GTP based S5, e.g. send signalling to the PGW via the Gx interface. The Gxc session is restored when the PCRF receives Gateway Control Session Establishment from the SGW as specified in TS 29.212.

After the SGW restarts, the SGW shall not send Error indication message for a configurable period when the SGW receives a GTP-U PDU for which no Bearer context exists.

The following requirements shall apply if the MME/S4-SGSN, the SGW and the PGW support this feature. The PGW shall know by local configuration whether this PGW triggered SGW restoration procedure is supported in the PLMN. The MME/S4-SGSN/SGW may know the same by local configuration. When supported in the PLMN, the PGW supporting this procedure should be configured with the address of alternative(s) SGW(s) also supporting this procedure. The PGW shall assume that either all or none of the MMEs/S4-SGSNs in the PLMN support the procedure. All MMEs/S4-SGSNs in an MME/S4-SGSN pool should support this procedure when it is deployed. The PGW triggered SGW restoration procedure does not apply to emergency PDN connections for users without authenticated IMSI.

During normal mode of operation (i.e. before SGW failure with/without restart): The MME/S4-SGSN supporting the PGW triggered SGW restoration procedure shall include the MME/S4-SGSN identifier IE in existing signalling over the S11/S4 interface, i.e. in

• Create Session Request messages during an E-UTRAN Initial Attach, a UE requested PDN connectivity, and a PDP Context Activation procedure;
• Create Session Request message during TAU/RAU procedures with a SGW change;
• Create Session Request message during X2 based handover/Enhanced SRNS Relocation procedure with a SGW change;
• Modify Bearer Request message during Inter-RAT Handover procedures with/without a SGW change;
• Modify Bearer Request message during Intra-RAT handover procedure with a SGW change;
• Modify Bearer Request message during Inter-RAT TAU/RAU procedures without a SGW change;
• Modify Bearer Request message over S11/S4 if the message is deemed to be sent to the PGW due to other reasons, e.g. reporting ULI, time zone.

During SGW restoration procedure: Upon receipt of a PGW Downlink Triggering Notification message for which it cannot find a UE context corresponding to the received IMSI, the MME/S4-SGSN shall send a PGW Downlink Triggering Acknowledge message with the rejection cause code "Context Not Found" to the SGW to inform the SGW that the PGW Downlink Triggering Notification message has been received by the MME/S4-SGSN. If the PGW Downlink Triggering Notification message contains an MME/S4-SGSN identifier, the MME/S4-SGSN shall also include the IMSI and the MME/S4-SGSN identifier in the PGW Downlink Triggering Acknowledge message. Upon receipt of a PGW Downlink Triggering Notification message for which it can find a UE context corresponding to the received IMSI, the MME/S4-SGSN shall send a PGW Downlink Triggering Acknowledge message back to the SGW with an acceptance cause code, and perform S-TMSI/P-TMSI paging as part of Network Initiated Service Request procedure as specified in clause 5.3.4.3 of TS 23.401 and in clause 6.12.1A of TS 23.060. When receiving a Service Request message from the UE, the MME/S4-SGSN shall perform the SGW restoration procedure as specified in the clause 27.2.2 with the addition that the MME/S4-SGSN shall include the MME/S4-SGSN identifier IE in the create session request message.

During normal mode of operation (i.e. before SGW failure with/without restart): The SGW shall forward the MME/S4-SGSN identifier IE to the PGW in existing signalling over the S5 interface if it is received over S11/S4 interface. During SGW restoration procedure: Upon receipt of a PGW Downlink Triggering Notification message (or a PMIP Update Notification message with the Notification Reason set to "PGW Downlink Trigger Notification") from a PGW, the SGW shall send the PGW Downlink Triggering Notification message to the MME/S4-SGSN identified by the MME/S4-SGSN identifier if present in the message. If no MME/S4-SGSN identifier is received from the PGW, the SGW shall send the PGW Downlink Triggering Notification message to all the MME/S4-SGSN within the MME/S4-SGSN pool as known by local configuration. The SGW shall then send a PGW Downlink Triggering Acknowledge message (or a PMIP Update Notification Acknowledgement message) back to the PGW with an acceptance cause code. If the SGW receives a PGW Downlink Triggering Acknowledge message from an MME/S4-SGSN with the rejection cause code "Context Not Found" and with an IMSI and an MME/S4-SGSN identifier, the SGW shall then send a PGW Downlink Triggering Notification message, including the IMSI (as received in the PGW Downlink Triggering Acknowledge message), to all the MME/S4-SGSN within the MME/S4-SGSN pool as known by local configuration, except to the MME/S4-SGSN identified by the MME/S4-SGSN identifier received in the Downlink Triggering Acknowledge message. The MME/S4-SGSN may have more than one IP address on the S11/S4 interface configured, but the PGW Downlink Triggering Notification should be sent only once per MME/S4-SGSN per local configuration in the SGW.

During normal mode of operation (i.e. before SGW failure with/without restart): The PGW shall store the MME/S4-SGSN identifier received in the last Create Session Request or Modify Bearer Request message (for GTP based S5) or Proxy Binding Update (for PMIP based S5) per PDN connection. If the PGW receives a Modify Bearer Request without MME/SGSN identifier, it shall delete the stored MME/S4-SGSN identifier. During SGW restoration procedure: When downlink data packets or signalling other than an IP-CAN Session Termination Request arrives at the PGW, for a PDN connection associated with a failed SGW and that has not been restored yet (as specified in clause 27.2.2), and the PDN connection is eligible for PGW initiated Downlink triggering based on operator's policies, e.g. for IMS PDN connection, the PGW shall proceed as follows:

• the PGW shall select a SGW (i.e. the restarted or an alternative SGW) which supports the PGW triggered SGW restoration procedure, based on local configuration;
• for GTP-based S5, the PGW shall then send a PGW Downlink Triggering Notification message including the IMSI and the MME/S4-SGSN identifier if available;
• for PMIP-based S5, the PGW shall then send an PMIP Update Notification message as specified in IETF RFC 7077 to indicate it is a PGW initiated downlink triggering notification, including the IMSI and the MME/S4-SGSN Identifier when it is available;
• the PGW should not send a new PGW Downlink Triggering Notification message (for GTP-based S5) or Update Notification message (for PMIP-based S5) in very short time if it continues to receive subsequent downlink data or signalling for the same PDN connection. It is an implementation option how many times/how frequently the PGW should send subsequent PGW Downlink Triggering Notification message (for GTP-based S5) or Update Notification message (for PMIP-based S5) before discarding the downlink packets or rejecting signalling.
• the PGW shall handle an IP-CAN Session Modification Request received from the PCRF as specified in clause B.3.14 of TS 29.212 as if the PDN connection had not been affected by the SGW failure i.e. was in a normal state . After accepting an IP-CAN session modification request, if the MME/S4-SGSN does not restore the PDN connection shortly after the PGW initiated triggering, the PGW shall report the modification failure to the PCRF with a cause as specified in clause B.3.14 of TS 29.212.

The PGW shall behave as specified in clause 27.2.2.3 if the PGW receives an IP-CAN Session Termination Request for a PDN connection associated with a failed SGW and that has not been restored yet.

The requirement specified in clause 27.3.1.2 shall apply on top of the MME/S4-SGSN triggered SGW restoration procedure specified in clause 27.2.2 and the involved MME and S4-SGSN additionally support the ISR feature.

The MME/S4-SGSN shall restore the PDN connections of the affected UEs after the SGW failure as follows:

1. for UEs initiating an intra MME/S4-SGSN TAU/RAU procedure:
   • the MME/S4 SGSN shall perform the SGW relocation procedure as specified in clause 27.2.2, and inform the UE in the related TAU/RAU Accept message to disable ISR as specified in TS 23.401 and TS 23.060.
2. for UEs in ECM-IDLE/PMM-IDLE/GPRS STANDBY state initiating a Service Request procedure:
   • the MME/S4 SGSN shall perform the SGW relocation procedure as specified in clause 27.2.2 and 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.
3. for UEs in ECM-CONNECTED/PMM-CONNECTED/GPRS READY state engaged in any handover or inter MME/S4-SGSN TAU/RAU procedure:
   • it shall be handled as specified in clause 27.2.2.
4. for UEs in ECM-IDLE/PMM-IDLE/GPRS STANDBY state which are not engaged in any Service Request or other mobility procedure:
   • In networks supporting PGW triggered SGW restoration proactive paging of UEs in ECM-IDLE/PMM-IDLE/GPRS STANDBY state shall not be initiated.
     The MME/S4-SGSN shall page the UE to bring the UE to ECM-CONNECTED/PMM-CONNECTED. If the paging is successful and the UE initiates the Service Request procedure, the MME/S4-SGSN shall perform the SGW relocation procedure as specified in clause 27.2.2 and 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 as specified in clause 5.3.4.3 of TS 23.401. If paging the UE fails, the MME or S4-SGSN should adjust its paging retransmission strategy (e.g. limit the number of short spaced retransmissions) to take into account the fact that the UE might be in GERAN/UTRAN or E-UTRAN coverage. If the associated MME/S4-SGSN receives ISR Status Indication with "deactivation Indication" from S4-SGSN/MME, the MME/S4-SGSN shall release the UE session locally. Otherwise after retrying the paging procedure, the MME/S4-SGSN may release locally the PDN connection context and UE MM context assuming the UE is in GERAN/UTRAN or E-UTRAN coverage area.
     MME/S4-SGSN should handle UEs in ECM-CONNECTED/PMM-CONNECTED and involved in any handover or inter MME/S4-SGSN TAU/RAU procedure first before paging of UEs in ECM-IDLE/PMM-IDLE/GPRS STANDBY to minimise paging of UEs. Furthermore the sequence on how UEs in ECM-IDLE/PMM-IDLE/GPRS STANDBY can be paged to avoid overload are implementation dependent.

The MME/S4-SGSN which initiates the SGW restoration procedure should send ISR Status Indication with "ISR deactivation Indication" to the ISR associated S4-SGSN/MME to release the PDN connection context and UE MM context. The S4-SGSN will only perform the SGW reselection for the UEs camping on the GERAN/UTRAN, ISR activated UEs can camp in the LTE, so paging is needed.

The requirement specified in clause 27.3.2.2 shall apply on top of the PGW triggered SGW restoration procedure specified in clause 27.2.3 and the involved MME and S4-SGSN additionally support the ISR feature.

If the MME/S4-SGSN receives a PGW Downlink Triggering Notification message containing MME/S4-SGSN Identifier from the SGW for those UEs affected by the failed SGW, the MME/S4-SGSN shall behave as specified in clause 27.2.3.2 and additionally send ISR Status Indication message with "Paging Indication" over the S3 interface to the ISR associated S4-SGSN/MME over the existing GTP-C tunnel between the S4-SGSN and the MME. The ISR associated S4-SGSN/MME, which receives ISR Status Indication message with "Paging Indication", shall perform P-TMSI/S-TMSI paging as part of the Network Initiated Service Request procedure as specified in clause 27.3.1.2. After the MME/S4-SGSN receiving NAS message Service Request, the MME/S4-SGSN shall behave as specified in the clause 27.3.1.2.