S-GW Restoration
Support

Feature
Description

S-GW Restoration
helps in handling the S-GW failure in the EPC network. It allows affected PDNs
that fail due to S-GW to be restored by selecting another S-GW to serve the
affected PDNs. This avoids unnecessary flooding of signaling for PDN cleanup.

The P-GW maintains
the sessions in case path failure is detected or if S-GW restart is detected
during recovery IE on GTP-C signaling. The P-GW will ensure that any dropped
packets in this scenario are not charged. The P-GW also rejects any bearer
additions or modification requests received for the PDN connection maintained
after the S-GW failure detection. This occurs until the PDN is restored.

Once the session has
been restored by the MME and the P-GW receives a Modify Bearer Request from the
restarted S-GW or a different S-GW, then the P-GW continues forwarding any
received downlink data and start charging them.

When a subscriber is
in S-GW restoration phase, all RARs (expect for Session Termination) reject the
PCEF. The P-GW rejects all internal updates which can trigger CCR-U towards the
PCRF. The P-GW triggers a CCR-U with AN-GW changes for the PDNs that are
restored if the S-GW has changed on restoration.

The MME/S4-SGSN is
locally configured to know that the P-GW in the same PLMN supports the S-GW
restoration feature. When this feature is enabled at the P-GW, it supports it
for all S-GWs/MMEs.

Important:

Only MME/S4-SGSN
triggered S-GW restoration procedure will be supported.

S-GW restoration
detection based on GTP-U path failure shall not be considered for this release.
GTP-C path failure detection should be enabled for enabling this feature.

S-GW restoration
detection based on GTP-U path failure shall not be considered for this release.
GTP-C path failure detection should be enabled for enabling this feature.

The P-GW Restart
Notification may also be used to signal that the peer P-GW has failed and not
restarted. In this case, the P-GW Restart Notification contains a cause value:
P-GW not responding. While sending the PRN, the S-GW includes the cause with
this new cause value depending on the echo response.

Relationships to
Other Features

How it Works

Changes at
P-GW

If a path failure is
detected at the Demux, then the path failure notification is sent to all
session managers at the P-GW. Next, the session manager cleans up the ongoing
transactions. Once all the transactions are deleted, the sessmgr-egtpc deletes
the tunnels by adding them into the pacing queue.

The P-GW will not
delete the session immediately after detecting path failure with the S-GW
restoration in place. The P-GW discards downlink packets received for a
maintained PDN connection and stop charging for maintained PDN connections
after an S-GW failure that has not been restored.

The MME/S4-SGSN
controls the pace of the S-GW relocations to avoid core network node overload.
The MME/S4-SGSN prioritizes the S-GW relocation for UEs engaged in a Service
Request for RAU/TAU procedures over UEs which are not engaged in any mobility
product procedure and do not have a signaling connection to MME/S4-SGSN.

If a session is
marked for S-GW restoration and if a new request results in context
replacement, then the existing session is aborted followed by a new request
indication event.

Changes at the
E-GTPC

When the Demux
informs the eGTP-C about the path failure, abort all active procedures. The
abort procedure indicates to the P-GW if S-GW restoration is enabled to for the
session. Add all the session in the queue and start the session hold timer for
S-GW. The MME restores these sessions by relocating sessions to the new or the
same S-GW. When the MBReq is received at the P-GW and if the session is marked
with S-GW restoration, then the S-GW flag is reset. At this point, the session
hold timer expires and S-GW restoration is removed.

Changes at the MME
and SGSN

When the MME and
SGSN detects path failure towards the S-GW and the MME supports S-GW
restoration, then MME relocates sessions from the failed S-GW to another S-GW.
Currently, S-GW restoration is not supported in MME and SGSN.

Demux Failure
Detection

The EGTPIN manager
detects a path failure and informs all session managers about the failure.
Then, the session manager gets the path failure notification and S-GW
restoration is enabled so it will stop all ongoing transactions. The
Sessmgr-egtpc informs the P-GW-drv about the path failure. The P-GW deletes the
session.

Next, the eGTP-C
starts the session hold timer. If the MME triggers the S-GW service restoration
before the session hold up timer, then sessions from the old S-GW will move to
the new S-GW. This ensures that no sessions are handed over and none are
deleted.

Once the session
hold timer expires, all the sessions with that peer are cleaned up. At this
point, new sessions are not moved to the new S-GW.

Important: If the S-GW goes down and comes back up in a very short
interval, then the P-GW will not detect the path failure. In this case, S-GW
restoration does not occur. If the old S-GW comes up again before the hold
timer expires, then there is a chance that only some partial sessions move to
the new S-GW. In this case, the eGTP-C does not need to delete the remaining
sessions with that peer. The eGTP-C will stop the timer.

If the session
manager detects the path failure, then it informs the Demux manager. The above,
scenario still occurs in this case.

After detecting the
path failure, the Demux will not send ECHO messages towards the S-GW. If the
new session addition occurs or a new session is restored from the node, then
the Demux sends the ECHO messages towards the peer.

Standards
Compliance

The S-GW Restoration
functionality complies with the following standards:

3GPP TS 23.007: Restoration procedures

3GPP TS 29.212:
Policy and Charging Control over Gx reference point

Configuring S-GW
Restoration Support

The session-hold
timer is a configurable parameter. The operator can configure this parameter
using the
egtpc sgw-restoration
session-hold timeout seconds CLI command.

When the P-GW
detects that the peer S-GW is down (detection is based on restart counter
change or PATH failure due to an ECHO response failure), it moves all PDN
sessions associated with the peer S-GW to the SGW-RESTORATION-STATE. Also the
P-GW starts a timer with the value provided for session-hold timeout per peer
S-GW. After timer expiry, the P-GW cleans up all the sessions which are in the
SGW-RESTORATION-STATE.

On S-GW failure
indication, the P-GW checks if the S-GW restoration feature is enabled or not.
If enabled, the P-GW maintains all the affected sessions for session-hold
timeout. After session-hold timeout, the P-GW clears all the sessions which are
not recovered yet.

Verifying the S-GW
Configuration

show pgw-service
all

To verify the S-GW
Restoration configuration, use the following command:

The following fields
have been added to display configuration information for S-GW restoration.

EGTP SGW Restoration Handling

Session Hold Timer

Timeout

Monitoring and
Troubleshooting S-GW Restoration Support

This section
includes show commands in support of the S-GW Restoration.