When a PGW fails, all its Bearer contexts affected by the failure become invalid and may be deleted. PGW storage of subscriber data is volatile. When the PGW 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 i.e. the SGW/ePDG/TWAN. The PGW should ensure as far as possible that previously used TEID values are not immediately reused after a PGW restart, in order to avoid inconsistent TEID allocation throughout the network.

After a PGW restart, the PGW shall delete all MM Bearer contexts affected by the restart that it may have stored. During or immediately after a PGW Restart, the PGW shall place this PGW restart counter value in all GTPv2 echo requests/responses and PMIPv6 heartbeat responses the PGW sends.

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

After a PGW-C restart, the PGW-C shall delete all MM Bearer and session contexts, and Sx Associations affected by the restart that it may have stored. During or immediately after a PGW-C Restart, the PGW-C shall place local PGW-C Recovery Time Stamp value in all Heartbeat Request/Response and Sx Association Setup Request/Response Messages.

When a PGW-U fails, all its Session contexts and Sx associations affected by the failure become invalid and may be deleted. If F-TEID allocation is performed in the PGW-U, the PGW-U shall ensure that previously used F-TEID values are not immediately reused after a PGW-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. The PGW-U shall not send Error indication message for a configurable period after an PGW-U restart when the PGW-U receives G-PDU not matching any PDRs.

During or immediately after an PGW-U Restart, the PGW-U shall place local PGW-U Recovery Time Stamp value in all Heartbeat Request/Response and Sx Association Setup Request/Response Messages. Immediately after the re-establishment of an Sx association between the PGW-C and the PGW-U, the PGW-C may start restoring Sx sessions in the PGW-U.

The PGW will receive the SGW/ePDG/TWAN restart counters in GTPv2 echo requests/responses and PMIPv6 heartbeat responses that the PGW receives from the SGW/ePDG/TWAN. When a PGW detects that a peer ePDG/peer TWAN has restarted it shall delete all PDN connection table data/MM bearer contexts associated with the peer node that fails as well as freeing any internal PGW resources associated with those PDN connections. The PGW may optionally perform other implementation specific actions such as messages to clear other external resources (e.g. PCC messages). When a PGW detects that a peer SGW has failed with or without restart it shall either:

• proceed as specified above when the PGW detects that a peer ePDG/TWAN fails; or
• follow the procedures specified in clause 27 to restore the PDN connections affected by the SGW failure, if the MME/S4-SGSN and the PGW support these procedures.

For multi-access PDN connection in the Network-initiated NBIFOM mode, when the PGW detects ePDG/TWAN has failed, the PGW may:

• maintain the PDN connection on the 3GPP access and notify the PCRF the removal of Non-3GPP access. Then the PCRF can determine to move the affected traffic to the 3GPP access by updating the PCC rules as specified in the clause 5.8 in TS 23.161.

For multi-access PDN connection in the Network-initiated NBIFOM mode, when the PGW detects that the SGW has failed, the PGW may:

• maintain the PDN connection on the Non-3GPP access and notify the PCRF the removal of 3GPP access. Then the PCRF can determine to move the affected traffic to the 3GPP access by updating the PCC rules as specified in the clause 5.8 in TS 23.161, if the SGW restoration procedures as specified in clause 27 are not supported; or,
• follow the SGW restoration procedures specified in clause 27, e.g. maintain the PDN connection on both non-3GPP access and 3GPP access without notify the PCRF about SGW failure, if the SGW restoration procedures are supported.

If the PGW needs to send a request for IP-CAN Session Modification procedure towards a PCRF which is known to have restarted since the IP-CAN session establishment, the PGW may discard the request and may tear down the associated PDN connection, based on operator policy, by initiating a PGW initiated bearer deactivation procedure for the default bearer towards the MME/S4-SGSN with the cause set to "Reactivation requested". 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.

The PGW-U will receive the recovery time stamps of the PFCP entity(ies) in the PGW-C in PFCP heartbeat requests/responses. When a PGW-U detects that a peer PFCP entity in the PGW-C has restarted, the PGW-U shall delete all session contexts affected by the restart that it may have stored. When a PGW-U detects that a peer PFCP entity in the PGW-C is not reachable for a preconfigured time, the PGW-U shall delete all session contexts affected by the unreachability of the peer PFCP entity in the PGW-C that it may have stored.

The PGW-C will receive the recovery time stamps of the PFCP entity(ies) in the PGW-U in and PFCP heartbeat requests/responses. The PGW-C may start restoring Sx sessions in the PGW-U and it may:

• if re-establishment of Sx association is required, immediately re-establish the Sx association between the PGW-C and the PGW-U;
• re-establish Sx sessions affected by the PGW-U failure.
  • when re-establishing a Sx session and if F-TEID allocation is performed in the PGW-U by network configuration, the PGW-C shall include a restoration indication in the PFCP Session Establishment Request message to indicate to the PGW-U it is for a restoration of an existing PFCP session and the PGW-U shall accept PGW-C allocated F-TEID if possible.

See Clause 23.

If the PGW supports the feature, the following procedures apply. During a PDN connection establishment, the PGW shall provide one FQ-CSID containing exactly one CSID for that particular PDN connection to the SGW, the ePDG or the TWAN. The PGW shall store the FQ-CSID provided by the SGW and the MME in the PDN Connection table maintained as part of P-GW Context as specified in Table 5.7.3-1 in TS 23.401. Similarly, the PGW shall store the FQ-CSID received from the ePDG or the TWAN. The PGW should ensure as far as possible that previously used FQ-CSIDs are not immediately reused after a partial/full failure of a PGW. PGW determines that the partial failure handling does not apply to this PDN connection if it does not receive an SGW FQ-CSID in the S5/S8 Create Session Request (for GTP based interface) or in Proxy Binding Update (for PMIPv6 based interface), or if it does not receive a TWAN FQ-CSID in the S2a Create Session Request (for GTP based S2a) or in Proxy Binding Update (for PMIPv6 based S2a), or if it does not receive an ePDG FQ-CSID in the S2b Create Session Request (for GTP based S2b) or in Proxy Binding Update (for PMIPv6 based S2b).

If the PGW supports the feature, the following procedures apply. When a PGW detects that it has undergone a partial failure, it shall verify that one or more corresponding CSID(s) are present for the component(s) 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 PGW shall perform the following:

• The PGW may perform implementation-specific operations to clean up any residual state associated with the CSID(s).
• The PGW shall send the GTPv2 Delete PDN Connection Set Request (or PMIPv6 Binding Revocation Indication with G bit set) message containing all the PGW FQ-CSID(s) of the component(s) failing to the SGW, the TWAN or the ePDG that support the feature.

Upon receiving a GTPv2 Delete PDN Connection Set Response message with Cause value "Success", the PGW shall conclude that the SGW, the ePDG peer or the TWAN peer 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 PMIP6 Binding Revocation Acknowledgment message with G bit set, the PGW shall conclude that the SGW, the ePDG or the TWAN has initiated the internal deletion of the PDN connections corresponding to the CSID(s) present in the PMIPv6 Binding Revocation Indication message with G bit set. The PGW is not required to perform any further recovery actions towards SGW, MME peers, an ePDG peer or a TWAN peer for PDN connections in the connection set identified by the PGW FQ-CSID regardless of the "Cause" value in the response.

If the PGW supports the feature, the following procedures apply. When a PGW receives a GTPv2 Delete PDN Connection Set Request (or PMIPv6 Binding Revocation Indication with G bit set) message from an SGW, an ePDG or a TWAN, the PGW shall retrieve all the PDN connections corresponding to each of the FQ-CSIDs present in the message. The PGW shall delete all the retrieved PDN connections and the associated resources. Other implementation-specific actions may be performed. As a response, the PGW shall send a GTPv2 Delete PDN Connection Set Response message. On PMIPv6-based S5/S8 interface, the PGW shall send a PMIPv6 Binding Revocation Acknowledgment message with G bit set.

If the PGW supports the feature, the following procedures apply. During a S5/S8 procedure, impacting an existing PDN connection Removal or Modification the following apply:

1. If an SGW is being relocated then the PGW shall clear the currently stored MME and SGW FQ-CSID values.
2. If the SGW includes a SGW FQ-CSID in the S5/S8 Modify Bearer Request (Proxy Binding Update for PMIPv6), or Update PDN Connection Request message, then the PGW shall include PGW FQ-CSID in the S5/S8 Modify Bearer Response (Proxy Binding Acknowledgement for PMIPv6), or Update PDN Connection Response message.
3. If the new SGW does not include a SGW FQ-CSID in the S5/S8 Modify Bearer Request (Proxy Binding Update for PMIPv6), then the new SGW does not support the feature and the feature does not apply for this PDN connection. In such case, PGW shall not include PGW FQ-CSID in the S5/S8 Modify Bearer Response (Proxy Binding Acknowledgement for PMIPv6).
4. If the PGW receives an SGW FQ-CSID and/or an MME FQ-CSID value of a SGW over S5/S8 then the PGW shall overwrite the respective stored FQ-CSID value with the received value.
5. If the PGW receives an Update PDN Connection Request, a Modify Bearer Request or Proxy Binding Update with an SGW FQ-CSID but without an MME FQ-CSID then the PGW shall erase the MME FQ-CSID value (i.e. the current MME does not support the feature).
6. During a S5/S8 procedure removing an existing PDN connection the PGW simply removes the PDN data as well as any stored FQ-CSID values(s) of the MME and SGW or pointers to such data.

During an S2a/S2b procedure, impacting an existing PDN connection Removal or Modification the following apply:

1. If the PGW receives a TWAN or an ePDG FQ-CSID value then the PGW shall overwrite the respective stored FQ-CSID value with the received value;
2. During an S2a/S2b procedure removing an existing PDN connection, the PGW removes the corresponding PDN data as well as any stored FQ-CSID value of the TWAN or the ePDG FQ-CSID.