Features and Functionality
It is impossible
to list all of the features supported by the ASR 5000 2.5G and/or
3G SGSN.
Those features listed
below are only a few of the features that enable the operator to
control the SGSN and their network. All of these features are either
proprietary or comply with relevant 3GPP specifications.
Some of the proprietary
features may require a separate license. Contact your Cisco account representative
for detailed information on specific licensing requirements. For
information on installing and verifying licenses, refer to the Managing License Keys section
of the Software Management
Operations chapter in the System
Administration Guide.
The following is an
alphabetical list of the features described in this overview:
APN Aliasing
In many situations,
the APN provided in the Activation Request is unacceptable – perhaps
it does not match with any of the subscribed APNs or it is misspelled – and
would result in the SGSN rejecting the Activation Request. The APN
Aliasing feature enables the operator to override an incoming APN – specified
by a subscriber or provided during the APN selection procedure (TS
23.060) – or replace a missing APN with an operator-preferred
APN.
The APN Aliasing feature
provides a set of override functions: Default APN, Blank APN, APN
Remapping, and Wildcard APN to facilitate such actions as:
- overriding a mismatched
APN with a default APN.
- overriding a missing
APN (blank APN) with a default or preferred APN.
- overriding an APN on
the basis of charging characteristics.
- overriding an APN by
replacing part or all of the network or operator identifier with information
defined by the operator, for example, MNC123.MCC456.GPRS could be
replaced by MNC222.MCC333.GPRS.
- overriding an APN for
specific subscribers (based on IMSI) or for specific devices (based
on IMEI).
Default APN
Operators can configure
a “default APN” for subscribers not provisioned
in the HLR. The default APN feature will be used in error situations
when the SGSN cannot select a valid APN via the normal APN selection
process. Within an APN remap table, a default APN can be configured
for the SGSN to:
- override a requested
APN when the HLR does not have the requested APN in the subscription
profile.
- provide a viable APN
if APN selection fails because there was no “requested
APN” and wildcard subscription was not an option.
In either of these
instances, the SGSN can provide the default APN as an alternate
behavior to ensure that PDP context activation is successful.
Recently, the SGSN’s
default APN functionality was enhanced so that if a required subscription
APN is not present in the subscriber profile, then the SGSN will
now continue the activation with another configured 'dummy' APN.
The call will be redirected, via the GGSN, to a webpage informing
the user of the error and prompting to subscribe for services.
Refer to the APN Remap Table Configuration
Mode in the Command
Line Interface Reference for the command to configure this feature.
APN Resolution with
SCHAR or RNC-ID
It is now possible
to append charging characteristic information to the DNS string.
The SGSN includes the profile index value portion of the CC as binary/decimal/hexadecimal
digits (type based on the configuration) after the APN network identification.
The charging characteristic value is taken from the subscription
record selected for the subscriber during APN selection. This enables
the SGSN to select a GGSN based on the charging characteristics
information.
After appending the
charging characteristic the DNS string will take the following form: <apn_network_id>.<profile_index>.<apn_operator_id >
.
The profile index in the following example has a value 10: quicknet.com.uk.1010.mnc234.mcc027.gprs
.
If the RNC_ID
information is configured to be a part of the APN name, and if inclusion
of the profile index of the charging characteristics information
is enabled before the DNS query is sent, then the profile index
is included after the included RNC_ID and the DNS APN name
will appear in the following form: <apn_network_id>.<rnc_id>.<profile_index>.<apn_operator_id>.
In
the following example, the DNS query for a subscriber using RNC
0321 with the profile index of value 8 would appear as: quicknet.com.uk.0321.1000.mnc234.mcc027.gprs.
Automatic Protection
Switching (APS)
Automatic protection
switching (APS is now available on an inter-card basis for SONET configured
CLC2 (Frame Relay) and OLC2 (ATM) optical line cards. Multiple switching
protection (MSP) version of is also available for SDH configured
for the CLC2 and OLC2 (ATM) line cards.
APS/MSP offers
superior redundancy for SONET/SDH equipment and supports
recovery from card failures and fiber cuts. APS allows an operator
to configure a pair of SONET/SDH lines for line redundancy.
In the event of a line problem, the active line switches automatically
to the standby line within 60 milliseconds (10 millisecond initiation
and 50 millisecond switchover).
At this time, the ASR
5000 APS/MSP supports the following parameters:
- 1+1 - Each
redundant line pair consists of a working line and a protection line.
- uni-directional - Protection
on one end of the connection.
- non-revertive - Upon
restoration of service, this parameter prevents the network from automatically
reverting to the original working line.
The protection mechanism
used for the APS/MSP uses a linear 1+1 architecture,
as described in the ITU-T G.841 standard and the Bellcore publication
GR-253-CORE, SONET Transport Systems; Common Generic Criteria, Section
5.3. The connection is unidirectional.
With APS/MSP
1+1, each redundant line pair consists of a working line
and a protection line. Once a signal fail condition or a signal
degrade condition is detected, the hardware switches from the working
line to the protection line.
With the non-revertive
option, if a signal fail condition is detected, the hardware switches
to the protection line and does not automatically revert back to
the working line.
Since traffic is carried
simultaneously by the working and protection lines, the receiver
that terminates the APS/MSP 1+1 must select cells
from either line and continue to forward one consistent traffic
stream. The receiving ends can switch from working to protection
line without coordinating at the transmit end since both lines transmit
the same information.
Refer to the section
on Configuring APS/MSP
Redundancy in the SGSN
Service Configuration Procedures chapter for configuration details.
Authentications and
Reallocations -- Selective
Subscriber event
authentication, P-TMSI reallocation, and P-TMSI signature reallocation
are now selective rather than enabled by default.
The operator can enable
and configure them to occur according to network requirements:
- every instance or every
nth instance;
- on the basis of UMTS,
GPRS or both;
- on the basis of elapsed
time intervals between events.
There are situations
in which authentication will be performed unconditionally:
- IMSI Attach – all
IMSI attaches will be authenticated
- When the subscriber
has not been authenticated before and the SGSN does not have a vector
- When there is a P-TMSI
signature mismatch
- When there is a CKSN
mismatch
There are situation
in which P-TMSI will be reallocated unconditionally:
- Inter SGSN Attach/RAU
- Inter-RAT Attach/RAU
in 2G
- IMSI Attach
Avoiding PDP Context
Deactivations
The SGSN can
be configured to avoid increased network traffic resulting from
bursts of service deactivations/activations resulting from
erroneous restart counter change values in received messages (Create
PDP Context Response or Update PDP Context Response or Update PDP
Context Request). Be default, the SGSN has the responsibility to
verify possible GTP-C path failure by issuing an Echo Request/Echo
Response to the GGSN. Path failure will only be confirmed if the
Echo Response contains a new restart counter value. Only after this
confirmation of the path failure does the SGSN begin deactivation
of PDP contexts.
Bulk Statistics Support
System support
for bulk statistics allows operators to choose which statistics
to view and to configure the format in which the statistics are
presented. This simplifies the post-processing of statistical data
since it can be formatted to be parsed by external, back-end processors.
When used in conjunction
with the Web Element Manager, the data can be parsed, archived,
and graphed.
The system can be
configured to collect bulk statistics (performance data) and send
them to a collection server (called a receiver). Bulk statistics
are statistics that are collected in a group. The individual statistics
are grouped by schema. The following is the list of schemas supported
for use by the SGSN:
-
System: Provides
system-level statistics
-
Card: Provides card-level
statistics
-
Port: Provides port-level
statistics
-
DLCI-Util: Provides
statistics specific to DLCIs utilization for CLC-type line cards
-
GPRS: Provides statistics
for LLC, BSSGP, SNDCP, and NS layers
-
SCCP: Provides SCCP
network layer statistics
-
SGTP: Provides SGSN-specific
GPRS Tunneling Protocol (GTP) statistics
-
SGSN: Provides statistics
for: mobility management (MM) and session management (SM) procedures;
as well, MAP, TCAP, and SMS counters are captured in this schema.
SGSN Schema statistic availability is per service (one of: SGSN,
GPRS, MAP) and per routing area (RA)
-
SS7Link: Provides
SS7 link and linkset statistics
-
SS7RD: Provides
statistics specific to the proprietary SS7 routing domains
The system supports
the configuration of up to 4 sets (primary/secondary) of
receivers. Each set can be configured with to collect specific sets
of statistics from the various schemas. Statistics can be pulled
manually from the chassis or sent at configured intervals. The bulk
statistics are stored on the receiver(s) in files.
The format of the bulk
statistic data files can be configured by the user. Users can specify
the format of the file name, file headers, and/or footers
to include information such as the date, chassis host name, chassis
uptime, the IP address of the system generating the statistics (available for
only for headers and footers), and/or the time that the
file was generated.
When the Web Element
Manager is used as the receiver, it is capable of further processing the
statistics data through XML parsing, archiving, and graphing.
The Bulk Statistics
Server component of the Web Element Manager parses collected statistics
and stores the information in the PostgreSQL database. If XML file
generation and transfer is required, this element generates the
XML output and can send it to a Northbound NMS or an alternate bulk
statistics server for further processing.
Additionally, if archiving
of the collected statistics is desired, the Bulk Statistics server writes
the files to an alternative directory on the server. A specific
directory can be configured by the administrative user or the default
directory can be used. Regardless, the directory can be on a local
file system or on an NFS-mounted file system on the Web Element
Manager server.
CAMEL Service Phase
3, Ge Interface
The ASR 5000
SGSN provides PDP session support as defined by Customized Applications for
Mobile network Enhanced Logic (CAMEL) phase 3.
CAMEL Service
CAMEL service
enables operators of 2.5G/3G networks to provide operator-specific
services (such as prepaid GPRS service and prepaid SMS service)
to subscribers, even when the subscribers are roaming outside their
HPLMN.
CAMEL Support
ASR 5000 SGSN
support for CAMEL phase 3 services expands with each SGSN application release.
Current support enables operators of 2.5G/3G networks to
provide operator-specific services (such as prepaid GPRS service
and prepaid SMS service) to subscribers, even when the subscribers
are roaming outside their HPLMN.
For this release the
SGSN has expanded its support for CAMEL Scenario 1 adding:
- Implementation of Scenario1
triggers (TDP-Attach, TDP-Attach-ChangeofPosition)
- Implementation of Scenario1
Dynamic triggers (DP-Detach, DP-ChangeofPosition)
- Expanded conformance
to 3GPP spec 23.078 (Release 4)
The ASR 5000 SGSN supports
the following GPRS-related functionality in CAMEL phase 3:
- Control of GPRS PDP
contexts
Functional support
for CAMEL interaction includes:
- PDP Context procedures
per 3GPP TS 29.002
- GPRS TDP (trigger detection
point) functions
- Default handling codes,
if no response received from SCP
- GPRS EDP (event detection
points) associated with SCP
- Charging Procedures:
Handle Apply Charging GPRS & Handle Apply Charging Report GPRS
- “GPRS Dialogue
scenario 2" for CAMEL control with SCP
- CAMEL-related data
items in an S-CDR:
- SCF Address
- Service Key
- Default Transaction
Handling
- Level of CAMEL service
(phase 3)
- Session Recovery for
all calls have an ESTABLISHED CAMEL association.
Ge Interface
The ASR 5000 implementation
of CAMEL uses standard CAP protocol over a Ge interface between
the SGSN and the SCP. This interface can be deployed over SS7 or
SIGTAN.
The SGSN's Ge support
includes use of the gprsSSF CAMEL component with the SGSN and the
gsmSCF component with the SCP.
CAMEL Configuration
To provide the CAMEL
interface on the SGSN, a new service configuration mode, called “CAMEL
Service”, has been introduced on the SGSN.
- An SCCP Network configuration
must be created or exist already.
- A CAMEL Service instance
must be created.
- The CAMEL Service instance
must be associated with either the SGSN Service configuration or
the GPRS Service configuration in order to enable use of the CAMEL interface.
- The CAMEL Service must
be associated with the SCCP Network configuration.
Until a CAMEL Service
is properly configured, the SGSN will not process any TDP for pdp-context
or mo-sms.
For
configuration details, refer to the Serving GPRS Support
Node Administration Guide and the Command Line Interface Reference.
Configurable RAB
Asymmetry Indicator in RAB Assignment Request
The SGSN sets
the value for the RAB Asymmetry Indicator that isincluded in the
RAB Assignment Request.
In releases prior
to R12.0, the SGSN set the RAB asymmetry indicator to "Symmetric-Bidirectional"
when downlink and uplink bit rates were equal. Now, the SGSN selects
the value based on the symmetry of negotiated maximum bitrates as
follows:
- If the uplink and
downlink bitrates are equal then it is set to “Symmetric-Bidirectional”,
- If uplink bitrate
is set to 0 kbps, then it is set to “Asymmetric-Unidirectional-Downlink”,
- If downlink bitrate
is set to 0 kbps, then it is set to “Asymmetric-Unidirectional-Uplink”,
- If the uplink and
downlink bitrates are non-zero and different, then it is set to “Asymmetric-Bidirectional”.
A change in CLI configuration
allows the SGSN to override the above functionality and set the
RAB Asymmetry Indicator to “Asymmetric-Bidirectional” when
uplink and downlink bitrates are equal. As a result, two sets of
bitrates - one for downlink and one for uplink - will be included in
the RAB Assignment Requests as mandated in 3GPP TS 25.413.
Direct Tunnel
In accordance
with standards, one tunnel functionality enables the SGSN to establish
a direct tunnel at the user plane level - a GTP-U tunnel, directly
between the RAN and the GGSN. Feature details and configuration
procedures are provided in the Direct Tunnel feature
chapter in this guide.
DSCP Templates for
Control and Data Packets - Iu or Gb over IP
The SGSN supports
a mechanism for differentiated services code point (DSCP) marking
of control packets and signaling messages for the SGSN’s LLC messages for the Gb interface.
This DSCP marking feature
enables the SGSN to perform classifying and managing of network
traffic and to determine quality of service (QoS) for the interfaces
to an IP network.
ECMP over ATM
Iu Redundancy
is the ASR 5000's implementation of equal-cost multi-path routing
(ECMP) over ATM.
Iu Redundancy is based
on the standard ECMP multi-path principle of providing multiple
next-hop-routes of equal cost to a single destination for packet
transmission. ECMP works with most routing protocols and can provide
increased bandwidth when traffic load-balancing is implemented over
multiple paths.
ECMP over ATM will
create an ATM ECMP group when multiple routes with different destination
ATM interfaces are defined for the same destination IP address.
When transmitting a packet with ECMP, the NPU performs a hash on
the packet header being transmitted and uses the result of the hash
to index into a table of next hops. The NPU looks up the ARP index
in the ARP table (the ARP table contains the next-hop and egress
interfaces) to determine the next-hop and interface for sending
packets.
Equivalent PLMN
This feature
is useful when an operator deploys both GPRS and UMTS access in
the same radio area and each radio system broadcasts different PLMN
codes. It is also useful when operators have different PLMN codes
in different geographical areas, and the operators’ networks
in the various geographical areas need to be treated as a single
HPLMN.
This feature allows
the operator to consider multiple PLMN codes for a single subscriber
belonging to a single home PLMN (HPLMN). This feature also allows operators
to share infrastructure and it enables a UE with a subscription
with one operator to access the network of another operator.
First Vector Configurable
Start for MS Authentication
Previously, the
SGSN would begin authentication towards the MS only after the SGSN
received all requested vectors. This could result in a radio network
traffic problem when the end devices timed out and needed to re-send
attach requests.
Now, the SGSN can be
configured to start MS authentication as soon as it receives the
first vector from the AuC/HLR while the SAI continues in
parallel. After an initial attach request, some end devices restart
themselves after waiting for the PDP to be established. In such
cases, the SGSN restarts and a large number of end devices repeat
their attempts to attach. The attach requests flood the radio network,
and if the devices timeout before the PDP is established then they
continue to retry, thus even more traffic is generated. This feature reduces
the time needed to retrieve vectors over the GR interface to avoid
the high traffic levels during PDP establishment and to facilitate
increased attach rates.
GMM-SM Event Logging
To facilitate
troubleshooting, the SGSN will capture procedure-level information
per 2G or 3G subscriber (IMSI-based) in CSV formatted event data
records (EDRs) that are stored on an external server.
This feature logs the
following events:
- Attaches
- Activation of PDP Context
- RAU
- ISRAU
- Deactivation of PDP
Context
- Detaches
- Authentications
- PDP Modifications
The new SGSN event logging
feature is enabled/disabled per service with via the CLI commands.
For more information on this feature, refer to the chapter GMM/SM Event Logging in
this guide.
Gn/Gp Delay
Monitoring
The SGSN measures
the control plane packet delay for GTP-C signaling messages on the SGSN’s
Gn/Gp interface towards the GGSN.
If the delay crosses
a configurable threshold, an alarm will be generated to prompt the
operator.
A delay trap is generated
when the GGSN response to an ECHO message request is delayed more
than a configured amount of time and for a configured number of
consecutive responses. When this occurs, the GGSN will be flagged
as experiencing delay.
A clear delay trap
is generated when successive ECHO Response (number of successive responses
to detect a delay clearance is configurable), are received from
a GGSN previously flagged as experiencing delay.
This functionality
can assist with network maintenance, troubleshooting, and early
fault discovery.
GTP-C Path Failure
Detection and Management
The SGSN now
provides the ability to manage GTP-C path failures detected as a
result of spurious restart counter change messages received from
the GGSN.
Previous Behavior: The
old default behavior was to have the Session Manager (SessMgr) detect
GTP-C path failure based upon receiving restart counter changes
in messages (Create PDP Context Response or Update PDP Context Response
or Update PDP Context Request) from the GGSN and immediately inform
the SGTPC Manager (SGTPCMgr) to pass the path failure detection
to all other SessMgrs so that PDP deactivation would begin.
New Behavior: The
new default behavior has the SessMgr inform the SGTPCMgr of the
changed restart counter value. The SGTPCMgr now has the responsibility
to verify a possible GTP-C path failure by issuing an Echo Request/Echo
Response to the GGSN. Path failure will only be confirmed if the
Echo Response contains a new restart counter value. Only after this
confirmation of the path failure does the SGTPCMgr inform all SessMgrs
so that deactivation of PDP contexts begins.
Handling Multiple
MS Attaches All with the Same Random TLLI
Some machine-to-machine
(M2M) devices from the same manufacturer will all attempt PS Attaches
using the same fixed random Temporary Logical Link Identifier (TLLI).
The SGSN cannot distinguish
between multiple M2M devices trying to attach simultaneously using
the same random TLLI and routing area ID (RAI). As a result, during
the attach process of an M2M device, if a second device tries to
attach with the same random TLLI, the SGSN interprets that as an
indication that the original subscriber moved during the Attach
process and the SGSN starts communicating with the second device
and drops the first device.
The SGSN can be configured
to allow only one subscriber at a time to attach using a fixed random
TLLI. While an Attach procedure with a fixed random TLLI is ongoing
(that is, until a new P-TMSI is accepted by the MS), all other attaches
sent to the SGSN with the same random TLLI using a different IMSI
will be dropped by the SGSN’s Linkmgr.
To limit the wait-time
functionality to only the fixed random TLLI subscribers, the TLLI
list can be configured to control which subscribers will be provided
this functionality.
HSPA Fallback
Besides enabling
configurable support for either 3GPP Release 6 (HSPA) and 3GPP Release 7
(HSPA+) to match whatever the RNCs support, this feature
enables configurable control of data rates on a per RNC basis. This
means that operators can allow subscribers to roam in and out of
coverages areas with different QoS levels.
The SGSN can now limit
data rates (via QoS) on a per-RNC basis. Some RNCs support HSPA
rates (up to 16 Mbps in the downlink and 8 Mbps in the uplink) and cannot
support higher data rates - such as those enabled by HSPA+ (theoretically,
up to 256 Mbps both downlink and uplink). Being able to specify
the QoS individually for each RNC makes it possible for operators
to allow their subscribers to move in-and-out of coverage areas
with different QoS levels, such as those based on 3GPP Release 6
(HSPA) and 3GPP Release 7 (HSPA+).
For example, when a
PDP context established from an RNC with 21 Mbps is handed off to an
RNC supporting only 16 Mbps, the end-to-end QoS will be re-negotiated
to 16 Mbps. Note that an MS/UE may choose to drop the PDP
context during the QoS renegotiation to a lower value.
This data rate management
per RNC functionality is enabled, in the radio network controller (RNC)
configuration mode, by specifying the type of 3GPP release specific
compliance, either release 7 for HSPA+ rates or pre-release
7 for HSPA rates.
For
configuration details, refer to the RNC Configuration Mode chapter
in the Command Line Interface Reference.
Ignore Context-ID
During 4G/3G Handovers
HSS and HLR, when operating
as separate network nodes, are required to use the same context-ID
for a given APN-configuration of a subscriber. During inter-RAT
cell reselections and handovers between 2G/3G and 4G, if
the SGSN does not find a matching APN-configuration for the given
context-ID learnt from the the peer node, then the PDP does not
get established. This could result in SRNS relocation failures when
none of the PDP's learnt from theSGSN has a matching context-ID
in the HLR.
New commands have been
added to enable the operator to configure the SGSN to ignore the context-ID
provided by the peer and to use the PDP- type and address information
to search through HLR subscription and to update the context-ID
information within the PDP. For details, refer to the description
for the rau-inter command
under the Call-Control
Profile Configuration Mode Commands section of the Cisco ASR
5x00 GPRS / UMTS Command Line Interface Reference.
Intra- or Inter-SGSN
Serving Radio Network Subsystem (SRNS) Relocation (3G only)
Implemented
according to 3GPP standard, the SGSN supports both inter- and intra-SGSN RNS
relocation (SRNS) to enable handover of an MS from one RNC to another
RNC.
The relocation feature
is triggered by subscribers (MS/UE) moving from one RNS
to another. If the originating RNS and destination RNS are connected
to the same SGSN but are in different routing areas, the behavior
triggers an intra-SGSN Routing Area Update (RAU). If the RNS are
connected to different SGSNs, the relocation is followed by an inter-SGSN
RAU. This feature is configured through the Call-Control Profile
Configuration Mode which is part of the feature set.
Lawful Intercept
The Cisco Lawful
Intercept feature is supported on the SGSN. Lawful Intercept is
a license-enabled, standards-based feature that provides telecommunications
service providers with a mechanism to assist law enforcement agencies
in monitoring suspicious individuals for potential illegal activity.
For additional information and documentation on the Lawful Intercept
feature, contact your Cisco account representative.
Link Aggregation
- Horizontal
The SGSN supports
enhanced link aggregation (LAG) within ports on different XGLCs. Ports
can be from multiple XGLCs. LAG works by exchanging control packets
(Link Aggregation Control Marker Protocol) over configured physical
ports with peers to reach agreement on an aggregation of links. LAG
sends and receives the control packets directly on physical ports
attached to different XGLCs. The link aggregation feature provides
higher aggregated bandwidth, auto-negotiation, and recovery when
a member port link goes down.
Local DNS
Previously,
the SGSN supported GGSN selection for an APN only through operator
policy, and supported a single pool of up to 16 GGSN addresses which
were selected in round robin fashion.
The SGSN now supports
configuration of multiple pools of GGSNs; a primary pool and a secondary.
As part of DNS resolution, the operator can use operator policies to
prioritize local GGSNs versus remote ones. This function is built
upon existing load balancing algorithms in which weight and priority
are configured per GGSN, with the primary GGSN pool used first and
the secondary used if no primary GGSNs are available.
The SGSN first selects
a primary pool and then GGSNs within that primary pool; employing a
round robin mechanism for selection. If none of the GGSNs in a pool
are available for activation, then the SGSN proceeds with activation
selecting a GGSN from a secondary pool on the basis of assigned
weight. A GGSN is considered unavailable when it does not respond
to GTP Requests after a configurable number of retries over a configurable
time period. Path failure is detected via GTP-echo.
Local Mapping of
MBR
The SGSN provides
the ability to map a maximum bit rate (MBR) value (provided by the HLR)
to an HSPA MBR value.
The mapped value is
selected based on the matching MBR value obtained from the HLR subscription.
QoS negotiation then occurs based on the converted value.
This feature is available
within the operator policy framework. MBR mapping is configured via
new keywords added to the qos class command
in the APN Profile configuration mode. A maximum of four values
can be mapped per QoS per APN.
IMPORTANT:
To enable this feature
the qos prefer-as-cap,
also a command in the APN Profile configuration mode, must be set
to either both-hlr-and-local or
to hlr subscription.
Local QoS Capping
The operator
can configure a cap or limit for the QoS bit rate.
The SGSN can now be
configured to cap the QoS bit rate parameter when the subscribed
QoS provided by the HLR is lower than the locally configured value.
Depending upon the
keywords included in the command, the SGSN can:
- take the QoS parameter
configuration from the HLR configuration.
- take the QoS parameter
configuration from the local settings for use in the APN profile.
- during session establishment,
apply the lower of either the HLR subscription or the locally configured
values.
Refer
to the APN Profile Configuration
Mode chapter of the Command
Line Interface Reference for the qos command.
Management System
Overview
The system's
management capabilities are designed around the Telecommunications
Management Network (TMN) model for management - focusing on providing
superior quality network element (NE) and element management system
(Web Element Manager) functions. The system provides element management
applications that can easily be integrated, using standards-based
protocols (CORBA and SNMPv1, v2), into higher-level management systems
- giving wireless operators the ability to integrate the system
into their overall network, service, and business management systems.
In addition, all management is performed out-of-band for security
and to maintain system performance.
The Operation and Maintenance
module of the system offers comprehensive management capabilities
to the operators and enables them to operate the system more efficiently.
There are multiple ways to manage the system either locally or remotely
using its out-of-band management interfaces.
These include:
- Using the command line
interface (CLI)
- Remote login using Telnet,
and Secure Shell (SSH) access to CLI through SPIO card's Ethernet
management interfaces
- Local login through
the Console port on SPIO card using an RS-232 serial connection
- Using the Web Element
Manager (WEM) application (requires a separate license)
- Supports communications
through 10 Base-T, 100 Base-TX, 1000 Base-TX, or 1000
- Base-SX (optical gigabit
Ethernet) Ethernet management interfaces on the SPIO
- Client-Server model
supports any browser (i.e. Microsoft Internet Explorer v5.0 and
above or Netscape v4.7 or above, and others)
- Supports Common Object
Request Broker Architecture (CORBA) protocol and Simple Network
Management Protocol version 1 (SNMPv1) for fault management
- Provides complete Fault,
Configuration, Accounting, Performance, and Security (FCAPS) capabilities
- Can be easily integrated
with higher-level network, service, and business layer applications using
the Object Management Group's (OMG’s) Interface Definition
Language (IDL)
The following figure
demonstrates these various element management options and how they can
be utilized within the wireless carrier network.
Figure 4. Element Management
Methods
IMPORTANT:
By default, SGSN management
functionality is enabled for console-based access.
For more information
on command line interface based management, refer to the Command Line Interface
Reference.
Multiple PLMN Support
With this feature,
the 2.5G and 3G SGSNs now support more than one PLMN ID per SGSN. Multiple
PLMN support facilitates MS handover from one PLMN to another PLMN.
Multiple PLMN support
also means an operator can 'hire out' their infrastructure to other
operators who may wish to use their own PLMN IDs. As well, multiple PLMN
support enables an operator to assign more than one PLMN ID to a
cell-site or an operator can assign each cell-site a single PLMN
ID in a multi-cell network (typically, there are no more than 3
or 4 PLMN IDs in a single network).
This feature is enabled
by configuring, within a single context, multiple instances of either an
IuPS service for a single 3G SGSN service or multiple GPRS services
for a 2.G SGSN. Each IuPS service or GPRS service is configured
with a unique PLMN ID. Each of the SGSN and/or GPRS services
must use the same MAP, SGTPU and GS services so these only need
to be defined one-time per context.
Network Sharing
In accordance
with 3GPP TS 23.251, the SGSN provides an operator the ability to
share the RAN and/or the core network with other operators.
Depending upon the resources to be shared, there are 2 network sharing
modes of operation: the Gateway Core Network (GWCN) and the Multi-Operator
Core Network (MOCN).
Benefits of Network
Sharing
Network sharing provides
operators with a range of logistical and operational benefits:
- Enables two or more
network operators to share expensive common network infrastructure.
- A single operator with
multiple MCC-MNC Ids can utilize a single physical access infrastructure
and provide a single HPLMN view to the UEs.
- Facilitates implementation
of MVNOs.
GWCN Configuration
With a gateway
core network configuration, the complete radio access network and
part of the core network are shared (for example, MSC/SGSN)
among different operators, while each operator maintains its own
separate network nodes (for example, GGSN/HLR).
Figure 5. GWCN-type Network Sharing
With the GWCN configuration,
the SGSN supports two scenarios:
- GWCN with non-supporting
UE
- GWCN with supporting
UE
MOCN Configuration
In the multi-operator
core network configuration, the complete radio network is shared among
different operators, while each operators maintains its own separate
core network.
Figure 6. MOCN-type Network Sharing
With the MOCN configuration,
the SGSN supports the following scenarios:
- MOCN with non-supporting
UE
- MOCN with supporting
UE
Implementation
To facilitate network
sharing, the SGSN implements the following key features:
- Multiple virtual SGSN
services in a single physical node.
- Sharing operators can
implement independent policies, such as roaming agreements.
- Equivalent PLMN configuration.
- RNC identity configuration
allows RNC-ID + MCC-MNC instead of just RNC-ID.
Configuration for network
sharing is accomplished by defining:
- NRI in the SGSN service
configuration mode
- PLMN IDs and RNC IDs
in the IuPS configuration mode
- Equivalent PLMN IDs
and configured in the Call-Control Profile configuration mode.
- IMSI ranges are defined
in the SGSN-Global configuration mode
- The Call-Control Profile
and IMSI ranges are associated in the configuration mode.
For commands and information
on network sharing configuration, refer to the Service Configuration
Procedures section in the Serving
GPRS Support Node Administration Guide and the command details
in the Command Line Interface Reference.
NPU FastPath
NPU FastPath’s
proprietary internal direct tunnel optimizes resource usage and
reduces latency when processing GTP-U packets. This proprietary
feature is only available on the ASR 5000 SGSN.
Incoming traffic passes
through the switch fabric and the routing headers are changed to
re-route traffic from the incoming network processing unit (NPU)
of the ingress packet processing card directly to the outgoing NPU
of the egress packet processing card. This means that intervening
NPUs and CPUs are by-passed. This provides the SGSN with router-like
latency and increased node signaling capacity.
Figure 7. SGSN NPU FastPath
FastPath is established
when both ends of a tunnel are available. Two FastPath flows are established,
one for the uplink and one for the downlink direction for a given
PDP context. FastPath will temporarily go down or be disengaged
so that packets temporarily do not move through FastPath when either
an Intra-SGSN RAU or an Iu-Connection Release occurs.
If FastPath cannot
be established, the NPU forwards the GTP-U packets to a CPU for processing
and they are processed like all other packets.
FastPath can not be
established for subscriber PDP sessions if:
- Traffic Policing and
Shaping is enabled.
- Subscriber Monitoring
is enabled.
- Lawful Intercept (LI)
is enabled,
- IP Source Violation
Checks are enabled.
- GTP-v0 tunnel is established
with an GGSN.
For NPU fast path configuration,
refer to Enabling NPU Fast Path for GTP-U Processing section of “Service
Configuration Procedures” chapter of Cisco ASR 5000 Series
Serving GPRS Support Node Administration Guide.
NRPCA - 3G
The SGSN supports
the Network Requested Primary PDP Context Activation (NRPCA) procedure
for 3G attachments.
There are no interface
changes to support this feature. Support is configured with existing
CLI commands (network-initiated-pdp-activation, location-area-list)
in the call control profile configuration mode and timers (
T3385-timeout
and
max-actv-retransmission
)
are set in the SGSN service configuration mode.
For command details,
see the Command Line Interface
Reference
Operator Policy
The non-standard
feature is unique to the ASR 5000 SGSN. This feature empowers the
carrier with unusual and flexible control to manage functions that
aren’t typically used in all applications and to determine
the granularity of the implementation of any: to groups of incoming
calls or to simply one single incoming call. For details about the
feature, its components, and how to configure it, refer to the Operator Policy chapter
in this guide.
IMPORTANT:
SGSN configurations
created prior to Release 11.0 are not forward compatible. All
configurations for SGSNs, with -related configurations that were
generated with software releases prior to Release 11.0, must be
converted to enable them to operate with an SGSN running Release
11.0 or higher. Your Cisco Representative can accomplish this conversion
for you.
Some Features Managed
by Operator Policies
The following is a list
of some of the features and functions that can be controlled via
configuration of Operator Policies:
- APN Aliasing
- Authentication
- Direct Tunnel - for
feature description and configuration details, refer to the Direct Tunnel chapter
in this guide
- Equivalent PLMN
- IMEI Override
- Intra- or Inter-SGSN
Serving Radio Network Subsystem (SRNS) Relocation (3G only)
- Network Sharing
- QoS Traffic Policing
per Subscriber
- SGSN Pooling - Gb/Iu
Flex
- SuperCharger
- Subscriber Overcharging
Protection - for feature description and configuration details,
refer to the Subscriber
Overcharging Protection chapter in this guide.
Overcharging Protection
Overcharging
Protection enables the SGSN to avoid overcharging the subscriber
if/when a loss of radio coverage (LORC) occurs in a UMTS
network. For details and configuration information, refer to the Subscriber Overcharging
Protection chapter in this book.
QoS Traffic Policing
per Subscriber
Traffic policing
enables the operator to configure and enforce bandwidth limitations
on individual PDP contexts for a particular traffic class.
Traffic policing typically
deals with eliminating bursts of traffic and managing traffic flows
in order to comply with a traffic contract.
The SGSN conforms to
the DiffServ model for QoS by handling the 3GPP defined classes
of traffic, QoS negotiation, DSCP marking, traffic policing, and
support for HSDPA/HSUPA.
QoS Classes
The 3GPP QoS classes
supported by the SGSN are:
- Conversational
- Streaming
- Interactive
- Background
The SGSN is capable
of translating between R99 and R97/98 QoS attributes.
QoS Negotiation
On PDP context activation,
the SGSN calculates the QoS allowed, based upon:
-
Subscribed QoS - This
is a per-APN configuration, obtained from the HLR on an Attach.
It specifies the highest QoS allowed to the subscriber for that
APN.
-
Configured QoS - The
SGSN can be configured with default and highest QoS profiles in
the configuration.
-
MS requested QoS - The
QoS requested by the UE on pdp-context activation.
DSCP Marking
The SGSN performs
diffserv code point (DSCP) marking of the GTP-U packets according to
allowed-QoS to PHB mapping. The default mapping matches that of
the UMTS to IP QoS mapping defined in 3GPP TS 29.208.
The SGSN also supports
DSCP marking of the GTP control plane messages on the Gn/Gp
interface. This allows QoS to be set on GTP-C messages, and is useful
if Gn/Gp is on a less than ideal link. DSCP marking is
configurable via the CLI, with default = Best Effort Forwarding.
Traffic Policing
The SGSN can police
uplink and downlink traffic according to predefined QoS negotiated
limits fixed on the basis of individual contexts - either primary
or secondary. The SGSN employs the Two Rate Three Color Marker (RFC2698)
algorithm for traffic policing. The algorithm meters an IP packet
stream and marks its packets either green, yellow, or red depending
upon the following variables:
-
PIR - Peak Information
Rate (measured in bytes/second)
-
CIR - Committed
Information Rate (measured in bytes/second)
-
PBS - Peak Burst
Size (measured in bytes)
-
CBS - Committed
Burst Size (measured in bytes)
The following figure
depicts the working of the TCM algorithm:
Figure 8. TCM Algorithm Logic
for Traffic Policing
For commands and more
information on traffic policing configuration, refer to the Command Line Interface Reference.
Reordering of SNDCP
N-PDU Segments
The SGSN fully
supports reordering of out-of-order segments coming from the same
SNDCP N-PDU. The SGSN waits the configured amount of time for all
segments of the N-PDU to arrive. If all the segments are not received
before the timer expiries, then all queued segments are dropped.
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.
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.
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.
The additional hardware
resources required for session recovery include a standby System Management
Card and a 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.
-
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.
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.
When session recovery
occurs, the system reconstructs the following subscriber information:
- Data and control state
information required to maintain correct call behavior
- Subscriber data statistics
that are required to ensure that accounting information is maintained
- A best-effort attempt
to recover various timer values such as call duration, absolute
time, and others
For more information
on session recovery use and session recovery configuration, refer
to the Session Recovery chapter
in the Cisco ASR 5000
Series System Administration Guide.
SGSN Pooling and
Iu-Flex / Gb-Flex
This implementation
allows carriers to load balance sessions among pooled SGSNs, to
improve reliability and efficiency of call handling, and to use
Iu-Flex / Gb-Flex to provide carriers with deterministic
failure recovery.
The SGSN, with its high
capacity, signaling performance, and peering capabilities, combined
with its level of fault tolerance, delivers many of the benefits
of Flex functionality even without deploying SGSN pooling.
As defined by 3GPP TS
23.236, the SGSN implements Iu-Flex and Gb-Flex functionality to facilitate
network sharing and to ensure SGSN pooling for 2.5G and 3G accesses
as both separate pools and as dual-access pools.
SGSN pooling enables
the following:
- Eliminates the single
point of failure between an RNC and an SGSN or between a BSS and
an SGSN.
- Ensures geographical
redundancy, as a pool can be distributed across sites.
- Minimizes subscriber
impact during service, maintenance, or node additions or replacements.
- Increases overall capacity
via load sharing across the SGSNs in a pool.
- Reduces the need/frequency
for inter-SGSN RAUs. This substantially reduces signaling load and
data transfer delays.
- Supports load redistribution
with the SGSN offloading procedure.
Gb/Iu Flex
Offloading
The SGSN supports
Gb/Iu Flex subscriber offloading from one SGSN to another
specific SGSN in a 2G/3G pool.
In addition, the operator
can configure the offloading Target NRI in P-TMSI, and the quantity
to offload to the Target. This can be used to provide load balancing,
or to offload a single node in pool, take it out of service for
whatever reason (e.g., maintenance).
Short Message Service
(SMS over Gd)
The SGSN implements
a configurable Short Message Service (SMS) to support sending and receiving
text messages up to 140 octets in length. The SGSN handles multiple,
simultaneous messages of both types: those sent from the MS/UE
(SMS-MO: mobile originating) and those sent to the MS/UE
(SMS-MT: mobile terminating). Short Message Service is disabled
by default.
After verifying a subscription
for the PLMN’s SMS service, the SGSN connects with the
SMSC (short message service center), via a Gd interface, to relay received
messages (from a mobile) using MAP-MO-FORWARD-REQUESTs for store-and-forward.
In the reverse, the
SGSN awaits messages from the SMSC via MAP-MT-FORWARD-REQUESTs and
checks the subscriber state before relaying them to the target MS/UE.
The SGSN will employ
both the Page procedure and MNRG (mobile not reachable for GPRS)
flags in an attempt to deliver messages to subscribers that are
absent.
The SGSN supports
- charging for SMS messages,
and
- lawful intercept of
SMS messages
For information on configuring
and managing the SMS, refer to the SMS Service Configuration
Mode chapter in the Command
Line Interface Reference.
SMS Authentication
Repetition Rate
The SGSN provides
an authentication procedures for standard GMM events like Attach,
Detach, RAU, and Service-Request, and SMS events such as Activate,
all with support for 1-in-N Authenticate functionality. The SGSN
did not provide the capability to authenticate MO/MT SMS
events.
Now, the authentication
functionality has been expanded to the Gs interface where the SGSN
now supports configuration of the authentication repetition rate
for SMS-MO and SMS-MT, for every nth event. This functionality is
built on existing SMS CLI, with configurable MO and/or
MT. The default is not to authenticate.
SMSC Address Denial
Previously,
the SGSN supported restricting MO-SMS and MT-SMS only through SGSN
operator policy configuration.
Now, the SGSN can restrict
forwarding of SMS messages to specific SMSC addresses, in order
to allow operators to block SMS traffic that cannot be charged for.
This functionality supports multiple SMSCs and is configurable per
SMSC address with a maximum of 10 addresses. It is also configurable
for MO-SMS and/or MT-SMS messages.
Threshold Crossing
Alerts (TCA) Support
Thresholding on the
system is used to monitor the system for conditions that could potentially
cause errors or outage. Typically, these conditions are temporary (i.e
high CPU utilization, or packet collisions on a network) and are
quickly resolved. However, continuous or large numbers of these
error conditions within a specific time interval may be indicative
of larger, more severe issues. The purpose of thresholding is to
help identify potentially severe conditions so that immediate action
can be taken to minimize and/or avoid system downtime.
The system supports
Threshold Crossing Alerts for certain key resources such as CPU, memory,
number of sessions etc. With this capability, the operator can configure
threshold on these resources whereby, should the resource depletion
cross the configured threshold, a SNMP Trap would be sent.
The following thresholding
models are supported by the system:
-
Alert: A value is
monitored and an alert condition occurs when the value reaches or
exceeds the configured high threshold within the specified polling
interval. The alert is generated then generated and/or
sent at the end of the polling interval.
-
Alarm: Both high
and low threshold are defined for a value. An alarm condition occurs
when the value reaches or exceeds the configured high threshold
within the specified polling interval. The alert is generated then
generated and/or sent at the end of the polling interval.
Thresholding reports
conditions using one of the following mechanisms:
-
SNMP traps: SNMP
traps have been created that indicate the condition (high threshold
crossing and/or clear) of each of the monitored values.
Generation of specific
traps can be enabled or disabled on the chassis. Ensuring that only important
faults get displayed. SNMP traps are supported in both Alert and
Alarm modes.
-
Logs: The system
provides a facility called threshold for which active and event
logs can be generated. As with other system facilities, logs are
generated Log messages pertaining to the condition of a monitored
value are generated with a severity level of WARNING.
Logs are supported
in both the Alert and the Alarm models.
-
Alarm System: High
threshold alarms generated within the specified polling interval
are considered “outstanding” until a the condition
no longer exists or a condition clear alarm is generated. “Outstanding” alarms
are reported to the system's alarm subsystem and are viewable through
the Alarm Management menu in the Web Element Manager.
The Alarm System is
used only in conjunction with the Alarm model.
IMPORTANT:
For more information
on threshold crossing alert configuration, refer to the Thresholding Configuration
Guide.
Tracking Usage of
GEA Encryption Algorithms
GPRS encryption
algorithm (GEA) significantly affects the SGSN processing capacity
based on the GEAx level used - GEA1, GEA2, or GEA3.
Operators would like
to be able to identify the percentages of their customer base that
are using the various GEA encryption algorithms. The same tool can
also track the migration trend from GEA2 to GEA3 and allow an operator
to forecast the need for additional SGSN capacity.
New fields and counters
have been added to the output generated by the show subscribers gprs-only|sgsn-only
summary command. This new information enables the operator
to track the number of subscribers capable of GEA0-GEO3 and to easily
see the number of subscribers with negotiated GEAx levels.
VLR Pooling via the
Gs Interface
VLR Pooling,
also known as Gs Pooling, helps to reduce call delays and call dropping,
when the MS/UE is in motion, by routing a service request
to a core network (CN) node with available resources.
VLR pools are configured
in the Gs Service, which supports the Gs interface configuration
for communication with VLRs and MSCs.
A pool area is a geographical
area within which an MS/UE can roam without the need to
change the serving CN node. A pool area is served by one or more
CN nodes in parallel. All the cells, controlled by an RNC or a BSC
belong to the same one (or more) pool area(s).
VLR hash is used when
a pool of VLRs is serving a particular LAC (or list of LACs). The selection
of VLR from this pool is based on the IMSI digits. From the IMSI,
the SGSN derives a hash value (V) using the algorithm: [(IMSI
div 10) modulo 1000]. Every hash value (V) from the range
0 to 999 corresponds to a single MSC/VLR node. Typically
many values of (V) may point to the same MSC/VLR node.
For commands to configure
the VLR and pooling, refer to the “Gs Service Configuration Mode” chapter
in the Command Line Interface
Reference.