When a SGW fails, all its Bearer contexts affected by the failure become invalid and may be deleted. SGW storage of subscriber data is volatile. When the SGW receives a GTP-U PDU for which no Bearer context exists, it shall discard the GTP-U PDU and return a GTP error indication to the originating node (the PGW, the eNodeB, the S4-SGSN, or if Direct Tunnel is established, the RNC) or follow the procedures specified in clause 27.2.2.5 if the restoration of PDN connections after an SGW failure is supported. The SGW should ensure as far as possible that previously used TEID values are not immediately reused after a SGW restart, in order to avoid inconsistent TEID allocation throughout the network.

After an SGW restart, the SGW shall delete all MM Bearer contexts affected by the restart that it may have stored. During or immediately after an SGW Restart the SGW shall place local SGW restart counter value in all GTPv2 Echo requests/responses messages and PMIPv6 heartbeat responses the SGW sends.

When a SGW-C fails, all its Bearer and Session contexts, Sx Association(s) affected by the failure become invalid and may be deleted. If F-TEID allocation is performed in the SGW-C, the SGW-C should ensure as far as possible that previously used F-TEID values are not immediately reused after a SGW-C restart, in order to avoid inconsistent TEID allocation throughout the network.

During or immediately after an SGW-C Restart, the SGW-C shall place local SGW-C Recovery Time Stamp value in all Heartbeat Request/Response and Sx Association Setup Request/Response Messages.

When a SGW-U fails, all its Sx session contexts and Sx Association(s) affected by the failure become invalid and may be deleted. If F-TEID allocation is performed in the SGW-U, the SGW-U shall ensure that previously used F-TEID values are not immediately reused after a SGW-U restart, in order to avoid inconsistent TEID allocation throughout the network and to enable the restoration of Sx sessions affected by the failure. How this is ensured is implementation specific.

During or immediately after an SGW-U Restart, the SGW-U shall place local SGW-U Recovery Time Stamp value in all Heartbeat Request/Response and Sx Association Setup Request/Response Messages.

The SGW will receive the PGW restart counter in GTPv2 Echo requests/ responses and PMIPv6 heartbeat responses that the SGW receives from the PGW. When an SGW detects that a peer PGW has restarted (see clause 18 "GTP-C based restart procedures") it shall delete all PDN connection table data/MM bearer contexts associated with the peer node that fails as well as freeing any internal SGW resources associated with those PDN connections. In addition, if the optional feature PGW Restart Notification is supported by the SGW and MME/S4-SGSN as specified in clause 8.83 of TS 29.274, the SGW shall initiate the cleanup of the hanging PDN connections associated with the SGW and the restarted PGW at the corresponding MMEs/S4-SGSNs by sending GTPv2 message(s) PGW Restart Notification, with the control plane IP address of the restarted PGW and the control plane IP address of the SGW on the S11/S4 interface included. The SGW may optionally perform other implementation specific actions such as messages to clear other external resources (e.g. PCC messages). If an SGW detects that a peer PGW has failed and not restarted, it may delete all PDN connection table data/MM bearer contexts associated with the peer node that fails as well as freeing any internal SGW resources associated with those PDN connections. In addition, if the optional feature PGW Restart Notification is supported by the SGW and MME/S4-SGSN as specified in clause 8.83 of TS 29.274, the SGW may also send a PGW Restart Notification message to the MME or S4-SGSN. The PGW Restart Notification message shall include the control plane IP address of the PGW, the control plane IP address of the SGW on the S11/S4 interface and the cause value "PGW not responding". It is an implementation matter how an SGW becomes aware that a PGW has failed and has not restarted, e.g. the SGW detects a signalling path failure with the PGW for a duration exceeding the maximum path failure duration timer (see clause 20.2.1). When the MME/S4-SGSN receives this message, according to the control plane IP address of the restarted PGW and the control plane IP address of the SGW on the S11/S4 interface included in the message, the MME/S4 SGSN should delete all PDN connection table data/MM bearer contexts associated with the SGW and the restarted PGW as well as freeing any internal MME/S4-SGSN resources associated with those PDN connections. Additionally the MME/S4-SGSN may decide to restore certain PDN connections based on operator's policy e.g. based on the QCI and/or ARP and/or APN. If so,

• the S4-SGSN shall deactivate the corresponding PDN connections using the "reactivation requested" cause value as specified in clause 9.2.4.2 of TS 23.060;
• the MME shall deactivate the corresponding PDN connections using the "reactivation requested" cause value as specified in clause 5.10.3 of TS 23.401 if only a subset of the PDN connections of the UE need to be restored or if the UE has a SCEF PDN connection or if the UE supports Attach without PDN connectivity as specified in clause 5.3.8.3 of TS 23.401; if all the PDN connections of the UE need to be restored and the UE does not have a SCEF PDN connection and the UE does not support Attach without PDN connectivity, the MME shall initiate the "explicit detach with reattach required" procedure as specified in clause 5.3.8.3 of TS 23.401.

The MME/S4-SGSN may prioritize the PDN connections to restore 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 by 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. The MME/S4-SGSN may optionally perform other implementation specific actions such as to clear external resources (e.g. S1-MME messages to clear eNodeB resources or Iu messages to clear RNC resources) or more advanced forms of restoration. If PMIPv6 based S5/S8 interface is used and if the SGW needs to send a request for Gateway Control and QoS Policy Rules Provision procedure towards a PCRF which is known to have restarted since the Gateway Control Session Establishment, the SGW may discard the request and may tear down the associated PDN connection, based on operator policy, by sending a Delete Bearer Request message for the default bearer towards the MME/S4-SGSN with the cause set to "Reactivation requested". Additionally, SGW initiates an SGW initiated PDN Disconnection procedure towards PGW. This leads the UE to initiate a UE requested PDN connectivity procedure for the same APN. Emergency and eMPS sessions should not be torn down. For a split SGW, if the SGW-C detects a PGW failure, it shall initiate a Sx Session Deletion procedure towards the SGW-U.

The SGW-U will receive the recovery time stamps of the PFCP entity(ies) in the SGW-C in PFCP heartbeat request/response messages. When an SGW-U detects that a peer PFCP entity in the SGW-C has restarted, the SGW-U shall delete all its Sx session contexts affected by the restart. When the SGW-U receives a GTP-U PDU not matching any PDRs, it shall discard the GTP-U PDU and return a GTP error indication to the originating node (the PGW, the eNodeB, the S4-SGSN, or if Direct Tunnel is established, the RNC); as an exception, if the restoration of PDN connections after an SGW failure is supported as specified in clause 27, the SGW-U shall not send Error indication message for a configurable period after the restart in the SGW-C. When a SGW-U detects that a peer PFCP entity in the SGW-C is not reachable for a preconfigured time, the SGW-U shall delete all session contexts affected by the unreachability of the peer PFCP entity in the SGW-C that it may have stored.

The SGW-C will receive the recovery time stamps of the PFCP entity(ies) in the SGW-U in PFCP heartbeat request/response messages. After an SGW-U restart, the Sx association between SGW-C(s) and the SGW-U has to be re-established. Restoration of Sx sessions includes:

• if re-establishment of Sx association is required, the SGW-C may start immediately the Sx association setup procedure, and then;
  • when re-establishing a Sx session and if F-TEID allocation is performed in the SGW-U by network configuration, the SGW-C shall include a restoration indication in the PFCP Session Establishment Request message to indicate to the SGW-U it is for a restoration of an existing PFCP session and the SGW-U shall accept SGW-C allocated F-TEID if possible.
• if the restoration is supported in the SGW-C on a proactive basis, the SGW-C may start re-establishing Sx sessions matching any PDRs.
• if the restoration is supported in the SGW-C on a reactive basis:
  • the SGW-C shall establish an Sx session with a wildcarded PDR to instruct the UP function to forward G-PDU packets which are not matching any other PDRs to the CP function (to a F-TEID uniquely assigned in the CP function for this Sx-u tunnel);
  • upon receipt of G-PDUs from this Sx-u tunnel, the CP function shall then check if it has an active session for each received G-PDU packet:
    • if so, the CP function shall perform Sx Session establishment procedures to re-establish the corresponding Sx sessions in the SGW-U;
    • otherwise the CP function shall generate a GTP-U Error Indication with a destination address set to the source IP address of the received G-PDU, and send it to the UP function. The UP function shall forward this GTP-U Error Indication transparently. The CP function shall delete the G-PDU after the check for active sessions.

The SGW-U shall not send Error indication message for a configurable period after a PFCP entity restart in the SGW-U when the SGW-U receives G-PDU not matching any PDRs. When the SGW-C detects the failure of an SGW-U without a restart, the SGW-C may select an alternative SGW-U which can take over the IP addresses of the failed one to restore the Sx sessions in the UP function. How this is performed is implementation specific.

See Clause 23. In addition, the following applies. If an SGW, which supports the feature receives Delete PDN Connection Set Request/Reply messages from MME or the PGW it shall forward the messages to the appropriate peer. If the SGW does not support the feature then partial failure handling does not apply to that specific PDN connection.

If the SGW supports the feature, the following procedures apply. During a PDN connection establishment, the SGW shall provide one SGW FQ-CSID for that particular PDN connection to the PGW. Similarly, the SGW shall provide one SGW FQ-CSID for that particular PDN connection to the MME if the MME supports partial failure handling. The SGW shall store the Node-ID and CSID from the FQ-CSID provided by the PGW and the MME respectively for that particular PDN connection in its PDN Connection table maintained as part of "EPS Bearer Contexts" table as specified in Table 5.7.3-1 in TS 23.401. The SGW shall forward the MME FQ-CSID provided by the MME on S11 to the PGW in the S5/S8 Create Session Request (Proxy Binding Update for PMIPv6) for that PDN connection. Similarly, the SGW shall forward the PGW FQ-CSID provided by the PGW on S5/S8 to the MME in the S11 Create Session Response for that PDN connection if the MME supports partial failure handling. The SGW determines that the MME supports partial failure handling by the presence of the MME FQ-CSID in the S11 Create Session Request. The SGW determines that the PGW supports partial failure handling by the presence of the PGW FQ-CSID in the S5/S8 Create Session Response for GTPv2 based S5/S8 and the Proxy Binding Acknowledgement for PMIPv6 based S5/S8.

If the SGW supports the feature, the following procedures apply. When an SGW detects that it has undergone a partial failure, it shall verify that one or more corresponding CSID(s) are present for the component undergoing a partial fault. If there is no such CSID, then the following does not apply. When one or more CSIDs are currently assigned, the SGW shall perform the following. The SGW may perform implementation-specific operations to clean up any residual state associated with the CSID(s). The SGW shall send the GTPv2 Delete PDN Connection Set Request containing all the SGW CSIDs of the component(s) failing in SGW FQ-CSID to MME peers supporting the feature. The SGW shall send the GTPv2 Delete PDN Connection Set Request (or PMIP6 Binding Revocation Indication with G bit set) message containing the equivalent SGW FQ-CSID(s) to PGW peers supporting the feature. Upon receiving a GTPv2 Delete PDN Connection Set Response message with Cause value "Success", the SGW shall conclude that the PGW (for GTPv2 S5/S8) or the MME (for S11) has initiated the internal deletion of the PDN connections corresponding to the FQ-CSID(s) present in the GTPv2 Delete PDN Connection Set Request message. Similarly, upon receiving a successful PMIP6 Binding Revocation Acknowledgment message with G bit set, the SGW shall conclude that the PGW has initiated the internal deletion of the PDN connections corresponding to the CSID(s) present in the PMIP6 Binding Revocation Indication message. The SGW is not required to perform any further recovery actions towards MME and PGW peers for PDN connections in the connection set identified by the SGW FQ-CSID(s).

If the SGW supports the feature, the following procedures apply. When an SGW receives a S11 GTPv2 Delete PDN Connection Set Request message from an MME, the SGW shall retrieve all the PDN connections corresponding to each of the FQ-CSID(s) present in the message. The SGW shall send a S5/S8 GTPv2 Delete PDN Connection Set Request (or PMIP6 Binding Revocation Indication with G bit set) message containing the FQ-CSID(s) provided by the MME to PGW peers supporting the feature. The SGW shall delete all the retrieved PDN connections and the associated resources. Other implementation-specific actions may be performed. As a response, the SGW shall send a S11 GTPv2 Delete PDN Connection Set Response message with an appropriate Cause value immediately to the MME. When an SGW receives a S5/S8 GTPv2 Delete PDN Connection Set Request (or PMIP6 Binding Revocation Indication with G bit set) message from a PGW, the SGW shall retrieve all the PDN connections corresponding to each of the FQ-CSID(s) present in the message. The SGW shall send a S11 GTPv2 Delete PDN Connection Set Request message containing the FQ-CSID(s) provided by the PGW to MME peers supporting the feature. The SGW shall delete all the retrieved PDN connections and the associated resources. Other implementation-specific actions may be performed. As a response, the SGW shall send a S5/S8 GTPv2 Delete PDN Connection Set Response message with an appropriate Cause value to the PGW. On PMIP6-based S5/S8 interface, the SGW shall send a PMIP6 Binding Revocation Acknowledgment message with G bit set. If the SGW detects the full/complete failure of an MME or PGW, e.g., through the Echo Request/Echo Response procedure, it may send a Delete PDN Connection Set Request (or PMIP6 Binding Revocation Indication with G bit set) message, containing all of the FQ-CSIDs of the associated hanging PDN connections of the failed node, to the corresponding remote node (MME or PGW).

Only if the SGW supports the feature, the following procedures apply. During a S11 or an S5/S8 procedure, impacting an existing PDN connection removal or modification the following apply:

1. If the MME is being relocated then the SGW shall clear the currently stored MME FQ-CSID value (if any).
2. For inter MME and intra SGW HO/TAU, and if the new MME supports the feature, then the SGW shall:
   • include SGW FQ-CSID in the S11 Modify Bearer Response. If PGW supports the feature, the SGW shall also include PGW FQ-CSID into the message.
   • inform the feature supporting PGW about the change of FQ-CSID values with the following messages:
     • Modify Bearer Request, when Modify Bearer Request message needs to be sent to the PGW as specified in the TS 23.401, e.g. if the sending of this message is triggered by user location reporting procedure. The message shall contain both SGW FQ-CSID and MME FQ-CSID.
     • Update PDN Connection Set Request message, only if Modify Bearer Request is not sent. The message shall contain both SGW FQ-CSID and MME FQ-CSID.
     • Proxy Binding Update (if PMIPv6 is used). The message shall contain both SGW FQ-CSID and MME FQ-CSID.
3. For inter MME and intra SGW HO/TAU, and if the new MME does not support the feature, then the SGW shall:
   • not include any FQ-CSID in the S11 Modify Bearer Response.
   • inform the feature supporting PGW with the following messages:
     • Modify Bearer Request when Modify Bearer Request message needs to be sent to the PGW as specified in the TS 23.401, e.g. if the sending of this message is triggered by user location reporting procedure. The message shall contain only SGW FQ-CSID.
     • Update PDN Connection Set Request message, only if Modify Bearer Request is not sent. The message shall contain only SGW FQ-CSID.
     • Proxy Binding Update (if PMIPv6 is used). The message shall contain only the SGW FQ-CSID.
4. For inter SGW HO/TAU, if the new MME supports the feature, then the new SGW shall:
   • include SGW FQ-CSID in the S11 Create Session Response. If PGW supports the feature, the SGW shall also include PGW FQ-CSID into the message.
   • inform the feature supporting PGW about the change of FQ-CSID values with the following messages:
     • Modify Bearer Request. The message shall contain both SGW FQ-CSID and MME FQ-CSID.
     • Proxy Binding Update (if PMIPv6 is used). The message shall contain both SGW FQ-CSID and MME FQ-CSID.
5. For inter SGW HO/TAU, if the MME does not support the feature, then the SGW shall:
   • not include any FQ-CSID in the S11 Create Session Response.
   • inform the feature supporting PGW about the change of SGW FQ-CSID value with the following messages:
     • Modify Bearer Request. The message shall contain only SGW FQ-CSID
     • Proxy Binding Update (if PMIPv6 is used). The message shall contain only the SGW FQ-CSID.
6. If the SGW receives a FQ-CSID value of a PGW over S5/S8, or a FQ-CSID value of a MME over S11, the SGW shall overwrite the current stored FQ-CSID value with the received value.
7. During the PDN connection removing procedures, a PGW removes the PDN data as well as any stored FQ-CSID values(s) of the MME and SGW FQ-CSIDs.
8. For the following procedures, if the procedures as specified in TS 23.401 e.g. Location Change reporting is enabled, the SGW shall send its own FQ-CSID and the MME FQ-CSID in Modify Bearer Request and Proxy Binding Update across S5/S8 interface to the respective PGW even if the MME did not update its FQ-CSID, e.g.:
   • X2-based Handover without SGW relocation
   • TAU without MME and without SGW relocation
   • UE Triggered Service Request

During a S11 or S5/S8 procedure removing an existing PDN connection the SGW simply removes the PDN data as well as any stored FQ-CSID values(s) of the PGW FQ-CSID and MME FQ-CSID or pointers to such data. The same actions are done on the old SGW if there is an SGW relocation. An SGW determines that the MME supports partial failure handling if MME FQ-CSID is present in the received S11 Modify Bearer Request or S11 Create Session Request (with both MME and SGW change) messages. A new SGW determines that the PGW supports partial failure handling if PGW FQ-CSID is present in the S5/S8 Modify Bearer Response for GTPv2 based S5/S8 or in the Proxy Binding Acknowledgement for PMIPv6 based S5/S8.