21 8 SGW Admin
21 8 SGW Admin
21 8 SGW Admin
8
First Published: 2018-04-26
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,
INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH
THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY,
CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version
of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS.
CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT
LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network
topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional
and coincidental.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: https:/
/www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership
relationship between Cisco and any other company. (1721R)
Rf Diameter Accounting 32
S-GW Collision Handling 33
Viewing S-GW Collision Statistics 33
S-GW Session Idle Timer 34
Subscriber Level Trace 34
Support for One Million S1-U Peers on the S-GW 35
Threshold Crossing Alerts (TCA) Support 36
ULI Enhancements 37
Features and Functionality - Optional Enhanced Feature Software 37
128k eNodeB Support 38
Direct Tunnel 38
Intelligent Paging for ISR 39
Inter-Chassis Session Recovery 39
IP Security (IPSec) Encryption 40
Lawful Intercept 41
Layer 2 Traffic Management (VLANs) 41
New Call Policy for Stale Sessions 41
New Standard QCI Support 41
Overcharging Protection Support 41
Paging Policy Differentiation 42
3GPP Release 12 Load and Overload Support 43
Operation 44
Separate Paging for IMS Service Inspection 44
Session Recovery Support 45
S-GW Paging Enhancements 45
How the Serving Gateway Works 46
GTP Serving Gateway Call/Session Procedures in an LTE-SAE Network 46
Subscriber-initiated Attach (initial) 47
Subscriber-initiated Detach 50
Supported Standards 50
3GPP References 51
Release 12 3GPP References 51
Release 11 3GPP References 51
Release 10 3GPP References 52
Release 9 Supported Standards 52
CHAPTER 14 3GPP R12 GTP-C Load and Overload Control Support on the P-GW, SAEGW, and
S-GW 245
Feature Description 245
Relationships to Other Features 246
How It Works 247
Creating and Configuring a 3GPP R12 GTP-C Load Control Profile 247
Configuration Overview 247
Creating the GTPP R12 Load Control Profile 248
Configuring the 3GPP R12 Load Control Profile Weightage Settings 248
Configuring the 3GPP R12 Load Control Profile Inclusion Frequency 249
Configuring the 3GPP R12 Load Control Threshold 249
Configuring 3GPP R12 Load Control Information Handling 249
Configuring 3GPP R12 Load Control Information Publishing 250
Configuring the 3GPP R12 GTP-C Polling Parameter Interval 250
Associating the 3GPP R12 Load Control Profile with a P-GW, SAEGW, or S-GW
Service. 251
Verifying the 3GPP R12 Load Control Configuration 252
Saving the Configuration 252
Creating and Configuring a 3GPP R12 GTP-C Overload Control Profile 252
Configuration Overview 253
Creating the GTPP R12 Overload Control Profile 253
Configuring 3GPP R12 Overload Control Weightage Settings 254
Configuring the 3GPP R12 Overload Control Inclusion Frequency 254
Configuring the 3GPP R12 Overload Control Validity Period 255
Configuring 3GPP R12 Overload Control Tolerance Limits 255
Configuring 3GPP R12 Overload Control Throttling Behavior 256
Configuring 3GPP R12 Overload Control Message Prioritization 256
License 292
Configuring Overcharging Protection Feature 292
Configuring Overcharging Support on the P-GW 292
Configuring Overcharging Support on the S-GW 293
Monitoring and Troubleshooting 294
P-GW Schema 294
show apn statistics all 294
show pgw-service all 294
show pgw-service statistics all 294
show sgw-service statistics name <sgw_service_name> 295
show subscribers full 295
show subscribers pgw-only full all 295
show subscribers summary 295
Conventions Used
The following tables describe the conventions used throughout this documentation.
Warning Alerts you of potential personal injury or fatality. May also alert you of potential
electrical hazards.
Text represented as a command This typeface represents a variable that is part of a command, for example:
variable show card slot_number
slot_number is a variable representing the desired chassis slot number.
Text represented as menu or This typeface represents menus and sub-menus that you access within a
sub-menu names software application, for example:
Click the File menu, then click New
Obtaining Documentation
The most current Cisco documentation is available on the following website:
http://www.cisco.com/cisco/web/psa/default.html
Use the following path selections to access the S-GW documentation:
Products > Wireless > Mobile Internet> Network Functions > Cisco SGW Serving Gateway
Product Description
The Serving Gateway routes and forwards data packets from the UE and acts as the mobility anchor during
inter-eNodeB handovers. Signals controlling the data traffic are received on the S-GW from the MME which
determines the S-GW that will best serve the UE for the session. Every UE accessing the EPC is associated
with a single S-GW.
The S-GW is also involved in mobility by forwarding down link data during a handover from the E-UTRAN
to the eHRPD network. An interface from the eAN/ePCF to an MME provides signaling that creates a GRE
tunnel between the S-GW and the eHRPD Serving Gateway.
• support of circuit switched fallback (CSFB) for re-using deployed CS domain access for voice and other
CS domain services.
Platform Requirements
The S-GW service runs on a Cisco® ASR 5500 Series chassis running StarOS. The chassis can be configured
with a variety of components to meet specific network deployment requirements. For additional information,
refer to the Installation Guide for the chassis and/or contact your Cisco account representative.
Licenses
The S-GW is a licensed Cisco product. Separate session and feature licenses may be required. 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.
Network Deployment(s)
This section describes the supported interfaces and the deployment scenarios of a Serving Gateway.
The following figure displays a sample network deployment of an S-GW, including all of the interface
connections with other 3GPP Evolved-UTRAN/Evolved Packet Core network devices.
S1-U Interface
This reference point provides bearer channel tunneling between the eNodeB and the S-GW. It also supports
eNodeB path switching during handovers. The S-GW provides the local mobility anchor point for inter-eNodeB
hand-overs. It provides inter-eNodeB path switching during hand-overs when the X2 handover interface
between base stations cannot be used. The S1-U interface uses GPRS tunneling protocol for user plane
(GTP-Uv1). GTP encapsulates all end user IP packets and it relies on UDP/IP transport. The S1-U interface
also supports IPSec IKEv2. This interface is defined in 3GPP TS 23.401.
Supported protocols:
• Transport Layer: UDP, TCP
• Tunneling: IPv4 or IPv6 GTPv1-U (bearer channel)
• Network Layer: IPv4, IPv6
• Data Link Layer: ARP
• Physical Layer: Ethernet
S4 Interface
This reference point provides tunneling and management between the S-GW and a 3GPP S4 SGSN. The
interface facilitates soft hand-offs with the EPC network by providing control and mobility support between
the inter-3GPP anchor function of the S-GW. This interface is defined in 3GPP TS 23.401.
Supported protocols:
• Transport Layer: UDP
• Tunneling:
◦GTP: IPv4 or IPv6 GTP-C (GTPv2 control/signaling channel) and GTP-U (GTPv1 user/bearer
channel)
S5/S8 Interface
This reference point provides tunneling and management between the S-GW and the P-GW, as defined in
3GPP TS 23.401. The S8 interface is an inter-PLMN reference point between the S-GW and the P-GW used
during roaming scenarios. The S5 interface is used between an S-GW and P-GW located within the same
administrative domain (non-roaming). It is used for S-GW relocation due to UE mobility and if the S-GW
needs to connect to a non-collocated P-GW for the required PDN connectivity.
Supported protocols:
• Transport Layer: UDP, TCP
• Tunneling: GTP: GTPv2-C (signaling channel), GTPv1-U (bearer channel)
• Network Layer: IPv4, IPv6
• Data Link Layer: ARP
• Physical Layer: Ethernet
S11 Interface
This reference point provides GTP-C control signal tunneling between the MME and the S-GW. One GTP-C
tunnel is created for each mobile terminal between the MME and S-GW. This interface is defined in 3GPP
TS 23.401.
Supported protocols:
• Transport Layer: UDP
• Tunneling: IPv4 or IPv6 GTPv2-C (signaling channel)
• Network Layer: IPv4, IPv6
• Data Link Layer: ARP
• Physical Layer: Ethernet
S12 Interface
This reference point provides GTP-U bearer/user direct tunneling between the S-GW and a UTRAN Radio
Network Controller (RNC), as defined in 3GPP TS 23.401. This interface provides support for inter-RAT
handovers between the 3G RAN and EPC allowing a direct tunnel to be initiated between the RNC and S-GW,
thus bypassing the S4 SGSN and reducing latency.
Supported protocols:
• Transport Layer: UDP
• Tunneling: IPv4 or IPv6 GTP-U (GTPv1 bearer/user channel)
• Network Layer: IPv4, IPv6
• Data Link Layer: ARP
Gxc Interface
This signaling interface supports the transfer of policy control and charging rules information (QoS) between
the Bearer Binding and Event Reporting Function (BBERF) on the S-GW and a Policy and Charging Rules
Function (PCRF) server.
Supported protocols:
• Transport Layer: TCP or SCTP
• Network Layer: IPv4, IPv6
• Data Link Layer: ARP
• Physical Layer: Ethernet
Gz Interface
The Gz reference interface enables offline accounting functions on the S-GW. The S-GW collects charging
information for each mobile subscriber UE pertaining to the radio network usage. The Gz interface and offline
accounting functions are used primarily in roaming scenarios where the foreign P-GW does not support offline
charging.
Supported protocols:
• Transport Layer: TCP
Rf Interface
Important In StarOS 19 and later releases, the Rf interface is not supported on the S-GW.
The Diameter Rf interface (3GPP 32.240) is used for offline (post-paid) charging between the Charging
Trigger Function (CTF, S-GW) and the Charging Data Function (CDF). It follows the Diameter base protocol
state machine for accounting (RFC 3588) and includes support for IMS specific AVPs (3GPP TS 32.299)
Supported protocols:
• Transport Layer: TCP or SCTP
• Network Layer: IPv4, IPv6
• Data Link Layer: ARP
• Physical Layer: Ethernet
Important To configure the basic service and functionality on the system for the S-GW service, refer to the
configuration examples provided in the Serving Gateway Administration Guide.
These measures are applicable to the ASR 5500 Platform and an element management system since both
require password authentication. A subset of these guidelines where applicable to each platform will be
implemented. A known subset of guidelines, such as certificate authentication, are not applicable to either
product. Furthermore, the platforms support a variety of authentication methods such as RADIUS and SSH
which are dependent on external elements. ANSI T1.276 compliance in such cases will be the domain of the
external element. ANSI T1.276 guidelines will only be implemented for locally configured operators.
Important For more information on Backup and Recovery of Key KPI Statistics, refer to the Backup and Recovery
of Key KPI Statistics chapter in this guide.
The system supports the configuration of up to four 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 system 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, system host name, system
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.
An element management system is capable of further processing the statistics data through XML parsing,
archiving, and graphing.
The Bulk Statistics Server component of an element management system parses collected statistics and stores
the information in its PostgreSQL database. It can also generate XML output and can send it to a Northbound
NMS or an alternate bulk statistics server for further processing.
Additionally, the Bulk Statistics server can archive files to an alternative directory on the server. The directory
can be on a local file system or on an NFS-mounted file system on an element management system server.
Important For more information on bulk statistic configuration, refer to the Configuring and Maintaining Bulk
Statistics chapter in the System Administration Guide.
temporarily suspended (either the data transfer is suspended or the packet switched connection is handed over
to the 2G/3G network).
CSFB provides an interim solution for enabling telephony and SMS services for LTE operators that do not
plan to deploy IMS packet switched services at initial service launch.
The S-GW supports CSFB messaging over the S11 interface over GTP-C. Supported messages are:
• Suspend Notification
• Suspend Acknowledge
• Resume Notification
• Resume Acknowledgement
The S-GW forwards Suspend Notification messages towards the P-GW to suspend downlink data for non-GBR
traffic; the P-GW then drops all downlink packets. Later, when the UE finishes with CS services and moves
back to E-UTRAN, the MME sends a Resume Notification message to the S-GW which forwards the message
to the P-GW. The downlink data traffic then resumes.
◦Suspend Old: Suspend processing of the original (old) message, process the new message, then
resume old message handling.
◦Abort Old: Abort the original message handling and processes the new message.
◦Reject New: The new message is rejected, and the original (old) message is processed.
◦Silent Drop New: Drop the new incoming message, and the old message is processed.
◦Parallel Hndl: Both the original (old) and new messages are handled in parallel.
◦Buffer New: The new message is buffered and processed once the original (old) message processing
is done.
Important The Message Collision Statistics section of the command output only appears if any of the collision
statistics have a counter total that is greater than zero.
Sample output:
Message Collision Statistics
Interface Old Proc (Msg Type) New Proc (Msg Type) Action Counter
SGW(S5) NW Init Bearer Create (95) NW Init PDN Delete (99) Abort Old 1
In this instance, the output states that at the S-GW egress interface (S5) a Bearer creation procedure is going
on due to a CREATE BEARER REQUEST(95) message from the P-GW. Before its response comes to the
S-GW from the MME, a new procedure PDN Delete is triggered due to a DELETE BEARER REQUEST(99)
message from the P-GW.
The action that is carried out due to this collision at eGTP-C is to abort (Abort Old) the Bearer Creation
procedure and carry on normally with the PDN Delete procedure. The Counter total of 1 indicates that this
collision happened only once.
Congestion Control
The congestion control feature allows you to set policies and thresholds and specify how the system reacts
when faced with a heavy load condition.
Congestion control monitors the system for conditions that could potentially degrade performance when the
system is under heavy load. Typically, these conditions are temporary (for example, high CPU or memory
utilization) and are quickly resolved. However, continuous or large numbers of these conditions within a
specific time interval may have an impact the system's ability to service subscriber sessions. Congestion
control helps identify such conditions and invokes policies for addressing the situation.
Congestion control operation is based on configuring the following:
• Congestion Condition Thresholds: Thresholds dictate the conditions for which congestion control is
enabled and establish limits for defining the state of the system (congested or clear). These thresholds
function in a way similar to operational thresholds that are configured for the system as described in the
Thresholding Configuration Guide. The primary difference is that when congestion thresholds are
reached, a service congestion policy and an SNMP trap, starCongestion, are generated.
A threshold tolerance dictates the percentage under the configured threshold that must be reached in
order for the condition to be cleared. An SNMP trap, starCongestionClear, is then triggered.
◦Port Utilization Thresholds: If you set a port utilization threshold, when the average utilization
of all ports in the system reaches the specified threshold, congestion control is enabled.
◦Port-specific Thresholds: If you set port-specific thresholds, when any individual port-specific
threshold is reached, congestion control is enabled system-wide.
• Service Congestion Policies: Congestion policies are configurable for each service. These policies
dictate how services respond when the system detects that a congestion condition threshold has been
crossed.
Important For more information on congestion control, refer to the Congestion Control chapter in the System
Administration Guide.
Value Handling
This feature provides for the handling of delay value information elements (IEs) at the S-GW. When a delay
value is received at the S-GW from a particular MME, the S-GW delays sending data notification requests
for all idle calls belonging to that particular MME. Once the timer expires, requests can be sent. The delay
value at the S-GW is determined by the factor received in the delay value IE (as a part of either a Modify
Bearer Request or a Data Downlink Notification Request) and a hard-coded base factor of 50 ms at the S-GW
Throttling
This feature provides additional controls allowing the S-GW to set factors that "throttle" the continuous sending
and receiving of DDN messages. A single command configures the throttling parameters supporting this
feature,
A description of the ddn throttle command is located in the S-GW Service Configuration Mode Commands
chapter in the Command Line Interface Reference.
DSCP Ingress and Egress and DSCP Marking at the APN Profile
This feature will provide an operator with a configuration to set the DSCP value per APN profile, so different
APNs can have different DSCP markings as per QOS requirements for traffic carried by the APN. In addition,
the qci-qos mapping table is updated with the addition of a copy-outer for copying the DSCP value coming
in the encapsulation header from the S1u interface to the S5 interface and vice-versa.
To enable this functionality, use the micro-checkpoint-deemed-idle keyword in the timeout idle command
in APN Configuration Mode.
Event Reporting
The S-GW can be configured to send a stream of user event data to an external server. As users attach, detach,
and move throughout the network, they trigger signaling events, which are recorded and sent to an external
server for processing. Reported data includes failure reasons, nodes selected, user information (IMSI, IMEI,
MSISDN), APN, failure codes (if any) and other information on a per PDN-connection level. Event data is
used to track the user status via near real time monitoring tools and for historical analysis of major network
events.
The S-GW Event Reporting chapter at the end of this guide describes the trigger mechanisms and event record
elements used for event reporting.
The SGW sends each event record in comma separated values (CSV) format. The record for each event is
sent to the external server within 60 seconds of its occurrence. The session-event-module command in the
Context Configuration mode allows an operator to set the method and destination for transferring event files,
as well as the format and handling characteristics of event files. For a detailed description of this command,
refer to the Command Line Interface Reference.
Table 1: New and Modified System Event Logs with IMSI/IMEI in System Event Log Details
12225 Represents misc_error3 in format "[IMSI <IMSI>] Misc Error3: %s, error code %d"
Modified Events
139001 To print miscellaneous PGW error log.
10034 Represents FSM error in format "[IMSI <IMSI>] default call fsm error: ostate=%s(%d)
state=%s(%d) event=%s(%d)"
10035 Represents FSM INVALID event in format "[IMSI <IMSI>] default call fsm invalid
event: state=%s(%d) event=%s(%d)"
12668 Represents fsm_event_error in format "[IMSI <IMSI>] Misc Error: Bad event in
sessmgr fsm, event code %d"
12860 Represents ncqos_sec_rej in format "[IMSI <IMSI>] NCQOS Secondary ctxt with
nsapi <%u> rejected, due to <%s>."
12861 Represents ncqos_upc_rej in format "[IMSI <IMSI>] UPC Rejected for ctxt with
nsapi <%u>, due to <%s>."
11293 Represents collision_error in format "[IMSI <IMSI>] Collision Error: Temp Failure
Handling Delayed Pending Active Transaction: , error code %d"
Enable this functionality by using the logging include-ueid command in Global Configuration Mode. When
enabled, the previously mentioned system events of type error and critical will provide the IMSI/IMEI in the
logging details, if available.
Important The S-GW supports interface-based ACLs only. For more information on IP access control lists, refer to
the IP Access Control Lists chapter in the System Administration Guide.
IPv6 Capabilities
IPv6 enables increased address efficiency and relieves pressures caused by rapidly approaching IPv4 address
exhaustion problem.
The S-GW platform offers the following IPv6 capabilities:
IPv6 Connections to Attached Elements
IPv6 transport and interfaces are supported on all of the following connections:
• Diameter Gxc policy signaling interface
• Diameter Rf offline charging interface
• Lawful Intercept (X1, X2 interfaces)
Important In StarOS v19 and later releases, the Diameter Rf offline charging interface is not supported on the S-GW.
LIPA Support
A LIPA (Local IP Access) PDN is a PDN Connection for local IP access for a UE connected to a HeNB. The
LIPA architecture includes a Local Gateway (LGW) acting as an S-GW GTPv2 peer. The LGW is collocated
with HeNB in the operator network behaves as a PGW from SGW perspective. Once the default bearer for
the LIPA PDN is established, then data flows directly to the LGW and from there into the local network
without traversing the core network of the network operator.
In order to support millions of LIPA GTPC peers, S-GW memory management has been enhanced with regards
to GTPv2 procedures and as well as to support the maintenance of statistics per peer node.
Establishment of LIPA PDN follows a normal call flow similar to that of a normal PDN as per 23.401; the
specification does not distinguish between a LGW and a PGW call. As a result, the S-GW supports a new
configuration option to detect a LIPA peer. As a fallback mechanism, heuristic detection of LIPA peer based
on data flow characteristics of a LIPA call is also supported.
Whenever a peer is detected as a LIPA peer, the S-GW will disable GTPC echo mechanism towards that
particular peer and stop maintaining some statistics for that peer.
A configuration option in APN profile explicitly indicates that all the PDN's for that APN are LIPA PDN's,
so all GTPC peers on S5 for that APN are treated as LGW, and thus no any detection algorithm is applied to
detect LGW.
Location Reporting
Location reporting can be used to support a variety of applications including emergency calls, lawful intercept,
and charging. This feature reports user location information (ULI).
ULI data reported in GTPv2 messages includes:
• TAI-ID: Tracking Area Identity
• MCC: MNC: Mobile Country Code, Mobile Network Code
• TAC: Tracking Area Code
The S-GW stores the ULI and also reports the information to the accounting framework. This may lead to
generation of Gz and Rf Interim records. The S-GW also forwards the received ULI to the P-GW. If the S-GW
receives the UE time zone IE from the MME, it forwards this IE towards the P-GW across the S5/S8 interface.
The S5/S8 bearers eligible for network initiated service restoration are determined by the S-GW based on
operator's policy, for example, based on the QCI and/or ARP and/or APN.
The benefit of this feature is that it provides support for the geo-redundant pool feature on the S4-SGSN/MME.
In order to restore session when the MME receives a DDN, the S-GW triggers restoration when the serving
MME is unavailable, by selecting another MME and sending DDN. This helps in faster service
restoration/continuity in case of MME/S4-SGSN failures.
MME Restoration Standards Extension
The solution to recover from MME node failures proposed in the 3GPP standards rely on the deployment of
MME pools where each pool services a coverage area. Following an MME failure, the S-GW and MSC/VLR
nodes may select the same MME that used to service a UE, if it has restarted, or an alternate MME in the
same pool to process Network-initiated signaling that it received in accordance with the NTSR procedures
defined in 3GPP TS 23.007 Release 11.
For a failed MME, the S-GW will select an alternate MME from the associated NTSR pool in round robin
fashion in each sessmgr instance.
dedicated bearers. To request the various PDN connections, the MAG includes a common MN-ID and separate
Home Network Prefixes, APNs and a Handover Indication Value equal to one in the PMIPv6 Binding Updates.
Important Note that the S-GW does not support MABR functionality.
If S-GW wants to use new message, such as P-GW Restart Notification, then S-GW should check if the peer
node supports this new feature or not. If the peer does not support it, then S-GW should fall back to old
behavior.
If S-GW receives a new message from the peer node, and if S-GW does not support this new message, then
S-GW should ignore it. If S-GW supports the particular feature, then it should handle the new message as per
the specification.
Online/Offline Charging
Important In StarOS release 19 and later releases, Offline Charging is not supported on the S-GW.
The Cisco EPC platforms support offline charging interactions with external OCS and CGF/CDF servers. To
provide subscriber level accounting, the Cisco EPC platform supports integrated Charging Transfer Function
(CTF) and Charging Data Function (CDF) / Charging Gateway Function (CGF). Each gateway uses
Charging-IDs to distinguish between default and dedicated bearers within subscriber sessions.
The ASR 5500 platform offers a local directory to enable temporary file storage and buffer charging records
in persistent memory located on a pair of dual redundant RAID hard disks.
The offline charging implementation offers built-in heart beat monitoring of adjacent CGFs. If the Cisco
P-GW has not heard from the neighboring CGF within the configurable polling interval, it will automatically
buffer the charging records on the local drives until the CGF reactivates itself and is able to begin pulling the
cached charging records.
Important The S-GW does not support non-standard QCI values. QCI values 1 through 9 are standard values and
are defined in 3GPP TS 23.203; the S-GW supports these standard values.
Guaranteed Bit Rate (GBR): A GBR bearer is associated with a dedicated EPS bearer and provides a
guaranteed minimum transmission rate in order to offer constant bit rate services for applications such as
interactive voice that require deterministic low delay service treatment.
Maximum Bit Rate (MBR): The MBR attribute provides a configurable burst rate that limits the bit rate that
can be expected to be provided by a GBR bearer (e.g. excess traffic may get discarded by a rate shaping
function). The MBR may be greater than or equal to the GBR for a given dedicated EPS bearer.
Aggregate Maximum Bit Rate (AMBR): AMBR denotes a bit rate of traffic for a group of bearers destined
for a particular PDN. The Aggregate Maximum Bit Rate is typically assigned to a group of Best Effort service
data flows over the Default EPS bearer. That is, each of those EPS bearers could potentially utilize the entire
AMBR, e.g. when the other EPS bearers do not carry any traffic. The AMBR limits the aggregate bit rate that
can be expected to be provided by the EPS bearers sharing the AMBR (e.g. excess traffic may get discarded
by a rate shaping function). AMBR applies to all Non-GBR bearers belonging to the same PDN connection.
GBR bearers are outside the scope of AMBR.
Policing and Shaping: The Cisco S-GW offers a variety of traffic conditioning and bandwidth management
capabilities. These tools enable usage controls to be applied on a per-subscriber, per-EPS bearer or
per-PDN/APN basis. It is also possible to apply bandwidth controls on a per-APN AMBR capacity. These
applications provide the ability to inspect and maintain state for user sessions or Service Data Flows (SDF's)
within them using shallow L3/L4 analysis or high touch deep packet inspection at L7. Metering of out-of-profile
flows or sessions can result in packet discards or reducing the DSCP marking to Best Effort priority. When
traffic shaping is enabled the S-GW enqueues the non-conforming session to the provisioned memory limit
for the user session. When the allocated memory is exhausted, the inbound/outbound traffic for the user can
be transmitted or policed in accordance with operator provisioned policy.
Table 2: Previous and New Behavior: CSReq and CSRsp Messages at P-GW Due to Removal of Private Extension
Overcharging Support
Scenario IE Carrying OCP Capability Old Behavior: IE carrying OCP New Behavior: IE Carrying OCP
No. Received from S-GW in Capability Sent to S-GW in Capability Sent to S-GW in CSRsp
CSReq CSRsp
1 Indication IE Indication IE No change. Indication IE will be sent
in CSRsp.
2 Private Extension IE Both Private Extension and Private Extension IE received from
Indication IEs. S-GW is ignored. Indication IE is
sent in CSRsp.
The following table describes the previous and new behavior in Modify Bearer Request (MBReq) and Modify
Bearer Response (MBRsp) messages due to the removal of Private Extension Overcharging Support.
Table 3: Previous and New Behavior: MBRreq and MBRsp Messages at P-GW Due to Removal of Private Extension
Overcharging Support
Scenario IE carrying OCP Capability Old Behavior: IE Carrying OCP New Behavior: IE Carrying OCP
No. Received from S-GW in Capability Sent to S-GW in Capability Sent to S-GW in MBRsp
MBReq MBRsp
1 Indication IE Indication IE No Change. Indication IE is sent in
MBRsp messages.
Table 4: Previous and New Behavior: CSRsp Messages at the S-GW Due to the Removal of Private Extension Overcharging
Support
2 Private Extension IE OCP capability received If gtpc private-extension Since the CLI command
as part of Private overcharge-protection is is deprecated, then the
Extension IE is ignored. disabled at egtpc service Private Extension IE is
level: Private forwarded to the MME in
Extension IE. CSRsp as would be done
for any unknown Private
If gtpc private-extension
Extension IE.
overcharge-protection is
enabled at egtpc service
level: Indication IE.
The following table describes the previous and new behavior in Modify Bearer Response (MBRsp) messages
at the S-GW due to the removal of Private Extension Overcharging Support.
Table 5: Previous Behavior and New Behavior: MBRsp Messages at the S-GW Due to the Removal of Private Extension
Overcharging Support
Important In StarOS releases 21.0 and later, the S-GW will send a MBReq message with only the indication IE for
the Pause/Start Charging procedure. The private extension IE is not sent.
Important If the S-GW receives only the private extension IE from the P-GW in the CSRsp/MBRsp message, then
the S-GW ignores the private extension IE. As a result, the S-GW assumes that Overcharging Protection
is NOT enabled for the P-GW. So, in this scenario, even if the overcharging condition is met at the S-GW,
the S-GW will not send a MBReq message for Charging pause to the P-GW.
Rf Diameter Accounting
Important In StarOS release 19 and later releases, Rf Diameter Accounting is not supported on the S-GW.
Provides the framework for offline charging in a packet switched domain. The gateway support nodes use
the Rf interface to convey session related, bearer related or service specific charging records to the CGF and
billing domain for enabling charging plans.
The Rf reference interface enables offline accounting functions on the HSGW in accordance with 3GPP
Release 8 specifications. In an LTE application the same reference interface is also supported on the S-GW
and P-GW platforms. The Cisco gateways use the Charging Trigger Function (CTF) to transfer offline
accounting records via a Diameter interface to an adjunct Charging Data Function (CDF) / Charging Gateway
Function (CGF). The HSGW and Serving Gateway collect charging information for each mobile subscriber
UE pertaining to the radio network usage while the P-GW collects charging information for each mobile
subscriber related to the external data network usage.
The S-GW collects information per-user, per IP CAN bearer or per service. Bearer charging is used to collect
charging information related to data volumes sent to and received from the UE and categorized by QoS traffic
class. Users can be identified by MSISDN or IMSI.
Flow Data Records (FDRs) are used to correlate application charging data with EPC bearer usage information.
The FDRs contain application level charging information like service identifiers, rating groups, IMS charging
identifiers that can be used to identify the application. The FDRs also contain the authorized QoS information
(QCI) that was assigned to a given flow. This information is used correlate charging records with EPC bearers.
◦Silent Drop New: Drop the new incoming message, and the old message is processed.
◦Parallel Hndl: Both the original (old) and new messages are handled in parallel.
◦Buffer New: The new message is buffered and processed once the original (old) message processing
is done.
Important The Message Collision Statistics section of the command output appears only if any of the collision
statistics have a counter total that is greater than zero.
Important The session idle timer feature will not work if the Fast Data Path feature is enabled.
Note: Once the trace is provisioned it can be provisioned through the access cloud via various signaling
interfaces.
The session level trace function consists of trace activation followed by triggers. The EPC network element
buffers the trace activation instructions for the provisioned subscriber in memory using camp-on monitoring.
Trace files for active calls are buffered as XML files using non-volatile memory on the local dual redundant
hard drives on the ASR 5500 platform. The Trace Depth defines the granularity of data to be traced. Six levels
are defined including Maximum, Minimum and Medium with ability to configure additional levels based on
vendor extensions.
All call control activity for active and recorded sessions is sent to an off-line Trace Collection Entity (TCE)
using a standards-based XML format over an FTP or secure FTP (SFTP) connection. In the current release
the IPv4 interfaces are used to provide connectivity to the TCE. Trace activation is based on IMSI or IMEI.
Once a subscriber level trace request is activated it can be propagated via the S5/S8 signaling to provision the
corresponding trace for the same subscriber call on the P-GW. The trace configuration will only be propagated
if the P-GW is specified in the list of configured Network Element types received by the S-GW. Trace
configuration can be specified or transferred in any of the following message types:
• S11: Create Session Request
• S11: Trace Session Activation
• S11: Modify Bearer Request
Caution As subscriber level trace is a CPU intensive activity the maximum number of concurrently monitored
trace sessions per Cisco S-GW is 32. Use in a production network should be restricted to minimize the
impact on existing services.
How it Works
The gtpumgr uses the following guidelines while allocating peers:
• When a session installation comes from the Session Manager, a peer is created. If statistics are maintained
at the Session Manager, the gtpumgr also creates the peer record with the statistics.
• Peer records are maintained per service.
• The number of peers is maintained at the gtpumgr instance level. The limit is one million S1-U peers
per gtpumgr instance.
• If the limit of one million peers is exceeded, then peer creation fails. It causes a call installation failure
in the gtpumgr, which leads to an audit failure if an audit is triggered.
The feature changes impact all the interfaces/services using the gtpu-service including
GGSN/S4-SGSN/SGW/PGW/SAEGW/ePDG/SaMOG/HNB-GW/HeNB-GW for:
• The Gn and Gp interfaces of the General Packet Radio Service (GPRS)
• The Iu, Gn, and Gp interfaces of the UMTS system
• The S1-U, S2a, S2b, S4, S5, S8, and S12 interfaces of the Evolved Packet System (EPS)
Recovery/ICSR Considerations
• After a session manager/gtpumgr recovery or after an ICSR switchover, the same set of peers configured
for statistics collection is recovered.
◦Peers with 0 sessions and without statistics are not recovered.
◦Peers with 0 sessions and with statistics are recovered.
◦Peers with Extension Header Support disabled are recovered.
• While upgrading from a previous release, ensure the newer release chassis gtpu peer statistics threshold
is equal to or greater than the previous release. This ensures that the GTPU peer statistics are preserved
during the upgrade. For example, if you are upgrading from release 19.0 to 20.2, and the 19.0 system
has 17,000 GTPU sessions, then configure the threshold on the 20.2 chassis to 17,000 as well.
Configuration/Restrictions
• Due to the large number of GTP-U entities connecting to the StarOS, Cisco recommends disabling the
GTP-U Path Management feature.
• The configured threshold is not the hard upper limit for statistics allocation because of the distributed
nature of system. It is possible that total GTP-U peers with statistics exceeds the configured threshold
value to some extent.
• It is assumed that all 1,000,000 peers are not connected to the node in a point-to-point manner. They
are connected through routers.
• There will not be any ARP table size change for the StarOS to support this feature.
Important For more information on threshold crossing alert configuration, refer to the Thresholding Configuration
Guide.
ULI Enhancements
VoLTE carriers need the last cell/sector updates within the IMS CDRs to assist in troubleshooting customer
complaints due to dropped calls as well as LTE network analysis, performance, fraud detection, and operational
maintenance. The ultimate objective is to get the last cell sector data in the IMS CDR records in addition to
the ULI reporting for session establishment.
To address this issue, the S-GW now supports the following:
• RAN/NAS Cause IE within bearer context of Delete Bearer Command message.
• The S-GW ignores the ULI received as call is going down so there is no point in updating the CDR.
Support for ULI and ULI Timestamp in Delete Bearer Command message had already been added in release
17.0.
Now, when a new ULI is received in the Delete Bearer Command message, a S-GW CDR is initiated.
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 S-GW.
In effect, a direct tunnel reduces data plane latency as the tunnel functionality acts to remove the SGSN from
the data plane and limit the SGSN to the control plane for processing. This improves the user experience (for
example, expedites web page delivery, reduces round trip delay for conversational services). Additionally,
direct tunnel functionality implements the standard SGSN optimization to improve the usage of user plane
resources (and hardware) by removing the requirement from the SGSN to handle the user plane processing.
Typically, the SGSN establishes a direct tunnel at PDP context activation using an Update PDP Context
Request towards the S-GW. This means a significant increase in control plane load on both the SGSN and
S-GW components of the packet core. Hence, deployment requires highly scalable S-GWs since the volume
and frequency of Update PDP Context messages to the S-GW will increase substantially. The ASR 5500
platform capabilities ensure control plane capacity will not be a limiting factor with direct tunnel deployment.
Important For more information on direct tunnel support, refer to the Direct Tunnel for 4G (LTE) Networks chapter
in this guide.
Even though Cisco provides excellent intra-chassis redundancy with these two schemes, certain catastrophic
failures which can cause total chassis outages, such as IP routing failures, line-cuts, loss of power, or physical
destruction of the chassis, cannot be protected by this scheme. In such cases, the MME Inter-Chassis Session
Recovery (ICSR) feature provides geographic redundancy between sites. This has the benefit of not only
providing enhanced subscriber experience even during catastrophic outages, but can also protect other systems
such as the RAN from subscriber re-activation storms.
ICSR allows for continuous call processing without interrupting subscriber services. This is accomplished
through the use of redundant chassis. The chassis are configured as primary and backup with one being active
and one in recovery mode. A checkpoint duration timer is used to control when subscriber data is sent from
the active chassis to the inactive chassis. If the active chassis handling the call traffic goes out of service, the
inactive chassis transitions to the active state and continues processing the call traffic without interrupting the
subscriber session. The chassis determines which is active through a propriety TCP-based connection called
a redundancy link. This link is used to exchange Hello messages between the primary and backup chassis and
must be maintained for proper system operation.
Interchassis Communication
Chassis configured to support ICSR communicate using periodic Hello messages. These messages are sent
by each chassis to notify the peer of its current state. The Hello message contains information about the chassis
such as its configuration and priority. A dead interval is used to set a time limit for a Hello message to be
received from the chassis' peer. If the standby chassis does not receive a Hello message from the active chassis
within the dead interval, the standby chassis transitions to the active state. In situations where the redundancy
link goes out of service, a priority scheme is used to determine which chassis processes the session. The
following priority scheme is used:
• router identifier
• chassis priority
• chassis MAC address
Checkpoint Messages
Checkpoint messages are sent from the active chassis to the inactive chassis. Checkpoint messages are sent
at specific intervals and contain all the information needed to recreate the sessions on the standby chassis, if
that chassis were to become active. Once a session exceeds the checkpoint duration, checkpoint data is collected
on the session. The checkpoint parameter determines the amount of time a session must be active before it is
included in the checkpoint message.
Important For more information on inter-chassis session recovery support, refer to the Interchassis Session Recovery
chapter in System Administration Guide.
Important You must purchase an IPSec license to enable IPSec. For more information on IPSec support, refer to the
IPSec Reference.
Lawful Intercept
The Cisco Lawful Intercept feature is supported on the S-GW. Lawful Intercept is a licensed-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.
Important For more information on VLAN support, refer to the VLANs chapter in the System Administration Guide.
Overcharging Protection helps in avoiding charging the subscribers for dropped downlink packets while the
UE is in idle mode. In some countries, it is a regulatory requirement to avoid such overcharging, so it becomes
a mandatory feature for operators in such countries. Overall, this feature helps ensure subscriber are not
overcharged while the subscriber is in idle mode.
Important This feature is supported on the P-GW, and S-GW. Overcharging Protection is supported on the SAEGW
only if the SAEGW is configured for Pure P or Pure S functionality.
P-GW will never be aware of UE state (idle or connected mode). Charging for downlink data is applicable at
P-GW, even when UE is in idle mode. Downlink data for UE may be dropped at S-GW when UE is in idle
mode due to buffer overflow or delay in paging. Thus, P-GW will charge the subscriber for the dropped
packets, which isn't desired. To address this problem, with Overcharging Protection feature enabled, S-GW
will inform P-GW to stop or resume charging based on packets dropped at S-GW and transition of UE from
idle to active state.
If the S-GW supports the Overcharging Protection feature, then it will send a CSReq with the PDN Pause
Support Indication flag set to 1 in an Indication IE to the P-GW.
If the PGW supports the Overcharging Protection feature then it will send a CSRsp with the PDN Pause
Support Indication flag set to 1 in Indication IE and/or private extension IE to the S-GW.
Once the criterion to signal "stop charging" is met, S-GW will send Modify Bearer Request (MBReq) to
P-GW. MBReq would be sent for the PDN to specify which packets will be dropped at S-GW. The MBReq
will have an indication IE and/or a new private extension IE to send "stop charging" and "start charging"
indication to P-GW. For Pause/Start Charging procedure (S-GW sends MBReq), MBRes from P-GW will
have indication and/or private extension IE with Overcharging Protection information.
When the MBReq with stop charging is received from a S-GW for a PDN, P-GW will stop charging for
downlink packets but will continue sending the packets to S-GW.
P-GW will resume charging downlink packets when either of these conditions is met:
• When the S-GW (which had earlier sent "stop charging" in MBReq) sends "start charging" in MBReq.
• When the S-GW changes (which indicates that maybe UE has relocated to new S-GW).
This feature aligns with the 3GPP TS 29.274: 3GPP Evolved Packet System (EPS); Evolved General Packet
Radio Service (GPRS) Tunneling Protocol for Control plane (GTPv2-C) specification.
For more information on this feature, refer to the Overcharging Protection Support chapter in this guide.
packet. This user-datagram packet DSCP value is sent in DDN message by S-GW to MME/S4-SGSN.
MME/S4-SGSN uses this DSCP value to give paging priority.
Important P-GW and S-GW should apply the PPD feature for both Default and Dedicated bearers. As per the
specifications, P-GW transparently passes the user-datagram packet towards S-GW. This means, if PPD
feature is enabled, operator can't apply different behavior for Default and Dedicated bearers.
Important For more information on paging policy differentiation, refer to the Paging Policy Differentiation chapter
in this guide.
Important 3GPP R12 Load and Overload Support is a license-controlled feature. Contact your Cisco representative
for more information on licensing requirements.
Important For more information on this feature, refer to the GTP-C Load and Overload Control Support on the
P-GW, SAEGW, and S-GW chapter in this guide.
Operation
The node periodically fetches various parameters (for example, License-Session-Utilization,
System-CPU-Utilization and System-Memory-Utilization), which are required for Node level load control
information. The node then calculates the load control information itself either based on the weighted factor
provided by the user or using the default weighted factor.
Node level load control information is calculated every 30 seconds. The resource manager calculates the
system-CPU-utilization and System-Memory-Utilization at a systems level.
For each configured service, load control information can be different. This can be achieved by providing a
weightage to the number of active session counts per service license, for example, ((number of active sessions
per service / max session allowed for the service license) * 100 ).
The node's resource manager calculates the system-CPU-utilization and System-Memory-Utilization at a
systems level by averaging CPU and Memory usage for all cards and which might be different from that
calculated at the individual card level.
a small DPI function to inspect where the traffic comes from using an ID which is assigned from SGW
according to the services. The S-GW distinguishes IMS services using a small DPI function to inspect where
the traffic comes from (for example IP, Port and so on). After the MME receives this ID from the S-GW after
IMS service inspection, the MME will do classified separate paging for each of the services as usual.
Session recovery is also useful for in-service software patch upgrade activities. If session recovery is enabled
during the software patch upgrade, it helps to preserve existing sessions on the active packet services card
during the upgrade process.
Important For more information on session recovery support, refer to the Session Recovery chapter in the System
Administration Guide.
In addition to the above functionality, to be compliant with 3GPP standards, support has been enhanced for
Downlink Data Notification message and Mobility procedures. As a result, DDN message and downlink data
which triggers DDN is not lost. This helps improve paging KPI and VoLTE success rates in scenarios where
DDN is initiated because of SIP invite data.
Important For more information on this functionality, refer to the S-GW Paging Enhancements chapter in this guide.
Step Description
1 The UE initiates the Attach procedure by the transmission of an Attach Request (IMSI or old GUTI,
last visited TAI (if available), UE Network Capability, PDN Address Allocation, Protocol
Configuration Options, Attach Type) message together with an indication of the Selected Network
to the eNodeB. IMSI is included if the UE does not have a valid GUTI available. If the UE has a
valid GUTI, it is included.
Step Description
2 The eNodeB derives the MME from the GUTI and from the indicated Selected Network. If that MME
is not associated with the eNodeB, the eNodeB selects an MME using an MME selection function.
The eNodeB forwards the Attach Request message to the new MME contained in a S1-MME control
message (Initial UE message) together with the Selected Network and an indication of the E-UTRAN
Area identity, a globally unique E-UTRAN ID of the cell from where it received the message to the
new MME.
3 If the UE is unknown in the MME, the MME sends an Identity Request to the UE to request the IMSI.
4 The UE responds with Identity Response (IMSI).
5 If no UE context for the UE exists anywhere in the network, authentication is mandatory. Otherwise
this step is optional. However, at least integrity checking is started and the ME Identity is retrieved
from the UE at Initial Attach. The authentication functions, if performed this step, involves AKA
authentication and establishment of a NAS level security association with the UE in order to protect
further NAS protocol messages.
6 The MME sends an Update Location (MME Identity, IMSI, ME Identity) to the HSS.
7 The HSS acknowledges the Update Location message by sending an Update Location Ack to the
MME. This message also contains the Insert Subscriber Data (IMSI, Subscription Data) Request.
The Subscription Data contains the list of all APNs that the UE is permitted to access, an indication
about which of those APNs is the Default APN, and the EPS subscribed QoS profile for each permitted
APN. If the Update Location is rejected by the HSS, the MME rejects the Attach Request from the
UE with an appropriate cause.
8 The MME selects an S-GW using the Serving GW selection function and allocates an EPS Bearer
Identity for the Default Bearer associated with the UE. If the PDN subscription context contains no
P-GW address the MME selects a P-GW as described in clause PDN GW selection function. Then
it sends a Create Default Bearer Request (IMSI, MME Context ID, APN, RAT type, Default Bearer
QoS, PDN Address Allocation, AMBR, EPS Bearer Identity, Protocol Configuration Options, ME
Identity, User Location Information) message to the selected S-GW.
9 The S-GW creates a new entry in its EPS Bearer table and sends a Create Default Bearer Request
(IMSI, APN, S-GW Address for the user plane, S-GW TEID of the user plane, S-GW TEID of the
control plane, RAT type, Default Bearer QoS, PDN Address Allocation, AMBR, EPS Bearer Identity,
Protocol Configuration Options, ME Identity, User Location Information) message to the P-GW.
10 If dynamic PCC is deployed, the P-GW interacts with the PCRF to get the default PCC rules for the
UE. The IMSI, UE IP address, User Location Information, RAT type, AMBR are provided to the
PCRF by the P-GW if received by the previous message.
11 The P-GW returns a Create Default Bearer Response (P-GW Address for the user plane, P-GW TEID
of the user plane, P-GW TEID of the control plane, PDN Address Information, EPS Bearer Identity,
Protocol Configuration Options) message to the S-GW. PDN Address Information is included if the
P-GW allocated a PDN address Based on PDN Address Allocation received in the Create Default
Bearer Request. PDN Address Information contains an IPv4 address for IPv4 and/or an IPv6 prefix
and an Interface Identifier for IPv6. The P-GW takes into account the UE IP version capability
indicated in the PDN Address Allocation and the policies of operator when the P-GW allocates the
PDN Address Information. Whether the IP address is negotiated by the UE after completion of the
Attach procedure, this is indicated in the Create Default Bearer Response.
12 The Downlink (DL) Data can start flowing towards S-GW. The S-GW buffers the data.
Step Description
13 The S-GW returns a Create Default Bearer Response (PDN Address Information, S-GW address for
User Plane, S-GW TEID for User Plane, S-GW Context ID, EPS Bearer Identity, Protocol
Configuration Options) message to the new MME. PDN Address Information is included if it was
provided by the P-GW.
14 The new MME sends an Attach Accept (APN, GUTI, PDN Address Information, TAI List, EPS
Bearer Identity, Session Management Configuration IE, Protocol Configuration Options) message
to the eNodeB.
15 The eNodeB sends Radio Bearer Establishment Request including the EPS Radio Bearer Identity to
the UE. The Attach Accept message is also sent along to the UE.
16 The UE sends the Radio Bearer Establishment Response to the eNodeB. In this message, the Attach
Complete message (EPS Bearer Identity) is included.
17 The eNodeB forwards the Attach Complete (EPS Bearer Identity) message to the MME.
18 The Attach is complete and UE sends data over the default bearer. At this time the UE can send uplink
packets towards the eNodeB which are then tunneled to the S-GW and P-GW.
19 The MME sends an Update Bearer Request (eNodeB address, eNodeB TEID) message to the S-GW.
20 The S-GW acknowledges by sending Update Bearer Response (EPS Bearer Identity) message to the
MME.
21 The S-GW sends its buffered downlink packets.
22 After the MME receives Update Bearer Response (EPS Bearer Identity) message, if an EPS bearer
was established and the subscription data indicates that the user is allowed to perform handover to
non-3GPP accesses, and if the MME selected a P-GW that is different from the P-GW address which
was indicated by the HSS in the PDN subscription context, the MME sends an Update Location
Request including the APN and P-GW address to the HSS for mobility with non-3GPP accesses.
23 The HSS stores the APN and P-GW address pair and sends an Update Location Response to the
MME.
24 Bidirectional data is passed between the UE and PDN.
Subscriber-initiated Detach
This section describes the procedure of detachment from the EPC network by a subscriber.
Step Description
1 The UE sends NAS message Detach Request (GUTI, Switch Off) to the MME. Switch Off indicates
whether detach is due to a switch off situation or not.
2 The active EPS Bearers in the S-GW regarding this particular UE are deactivated by the MME sending
a Delete Bearer Request (TEID) message to the S-GW.
3 The S-GW sends a Delete Bearer Request (TEID) message to the P-GW.
4 The P-GW acknowledges with a Delete Bearer Response (TEID) message.
5 The P-GW may interact with the PCRF to indicate to the PCRF that EPS Bearer is released if PCRF
is applied in the network.
6 The S-GW acknowledges with a Delete Bearer Response (TEID) message.
7 If Switch Off indicates that the detach is not due to a switch off situation, the MME sends a Detach
Accept message to the UE.
8 The MME releases the S1-MME signaling connection for the UE by sending an S1 Release command
to the eNodeB with Cause = Detach.
Supported Standards
The S-GW service complies with some of the standards in the following standards categories:
• 3GPP References, on page 51
3GPP References
Important The S-GW currently supports the following Release 12 3GPP specifications. Most 3GPP specifications
are also used for 3GPP2 support; any specifications that are unique to 3GPP2 are listed under 3GPP2
References.
Important The S-GW currently supports the following Release 11 3GPP specifications. Most 3GPP specifications
are also used for 3GPP2 support; any specifications that are unique to 3GPP2 are listed under 3GPP2
References.
Important The S-GW currently supports the following Release 10 3GPP specifications. Most 3GPP specifications
are also used for 3GPP2 support; any specifications that are unique to 3GPP2 are listed under 3GPP2
References.
• 3GPP TS 24.008: Mobile radio interface Layer 3 specification; Core network protocols
• 3GPP TS 24.229: IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3
• 3GPP TS 29.210. Gx application
• 3GPP TS 29.212: Policy and Charging Control over Gx reference point
• 3GPP TS 29.213: Policy and Charging Control signaling flows and QoS
• 3GPP TS 29.214: Policy and Charging Control over Rx reference point
• 3GPP TS 29.274 V8.1.1 (2009-03): 3GPP Evolved Packet System (EPS); Evolved General Packet Radio
Service (GPRS) Tunneling Protocol for Control plane (GTPv2-C); Stage 3 (Release 8)
• 3GPP TS 29.274: Evolved GPRS Tunneling Protocol for Control plane (GTPv2-C), version 8.2.0 (both
versions are intentional)
• 3GPP TS 29.275: Proxy Mobile IPv6 (PMIPv6) based Mobility and Tunneling protocols, version 8.1.0
• 3GPP TS 29.281: GPRS Tunneling Protocol User Plane (GTPv1-U)
• 3GPP TS 32.251: Telecommunication management; Charging management; Packet Switched (PS)
domain charging
• 3GPP TS 32.295: Charging management; Charging Data Record (CDR) transfer
• 3GPP TS 32.298: Telecommunication management; Charging management; Charging Data Record
(CDR) encoding rules description
• 3GPP TS 32.299: Charging management; Diameter charging applications
• 3GPP TS 33.106: 3G Security; Lawful Interception Requirements
• 3GPP TS 36.107: 3G security; Lawful interception architecture and functions
• 3GPP TS 36.300: Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal
Terrestrial Radio Access Network (E-UTRAN); Overall description
• 3GPP TS 36.412. EUTRAN S1 signaling transport
• 3GPP TS 36.413: Evolved Universal Terrestrial Radio Access (E-UTRA); S1 Application Protocol
(S1AP)
• 3GPP TS 36.414: Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 data transport
3GPP2 References
• X.P0057-0 v0.11.0 E-UTRAN - eHRPD Connectivity and Interworking: Core Network Aspects
IETF References
• RFC 768: User Datagram Protocol (STD 6).
• RFC 791: Internet Protocol (STD 5).
• RFC 2131: Dynamic Host Configuration Protocol
Important Information about all commands in this chapter can be found in the Command Line Interface Reference.
Because each wireless network is unique, the system is designed with a variety of parameters allowing it to
perform in various wireless network environments. In this chapter, only the minimum set of parameters are
provided to make the system operational. Optional configuration commands specific to the S-GW product
are located in the Command Line Interface Reference.
This chapter includes the following topics:
Information Required
The following sections describe the minimum amount of information required to configure and make the
S-GW operational on the network. To make the process more efficient, you should have this information
available prior to configuring the system.
There are additional configuration parameters that are not described in this section. These parameters deal
mostly with fine-tuning the operation of the S-GW in the network. Information on these parameters can be
found in the appropriate sections of the Command Line Interface Reference.
Interface name An identification string between 1 and 79 characters (alpha and/or numeric)
by which the interface will be recognized by the system.
Multiple names are needed if multiple interfaces will be configured.
Physical port number The physical port to which the interface will be bound. Ports are identified
by the chassis slot number where the line card resides followed by the
number of the physical connector on the card. For example, port 17/1
identifies connector number 1 on the card in slot 17.
A single physical port can facilitate multiple interfaces.
Gateway IP address Used when configuring static IP routes from the management interface(s)
to a specific network.
Security administrator name The name or names of the security administrator with full rights to the
system.
Remote access type(s) The type of remote access that will be used to access the system such as
telnetd, sshd, and/or ftpd.
Accounting policy name An identification string from 1 to 63 characters (alpha and/or numeric) by
which the accounting policy is recognized by the system. The accounting
policy is used to set parameters for the Rf (off-line charging) interface.
Physical port number The physical port to which the interface will be bound. Ports are identified
by the chassis slot number where the line card resides followed by the
number of the physical connector on the card. For example, port 17/1
identifies connector number 1 on the card in slot 17.
A single physical port can facilitate multiple interfaces.
Gateway IP address Used when configuring static IP routes from the interface(s) to a specific
network.
Gateway IP address Used when configuring static IP routes from the interface(s) to a specific
network.
GTP-U service name (for An identification string from 1 to 63 characters (alpha and/or numeric) by
S1-U/S11 interface) which the GTP-U service bound to the S1-U/S11 interface will be
recognized by the system.
S-GW service name An identification string from 1 to 63 characters (alpha and/or numeric) by
which the S-GW service is recognized by the system.
Multiple names are needed if multiple S-GW services will be used.
eGTP S1-U/S11 ingress service An identification string from 1 to 63 characters (alpha and/or numeric) by
name which the eGTP S1-U/S11 ingress service is recognized by the system.
Interface name An identification string between 1 and 79 characters (alpha and/or numeric)
by which the interface is recognized by the system.
Multiple names are needed if multiple interfaces will be configured.
Physical port number The physical port to which the interface will be bound. Ports are identified
by the chassis slot number where the line card resides followed by the
number of the physical connector on the card. For example, port 17/1
identifies connector number 1 on the card in slot 17.
A single physical port can facilitate multiple interfaces.
Gateway IP address Used when configuring static IP routes from the interface(s) to a specific
network.
GTP-U service name (for S5/S8 An identification string from 1 to 63 characters (alpha and/or numeric) by
interface) which the GTP-U service bound to the S5/S8 interface will be recognized
by the system.
eGTP Egress Service Name An identification string from 1 to 63 characters (alpha and/or numeric) by
which the eGTP egress service is recognized by the system.
Figure 16: eGTP S-GW Call Processing Using a Single Ingress and Egress Context
1 A subscriber session from the MME is received by the S-GW service over the S11 interface.
2 The S-GW service determines which context to use to access PDN services for the session. This process
is described in the How the System Selects Contexts section located in the Understanding the System
Operation and Configuration chapter of the System Administration Guide.
3 S-GW uses the configured egress context to determine the eGTP service to use for the outgoing S5/S8
connection.
4 The S-GW establishes the S5/S8 connection by sending a create session request message to the P-GW.
5 The P-GW responds with a Create Session Response message that includes the PGW S5/S8 Address for
control plane and bearer information.
6 The S-GW conveys the control plane and bearer information to the MME in a Create Session Response
message.
7 The MME responds with a Create Bearer Response and Modify Bearer Request message.
8 The S-GW sends a Modify Bearer Response message to the MME.
Step 1 Set system configuration parameters such as activating PSCs by applying the example configurations found in the System
Administration Guide.
Step 2 Set initial configuration parameters such as creating contexts and services by applying the example configurations found
in theInitial Configuration, on page 61.
Step 3 Configure the system to perform as an eGTP S-GW and set basic S-GW parameters such as eGTP interfaces and an IP
route by applying the example configurations presented in the eGTP Configuration, on page 63.
Step 4 Verify and save the configuration by following the instruction in the Verifying and Saving the Configuration, on page
64.
Initial Configuration
Step 1 Set local system management parameters by applying the example configuration in the Modifying the Local Context,
on page 61.
Step 2 Create an ingress context where the S-GW and eGTP ingress service will reside by applying the example configuration
in the Creating an S-GW Ingress Context, on page 61.
Step 3 Create an eGTP ingress service within the newly created ingress context by applying the example configuration in the
Creating an eGTP Ingress Service, on page 62.
Step 4 Create an S-GW egress context where the eGTP egress services will reside by applying the example configuration in
the Creating an S-GW Egress Context, on page 62.
Step 5 Create an eGTP egress service within the newly created egress context by applying the example configuration in the
Creating an eGTP Egress Service, on page 63.
Step 6 Create a S-GW service within the newly created ingress context by applying the example configuration in the Creating
an S-GW Service, on page 63.
exit
interface <s1u-s11_interface_name>
ip address <ipv4_address_primary>
ip address <ipv4_address_secondary>
exit
ip route 0.0.0.0 0.0.0.0 <next_hop_address> <sgw_interface_name>
exit
port ethernet <slot_number/port_number>
no shutdown
bind interface <s1u-s11_interface_name> <ingress_context_name>
end
Notes:
• This example presents the S1-U/S11 connections as a shared interface. These interfaces can be separated
to support a different network architecture.
• The S1-U/S11 interface IP address(es) can also be specified as IPv6 addresses using the ipv6 address
command.
eGTP Configuration
Step 1 Set the system's role as an eGTP S-GW and configure eGTP service settings by applying the example configuration in
the Setting the System's Role as an eGTP S-GW and Configuring GTP-U and eGTP Service Settings, on page 63.
Step 2 Configure the S-GW service by applying the example configuration in the Configuring the S-GW Service, on page 64.
Step 3 Specify an IP route to the eGTP Serving Gateway by applying the example configuration in the Configuring an IP Route,
on page 64.
Setting the System's Role as an eGTP S-GW and Configuring GTP-U and eGTP Service Settings
Use the following configuration example to set the system to perform as an eGTP S-GW and configure the
GTP-U and eGTP services:
configure
context <sgw_ingress_context_name>
gtpp group default
exit
gtpu-service <gtpu_ingress_service_name>
bind ipv4-address <s1-u_s11_interface_ip_address>
exit
egtp-service <egtp_ingress_service_name>
interface-type interface-sgw-ingress
validation-mode default
associate gtpu-service <gtpu_ingress_service_name>
gtpc bind address <s1u-s11_interface_ip_address>
exit
exit
context <sgw_egress_context_name>
gtpu-service <gtpu_egress_service_name>
bind ipv4-address <s5s8_interface_ip_address>
exit
egtp-service <egtp_egress_service_name>
interface-type interface-sgw-egress
validation-mode default
associate gtpu-service <gtpu_egress_service_name>
gtpc bind address <s5s8_interface_ip_address>
end
Notes:
• The bind command in the GTP-U ingress and egress service configuration can also be specified as an
IPv6 address using the ipv6-address command.
Configuring an IP Route
Use the following example to configure an IP Route for control and user plane data communication with an
eGTP PDN Gateway:
configure
context <egress_context_name>
ip route <pgw_ip_addr/mask> <sgw_next_hop_addr> <sgw_intrfc_name>
end
eGTP-C
configure
context <context_name>
egtp-service <egtp_service_name>
gtpc echo-interval <seconds>
gtpc echo-retransmission-timeout <seconds>
gtpc max-retransmissions <num>
end
Notes:
• This configuration can be used in either the ingress context supporting the S1-U and/or S11 interfaces
with the eNodeB and MME respectively; and the egress context supporting the S5/S8 interface with the
P-GW.
• The following diagram describes a failure and recovery scenario using default settings of the three gtpc
commands in the example above:
GTP-U
configure
context <context_name>
gtpu-service <gtpu_service_name>
echo-interval <seconds>
echo-retransmission-timeout <seconds>
max-retransmissions <num>
end
Notes:
• This configuration can be used in either the ingress context supporting the S1-U interfaces with the
eNodeB and the egress context supporting the S5/S8 interface with the P-GW.
• The following diagram describes a failure and recovery scenario using default settings of the three
GTP-U commands in the example above:
eGTP-C
configure
context <context_name>
egtp-service <egtp_service_name>
gtpc echo-interval <seconds> dynamic smooth-factor <multiplier>
gtpc echo-retransmission-timeout <seconds>
gtpc max-retransmissions <num>
end
Notes:
• This configuration can be used in either the ingress context supporting the S1-U and/or S11 interfaces
with the eNodeB and MME respectively; and the egress context supporting the S5/S8 interface with the
P-GW.
• The following diagram describes a failure and recovery scenario using default settings of the three gtpc
commands in the example above and an example round trip timer (RTT) of six seconds:
• The multiplier (x2) and the 100 second maximum are system-coded and cannot be configured.
GTP-U
configure
context <context_name>
gtpu-service <gtpu_service_name>
echo-interval <seconds> dynamic smooth-factor <multiplier>
echo-retransmission-timeout <seconds>
max-retransmissions <num>
end
Notes:
• This configuration can be used in either the ingress context supporting the S1-U interfaces with the
eNodeB and the egress context supporting the S5/S8 interface with the P-GW.
• The following diagram describes a failure and recovery scenario using default settings of the three gtpc
commands in the example above and an example round trip timer (RTT) of six seconds:
• The multiplier (x2) and the 100 second maximum are system-coded and cannot be configured.
Important In StarOS release 19 and later releases, Diameter Offline Accounting is not supported on the S-GW.
configure
operator-policy name <policy_name>
associate call-control-profile <call_cntrl_profile_name>
exit
call-control-profile <call_cntrl_profile_name>
accounting mode radius-diameter
exit
lte-policy
subscriber-map <map_name>
precendence <number> match-criteria all operator-policy-name <policy_name>
exit
exit
context <ingress_context_name>
policy accounting <rf_policy_name>
accounting-level {type}
operator-string <string>
exit
sgw-service <sgw_service_name>
associate accounting-policy <rf_policy_name>
associate subscriber-map <map_name>
exit
aaa group <rf-radius_group_name>
radius attribute nas-identifier <id>
radius accounting interim interval <seconds>
radius dictionary <name>
radius mediation-device accounting server <address> key <key>
diameter authentication dictionary <name>
diameter accounting dictionary <name>
diameter accounting endpoint <rf_cfg_name>
diameter accounting server <rf_cfg_name> priority <num>
exit
diameter endpoint <rf_cfg_name>
use-proxy
origin realm <realm_name>
origin host <name> address <rf_ipv4_address>
peer <rf_cfg_name> realm <name> address <ofcs_ipv4_or_ipv6_addr>
route-entry peer <rf_cfg_name>
exit
exit
context <ingress_context_name>
interface <rf_interface_name>
ip address <rf_ipv4_address>
exit
exit
port ethernet <slot_number/port_number>
no shutdown
bind interface <rf_interface_name> <ingress_context_name>
end
Notes:
• accounting-level types are: flow, PDN, PDN-QCI, QCI, and subscriber. Refer to the Accounting Profile
Configuration Mode Commands chapter in the Command Line Interface Reference for more information
on this command.
• The Rf interface IP address can also be specified as an IPv6 address using the ipv6 address command.
Important Use of the IP Security feature requires that a valid license key be installed. Contact your local Sales or
Support representative for information on how to obtain a license.
The following configuration example enables X.509 certificate-based peer authentication on the S-GW.
In Global Configuration Mode, specify the name of the X.509 certificate and CA certificate, as follows:
configure
certificate name <cert_name> pem url <cert_pem_url> private-key pem url <private_key_url>
When creating the crypto template for IPSec in Context Configuration Mode, bind the X.509 certificate and
CA certificate to the crypto template and enable X.509 certificate-based peer authentication for the local and
remote nodes, as follows:
configure
context <sgw_context_name>
crypto template <crypto_template_name> ikev2-dynamic
certificate name <cert_name>
ca-certificate list ca-cert-name <ca_cert_name>
authentication local certificate
authentication remote certificate
end
Notes:
• A maximum of sixteen certificates and sixteen CA certificates are supported per system. One certificate
is supported per service, and a maximum of four CA certificates can be bound to one crypto template.
• The certificate name and ca-certificate list ca-cert-name commands bind the certificate and CA
certificate to the crypto template.
• The authentication local certificate and authentication remote certificate commands enable X.509
certificate-based peer authentication for the local and remote nodes.
Important Use of the IP Security feature requires that a valid license key be installed. Contact your local Sales or
Support representative for information on how to obtain a license.
mode tunnel
end
Notes:
• The encryption algorithm, aes-cbc-128, or Advanced Encryption Standard Cipher Block Chaining, is
the default algorithm for IPSec transform sets configured on the system.
• The group none command specifies that no crypto strength is included and that Perfect Forward Secrecy
is disabled. This is the default setting for IPSec transform sets configured on the system.
• The hmac command configures the Encapsulating Security Payload (ESP) integrity algorithm. The
sha1-96 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default
setting for IPSec transform sets configured on the system.
• The mode tunnel command specifies that the entire packet is to be encapsulated by the IPSec header,
including the IP header. This is the default setting for IPSec transform sets configured on the system.
Important Use of the IP Security feature requires that a valid license key be installed. Contact your local Sales or
Support representative for information on how to obtain a license.
• The type of crypto map used in this example is IKEv2-IPv4 for IPv4 addressing. An IKEv2-IPv6 crypto
map can also be used for IPv6 addressing.
• The ipsec transform-set list command specifies up to four IPSec transform sets.
The following example configures an IKEv2 crypto map and applies it to the S5 interface:
configure
context <sgw_egress_context_name>
crypto map <crypto_map_name> ikev2-ipv4
match address <acl_name>
peer <ipv4_address>
authentication local pre-shared-key key <text>
authentication remote pre-shared-key key <text>
payload <name> match ipv4
lifetime <seconds>
ipsec transform-set list <name1> . . . <name4>
exit
exit
interface <s5_intf_name>
ip address <ipv4_address>
crypto map <crypto_map_name>
exit
exit
port ethernet <slot_number/port_number>
no shutdown
bind interface <s5_intf_name> <sgw_egress_context_name>
end
Notes:
• The type of crypto map used in this example is IKEv2-IPv4 for IPv4 addressing. An IKEv2-IPv6 crypto
map can also be used for IPv6 addressing.
• The ipsec transform-set list command specifies up to four IPSec transform sets.
• The inclusion-frequency parameter determines how often the Load control information element is sent
to the peer(s).
• The total of the three weightage parameters should not exceed 100.
• The associate command is used to associate the Load Control Profile with an existing S-GW service.
exit
port ethernet <slot_number/port_number>
no shutdown
bind interface <s4_interface_name> <ingress_context_name>
exit
context <ingress_context_name> -noconfirm
gtpu-service <s4_gtpu_ingress_service_name>
bind ipv4-address <s4_interface_ip_address>
exit
egtp-service <s4_egtp_ingress_service_name>
interface-type interface-sgw-ingress
validation-mode default
associate gtpu-service <s4_gtpu_ingress_service_name>
gtpc bind address <s4_interface_ip_address>
exit
sgw-service <sgw_service_name> -noconfirm
associate ingress egtp-service <s4_egtp_ingress_service_name>
end
Notes:
• The S4 interface IP address(es) can also be specified as IPv6 addresses using the ipv6 address command.
View eGTP-C service statistics for a specific show egtpc statistics egtpc-service name
service
View GTP-U service statistics for all GTP-U data show gtpu statistics
traffic on the system
Table 12: New and Modified System Event Logs with IMSI/IMEI in System Event Log Details
12225 Represents misc_error3 in format "[IMSI <IMSI>] Misc Error3: s, error code d"
Modified Events
10034 Represents FSM error in format "[IMSI <IMSI>] default call fsm error: ostate=s(d)
state=s(d) event=s(d)"
10035 Represents FSM INVALID event in format "[IMSI <IMSI>] default call fsm invalid
event: state=s(d) event=s(d)"
12668 Represents fsm_event_error in format "[IMSI <IMSI>] Misc Error: Bad event in
sessmgr fsm, event code d"
12860 Represents ncqos_sec_rej in format "[IMSI <IMSI>] NCQOS Secondary ctxt with
nsapi <u> rejected, due to <s>."
12861 Represents ncqos_upc_rej in format "[IMSI <IMSI>] UPC Rejected for ctxt with
nsapi <u>, due to <s>."
11293 Represents collision_error in format "[IMSI <IMSI>] Collision Error: Temp Failure
Handling Delayed Pending Active Transaction: , error code d"
• no disables the inclusion of the IMSI/IMEI in system event logs of type error and critical
• To determine if logging include-ueid is enabled on the S-GW, use the show configuration command
in Exec Mode. This command will indicate one of the following:
◦logging include-ueid (when enabled)
◦no logging include-ueid (when disabled)
Feature Description
GTPv2 message collisions occur in the network when a node is expecting a particular procedure message
from a peer node but instead receives a different procedure message from the peer. GTP procedure collisions
are quite common in the network; especially with dynamic Policy and Charging Control, the chances of
collisions happening in the network are very high.
These collisions are tracked by statistics and processed based on a pre-defined action for each message collision
type. These statistics assist operators in debugging network issues.
Important If the SAEGW is configured as a pure P-GW or a pure S-GW, operators will see the respective collision
statistics if they occur.
How It Works
Collision Handling
As GTPv2 message collisions occur, they are processed by the P-GW, SAEGW, and S-GW. They are also
tracked by statistics and with information on how the collision was handled.
Specifically, the output of the show egtpc statistics verbose command has been enhanced to provide information
on GTPv2 message collision tracking and handling at the S-GW and P-GW ingress interfaces, The information
available includes:
• Interface: The interface on which the collision occurred: SGW (S4/S11), SGW (S5) and P-GW (S8).
• Old Proc (Msg Type): Indicates the ongoing procedure at eGTP-C when a new message arrived at the
interface which caused the collision. The Msg Type in brackets specifies which message triggered this
ongoing procedure. Note that the Old Proc are per 3GPP TS 23.401.
• New Proc (Msg Type): The new procedure and message type. Note that the New Proc are per 3GPP
TS 23.401.
• Action: The pre-defined action taken to handle the collision. The action can be one of:
◦No Collision Detected
◦Suspend Old: Suspend processing of the original (old) message, process the new message, then
resume old message handling.
◦Abort Old: Abort the original message handling and processes the new message.
◦Reject New: Reject the new message, and process the original (old) message.
◦Silent Drop New: Drop the new incoming message, and the process the old message.
◦Parallel Hndl: Handle both the original (old) and new messages in parallel.
◦Buffer New: Buffer the new message and process it once the original (old) message has been
processed.
◦Counter: The number of times each collision type has occurred.
Important The Message Collision Statistics section of the command output appears only if any of the collision
statistics have a counter total that is greater than zero.
Sample output:
Message Collision Statistics
Interface Old Proc (Msg Type) New Proc (Msg Type) Action Counter
SGW(S5) NW Init Bearer Create (95) NW Init PDN Delete (99) Abort Old 1
In this instance, the output states that at the S-GW egress interface (S5) a Bearer creation procedure is going
on due to a CREATE BEARER REQUEST(95) message from the P-GW. Before its response comes to the
S-GW from the MME, a new procedure PDN Delete is triggered due to a DELETE BEARER REQUEST(99)
message from the P-GW.
The action that is carried out due to this collision at the eGTP-C layer is to abort (Abort Old) the Bearer
Creation procedure and carry on normally with the Initiate PDN Delete procedure. The Counter total of 1
indicates that this collision happened once.
The CLI command collision handling provides more flexibility in configuring the handling of the DBCmd
message and MBReq message collision scenario. Also refer to Configuring DBcmd Message Behavior, on
page 90 in this document for instructions on how to configure the behavior for this collision handling scenario.
MBReq/CBreq Parallel Processing; Handling CBRsp:
The P-GW/S-GW has handles the following example collision scenario:
The node queues the CBRsp message and feeds the CBRsp message to the P-GW/S-GW session manager
when the MBRsp is sent out. As a result, operators will see no retransmission of CBRsp messages from the
MME.
Handling UBrsp when Transaction is Suspended:
The P-GW/S-GW handles the following example collision scenario:
When the P-GW/S-GW receives an UBRsp message, then the P-GW/S-GW handles the UBRsp message for
the suspended transaction. As a result, The UBRsp message will be buffered until the MBRsp message is sent
out.
Limitations
There are no known limitations to the collision handling feature on the P-GW/SAEGW/S-GW.
Standards Compliance
Specifications and standards do not specify any hard rules for collision handling cases.
Important Configuration via the CLI is not required for all other P-GW and S-GW collision handling scenarios.
show configuration
The output of this command indicates if collision handling for the DBcmd message when the MBreq message
is pending is enabled or disabled.
• collision-handling dbcmd-over-mbreq queue
• no collision-handling dbcmd-over-mbreq queue
Important The Message Collision Statistics section of the command output appears only if any of the collision
statistics have a counter total that is greater than zero.
Important For detailed information for session tracing on the MME, refer to the MME Administration Guide.
The product Administration Guides provide examples and procedures for configuration of basic services on
the system. It is recommended that you select the configuration example that best meets your service model,
and configure the required elements for that model, as described in the respective product Administration
Guide, before using the procedures in this chapter.
This chapter includes a feature description, configuration procedures, monitoring commands, and a session
tracing file example.
initiated from the CLI (Command Line Interface) and can be propagated throughout the access cloud via the
various signaling interfaces available to the UMTS/EPC network element.
Essentially, the Session Trace capability records and forwards all control activity for the monitored subscriber
on the monitored interfaces. This is typically all the signaling and authentication/subscriber services messages
that flow when a User Equipment (UE) connects to the access network.
All monitored activity is sent to an off-line Trace Collection Entity (TCE) using a standards-based XML
format over a File Transfer Protocol (FTP) or secure FTP (sFTP) connection.
Important Session tracing is a resource intensive application in terms of CPU utilization and will affect call rates
and data throughput when in use. The use of this feature in a production network should be restricted to
minimize the impact on existing services.
Important For 19.2 and prior StarOS releases, both the FTP and SFTP options are available. In release 20.0 and
higher trusted StarOS builds only the SFTP option is supported; FTP is not supported for the Session
Trace function in release 20.0 and higher trusted StarOS builds.
As can be seen in the following illustration, of the three Network Elements (NEs) shown, one NE is actively
tracing data on one or more interfaces. All data collected is stored as files in an XML format and then transferred
to the collection entity using (S)FTP or FTP. Note that IPv4 or IPv6 connectivity is required between the NE
and the TCE in order to transfer the files.
• Signaling Trace: With a signaling based activation, the trace session is indicated to the UMTS/EPC
network element across a signaling interface via a trace invocation message. This message can either
be piggybacked with an existing bearer setup message (in order to trace all control messages) or by
sending a separate trace invocation message (if the user is already active). Signaling based activations
are always propagated to neighboring NEs even if the current NE does not participate in the trace (either
they not enabled by configuration or not present in the configured trace parameters).
Important Note that the maximum number of unique International Mobile Subscriber Identification (IMSI) numbers
or International Mobile Equipment Identification (IMEI) numbers cannot exceed 32; however, each NE
can trace all 32 unique IMSI/IMEIs.
Caution Session tracing is a resource intensive application in terms of CPU utilization and will affect call rates
and data throughput when in use. The use of this feature in a production network should be restricted to
minimize the impact on existing services.
Data Collection
Data collection is done inline by each of the NEs. In order to reduce the overhead on a per-control packet
basis, a copy of the entire packet is made and stored into an internal database (DB) of packets.
The local internal path for the trace database is /hd-raid/trace.
This storage is done regardless of the trace depth. After xx bytes (or xx messages) have been stored or a
configurable number of seconds have elapsed, all cached data is encoded in the standard XML format and
written out to a file to be forwarded to/pulled from the TCE. If there is no TCE active, the UMTS/EPC network
element will continue to cache data and create trace files as long as there is space available before stopping
the trace recording session. Once the connection to the TCE becomes active, all cached data will be sent
immediately to the TCE.
Data Forwarding
When a session is activated, the IP address of the TCE is supplied in the session activation request. Upon
activation and if the push mode is used, a check is made to see if there is already an (S)FTP connection to the
TCE. If so, it is used for all traffic associated with this trace session. If not, an (S)FTP connection is made to
the TCE using the supplied IP address. Data is buffered locally and trace files generated until the connection
is established. Once the connection is established, all previously created trace files are sent to the TCE. Note
that the (S)FTP connection is established to the TCE at session activation regardless of whether or not a trace
recording session has been triggered. The (S)FTP connection is maintained until the trace session is deactivated.
Note the following:
• If a default TCE IP Address is supplied when the trace capability is configured, a default (S)FTP
connection is made to the remote TCE.
• The TCE can be reachable either via IPv4 or IPv6 addressing. The supplied TCE address indicates the
version.
• If the push mode is not used, the files are stored on the local hard drive (/hd-raid/trace) and must be
pulled off by the TCE using FTP or SFTP.
Supported Standards
Support for the following standards and requests for comments (RFCs) have been added for the Session Trace
feature:
• 3GPP TS 32.421 V8.5.0 (2009-06): 3rd Generation Partnership Project; Technical Specification Group
Services and System Aspects; Telecommunication management; Subscriber and equipment trace: Trace
concepts and requirements (Release 8)
• 3GPP TS 32.422 V8.6.0 (2009-09): 3rd Generation Partnership Project; Technical Specification Group
Services and System Aspects; Telecommunication management; Subscriber and equipment trace; Trace
control and configuration management (Release 8)
• 3GPP TS 32.423 V8.2.0 (2009-09): 3rd Generation Partnership Project; Technical Specification Group
Services and System Aspects; Telecommunication management; Subscriber and equipment trace: Trace
data definition and management (Release 8)
Important Not all combinations of Session Trace configuration types are allowed on the SAEGW. For details on the
supported session trace configuration types, refer to Supported SAEGW Session Trace Configurations,
on page 109 in this document.
• retry-timer: Specifies the amount of time, in seconds, to wait before retrying a file transfer if the previous
transfer failed. The default is 60 seconds.
Example:
session trace network-element saegw tce-mode push transport sftp path /SessionTrace username
root encrypted password 5c4a38dc2ff61f72 collection-timer 5
Important The options available in Session Trace Template Configuration Mode are dependent on the network
element selected in the previous command.
For the GGSN, MME, P-GW and S-GW, enter the following command in Session Trace Template
Configuration Mode:
interface interface_name
end
For the SAEGW, enter the following command in Session Trace Template Configuration Mode:
{ func-pgw | func-sgw } interface interface_name
end
• Notes: The available UMTS/EPC network elements provide various interface options for the session
trace template.
GGSN
Available ggsn interfaces include:
• all: Specifies that all available GGSN interfaces are to be traced.
• gi: Specifies that the interface where the trace will be performed is the Gi interface between the GGSN
and RADIUS server.
• gmb: Specifies that the interface where the trace will be performed is the Gmb interface between the
GGSN and BM-SC.
• gn: Specifies that the interface where the trace will be performed is the Gn interface between the GGSN
and the SGSN.
• gx: Specifies that the interface where the trace will be performed is the Gx interface between the GGSN
and PCRF.
• gy: Specifies that the interface where the trace will be performed is the Gx interface between the GGSN
and PCRF.
HNBGW
Available hnbgw interfaces are:
• all: Specifies that all hnbgw interfaces are to be traced.
• iucs: Specifies that the interface where the trace will be performed is the iucs interface between the
HNB-GW and the Mobile Switching Center (3G MSC) in a 3G UMTS Femtocell Access Network.
• iups: Specifies that the interface where the trace will be performed is the iups interface between the
HNB-GW and the SGSN.
MME
Available mme interfaces include:
• all: Specifies that all MME interfaces are to be traced.
• s10: Specifies that the interface where the trace will be performed is the S10 interface between the MME
and another MME.
• s11: Specifies that the interface where the trace will be performed is the S11 interface between the MME
and the S-GW.
• s13: Specifies that the interface where the trace will be performed is the S13 interface between the MME
and the EIR.
• s1mme: Specifies that the interface where the trace will be performed is the S1-MME interface between
the MME and the eNodeB.
• s3: Specifies that the interface where the trace will be performed is the S3 interface between the MME
and an SGSN.
• s6a: Specifies that the interface where the trace will be performed is the S6a interface between the MME
and the HSS.
P-GW
Available pgw interfaces are:
• all: Specifies that all available P-GW interfaces are to be traced.
• gx: Specifies that the interface where the trace will be performed is the Gx interface between the P-GW
and the PCRF.
• gy: Specifies that the interface where the trace will be performed is the Gy interface between the P-GW
and OCS.
• s2a: Specifies that the interface where the trace will be performed is the S2a interface between the P-GW
and the HSGW.
• s2b: Specifies that the interface where the trace will be performed is the S2b interface between the P-GW
and an ePDG.
• s2c: Specifies that the interface where the trace will be performed is the S2c interface between the P-GW
and a trusted, non-3GPP access device.
• s5: Specifies that the interface where the trace will be performed is the S5 interface between an S-GW
and P-GW located within the same administrative domain (non-roaming).
• s6b: Specifies that the interface where the trace will be performed is the S6b interface between the P-GW
and the 3GPP AAA server.
• s8: Specifies that the interface where the trace will be performed is the S8 interface -- an inter-PLMN
reference point between the S-GW and the P-GW used during roaming scenarios.
• sgi: Specifies that the interface where the trace will be performed is the SGi interface between the P-GW
and the PDN.
SAEGW
The interfaces that can be traced on the SAEGW are broken down by the interfaces available on a P-GW
configured under an SAEGW (func-pgw), and the interfaces available on a S-GW configured under an
SAEGW (func-sgw).
• Available func-pgw interface options are:
◦all: Specifies that all available func-pgw interfaces are to be traced.
◦gx: Specifies that the interface where the trace will be performed is the Gx interface between the
P-GW and the PCRF.
◦gy: Specifies that the interface where the trace will be performed is the GTPP based online charging
interface between P-GW and online charging system.
◦s2a: Specifies that the interface where the trace will be performed is the S2a interface between the
PGW and the HSGW.
◦s2b: Specifies that the interface where the trace will be performed is the S2b interface between the
PGW and an ePDG.
◦s2c: Specifies that the interface where the trace will be performed is the S2c interface between the
PGW and a trusted, non-3GPP access device.
◦s5: Specifies that the interface where the trace will be performed is the S5 interface between the
P-GW and the S-GW.
◦s6b: Specifies that the interface where the trace will be performed is the S6b interface between the
PGW and the 3GPP AAA server.
◦s8: Specifies that the interface where the trace will be performed is the S8b interface between the
PGW and the S-GW.
◦sgi: Specifies that the interface where the trace will be performed is the SGi interface between the
PGW and the PDN.
S-GW
The available sgw interfaces are:
• all: Specifies that all available S-GW interfaces are to be traced.
• gxc: Specifies that the interface where the trace will be performed is the Gxc interface between the S-GW
and the PCRF.
• s11: Specifies that the interface where the trace will be performed is the S11 interface between the S-GW
and the MME.
• s4: Specifies that the interface where the trace will be performed is the S4 interface between the S-GW
and an SGSN.
• s5: Specifies that the interface where the trace will be performed is the S5 interface between the S-GW
and the P-GW.
• s8: Specifies that the interface where the trace will be performed is the S8 interface between the S-GW
and the P-GW.
Disabling the Session Trace Template Configuration per Network Element and Subscriber
To disable the session trace template per network element and subscriber:
no session trace subscriber network-element { ggsn | hnbgw | mme | pgw | saegw | sgw } template-name
template_name { imsi id | imei id } trace-ref trace_ref_value collection-entity ip_address
Example:
This following is a complete example showing the configuration of a subscriber management trace for all
S-GW and P-GW interfaces. It consists of enabling session tracing on the SAEGW, creating the session trace
template for all S-GW and P-GW interfaces, and then executing the subscriber management trace for a specific
IMSI using the template.
config
session trace network-element saegw
end
config
template-session-trace network-element saegw template-name saegw_all
func-pgw interface all
func-sgw interface all
end
session trace subscriber network-element saegw template-name saegw_all imsi 123456789012345
trace-ref 123456789012 collection-entity 1.1.1.1
• If neither func-sgw or func-pgw is specified, then the signaling trace will be performed for all P-GW
and S-GW interfaces of the SAEGW.
• collection-entity: Specifies the IPv4 or IPv6 address of the Trace Collection Entity (TCE) to which the
trace files are sent.
Example:
This example configures a signaling session trace for all S-GW and P-GW interfaces under an SAEGW:
session trace signaling network-element saegw
• interface: Specifies the network interfaces for the random trace. Interfaces available depend on the
network element type selected.
GGSN
Available ggsn interfaces are:
• all: Specifies that all available GGSN interfaces are to be traced.
• gi: Specifies that the interface where the trace will be performed is the Gi interface between the GGSN
and RADIUS server.
• gmb: Specifies that the interface where the trace will be performed is the Gmb interface between the
GGSN and BM-SC.
• gn: Specifies that the interface where the trace will be performed is the Gn interface between the GGSN
and the SGSN.
• gx: Specifies that the interface where the trace will be performed is the Gx interface between the GGSN
and PCRF.
• gy: Specifies that the interface where the trace will be performed is the Gx interface between the GGSN
and PCRF.
HNBGW
Available hnbgw interfaces are:
• all: Specifies that all hnbgw interfaces are to be traced.
• iucs: Specifies that the interface where the trace will be performed is the iucs interface between the
HNB-GW and the Mobile Switching Center (3G MSC) in a 3G UMTS Femtocell Access Network.
• iups: Specifies that the interface where the trace will be performed is the iups interface between the
HNB-GW and the SGSN.
P-GW
Available P-GW interfaces are:
• all: Specifies that all interfaces are to be traced.
• gx: Specifies that the interface where the trace will be performed is the Gx interface between the P-GW
and the PCRF.
• gy: Specifies that the interface where the trace will be performed is the Gy interface between the P-GW
and OCS.
• s2a: Specifies that the interface where the trace will be performed is the S2a interface between the P-GW
and the HSGW.
• s2b: Specifies that the interface where the trace will be performed is the S2b interface between the P-GW
and an ePDG.
• s2c: Specifies that the interface where the trace will be performed is the S2c interface between the P-GW
and a trusted, non-3GPP access device.
• s5: Specifies that the interface where the trace will be performed is the S5 interface between an S-GW
and P-GW located within the same administrative domain (non-roaming).
• s6b: Specifies that the interface where the trace will be performed is the S6b interface between the P-GW
and the 3GPP AAA server.
• s8: Specifies that the interface where the trace will be performed is the S8 interface -- an inter-PLMN
reference point between the S-GW and the P-GW used during roaming scenarios.
• sgi: Specifies that the interface where the trace will be performed is the SGi interface between the P-GW
and the PDN.
SAEGW
The interfaces that can be traced on the SAEGW are broken down by the interfaces available on a P-GW
configured under an SAEGW (func-pgw), and the interfaces available on a S-GW configured under an
SAEGW (func-sgw).
Available SAEGW func-pgw interface options are:
• all: Specifies that all func-pgw interfaces configured under an SAEGW are to be traced.
• gx: Specifies that the interface where the trace will be performed is the Gx interface between the P-GW
and the PCRF.
• s2a: Specifies that the interface where the trace will be performed is the S2a interface between the PGW
and the HSGW.
• s2b: Specifies that the interface where the trace will be performed is the S2b interface between the PGW
and an ePDG.
• s2c: Specifies that the interface where the trace will be performed is the S2c interface between the PGW
and a trusted, non-3GPP access device.
• s5: Specifies that the interface where the trace will be performed is the S5 interface between the P-GW
and the S-GW.
• s6b: Specifies that the interface where the trace will be performed is the S6b interface between the PGW
and the 3GPP AAA server.
• s8: Specifies that the interface where the trace will be performed is the S8b interface between the PGW
and the S-GW.
• sgi: Specifies that the interface where the trace will be performed is the SGi interface between the PGW
and the PDN.
• gy: Specifies that the interface where the trace will be performed is the GTPP based online charging
interface between P-GW and online charging system.
• s5: Specifies that the interface where the trace will be performed is the S5 interface between the S-GW
and the P-GW.
• s8: Specifies that the interface where the trace will be performed is the S8b interface between the S-GW
and the P-GW.
• collection-entity specifies the IPv4 address of the Trace Collection Entity (TCE)
Example:
To enable random tracing on a range of 40 SAEGW subscribers on all S-GW interfaces and the s5 interface
of the P-GW in the SAEGW, enter the following sample command:
session trace random 40 network-element saegw func-pgw interface s5 func-sgw interface all
collection-entity 1.1.1.1
• R = Random
• S = Signaling
M+S M+S Collapsed Yes Yes 2 SAEGW trace When M+S traces
files generated are enabled for
Func-S-GW,
Func-P-GW and
call type collapsed
both -SGW control
messages (gtpv2)
and P-GW control
messages shall be
traced in 2
SAEGW trace
files. One Trace
file due to
Management and
other due to
Signaling. Both
files have the same
contents.
Feature Description
Before the Backup and Recovery of Key KPI Statistics feature was implemented, statistics were not backed
up and could not be recovered after a SessMgr task restart. Due to this limitation, monitoring the KPI was a
problem as the GGSN, P-GW, SAEGW, and S-GW would lose statistical information whenever task restarts
occurred.
KPI calculation involves taking a delta between counter values from two time intervals and then determines
the percentage of successful processing of a particular procedure in that time interval. When a SessMgr crashes
and then recovers, the GGSN, P-GW, SAEGW, and S-GW lose the counter values - they are reset to zero.
So, the KPI calculation in the next interval will result in negative values for that interval. This results in a dip
in the graphs plotted using the KPI values, making it difficult for operations team to get a consistent view of
the network performance to determine if there is a genuine issue or not.
This feature makes it possible to perform reliable KPI calculations even if a SessMgr restart occurs.
How It Works
A key set of counters used in KPI computation will be backed up for recovery if a SessMgr task restarts. The
counters that will be backed up are determined by the KPIs typically used in several operator networks.
The backup of counters is enabled or disabled via configuration. The configuration specifies the product
(GGSN, P-GW, SAEGW, and/or S-GW) for which counters will be backed up and also a time interval for
the backup of the counters.
Architecture
When this feature is enabled (see Configuring Backup Statistics Feature below), the GGSN, P-GW, SAEGW,
and/or S-GW only backs up the counters maintained at the SessMgr. The recovery function does not need to
be configured or started as it occurs automatically as needed when the feature is enabled.
The counters are backed up to the AAAMgr that is paired with the SessMgr.
Checkpointing
Node-level statistics are checkpointed at AAAMgr. Once statistics are backed up for a specific product, all
the associated services, such as eGTP-C and GTP-U statistics, are also checkpointed.
Recovery
When SessMgr restarts, recovery is performed by receiving all the stored statistics from the mapped AAAMgr
and the recovered values are added to the backup counters maintained at per-service level. This will not impact
session recovery time as the backed up counters are pushed to SessMgr only after session recovery is complete.
Since session recovery is complete, the session managers may start processing calls. In such cases, the counters
will continue to be incremented. The recovered values of the corresponding counters will always be added to
the existing counters. Gauge counters are checkpointed but not recovered.
Order of Statistics Collection
The upper limit of checkpoint messaging is a maximum of 1 MB. Before picking any node to checkpoint,
available memory is checked. If memory is insufficient, the whole node is discarded.
Since there is 1 MB limit, nodes/statistics to checkpoint are prioritized as follows:
1 SAEGW statistics:
• P-GW and S-GW service node-level statistics collected
4 GGSN statistics:
• GGSN service statistics, if not associated with P-GW service, collected
Error Handling
If adding new statistics is going to cause overflow of 1 MB buffer, that service and the corresponding node
will not be included. Checkpointing of any further nodes will also be stopped. Error level log will be flagged
if total memory requirement goes above 1 MB.
Limitations
• A backup interval must be specified and counters are backed up only at the specified interval. For
example, if the backup interval is specified as 5 minutes, then counters are backed up every 5 minutes.
Suppose backup happened at Nth minute and the configured backup interval is for every 5 minutes, then
if a task crash happens at N+4 minutes, the GGSN, P-GW, SAEGW, and/or S-GW recovers only the
values backed up at Nth minute and the data for the past 4 minutes is lost.
• Only statistics maintained at the SessMgr are backed up. Statistics at other managers are not backed up
or recovered.
• The following statistics are not considered for backup:
• APN-level statistics
• eGTP-C APN-QCI statistics
• DemuxMgr statistics
• The CLI command clear statistics will not trigger checkpoint to delete the node statistics on AAAMgr.
New checkpoint after timer expiry will overwrite the statistics.
• Maximum of 1 MB of statistics will be stored on AAAMgr. Services after the maximum size limit are
not backed up.
• Setting the backup interval to shorter periods of time causes higher system overhead for checkpointing.
Alternately, setting the backup interval to longer periods of time results in lower system overhead for
checkpointing but higher probability of hitting the 1 MB storage limit.
• If SessMgr restarts and AAAMgr restarts before SessMgr recovers statistics from AAAMgr, then backed
up statistics are lost.
• This feature is not applicable for ICSR.
Configuration
The following CLI commands are used to manage the functionality for the backing up of the key KPI statistics
feature.
Enabling
The following configures the backup of statistics for the GGSN, P-GW, SAEGW, and/or S-GW and enables
the Backup and Recovery of Key KPI Statistics feature.
configure
statistics-backup { ggsn | pgw | saegw | sgw }
exit
Important Setting the backup interval to shorter periods of time causes higher system overhead for checkpointing.
Alternately, setting the backup interval to longer periods of time results in lower system overhead for
checkpointing but higher probability of hitting the 1 MB storage limit.
Disabling
The following configures the GGSN, P-GW, SAEGW, and/or S-GW to disable the backing up of statistics
for the GGSN, P-GW, SAEGW, and/or S-GW.
configure
no statistics-backup { ggsn | pgw | saegw | sgw }
exit
Feature Description
To comply with the “Long Term Evolution (LTE) Access Network Government Industry Requirements (GIR)
for National Security/Emergency Preparedness (NS/EP) Next Generation Network (NGN) Priority” to support
emergency calls over Voice over LTE (VoLTE), several Key Performance Indicators (KPIs) have been
introduced with this feature. This feature is utilized to collect statistics for total number of GTP-C messages
received for Enhanced Multimedia Priority Service (eMPS) session for specified interval (in minutes). The
list of GTP-C messages are defined in accordance with the GIR document. As part of this feature:
• The S-GW will generate peg counts of the total number of received GTP-C messages containing an
Allocation and Retention Priority (ARP), chosen from the set of values allocated for NS/EP NGN-PS
use, for a specified interval (in minutes). This peg count is administered at the S-GW level.
• The P-GW will generate peg counts of the total number of received GTP-C messages containing an
ARP, chosen from the set of values allocated for NS/EP NGN-PS use, for a specified interval (in minutes).
This peg count is administered at the specific P-GW level.
• The peg counts for GTP-C messages are broken down by message type similar to existing GTP-C
message counters. The bulkstats are broken down by applicable S-GW and P-GW service and S5, S8,
S11, and S4 interfaces.
In earlier releases, bulkstats were not present for eMPS session. With this release 21.1, bulkstats are added
for eMPS session/message.
Piggy-back Message
For piggy-back messages, if either of the messages have matching ARP or result into converting non-eMPS
session to eMPS session, then both messages are counted as eMPS message and corresponding statistics for
both messages are incremented.
If Modify Bearer Request is piggy-backed with Create Bearer Response on S11 interface of S-GW and Create
Bearer Response result into converting non-eMPS session into eMPS session, then Modify Bearer Response
statistics will not increment for this Modify Bearer Request.
Limitations
This section identifies the known limitations of the feature:
• Peer level and APN level statistics are not collected.
• MPS statistics recovery is not supported.
• MPS statistics are not collected for CSReq, DDNReq, and change notification messages rejected by
demux with ARP for eMPS sessions.
• MPS statistics are not collected for retried/re-transmitted messages.
Licensing
Important Bulkstats for GTP-C Messages by ARP Value feature requires that a valid license key be installed. Contact
your Cisco Account or Support representative for information on how to obtain a license.
The output of the above CLI commands displays the following new parameters:
• Total eMPS Statistics: Cumulative GTP-C message statistics for messages received/transmitted on
eMPS Sessions.
• Current interval eMPS Statistics: GTP-C message statistics for messages received/transmitted on
eMPS Sessions for current statistics collection interval. Statistics collection interval will be same as
bulkstats collection interval. If bulk stats collection is not configured, then Current MPS Statistics will
be same as Total MPS Statistics.
• Create Session Request (Total RX): This counter will be incremented by S-GW when it receives Create
session request message on S4 interface containing an ARP value configured in MPS Profile.
• Create Session Response (Total TX): This counter will be incremented by S-GW when it transmits
Create session response message on S4 interface containing an ARP value configured in MPS Profile.
The output of the above CLI commands displays the following new parameters:
• Total eMPS Statistics: Cumulative GTP-C message statistics for messages received/transmitted on
eMPS Sessions.
• Current interval eMPS Statistics: GTP-C message statistics for messages received/transmitted on
eMPS Sessions for current statistics collection interval. Statistics collection interval will be same as
bulkstats collection interval. If bulk stats collection is not configured, then Current MPS Statistics will
be same as Total MPS Statistics.
• Create Session Request (Total RX): This counter will be incremented by S-GW when it receives Create
session request message on S11 interface containing an ARP value configured in MPS Profile.
• Create Session Response (Total TX): This counter will be incremented by S-GW when it transmits
Create session response message on S11 interface containing an ARP value configured in MPS Profile.
• Modify Bearer Request (Total RX): This counter will be incremented by S-GW when it receives
Modify Bearer request message on S11 interface containing an ARP value configured in MPS Profile.
• Modify Bearer Response (Total TX): This counter will be incremented by S-GW when it transmits
Modify Bearer response message on S11 interface containing an ARP value configured in MPS Profile.
• Create Bearer Request (Total TX): This counter will be incremented by S-GW when it transmits
Create Bearer request message on S11 interface containing an ARP value configured in MPS Profile.
• Create Bearer Response (Total RX): This counter will be incremented by S-GW when it receives
Create Bearer response message on S11 interface containing an ARP value configured in MPS Profile.
• Downlink Data Notification (Total TX): This counter will be incremented by S-GW when it transmits
Downlink Data Notification message on S11 interface containing an ARP value configured in MPS
Profile.
• Downlink Data Notification Ack (Total RX): This counter will be incremented by S-GW when it
receives Downlink Data Notification Ack message on S11 interface containing an ARP value configured
in MPS Profile.
• Update Bearer Request (Total TX): This counter will be incremented by S-GW when it transmits
Update Bearer request message on S11 interface containing an ARP value configured in MPS Profile.
• Update Bearer Response (Total RX): This counter will be incremented by S-GW when it receives
Update Bearer response message on S11 interface containing an ARP value configured in MPS Profile.
The output of the above CLI commands displays the following new parameters:
• Total eMPS Statistics: Cumulative GTP-C message statistics for messages received/transmitted on
eMPS Sessions.
• Current interval eMPS Statistics: GTP-C message statistics for messages received/transmitted on
eMPS Sessions for current statistics collection interval. Statistics collection interval will be same as
bulkstats collection interval. If bulk stats collection is not configured, then Current MPS Statistics will
be same as Total MPS Statistics.
• Create Session Request (Total TX): This counter will be incremented by S-GW when it transmits
Create session request message on S5/S8 interface containing an ARP value configured in MPS Profile.
• Create Session Response (Total RX): This counter will be incremented by S-GW when it receives
Create session response message on S5/S8 interface containing an ARP value configured in MPS Profile.
• Modify Bearer Request (Total TX): This counter will be incremented by S-GW when it transmits
Modify Bearer request message on S5/S8 interface containing an ARP value configured in MPS Profile.
• Modify Bearer Response (Total RX): This counter will be incremented by S-GW when it receives
Modify Bearer response message on S5/S8 interface containing an ARP value configured in MPS Profile.
• Create Bearer Request (Total RX): This counter will be incremented by S-GW when it receives Create
Bearer request message on S5/S8 interface containing an ARP value configured in MPS Profile.
• Create Bearer Response (Total TX): This counter will be incremented by S-GW when it transmits
Create Bearer response message on S5/S8 interface containing an ARP value configured in MPS Profile.
• Update Bearer Request (Total RX): This counter will be incremented by S-GW when it receives
Update Bearer request message on S5/S8 interface containing an ARP value configured in MPS Profile.
• Update Bearer Response (Total TX): This counter will be incremented by S-GW when it transmits
Update Bearer response message on S5/S8 interface containing an ARP value configured in MPS Profile.
The output of the above CLI commands displays the following new parameters:
• Total eMPS Statistics: Cumulative GTP-C message statistics for messages received/transmitted on
eMPS Sessions.
• Current interval eMPS Statistics: GTP-C message statistics for messages received/transmitted on
eMPS Sessions for current statistics collection interval. Statistics collection interval will be same as
bulkstats collection interval. If bulk stats collection is not configured, then Current MPS Statistics will
be same as Total MPS Statistics.
• Create Session Request (Total RX): This counter will be incremented by P-GW when it receives Create
session request message on S5/S8 interface containing an ARP value configured in MPS Profile.
• Create Session Response (Total TX): This counter will be incremented by P-GW when it transmits
Create session response message on S5/S8 interface containing an ARP value configured in MPS Profile.
• Modify Bearer Request (Total RX): This counter will be incremented by P-GW when it receives
Modify Bearer request message on S5/S8 interface containing an ARP value configured in MPS Profile.
• Modify Bearer Response (Total TX): This counter will be incremented by P-GW when it transmits
Modify Bearer response message on S5/S8 interface containing an ARP value configured in MPS Profile.
• Create Bearer Request (Total TX): This counter will be incremented by P-GW when it receives Create
Bearer request message on S5/S8 interface containing an ARP value configured in MPS Profile.
• Create Bearer Response (Total RX): This counter will be incremented by P-GW when it receives
Create Bearer response message on S5/S8 interface containing an ARP value configured in MPS Profile.
• Update Bearer Request (Total TX): This counter will be incremented by P-GW when it transmits
Update Bearer request message on S5/S8 interface containing an ARP value configured in MPS Profile.
• Update Bearer Response (Total RX): This counter will be incremented by P-GW when it receives
Update Bearer response message on S5/S8 interface containing an ARP value configured in MPS Profile.
clear egtpc
The following CLI commands are modified to clear eMPS statistics at interface level and eGTP-C service
level:
• clear egtpc statistics interface-type interface-pgw-ingress interface s5s8: Clears interface statistics
along with eMPS statistics for all eGTP-C services of P-GW Ingress type and S5/S8 interface.
• clear egtpc statistics interface-type [ interface-sgw-ingress | interface-sgw-egress ] interface [ s4 |
s11 | sgw-s5s8 ]: Clears interface statistics along with eMPS statistics for all eGTP-C services of S-GW
Ingress type and S4 or S11 interface/S-GW Egress type and S5/S8 interface.
• clear egtpc statistics egtp-service pgw_egtpc_service_name interface [ s5s8 ]: Clears interface statistics
along with eMPS statistics for all P-GW eGTP-C services and S5/S8 interface.
• clear egtpc statistics egtp-service sgw_egptc_service_name interface [ s11 | s4 | sgw-s5s8 ]: Clears
interface statistics along with eMPS statistics for all S-GW eGTP-C services and S4 or S11 or S5/S8
interface.
eGTP-C Schema
The following new bulk statistics variables are added to the eGTP-C schema in support of this feature:
• s11-tun-recv-cresessreq-emps – The total number of tunnel - create session request - messages received
by the system for eMPS subscriber on interface s11. This stat is for current bulkstat interval only.
• s11-tun-sent-cresessresp-emps – The total number of tunnel - create session response - messages sent
by the system for eMPS subscriber on interface s11. This stat is for current bulkstat interval only.
• s11-tun-recv-modbearerreq-emps – The total number of tunnel - modify bearer request - messages
received by the system for eMPS subscriber on interface s11. This stat is for current bulkstat interval
only.
• s11-tun-sent-modbearerresp-emps – The total number of tunnel - modify bearer response - messages
sent by the system for eMPS subscriber on interface s11. This stat is for current bulkstat interval only.
• s11-tun-sent-crebearerreq-emps – The total number of tunnel - create bearer request - messages sent by
the system for eMPS subscriber on interface s11. This stat is for current bulkstat interval only.
• s11-tun-recv-crebearerresp-emps – The total number of tunnel - create bearer response - messages
received by the system for eMPS subscriber on interface s11. This stat is for current bulkstat interval
only.
• s11-tun-sent-updbearerreq-emps – The total number of tunnel - update bearer request - messages sent
by the system for eMPS subscriber on interface s11. This stat is for current bulkstat interval only.
• s11-tun-recv-updbearerresp-emps – The total number of tunnel - update bearer response - messages
received by the system for eMPS subscriber on interface s11. This stat is for current bulkstat interval
only.
• s11-tun-sent-ddnreq-emps – The total number of downlink data notification - messages sent by the
system for eMPS subscriber on interface s11. This stat is for current bulkstat interval only.
• s11-tun-recv-ddnack-emps – The total number of downlink data notificatino acknowledge - messages
received by the system for eMPS subscriber on interface s11. This stat is for current bulkstat interval
only.
• s4-tun-recv-cresessreq-emps – The total number of tunnel - create session request - messages received
by the system for eMPS subscriber on interface s4. This stat is for current bulkstat interval only.
• s4-tun-sent-cresessresp-emps – The total number of tunnel - create session response - messages sent by
the system for eMPS subscriber on interface s4. This stat is for current bulkstat interval only.
• tun-sent-cresessreq-emps – The total number of tunnel - create session request - messages sent by the
system for eMPS subscriber on interface s5s8. This stat is for current bulkstat interval only.
• tun-recv-cresessresp-emps – The total number of tunnel - create session response - messages received
by the system for eMPS subscriber on interface s5s8. This stat is for current bulkstat interval only.
• tun-sent-modbearerreq-emps – The total number of tunnel - modify bearer request - messages sent by
the system for eMPS subscriber on interface s5s8. This stat is for current bulkstat interval only.
• tun-recv-modbearerresp-emps – The total number of tunnel - modify bearer response - messages received
by the system for eMPS subscriber on interface s5s8. This stat is for current bulkstat interval only.
• tun-recv-crebearerreq-emps – The total number of tunnel - create bearer request - messages received by
the system for eMPS subscriber on interface s5s8. This stat is for current bulkstat interval only.
• tun-sent-crebearerresp-emps – The total number of tunnel - create bearer response - messages sent by
the system for eMPS subscriber on interface s5s8. This stat is for current bulkstat interval only.
• tun-recv-updbearerreq-emps – The total number of tunnel - update bearer request - messages received
by the system for eMPS subscriber on interface s5s8. This stat is for current bulkstat interval only.
• tun-sent-updbearerresp-emps – The total number of tunnel - update bearer response - messages sent by
the system for eMPS subscriber on interface s5s8. This stat is for current bulkstat interval only.
Related Documentation
• Command Line Interface Reference
• S-GW Administration Guide
• SAEGW Administration Guide
Revision History
Feature Description
This feature introduces configuration changes that would allow you to configure the S-GW, including SAEGW
instances, to disable the Cause Source bit functionality in Cause IE. If this configuration is enabled, S-GW
and SAEGW always set the Cause Source Bit in Cause IE to zero.
Configuring cause-source
The gtpc disable cause source command has been introduced in support of this feature.
configure
context context_name
egtp-service egtp_service_name
[ no | default ] gtpc disable cause-source
end
Notes:
• disable: Disables functionality at egtpc level
• cause-source: Disables cause source Bit in Cause IE.
Troubleshooting
The following commands can be used for troubleshooting:
• The following commands can be used for checking current status of this feature:
show egtp-service name service_name
• Monitor protocol CLI can be enabled to check GTPV2 protocol trace. In the protocol trace output cause
source bit in Cause IE can be checked.
Important Direct Tunnel is a licensed Cisco feature. A separate feature license is required for configuration. 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.
Important Direct tunnel is a licensed Cisco feature. A separate feature license is required for configuration. 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.
Important Establishment of a direct tunnel is controlled by the SGSN; for 4G networks this requires an S4
license-enabled SGSN setup and configured as an S4-SGSN.
Once a direct tunnel is established, the S4-SGSN/S-GW continues to handle the control plane (RANAP/GTP-C)
signaling and retains the responsibility of making the decision to establish direct tunnel at PDP context
activation.
A direct tunnel improves the user experience (for example, expedites web page delivery, reduces round trip
delay for conversational services) by eliminating switching latency from the user plane. An additional advantage,
direct tunnel functionality implements optimization to improve the usage of user plane resources (and hardware)
by removing the requirement from the S4-SGSN/S-GW to handle the user plane processing.
A direct tunnel is achieved upon PDP context activation when the S4-SGSN establishes a user plane tunnel
(GTP-U tunnel) directly between the RNC and the S-GW over an S12 interface, using a Create Bearer Response
or Modify Bearer Request towards the S-GW.
A major consequence of deploying a direct tunnel is that it produces a significant increase in control plane
load on both the SGSN/S-GW and GGSN/P-GW components of the packet core. Hence, deployment requires
highly scalable GGSNs/P-GWs since the volume and frequency of Update PDP Context messages to the
GGSN/P-GW will increase substantially. The SGSN/S-GW platform capabilities ensure control plane capacity
will not be a limiting factor with direct tunnel deployment.
S4-SGSN supports establishment of a GTP-U direct tunnel between an RNC and the S-GW under the scenarios
listed below:
• Primary PDP activation
• Secondary PDP activation
• Service Request Procedure
• Intra SGSN Routing Area Update without S-GW change
• Intra SGSN Routing Area Update with S-GW change
• Intra SGSN SRNS relocation without S-GW change
• Intra SGSN SRNS relocation with S-GW change
• New SGSN SRNS relocation with S-GW change
• New SGSN SRNS relocation without S-GW relocation
• E-UTRAN-to-UTRAN Iu mode IRAT handover with application of S12U FTEID for Indirect Data
Forwarding Tunnels as well
• UTRAN-to-E-UTRAN Iu mode IRAT handover with application of S12U FTEID for Indirect Data
Forwarding Tunnels as well
• Network Initiated PDP Activation
Scenarios that vary at S4-SGSN when direct tunneling is enabled, as compared to DT on a 2G or 3G SGSN
using the Gn interface, include:
• RAB Release
• Iu Release
• Error Indication from RNC
• Downlink Data Notification from S-GW
• Downlink Data Error Indication from S-GW
• MS Initiated PDP Modification
• P-GW Initiated PDP Modification while the UE is IDLE
• HLR/HSS Initiated PDP Modification
• Session Recovery with Direct Tunnel
The above scenarios exhibit procedural differences in S4-SGSN when a direct tunnel is established.
How It Works
DT functionality enables direct user plane tunnel between RNC and SGW within the PS domain. With direct
tunneling the S4-SGSN provides the RNC with the TEID and user plane address of the S-GW, and also
provides the S-GW with the TEID and user plane address of the RNC.
The SGSN handles the control plane signaling and makes the decision when to establish the direct tunnel
between RNC and S-GW, or use two tunnels for this purpose (based on configuration).
DT Establishment Logic
The following figure illustrates the logic used within the S4-SGSN/S-GW to determine if a direct tunnel will
be setup.
• The SGSN forwards the S-GW S12U to RNC via a RAB Assignment Request.
• In its RAB Assignment Response, the RNC sends its transport address and TEID to the SGSN.
• The SGSN forwards the S12U TEID received from the RNC to the S-GW via a Create Bearer Response.
Bearers with a streaming or conversational class will not be included in the Release Access Bearer Request
because these bearers should be deactivated. However, S4-SGSN currently does not support deactivation of
streaming/conversational bearers upon RAB release.
Important Operators should not use conversational or streaming class bearers in S4-SGSN.
Important Operators should not use conversational or streaming class bearers in S4-SGSN.
Upon receiving a Service Request for data, the SGSN establishes RABs and sends a Modify Bearer Request
to the S-GW with the 12U FTEID received from the RNC.
If the Downlink Data Notification is received from the S-GW, all of the missing RABs are established and a
Modify Bearer Request is sent to the S-GW with the RNC S12U FTEID
Data Notification is received from S-GW when the UE is idle, the SGSN pages the UE before establishing
the RABs. The SGSN sends a Modify Bearer Request to the S-GW with the RNC S12U FTEID.
The table below includes detailed behaviors for a Routing Area Update without S-GW change.
Table 14: Routing Area Update without S-GW Change Behavior Table
Scenario Old Old RNC Old RNC DT PLMN NEW RNC DT S-GW SGSN Action
RNC RAB Status Change Status Change
Status
Intra RAU Not No RAB Supported No Supported No No RAB
Present establishment with
new RNC. No
Modify Bearer
Request to S-GW
Intra RAU Present No RAB Supported No Supported No No RAB
establishment with
new RNC. No
Modify Bearer
Request to S-GW
Scenario Old Old RNC Old RNC DT PLMN NEW RNC DT S-GW SGSN Action
RNC RAB Status Change Status Change
Status
Intra RAU Present Some Supported Do not Supported No Only the present
RABs care RABs are
established. MBR
sent to S-GW with
the bearers with
RABs that are be
modified and the
rest released. The
bearers without
RABs will be
deactivated post
RAU. If PLMN
changed then MBR
will carry the new
PLMN ID.
Intra RAU Not No RAB Supported Yes Supported No No RAB
Present establishment with
new RNC. MBR is
sent with only
PLMN change.
Bearer Context will
not carry any TEID.
Intra RAU Present No RAB Supported Yes Supported No Same as above.
Intra RAU Not No RAB Not No Supported No No RAB
Present Supported establishment with
new RNC. Modify
Bearer Request to
S-GW with DTF set
and no user FTEID.
Intra RAU Present No RAB Not No Supported No Same as above.
Supported
Scenario Old Old RNC Old RNC DT PLMN NEW RNC DT S-GW SGSN Action
RNC RAB Status Change Status Change
Status
Intra RAU Present Some Not Do not Supported No Only the present
RABs Supported care RABs are
established. MBR
sent to S-GW with
the bearers with
RABs to be
modified and the
rest to be released.
The bearers without
RABs will be
deactivated post
RAU. If PLMN
changed then MBR
will carry the new
PLMN ID.Modify
Bearer.
Intra RAU Not No RAB Not Yes Supported No No RAB
Present Supported establishment with
new RNC. MBR is
sent with only
PLMN change.
SGSN will page /
Service req /
establish RABs
when a downlink
data notification is
received.
Intra RAU Present No RAB Not Yes Supported No Same as above.
Supported
Intra RAU: New RNC does not support Direct Tunnel. No SGW relocation
Intra RAU Not No RAB Supported Do not Not No No RAB
Present care Supported establishment with
new RNC. SGSN
sends Modify
Bearer Request to
S-GW with S4U
TEID. If there is
change in PLMN
ID, then new PLMN
ID will be carried.
Intra RAU Present No RAB Supported Do not No No Same as above.
care Supported
Scenario Old Old RNC Old RNC DT PLMN NEW RNC DT S-GW SGSN Action
RNC RAB Status Change Status Change
Status
Intra RAU Present Some Supported Do not Not No Only the present
RABs care supported RABs are
established. MBR
sent to S-GW with
all bearers having
S4U TEID. If there
is change in PLMN
ID, the new PLMN
ID will be carried.
The table below includes detailed behaviors for a Routing Area Update with S-GW change.
Table 15: Routing Area Update with S-GW Change Behavior Table
Scenario Old Old RNC Old RNC DT PLMN NEW RNC DT S-GW SGSN Action
RNC RAB Status Change Status Change
Status
Intra RAU: Both RNCs support Direct Tunnel. SGW relocation
Intra RAU Not No RAB Supported Do not Supported Yes Send CSR request to
Present care new S-GW with
DTF flag but no
S4U / S12U FTEID.
S-GW will send its
S12U TEID that
SGSN stores as part
of DP's remote
TEID. SGSN will
not initiate any
MBR request to
S-GW since no
RABs are
established with
new RNC. If S-GW
subsequently gets
downlink data,
SGSN will get DDN
and establish RABs
and send MBR.
Intra RAU Present No RAB Supported Do not Supported Yes Same as above.
care
Intra RAU Present Some Supported Do not Supported Yes Send CSR request to
RABs care new S-GW with
DTF flag but no
S4U / S12U FTEID.
S-GW sends its
S12U TEID. RABs
that are present will
be established with
new RNC. MBR
will be initiated only
with those RABs
that are present rest
of bearers to be
removed.
Intra RAU: Old RNC does not support Direct Tunnel. SGW relocation
Scenario Old Old RNC Old RNC DT PLMN NEW RNC DT S-GW SGSN Action
RNC RAB Status Change Status Change
Status
Intra RAU Not No RAB Not Do not Supported Yes Send CSR request to
Present Supported care new S-GW with
DTF flag but no
S4U / S12U FTEID.
S-GW sends its
S12U TEID that
SGSN stores as part
of our DP's remote
TEID. SGSN will
not initiate any
MBR request to
S-GW since no
RABs are
established with
new RNC. If S-GW
subsequently gets
downlink data,
SGSN gets DDN
and establishes
RABs and sends
MBR.
Intra RAU present No RAB Not Do not Supported Yes Same as above.
Supported care
Intra RAU Present Some Not Do not Supported Yes Send CSR request to
RABs SUpported care new S-GW with
DTF flag but no
S4U / S12U FTEID.
S-GW sends its
S12U TEID. RABs
that are present will
be established with
new RNC and MBR
will be initiated only
with those RABs
that are present and
the rest as bearers to
be removed.
Intra RAU: New RNC does not support Direct Tunnel. SGW relocation
Intra RAU Not No RAB Supported Do not Not Yes CSR request
Present care Supported without DTF flag
and with S4U
FTEID.
Scenario Old Old RNC Old RNC DT PLMN NEW RNC DT S-GW SGSN Action
RNC RAB Status Change Status Change
Status
Intra RAU Present No RAB Supported Do not Not Yes CSR request
care Supported without DTF flag
and with S4U
FTEID.
Intra RAU Present Some Supported Do not Not Yes CSR request
rABs care Supported without DTF flag
and with S4U
FTEID. No
deactivation of
PDPs.
The SGSN sends the RNC S12U FTEID to the new S-GW in a Modify Bearer Request.
The table below includes detailed behaviors for intra SRNS scenarios.
The table below includes detailed behaviors for intra SRNS scenarios.
to the Target RNC. The new SGSN sends the RNC S12U FTEID received in a Relocation Request Ack to
the new S-GW in a Modify Bearer Request.
Figure 40: New SRNS with S-GW Change with Data Transfer
The table below includes detailed behaviors for New SRNS scenarios.
Figure 41: New SRNS with S-GW Change and Indirect Data Transfer
The table below includes detailed behaviors for New SRNS scenarios.
Notification internally. This sets up all RABs (using old QoS) and sends a Modify Bearer Request. When the
Downlink Data Procedure is completed, the queued PGW Init Modification is processed.
Limitations
During an intra RAU, intra SRNS or Service Request triggered by RAB establishment, if a few RABs fail the
Modify Bearer Request the SGSN will mark those RABs as bearers to be removed. Under current specifications,
it is not possible to send a Modify Bearer Request with a few bearers having S12U U-FTEIDs and a few
bearers not having U-FTEIDs.
There is an ongoing CR at 3GPP to allow such Modify Bearer Requests and the S-GW should send DDN
when it gets downlink data for the bearers that did not have U-FTEIDs. If this CR is approved, the SGSN will
support (in a future release) sending a partial set of bearers with S12U FTEID and some bearers without any
U-FTEID.
Standards Compliance
The Direct Tunnel complies with the following standards:
• 3GPP TS 23.060 version 10 sec 9.2.2 General Packet Radio Service (GPRS) Service description
• 3GPP TS 29.274 v10.5.0 3GPP Evolved Packet System (EPS) Evolved General Packet Radio Service
(GPRS) Tunnelling Protocol for Control plane (GTPv2-C)
The SGSN/S-GW direct tunnel functionality is enabled within an operator policy configuration. One aspect
of an operator policy is to allow or disallow the setup of direct GTP-U tunnels. If no operator policies are
configured, the system looks at the settings in the operator policy named default. If direct tunnel is allowed
in the default operator policy, then any incoming call that does not have an applicable operator policy configured
will have direct tunnel allowed. For more information about the purpose and uses of operator policies, refer
to the section Operator Policy.
Important Direct tunneling must be enabled at both end points to allow direct tunneling for the MS/UE.
• To remove the direct tunnel settings from the configuration, use the following command: direct-tunnel
attempt-when-permitted [ to-ggsn | to-sgw ]
• Direct tunnel is allowed on the SGSN but will only setup if allowed on both the destination node and
the RNC.
config
call-control-profile profile_name
rau-inter avoid-s12-direct-tunnel
end
Restrict direct tunneling by a specific RNC. The following configuration scenario restricts the SGSN from
attempting to setup a direct tunnel when a call originates from a specific RNC.
config
context context_name
iups-service service_name
rnc id rnc_id
direct-tunnel not-permitted-by-rnc
end
|
NSAPI: 05 Context Type: Primary
Context initiated by: MS
Direct Tunnel : Established
The following bulkstats under EGTPC schema track Downlink Data Notification (DDN) Ack and failure
messages between the S-GW and the SGSN when either direct tunnel or ISR is active:
• tun-recv-dlinknotif
• tun-recv-dlinknotifDiscard
• tun-recv-dlinknotifNorsp
• tun-recv-retransdlinknotif
• tun-sent-dlinknotifackaccept
• tun-sent-dlinknotifackdenied
• tun-sent-dlinkdatafail
For complete descriptions of these variables, see the EGTPC Schema Statistics chapter in the Statistics and
Counters Reference.
Applicable Platform(s)
• ASR 5500
• VPC - Di
• VPC - Si
Related Documentation
• Command Line Interface Reference
• GGSN Administration Guide
• P-GW Administration Guide
• SAEGW Administration Guide
• S-GW Administration Guide
Revision History
Feature Description
For troubleshooting and investigating network issues related to the Diameter interface, it is important to filter
the subscriber or UE specific Diameter traffic. Any traffic associated with a particular IMSI can be easily
filtered, even without knowing the Diameter session ID, if the IMSI information is embedded into the Diameter
Session ID AVP. This feature allows the operator to filter the subscriber or UE specific Diameter traffic.
This feature introduces a new CLI command session-id include imsi under the diameter endpoint
configuration mode to embed IMSI into Diameter session ID AVP over the Gx, Gy, and Gz (Rf) interface.
Important This feature is license controlled. Contact your Cisco account representative for information on how to
obtain a license.
How It Works
A new CLI command session-id include imsi has been added under the diameter endpoint configuration
mode to enable/disable inclusion of IMSI in Session-Id AVP for all Diameter sessions associated with that
Diameter endpoint. Operators can enable only the required Diameter endpoints and control the inclusion of
IMSI in the Session-ID AVP. IMSI information is included in the Diameter Session-ID AVP over the Gx,
Gy, and Gz (Rf) interface, if the session-id include imsi is enabled on respective Diameter endpoints.
For emergency call with "only IMEI", IMSI information is not available for that emergency PDN. Hence, this
IMSI information is not included in Diameter Session-ID at Gx, Gy, and Gz interface, when session-id
include imsi is enabled. Configuring session-id include imsi impacts only new PDN connection and does
not have any impact on existing PDN connection behavior (Gx, Gy, and Gz (Rf)) interface. For example, if
the CLI command to include IMSI is enabled for the Gy Diameter endpoint after PDN creation. If a new
dedicated bearer is created after this configuration change, then in this case Gy session established for a new
dedicated bearer is not included IMSI in Gy Diameter session ID.
There is no impact of session manager recovery/ICSR on the session-ID AVP. Session-ID associated with
Gx, Gy, and Gz (Rf) session is recovered transparently (which is irrespective of latest endpoint configuration).
New sessions come up with session IDs as per the configuration on the newly active chassis.
Limitations
Following are the known limitations of this feature:
• Assuming IMSI information as sensitive information, operator must consider security aspects before
enabling this CLI option.
• For an emergency call with "Only IMEI", IMSI information is not available for the emergency PDN,
hence it is not included in the diameter Session-ID at Gx, Gy, and Gz (Rf) interface.
• During ICSR upgrade scenario, it is assumed that the new CLI option must be enabled only when the
upgraded chassis is in stable state and there exists no chances of ICSR downgrade.
• If new CLI is enabled in the newer version of chassis, ICSR Downgrade is not recommended.
• As new CLI option is not available in old software versions, hence ICSR downgrade is not recommended.
Performing ICSR downgrade should have the following impact on the diameter sessions, which have
IMSI, included as part of Session-ID.
• Gx and Gy: Existing diameter session (Gx, Gy) should be downgraded with old format of Session-Id.
In that case, both P-GW and PCRF are out of sync leading to hanging session at P-GW or/and
PCRF. Any communication from PCRF (RAR)/P-GW (CCR-U) can lead to stale session deletion.
• Gz (Rf): However, Rf sessions should be recovered properly and any Rf signaling is sent out to
Rf servers properly but responses cannot be processed as diamproxy cannot parse the new format
session id which again puts Rf sessions into stale state until purged.
configure
context context_name
diameter endpoint endpoint_name
[no] session-id include imsi
end
Notes:
• session-id: Describes Diameter Session-ID format
• include: Includes configured information in Diameter Session-ID
show configuration
The output of the above command is modified to display the following new field depending on whether the
CLI is enabled or disabled:
• session-id include imsi
• no session-id include imsi
Feature Description
The National Security/Emergency Preparedness (NS/EP) Next Generation Network (NGN) Priority Services
(NGN-PS) (formerly called NGN Government Emergency Telecommunications Service (GETS)) is a set of
voice, video and data services that are based on services available from public packet-switched Service
Providers. The NS/EP NGN-PS provides priority treatment for a Service User’s NS/EP communications and
is particularly needed when the Service Providers’ networks are impaired due to congestion and/or damage
from natural disasters (such as floods, earthquakes and hurricanes) and man-made disasters (such as physical,
cyber or other forms of terrorist attacks).
In earlier releases, the DSCP marking of control message from P-GW and S-GW was based on associated
egtpc-service configuration.
With Release 21.1, for control message belonging to eMPS session or containing Allocation and Retention
Priority (ARP) associated with eMPS profile, the DSCP marking is based on eMPS profile configured DSCP
value.
As part of this enhancement, support is also added for marking of certain GTP-C message at the P-GW and
S-GW for priority treatment as defined in the Government Industry Requirements (GIR) NS/EP NGN.
Important Any existing features which works on ARP (PL) configurations will continue to work as before irrespective
of whether ARP values configured are same as reserved under NS/EP NGN-PS for eMPS services. If
existing features need to work with eMPS requirements, then same ARP (PL) values should be configured
as reserved NS/EP NGN-PS for eMPS services.
Licensing
The DSCP marking capability requires that a valid license key be installed. Contact your Cisco Account or
Support representative for information on how to obtain a license.
How It Works
GIR Document References
The following table describes the requirements of this feature as per the GIR document.
R-130 [204] The S-GW shall mark for priority treatment the S11 “Create Session
Response” message from the S-GW to the MME which contains request
to establish a bearer or bearers with an ARP corresponding to an NS/EP
NGN-PS call/session.
R-132 [205] The S-GW shall mark for priority treatment the S11 “Create Bearer
Request” and S11 “Update Bearer Request” messages from the SGW to
the MME which contains an indication that a UE currently has an
established/updated bearer or bearers for NS/EP NGN-PS service.
R-134 [206] In the case where the S5/S8 Interface is GTP-based, the S-GW shall
mark for priority treatment the S5/S8 “Create Session Request” message
from the S-GW to the PDN-GW which contains an indication that a UE
will establish a bearer or bearers for NS/EP NGN-PS.
R-137 [207] In the case where the S5/S8 Interface is GTP-based, the S-GW shall
mark for priority treatment the S5/S8 “Create Bearer Response” and “Update
Bearer Response” messages from the S-GW to the PDN-GW which contain
an indication that a UE currently has established / updated a bearer or
bearers for NS/EP NGN-PS.
R-143 [213] In the case where the S5/S8 Interface is GTP-based, the PDN-GW
shall mark for priority treatment the S5/S8 “Create Session Response”
message from the PDN-GW to the S-GW which contains a request to
establish a bearer or bearers with an ARP corresponding to an NS/EP
NGN-PS call/session.
configure
[ no ] emps-profile emps_profile_name -noconfirm
[ no ] earp { [ 1...15 ] { [ 1...15 ] { [ 1...15 ] } } }
[ no ] dscp-marking dscp_value
end
Notes:
• emps-profile emps_profile_name: Configures eMPS profile for defining attributes of an eMPS session.
The emps_profile_name is a string of size from 1 to 63.
• earp: Configures a maximum of 3 eARP priority level (PL) values so that sessions with configured
eARP priority values can be marked as eMPS sessions.
• -noconfirm: Creates a new eMPS profile without prompting for confirmation.
• dscp-marking dscp_value: Specifies the DSCP value to be applied to eMPS sessions. The dscp_value
is a hexadecimal number between 0x0 and 0x3F.
• Maximum of 3 eARP values can be configured under an eMPS profile. The above CLI syntax provides
flexibility to configure one or more (max 3) eARP values in a single command. For example:
earp 1 2 3
-Or-
earp 4
• The latest set of eARP values configured will overwrite the previous configuration. For example: Invoking
below two commands in sequence will configure only eARP value 4.
earp 1 2 3
earp 4
• eMPS profile name should be unique and is treated case insensitive across context.
• The no earp command can be used to disable all configured eARP values. However, this will not delete
the corresponding eMPS profile. The no emps-profile emps_profile_name CLI command will delete
the profile.
• Warning message: When no of a non-existent eMPS profile is executed, a warning message is displayed.
For example:
no emps-profile xyz
eMPS Profile : xyz does not exist
There will be no warning message if no of an un-configured eARP is executed.
• There will be a warning and confirmation message when existing profile is deleted:
This operation will result in deletion of this eMPS Profile.
Are you sure? [Yes|No]:
Important Maximum of one eMPS profile can be associated with P-GW service at a time; the latest configuration
will overwrite the previously associated configuration.
Important Maximum of one eMPS profile can be associated with S-GW service at a time; the latest configuration
will overwrite the previously associated configuration.
• Cumulative De-activated: Increments when an eMPS PDN is released or when it degrades to a non-eMPS
PDN.
Where:
• Current Active: Increments when any PDN is setup as an eMPS PDN or upgraded to eMPS PDN.
Decrements when an eMPS PDN is released or when it degrades to a non-eMPS PDN.
• Cumulative Activated: Increments when any PDN is setup as an eMPS PDN or upgrades to an eMPS
PDN.
• Cumulative De-activated: Increments when an eMPS PDN is released or when it degrades to a non-eMPS
PDN.
SGW Schema
The following bulk statistics have been added to the S-GW schema as part of this enhancement:
• sessstat-pdn-emps-current-active – The total number of currently active S-GW eMPS PDNs.
• sessstat-pdn-emps-cumulative-activated – The total number of S-GW PDNs that are either setup as an
eMPS PDN or upgrades to an eMPS PDN.
• sessstat-pdn-emps-cumulative-deactivated – The total number of S-GW PDNs that were either released
or degrades to a non-eMPS PDN.
SAEGW Schema
The following bulk statistics have been added to the SAE-GW schema as part of this enhancement:
• pgw-anchor-pdns-emps-current-active – The total number of currently active P-GW anchored eMPS
PDNs.
• pgw-anchor-pdns-emps-cumulative-activated – The total number of P-GW anchored PDNs that are
either setup as an eMPS PDN or upgrades to an eMPS PDN.
• pgw-anchor-pdns-emps-cumulative-deactivated – The total number of P-GW anchored PDNs that were
either released or degrades to a non-eMPS PDN.
• saegw-colocated-pdns-emps-current-active – The total number of currently active SAE-GW collapsed
eMPS PDNs.
• saegw-colocated-pdns-emps-cumulative-activated – The total number of SAE-GW collapsed PDNs that
are either setup as an eMPS PDN or upgrades to an eMPS PDN.
• saegw-colocated-pdns-emps-cumulative-deactivated – The total number of SAE-GW collapsed PDNs
that were either released or degrades to a non-eMPS PDN.
• sgw-anchor-pdns-emps-current-active – The total number of currently active S-GW anchored eMPS
PDNs.
• sgw-anchor-pdns-emps-cumulative-activated – The total number of S-GW anchored PDNs that are either
setup as an eMPS PDN or upgrades to an eMPS PDN.
• Per QCI Packet Drop Counters and ARP Granularity for QCI Level Counters, page 185
• DSCP Marking Based on Both QCI and ARP Values, page 197
• New Standard QCI Support, page 200
• Non-standard QCI Support, page 234
Per QCI Packet Drop Counters and ARP Granularity for QCI Level
Counters
This section describes the Per QCI Packet Drop Counters and ARP Granularity for QCI Level Counters feature.
Feature Description
This section describes the Per QCI Packet Drop Counters and ARP Granularity for QCI Level Counters feature.
Important For the ARP value only the priority level value in the Allocation/Retention Priority (ARP) Information
Element (IE) is considered. Pre-emption Vulnerability (PVI) and Pre-emption Capability (PCI) flags in
the ARP IE are not considered.
The existing show apn statistics name apn-name and show apn statistics Exec Mode CLI commands have
been enhanced. The output of these commands now provides visibility for QoS statistics on a QCI/ARP basis.
Licensing
Important ARP Granularity for QCI Level Counters is a license-controlled feature. Per QCI Packet Drop Counters
functionality does not require a license. Contact your Cisco account or support representative for licensing
details.
Important ARP Granularity for QCI Level Counters is a license-controlled feature. Per QCI Packet Drop Counters
functionality does not require a license. Contact your Cisco account or support representative for licensing
details.
Important If a Stats Profile is associated with more than 12 APNs, the following memory and performance impact
warning is provided:
[WARNING] Configuring QCI/ ARP level statistics for more then 12 APNs will have
memory and performance impact. Do you want to continue [Y/N]
Next, verify that the Stats Profile configuration settings are correct. In Exec Mode, enter the following command:
show stats-profile name stats_profile_name
Notes:
• Where stats_profile_name is the name of the Stats Profile for which you want to view settings.
• The command output includes the following information:
◦Stats Profile name
◦Packet-drop configuration settings for both QCI and ARP
◦QCI ARP combinations for which the StarOS will collect granular ARP statistics
If any of the above settings are incorrect, perform the configuration procedure again to reconfigure the Stats
Profile with the proper settings.
Monitoring Per QCI Packet Drop Counters and ARP Granularity for QCI Level
Counters
This section describes how to monitor the Per QCI Packet Drop Counters and ARP Granularity for QCI Level
Counters feature.
Bulk Statistics
This section provides the bulk statistics that have been added to support the ARP Granularity and per QCI
Packet Drop Counters feature.
APN Schema
The following bulk statistics have been added to the APN Schema to support the New Standard QCIs feature.
qci65-actbear
qci65-setupbear
qci65-relbear
qci65-uplinkpkt-fwd
qci65-dwlinkpkt-fwd
qci65-uplinkbyte-fwd
qci65-dwlinkbyte-fwd
qci65-uplinkpkt-drop
qci65-dwlinkpkt-drop
qci65-uplinkbyte-drop
qci65-dwlinkbyte-drop
qci65-uplinkpkt-drop-mbrexcd
qci65-dwlinkpkt-drop-mbrexcd
qci65-uplinkbyte-drop-mbrexcd
qci65-dwlinkbyte-drop-mbrexcd
qci65-rejbearer
qci66-actbear
qci66-setupbear
qci66-relbear
qci66-uplinkpkt-fwd
qci66-dwlinkpkt-fwd
qci66-uplinkbyte-fwd
qci66-dwlinkbyte-fwd
qci66-uplinkpkt-drop
qci66-dwlinkpkt-drop
qci66-uplinkbyte-drop
qci66-dwlinkbyte-drop
qci66-uplinkpkt-drop-mbrexcd
qci66-dwlinkpkt-drop-mbrexcd
qci66-uplinkbyte-drop-mbrexcd
qci66-dwlinkbyte-drop-mbrexcd
qci66-rejbearer
qci69-actbear
qci69-setupbear
qci69-relbear
qci69-uplinkpkt-fwd
qci69-dwlinkpkt-fwd
qci69-uplinkbyte-fwd
qci69-dwlinkbyte-fwd
qci69-uplinkpkt-drop
qci69-dwlinkpkt-drop
qci69-uplinkbyte-drop
qci69-dwlinkbyte-drop
qci69-uplinkpkt-drop-mbrexcd
qci69-dwlinkpkt-drop-mbrexcd
qci69-uplinkbyte-drop-mbrexcd
qci69-dwlinkbyte-drop-mbrexcd
qci69-rejbearer
qci70-actbear
qci70-setupbear
qci70-relbear
qci70-uplinkpkt-fwd
qci70-dwlinkpkt-fwd
qci70-uplinkbyte-fwd
qci70-dwlinkbyte-fwd
qci70-uplinkpkt-drop
qci70-dwlinkpkt-drop
qci70-uplinkbyte-drop
qci70-dwlinkbyte-drop
qci70-uplinkpkt-drop-mbrexcd
qci70-dwlinkpkt-drop-mbrexcd
qci70-uplinkbyte-drop-mbrexcd
qci70-dwlinkbyte-drop-mbrexcd
qci70-rejbearer
sessstat-bearrel-ded-admin-clear-qci65
sessstat-bearrel-ded-admin-clear-qci66
sessstat-bearrel-ded-admin-clear-qci69
sessstat-bearrel-ded-admin-clear-qci70
Show Commands
This section provides the Exec Mode show commands that are available to support the Per Packet QCI Drop
Counters and ARP Granularity for QCI Level Counters feature.
Notes:
• apn_name: must be the name of a configured APN created in APN Configuration Mode.
• qci: displays packet drop statistics for the specified QCI(s).
• all: displays packet drop statistics for all QCI(s).
• 1-9: displays packet drop statistics for QCI <n>. Must be a QCI number from 1 to 9.
• non-std: displays packet drop statistics for non-standard QCIs.
• non-gbr: displays packet drop statistics for non-standard non-gbr QCIs
• gbr: displays packet drop statistics for non-standard GBR QCIs.
• arp: displays statistics for the specified ARP priority level(s)
• all: displays packet drop statistics for all ARP priority levels.
• 1-15: displays statistics for the specified ARP priority level.
Scenario 2
View packet drop counters with granularity at the QCI/ARP level for all APNs.
show apn statistics qci { all | 1-9 | non-std { gbr | non-gbr } } arp { all | 1-15 }
Notes:
• apn_name: must be the name of a configured APN created in APN Configuration Mode.
• qci: displays packet drop statistics for the specified QCI(s).
• all: displays packet drop statistics for all QCI(s).
• 1-9: displays packet drop statistics for QCI <n>. Must be a QCI number from 1 to 9.
• non-std: displays packet drop statistics for non-standard QCIs.
• non-gbr: displays packet drop statistics for non-standard non-gbr QCIs
• gbr: displays packet drop statistics for non-standard GBR QCIs.
• arp: displays statistics for the specified ARP priority level(s)
• all: displays packet drop statistics for all ARP priority levels.
• 1-15: displays statistics for the specified ARP priority level.
Scenario 3
View the new packet drop counters at granularity of QCI level, and pre-existing QCI level counters for the
specified APN.
show apn statistics name apn_name qci { all | 1-9 | non-std { gbr | non-gbr } }
Notes:
• apn_name: must be the name of a configured APN created in APN Configuration Mode.
• qci: displays packet drop statistics for the specified QCI(s).
• all: displays packet drop statistics for all QCI(s).
• 1-9: displays packet drop statistics for QCI <n>. Must be a QCI number from 1 to 9.
• non-std: displays packet drop statistics for non-standard QCIs.
• non-gbr: displays packet drop statistics for non-standard non-gbr QCIs
• gbr: displays packet drop statistics for non-standard GBR QCIs.
• arp: displays statistics for the specified ARP priority level(s)
• all: displays packet drop statistics for all ARP priority levels.
• 1-15: displays statistics for the specified ARP priority level.
Scenario 4
View the packet drop counters at the granularity of the QCI level, and view pre-existing QCI counters
consolidated for all APNs.
show apn statistics qci { all | 1-9 | non-std { gbr | non-gbr } }
Notes:
• apn_name: must be the name of a configured APN created in APN Configuration Mode.
The output of the show apn statistics name apn_name qci all arp all command has been enhanced to display
the following new statistics:
Data Statistics:
Admin disconnect: 0 0 0 0 0 0 0 0 0
Admin disconnect:
QCI 1:
ARP 1: 0
ARP 2: 0
ARP 3: 0
ARP 4: 0
ARP 5: 0
ARP 6: 0
ARP 7: 0
ARP 8: 0
ARP 9: 0
ARP 10: 0
ARP 11: 0
ARP 12: 0
ARP 13: 0
ARP 14: 0
ARP 15: 0
.
.
.
QCI 9:
ARP 1: 0
ARP 2: 0
ARP 3: 0
ARP 4: 0
ARP 5: 0
ARP 6: 0
ARP 7: 0
ARP 8: 0
ARP 9: 0
ARP 10: 0
ARP 11: 0
ARP 12: 0
ARP 13: 0
ARP 14: 0
ARP 15: 0
Admin disconnect: 0 0 0 0 0 0 0 0 0
Admin disconnect:
QCI 1:
ARP 1: 0
ARP 2: 0
ARP 3: 0
ARP 4: 0
ARP 5: 0
ARP 6: 0
ARP 7: 0
ARP 8: 0
ARP 9: 0
ARP 10: 0
ARP 11: 0
ARP 12: 0
ARP 13: 0
ARP 14: 0
ARP 15: 0
.
.
.
QCI 9:
ARP 1: 0
ARP 2: 0
ARP 3: 0
ARP 4: 0
ARP 5: 0
ARP 6: 0
ARP 7: 0
ARP 8: 0
ARP 9: 0
ARP 10: 0
ARP 11: 0
ARP 12: 0
ARP 13: 0
ARP 14: 0
ARP 15: 0
QCI 1:
ARP 1:
Bearer Active: 0 Bearer setup: 2
Bearer Released: 2 Bearer Rejected: 0
QCI 1:
Bearer Active: 0 Bearer setup: 0
Bearer Released: 0 Bearer Rejected: 0
.
.
QCI 9:
Bearer Active: 0 Bearer setup: 0
Bearer Released: 0 Bearer Rejected: 0
show configuration
The output of this command has been enhanced to show the Stats Profile configuration settings.
• stats-profile <stats_profile_name>
• qci <qci number> arp <arp number>
• packet-drop (if packet-drop is enabled)
Feature Description
P-GW allows users to perform DSCP marking based on QoS Class Identifier (QCI) values. This functionality
has been expanded to include the Priority Level (PL) values 1-15 of Allocation and Retention Priority (ARP),
which allows users to assign different DSCP values for bearers with the same QCI but different ARP priority
values. For example, the ability to assign DSCP values based on QCI+ARP could be used to meet compliance
on priority and emergency calling via VoLTE.
Applies to the P-GW for the following interfaces:
• S5
• S8
• SGi
• S2b
• S8
• S11
• S4
Once values are received from SM, ECS caches these values and uses the cached values for marking the
further packets. Another lookup into the table is done only when there is a mismatch between the currently
cached QCI-ARP value and the current packet's QCI-ARP value. Therefore, any change in the QCI-ARP table
would be affected for inner DSCP marking on existing flows only in case of QCI or ARP change.
Licensing
DSCP marking capability requires that a valid license key be installed. Contact your Cisco Account or Support
representative for information on how to obtain a license.
How It Works
The expansion of functionality to allow assigning different DSCP values for bearers with the same QCI, but
different APR values, works as follows.
• DSCP marking of packets based on QCI+ARP combination allowed
• QCI + ARP configuration will override any DSCP entry for that QCI+ARP combination
• QCI only DSCP entry will override all existing QCI+ARP configuration
• Applying associated DSCP marking for QCI+ARP for Uplink and Downlink functionality is also allowed
Use the following example to specify that the S-GW service is to be associated with an existing QCI-QoS
mapping configuration:
configure
contextcontext_name
sgw-service sgw_service_name
associate qci-qos-mapping name
end
Notes:
• QCI-QoS mapping configurations are created in the AAA context.
Feature Description
The P-GW/SAEGW/S-GW support additional new 3GPP-defined standard QCIs. QCIs 65, 66, 69, and 70
are now supported for Mission Critical and Push-to-Talk (MCPTT) applications. These new standard QCIs
are supported in addition to the previously supported QCIs of 1 through 9, and operator-defined QCIs 128
through 254.
The StarOS will continue to reject QCIs 10 through 127 sent by the PCRF.
Licensing
Important New Standard QCI Support is a licensed feature. Contact your Cisco account or support representative
for licensing details.
How it Works
Although the 3GPP specification mentions that only QCIs 65 and 69 can co-exist, there is no hard restriction
on the QCIs in the StarOS implementation of this feature, as that is applicable to the PCRF. The P-GW acts
as a pass-through node and allows QCIs 65 and 69 if a different QCI combination is requested from PCRF.
With support for standard QCIs 65, 66, 69, and 70 present, the implementation has also added support across
the following StarOS interfaces:
• Gx: Gx processes Default Bearer QoS and Rule Validation allowing the new Mission Critical (MC)/Push
to Talk (PTT) QCIs. When the MC/PTT bit is not negotiated with the PCRF, the PCEF will reject the
creation of a bearer or reject call setup.
• sessmgr: The P-GW sessmgr now processes the updating and modification of QoS. The P-GW rejects
all UE initiated BRC creation for the new standard QCIs.
• ECS: ECS accepts the new standard QCIs when received from the PCRF and will reject them when
either the license is not configured or the same is received in 3G. The ECS is able to update a Default
bearer with this QoS change or create a Dedicated Bearer for the new standard QCIs.
Handoff Behavior
For Gn/Gp handoffs, local mapping via the CLI is supported so that the P-GW/SAEGW/S-GW is in sync with
the MME-to-SGSN context transfer. The following scenarios are supported:
No Local QoS Mapping Present: When no local mapping is present for the new QCIs, a call handoff from
4G to 3G will be rejected.
Local QoS Mapping Present: Three scenarios are supported when local mapping is present:
• Local Mapping present for MME-SGSN and PCRF Out of Synchronization: When local mapping
is present it is assumed that the QoS mapping in the P-GW is in sync with the mapping from the MME
to SGSN. Even if the QoS mapping for one of the transferred PDPs during a Gn/Gp handoff is not in
sync with MME-SGSN mapping, the P-GW/SAEGW/S-GW still continues with the handoff with the
local mapping present. However, the CDR generated while waiting for the PCRF response during the
handoff would be out of sync with the CDR's received after the handoff.
• Mapping present for MME-SGSN and PCRF in Synchronization: When local mapping is in sync
with the MME-SGSN there is no difference in the CDR generated after the handoff.
• Partial Mapping Present: Partial mapping occurs when some MC/PTT QCI(s) have mapping and the
remainder of the MC/PTT QCI(s) do not have mapping. In this case the call is dropped.
These sections describe new behaviors and provide behavior clarification for this feature. Behavior not
described is similar to that for Standard QCIs.
Procedure Pre-Condition Call QCI Message Type Request with PGW Gx Interface (Type of Re-mapped Expected
(3G/4G/ Modification Type Of QCI License QCI received) Behavior
S2b/S2a)
CCA-I CCA-U RAR
Setup 3G N/A N/A Create PDP Std QCI Enabled MC/PTT- N/A N/A Call rejected
(GGSN) Req Std QCI by
application
Setup N/A N/A PBU Std QCI Enabled MC/PTT- N/A N/A Call accepted
eHRPD Std QCI and created
with this rule
Setup 4G N/A N/A Create Session Std QCI Enabled MC/PTT- N/A N/A Call accepted
(RAT: Req Std QCI and created
S4-SGSN) with this rule
Handoff Procedures
This section provides detailed information on expected call flow output for various handoff procedure scenarios
with the New Standard QCI Support feature.
Procedure Pre-Condition Call QCI Message Type Request with PGW Gx Interface (Type of Re-mapped Expected
(3G/4G/ Modification Type Of QCI License QCI received) Behavior
S2b/S2a)
CCA-I CCA-U RAR
Default Call Create MC/PTT - QCI Enabled N/A MC/PTT- N/A Handoff
bearer existing Session Std QCI accepted
existing with Req received for and
for WiFi MC/PTT- default downloaded
QCI bearer MC/PTT
requested to Std
handoff to QCI
MC/PTT- applied
QCI
Procedure Pre-Condition Call QCI Message Type Request with PGW Gx Interface (Type of Re-mapped Expected
(3G/4G/ Modification Type Of QCI License QCI received) Behavior
S2b/S2a)
CCA-I CCA-U RAR
GnGp Update PDP Call Update PDP Partial Enabled N/A Partial N/A Handoff
Handoff request existing Req mapping mapped rejected and
received for with received from Std QCI call drop
(4G
(LTE) to primary MC/PTT- PCRF for for Initiated
PDP and QCI MC/PTT- QCI MC/PTT-
3G
(GGSN)) pending requested to to Std-QCI QCIs
response Std-QCI received.
where Here
(Local
mapping mapping
mapping
not is not
present)
received for Received
few for some
MC/PTT- PDP
QCI bearers bearers .
Update PDP Call Update PDP No mapping Enabled N/A No N/A Handoff
Request existing Req Received from mapping rejected and
received for with PCRF for received call drop
primary MC/PTT- MC/PTT- QCI initiated
PDP and QCI to Std-QCI
pending requested to
response Std-QCI
where no
(Local
mapping
mapping
received for
present)
few
MC/PTT-
QCI bearers
Update PDP Call Update PDP N/A Enabled N/A MC/PTT N/A MC/PTT QCI
request existing Req update mapped rule
received for with Std rules associated
primary primary received dedicated
PDP and PDP & for Std bearer purged
pending MC/PTT- QCI and handoff
response QCI dedicated accepted
requested to bearers
(No-Local
Std-QCI
Mapping
Present)
Procedure Pre-Condition Call QCI Message Type Request with PGW Gx Interface (Type of Re-mapped Expected
(3G/4G/ Modification Type Of QCI License QCI received) Behavior
S2b/S2a)
CCA-I CCA-U RAR
Update PDP Handoff
Request rejected and
received for call drop
primary Initiated
PDP and (dropped
pending before
response Initiating
CCA-U for
(No-local
handoff)
mapping
present)
Update PDP Call Update PDP PCRF Enabled N/A No N/A Handoff
Request existing Req Timeout No response rejected and
received for with Response from call drop
primary MC/PTT- received PCRF / initiated
PDP and QCI CCA-U
pending requested to timeout
response Std-QCI
(Local
mapping
present)
Update PDP Call Update PDP Mapping Enabled N/A All N/A Handoff
Request existing Req received from mapping accepted
received for with PCRF for received
primary MC/PTT- MC/PTT- QCI from
PDP and QCI to Std-QCI PCRF
pending requested to
response. Std-QCI
BCM mode
is mixed.
(Local
mapping
present and
same as
what QCI
values
comes in
UPC during
HO)
Procedure Pre-Condition Call QCI Message Type Request with PGW Gx Interface (Type of Re-mapped Expected
(3G/4G/ Modification Type Of QCI License QCI received) Behavior
S2b/S2a)
CCA-I CCA-U RAR
Update PDP Call
Request existing
received for with
primary MC/PTT-
PDP and QCI
pending requested to
response. Std-QCI
BCM mode
is mixed.
(Local
mapping
present and
not same as
what QCI
values
comes in
UPC during
HO).
Update PDP Call Update PDP Mapping Enabled N/A All N/A Handoff
Request existing Req received from mapping accepted
received for with PCRF for received
primary MC/PTT- MC/PTT- QCI from
PDP and QCI to Std-QCI PCRF
pending requested to
response. Std-QCI
BCM mode
is UE Only.
(Local
mapping
present and
same as
what QCI
values come
in UPC
during HO)
Procedure Pre-Condition Call QCI Message Type Request with PGW Gx Interface (Type of Re-mapped Expected
(3G/4G/ Modification Type Of QCI License QCI received) Behavior
S2b/S2a)
CCA-I CCA-U RAR
Update PDP
Request
received for
primary
PDP and
pending
response.
BCM mode
is UE Only.
(Local
mapping
present and
not same as
what QCI
values come
in UPC
during HO.)
Update PDP Call Update PDP N/A Enabled N/A N/A N/A Handoff
Request existing Req rejected and
received for with call drop
primary MC/PTT- initiated
PDP and QCI
pending requested to
response Std-QCI.
Also
(Local
suppress-
mapping
NRUPC
present/not
UPC is
present)
configured
at the
GGSN
service
level.
Update PDP Update PDP Complete Enabled N/A All N/A Handoff
Request Req mapping mapped accepted
received for Received from Std QCI
primary PCRF for for
PDP and MC/PTT- QCI MC/PTT-
response to Std-QCI (as QCI
sent per Local
MC/PTT to
(Local
Std QCI
mapping
mapping)
present)
Procedure Pre-Condition Call QCI Message Type Request with PGW Gx Interface (Type of Re-mapped Expected
(3G/4G/ Modification Type Of QCI License QCI received) Behavior
S2b/S2a)
CCA-I CCA-U RAR
Call
existing
with
MC/PTT-
QCI
requested to
Std-QCI
mapping
received for
All
MC/PTT-
QCI bearers
Update PDP Call Update PDP Complete Enabled N/A All N/A Handoff
Request existing Req mapping mapped accepted and
received for with received from Std QCI Update PDP
primary MC/PTT- PCRF for for Response
PDP and QCI MC/PTT- QCI MC/PTT- sent for all
response requested to to Std-QCI QCI bearers
sent Std-QCI (different
mapping from local
(Local
received for MC/PTT to
mapping
All Std QCI
present)
MC/PTT- mapping)
QCI bearers
eHRPD Create Only one Create Session MC/PTT - Enabled N/A MC/PTT- N/A Handoff
-> LTE Session Req bearer Req QCI Std QCI accepted and
received existing received dedicated
with ho_ind with the with rules bearer are
=1 call created with
the MC/PTT-
Std QCI
received.
LTE -> Default + Call PBU N/A Enabled N/A N/A N/A Handoff
eHRPD dedicated existing accepted and
bearer with PBA is sent
existing for MC/PTT- and dedicated
LTE QCI bearer rules
are added
under single
bearer
Procedure Pre-Condition Call QCI Message Type Request with PGW Gx Interface (Type of Re-mapped Expected
(3G/4G/ Modification Type Of QCI License QCI received) Behavior
S2b/S2a)
CCA-I CCA-U RAR
LTE UE Default N/A Bearer MC/PTT- Std N/A N/A N/A N/A BRC rejected
Initiated bearer Resource QCI by
Bearer existing for Command application
LTE
Default N/A Bearer Std QCI Disabled N/A MC/PTT- N/A BRC rejected
bearer Resource Std / rule rejected
existing for Command dedicated with resource
LTE QCI allocation
failure
Default N/A Bearer Std QCI Enabled N/A MC/PTT- N/A BRC rejected
bearer Resource Std /CBReq
existing for Command dedicated initiated with
LTE QCI MC/PTT-
Std QCI
Bearer Creation
This section provides detailed information on the expected call flow output for Bearer Creation scenarios with
the New Standard QCI Support feature.
Procedure Pre-Condition Call QCI Message Type Request with PGW Gx Interface (Type of Re-mapped Expected
(3G/4G/ Modification Type Of QCI License QCI received) Behavior
S2b/S2a)
CCA-I CCA-U RAR
GGSN Primary New RAR Procedure N/A Enabled N/A N/A Rules CCR-I
secondary PDP secondary received resource
PDP existing for PDP with allocation
creation GGSN requested MC/PTT- failure for
with Std secondary
MC/PTT-Std- QCI PDP sent to
QCI PCRF
Bearer Update
This section provides detailed information on the expected call flow output for Bearer Update scenarios with
the New Standard QCI Support feature.
Procedure Pre-Condition Call QCI Message Type Request with PGW Gx Interface (Type of Re-mapped Expected
(3G/4G/ Modification Type Of QCI License QCI received) Behavior
S2b/S2a)
CCA-I CCA-U RAR
GGSN Primary Call existing RAR Procedure MC/PTT- Std Enabled N/A N/A MC/PTT- CCR-I QoS
Primary PDP with QCI Std modification
PDP existing for Std-QCI QCI for failure for
QoS GGSN requested to primary primary PDP
modification MC/PTT- PDP QoS
Std QCI received modification
modification rejected
GGSN Primary Call existing RAR Procedure MC/PTT- Std Enabled N/A N/A MC/PTT- CCR-I
Secondary PDP & with QCI Std resource
PDP Qos secondary Std-QCI QCI for allocation
Modification PDP requested to secondary failure for
existing for MC/PTT- PDP secondary
GGSN Std QCI with PDP QoS
modification rules modification
for received sent
secondary
PDP
• no disables transaction rate network initiated setup/teardown events for the specified new standard QCI
value.
Important The LTE Wireless Priority Feature Set must be enabled to configure the mission-critical-qcis option. The
LTE Wireless Priority Feature Set is a license-controlled feature. Contact your Cisco account or support
representative for licensing details.
Bulk Statistics
This section lists the bulk statistics that have been added to support the New Standard QCIs feature.
APN Schema
The following bulk statistics have been added to the APN Schema to support the New Standard QCIs feature.
qci65-actbear
qci65-setupbear
qci65-relbear
qci65-uplinkpkt-fwd
qci65-dwlinkpkt-fwd
qci65-uplinkbyte-fwd
qci65-dwlinkbyte-fwd
qci65-uplinkpkt-drop
qci65-dwlinkpkt-drop
qci65-uplinkbyte-drop
qci65-dwlinkbyte-drop
qci65-uplinkpkt-drop-mbrexcd
qci65-dwlinkpkt-drop-mbrexcd
qci65-uplinkbyte-drop-mbrexcd
qci65-dwlinkbyte-drop-mbrexcd
qci65-rejbearer
qci66-actbear
qci66-setupbear
qci66-relbear
qci66-uplinkpkt-fwd
qci66-dwlinkpkt-fwd
qci66-uplinkbyte-fwd
qci66-dwlinkbyte-fwd
qci66-uplinkpkt-drop
qci66-dwlinkpkt-drop
qci66-uplinkbyte-drop
qci66-dwlinkbyte-drop
qci66-uplinkpkt-drop-mbrexcd
qci66-dwlinkpkt-drop-mbrexcd
qci66-uplinkbyte-drop-mbrexcd
qci66-dwlinkbyte-drop-mbrexcd
qci66-rejbearer
qci69-actbear
qci69-setupbear
qci69-relbear
qci69-uplinkpkt-fwd
qci69-dwlinkpkt-fwd
qci69-uplinkbyte-fwd
qci69-dwlinkbyte-fwd
qci69-uplinkpkt-drop
qci69-dwlinkpkt-drop
qci69-uplinkbyte-drop
qci69-dwlinkbyte-drop
qci69-uplinkpkt-drop-mbrexcd
qci69-dwlinkpkt-drop-mbrexcd
qci69-uplinkbyte-drop-mbrexcd
qci69-dwlinkbyte-drop-mbrexcd
qci69-rejbearer
qci70-actbear
qci70-setupbear
qci70-relbear
qci70-uplinkpkt-fwd
qci70-dwlinkpkt-fwd
qci70-uplinkbyte-fwd
qci70-dwlinkbyte-fwd
qci70-uplinkpkt-drop
qci70-dwlinkpkt-drop
qci70-uplinkbyte-drop
qci70-dwlinkbyte-drop
qci70-uplinkpkt-drop-mbrexcd
qci70-dwlinkpkt-drop-mbrexcd
qci70-uplinkbyte-drop-mbrexcd
qci70-dwlinkbyte-drop-mbrexcd
qci70-rejbearer
sessstat-bearrel-ded-admin-clear-qci65
sessstat-bearrel-ded-admin-clear-qci66
sessstat-bearrel-ded-admin-clear-qci69
sessstat-bearrel-ded-admin-clear-qci70
GTPU Schema
The following bulk statistics have been added to the GTPU Schema to support the New Standard QCIs feature.
qci65-uplink-pkts
qci65-uplink-bytes
qci65-dwlink-pkts
qci65-dwlink-byte
qci65-pkts-discard
qci65-bytes-discard
qci66-uplink-pkts
qci66-uplink-bytes
qci66-dwlink-pkts
qci66-dwlink-byte
qci66-pkts-discard
qci66-bytes-discard
qci69-uplink-pkts
qci69-uplink-bytes
qci69-dwlink-pkts
qci69-dwlink-byte
qci69-pkts-discard
qci69-bytes-discard
qci70-uplink-pkts
qci70-uplink-bytes
qci70-dwlink-pkts
qci70-dwlink-byte
qci70-pkts-discard
qci70-bytes-discard
P-GW Schema
The following bulk statistics have been added to the P-GW schema to support the New Standard QCIs feature.
subqosstat-bearact-qci65
subqosstat-bearact-qci66
subqosstat-bearact-qci69
subqosstat-bearact-qci70
subqosstat-bearsetup-qci65
subqosstat-bearsetup-qci66
subqosstat-bearsetup-qci69
subqosstat-bearsetup-qci70
subqosstat-bearrel-qci65
subqosstat-bearrel-qci66
subqosstat-bearrel-qci69
subqosstat-bearrel-qci70
subdatastat-uppktfwd-qci65
subdatastat-uppktfwd-qci66
subdatastat-uppktfwd-qci69
subdatastat-uppktfwd-qci70
subdatastat-upbytefwd-qci65
subdatastat-upbytefwd-qci66
subdatastat-upbytefwd-qci69
subdatastat-upbytefwd-qci70
subdatastat-downpktfwd-qci65
subdatastat-downpktfwd-qci66
subdatastat-downpktfwd-qci69
subdatastat-downpktfwd-qci70
subdatastat-downbytefwd-qci65
subdatastat-downbytefwd-qci66
subdatastat-downbytefwd-qci69
subdatastat-downbytefwd-qci70
subdatastat-uppktdrop-qci65
subdatastat-uppktdrop-qci66
subdatastat-uppktdrop-qci69
subdatastat-uppktdrop-qci70
subdatastat-upbytedrop-qci65
subdatastat-upbytedrop-qci66
subdatastat-upbytedrop-qci69
subdatastat-upbytedrop-qci70
subdatastat-downpktdrop-qci65
subdatastat-downpktdrop-qci66
subdatastat-downpktdrop-qci69
subdatastat-downpktdrop-qci70
subdatastat-downbytedrop-qci65
subdatastat-downbytedrop-qci66
subdatastat-downbytedrop-qci69
subdatastat-downbytedrop-qci70
subdatastat-uppktdropmbrexc-qci65
subdatastat-uppktdropmbrexc-qci66
subdatastat-uppktdropmbrexc-qci69
subdatastat-uppktdropmbrexc-qci70
subdatastat-upbytedropmbrexc-qci65
subdatastat-upbytedropmbrexc-qci66
subdatastat-upbytedropmbrexc-qci69
subdatastat-upbytedropmbrexc-qci70
subdatastat-downpktdropmbrexc-qci65
subdatastat-downpktdropmbrexc-qci66
subdatastat-downpktdropmbrexc-qci69
subdatastat-downpktdropmbrexc-qci70
subdatastat-downbytedropmbrexc-qci65
subdatastat-downbytedropmbrexc-qci66
subdatastat-downbytedropmbrexc-qci69
subdatastat-downbytedropmbrexc-qci70
SAEGW Schema
The following bulk statistics have been added to the SAEGW Schema to support the New Standard QCIs
feature.
sgw-totepsbearact-qci65
sgw-totepsbearact-qci66
sgw-totepsbearact-qci69
sgw-totepsbearact-qci70
sgw-totepsbearset-qci65
sgw-totepsbearset-qci66
sgw-totepsbearset-qci69
sgw-totepsbearset-qci70
sgw-totepsbearrel-qci65
sgw-totepsbearrel-qci66
sgw-totepsbearrel-qci69
sgw-totepsbearrel-qci70
sgw-totepsbearmod-qci65
sgw-totepsbearmod-qci66
sgw-totepsbearmod-qci69
sgw-totepsbearmod-qci70
sgw-totepsbearrel-dedrsn-pgw-qci65
sgw-totepsbearrel-dedrsn-pgw-qci66
sgw-totepsbearrel-dedrsn-pgw-qci69
sgw-totepsbearrel-dedrsn-pgw-qci70
sgw-totepsbearrel-dedrsn-s1err-qci65
sgw-totepsbearrel-dedrsn-s1err-qci66
sgw-totepsbearrel-dedrsn-s1err-qci69
sgw-totepsbearrel-dedrsn-s1err-qci70
sgw-totepsbearrel-dedrsn-s5err-qci65
sgw-totepsbearrel-dedrsn-s5err-qci66
sgw-totepsbearrel-dedrsn-s5err-qci69
sgw-totepsbearrel-dedrsn-s5err-qci70
sgw-totepsbearrel-dedrsn-s4err-qci65
sgw-totepsbearrel-dedrsn-s4err-qci66
sgw-totepsbearrel-dedrsn-s4err-qci69
sgw-totepsbearrel-dedrsn-s4err-qci70
sgw-totepsbearrel-dedrsn-s12err-qci65
sgw-totepsbearrel-dedrsn-s12err-qci66
sgw-totepsbearrel-dedrsn-s12err-qci69
sgw-totepsbearrel-dedrsn-s12err-qci70
sgw-totepsbearrel-dedrsn-local-qci65
sgw-totepsbearrel-dedrsn-local-qci66
sgw-totepsbearrel-dedrsn-local-qci69
sgw-totepsbearrel-dedrsn-local-qci70
sgw-totepsbearrel-dedrsn-pdn-qci65
sgw-totepsbearrel-dedrsn-pdn-qci66
sgw-totepsbearrel-dedrsn-pdn-qci69
sgw-totepsbearrel-dedrsn-pdn-qci70
sgw-totepsbearrel-dedrsn-pathfail-s1-u-qci65
sgw-totepsbearrel-dedrsn-pathfail-s1-u-qci66
sgw-totepsbearrel-dedrsn-pathfail-s1-u-qci69
sgw-totepsbearrel-dedrsn-pathfail-s1-u-qci70
sgw-totepsbearrel-dedrsn-pathfail-s5-u-qci65
sgw-totepsbearrel-dedrsn-pathfail-s5-u-qci66
sgw-totepsbearrel-dedrsn-pathfail-s5-u-qci69
sgw-totepsbearrel-dedrsn-pathfail-s5-u-qci70
sgw-totepsbearrel-dedrsn-pathfail-s5-qci65
sgw-totepsbearrel-dedrsn-pathfail-s5-qci66
sgw-totepsbearrel-dedrsn-pathfail-s5-qci69
sgw-totepsbearrel-dedrsn-pathfail-s5-qci70
sgw-totepsbearrel-dedrsn-pathfail-s11-qci65
sgw-totepsbearrel-dedrsn-pathfail-s11-qci66
sgw-totepsbearrel-dedrsn-pathfail-s11-qci69
sgw-totepsbearrel-dedrsn-pathfail-s11-qci70
sgw-totepsbearrel-dedrsn-pathfail-s12-qci65
sgw-totepsbearrel-dedrsn-pathfail-s12-qci66
sgw-totepsbearrel-dedrsn-pathfail-s12-qci69
sgw-totepsbearrel-dedrsn-pathfail-s12-qci70
sgw-totepsbearrel-dedrsn-pathfail-s4-u-qci65
sgw-totepsbearrel-dedrsn-pathfail-s4-u-qci66
sgw-totepsbearrel-dedrsn-pathfail-s4-u-qci69
sgw-totepsbearrel-dedrsn-pathfail-s4-u-qci70
sgw-totepsbearrel-dedrsn-inactivity-timeout-qci65
sgw-totepsbearrel-dedrsn-inactivity-timeout-qci66
sgw-totepsbearrel-dedrsn-inactivity-timeout-qci69
sgw-totepsbearrel-dedrsn-inactivity-timeout-qci70
sgw-totepsbearrel-dedrsn-other-qci65
sgw-totepsbearrel-dedrsn-other-qci66
sgw-totepsbearrel-dedrsn-other-qci69
sgw-totepsbearrel-dedrsn-other-qci70
sgw-datastat-ul-qci65totbyte
sgw-datastat-ul-qci65totpkt
sgw-datastat-ul-qci66totbyte
sgw-datastat-ul-qci66totpkt
sgw-datastat-ul-qci69totbyte
sgw-datastat-ul-qci69totpkt
sgw-datastat-ul-qci70totbyte
sgw-datastat-ul-qci70totpkt
sgw-datastat-ul-dropstat-qci65totbyte
sgw-datastat-ul-dropstat-qci65totpkt
sgw-datastat-ul-dropstat-qci66totbyte
sgw-datastat-ul-dropstat-qci66totpkt
sgw-datastat-ul-dropstat-qci69totbyte
sgw-datastat-ul-dropstat-qci69totpkt
sgw-datastat-ul-dropstat-qci70totbyte
sgw-datastat-ul-dropstat-qci70totpkt
sgw-datastat-dl-qci65totbyte
sgw-datastat-dl-qci65totpkt
sgw-datastat-dl-qci66totbyte
sgw-datastat-dl-qci66totpkt
sgw-datastat-dl-qci69totbyte
sgw-datastat-dl-qci69totpkt
sgw-datastat-dl-qci70totbyte
sgw-datastat-dl-qci70totpkt
sgw-datastat-dl-dropstat-qci65totbyte
sgw-datastat-dl-dropstat-qci65totpkt
sgw-datastat-dl-dropstat-qci66totbyte
sgw-datastat-dl-dropstat-qci66totpkt
sgw-datastat-dl-dropstat-qci69totbyte
sgw-datastat-dl-dropstat-qci69totpkt
sgw-datastat-dl-dropstat-qci70totbyte
sgw-datastat-dl-dropstat-qci70totpkt
sgw-s1u-ul-qci65totbyte
sgw-s1u-ul-qci65totpkt
sgw-s1u-ul-qci66totbyte
sgw-s1u-ul-qci66totpkt
sgw-s1u-ul-qci69totbyte
sgw-s1u-ul-qci69totpkt
sgw-s1u-ul-qci70totbyte
sgw-s1u-ul-qci70totpkt
sgw-s1u-ul-drop-qci65totbyte
sgw-s1u-ul-drop-qci65totpkt
sgw-s1u-ul-drop-qci66totbyte
sgw-s1u-ul-drop-qci66totpkt
sgw-s1u-ul-drop-qci69totbyte
sgw-s1u-ul-drop-qci69totpkt
sgw-s1u-ul-drop-qci70totbyte
sgw-s1u-ul-drop-qci70totpkt
sgw-s1u-dl-qci65totbyte
sgw-s1u-dl-qci65totpkt
sgw-s1u-dl-qci66totbyte
sgw-s1u-dl-qci66totpkt
sgw-s1u-dl-qci69totbyte
sgw-s1u-dl-qci69totpkt
sgw-s1u-dl-qci70totbyte
sgw-s1u-dl-qci70totpkt
sgw-s1u-dl-drop-qci65totbyte
sgw-s1u-dl-drop-qci65totpkt
sgw-s1u-dl-drop-qci66totbyte
sgw-s1u-dl-drop-qci66totpkt
sgw-s1u-dl-drop-qci69totbyte
sgw-s1u-dl-drop-qci69totpkt
sgw-s1u-dl-drop-qci70totbyte
sgw-s1u-dl-drop-qci70totpkt
sgw-s4u-ul-qci65totbyte
sgw-s4u-ul-qci65totpkt
sgw-s4u-ul-qci66totbyte
sgw-s4u-ul-qci66totpkt
sgw-s4u-ul-qci69totbyte
sgw-s4u-ul-qci69totpkt
sgw-s4u-ul-qci70totbyte
sgw-s4u-ul-qci70totpkt
sgw-s4u-ul-drop-qci65totbyte
sgw-s4u-ul-drop-qci65totpkt
sgw-s4u-ul-drop-qci66totbyte
sgw-s4u-ul-drop-qci66totpkt
sgw-s4u-ul-drop-qci69totbyte
sgw-s4u-ul-drop-qci69totpkt
sgw-s4u-ul-drop-qci70totbyte
sgw-s4u-ul-drop-qci70totpkt
sgw-s4u-dl-qci65totbyte
sgw-s4u-dl-qci65totpkt
sgw-s4u-dl-qci66totbyte
sgw-s4u-dl-qci66totpkt
sgw-s4u-dl-qci69totbyte
sgw-s4u-dl-qci69totpkt
sgw-s4u-dl-qci70totbyte
sgw-s4u-dl-qci70totpkt
sgw-s4u-dl-drop-qci65totbyte
sgw-s4u-dl-drop-qci65totpkt
sgw-s4u-dl-drop-qci66totbyte
sgw-s4u-dl-drop-qci66totpkt
sgw-s4u-dl-drop-qci69totbyte
sgw-s4u-dl-drop-qci69totpkt
sgw-s4u-dl-drop-qci70totbyte
sgw-s4u-dl-drop-qci70totpkt
sgw-s12-ul-qci65totbyte
sgw-s12-ul-qci65totpkt
sgw-s12-ul-qci66totbyte
sgw-s12-ul-qci66totpkt
sgw-s12-ul-qci69totbyte
sgw-s12-ul-qci69totpkt
sgw-s12-ul-qci70totbyte
sgw-s12-ul-qci70totpkt
sgw-s12-ul-drop-qci65totbyte
sgw-s12-ul-drop-qci65totpkt
sgw-s12-ul-drop-qci66totbyte
sgw-s12-ul-drop-qci66totpkt
sgw-s12-ul-drop-qci69totbyte
sgw-s12-ul-drop-qci69totpkt
sgw-s12-ul-drop-qci70totbyte
sgw-s12-ul-drop-qci70totpkt
sgw-s12-dl-qci65totbyte
sgw-s12-dl-qci65totpkt
sgw-s12-dl-qci66totbyte
sgw-s12-dl-qci66totpkt
sgw-s12-dl-qci69totbyte
sgw-s12-dl-qci69totpkt
sgw-s12-dl-qci70totbyte
sgw-s12-dl-qci70totpkt
sgw-s12-dl-drop-qci65totbyte
sgw-s12-dl-drop-qci65totpkt
sgw-s12-dl-drop-qci66totbyte
sgw-s12-dl-drop-qci66totpkt
sgw-s12-dl-drop-qci69totbyte
sgw-s12-dl-drop-qci69totpkt
sgw-s12-dl-drop-qci70totbyte
sgw-s12-dl-drop-qci70totpkt
sgw-s5-ul-qci65totbyte
sgw-s5-ul-qci65totpkt
sgw-s5-ul-qci66totbyte
sgw-s5-ul-qci66totpkt
sgw-s5-ul-qci69totbyte
sgw-s5-ul-qci69totpkt
sgw-s5-ul-qci70totbyte
sgw-s5-ul-qci70totpkt
sgw-s5-ul-drop-qci65totbyte
sgw-s5-ul-drop-qci65totpkt
sgw-s5-ul-drop-qci66totbyte
sgw-s5-ul-drop-qci66totpkt
sgw-s5-ul-drop-qci69totbyte
sgw-s5-ul-drop-qci69totpkt
sgw-s5-ul-drop-qci70totbyte
sgw-s5-ul-drop-qci70totpkt
sgw-s5-dl-qci65totbyte
sgw-s5-dl-qci65totpkt
sgw-s5-dl-qci66totbyte
sgw-s5-dl-qci66totpkt
sgw-s5-dl-qci69totbyte
sgw-s5-dl-qci69totpkt
sgw-s5-dl-qci70totbyte
sgw-s5-dl-qci70totpkt
sgw-s5-dl-drop-qci65totbyte
sgw-s5-dl-drop-qci65totpkt
sgw-s5-dl-drop-qci66totbyte
sgw-s5-dl-drop-qci66totpkt
sgw-s5-dl-drop-qci69totbyte
sgw-s5-dl-drop-qci69totpkt
sgw-s5-dl-drop-qci70totbyte
sgw-s5-dl-drop-qci70totpkt
sgw-s8-ul-qci65totbyte
sgw-s8-ul-qci65totpkt
sgw-s8-ul-qci66totbyte
sgw-s8-ul-qci66totpkt
sgw-s8-ul-qci69totbyte
sgw-s8-ul-qci69totpkt
sgw-s8-ul-qci70totbyte
sgw-s8-ul-qci70totpkt
sgw-s8-ul-drop-qci65totbyte
sgw-s8-ul-drop-qci65totpkt
sgw-s8-ul-drop-qci66totbyte
sgw-s8-ul-drop-qci66totpkt
sgw-s8-ul-drop-qci69totbyte
sgw-s8-ul-drop-qci69totpkt
sgw-s8-ul-drop-qci70totbyte
sgw-s8-ul-drop-qci70totpkt
sgw-s8-dl-qci65totbyte
sgw-s8-dl-qci65totpkt
sgw-s8-dl-qci66totbyte
sgw-s8-dl-qci66totpkt
sgw-s8-dl-qci69totbyte
sgw-s8-dl-qci69totpkt
sgw-s8-dl-qci70totbyte
sgw-s8-dl-qci70totpkt
sgw-s8-dl-drop-qci65totbyte
sgw-s8-dl-drop-qci65totpkt
sgw-s8-dl-drop-qci66totbyte
sgw-s8-dl-drop-qci66totpkt
sgw-s8-dl-drop-qci69totbyte
sgw-s8-dl-drop-qci69totpkt
sgw-s8-dl-drop-qci70totbyte
sgw-s8-dl-drop-qci70totpkt
sgw-s5s8-ul-qci65totbyte
sgw-s5s8-ul-qci65totpkt
sgw-s5s8-ul-qci66totbyte
sgw-s5s8-ul-qci66totpkt
sgw-s5s8-ul-qci69totbyte
sgw-s5s8-ul-qci69totpkt
sgw-s5s8-ul-qci70totbyte
sgw-s5s8-ul-qci70totpkt
sgw-s5s8-ul-drop-qci65totbyte
sgw-s5s8-ul-drop-qci65totpkt
sgw-s5s8-ul-drop-qci66totbyte
sgw-s5s8-ul-drop-qci66totpkt
sgw-s5s8-ul-drop-qci69totbyte
sgw-s5s8-ul-drop-qci69totpkt
sgw-s5s8-ul-drop-qci70totbyte
sgw-s5s8-ul-drop-qci70totpkt
sgw-s5s8-dl-qci65totbyte
sgw-s5s8-dl-qci65totpkt
sgw-s5s8-dl-qci66totbyte
sgw-s5s8-dl-qci66totpkt
sgw-s5s8-dl-qci69totbyte
sgw-s5s8-dl-qci69totpkt
sgw-s5s8-dl-qci70totbyte
sgw-s5s8-dl-qci70totpkt
sgw-s5s8-dl-drop-qci65totbyte
sgw-s5s8-dl-drop-qci65totpkt
sgw-s5s8-dl-drop-qci66totbyte
sgw-s5s8-dl-drop-qci66totpkt
sgw-s5s8-dl-drop-qci69totbyte
sgw-s5s8-dl-drop-qci69totpkt
sgw-s5s8-dl-drop-qci70totbyte
sgw-s5s8-dl-drop-qci70totpkt
pgw-subqosstat-bearact-qci65
pgw-subqosstat-bearact-qci66
pgw-subqosstat-bearact-qci69
pgw-subqosstat-bearact-qci70
pgw-subqosstat-bearset-qci65
pgw-subqosstat-bearset-qci66
pgw-subqosstat-bearset-qci69
pgw-subqosstat-bearset-qci70
pgw-subqosstat-bearrel-qci65
pgw-subqosstat-bearrel-qci66
pgw-subqosstat-bearrel-qci69
pgw-subqosstat-bearrel-qci70
pgw-subdatastat-ulpktfwd-qci65
pgw-subdatastat-ulpktfwd-qci66
pgw-subdatastat-ulpktfwd-qci69
pgw-subdatastat-ulpktfwd-qci70
pgw-subdatastat-ulbytefwd-qci65
pgw-subdatastat-ulbytefwd-qci66
pgw-subdatastat-ulbytefwd-qci69
pgw-subdatastat-ulbytefwd-qci70
pgw-subdatastat-dlpktfwd-qci65
pgw-subdatastat-dlpktfwd-qci66
pgw-subdatastat-dlpktfwd-qci69
pgw-subdatastat-dlpktfwd-qci70
pgw-subdatastat-dlbytefwd-qci65
pgw-subdatastat-dlbytefwd-qci66
pgw-subdatastat-dlbytefwd-qci69
pgw-subdatastat-dlbytefwd-qci70
pgw-subdatastat-ulpktdrop-qci65
pgw-subdatastat-ulpktdrop-qci66
pgw-subdatastat-ulpktdrop-qci69
pgw-subdatastat-ulpktdrop-qci70
pgw-subdatastat-ulbytedrop-qci65
pgw-subdatastat-ulbytedrop-qci66
pgw-subdatastat-ulbytedrop-qci69
pgw-subdatastat-ulbytedrop-qci70
pgw-subdatastat-dlpktdrop-qci65
pgw-subdatastat-dlpktdrop-qci66
pgw-subdatastat-dlpktdrop-qci69
pgw-subdatastat-dlpktdrop-qci70
pgw-subdatastat-dlbytedrop-qci65
pgw-subdatastat-dlbytedrop-qci66
pgw-subdatastat-dlbytedrop-qci69
pgw-subdatastat-dlbytedrop-qci70
pgw-subdatastat-ulpktdropmbrexc-qci65
pgw-subdatastat-ulpktdropmbrexc-qci66
pgw-subdatastat-ulpktdropmbrexc-qci69
pgw-subdatastat-ulpktdropmbrexc-qci70
pgw-subdatastat-ulbytedropmbrexc-qci65
pgw-subdatastat-ulbytedropmbrexc-qci66
pgw-subdatastat-ulbytedropmbrexc-qci69
pgw-subdatastat-ulbytedropmbrexc-qci70
pgw-subdatastat-dlpktdropmbrexc-qci65
pgw-subdatastat-dlpktdropmbrexc-qci66
pgw-subdatastat-dlpktdropmbrexc-qci69
pgw-subdatastat-dlpktdropmbrexc-qci70
pgw-subdatastat-dlbytedropmbrexc-qci65
pgw-subdatastat-dlbytedropmbrexc-qci66
pgw-subdatastat-dlbytedropmbrexc-qci69
pgw-subdatastat-dlbytedropmbrexc-qci70
collapsed-subdatastat-ulpktfwd-qci65
collapsed-subdatastat-ulpktfwd-qci66
collapsed-subdatastat-ulpktfwd-qci69
collapsed-subdatastat-ulpktfwd-qci70
collapsed-subdatastat-ulbytefwd-qci65
collapsed-subdatastat-ulbytefwd-qci66
collapsed-subdatastat-ulbytefwd-qci69
collapsed-subdatastat-ulbytefwd-qci70
collapsed-subdatastat-dlpktfwd-qci65
collapsed-subdatastat-dlpktfwd-qci66
collapsed-subdatastat-dlpktfwd-qci69
collapsed-subdatastat-dlpktfwd-qci70
collapsed-subdatastat-dlbytefwd-qci65
collapsed-subdatastat-dlbytefwd-qci66
collapsed-subdatastat-dlbytefwd-qci69
collapsed-subdatastat-dlbytefwd-qci70
collapsed-subdatastat-ulpktdrop-qci65
collapsed-subdatastat-ulpktdrop-qci66
collapsed-subdatastat-ulpktdrop-qci69
collapsed-subdatastat-ulpktdrop-qci70
collapsed-subdatastat-ulbytedrop-qci65
collapsed-subdatastat-ulbytedrop-qci66
collapsed-subdatastat-ulbytedrop-qci69
collapsed-subdatastat-ulbytedrop-qci70
collapsed-subdatastat-dlpktdrop-qci65
collapsed-subdatastat-dlpktdrop-qci66
collapsed-subdatastat-dlpktdrop-qci69
collapsed-subdatastat-dlpktdrop-qci70
collapsed-subdatastat-dlbytedrop-qci65
collapsed-subdatastat-dlbytedrop-qci66
collapsed-subdatastat-dlbytedrop-qci69
collapsed-subdatastat-dlbytedrop-qci70
collapsed-subqosstat-bearact-qci65
collapsed-subqosstat-bearact-qci66
collapsed-subqosstat-bearact-qci69
collapsed-subqosstat-bearact-qci70
collapsed-subqosstat-bearset-qci65
collapsed-subqosstat-bearset-qci66
collapsed-subqosstat-bearset-qci69
collapsed-subqosstat-bearset-qci70
collapsed-subqosstat-bearrel-qci65
collapsed-subqosstat-bearrel-qci66
collapsed-subqosstat-bearrel-qci69
collapsed-subqosstat-bearrel-qci70
saegw-ggsn-subqosstat-bearact-qci65
saegw-ggsn-subqosstat-bearact-qci66
saegw-ggsn-subqosstat-bearact-qci69
saegw-ggsn-subqosstat-bearact-qci70
saegw-ggsn-subqosstat-bearset-qci65
saegw-ggsn-subqosstat-bearset-qci66
saegw-ggsn-subqosstat-bearset-qci69
saegw-ggsn-subqosstat-bearset-qci70
saegw-ggsn-subqosstat-bearrel-qci65
saegw-ggsn-subqosstat-bearrel-qci66
saegw-ggsn-subqosstat-bearrel-qci69
saegw-ggsn-subqosstat-bearrel-qci70
saegw-ggsn-subdatastat-ulpktfwd-qci65
saegw-ggsn-subdatastat-ulpktfwd-qci66
saegw-ggsn-subdatastat-ulpktfwd-qci69
saegw-ggsn-subdatastat-ulpktfwd-qci70
saegw-ggsn-subdatastat-ulbytefwd-qci65
saegw-ggsn-subdatastat-ulbytefwd-qci66
saegw-ggsn-subdatastat-ulbytefwd-qci69
saegw-ggsn-subdatastat-ulbytefwd-qci70
saegw-ggsn-subdatastat-dlpktfwd-qci65
saegw-ggsn-subdatastat-dlpktfwd-qci66
saegw-ggsn-subdatastat-dlpktfwd-qci69
saegw-ggsn-subdatastat-dlpktfwd-qci70
saegw-ggsn-subdatastat-dlbytefwd-qci65
saegw-ggsn-subdatastat-dlbytefwd-qci66
saegw-ggsn-subdatastat-dlbytefwd-qci69
saegw-ggsn-subdatastat-dlbytefwd-qci70
saegw-ggsn-subdatastat-ulpktdrop-qci65
saegw-ggsn-subdatastat-ulpktdrop-qci66
saegw-ggsn-subdatastat-ulpktdrop-qci69
saegw-ggsn-subdatastat-ulpktdrop-qci70
saegw-ggsn-subdatastat-ulbytedrop-qci65
saegw-ggsn-subdatastat-ulbytedrop-qci66
saegw-ggsn-subdatastat-ulbytedrop-qci69
saegw-ggsn-subdatastat-ulbytedrop-qci70
saegw-ggsn-subdatastat-dlpktdrop-qci65
saegw-ggsn-subdatastat-dlpktdrop-qci66
saegw-ggsn-subdatastat-dlpktdrop-qci69
saegw-ggsn-subdatastat-dlpktdrop-qci70
saegw-ggsn-subdatastat-dlbytedrop-qci65
saegw-ggsn-subdatastat-dlbytedrop-qci66
saegw-ggsn-subdatastat-dlbytedrop-qci69
saegw-ggsn-subdatastat-dlbytedrop-qci70
saegw-ggsn-subdatastat-ulpktdropmbrexc-qci65
saegw-ggsn-subdatastat-ulpktdropmbrexc-qci66
saegw-ggsn-subdatastat-ulpktdropmbrexc-qci69
saegw-ggsn-subdatastat-ulpktdropmbrexc-qci70
saegw-ggsn-subdatastat-ulbytedropmbrexc-qci65
saegw-ggsn-subdatastat-ulbytedropmbrexc-qci66
saegw-ggsn-subdatastat-ulbytedropmbrexc-qci69
saegw-ggsn-subdatastat-ulbytedropmbrexc-qci70
saegw-ggsn-subdatastat-dlpktdropmbrexc-qci65
saegw-ggsn-subdatastat-dlpktdropmbrexc-qci66
saegw-ggsn-subdatastat-dlpktdropmbrexc-qci69
saegw-ggsn-subdatastat-dlpktdropmbrexc-qci70
saegw-ggsn-subdatastat-dlbytedropmbrexc-qci65
saegw-ggsn-subdatastat-dlbytedropmbrexc-qci66
saegw-ggsn-subdatastat-dlbytedropmbrexc-qci69
saegw-ggsn-subdatastat-dlbytedropmbrexc-qci70
S-GW Schema
The following bulk statistics have been added to the S-GW schema to support the New Standard QCIs feature.
totepsbearactive-qci65
totepsbearactive-qci66
totepsbearactive-qci69
totepsbearactive-qci70
totepsbearsetup-qci65
totepsbearsetup-qci66
totepsbearsetup-qci69
totepsbearsetup-qci70
totepsbearrel-qci65
totepsbearrel-qci66
totepsbearrel-qci69
totepsbearrel-qci70
totepsbearmod-qci65
totepsbearmod-qci66
totepsbearmod-qci69
totepsbearmod-qci70
totepsbearrel-dedrsn-pgw-qci65
totepsbearrel-dedrsn-pgw-qci66
totepsbearrel-dedrsn-pgw-qci69
totepsbearrel-dedrsn-pgw-qci70
totepsbearrel-dedrsn-s1err-qci65
totepsbearrel-dedrsn-s1err-qci66
totepsbearrel-dedrsn-s1err-qci69
totepsbearrel-dedrsn-s1err-qci70
totepsbearrel-dedrsn-s5err-qci65
totepsbearrel-dedrsn-s5err-qci66
totepsbearrel-dedrsn-s5err-qci69
totepsbearrel-dedrsn-s5err-qci70
totepsbearrel-dedrsn-s4err-qci65
totepsbearrel-dedrsn-s4err-qci66
totepsbearrel-dedrsn-s4err-qci69
totepsbearrel-dedrsn-s4err-qci70
totepsbearrel-dedrsn-s12err-qci65
totepsbearrel-dedrsn-s12err-qci66
totepsbearrel-dedrsn-s12err-qci69
totepsbearrel-dedrsn-s12err-qci70
totepsbearrel-dedrsn-local-qci65
totepsbearrel-dedrsn-local-qci66
totepsbearrel-dedrsn-local-qci69
totepsbearrel-dedrsn-local-qci70
totepsbearrel-dedrsn-pdn-qci65
totepsbearrel-dedrsn-pdn-qci66
totepsbearrel-dedrsn-pdn-qci69
totepsbearrel-dedrsn-pdn-qci70
totepsbearrel-dedrsn-pathfail-s1-u-qci65
totepsbearrel-dedrsn-pathfail-s1-u-qci66
totepsbearrel-dedrsn-pathfail-s1-u-qci69
totepsbearrel-dedrsn-pathfail-s1-u-qci70
totepsbearrel-dedrsn-pathfail-s5-u-qci65
totepsbearrel-dedrsn-pathfail-s5-u-qci66
totepsbearrel-dedrsn-pathfail-s5-u-qci69
totepsbearrel-dedrsn-pathfail-s5-u-qci70
totepsbearrel-dedrsn-pathfail-s5-qci65
totepsbearrel-dedrsn-pathfail-s5-qci66
totepsbearrel-dedrsn-pathfail-s5-qci69
totepsbearrel-dedrsn-pathfail-s5-qci70
totepsbearrel-dedrsn-pathfail-s11-qci65
totepsbearrel-dedrsn-pathfail-s11-qci66
totepsbearrel-dedrsn-pathfail-s11-qci69
totepsbearrel-dedrsn-pathfail-s11-qci70
totepsbearrel-dedrsn-pathfail-s12-qci65
totepsbearrel-dedrsn-pathfail-s12-qci66
totepsbearrel-dedrsn-pathfail-s12-qci69
totepsbearrel-dedrsn-pathfail-s12-qci70
totepsbearrel-dedrsn-pathfail-s4-u-qci65
totepsbearrel-dedrsn-pathfail-s4-u-qci66
totepsbearrel-dedrsn-pathfail-s4-u-qci69
totepsbearrel-dedrsn-pathfail-s4-u-qci70
totepsbearrel-dedrsn-inactivity-timeout-qci65
totepsbearrel-dedrsn-inactivity-timeout-qci66
totepsbearrel-dedrsn-inactivity-timeout-qci69
totepsbearrel-dedrsn-inactivity-timeout-qci70
totepsbearrel-dedrsn-other-qci65
totepsbearrel-dedrsn-other-qci66
totepsbearrel-dedrsn-other-qci69
totepsbearrel-dedrsn-other-qci70
datastat-uplink-qci65totbyte
datastat-uplink-qci65totpkt
datastat-uplink-qci66totbyte
datastat-uplink-qci66totpkt
datastat-uplink-qci69totbyte
datastat-uplink-qci69totpkt
datastat-uplink-qci70totbyte
datastat-uplink-qci70totpkt
datastat-uplink-dropstat-qci65totbyte
datastat-uplink-dropstat-qci65totpkt
datastat-uplink-dropstat-qci66totbyte
datastat-uplink-dropstat-qci66totpkt
datastat-uplink-dropstat-qci69totbyte
datastat-uplink-dropstat-qci69totpkt
datastat-uplink-dropstat-qci70totbyte
datastat-uplink-dropstat-qci70totpkt
datastat-downlink-qci65totbyte
datastat-downlink-qci65totpkt
datastat-downlink-qci66totbyte
datastat-downlink-qci66totpkt
datastat-downlink-qci69totbyte
datastat-downlink-qci69totpkt
datastat-downlink-qci70totbyte
datastat-downlink-qci70totpkt
datastat-downlink-dropstat-qci65totbyte
datastat-downlink-dropstat-qci65totpkt
datastat-downlink-dropstat-qci66totbyte
datastat-downlink-dropstat-qci66totpkt
datastat-downlink-dropstat-qci69totbyte
datastat-downlink-dropstat-qci69totpkt
datastat-downlink-dropstat-qci70totbyte
datastat-downlink-dropstat-qci70totpkt
s1u-uplnk-qci65totbyte
s1u-uplnk-qci65totpkt
s1u-uplnk-qci66totbyte
s1u-uplnk-qci66totpkt
s1u-uplnk-qci69totbyte
s1u-uplnk-qci69totpkt
s1u-uplnk-qci70totbyte
s1u-uplnk-qci70totpkt
s1u-uplnk-drop-qci65totbyte
s1u-uplnk-drop-qci65totpkt
s1u-uplnk-drop-qci66totbyte
s1u-uplnk-drop-qci66totpkt
s1u-uplnk-drop-qci69totbyte
s1u-uplnk-drop-qci69totpkt
s1u-uplnk-drop-qci70totbyte
s1u-uplnk-drop-qci70totpkt
s1u-downlnk-qci65totbyte
s1u-downlnk-qci65totpkt
s1u-downlnk-qci66totbyte
s1u-downlnk-qci66totpkt
s1u-downlnk-qci69totbyte
s1u-downlnk-qci69totpkt
s1u-downlnk-qci70totbyte
s1u-downlnk-qci70totpkt
s1u-downlnk-drop-qci65totbyte
s1u-downlnk-drop-qci65totpkt
s1u-downlnk-drop-qci66totbyte
s1u-downlnk-drop-qci66totpkt
s1u-downlnk-drop-qci69totbyte
s1u-downlnk-drop-qci69totpkt
s1u-downlnk-drop-qci70totbyte
s1u-downlnk-drop-qci70totpkt
s4u-uplnk-qci65totbyte
s4u-uplnk-qci65totpkt
s4u-uplnk-qci66totbyte
s4u-uplnk-qci66totpkt
s4u-uplnk-qci69totbyte
s4u-uplnk-qci69totpkt
s4u-uplnk-qci70totbyte
s4u-uplnk-qci70totpkt
s4u-uplnk-drop-qci65totbyte
s4u-uplnk-drop-qci65totpkt
s4u-uplnk-drop-qci66totbyte
s4u-uplnk-drop-qci66totpkt
s4u-uplnk-drop-qci69totbyte
s4u-uplnk-drop-qci69totpkt
s4u-uplnk-drop-qci70totbyte
s4u-uplnk-drop-qci70totpkt
s4u-downlnk-qci65totbyte
s4u-downlnk-qci65totpkt
s4u-downlnk-qci66totbyte
s4u-downlnk-qci66totpkt
s4u-downlnk-qci69totbyte
s4u-downlnk-qci69totpkt
s4u-downlnk-qci70totbyte
s4u-downlnk-qci70totpkt
s4u-downlnk-drop-qci65totbyte
s4u-downlnk-drop-qci65totpkt
s4u-downlnk-drop-qci66totbyte
s4u-downlnk-drop-qci66totpkt
s4u-downlnk-drop-qci69totbyte
s4u-downlnk-drop-qci69totpkt
s4u-downlnk-drop-qci70totbyte
s4u-downlnk-drop-qci70totpkt
s12-uplnk-qci65totbyte
s12-uplnk-qci65totpkt
s12-uplnk-qci66totbyte
s12-uplnk-qci66totpkt
s12-uplnk-qci69totbyte
s12-uplnk-qci69totpkt
s12-uplnk-qci70totbyte
s12-uplnk-qci70totpkt
s12-uplnk-drop-qci65totbyte
s12-uplnk-drop-qci65totpkt
s12-uplnk-drop-qci66totbyte
s12-uplnk-drop-qci66totpkt
s12-uplnk-drop-qci69totbyte
s12-uplnk-drop-qci69totpkt
s12-uplnk-drop-qci70totbyte
s12-uplnk-drop-qci70totpkt
s12-downlnk-qci65totbyte
s12-downlnk-qci65totpkt
s12-downlnk-qci66totbyte
s12-downlnk-qci66totpkt
s12-downlnk-qci69totbyte
s12-downlnk-qci69totpkt
s12-downlnk-qci70totbyte
s12-downlnk-qci70totpkt
s12-downlnk-drop-qci65totbyte
s12-downlnk-drop-qci65totpkt
s12-downlnk-drop-qci66totbyte
s12-downlnk-drop-qci66totpkt
s12-downlnk-drop-qci69totbyte
s12-downlnk-drop-qci69totpkt
s12-downlnk-drop-qci70totbyte
s12-downlnk-drop-qci70totpkt
s5-uplnk-qci65totbyte
s5-uplnk-qci65totpkt
s5-uplnk-qci66totbyte
s5-uplnk-qci66totpkt
s5-uplnk-qci69totbyte
s5-uplnk-qci69totpkt
s5-uplnk-qci70totbyte
s5-uplnk-qci70totpkt
s5-uplnk-drop-qci65totbyte
s5-uplnk-drop-qci65totpkt
s5-uplnk-drop-qci66totbyte
s5-uplnk-drop-qci66totpkt
s5-uplnk-drop-qci69totbyte
s5-uplnk-drop-qci69totpkt
s5-uplnk-drop-qci70totbyte
s5-uplnk-drop-qci70totpkt
s5-downlnk-qci65totbyte
s5-downlnk-qci65totpkt
s5-downlnk-qci66totbyte
s5-downlnk-qci66totpkt
s5-downlnk-qci69totbyte
s5-downlnk-qci69totpkt
s5-downlnk-qci70totbyte
s5-downlnk-qci70totpkt
s5-downlnk-drop-qci65totbyte
s5-downlnk-drop-qci65totpkt
s5-downlnk-drop-qci66totbyte
s5-downlnk-drop-qci66totpkt
s5-downlnk-drop-qci69totbyte
s5-downlnk-drop-qci69totpkt
s5-downlnk-drop-qci70totbyte
s5-downlnk-drop-qci70totpkt
s8-uplnk-qci65totbyte
s8-uplnk-qci65totpkt
s8-uplnk-qci66totbyte
s8-uplnk-qci66totpkt
s8-uplnk-qci69totbyte
s8-uplnk-qci69totpkt
s8-uplnk-qci70totbyte
s8-uplnk-qci70totpkt
s8-uplnk-drop-qci65totbyte
s8-uplnk-drop-qci65totpkt
s8-uplnk-drop-qci66totbyte
s8-uplnk-drop-qci66totpkt
s8-uplnk-drop-qci69totbyte
s8-uplnk-drop-qci69totpkt
s8-uplnk-drop-qci70totbyte
s8-uplnk-drop-qci70totpkt
s8-downlnk-qci65totbyte
s8-downlnk-qci65totpkt
s8-downlnk-qci66totbyte
s8-downlnk-qci66totpkt
s8-downlnk-qci69totbyte
s8-downlnk-qci69totpkt
s8-downlnk-qci70totbyte
s8-downlnk-qci70totpkt
s8-downlnk-drop-qci65totbyte
s8-downlnk-drop-qci65totpkt
s8-downlnk-drop-qci66totbyte
s8-downlnk-drop-qci66totpkt
s8-downlnk-drop-qci69totbyte
s8-downlnk-drop-qci69totpkt
s8-downlnk-drop-qci70totbyte
s8-downlnk-drop-qci70totpkt
s5s8-uplnk-qci65totbyte
s5s8-uplnk-qci65totpkt
s5s8-uplnk-qci66totbyte
s5s8-uplnk-qci66totpkt
s5s8-uplnk-qci69totbyte
s5s8-uplnk-qci69totpkt
s5s8-uplnk-qci70totbyte
s5s8-uplnk-qci70totpkt
s5s8-uplnk-drop-qci65totbyte
s5s8-uplnk-drop-qci65totpkt
s5s8-uplnk-drop-qci66totbyte
s5s8-uplnk-drop-qci66totpkt
s5s8-uplnk-drop-qci69totbyte
s5s8-uplnk-drop-qci69totpkt
s5s8-uplnk-drop-qci70totbyte
s5s8-uplnk-drop-qci70totpkt
s5s8-downlnk-qci65totbyte
s5s8-downlnk-qci65totpkt
s5s8-downlnk-qci66totbyte
s5s8-downlnk-qci66totpkt
s5s8-downlnk-qci69totbyte
s5s8-downlnk-qci69totpkt
s5s8-downlnk-qci70totbyte
s5s8-downlnk-qci70totpkt
s5s8-downlnk-drop-qci65totbyte
s5s8-downlnk-drop-qci65totpkt
s5s8-downlnk-drop-qci66totbyte
s5s8-downlnk-drop-qci66totpkt
s5s8-downlnk-drop-qci69totbyte
s5s8-downlnk-drop-qci69totpkt
s5s8-downlnk-drop-qci70totbyte
s5s8-downlnk-drop-qci70totpkt
System Schema
The following bulk statistics have been added to the System Schema to support the New Standard QCIs
feature.
sess-bearerdur-5sec-qci65
sess-bearerdur-10sec-qci65
sess-bearerdur-30sec-qci65
sess-bearerdur-1min-qci65
sess-bearerdur-2min-qci65
sess-bearerdur-5min-qci65
sess-bearerdur-15min-qci65
sess-bearerdur-30min-qci65
sess-bearerdur-1hr-qci65
sess-bearerdur-4hr-qci65
sess-bearerdur-12hr-qci65
sess-bearerdur-24hr-qci65
sess-bearerdur-over24hr-qci65
sess-bearerdur-2day-qci65
sess-bearerdur-4day-qci65
sess-bearerdur-5day-qci65
sess-bearerdur-5sec-qci66
sess-bearerdur-10sec-qci66
sess-bearerdur-30sec-qci66
sess-bearerdur-1min-qci66
sess-bearerdur-2min-qci66
sess-bearerdur-5min-qci66
sess-bearerdur-15min-qci66
sess-bearerdur-30min-qci66
sess-bearerdur-1hr-qci66
sess-bearerdur-4hr-qci66
sess-bearerdur-12hr-qci66
sess-bearerdur-24hr-qci66
sess-bearerdur-over24hr-qci66
sess-bearerdur-2day-qci66
sess-bearerdur-4day-qci66
sess-bearerdur-5day-qci66
sess-bearerdur-5sec-qci69
sess-bearerdur-10sec-qci69
sess-bearerdur-30sec-qci69
sess-bearerdur-1min-qci69
sess-bearerdur-2min-qci69
sess-bearerdur-5min-qci69
sess-bearerdur-15min-qci69
sess-bearerdur-30min-qci69
sess-bearerdur-1hr-qci69
sess-bearerdur-4hr-qci69
sess-bearerdur-12hr-qci69
sess-bearerdur-24hr-qci69
sess-bearerdur-over24hr-qci69
sess-bearerdur-2day-qci69
sess-bearerdur-4day-qci69
sess-bearerdur-5day-qci69
sess-bearerdur-5sec-qci70
sess-bearerdur-10sec-qci70
sess-bearerdur-30sec-qci70
sess-bearerdur-1min-qci70
sess-bearerdur-2min-qci70
sess-bearerdur-5min-qci70
sess-bearerdur-15min-qci70
sess-bearerdur-30min-qci70
sess-bearerdur-1hr-qci70
sess-bearerdur-4hr-qci70
sess-bearerdur-12hr-qci70
sess-bearerdur-24hr-qci70
sess-bearerdur-over24hr-qci70
sess-bearerdur-2day-qci70
sess-bearerdur-4day-qci70
sess-bearerdur-5day-qci70
Show Commands
This section describes the show commands available to monitor the New Standard QCIs feature.
QCI 65:
Bearer Active: 0 Bearer setup: 0
Bearer Released: 0 Bearer Rejected: 0
QCI 66:
Bearer Active: 0 Bearer setup: 0
Bearer Released: 0 Bearer Rejected: 0
QCI 69:
Bearer Active: 0 Bearer setup: 0
Bearer Released: 0 Bearer Rejected: 0
QCI 70:
Bearer Active: 0 Bearer setup: 0
Bearer Released: 0 Bearer Rejected: 0
...
QCI 9:
Uplink Packets: 0 Uplink Bytes: 0
Downlink Packets: 0 Downlink Bytes: 0
Packets Discarded: 0 Bytes Discarded: 0
QCI 65:
Uplink Packets: 0 Uplink Bytes: 0
Downlink Packets: 0 Downlink Bytes: 0
Packets Discarded: 0 Bytes Discarded: 0
QCI 66:
Uplink Packets: 0 Uplink Bytes: 0
Downlink Packets: 0 Downlink Bytes: 0
Packets Discarded: 0 Bytes Discarded: 0
QCI 69:
Uplink Packets: 0 Uplink Bytes: 0
Downlink Packets: 0 Downlink Bytes: 0
Packets Discarded: 0 Bytes Discarded: 0
QCI 70:
Uplink Packets: 0 Uplink Bytes: 0
Downlink Packets: 0 Downlink Bytes: 0
Packets Discarded: 0 Bytes Discarded: 0
Non-Std QCI(Non-GBR):
Uplink Packets: 0 Uplink Bytes: 0
Downlink Packets: 0 Downlink Bytes: 0
Packets Discarded: 0 Bytes Discarded: 0
...
Released:
QCI 1: 0
...
QCI 65: 0
QCI 66: 0
QCI 69: 0
QCI 70: 0
...
…
Std QCI(Non-GBR): 0 Std QCI(Non-GBR): 0
Std QCI(GBR): 0 Std QCI(GBR): 0
Uplink : Downlink :
Packets: Packets:
QCI 1: 0 QCI 1: 0
...
QCI 65: 0 QCI 65: 0
QCI 66: 0 QCI 66: 0
QCI 69: 0 QCI 69: 0
QCI 70: 0 QCI 70: 0
Non-Std QCI: 0 Non-Std QCI: 0
Bytes: Bytes:
QCI 1: 0 QCI 1: 0
...
QCI 65: 0 QCI 65: 0
QCI 66: 0 QCI 66: 0
QCI 69: 0 QCI 69: 0
QCI 70: 0 QCI 70: 0
Non-Std QCI: 0 Non-Std QCI: 0
Released: Modified:
QCI 1: 0 QCI 1: 0
...
QCI 65: 0 QCI 65: 0
QCI 66: 0 QCI 66: 0
QCI 69: 0 QCI 69: 0
QCI 70: 0 QCI 70: 0
...
...
Data Statistics Per Interface:
S1-U Total Data Statistics:
Uplink : Downlink :
...
Packets: Packets:
QCI 1: 0 QCI 1: 0
...
QCI 65: 0 QCI 65: 0
QCI 66: 0 QCI 66: 0
QCI 69: 0 QCI 69: 0
QCI 70: 0 QCI 70: 0
Non-Std QCI: 0 Non-Std QCI: 0
Bytes: Bytes:
QCI 1: 0 QCI 1: 0
...
QCI 65: 0 QCI 65: 0
QCI 66: 0 QCI 66: 0
QCI 69: 0 QCI 69: 0
QCI 70: 0 QCI 70: 0
Non-Std QCI: 0 Non-Std QCI: 0
Uplink : Downlink :
Total Pkts: 0 Total Pkts: 0
Total Bytes: 0 Total Bytes: 0
Dropped Pkts: 0 Dropped Pkts: 0
Dropped Bytes: 0 Dropped Bytes: 0
Packets: Packets:
QCI 1: 0 QCI 1: 0
...
QCI 65: 0 QCI 65: 0
QCI 66: 0 QCI 66: 0
QCI 69: 0 QCI 69: 0
QCI 70: 0 QCI 70: 0
Non-Std QCI: 0 Non-Std QCI: 0
Bytes: Bytes:
QCI 1: 0 QCI 1: 0
...
QCI 65: 0 QCI 65: 0
QCI 66: 0 QCI 66: 0
QCI 69: 0 QCI 69: 0
QCI 70: 0 QCI 70: 0
Non-Std QCI: 0 Non-Std QCI: 0
Packets: Packets:
QCI 1: 0 QCI 1: 0
...
QCI 65: 0 QCI 65: 0
QCI 66: 0 QCI 66: 0
QCI 69: 0 QCI 69: 0
QCI 70: 0 QCI 70: 0
Non-Std QCI: 0 Non-Std QCI: 0
Bytes: Bytes:
QCI 1: 0 QCI 1: 0
...
QCI 65: 0 QCI 65: 0
QCI 66: 0 QCI 66: 0
QCI 69: 0 QCI 69: 0
QCI 70: 0 QCI 70: 0
Non-Std QCI: 0 Non-Std QCI: 0
Packets: Packets:
QCI 1: 0 QCI 1: 0
...
QCI 65: 0 QCI 65: 0
QCI 66: 0 QCI 66: 0
QCI 69: 0 QCI 69: 0
QCI 70: 0 QCI 70: 0
Non-Std QCI: 0 Non-Std QCI: 0
Bytes: Bytes:
QCI 1: 0 QCI 1: 0
...
QCI 65: 0 QCI 65: 0
QCI 66: 0 QCI 66: 0
QCI 69: 0 QCI 69: 0
QCI 70: 0 QCI 70: 0
Non-Std QCI: 0 Non-Std QCI: 0
Packets: Packets:
QCI 1: 0 QCI 1: 0
...
QCI 65: 0 QCI 65: 0
QCI 66: 0 QCI 66: 0
QCI 69: 0 QCI 69: 0
QCI 70: 0 QCI 70: 0
Non-Std QCI: 0 Non-Std QCI: 0
Bytes: Bytes:
QCI 1: 0 QCI 1: 0
...
QCI 65: 0 QCI 65: 0
QCI 66: 0 QCI 66: 0
QCI 69: 0 QCI 69: 0
QCI 70: 0 QCI 70: 0
Non-Std QCI: 0 Non-Std QCI: 0
Feature Description
Usually, only standards-based QCI values of 1 through 9 are supported on GGSN/P-GW/SAEGW/S-GW/ePDG.
A license, however, allows non-standard QCIs (128-254) to be used on P-GW/GGSN (not standalone GGSN).
Licensing
Use of non-standard QCIs require that a valid license key be installed. Contact your Cisco Account or Support
representative for information on how to obtain a license.
How It Works
From 3GPP Release 8 onwards, operator-specific/non-standard QCIs can be supported and carriers can define
QCI 128-254. QCI values 0 and 10 to 255 are defined as follows:
• 0: Reserved
• 10-127: Reserved
• 128-254: Operator-specific/Non-standard QCI
• 255: Reserved
Unique operator-specific QCIs (128-254) can be used to differentiate between various services/applications
carriers provide to the end users in their network.
Limitations
• Non-standard QCIs can only be supported with S5/S8/S2a/S2b interfaces.
• The Gn interface is not supported.
Standards Compliance
• 3GPP Specification TS 23.203: Policy and charging control architecture
• 3GPP Specification TS 29.212: Policy and Charging Control over Gx reference point
If the pre-rel8-qos-mapping field is not configured for the non-standard QCI under P-GW which is
associated with a GGSN, then the 3G call would be rejected.
GnGp Handoff
1 If the pre-rel8-qos-mapping field is not configured for the non-standard QCI for default bearer,
then the handoff would be rejected.
2 If the pre-rel8-qos-mapping field is not configured for the non-standard QCI for dedicated bearer,
then only that bearer would be rejected during handoff.
3 In the following scenario:
• default bearer with standard QCI or non-standard QCI (with pre-rel8-qos-mapping configured)
• more than one dedicated bearer (some with standard QCI, some with non-standard QCI with
pre-rel8-qos-mapping configured, and some with non-standard QCI with no mapping)
Bulk Statistics
This section provides information regarding bulk statistics in support of non-standard QCI support.
APN Schema
The following counters have been added in support of non-standard QCIs (GBR and Non-GBR):
• nonstdqci-nongbr-uplinkpkt-drop-mbrexcd
• nonstdqci-nongbr-dwlinkpkt-drop-mbrexcd
• nonstdqci-nongbr-uplinkbyte-drop-mbrexcd
• nonstdqci-nongbr-dwlinkbyte-drop-mbrexcd
• nonstdqci-nongbr-rejbearer
• nonstdqci-gbr-uplinkpkt-drop-mbrexcd
• nonstdqci-gbr-dwlinkpkt-drop-mbrexcd
• nonstdqci-gbr-uplinkbyte-drop-mbrexcd
• nonstdqci-gbr-dwlinkbyte-drop-mbrexcd
• nonstdqci-gbr-rejbearer
• Non-Std QCI(GBR)
• Bearer Rejected
• Uplink Bytes dropped(MBR Excd)
• Downlink Bytes dropped(MBR Excd)
• Uplink pkts dropped(MBR Excd)
• Downlink pkts dropped(MBR Excd)
Feature Description
In StarOS 14.0 and earlier, during collision between SGSN initiated UPC request and GGSN Initiated UPC
request, pre-defined rules were activated at GGSN without waiting for network requested UPC (NRUPC)
response and there were no packet drops.
From StarOS release 15.0 onward, predefined rules were activated only on receiving NRUPC response at
GGSN and not in case of collision. This resulted in packet drops.
In StarOS 20.0, the GGSN UPC Collision Handling feature addresses the problem of packet drops. During
collision between SGSN initiated UPC request and GGSN initiated UPC Request, SGSN initiated UPC request
gets higher priority over NRUPC and there is no call or data loss during call establishment or during mid-call
phase. This feature can be enabled or disabled using a CLI and is enabled by default.
How It Works
In StarOS release 14.0 and earlier:
• Predefined rules were activated at GGSN without waiting for network requested UPC (NRUPC) response.
• SGSN initiated UPCReq was received at GGSN before NRUPC response (collision).
• SGSN initiated UPCReq aborted the NRUPC.
• Session manager (SM) did not send failure message to ECS.
• However, the predefined rules were already activated at GGSN (without waiting for NRUPC response).
Hence, there were no packet drops.
From StarOS release 15.0 onward, predefined rules were activated only on receiving NRUPC response at
GGSN and were not activated in case of collision. There was no static catch-all rule defined in rulebase. This
caused packet drops.
In StarOS 20.0, the GGSN UPC Collision Handling feature addresses the problem of packet drops. During
collision between SGSN initiated UPC request and GGSN initiated UPC Request, SGSN initiated UPC request
gets higher priority over NRUPC and there is no call or data loss during call establishment or during mid-call
phase. This feature can be enabled or disabled using a CLI and is enabled by default.
• When GGSN detects collision between SGSN initiated UPC request and NRUPC on primary PDP
context, NRUPC is retried (with different sequence number) after sending UPC Response.
• When GGSN detects collision between SGSN initiated UPC request for Inter-SGSN handoff and NRUPC
with TFT and after handoff BCM mode is changed from Mixed mode to MS-Only mode, NRUPC is
retried (with different sequence number) after sending UPC Response, but without TFT.
• When GGSN detects collision between an SGSN initiated UPC and a NRUPC on secondary PDP context,
NRUPC is aborted and PCRF is notified. When multiple CCR-U support is not enabled on GGSN,
CCR-U for aborted NRUPC (on secondary PDP context) is not informed to PCRF. In this case, PCRF
will not be aware of this aborted transaction (rule failure).
Limitations
• Behavior for GnGp GGSN has been modified for this feature, in this release. Behavior for GGSN remains
unaltered.
• When NRUPC received from Direct Tunnel (due to "Direct Tunnel Error Indication") collides with
SGSN initiated UPC request, NRUPC is aborted and not retried. This does not affect the functionality
as, when "Direct Tunnel Error Indication" is received from access side, NRUPC is triggered again.
• When a request for handoff to LTE is received before receiving NRUPC response, the behavior remains
unchanged. In this case, the pending NRUPC request is aborted. If the NRUPC request received is for
rule installation, the request remains in the pending state and the rule is not installed. As there is no static
rule and the rule installation request is in pending state, the PDP context stays up without an installed
rule.
gtpc handle-collision
This command in the service configuration mode can be used to the collision between SGSN initiated UPC
request and network initiated UPC Request.
GGSN Service
configure
context context_name
ggsn-service service_name
• show configuration
• show configuration verbose
Please see the Monitoring and Troubleshooting GGSN UPC Collision Handling section for the command
output.
show configuration
This command displays the following output:
ggsn-service ggsn-service
associate gtpu-service gtpu-service
associate pgw-service pgw_service
associate peer-map map_ggsn
ggsn-service ggsn-service
associate gtpu-service gtpu-service
associate pgw-service pgw_service
associate peer-map map_ggsn
QoS negotiation:
CPC QoS Accepted: 3 CPC QoS Downgraded: 0
QoS negotiation:
CPC QoS Accepted: 3 CPC QoS Downgraded: 0
UPC QoS Accepted: 3 UPC QoS Downgraded: 0
Feature Description
This section describes the 3GPP R12 GTP-C Load and Overload Control feature.
Important Use of the 3GPP R12 Load and Overload Control feature requires that a valid license key be installed.
Contact your Cisco account or support representative for information on how to obtain a license.
The 3GPP R12 GTP-C Load and Overload Control feature is a licensed, optional feature which allows a GTP
control plane node to send its load information to a peer GTP control plane node which the receiving GTP
control plane peer node uses to augment existing GW selection procedure for the P-GW and S-GW. Load
information reflects the operating status of the resources of the originating GTP control plane node.
Nodes using GTP control plane signaling may support communication of overload control information in
order to mitigate overload situations for the overloaded node through actions taken by the peer node(s). This
feature is supported over the S4, S11, S5 and S8 interfaces via the GTPv2 control plane protocol.
A GTP-C node is considered to be in overload when it is operating over its nominal capacity resulting in
diminished performance (including impacts to handling of incoming and outgoing traffic). Overload control
information reflects an indication of when the originating node has reached such a situation. This information,
when transmitted between GTP-C nodes, may be used to reduce and/or throttle the amount of GTP-C signaling
traffic between these nodes. As such, the overload control information provides guidance to the receiving
node to decide upon the correct actions, which leads to mitigation towards the sender of the information.
To summarize, load control and overload control can be described in this manner:
• Load Control: Load control enables a GTP-C entity (for example, an P-GW/SAEGW/S-GW) to send
its load information to a GTP-C peer (for example, an MME/SGSN, ePDG, TWAN) to adaptively
balance the session load across entities supporting the same function (for example, an S-GW cluster)
according to their effective load. The load information reflects the operating status of the resources of
the GTP-C entity.
• Overload Control: Overload control enables a GTP-C entity becoming or being overloaded to gracefully
reduce its incoming signaling load by instructing its GTP-C peers to reduce sending traffic according
to its available signaling capacity to successfully process the traffic. A GTP-C entity is in overload when
it operates over its signaling capacity, which results in diminished performance (including impacts to
handling of incoming and outgoing traffic).
• Once configured, the GTP-C Load and Overload Control profiles must be associated with a P-GW,
SAEGW, or S-GW service to function properly in the network.
How It Works
The node periodically fetches various parameters (for example, License-Session-Utilization,
System-CPU-Utilization, and System-Memory-Utilization), which are required for Node level load control
information. The node then calculates the load/overload control information itself either based on the weighted
factor provided by the user or using the default weighted factor.
Node level load control information is calculated every 30 seconds. The resource manager calculates the
system-CPU-utilization and System-Memory-Utilization at a systems level.
For each configured service, load control information can be different. This can be achieved by providing a
weightage to the number of active session counts per service license, for example, [(number of active sessions
per service / max session allowed for the service license) * 100].
The node's resource manager calculates the system-CPU-utilization and System-Memory-Utilization at a
systems level by averaging CPU and Memory usage for all cards and which might be different from that
calculated at the individual card level.
Configuration Overview
Creating and configuring a 3GPP R12 GTP-C load control profile consists of the following procedures:
Step 1 Create a load control profile. Refer to Creating the GTPP R12 Load Control Profile, on page 248.
Step 2 Configure the load control weightage settings. Refer to Configuring the 3GPP R12 Load Control Profile Weightage
Settings, on page 248.
Step 3 Configure the load control inclusion frequency. Refer to Configuring the 3GPP R12 Load Control Profile Inclusion
Frequency, on page 249.
Step 4 P-GW Only. Configure the load control threshold. Refer to Configuring the 3GPP R12 Load Control Threshold, on
page 249.
Step 5 Configure load control information handling. Refer to Configuring 3GPP R12 Load Control Information Handling, on
page 249.
Step 6 Configure load control information publishing. Refer to Configuring 3GPP R12 Load Control Information Publishing,
on page 250.
Step 7 Configure the 3GPP R12 GTP-C Polling Parameter Interval. Refer to Configuring the 3GPP R12 GTP-C Polling Parameter
Interval, on page 250
Step 8 Associate the load control profile with a P-GW, SAEGW, or S-GW service. Refer to Associating the 3GPP R12 Load
Control Profile with a P-GW, SAEGW, or S-GW Service., on page 251.
Step 9 Verify the configuration settings. Refer to Verifying the 3GPP R12 Load Control Configuration , on page 252.
Step 10 Save the configuration. Refer to Saving the Configuration, on page 252.
Important All parameters must be specified. The total of all three parameter settings should equal, but not exceed,
100.
Use the following example to enable/disable load control profile information handling on the
SAEGW/S-GW/P-GW.
config
gtpc-load-control-profile profile_name
load-control-handling { home | visited }
no load-control-handling { home | visited }
end
Notes:
• no disables load-control-handling for the specified option.
Caution Setting the time interval to a low value may impact system performance.
Associating the 3GPP R12 Load Control Profile with a P-GW, SAEGW, or S-GW
Service.
Once the 3GPP R12 GTP-C load control profile is created, it must be associated with an existing P-GW,
SAEGW, or S-GW service.
Use the following examples to associate the GTP-C load control profile with an existing P-GW, SAEGW, or
S-GW service.
P-GW Service Association:
configure
context context_name
pgw-service pgw_service_name
associate gtpc-load-control-profile profile_name
no associate gtpc-load-control-profile
end
Notes:
• no disables the service association for the GTP-C Load Control Profile.
exit
saegw-service saegw_service_name
associate sgw-service sgw_service_name
associate pgw-service pgw_service_name
exit
Configuration Overview
Step 1 Create the GTP-C overload control profile. Refer to Creating the GTPP R12 Overload Control Profile, on page 253.
Step 2 Configure the weightage settings. Refer to Configuring 3GPP R12 Overload Control Weightage Settings, on page 254.
Step 3 Configure the inclusion frequency. Refer to Configuring the 3GPP R12 Overload Control Inclusion Frequency, on page
254.
Step 4 Configure the validity period. Refer to Configuring the 3GPP R12 Overload Control Validity Period, on page 255.
Step 5 Configure the tolerance settings. Refer to Configuring 3GPP R12 Overload Control Tolerance Limits, on page 255.
Step 6 Configure the throttling behavior for the node. Refer to Configuring 3GPP R12 Overload Control Throttling Behavior,
on page 256.
Step 7 Configure the message prioritization. Refer to Configuring 3GPP R12 Overload Control Message Prioritization, on page
256.
Step 8 Configure self-protection behavior for the node. Refer to Configuring 3GPP R12 Overload Control Self-Protection
Behavior, on page 257.
Step 9 Configure overload control information handling. Refer to Configuring 3GPP R12 Overload Control Information
Handling, on page 258.
Step 10 Configure overload control information publishing. Refer to Configuring 3GPP R12 Overload Control Information
Publishing, on page 258.
Step 11 Configure the GTP-C polling parameter interval . Refer to Configuring the 3GPP R12 GTP-C Polling Parameter Interval,
on page 250.
Step 12 Associate the overload control configuration with an existing P-GW/SAEGW/S-GW service. Refer to Associating the
3GPP R12 Overload Control Configuration with a P-GW, SAEGW, or S-GW Service, on page 259.
Step 13 Verify the overload control configuration. Refer to Verifying the 3GPP R12 Overload Control Configuration , on page
260.
Step 14 Save the configuration. Refer to Saving the 3GPP R12 Overload Control Configuration, on page 260.
to 0, the node will send overload control information in each and every outgoing message to the
peers.interval_in_seconds must be an integer from 0 to 3600. The default is 300.
• change-factor change_factor: P-GW only. Configures the change factor for overload control. If the
overload control factor changes by a configured factor, whether by an increase or decrease, the overload
control information should be sent to the peers. This information is only sent to the peers when the
overload factor changes by the factor configured.change_factor must be an integer from 1 to 20. The
default is 5.
• self-protection-limit percentage: Configures the maximum overload tolerance threshold after which
node will move to self protection mode. When the maximum limit is reached, the node will start rejecting
all incoming messages, except for delete messages. The node will not initiate any new messages to the
peers. This is to mitigate the overload condition.percentage must be an integer from 1 to 100. The default
is 95.
default message-prioritization
end
Notes:
• group1 specifies the message priority percentage for the following messages:
◦Update Bearer Request message for default bearer generated from P-GW ingress
◦Update Bearer Request message for dedicated bearer generated from P-GW ingress
◦Handoff Create Session Request message generated from ePDG egress.
• group2 specifies the message priority percentage for the following messages:
◦Create Bearer Request message for default bearer generated from P-GW ingress
◦PDN connection requested Create Session Request message from ePDG egress
• The total percentage for the message groups should equal 100.
• group1 messages will have the highest priority (1) and are dropped last. group2 messages will have
the lowest priority (2) and are dropped first.
• default returns the group message priority settings to their default value. The default for each group is
50.
• The default behavior for this command is enabled. To disable the command use the no option.
demuxmgr can calculate the load factor based on different system requirements. This command sets the time
period over which to monitor the chassis level CPU, Memory, and Session count information from the resource
manager.
To configure the GTP-C polling parameter interval:
config
context context_name
gtpc-system-param-poll interval seconds
default gtpc-system-param-poll interval
end
• Where seconds is the time period over which to monitor the chassis level CPU, Memory, and Session
count information from the resource manager. Valid entries are from 15 to 300 seconds. The default
setting is 30 seconds.
• default returns the setting to its default value of 30 seconds.
Caution Setting the time interval to a low value may impact system performance.
Associating the 3GPP R12 Overload Control Configuration with a P-GW, SAEGW,
or S-GW Service
Once the 3GPP R12 overload control profile has been configured, it must be associated with an existing P-GW,
SAEGW, or S-GW service.
Use the following examples to associate the overload control configuration to an existing service.
P-GW Service Association:
configure
context context_name
pgw-service pgw_service_name
associate gtpc-overload-control-profile profile_name
no associate gtpc-overload-control-profile
end
Notes:
• no disables the service association for the GTP-C Load Control Profile.
• load-overload-own-lci
• load-overload-own-oci
• load-overload-num-msg-throttled
• load-overload-num-ovrload-cond-reached
For descriptions of these variables, see "eGTP Schema Statistics" in the Statistics and Counters Reference.
Feature Description
This section describes the Intelligent RAT Paging for ISR feature on the S-GW.
When Idle Mode Signaling Reduction (ISR) is active, and a UE is in idle mode with control plane connections
to both the MME and the S4-SGSN, and the S-GW receives downlink data for that UE, it sends
Downlink-Data-Notification-Requests (requests to page UEs) to both the S4-SGSN and MME in parallel.
This scenario causes the following problems:
• Both the MME and S4-SGSN perform paging in parallel, thereby resulting in an overuse of radio
resources. The UE can be camped on either the MME or S4-SGSN, and respond to the paging of either
the MME or S4-SGSN, so the radio resource of one node is not used effectively.
• If the S-GW tries to send DDN messages to both nodes sequentially, there can be a delay in call setup
and establishment.
The Intelligent RAT Paging for ISR feature reduces both the radio resource usage due to paging and the
internal load on the MME/S4-SGSN nodes.
The S-GW intelligently determines when to perform sequential paging as opposed to parallel paging by
identifying the APN and its configuration (in the apn-profile configuration) for the downlink packet for which
paging is originated. This provides the following benefits:
• More efficient utilization of radio resources used for paging when the incoming packet is not delay
sensitive.
• Reduction in the delay of call establishment due to parallel paging when the incoming packet is delay
sensitive.
This feature is useful for ISR enabled Networks to reduce the radio resource usage due to paging.
How it Works
For intelligent paging, the S-GW has to determine whether to perform radio resource optimization or to use
a quick call establishment procedure. The S-GW makes the decision to determine whether to perform sequential
paging or parallel paging based on the configuration of the APN (through apn-profile applied for the APN).
The S-GW finds the APN of the particular bearer, and it checks to see if it received the downlink data. If
isr-sequential-paging is configured for this APN on the S-GW, the S-GW initiates a DDN message to one
node (MME or S4-SGSN) and waits for the service request procedure from that node within a configured
time. If the S-GW does not receive the service request procedure within configured time, it initiates the DDN
message towards the other node.
The node which was last sent the Modify Bearer Request to the S-GW (that is, the last known RAT type) is
selected first to send the DDN messages.
Intelligent RAT Paging for ISR requires manual configuration through the Command Line Interface (CLI).
Licenses
Intelligent RAT Paging for ISR is a licensed-controlled Cisco feature. A separate feature license may be
required. 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.
Limitations
The Intelligent RAT Paging for ISR feature has the following restrictions and limitations:
1 The S-GW performs sequential paging (if configured) only for Downlink data triggered Downlink Data
Notification (DDN) messages. All control event triggered DDN messages are treated as high priority DDN
messages and the S-GW always performs parallel paging for control event triggered DDN messages. No
DDN-Throttling and DDN-Delay shall be applicable only to Downlink data triggered DDN messages.
2 S-GW Intelligent RAT Paging for ISR is supported on the S-GW only. It is not supported on the SAE-GW.
Flows
This section provides descriptive call flows for the Intelligent RAT Paging for ISR feature. It includes call
flows for both sequential and parallel paging procedures.
Figure 46: Intelligent RAT Paging for ISR: Sequential Paging Procedure
Table 24: Intelligent RAT Paging for ISR: Sequential Paging Procedure Description
Step Description
1 The S-GW receives the downlink data packet for an idle UE which has ISR active
and the S-GW is configured to initiate sequential paging for this APN. The Last
known RAT Type for this UE is E-UTRAN.
2 The S-GW initiates Downlink Data Notification towards the MME and starts the
timer tp.
3 The MME replies with a Downlink Data Notification Ack message. If the MME
initiates the service request procedure for this UE within time tp, then the S-GW will
stop the timer tp and process the service request procedure. The S-GW will not initiate
the Downlink Data Notification towards S4-SGSN (in a different RAT). Therefore,
the system saves the paging attempt and the radio resource of the S4-SGSN.
4 If the MME does not initiates the service request procedure for this UE within time
tp then upon expiry of timer tp, the S-GW will initiate the Downlink Data Notification
towards the S4-SGSN.
5 The S4-SGSN replies with a Downlink Data Notification Ack message. The S4-SGSN
attempts to page the UE. The S-GW will receive the service request procedure from
S4-SGSN.
Figure 47: Intelligent RAT Paging for ISR: Parallel Paging Procedure
Table 25: Intelligent RAT Paging for ISR: Parallel Paging Procedure 1
Step Description
1 The S-GW receives the downlink data packet for an ISR active, Idle UE. The S-GW
is configured to initiate parallel paging for this APN.
6 The MME and S4-SGSN attempt to page the UE. The S-GW will receive the service
request procedure from either the MME or S4-SGSN.
config
context sgw_context_name
sgw-service sgw-service_name
ddn isr-sequential-paging delay time duration_msecs
end
Notes:
• sgw_context_name is the name of the context in which the S-GW service is configured.
• sgw_service_name is the name of the configured S-GW service.
• ddn isr-sequential-paging delay time specifies the time delay between the paging of different RAT
types. This value is entered in increments of 100 milliseconds (where 1 = 100 milliseconds). Valid entries
are from 1 to 255. The default setting is 10 (1 second).
Applicable Platform(s)
• ASR 5500
• VPC - DI
• VPC - SI
Related Documentation
• Command Line Interface Reference
• P-GW Administration Guide
• S-GW Administration Guide
• SAEGW Administration Guide
Revision History
Important Revision history details are not provided for features introduced before release 21.2 and N5.1.
Feature Description
This feature enables P-GW, S-GW, and SAEGW nodes to support the control messages received on all the
transport addresses exchanged during the session setup. Prior to this release P-GW, S-GW, and SAEGW did
not support BRCmd, MBCmd, and DBCmd messages on transport other than the transport used for establishing
session.
A new CLI command has been introduced at the egtp-service level to control the behavior of the BRCmd,
MBCmd, and DBCmd messages.
How it Works
This section describes the working of this feature. Following is the sample call flow for MBCmd.
The following figure illustrates call flow when the feature is disabled:
The following figure illustrates the call flow when feature is enabled:
When a session is being established, P-GW, S-GW, and SAEGW node uses the IPv6 address as transport.
This transport is used for establishing tunnel with peer node. If IPv4 and IPv6 addresses are exchanged in
control FTEID then the node should handle MBCmd, BRCmd, and DBCmd messages on IPv4 transport by
the nodes.
When a session is being established, if IPv4 address is used as a transport and is being used for establishing
tunnel with peer node, and if IPv4 and IPv6 addresses are exchanged in control FTEID, then the MBCmd,
BRCmd, and DBCmd messages are also handled on the IPv6 transport by the nodes.
When a session is being established, if IPv4 and IPv6 addresses are exchanged in data F-TEID by both peers,
then the GTP-U data packets get handled on both IPv6 and IPv4 transport.
When a session is being established, if IPv4 address is used as a transport, however, C-TEID does not contain
IPv4 address, then that message is rejected by the node. The nodes exhibit similar behavior for IPv6 addresses.
When a session is being established, if IPv4 and IPv6 addresses are exchanged in data F-TEID by both peers,
then GTP-U data packets get handled on IPv6 and IPV4 transport both.
The following table displays the message handling behavior in different session establishment scenarios:
configure
context context_name
egtp-service service_name
[no] gtpc command-messages dual-ip-stack-support
end
NOTES:
• no: Disables the feature.
• command-messages: Configures MBC or DBC or BRC messages on S-GW and P-GW.
• dual-ip-stack-support: Enables P-GW, S-GW, SAEGW nodes to handle command messages on both
IPv4/IPv6 transport, if supported.
show configuration
The following new fields are added to the output of this command:
• gtpc command-messages dual-ip-stack-support - Specifies the command messages on both IPv4/IPv6
transport if supported.
methods for handling APNs, including converting incoming APNs to preferred APNs and this control
can be used in a focused fashion or defined to cover ranges of subscribers.
• In another example, it is not unusual for a blanket configuration to be implemented for all subscriber
profiles stored in the HLR. This results in a waste of resources, such as the allocation of the default
highest QoS setting for all subscribers. An operator policy provides the opportunity to address such
issues by allowing fine-tuning of certain aspects of profiles fetched from HLRs and, if desired, overwrite
QoS settings received from HLR.
These policies can override standard behaviors and provide mechanisms for an operator to circumvent the
limitations of other infrastructure elements such as DNS servers and HLRs in 2G/3G networks.
By configuring the various components of an operator policy, the operator fine-tunes any desired restrictions
or limitations needed to control call handling and this can be done for a group of callers within a defined IMSI
range or per subscriber.
Re-Usable Components - Besides enhancing operator control via configuration, the operator policy feature
minimizes configuration by drastically reducing the number of configuration lines needed. Operator policy
maximizes configurations by breaking them into the following reusable components that can be shared across
IMSI ranges or subscribers:
• call control profiles
• IMEI profiles (SGSN only)
• APN profiles
• APN remap tables
• operator policies
• IMSI ranges
Each of these components is configured via a separate configuration mode accessed through the Global
Configuration mode.
Call control profiles are configured with commands in the Call Control Profile configuration mode. A single
call control profile can be associated with multiple operator policies
For planning purposes, based on the system configuration, type of packet services cards, type of network (2G,
3G, 4G, LTE), and/or application configuration (single, combo, dual access), the following call control profile
configuration rules should be considered:
• 1 (only one) - call control profile can be associated with an operator policy
• 1000 - maximum number of call control profiles per system (e.g., an SGSN).
• 15 - maximum number of equivalent PLMNs for 2G and 3G per call control profile
◦15 - maximum number of equivalent PLMNs for 2G per ccprofile.
◦15 - maximum number of supported equivalent PLMNs for 3G per ccprofile.
APN Profile
An APN profile groups a set of access point name (APN)-specific parameters that may be applicable to one
or more APNs. When a subscriber requests an APN that has been identified in a selected operator policy, the
parameter values configured in the associated APN profile will be applied.
For example:
• enable/disable a direct tunnel (DT) per APN. (SGSN)
• define charging characters for calls associated with a specific APN.
• identify a specific GGSN to be used for calls associated with a specific APN (SGSN).
• define various quality of service (QoS) parameters to be applied to calls associated with a specific APN.
• restrict or allow PDP context activation on the basis of access type for calls associated with a specific
APN.
APN profiles are configured with commands in the APN Profile configuration mode. A single APN profile
can be associated with multiple operator policies.
For planning purposes, based on the system configuration, type of packet processing cards and 2G, 3G, 4G,
and/or dual access, the following APN profile configuration rules should be considered:
• 50 - maximum number of APN profiles that can be associated with an operator policy.
• 1000 - maximum number of APN profiles per system (e.g., an SGSN).
• 116 - maximum gateway addresses (GGSN addresses) that can be defined in a single APN profile.
IMEI profiles are configured with commands in the IMEI Profile configuration mode. A single IMEI profile
can be associated with multiple operator policies.
For planning purposes, based on the system configuration, type of packet processing cards, type of network
(2G, 3G, 4G, LTE), and/or application configuration (single, combo, dual access), the following IMEI profile
configuration rules should be considered:
• 10 - maximum number of IMEI ranges that can be associated with an operator policy.
• 1000 - maximum number of IMEI profiles per system (such as an SGSN).
An APN remap table group is a set of APN-handling configurations that may be applicable to one or more
subscribers. When a subscriber requests an APN that has been identified in a selected operator policy, the
parameter values configured in the associated APN remap table will be applied. For example, an APN remap
table allows configuration of the following:
• APN aliasing - maps incoming APN to a different APN based on partial string match (MME and SGSN)
or matching charging characteristic (MME and SGSN).
• Wildcard APN - allows APN to be provided by the SGSN when wildcard subscription is present and
the user has not requested an APN.
• Default APN - allows a configured default APN to be used when the requested APN cannot be used for
example, the APN is not part of the HLR subscription. In 21.4 and later releases, the configuration to
enable default APN on failure of DNS query is enhanced to support S4-SGSN. When wildcard APN is
received in subscription, the DNS request is tried with the MS requested APN and on failure of DNS,
it is retried with the APN value configured in the APN remap table.
APN remap tables are configured with commands in the APN Remap Table configuration mode. A single
APN remap table can be associated with multiple operator policies, but an operator policy can only be associated
with a single APN remap table.
For planning purposes, based on the system configuration, type of packet processing cards, type of network
(2G, 3G, 4G, LTE), and/or application configuration (single, combo, dual access), the following APN remap
table configuration rules should be considered:
• 1 - maximum number of APN remap tables that can be associated with an operator policy.
• 1000 - maximum number of APN remap tables per system (such as an SGSN).
• 100 - maximum remap entries per APN remap table.
Operator Policies
The profiles and tables are created and defined within their own configuration modes to generate sets of rules
and instructions that can be reused and assigned to multiple policies. An operator policy binds the various
configuration components together. It associates APNs, with APN profiles, with an APN remap table, with
a call control profile, and/or an IMEI profile (SGSN only) and associates all the components with filtering
ranges of IMSIs.
In this manner, an operator policy manages the application of rules governing the services, facilities, and
privileges available to subscribers.
Operator policies are configured and the associations are defined via the commands in the Operator Policy
configuration mode.
The IMSI ranges are configured with the command in the SGSN-Global configuration mode.
For planning purposes, based on the system configuration, type of packet processing cards, type of network
(2G, 3G, 4G, LTE), and/or application configuration (single, combo, dual access), the following operator
policy configuration rules should be considered:
• 1 maximum number of call control profiles associated with a single operator policy.
• 1 maximum number of APN remap tables associated with a single operator policy.
• 10 maximum number of IMEI profiles associated with a single operator policy (SGSN only)
• 50 maximum number of APN profiles associated with a single operator policy.
• 1000 maximum number of operator policies per system (e.g., an SGSN) this number includes the single
default operator policy.
• 1000 maximum number of IMSI ranges defined per system (e.g., an SGSN).
Important SGSN operator policy configurations created with software releases prior to Release 11.0 are not forward
compatible. Such configurations can be converted to enable them to work with an SGSN running Release
11.0 or higher. Your Cisco Account Representative can accomplish this conversion for you.
IMSI Ranges
Ranges of international mobile subscriber identity (IMSI) numbers, the unique number identifying a subscriber,
are associated with the operator policies and used as the initial filter to determine whether or not any operator
policy would be applied to a call. The range configurations are defined by the MNC, MCC, a range of MSINs,
and optionally the PLMN ID. The IMSI ranges must be associated with a specific operator policy.
IMSI ranges are defined differently for each product supporting the operator policy feature.
How It Works
The specific operator policy is selected on the basis of the subscriber's IMSI at attach time, and optionally the
PLMN ID selected by the subscriber or the RAN node's PLMN ID. Unique, non-overlapping, IMSI + PLMN-ID
ranges create call filters that distinguish among the configured operator policies.
The following flowchart maps out the logic applied for the selection of an operator policy:
Important This section provides a minimum instruction set to implement operator policy. For this feature to be
operational, you must first have completed the system-level configuration as described in the System
Administration Guide and the service configuration described in your product's administration guide.
The components can be configured in any order. This example begins with the call control profile:
Step 1 Create and configure a call control profile, by applying the example configuration presented in the Call Control Profile
Configuration section.
Step 2 Create and configure an APN profile, by applying the example configuration presented in the APN Profile Configuration
section.
Note It is not necessary to configure both an APN profile and an IMEI profile. You can associate either type of profile
with a policy. It is also possible to associate one or more APN profiles with an IMEI profile for an operator
policy (SGSN only).
Step 3 Create and configure an IMEI profile by applying the example configuration presented in the IMEI Profile Configuration
section (SGSN only).
Step 4 Create and configure an APN remap table by applying the example configuration presented in the APN Remap Table
Configuration section.
Step 5 Create and configure an operator policy by applying the example configuration presented in the Operator Policy
Configuration section.
Step 6 Configure an IMSI range by selecting and applying the appropriate product-specific example configuration presented
in the IMSI Range Configuration sections below.
Step 7 Associate the configured operator policy components with each other and a network service by applying the example
configuration in the Operator Policy Component Associations section.
Step 8 Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode
command save configuration. For additional information on how to verify and save configuration files, refer to the
System Administration Guide .
Step 9 Verify the configuration for each component separately by following the instructions provided in the Verifying the
Feature Configuration section of this chapter.
The example below includes some of the more commonly configured profile parameters with sample variables
that you will replace with your own values.
configure
imei-profile profile_name
ggsn-address 211.211.123.3
direct-tunnel not-permitted-by-ggsn (SGSN only)
associate apn-remap-table remap1
end
Notes:
• It is optional to configure an IMEI profile. An operator policy can include IMEI profiles and/or APN
profiles.
• This profile will only become valid when it is associated with an operator policy.
The example below includes sample variable that you will replace with your own values.
configure
operator-policy policy_name
associate call-control-profile profile_name
apn network-identifier apn-net-id_1 apn-profile apn_profile_name_1
apn network-identifier apn-net-id_2 apn-profile apn_profile_name_1
imei range <imei_number to imei_number imei-profile name profile_name
associate apn-remap-table table_name
end
Notes:
• Refer to the Operator-Policy Configuration Mode chapter in the Command Line Interface Reference
for command details and variable options.
• This policy will only become valid when it is associated with one or more IMSI ranges (SGSN) or
subscriber maps (MME and S-GW).
Important All commands listed here are under Exec mode. Not all commands are available on all platforms.
Verify that the operator policy has been created and that required profiles have been associated and configured properly
by entering the following command in Exec Mode:
show operator-policy full name oppolicy1
The output of this command displays the entire configuration for the operator policy configuration.
show operator-policy full name oppolicy1
Operator Policy Name = oppolicy1
Call Control Profile Name : ccprofile1
Validity : Valid
APN Remap Table Name : remap1
Validity : Valid
IMEI Range 711919739 to 711919777
IMEI Profile Name : imeiprof1
Include/Exclude : Include
Validity : Valid
APN NI homers1
APN Profile Name : apn-profile1
Validity : Valid
Notes:
• If the profile name is shown as "Valid", the profile has actually been created and associated with the policy. If the
Profile name is shown as "Invalid", the profile has not been created/configured.
• If there is a valid call control profile, a valid APN profile and/or valid IMEI profile, and a valid APN remap table,
the operator policy is valid and complete if the IMSI range has been defined and associated.
Important This feature is supported on the P-GW, and S-GW. Overcharging Protection is supported on the SAEGW
only if the SAEGW is configured for Pure P or Pure S functionality.
P-GW will never be aware of UE state (idle or connected mode). Charging for downlink data is applicable at
P-GW, even when UE is in idle mode. Downlink data for UE may be dropped at S-GW when UE is in idle
mode due to buffer overflow or delay in paging. Thus, P-GW will charge the subscriber for the dropped
packets, which isn't desired. To address this problem, with Overcharging Protection feature enabled, S-GW
will inform P-GW to stop or resume charging based on packets dropped at S-GW and transition of UE from
idle to active state.
If the S-GW supports the Overcharging Protection feature, then it will send a CSReq with the PDN Pause
Support Indication flag set to 1 in an Indication IE to the P-GW.
If the P-GW supports the Overcharging Protection feature then it will send a CSRsp with the PDN Pause
Support Indication flag set to 1 in Indication IE and/or private extension IE to the S-GW.
Once the criterion to signal "stop charging" is met, S-GW will send Modify Bearer Request (MBReq) to
P-GW. MBReq would be sent for the PDN to specify which packets will be dropped at S-GW. The MBReq
will have an indication IE and/or a new private extension IE to send "stop charging" and "start charging"
indication to P-GW. For Pause/Start Charging procedure (S-GW sends MBReq), MBRes from P-GW will
have indication and/or private extension IE with Overcharging Protection information.
When the MBReq with stop charging is received from a S-GW for a PDN, P-GW will stop charging for
downlink packets but will continue sending the packets to S-GW.
P-GW will resume charging downlink packets when either of these conditions is met:
• When the S-GW (which had earlier sent "stop charging" in MBReq) sends "start charging" in MBReq.
• When the S-GW changes (which indicates that maybe UE has relocated to new S-GW).
This feature aligns with the 3GPP TS 29.274: 3GPP Evolved Packet System (EPS); Evolved General Packet
Radio Service (GPRS) Tunneling Protocol for Control plane (GTPv2-C) specification.
Important When Overcharging Protection feature is configured at both P-GW service and APN, configuration at
APN takes priority.
License
Overcharging Protection is a license enabled feature and a new license key has been introduced for Overcharging
Protection for P-GW functionality.
Important Contact your Cisco account representative for information on how to obtain a license.
configure
apn-profile apn_profile_name
overcharge-protection { abnormal-s1-release | ddn-failure | drop-limit drop_limit_value { packets |
bytes } }
[ remove ] overcharge-protection { abnormal-s1-release | ddn-failure | drop-limit }
end
Notes:
• remove:
Removes the specified configuration.
• abnormal-s1-release:
(for future use) If overcharging protection is enabled for abnormal-s1-release, S-GW would send MBR
to pause charging at P-GW if Abnormal Release of Radio Link signal occurs from MME.
• ddn-failure:
If overcharging protection is enabled for ddn-failure message, MBR would be sent to P-GW to pause
charging upon receiving DDN failure from MME/S4-SGSN.
• drop-limit drop_limit_value { packets | bytes } }
Send MBR to pause charging at P-GW if specified number of packets/bytes is dropped for a PDN
connection.
drop_limit_value is an integer from 1 through 99999.
• packets: Configures drop-limit in packets.
• bytes: Configures drop-limit in bytes.
• When a CSReq does not have an Indication IE with the PDN Pause Support Indication flag set to 1, but
the P-GW supports Overcharging Protection, then it responds with both an Indication and Private
Extension IE.
P-GW Schema
The following bulk statistics have been added to the P-GW schema for Overcharging Protection:
For descriptions of these variables, see the Statistics and Counters Reference guide.
• sessstat-ovrchrgprtctn-uplkpktdrop
• sessstat-ovrchrgprtctn-uplkbytedrop
• sessstat-ovrchrgprtctn-dnlkpktdrop
• sessstat-ovrchrgprtctn-dnlkbytedrop
Important When a session is in overcharge protection state, not all the downlink packets will be dropped; however,
downlink packets will be rate limited. Current configuration allows one downlink packet per minute
towards S-GW without charging it, if any downlink packets come to P-GW. P-GW will not generate any
packets of its own.; separate debug stats have been added for P-GW.
Important When a session is in overcharge protection state, not all the downlink packets will be dropped; however,
downlink packets will be rate limited. Current configuration allows one downlink packet per minute
towards S-GW without charging it, if any downlink packets come to P-GW. P-GW will not generate any
packets of its own; separate debug stats have been added for P-GW.
Feature Description
S-GW/P-GW provide configuration control to change the DSCP value of the user-datagram packet and outer
IP packet (GTP-U tunnel IP header). DSCP marking is done at various levels depending on the configuration.
When the Paging Policy Differentiation (PPD) feature is enabled, however, the user-datagram packet DSCP
(tunneled IP packet) marking does not change.
Currently, standards specify QCI to DSCP marking of outer GTP-U header only. All configurations present
at ECS, P-GW, and S-GW to change the user-datagram packet DSCP value are non-standard. The
standards-based PPD feature dictates that P-CSCF or similar Gi entity marks the DSCP of user-datagram
packet. This user-datagram packet DSCP value is sent in DDN message by S-GW to MME/S4-SGSN.
MME/S4-SGSN uses this DSCP value to give paging priority.
Important P-GW and S-GW should apply the PPD feature for both Default and Dedicated bearers. As per the
specifications, P-GW transparently passes the user-datagram packet towards S-GW. This means, if PPD
feature is enabled, operator can't apply different behavior for Default and Dedicated bearers.
Relationships
Since P-GW/S-GW support non-standard based DSCP marking, there is a conflict when both standard based
PPD feature and non-standard based user-datagram packet DSCP configuration is enabled. To avoid this
conflict:
• APN and service level configuration is ignored if PPD feature is enabled.
• S-GW/P-GW can alter the outer GTP-U header DSCP value, even if PPD feature is enabled.
• User-datagram packet DSCP value is unaltered by ECS, P-GW, and S-GW if PPD feature is enabled.
• At P-GW, APN-level configuration is added to enable/disable the PPD feature.
• At S-GW, service-level configuration is added to enable/disable the PPD feature. This is to send DSCP
in Paging and Service Information IE of all the DDN messages triggered by either IMS-PDN or
Internet-PDN, etc.
• Separate Paging feature and PPD feature co-exist in system. That means, if both features are enabled,
both Paging and Service Information IE and Separate-paging IE are sent in DDN.
• Currently on P-GW, the DSCP configuration is getting applied at sub-session level during call setup
time. So, when the PPD CLI is enabled for P-GW, it is applicable for new calls.
• Currently on S-GW, the DSCP configuration is getting applied at S-GW service level. So, when PPD
CLI is enabled in S-GW service, it is applicable for both new and existing calls.
• Once the PPD CLI is enabled, it exists even after Session Recovery and ICSR switch over.
• The Paging and Service Information IE is used to carry per bearer paging and service information.
License
PPD is a license enabled feature. S-GW Paging Profile license key is required to enable PPD functionality
for P-GW, S-GW, and SAEGW.
Important Contact your Cisco account representative for information on how to obtain a license.
How It Works
Architecture
S-GW
When S-GW supports the PPD feature, it shall include new Paging and Service Information IE in the Downlink
Data Notification message triggered by the arrival of downlink data packets at the S-GW. The Paging Policy
Indication value within this IE will contain the value of the DSCP in TOS (IPv4) or TC (IPv6) information
received in the IP payload of the GTP-U packet from the P-GW.
At S-GW, service-level configuration enables/disables the PPD feature. Once the PPD is configured, the
feature is enabled and applicable for both existing and new calls.
P-GW
User-datagram packet DSCP value is unaltered by P-GW for downlink data. The PPD feature is supported
only for S5/S8 interface. For all Handoff scenarios from other interface to S5/S8 interface, the PPD feature
will get enabled if APN had it during its call setup time at that interface.
At P-GW, APN-level configuration enables/disables the PPD feature. If PPD feature is enabled for the call
and handoff happens from S5/S8 interface to any other interface, PPD feature should get disabled. Now, if
handoff happens and this call will come back to S5/S8 interface, PPD feature should become enabled.
SAEGW
To support PPD feature in SAEGW, both S-GW and P-GW configuration is required.
Standards Compliance
The PPD functionality complies with the following standards:
• 29.274, CR-1565, "Paging Policy Indication in Downlink Data Notification Message"
• 23.401, CR-2731 "Paging policy differentiation for IMS voice"
configuration. To avoid such a conflict, you must configure the PPD functionality on both P-GW (APN level
granularity) and S-GW (service level granularity).
Configuration
The following CLI commands are used to manage the functionality for the PPD feature.
Enabling on P-GW
The following command enables the PPD feature on P-GW at APN level.
configure
context context_name
apn apn_name
paging-policy-differentiation
end
Enabling on S-GW
The following command enables the PPD feature on S-GW at service level.
configure
context context_name
sgw-service service_name
paging-policy-differentiation
end
Notes:
• This is to send DSCP in Paging and Service Information IE of all the DDN messages triggered by either
IMS-PDN or Internet-PDN, etc.
• It is up to MME/S4-SGSN to use the Paging and Service Information IE of DDN message.
• If PPD feature is enabled at S-GW service, it is applicable for all calls irrespective of the APN profiles.
Disabling on P-GW
The following command disables the PPD feature on P-GW at APN level.
configure
context context_name
apn apn_name
no paging-policy-differentiation
end
Disabling on S-GW
The following command disables the PPD feature on S-GW at service level.
configure
context context_name
sgw-service service_name
no paging-policy-differentiation
end
Related Documentation
• Command Line Interface Reference
• P-GW Administration Guide
• SAEGW Administration Guide
• S-GW Administration Guide
Revision History
Feature Description
This feature adds support for the Presence Reporting Area (PRA) functionality to comply with the 3GPP
standards.
The Presence Reporting Area is an area defined within the 3GPP packet domain for reporting of UE presence
within that area. This is required for policy control and in charging scenarios. In E-UTRAN, the PRA may
consist in a set of neighbor or non-neighbor Tracking Areas, or eNBs or cells. There are two types of Presence
Reporting Areas: "UE-dedicated Presence Reporting Areas" and "Core Network pre-configured Presence
Reporting Areas" that apply to an MME pool.
This feature has the following highlights:
• This feature is supported for LTE/S4-SGSN related RAT-type. For any other RAT type, P-GW ignores
PRA information received from the PCRF.
• Currently single PRA-ID is supported per session as specification compliance.
• Currently, in P-GW, core network pre-configured presence reporting area is supported.
• For ICSR to N-1 release, PRA feature is not supported.
• PRA-ID is not supported on CDR interface, that is, Gz, Gy and Rf.
How It Works
During an IP-CAN session, the PCRF determines whether the reports for change of the UE presence in the
PRA are required for an IP-CAN session. This determination is made based on the subscriber's profile
configuration and the supported AVP features. The parameter CNO-ULI is set for the same. If reporting is
required for the IP-CAN session, the PCRF provides Presence-Reporting-Area-Information AVP, which
contains the PRA identifier within the Presence-Reporting-Area-Identifier AVP, to the PCEF.
During an IP-CAN session, the PCRF determines whether the reports for change of the UE presence in the
PRA are required for an IP-CAN session. This determination is made based on the subscriber's profile
configuration and the supported AVP features. The parameter CNO-ULI is set for the same. If the reporting
is required for the IP-CAN session, the PCRF provides Presence-Reporting-Area-Information AVP, which
contains the PRA identifier within the Presence-Reporting-Area-Identifier AVP to the PCEF. For a UE-dedicated
PRA, PCRF provides the list of elements consisting of the PRA within the
Presence-Reporting-Area-Elements-List AVP to the PCEF. The PCRF might activate the reporting changes
of the UE presence in the PRA by subscribing to the
CHANGE_OF_UE_PRESENCE_IN_PRESENCE_REPORTING_AREA_REPORT event trigger at the PCEF
at any time during the entire IP-CAN session.
Scenario Behavior
When PCRF sends a new PRA ID
different than the initial call setup. • P-GW receives the new PRA ID during the initial call setup and
stores the PRA ID information.
• In RAR, the PRA_EVENT_TRIGGER is registered.
• P-GW send PRA_ACTION PRA ID="A", ACTION=start.
• In CCA-U, a new PRA ID is received.
• P-GW stores new PRA ID information
• P-GW sends PRA_ACTION PRA ID = "B", Action=start but
does not send Action=stop for the earlier PRA.
PRA ID Decode Behavior If PRA ID received is "core network pre-configured presence reporting
area", then, P-GW ignores the "Element List" coming from PCRF.
Otherwise, if PRA ID is "UE-dedicated Presence Reporting Area",
then, P-GW parses the "Element List" and forwards it toward the
access side.
If PRA ID values from PCRF are 1 MSB of the value received from the PCRF is evaluated to find the
octet, 2 octets, and 3 octets. PRA type. While encoding, GTPC side zeros are prepended to make
it 3 octets.
For example, if PRA ID = FC (1111 1100) is received from PCRF it
is considered as UE-dedicated PRA and while decoding it is decoded
as 00 00 FC.
P-GW forwards PRA information toward the roaming subscriber if
it is received from the PCRF or from UE.
Important Change of UE presence in the Presence Reporting Area
reporting does not apply to the roaming scenario.
Scenario Behavior
Roaming Scenario Change of UE presence in the Presence Reporting Area reporting
does not apply to the roaming scenario.
When the serving EPC node (MME, S4-SGSN) is changed, the
Presence Reporting Area identifier is transferred for all PDN
connections as part of the MM Context information to the target
serving node during the mobility procedure. The list of Presence
Reporting Area elements are also transferred if they are provided by
the P-GW.
Handover Behavior: How the PRA MME/S4-SGSN gets the PRA Identifier from source MME/S4-SGSN
identifier is communicated from as part of MM Context information.
source MME/S4-SGSN to target When the serving EPC node (MME, S4-SGSN) is changed, the
MME/S4-SGSN. Presence Reporting Area identifier is transferred for all PDN
connections as part of the MM Context information to the target
serving node during the mobility procedure. The list of Presence
Reporting Area elements are also transferred if they are provided by
the P-GW.
Handoff Behavior: How PRA is Depending on the access type and internal configuration PCRF
disabled when the new access type is deactivates the PRA, if the new access PRA is not supported.
not supported PRA. During an IP-CAN session, P-GW notifies the PCRF that the UE is
located in an access type, where local PCRF configuration is such
that the reporting changes of the UE presence in the PRA are not
supported. The PCRF unsubscribes to the change of UE presence in
the PRA, if previously activated.
Behavior if for E-UTRAN some If PRA is enabled from PCRF, then EPC nodes supports it. If all nodes
nodes do not support PRA. are not supported, then PRA PCRF activates the Location Change
Reporting.
Important For E-UTRAN access, homogeneous support of reporting
changes of UE presence in a Presence Reporting Area in
a network is assumed. When the PCRF configuration
indicates that reporting changes of the UE presence in a
PRA is supported for E-UTRAN, this means all P-GWs,
all MME, and all S-GW support it, including the MME
and S-GW working in the network sharing mode. If the
change of UE presence in the PRA reporting is not
supported, the PCRF may instead activate the location
change reporting at the cell or serving area level.
Scenario Behavior
When access side procedure failure In Update or Create bearer procedure failure where the PRA action
or collision occurs (Create or Update was sent in the request message and if PRA information was not
Bearer procedure) received in response message, P-GW attempts to send the PRA action
in next control procedure toward the remote peer.
In Update or Create bearer procedure failure where PRA action was
sent in the request message and if PRA information was not received
in the response message, P-GW assumes it as PRA action was
successfully communicated toward the remote peer.
In the Update or Create bearer collision scenario where PRA action
was sent in the request message and Update or Create procedure got
aborted, P-GW attempts to send the PRA action in next control
procedure toward the remote peer.
configure
context context_name
ims-auth-service<service_name>
policy-control
diameter encode-supported-features { cno-uli }
{ default | no } diameter encode-supported-features
end
Notes:
• cno-uli: Enables Presence Reporting Area Information Reporting feature.
• diameter encode-supported-features: Enables or disables encoding and sending of Supported-Features
AVP.
• no: Removes the previously configured supported features.
• default: Applies the default setting for this command.
conditional-policy-info-default-qos
cno-uli
Auth Decision:
Event Triggers:
QoS-Change
RAT-Change
Change-Of-UE-Presence-In-PRA
Usage-Report
Resource-Modification-Request
Peer Profile :
PGW Access : default
SGW Access : default
SGW Network : default
ULI : TAI-ID
MCC : 214 MNC : 365
LAC : n/a TAC : 0x6789
SAC : n/a RAC : n/a
CI : n/a ECI : 0x1234567
PRA Information :
PRA-ID: 0xFC0104 Action: Start Status: In
Bearer QoS :
QCI : 5
ARP : 0x08
PCI : 0 (Enabled)
PL : 2
PVI : 0 (Enabled)
MBR Uplink(bps) : 0 MBR Downlink(bps) : 0
GBR Uplink(bps) : 0 GBR Downlink(bps) : 0
Feature Description
802.1p/MPLS EXP marking helps in providing QoS treatment by prioritizing traffic at L2 level.
Currently, data traffic for different access types, such as GGSN, eHRPD, P-GW, and S-GW, refer to the
QCI-QoS table and configure the appropriate 802.1p or MPLS-EXP (L2 QoS) markings based on the
internal-qos value associated with particular row. However, the usage of internal-qos from the QCI-QoS table
is not configurable and uses the default values. In addition, L2 QoS (802.1p/MPLS EXP) marking is not
supported in GGSN, SAEGW, and GTPv1/eHRPD calls on P-GW.
With this feature, you can:
• Configure internal priority in QCI-mapping table for the GGSN, GTPv1 P-GW, and SAEGW calls.
• Mark subscriber traffic with either 802.1p or MPLS-EXP to enable or disable L2 marking. A new CLI
command has been introduced to support service specific configuration to mark subscriber traffic. This
L2 marking can be decided based on QCI and DSCP marking together or solely based on DSCP marking.
Limitations
• This feature does not control the behavior of the control packets. The control packets (GTP-C) continue
to get L2 marked based on DSCP derived L2 marking.
• This feature is not supported on standalone GGSN. It is supported on GnGp-GGSN node.
How It Works
You can configure internal priority in QCI-mapping table for the GGSN, GTPv1 P-GW, and SAEGW calls.
You can also mark subscriber traffic with either 802.1p or MPLS-EXP to enable or disable L2 marking. To
do this, use the CLI command to configure service specific configuration to mark subscriber traffic. This L2
marking can be decided based on QCI and DSCP marking together or solely based on DSCP marking.
If the no or default option of the CLI command is used, then the traffic is not marked. When the feature is not
enabled, traffic is not marked.
P-GW GTPv2, S-GW, SAEGW Calls:
Previous Behavior: StarOS release 16 onward, the QCI-QoS mapping feature used internal-QoS for L2
marking, which in turn uses QCI-Derived marking for data traffic. This was the default behavior for P-GW,
S-GW, and SAEGW calls.
New Behavior: With this feature, the traffic is marked based on:
• QCI-Derived
• DSCP-Derived
• None
If the no or default option of the CLI command is used, then the traffic is not marked and the default behavior
is executed. When the feature is not enabled, traffic is not marked.
ggsn-service service_name
internal-qos data { dscp-derived | none | qci-derived }
{ no | default } internal-qos data { dscp-derived | none | qci-derived }
end
Notes:
• no: Disables the specified functionality.
• default: Disables the functionality.
• dscp-derived: Data packets are marked at Layer 2 based on DSCP configured in qci-qos mapping table,
then if DSCP is not configured in the qci-qos mapping table then data packets are not marked.
• none: Data packets are not marked with Layer 2 (MPLS EXP/802.1P) marking.
• qci-derived: Data packets are marked at Layer 2 based on internal-qos-priority configured in qci-qos
mapping table. If internal-qos priority is not configured in the qci-qos mapping table, then the data
packets are not marked.
• show configuration
• show service-type { all | name service_name }
Please see the Monitoring and Troubleshooting Revised Marking for Subscriber Traffic section for the command
output.
show configuration
This command displays the following output:
• When internal-qos data is configured as none:
internal-qos data none
Important In StarOS version 19 and later releases, the Rf interface is not supported on the S-GW.
It is recommended that before using the procedures in this chapter you select the configuration example that
best meets your service model, and configure the required elements for that model as described in the
administration guide for the product that you are deploying.
This chapter includes the following topics:
Introduction
The Rf interface is the offline charging interface between the Charging Trigger Function (CTF) (for example,
P-GW, P-CSCF) and the Charging Collection Function (CCF). The Rf interface specification for
LTE/GPRS/eHRPD offline charging is based on 3GPP TS 32.299 V8.6.0, 3GPP TS 32.251 V8.5.0 and other
3GPP specifications. The Rf interface specification for IP Multimedia Subsystem (IMS) offline charging is
based on 3GPP TS 32.260 V8.12.0 and 3GPP TS 32.299 V8.13.0.
Offline charging is used for network services that are paid for periodically. For example, a user may have a
subscription for voice calls that is paid monthly. The Rf protocol allows the CTF (Diameter client) to issue
offline charging events to a Charging Data Function (CDF) (Diameter server). The charging events can either
be one-time events or may be session-based.
The system provides a Diameter Offline Charging Application that can be used by deployed applications to
generate charging events based on the Rf protocol. The offline charging application uses the base Diameter
protocol implementation, and allows any application deployed on chassis to act as CTF to a configured CDF.
In general, accounting information from core network elements is required to be gathered so that the billing
system can generate a consolidated record for each rendered service.
The CCF with the CDF and Charging Gateway Function (CGF) will be implemented as part of the core
network application. The CDF function collects and aggregates Rf messages from the various CTFs and
creates CDRs. The CGF collects CDRs from the CDFs and generates charging data record files for the data
mediation/billing system for billing.
The following figure shows the Rf interface between CTF and CDF.
The Rf offline charging architecture mainly consists of three network elements CCF, CTF and Diameter
Dynamic Routing Agent (DRA).
License Requirements
The Rf interface support is a licensed Cisco feature. A separate feature license may be required. 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.
Supported Standards
Rf interface support is based on the following standards:
• IETF RFC 4006: Diameter Credit Control Application; August 2005
• 3GPP TS 32.299 V9.6.0 (2010-12) 3rd Generation Partnership Project; Technical Specification Group
Services and System Aspects; Telecommunication management; Charging management; Diameter
charging applications (Release9)
Basic Principles
The Diameter client and server must implement the basic functionality of Diameter accounting, as defined
by the RFC 3588 Diameter Base Protocol.
For offline charging, the CTF implements the accounting state machine as described in RFC 3588. The CDF
server implements the accounting state machine "SERVER, STATELESS ACCOUNTING" as specified in
RFC 3588, i.e. there is no order in which the server expects to receive the accounting information.
The reporting of offline charging events to the CDF is managed through the Diameter Accounting Request
(ACR) message. Rf supports the following ACR event types:
Request Description
START Starts an accounting session
ACR types START, INTERIM and STOP are used for accounting data related to successful sessions. In
contrast, EVENT accounting data is unrelated to sessions, and is used e.g. for a simple registration or
interrogation and successful service event triggered by a network element. In addition, EVENT accounting
data is also used for unsuccessful session establishment attempts.
Important The ACR Event Type "EVENT" is supported in Rf CDRs only in the case of IMS specific Rf
implementation.
The following table describes all possible ACRs that might be sent from the IMS nodes i.e. a P-CSCF and
S-CSCF.
Table 28: Accounting Request Messages Triggered by SIP Methods or ISUP Messages for P-CSCF and S-CSCF
ACR [Stop] SIP BYE message (both normal and abnormal session termination cases)
SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful SIP session
set-up
In order for the application to be compliant with the specification, state machines should be implemented at
some level within the implementation.
Diameter Base supports the following Rf message commands that can be used within the application.
There are a series of other Diameter messages exchanged to check the status of the connection and the
capabilities.
• Capabilities Exchange Messages: Capabilities Exchange Messages are exchanged between the diameter
peers to know the capabilities of each other and identity of each other.
◦Capabilities Exchange Request (CER): This message is sent from the client to the server to know
the capabilities of the server.
◦Capabilities Exchange Answer (CEA): This message is sent from the server to the client in response
to the CER message.
• Device Watchdog Request (DWR): After the CER/CEA messages are exchanged, if there is no more
traffic between peers for a while, to monitor the health of the connection, DWR message is sent from
the client. The Device Watchdog timer (Tw) is configurable and can vary from 6 through 30 seconds.
A very low value will result in duplication of messages. The default value is 30 seconds. On two
consecutive expiries of Tw without a DWA, the peer is considered to be down.
Important DWR is sent only after Tw expiry after the last message that came from the server. Say
if there is continuous exchange of messages between the peers, DWR might not be sent
if (Current Time - Last message received time from server) is less than Tw.
• Device Watchdog Answer (DWA): This is the response to the DWR message from the server. This is
used to monitor the connection state.
• Disconnect Peer Request (DPR): This message is sent to the peer to inform to shutdown the connection.
There is no capability currently to send the message to the Diameter server.
• Disconnect Peer Answer (DPA): This message is the response to the DPR request from the peer. On
receiving the DPR, the peer sends DPA and puts the connection state to "DO NOT WANT TO TALK
TO YOU" state and there is no way to get the connection back except for reconfiguring the peer again.
A timeout value for retrying the disconnected peer must be provided.
If an ACR-I could not be sent to the OFCS, the PCEF caches the container record and sends it in the next
transaction to the OFCS.
In releases prior to 16.0, once a CCR-U was sent out over Gy interface, ACR-I message was immediately
triggered (or containers were cached) based on policy accounting configuration and did not wait for CCA-U.
In 16.0 and later releases, the containers are closed only after receiving CCA-U successfully. That is, Rf trigger
will be sent only after receiving CCA-U message.
For more information on the command associated with this feature, see the Accounting Policy Configuration
Mode Commands chapter of the Command Line Interface Reference.
In 17.0 and later releases, a common timer based approach is implemented for Rf and Gy synchronization.
As part of the new design, Gy and Rf will be check-pointed at the same point of time for periodic as well as
for full check-pointing. Thus, the billing records will always be in sync at all times regardless of during an
ICSR switchover event, internal events, session manager crashes, inactive Rf/Gy link, etc. This in turn avoids
any billing discrepancies.
Feature Description
This feature is introduced to support creation and communication of duplicate Rf records to secondary AAA
group servers configured for the Rf interface.
To achieve this functionality, the following configurations must be enabled –
• aaa group CLI command under APN to configure a maximum of 2 AAA groups - primary and secondary
AAA groups, or two different endpoints for Rf Diameter accounting servers
• diameter accounting duplicate-record under AAA group to allow Rf duplicate record creation
The diameter accounting duplicate-record is a new CLI command introduced in this release for duplicating
the Rf START, INTERIM and STOP accounting records.
Important This is a license-controlled CLI command. For more information, contact your Cisco account representative.
In releases prior to 21, gateway allows only one AAA group configuration per APN for Rf accounting. The
AAA group is configured to load balance across multiple servers to pass the Rf traffic and also expect an
accounting answer. Note that the secondary AAA group configuration is allowed currently but is restricted
to only RADIUS accounting.
In release 21 and beyond, the gateway is provided with the ability to configure a secondary AAA group per
APN for the Rf interface, and send the duplicate Diameter Rf accounting records to the secondary AAA group
servers. The secondary AAA group is used for non-billing purposes only.
Important The failed duplicate records will neither be written to HDD nor added to the archival list.
There is no change in the current behavior with the primary AAA group messages. The primary AAA group
is independent of the secondary AAA group, and it has multiple Rf servers configured. When the Rf servers
do not respond even after multiple retries as per the applicable configuration, the Rf records are archived and
stored in HDD. This behavior continues as is irrespective of the configuration of secondary aaa-group.
Secondary aaa group has a very similar configuration as the primary aaa group except that the new CLI
command diameter accounting duplicate-record is additionally included to configure the secondary aaa-group.
It is also important to note that different Diameter endpoints and a separate set of Rf servers should be
provisioned for both primary and secondary AAA groups.
If all the configured servers are down, the request message will be discarded without writing it in HDD or
archiving at aaamgr.
The original and duplicate Rf messages use two different aaa-groups and two different Diameter endpoints.
Hence, the values for Session-ID AVP will be different. Based on the configuration of primary and secondary
endpoints the values for Origin-Host, Origin-Realm, Destination-Realm, and Destination-Host AVPs may be
different. Also based on the configuration under policy accounting for inclusion of virtual/gn apn name for
secondary group Called-Station-ID AVP might change. All other AVPs will have the same values as with the
primary aaa group Rf message.
Also, note that the values such as Acct-Interim-Interval (AII) interval received in ACA from secondary group
of AAA servers will be ignored.
Limitations
The following are the limitations of this feature:
• Only one secondary AAA group can be configured per APN.
• If all the Rf peers under secondary aaa group are down and duplicate Start Record is not sent, then the
duplicate Interim and Stop records will also not be sent to any of the secondary aaa group servers even
though they arrived later. However if the servers are up and duplicate Start record was sent but the server
did not respond, duplicate Start will be dropped after all the retries. In this case, the duplicate Interim
and Stop records may be sent out to the server.
• In cases when duplicate Start record was sent, but during duplicate Interim/Stop record generation peers
were not responding/down, after all retries duplicate Interim and Stop records will be dropped and will
not be written to HDD.
• Minimal impact to memory and CPU is expected due to the duplicate record generation for every primary
Rf record.
These statistics are maintained per aaamgr instance level. For descriptions of these statistics, see the Statistics
and Counters Reference guide.
These statistics can also be collected per group basis/server basis for duplicate records i.e. through show
diameter aaa-statistics group <group_name> and show diameter aaa-statistics server <server_name>
CLI commands.
Feature Description
Currently there is no way to quickly turn on the Rf accounting to the Data Streaming Service (DSS) server
per Virtual APN (S6b-VAPN) without reaching all nodes in the network and provision the Virtual APN on
each of them. This feature is implemented to truncate the virtual APN name returned by S6b server with the
configured standard delimiters. In this way a single configuration per node can be utilized for all enterprises
based on a virtual APN. This approach will significantly reduce the size and time to provision new enterprises
with the requested feature.
To achieve this functionality, a configuration is added per APN to enable truncation of S6b-VAPN and also
to configure the delimiter(s) where the APN name is to be truncated. Standard delimiters like (.) and (-) are
used since APN name supports only these two characters apart from the alphanumeric ones.
If AAA server returns both hyphen and dot delimiters or the same delimiter twice or more as a virtual-apn,
then the first delimiter will be considered as a separator. For example, if the AAA server returns the virtual-apn
as xyz-cisco.com, then hyphen is the separator.
AAA manager performs the truncation of the Virtual APN name based on the APN configuration and provides
the correct APN profile for the truncated APN name. If the truncation is successful, the full virtual APN name
will be sent to Gx, Gy and Rf interfaces.
Accounting records are required to support real-time usage notification and device management functionality.
So, the apn-name-to-be-included CLI command is extended to enable actual APN (Gn-APN) or virtual APN
(S6b returned virtual APN) name to be included in Called-Station-ID AVP in the secondary Rf accounting
records (secondary server group) under policy accounting configuration. Currently, policy accounting
configuration supports sending the Gn-APN/S6b-VAPN in Called-Station-ID for primary Rf server. With
this CLI command, this functionality is extended for the secondary Rf server.
A new AAA attribute “Secondary-Called-Station-ID” is added to support sending Gn/Virtual APN name in
the Called-Station-ID AVP for duplicate Rf records sent to secondary group Rf server.
• Both dot and hyphen delimiters can be configured in the same line or a new line.
• no virtual-apn truncate-s6b-vapn: Disables the truncation of virtual APN name. If both delimiters
should be disabled at once, use the no virtual-apn truncate-s6b-vapn CLI command.
If a particular delimiter needs to disabled, it should be done explicitly. For example, if the dot delimiter
should be disabled, use the no virtual-apn truncate-s6b-vapn delimiter dot CLI command.
• By default this feature will be disabled and no delimiter will be configured.
• This CLI command takes effect only when S6b server returns virtual APN name in Authentication
Authorization Accept (AAA) message.
• If the separator character is not present in the received S6b virtual APN name, then the whole virtual
APN name will be considered for configuration look-up.
Important For P-GW, GGSN and SAEGW services, if the truncation of S6b returned virtual APN name fails and
the virtual APN name is not configured, the call will be rejected with ‘unknown-apn-name’ cause.
How it Works
This section describes how offline charging for subscribers works with Rf interface support in
GPRS/eHRPD/LTE/IMS networks.
The following figure and table explain the transactions that are required on the Diameter Rf interface in order
to perform event based charging. The operation may alternatively be carried out prior to, concurrently with
or after service/content delivery.
Step Description
1 The network element (CTF) receives indication that service has been used/delivered.
Step Description
3 The CDF receives the relevant service charging parameters and processes accounting request.
4 The CDF returns Accounting-Answer (ACA) message with Accounting-Record-Type AVP set to
EVENT_RECORD to the CTF in order to inform that charging information was received.
The following figure and table explain the simple Rf call flow for session based charging.
Step Description
1 The CTF receives a service request. The service request may be initiated either by the user or the
other network element.
2 In order to start accounting session, the CTF sends a Accounting-Request (ACR) with
Accounting-Record-Type AVP set to START_RECORD to the CDF.
Step Description
3 The session is initiated and the CDF opens a CDR for the current session.
5 When either AII elapses or charging condition changes are recognized at CTF, the CTF sends an
Accounting-Request (ACR) with Accounting-Record-Type AVP set to INTERIM_RECORD to
the CDF.
10 The CDF updates the CDR accordingly and closes the CDR.
Important The procedures in this section assume that you have installed and configured your chassis including the
ECS installation and configuration as described in the Enhanced Charging Services Administration Guide.
3 Enable Rf accounting in ACS as described in Enabling Rf Interface in Active Charging Service, on page
338.
4 Configure Rf interface support as described in the relevant sections:
• Configuring GGSN / P-GW Rf Interface Support, on page 338
• Configuring P-CSCF/S-CSCF Rf Interface Support, on page 347
Important In StarOS versions 19 and later, the Rf interface is not supported on the S-GW.
5 Save your configuration to flash memory, an external memory device, and/or a network location using
the Exec mode command save configuration. For additional information on how to verify and save
configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Important Commands used in the configuration examples in this section provide base functionality to the extent that
the most common or likely commands and/or keyword options are presented. In many cases, other optional
commands and/or keyword options are available. Refer to the Command Line Interface Reference for
complete information regarding all commands.
exit
policy accounting <policy_name>
accounting-event-trigger { cgi-sai-change | ecgi-change | flow-information-change | interim-timeout
| location-change | rai-change | tai-change } action { interim | stop-start }
accounting-keys qci
accounting-level { flow | pdn | pdn-qci | qci | sdf | subscriber }
cc profile index { buckets num | interval seconds | sdf-interval seconds | sdf-volume { downlink octets
{ uplink octets } | total octets | uplink octets { downlink octets } } | serving-nodes num | tariff time1 min
hrs [ time2 min hrs...time4 min hrs ] | volume { downlink octets { uplink octets } | total octets | uplink
octets { downlink octets } } }
max-containers { containers | fill-buffer }
end
Notes:
• The policy can be configured in any context.
• For information on configuring accounting levels/policies/modes/event triggers, refer to the Accounting
Policy Configuration Mode Commands chapter in the Command Line Interface Reference.
• Depending on the triggers configured, the containers will either be cached or released. In the case of
GGSN/P-GW, the containers will be cached when the event trigger is one of the following:
◦QOS_CHANGE
◦FLOW_INFORMATION_CHANGE
◦LOCATION_CHANGE
◦SERVING_NODE_CHANGE
◦SERVICE_IDLE
◦SERVICE_DATA_VOLUME_LIMIT
◦SERVICE_DATA_TIME_LIMIT
◦IP_FLOW_TERMINATION
◦TARIFF_CHANGE
If the event trigger is one of the following, the containers will be released:
◦VOLUME_LIMIT
◦TIME_LIMIT
◦RAT_CHANGE
◦TIMEZONE_CHANGE
◦PLMN_CHANGE
Important Currently, SDF and flow level accounting are supported in P-GW.
The following assumptions guide the behavior of P-GW, GGSN and CCF for Change-Condition triggers:
• Data in the ACR messages due to change conditions contain the snapshot of all data that is applicable
to the interval of the flow/session from the previous ACR message. This includes all data that is already
sent and has not changed (e.g. SGSN-Address).
• All information that is in a PDN session/flow up to the point of the Change-Condition trigger is captured
(snapshot) in the ACR-Interim messages. Information about the target
Time-Zone/ULI/3GPP2-BSID/QoS-Information/PLMN Change/etc will be in subsequent Rf messages.
Table 32: P-GW/GGSN and CCF Behavior for Change-Condition in ACR-Stop and ACR-Interim for LTE/e-HRPD/GGSN
Gathering Statistics
This section explains how to gather Rf and related statistics and configuration information.
In the following table, the first column lists what statistics to gather, and the second column lists the action
to perform.
• ID 6: Bearer Update
• Bearer modifications that are intra-S-GW and intra-MME are not be reported.
• Bearers and sessions that fail to setup are reported once in a session/bearer creation record with the result
code set to failure.
Active-to-Idle Transitions
This table below describes how active-to-idle transitions generate event records.
Step Description
1 UE becomes Active (via UE or NW initiated service request)
2 Local Detach
3 Complete
5 ISR deactivation
16 Request accepted
Reject
67 Invalid length
69 Mandatory IE incorrect
70 Mandatory IE missing
71 Reserved
72 System failure
73 No resources available
79 Unexpected repeated IE
81 Relocation failure
87 UE not responding
88 UE refuses
89 Service denied
90 Unable to page UE
91 No memory available
94 Request rejected
104 APN Restriction type Incompatible with currently active PDN connection
105 Invalid overall length of the triggered response message and a piggybacked initial
message
116 to 239 Spare. This value range is reserved for Cause values in rejection response message.
Sub-Causes
NO_INFORMATION
ABORTED_BY_SESSION_DELETION
NO_RESPONSE_FROM_MME
INTERNALLY_TRIGGERED
BEARERS_IN_MULTIPLE_PDN_CONNECTIONS
EXPECTED_BEARERS_MISSING_IN_MESSAGE
UNEXPECTED_BEARERS_PRESENT_IN_MESSAGE
Feature Description
S-GW Paging includes the following scenarios:
Scenario 1: S-GW sends a DDN message to the MME/S4-SGSN nodes. MME/S4-SGSN responds to the
S-GW with a DDN Ack message. While waiting for the DDN Ack message from the MME/S4-SGSN, if the
S-GW receives a high priority downlink data, it does not resend a DDN to the MME/S4-SGSN.
Scenario 2: If a DDN is sent to an MME/S4-SGSN and TAU/RAU MBR is received from another
MME/S4-SGSN, S-GW does not send DDN.
Scenario 3: DDN is sent to an MME/S4-SGSN and DDN Ack with Cause #110 is received. DDN Ack with
cause 110 is treated as DDN failure and standard DDN failure action procedure is initiated.
To handle these scenarios, the following two enhancements have been added to the DDN functionality:
• High Priority DDN at S-GW
• MBR-DDN Collision Handling
In addition to the above functionality, to be compliant with 3GPP standards, support has been enhanced for
Downlink Data Notification message and Mobility procedures. As a result, DDN message and downlink data
which triggers DDN is not lost. This helps improve paging KPI and VoLTE success rates in scenarios where
DDN is initiated because of SIP invite data.
Licensing
This is a license-controlled feature. Contact your Cisco account or support representative for detailed licensing
information.
How It Works
This section describes working of these features related to S-GW Paging.
ARP Priority of second bearer is Buffers these downlink data Buffers these downlink data
higher than the first bearer on packets and the does not send a packets and the does not send a
which first DDN was sent. new DDN. However, separate new DDN. However, separate
Paging DDN is always sent out Paging DDN is always sent out
and this restriction does not apply and this restriction does not apply
to it. to it.
DDN is sent to an MME/S4-SGSN DDN Ack with cause 110 is treated S-GW starts a guard timer and wait
and DDN Ack with Cause #110 is as DDN failure and standard DDN for TAU/RAU MBR from the new
received. failure action procedure is initiated. MME/S4-SGSN. The timer is
stopped if any MBR or DDN
failure indication is received. But,
if none of them is received, and the
timer expires all buffered downlink
data packets are flushed.
If this is followed by mobility
handover without any data TEIDs,
DDN is resent to this new control
node as well.
MBR received with bearer context There is a possibility that DDN Bearers marked for deletion are not
to be removed. could be sent with EBIs included in any of the DDN
corresponding to bearers marked messages.
for deletion.
Limitations
High Priority DDN at S-GW
This section lists the limitations for High Priority DDN at S-GW feature.
1 High Priority DDN is always enabled whenever the license is available.
2 High priority DDN is sent only once. Any further higher priority data does not trigger another DDN.
3 DDN delay timer and DDN throttling is not applicable to High Priority DDN.
4 Separate Paging DDN is always sent out and above restriction does not apply to it.
5 No-user-connect behavior restarts the moment high priority DDN is sent out.
Configuring mbr-guard-timer
This CLI sets the guard timer to wait for a MBR when DDN Ack with Cause #110 temp-ho-rejection) is
received.
If the guard timer expires and if no MBR of any type or DDN Failure Indication is received, all the buffered
downlink data is flushed out and paging flags are reset.
If the guard timer is running and any MBR is received, the timer is stopped and no further action is taken.
If the guard timer is running and DDN Failure Indication is received, the timer is stopped and standard DDN
failure action is taken.
By default, this CLI command is always enabled.
configure
context context_name
sgw-service service_name
ddn temp-ho-rejection mbr-guard-timer time_in_seconds
{ no | default } ddn temp-ho-rejection mbr-guard-timer
end
Notes:
• no: Disables the guard timer.
• default: Enables the guard timer and sets it to the default value, 60 seconds.
• temp-ho-rejection: Action to be taken when peer node indicates temporary rejection of paging due to
handover-in-progress.
• mbr-guard-timer: Sets the guard timer for a MBR when DDN Ack with Cause #110 (temp-ho-rejection)
is received. When the timer expires, S-GW flushes all the buffered downlink data packets. The range
of this timer is from 60 seconds to 300 seconds. Default timer value is 60 seconds.
See the section Monitoring and Troubleshooting High Priority DDN Interaction Feature, on page 363 for the
command output.
Important If the MBR-guard-timer is disabled, DDN Ack with Temporary-HO-Rejection is treated as DDN Failure
Indication.
• Number of times 'High Priority Paging' is triggered and number of times it could not be triggered as it
was already sent. This shows data corresponding to only S-GW service(s) which is part of SAEGW
service(s).
• Number of times DDN Ack with a cause #110 is received and number of times TAU/RAU MBR with
control node change triggers a DDN automatically.
• Number of packets and bytes discarded when MBR-guard-timer expires; this timer is started when a
DDN Ack with Temporary-HO-Rejection (Cause #110) is received.
• This CLI shows data only corresponding to standalone sgw-service(s).
• Number of times DDN Ack with a cause #110 is received and number of times TAU/RAU MBR with
control node change triggers a DDN automatically.
• Data only corresponding to the S-GW service(s) which is associated with a SAEGW service(s).
• Number of packets and bytes discarded when MBR-guard-timer expires; this timer is started when a
DDN Ack with Temporary-HO-Rejection (Cause #110) is received
• Number of packets and bytes discarded when MBR-guard-timer expires; this timer is started when a
DDN Ack with Temporary-HO-Rejection (Cause #110) is received
• Packets/Bytes dropped due to MBR-guard-timer expiry are not shown for collapsed calls.
Important Paging packets dropped statistics are not incremented for collapsed calls and hence the newly added
counter of "MBR Guard timer Expiry Flushed Data" is also not updated in that case.
This command displays the following output:
Feature Description
Due to production forecasts, support has been added to the StarOS for one million S1-U connections on a
single S-GW.
The S1-U interface is the user plane interface carrying user data between an eNodeB and an S-GW received
from the terminal. The StarOS now has the capability to scale the number of S1-U peers to one million per
VPN context.
A CLI command enables operators to set the number of S1-U peers for which statistics should be collected.
The limit is restricted to less than one million peers (128k) due to StarOS memory limitations.
How it Works
The gtpumgr uses the following guidelines while allocating peers:
• When a session installation comes from the Session Manager, a peer is created. If statistics are maintained
at the Session Manager, the gtpumgr also creates the peer record with the statistics.
• Peer records are maintained per service.
• The number of peers is maintained at the gtpumgr instance level. The limit is one million S1-U peers
per gtpumgr instance.
• If the limit of one million peers is exceeded, then peer creation fails. It causes a call installation failure
in the gtpumgr, which leads to an audit failure if an audit is triggered.
The feature changes impact all the interfaces/services using the gtpu-service including
GGSN/S4-SGSN/S-GW/P-GW/SAEGW/ePDG/SaMOG/HNB-GW/HeNB-GW for:
• The Gn and Gp interfaces of the General Packet Radio Service (GPRS)
• The Iu, Gn, and Gp interfaces of the UMTS system
• The S1-U, S2a, S2b, S4, S5, S8, and S12 interfaces of the Evolved Packet System (EPS)
Recovery/ICSR Considerations
• After a session manager/gtpumgr recovery or after an ICSR switchover, the same set of peers configured
for statistics collection is recovered.
◦Peers with 0 sessions and without statistics are not recovered.
◦Peers with 0 sessions and with statistics are recovered.
◦Peers with Extension Header Support disabled are recovered.
• While upgrading from a previous release, ensure the newer release chassis gtpu peer statistics threshold
is equal to or greater than the previous release. This way the GTPU peer statistics are preserved during
the upgrade. For example, if you are upgrading from StarOS release 19.0 to 20.2, and the StarOS 19.0
system has 17,000 GTPU sessions, then configure the threshold on the StarOS 20.2 system to 17,000
as well.
Assumptions
Overall assumptions for the S5/S8 and S11 interfaces used in the LTE EPC between Serving Gateway and
PDN-GW are listed below.
• GTPv2-C is the signaling protocol used on the S5/S8 and S11 interfaces. Message and IE definitions
comply with 3GPP 29.274.
• S5 and S11 interfaces use IPv6 transport as defined in 29.274, section 10.
• MSISDN is assumed to be sent by MME in initial attach.
• MEI will always be retrieved by MME from UE and sent on S11 during initial attach and UE Requested
PDN connectivity procedure.
• MME will always send UE time zone information.
• The default bearer does not require any TFT.
• The PCO IE in Create Session Request shall contain two DNS server IP addresses. [S5/S8]
• UE's location change reporting support is required. [S5/S8]
• The S-GW does not verify the content of the IEs which are forwarded on the S5/S8 interface from the
S11 interface. The P-GW verifies the content of all the IEs received on the S5/S8 interface.
Caution Large numbers of services greatly increase the complexity of management and may impact overall system
performance. Only create a large number of services only be configured if your application absolutely
requires it. Please contact your local service representative for more information.
• The system maintains statistics for a maximum of 4,096 peer LMAs per MAG service.
• The total number of entries per table and per chassis is limited to 256.
• Even though service names can be identical to those configured in different contexts on the same system,
this is not a good practice. Having services with the same name can lead to confusion, difficulty
troubleshooting problems, and make it difficult to understand outputs of show commands.