Cisco Cisco ASR 5000
Serving GPRS Support Node (SGSN) Overview
▀ Features and Functionality
▄ SGSN Administration Guide, StarOS Release 18
Important:
The S4-SGSN currently does not support the association of a different EGTP service for each
PLMN.
2G and 3G Inter-SGSN and Inter SGSN-MME RAU with and without S-GW Relocation Across S16
and S3 Interfaces
The S4-SGSN supports both Inter-SGSN RAU and SGSN-MME RAU, which will be triggered when a UE sends
Routing Area Update (RAU) request to a new SGSN in the following scenarios:
Routing Area Update (RAU) request to a new SGSN in the following scenarios:
The serving RAI changes from one SGSN coverage area to another SGSN coverage area
During a handover from a E-UTRAN coverage area to a UMTS coverage area
Intra-SGSN Inter-RAT RAU with and without S-GW Relocation
The S4-SGSN supports intra-SGSN 3G to 2G routing area updates (RAU) and supports the handover of MM and PDP
contexts from the SGSN service to the GPRS service. Similarly, it supports intra-SGSN 2G to 3G RAUs and supports
the handover of MM and PDP contexts from the GPRS service to the SGSN service.
contexts from the SGSN service to the GPRS service. Similarly, it supports intra-SGSN 2G to 3G RAUs and supports
the handover of MM and PDP contexts from the GPRS service to the SGSN service.
Important:
Currently, the S4-SGSN expects that both the SGSN and GPRS services will be associated with the
same EGTP service for successful intra-SGSN inter-RAT handovers.
IPv4 and IPv6 PDP Type Override
The S4-SGSN supports the override of the IPv4/IPv6 PDP type by either IPv4 or IPv6 when the dual PDP feature is
enabled. This is controlled via a call control profile, and is configured independently for 2G GPRS and 3G UMTS
access.
enabled. This is controlled via a call control profile, and is configured independently for 2G GPRS and 3G UMTS
access.
Statistics are maintained to track successes and failures for IPv4 and IPv6 PDP activations with override.
NAPTR-based Dynamic HSS Discovery
In releases prior to R15.0, the SGSN could contact a HSS only through static configuration of the HSS peer end point
through the HSS service. From Release R15.0 onwards, dynamic peer discovery is supported. The HSS address will be
resolved using NAPTR based DNS request-response method. The following commands have to be enabled for dynamic
peer discovery:
through the HSS service. From Release R15.0 onwards, dynamic peer discovery is supported. The HSS address will be
resolved using NAPTR based DNS request-response method. The following commands have to be enabled for dynamic
peer discovery:
In the Context Configuration Mode, the command
diameter endpoint < endpoint_name >
has to be
enabled.
In the Diameter Endpoint Configuration Mode, the command
dynamic-peer-discovery [ protocol {
sctp | tcp } ]
has to be enabled.
In the Diameter Endpoint Configuration Mode, the command
dynamic-peer-realm < realm_name >
has to
be enabled.
In the Diameter Endpoint Configuration Mode, the command
dynamic-peer-failure-retry-count <
no_of_retries >
has to be enabled.
The “realm name” is used for dynamic peer discovery. The “dynamic-peer-failure-retry-count” is used to configure the
number of re-tries in peer discovery.
number of re-tries in peer discovery.