Cisco Cisco ASR 5000
Serving GPRS Support Node (SGSN) Overview
▀ Features and Functionality
▄ SGSN Administration Guide, StarOS Release 18
Procedure
Gn/Gp SGSN
S4-SGSN
Direct Tunnel (DT)
Activation
Activation
Configuration enabling DT is accomplished at
various levels - the Call Control Profile level,
the RNC level, and at the APN Profile level
for DT per APN/GGSN.
For a given UE, it is possible that one PDN
connection to an APN to a GGSN uses DT
while another PDN connection to a different
APN to a different GGSN does not use DT. It
all depends upon whether or not the target
GGSN supports DT.
various levels - the Call Control Profile level,
the RNC level, and at the APN Profile level
for DT per APN/GGSN.
For a given UE, it is possible that one PDN
connection to an APN to a GGSN uses DT
while another PDN connection to a different
APN to a different GGSN does not use DT. It
all depends upon whether or not the target
GGSN supports DT.
Configuration for DT is only available at Call
Control Profile and RNC levels as the S4-
SGSN’s DT is between an SGW and an RNC.
In an S4-SGSN, either all PDPs of a given UE
use DT or none of them use DT. So,
combinations of some PDPs using DT and some
PDPs not using DT is not possible.
Control Profile and RNC levels as the S4-
SGSN’s DT is between an SGW and an RNC.
In an S4-SGSN, either all PDPs of a given UE
use DT or none of them use DT. So,
combinations of some PDPs using DT and some
PDPs not using DT is not possible.
Handling Suspend from BSS
/ peer SGSN
/ peer SGSN
PDPs are suspended at SGSN. Any downlink
data received at this point will be queued by
the SGSN.
data received at this point will be queued by
the SGSN.
PDPs are suspended at SGSN. Downlink data
buffering happens at the PGW and not the
SGSN because the PDP suspension is carried
via a GTPv2 Suspend Notification message
from the SGSN to the SGW to the PGW.
buffering happens at the PGW and not the
SGSN because the PDP suspension is carried
via a GTPv2 Suspend Notification message
from the SGSN to the SGW to the PGW.
Session Recovery
Session recovery provides a seamless failover and reconstruction of subscriber session information in the event of a
hardware or software fault that prevents a fully attached user session from having the PDP contexts removed or the
attachments torn down.
hardware or software fault that prevents a fully attached user session from having the PDP contexts removed or the
attachments torn down.
Session recovery is performed by mirroring key software processes (e.g., session manager and AAA manager) within
the system. These mirrored processes remain in an idle state (in standby-mode) until they may be needed in the case of a
software failure (e.g., a session manager task aborts). The system spawns new instances of “standby mode” session and
AAA managers for each active control processor (CP) being used.
the system. These mirrored processes remain in an idle state (in standby-mode) until they may be needed in the case of a
software failure (e.g., a session manager task aborts). The system spawns new instances of “standby mode” session and
AAA managers for each active control processor (CP) being used.
As well, other key system-level software tasks, such as VPN manager, are performed on a physically separate packet
processing card to ensure that a double software fault (e.g., session manager and VPN manager fail at the same time on
the same card) cannot occur. The packet processing card used to host the VPN manager process is in active mode and is
reserved by the operating system for this sole use when session recovery is enabled.
processing card to ensure that a double software fault (e.g., session manager and VPN manager fail at the same time on
the same card) cannot occur. The packet processing card used to host the VPN manager process is in active mode and is
reserved by the operating system for this sole use when session recovery is enabled.
The additional hardware resources required for session recovery include a standby System Management Card and a
standby packet processing card.
standby packet processing card.
There are two modes for Session Recovery.
Task recovery mode: One or more session manager failures occur and are recovered without the need to use
resources on a standby packet processor card. In this mode, recovery is performed by using the mirrored
“standby-mode” session manager task(s) running on active packet processor cards. The “standby-mode” task is
renamed, made active, and is then populated using information from other tasks such as AAA manager.
“standby-mode” session manager task(s) running on active packet processor cards. The “standby-mode” task is
renamed, made active, and is then populated using information from other tasks such as AAA manager.
Full packet processing card recovery mode: Used when a packet processing card hardware failure occurs, or
when a packet processor card migration failure happens. In this mode, the standby packet processor card is
made active and the “standby-mode” session manager and AAA manager tasks on the newly activated packet
processor card perform session recovery.
made active and the “standby-mode” session manager and AAA manager tasks on the newly activated packet
processor card perform session recovery.
Session/Call state information is saved in the peer AAA manager task because each AAA manager and session manager
task is paired together. These pairs are started on physically different packet processor cards to ensure task recovery.
task is paired together. These pairs are started on physically different packet processor cards to ensure task recovery.
When session recovery occurs, the system reconstructs the following subscriber information:
Data and control state information required to maintain correct call behavior