P-GW Changes in Release 20 - Cisco - Global Home · PDF fileP-GW Changes in Release 20 ... CLI Added for Third-party S-GW Inter-operation ... packet.Thisuser-datagrampacketDSCPvalueissentinDDNmessagebyS-GWtoMME/S4-SGSN

P-GW Changes in Release 20

This chapter identifies features and functionality added to, modified for, or deprecated from the P-GW inStarOS 20 software releases.

• P-GW Changes in 20.3, page 1

• P-GW Changes in Release 20.2.x, page 2

• P-GW Changes in Release 20.2, page 4

• P-GW Enhancements for 20.1, page 33

• P-GW Enhancements for 20.0, page 35

P-GW Changes in 20.3

Support for Option 26 in DHCPCSCuy91901 - Configuration to send Reseller and Subclass ID AVPs on Gy

Applicable Products P-GW, SAEGW

Feature DescriptionWhile fetching IPv4 address for the UE, P-GW acts as an independent DHCP server and client at the sametime. It acts as a DHCP server towards the UE and as DHCP client towards the external DHCP server. Inearlier release, support for exchange of certain DHCP options between the UE and the external DHCP serverthrough the P-GW was added. This included support for relaying certain external DHCP server providedoptions (1, 3, 6, 28, and 43) to the UE along with the IPv4 address when deferred address allocation wasconfigured with IP-Addralloc Proxy mode.

This feature adds support for Option 26 received in DHCP OFFER message from the DHCP server.

P-GW preserved the exchanged DHCP option 26 between the UE and the external DHCP server. P-GW relaysthis option for any future message exchanges between the UE and the external DHCP server. The externalDHCP server component of the P-GW reserves and maintains the external DHCP server provided DHCPoption so that when the UE renews or rebinds the DHCP lease, P-GW responds with the preserved value.

Release Change Reference, StarOS Release 20 1

This feature introduces a behavior change with respect to renewal request. Earlier, when the ASR5500 wasconfigured in DHCP proxy mode and when the DHCP server did not respond to a renewal request, aretransmission at time T2 (.85 * lease time) did not include both of the configured DHCP servers. DHCP leasegot expired after retries exhaustion in the RENEW state.

With this feature, suppose the number of retransmission is configured as 2, then in RENEW state maximum2 retries are done for the DHCP request messages. If no response is received from the DHCP server and stateis changed to REBIND then also DHCP request messages is retried 2 times.

Old Behavior:Earlier, for lower values of "number of retransmission" (example >= 2), DHCP request messagewas not retried in the REBIND state.

New Behavior: Now, DHCP request message is retried for the number of times it is configured in bothRENEW and REBIND state.

P-GW Changes in Release 20.2.xThis section identifies all of the P-GW enhancements included in this release:

Feature Changes - new or modified features or behavior changes. For details, refer to theP-GWAdministrationGuide for this release.

Command Changes - changes to any of the CLI command syntax. For details, refer to the Command LineInterface Reference for this release.

Performance Indicator Changes - new, modified, and deprecated bulk statistics, disconnect reasons, countersand/or fields in new or modified schema and/or show command output. For detailed information on the showcommands, refer to the Statistics and Counters Reference for this release. For detailed information on thecounters and disconnect reasons, refer to the BulkstatStatistics_documentation.xls spreadsheet that isincluded as part of the software companion package for this release.

This release includes enhancements that are applicable to multiple products. The following lists the variousmulti-product enhancements sections, some of which might include content applicable to your P-GW.

Important

• AAA Enhancements

• CF Enhancements

• ECS Enhancements

• GTPP Enhancements

• Lawful Intercept Enhancements

• NAT Enhancements

• SNMP MIB Enhancements

• System and Platform Enhancements

CLI Added for Third-party S-GW Inter-operation IssueCSCva92344 - Interop issue with third Party SGW vendor with respect to Rel10

Release Change Reference, StarOS Release 202

P-GW Changes in Release 20P-GW Changes in Release 20.2.x

Applicable Products: P-GW

Feature ChangesIn some cases, UE is not able to connect to Cisco P-GW when connecting through a third-party S-GW whichcannot process Create Session Response with "context not found." Cisco P-GW behavior is compliant withspecification Release 12 3GPP TS 29.274, however, CLI has been added to resolve this third-partyinter-operation issue and allow a smooth transition. When enabled, new CLI will send bearer context IE withEPS Bearer ID (EBI) value hardcoded to 5 in Create Session Response in case of "context not found" scenario.

Previous Behavior: If UE is not attached to Cisco P-GW via any other PDN, the Create Session Request isrejected with cause code "context not found." In this case, Create Session Response is sent without bearercontext IE in it.

NewBehavior:With the newCLI egtp reject-cause no-context include-bearer-ctxt configured under P-GWservice, Create Session Response for rejection cause code "context not found" will contain bearer context IEwith EBI value hardcoded to 5.

Important • Nomatter what comes in Create Session Request as EBI in "context not found" rejection for no PDNconnected to P-GW, Create Session Response will contain only one bearer context with EBI valuehardcoded to 5.

• If S-GWhas extensive check for EBI in Create Request and Create Response, behavior of the systemwill be S-GW implementation dependent.

• This CLI is intended to resolve specific third-party inter-operation issue only. Contact your Ciscoaccount or support representative to determine if this configuration is needed.

Cisco does not recommend configuring this CLI for S-GW implementation that follows standardspecifications, such as Release 12 3GPP TS 29.274.

Customer Impact: In customer network, S-GWwhich expects bearer context IE in Create Session Responsefor "context not found" case where no PDN is connected to P-GW, call will be through as dummy IE is sentif this CLI is configured. To limit the impact to other customers, this behavior is CLI controlled.

Behavior of the system is S-GW implementation dependent for customers with S-GWs that do extensivecheck on received EBI in Create Session Request and Response.

Command Changesegtp reject-cause no-context include-bearer-ctxt

The keywords reject-cause no-context include-bearer-ctxt have been added to this command to handlethird-party S-GWswhich expect bearer context IE in Create Session Response for "context not found" rejectionfrom no PDN connected to P-GW.configure

context context_namepgw-service service_name

egtp reject-cause no-context include-bearer-ctxt{ default | no } egtp reject-cause no-context include-bearer-ctxt

Notes:


P-GW Changes in Release 20CLI Added for Third-party S-GW Inter-operation Issue

•When enabled, P-GW will send bearer context IE with EPS Bearer ID (EBI) value hardcoded to 5 inCreate Session Response in case of "context not found" scenario.

• This CLI is intended to resolve specific third-party inter-operation issue only. Contact your Cisco accountor support representative to determine if this configuration is needed.

Cisco does not recommend configuring this CLI for S-GW implementation that follows standardspecifications, such as Release 12 3GPP TS 29.274.

• default: If UE is not attached to P-GW via any other PDN, the Create Session Request is rejected withcause code "context not found." In this case, Create Session Response is sent without bearer context IEin it.

• no: If UE is not attached to P-GW via any other PDN, the Create Session Request is rejected with causecode "context not found." In this case, Create Session Response is sent without bearer context IE in it.

P-GW Changes in Release 20.2This section identifies all of the P-GW enhancements included in this release:





Important


• CF Enhancements








P-GW Changes in Release 20P-GW Changes in Release 20.2

APN-Backoff Timer SupportCSCux56957 - APN-Backoff timer support on PGW/SAEGW based on Chassis overload state

Applicable Products: P-GW, SAEGW

Feature DescriptionPreviously, the P-GW did not distinguish signaling traffic from Delay Tolerant or Low Priority devices suchas low priority machine-to-machine traffic.

The UE was able to indicate its device profile to the MME via NAS and Attach Request messages. The MMEwas able to pass this information to the P-GW via the Signaling Priority Indication Information Element (IE)on the S5 interface. Some UEs may not have supported the sending of the Signaling Priority Indication IE onthe S5 interface to the P-GW. As a result, the P-GW could not distinguish between the signaling types. Withthe current release, the P-GW can distinguish between these signaling types.

In addition, during overload situations, the P-GW previously allowed new sessions from Low Access PriorityIndicator (LAPI) devices and treated the traffic from LAPI devices with the same priority as the normal UEs.With the current StarOS release, during overload conditions, the P-GW can be configured to back off thetraffic that is identified as LAPI. The identification is based on either the APN configuration or the SignalingPriority Indicator IE.

The backoff timer algorithm and the R12 GTP-C Load/Overload Control algorithmwork together. This featureprovides the benefit of rejecting low priority calls in turn allowing more bandwidth for high priority calls.

Functionality

The following functionality has been implemented to support the APN Backoff Timer functionality:

1 The Signaling Priority Indication IE on the S5 interface in the Create Session Request message identifiesthe low priority devices.

2 A LAPI APN can be configured. Any call landing on that APN is considered a LAPI call.

3 A back off timer value is configured in the APN. The backoff timer is sent in Create Session Responsemessages in the P-GW Back-Off Timer IE.

4 If the following conditions are met, the call is rejected with the cause APN Congestion. The configuredbackoff timer value is inserted in the Back Off Timer IE in the Create Session Response message.

• Once an incoming call is identified as LAPI due to condition 1 or 2 above.

• The P-GW is in the overload state.

• The backoff timer is configured.

5 The M2M license must be present and enabled on the system. The GTP-C Load/Overload feature'sconfiguration and backend reporting of overload parameters works with the M2M license.

6 In some dictionaries (for example, custom35) CDRs have a LAPI field for LAPI calls. This field is populatedwhen the Signaling Priority Indication IE indicates that the call is a LAPI call. However, if the call is oftype LAPI due to the LAPI APN configuration, then the CDR should not have the LAPI field.


P-GW Changes in Release 20APN-Backoff Timer Support

7 Bulk statistics, counters, and statistics have been implemented at the APN and P-GW service level to showthe number of calls rejected due to the APN Backoff Timer feature.

GTP-C Overload Feature and the M2M License

To detect whether the P-GW/SAEGW is in the overload state, the GTP-C Overload feature's framework hasbeen used. It is tied to the M2M license so that only overload configuration and reporting of the overload stateis enabled. The remaining overload features such as, sending the OCI towards the peers, throttling, andreceiving OCIs from peers do not work. This leads to the following behavioral scenarios:

If a Call is a LAPI call and the Backoff Timer is Configured and the P-GW is in the Overload State:

• Only M2M License: Call is rejected with cause APN Congestion.

• Only GTP-C Overload Enabled: Not applicable as backoff timer cannot be configured.

• Both M2M and Overload Enabled: Call is rejected with cause APN Congestion. That is, LAPI takespriority over the GTP-C Load/Overload feature.

If a Call is Not LAPI or Backoff Timer is Not Configured and the P-GW is in the Overload State:

• Only M2M License Enabled: No impact. Call is accepted normally.

• Only Overload License Enabled: Call accepted. OCI will be sent in the Create Session Responsemessage.Overload feature works normally.

• Both M2M and Overload Features Enabled: Call accepted. OCI is sent in the Create Session Responsemessage. Overload feature works normally. Backoff Timer feature is ignored.

Licensing

The APNBackoff Timer feature requires that theM2M license be enabled on the P-GW/SAEGW. Contactyour Cisco account or support representative for licensing details.

Important

Configuring APN Backoff Timer Support on the P-GW/SAEGWThis section describes how to configure APN Backoff Timer Support on the P-GW/SAEGW. The procedureconsists of the following tasks:

1 Configuring LAPI Behavior

2 Configuring the Backoff Timer

3 Verifying the Configuration

Configuring LAPI Behavior

Use the following example to configure LAPI behavior:configure

apn apn_name



pdn-behavior lapiend

To disable LAPI behavior:configure

apn apn_nameno pdn-behaviorend

Notes:

• pdn-behavior lapi configures the APN as a LAPI APN.

• no pdn-behavior disables the LAPI APN configuration.

Do not configure the emergency APN and pdn-behavior lapi settings in the same APN, as these twosettings are mutually exclusive. If both settings are configured in the same APN the pdn-behavior lapiconfiguration takes priority. As a result, if both settings are configured and the system is overloaded, thecall will be rejected.

To determine if both settings are configured in the same APN, execute the show configuration errorverbose command in Exec Mode. The command output contains a warning if both settings are configuredin the same APN.

Caution

Configuring the APN Backoff Timer and Jitter Values

The P-GW requires a fixed value and a jitter to introduce randomness in the Backoff Timer value that isreturned to the MME for different sessions; this helps prevent a session storm after the Backoff Timer expiry.

Use the example below to configure the APN Backoff Timer and Jitter Values:configure

apn apn_namebackoff timer-value seconds [ jitter seconds ]end

To disable Backoff Timer functionality:configure

apn apn_nameno backoff timer-valueend

Notes:

• backoff timer-value seconds configures the backoff timer value, in seconds. Valid entry is an integerfrom 0 to 576000 seconds. There is no default setting.

• jitter seconds configures the jitter value, in seconds. Valid entry is from 0 to 1000 seconds. There is nodefault setting.

Verifying the Configuration

To verify the configuration:

In Exec Mode, issue the show apn name apn_name command, apn_name is the name of the APN for whichyou want to view configuration settings.



In the command output, look for the following fields:

• pdn behavior: <lapi> or <no pdn-behavior>

• Backoff Timer Value: <seconds> Jitter: <seconds>

Verify that the configuration settings are correct. If any of the settings are incorrect, use the configurationprocedure in this chapter to reconfigure the incorrect setting(s).

Monitoring the FeatureThis section provides information that enables operators to monitor the APN Backoff Timer feature.

Bulk Statistics

APN SchemaThe following bulk statistics have been added to the APN Schema to support the APN Backoff Timer feature:

• rej-pdn-backofftimer

P-GW SchemaThe following bulk statistic has been added to the P-GW schema to support the APN Backoff Timer feature.

• sessstat-rej-pdn-backofftimer

SAEGW SchemaThe following bulk statistic has been added to the SAEGW schema to support the APNBackoff Timer feature:

• pgw-sessstat-rej-pdn-backofftimer

Show Command Output

This section describes the Exec Mode show commands and output available to monitor the APN BackoffTimer Support on the P-GW/SAEGW feature.

show apn nameThe output of this command has been enhanced to show the configured backoff timer, jitter, and PDN behaviorsettings. These settings appear only if the M2M feature license is enabled.

• pdn behavior: lapi

• Backoff Timer Value: <seconds> Jitter: <seconds>

show apn statisticsThe output of this command has been enhanced to indicate the number of PDNs rejected as a result of theconfigured backoff timer value.

• Number of PDNs rejected due to backoff algorithm:

show configuration apn nameThe output of this command provides the operator with the current APN Backoff Timer settings.



• pdn-behavior lapi (if feature is enabled)

• backoff timer-value <secs> jitter <secs>

show pgw-service statisticsThe output of this command has been enhanced to provide the total number of PDNs rejected due to theconfigured backoff timer value.

• PDNs Rejected By Reason:

◦APN-Backoff Timer

show session disconnect-reasonsThe following disconnect reason has been added to support the APN Backoff Timer feature.

• apn-congestion

Asynchronous Core Transfer Support for egtpinmgrCSCuy89143 - Async Core transfer for Egtpinmgr

Applicable Products: GGSN, P-GW, SAEGW, S-GW

Feature Description

Asynchronous core transfer support for egtpinmgr has been added to optimize outage time during an egtpinmgrrestart.

Previous Behavior: Prior to StarOS release 20.2, when the egtpinmgr restarted, the recovery process beganonly after a core dump file was created and transferred. However, the time taken to transfer the core file wassignificant. The outage time during an egtpinmgr restart was equal to the egtpinmgr recovery time plus thecore file transfer time.

New Behavior: In StarOS release 20.2, support for Asynchronous Core Transfer has been added to includethe egtpinmgr during the recovery process. Now, recovery begins when the egtpinmgr process crashes withoutwaiting for the kernel to complete a core dump file transfer and release its resources. As a result, the outagetime during an egtpinmgr restart is equal to the egtpinmgr recovery time only.

Customer Impact: With this enhancement, outage time during an egtpinmgr restart is reduced. The outagetime consists only of the time required to recover the egtpinmgr. The time taken to create and transfer the corefile no longer contributes to the outage time.

Backup and Recovery of Key KPI StatisticsCSCuy19294 - Bulkstats counter retention after sessgmr process crash


This feature allows the backup of a small set of GGSN, P-GW, SAEGW, and/or S-GW key KPI counters forrecovery of the counter values after a session manager (SessMgr) restart.


P-GW Changes in Release 20Asynchronous Core Transfer Support for egtpinmgr

Feature DescriptionBefore the Backup and Recovery of Key KPI Statistics feature was implemented, statistics were not backedup and could not be recovered after a SessMgr task restart. Due to this limitation, monitoring the KPI was aproblem as the GGSN, P-GW, SAEGW, and S-GW would lose statistical information whenever task restartsoccurred.

KPI calculation involves taking a delta between counter values from two time intervals and then determinesthe percentage of successful processing of a particular procedure in that time interval. When a SessMgr crashesand 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 dipin the graphs plotted using the KPI values, making it difficult for operations team to get a consistent view ofthe 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 WorksA key set of counters used in KPI computation will be backed up for recovery if a SessMgr task restarts. Thecounters 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 forthe 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 tobe 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, allthe 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 AAAMgrand the recovered values are added to the backup counters maintained at per-service level. This will not impactsession 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 counterswill continue to be incremented. The recovered values of the corresponding counters will always be added tothe 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 Changes in Release 20Backup and Recovery of Key KPI Statistics

• P-GW and S-GW service node-level statistics collected

2 P-GW service node configuration will store the following statistics:

• P-GW, eGTP-C ingress, GTP-U ingress, per-interface (s2a, s2b, s5s8), and GGSN (if associated)statistics collected

• SAEGW associated P-GW service statistics not collected

3 S-GW service node configuration will store the following statistics:

• S-GW, eGTP-C ingress/egress, and GTP-U ingress/egress statistics collected

• SAEGW associated S-GW service statistics not collected

4 GGSN statistics:

• GGSN service statistics, if not associated with P-GW service, collected

5 Session disconnect reasons collected if GGSN/P-GW/SAEGW/S-GW is enabled

Error Handling

If adding new statistics is going to cause overflow of 1 MB buffer, that service and the corresponding nodewill not be included. Checkpointing of any further nodes will also be stopped. Error level log will be flaggedif total memory requirement goes above 1 MB.

Limitations

• A backup interval must be specified and counters are backed up only at the specified interval. Forexample, 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, thenif a task crash happens at N+4 minutes, the GGSN, P-GW, SAEGW, and/or S-GW recovers only thevalues 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 upor 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 arenot 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 forcheckpointing but higher probability of hitting the 1 MB storage limit.



• If SessMgr restarts and AAAMgr restarts before SessMgr recovers statistics fromAAAMgr, then backedup statistics are lost.

• This feature is not applicable for ICSR.

Configuring Backup Statistics FeatureFor the Backup and Recovery of Key KPI Statistics feature to work, it must be enabled by configuring thebackup of statistics for the GGSN, P-GW, SAEGW, and/or S-GW.

Configuration

The following CLI commands are used to manage the functionality for the backing up of the key KPI statisticsfeature.

Enabling

The following configures the backup of statistics for the GGSN, P-GW, SAEGW, and/or S-GW and enablesthe Backup and Recovery of Key KPI Statistics feature.configure

statistics-backup { ggsn | pgw | saegw | sgw }exit

Setting the Backup Interval

The following command configures the number of minutes (0 to 60) between each backup of the statistics.When the backup interval is not specified, a default value of 5 minutes is used as the backup intervalconfigure

statistics-backup-interval minutesexit

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 forcheckpointing but higher probability of hitting the 1 MB storage limit.

Important

Disabling

The following configures the GGSN, P-GW, SAEGW, and/or S-GW to disable the backing up of statisticsfor the GGSN, P-GW, SAEGW, and/or S-GW.configure

no statistics-backup { ggsn | pgw | saegw | sgw }exit

Verifying the Backup Statistics Feature Configuration

Use either the show configuration command or the show configuration verbose command to display thefeature configuration.



If the feature was enabled in the configuration, two lines similar to the following will appear in the output ofa show configuration [ verbose ] command:statistics-backup pgwstatistics-backup-interval 5Notes:

• The interval displayed is 5 minutes. 5 is the default. If the statistics-backup-interval command isincluded in the configuration, then the 5 would be replaced by the configured interval number of minutes.

• If the command to disable the feature is entered, then no statistics-backup line is displayed in the outputgenerated by a show configuration [ verbose ] command.

GTP Version Message HandlingCSCuz86464 - Packet with unexpected GTP version: Behavior change.

Applicable products: P-GW, SAEGW, S-GW

Feature Changes

Previous Behavior: If GTP-v2 receives messages with version v1, v0, or above v2, it sends "version notsupported" in corresponding response.

New Behavior: GTP-v2 messages will be silently discarded if version is v1 or v0; however, if version isabove v2, it will send "version not supported" in corresponding response.

Customer Impact: If GTP-v2 receives messages with version v1 or v0, they are silently discarded and peermay not see any response and retry the same.

Paging Policy DifferentiationCSCux56864 - Paging Policy Indication in Downlink Data Notification Msg

Applicable Products: P-GW, SAEGW, S-GW

Feature DescriptionS-GW/P-GW provide configuration control to change the DSCP value of the user-datagram packet and outerIP 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 presentat ECS, P-GW, and S-GW to change the user-datagram packet DSCP value are non-standard. Thestandards-based PPD feature dictates that P-CSCF or similar Gi entity marks the DSCP of user-datagrampacket. 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.


P-GW Changes in Release 20GTP Version Message Handling

P-GW and S-GW should apply the PPD feature for both Default and Dedicated bearers. As per thespecifications, P-GW transparently passes the user-datagram packet towards S-GW. This means, if PPDfeature is enabled, operator can't apply different behavior for Default and Dedicated bearers.

Important

Relationships

Since P-GW/S-GW support non-standard based DSCP marking, there is a conflict when both standard basedPPD feature and non-standard based user-datagram packet DSCP configuration is enabled. To avoid thisconflict:

• 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 DSCPin Paging and Service Information IE of all the DDN messages triggered by either IMS-PDN orInternet-PDN, etc.

It is up to MME/S4-SGSN to use the Paging and Service Information IE of DDNmessage.

Important

• 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 setuptime. 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 PPDCLI 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 functionalityfor P-GW, S-GW, and SAEGW.

Contact your Cisco account representative for information on how to obtain a license.Important


P-GW Changes in Release 20Paging Policy Differentiation

How It Works

Architecture

S-GW

When S-GW supports the PPD feature, it shall include new Paging and Service Information IE in the DownlinkData Notification message triggered by the arrival of downlink data packets at the S-GW. The Paging PolicyIndication value within this IE will contain the value of the DSCP in TOS (IPv4) or TC (IPv6) informationreceived 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, thefeature 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 supportedonly for S5/S8 interface. For all Handoff scenarios from other interface to S5/S8 interface, the PPD featurewill 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 calland handoff happens from S5/S8 interface to any other interface, PPD feature should get disabled. Now, ifhandoff 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.

Relationships to Other Features

• The PPD feature is license controlled under the license for S-GW Paging Profile. Once the license isenabled, both features co-exist together and work independently. That means, DDNmessage might carryboth DSCPmarking specified by PPD feature and Priority DDN value specified by S-GWPaging Profilefeature.

• At S-GW, the user-datagram packet DSCP value is used to send in DDN. S-GW can't change the DSCP,as per the local configuration (APN profile or service level). At eNodeB, the scheduling of the packetis based on the QCI instead of DSCP, however, any EPC node should not change/modify the inner DSCPvalue.

• If the PPD feature is enabled, none of the EPS nodes should change the user-datagram packet DSCPvalue. Therefore, ECS should avoid overwriting DSCP value of user-datagram packet when PPD isenabled.

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"



Configuring Paging Policy Differentiation FeatureFor the PPD feature to work, it must be enabled for P-GW and S-GW.

Both P-GW and S-GW services apply PPD configuration independently. Therefore, for any downlink datapacket from an APN, there could be a case where P-GW does not have PPD configuration but S-GW has PPDconfiguration. To avoid such a conflict, you must configure the PPD functionality on both P-GW (APN levelgranularity) 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_nameapn apn_name

paging-policy-differentiationend

Enabling on S-GW

The following command enables the PPD feature on S-GW at service level.configure

context context_namesgw-service service_name

paging-policy-differentiationend

Notes:

• This is to send DSCP in Paging and Service Information IE of all the DDNmessages triggered by eitherIMS-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


no paging-policy-differentiationend

Disabling on S-GW

The following command disables the PPD feature on S-GW at service level.configure

context context_name



sgw-service service_nameno paging-policy-differentiationend

Monitoring and Troubleshooting Paging Policy DifferentiationThis section includes show commands in support of the PPD feature.

P-GW Show Commands

This section provides information regarding P-GW show commands and/or their outputs in support of thePPD feature.

show apn name <apn_name>The following counter has been added to display PPD functionality.Paging Policy Differentiation : Enabled

show subscribers pgw-only full allThe following counter has been added to display PPD functionality.Paging Policy Differentiation : Enabled

SAEGW Show Commands

This section provides information regarding SAEGW show commands and/or their outputs in support of thePPD feature.

show subscribers saegw-only full allThe following counter has been added to display PPD functionality.Paging Policy Differentiation : Enabled

S-GW Show Commands

This section provides information regarding S-GW show commands and/or their outputs in support of thePPD feature.

show sgw-service name <service_name>The following counter has been added to display PPD functionality.Paging Policy Differentiation : Enabled

Per QCI Packet Drop Counters and ARP Granularity for QCI Level CountersCSCux57081 - ARP granularity in sho APN stats & per QCI pkt drp cnts

Applicable Products: GGSN, P-GW, SAEGW

Feature DescriptionThis section describes the Per QCI Packet Drop Counters and ARPGranularity for QCI Level Counters feature.


P-GW Changes in Release 20Per QCI Packet Drop Counters and ARP Granularity for QCI Level Counters

Support for QCI and ARP Visibility

As of StarOS release 20.2, the software has been enhanced to support the viewing of QoS statistics on aQuality of Service Class Index (QCI) and Allocation and Retention Priority (ARP) basis.

ARP is a 3GPPmechanism for dropping or downgrading lower-priority bearers in situations where the networkbecomes congested. The network looks at the ARP when determining if new dedicated bearers can beestablished through the radio base station. QCI is an operator provisioned value that controls bearer levelpacket forwarding treatments.

This enhancement enables operators to monitor QoS statistics that identify multiple services running with thesame QCI value. In addition, packet drop counters have been introduced to provide the specific reason theEnhanced Charging Service (ECS) dropped a packet. The packet drop counters provide output on a per ARPbasis. This provides additional information that operators can use to troubleshoot and identify network issuesthat may be affecting service.

For the ARP value only the priority level value in the Allocation/Retention Priority (ARP) InformationElement (IE) is considered. Pre-emption Vulnerability (PVI) and Pre-emption Capability (PCI) flags inthe ARP IE are not considered.

Important

The existing show apn statistics name apn-name and show apn statistics Exec Mode CLI commands havebeen enhanced. The output of these commands now provides visibility for QoS statistics on a QCI/ARP basis.

Licensing

ARP Granularity for QCI Level Counters is a license-controlled feature. Per QCI Packet Drop Countersfunctionality does not require a license. Contact your Cisco account or support representative for licensingdetails.

Important

Configuring ARP Granularity for QCI Level CountersThis section describes how to configure the ARP Granularity for QCI Level Counters feature.

ARP Granularity for QCI Level Counters is a license-controlled feature. Per QCI Packet Drop Countersfunctionality does not require a license. Contact your Cisco account or support representative for licensingdetails.

Important

Configuring the feature consists of the following tasks:

1 Create a Stats Profile.

2 Enable the Collection of Per QCI Packet Drop Counters.

3 Enable the Collection of QCI/ARP Level Statistics.

4 Associate a Stats Profile with an APN.

5 Verify the Configuration.



Create a Stats Profile

Use the following example to access Global Configuration Mode and create a Stats Profile:configure

stats-profile stats_profile_nameend

Notes:

• stats_profile_name must be an alphanumeric string from 1 to 63 characters in length.

Enable the Collection of Packet Drop Statistics

Use the following example to access Stats Profile Configuration Mode and create a Stats Profile and enablethe collection of packet drop statistics:configure

stats-profile stats_profile_namepacket-dropend

To disable the collection of packet drop statisticsconfigure

stats-profile stats_profile_nameno packet-dropend

Notes:

• stats_profile_name must be the name of an existing Stats Profile. The name must be an alphanumericstring from 1 to 63 characters in length.

• packet-drop: enables the collection of packet drop statistics for the specified Stats Profile.

• no packet-drop: disables the collection of packet drop statistics for the specified Stats Profile.

Enable the Collection of QCI/ARP Level Statistics

Use the following example to access Stats Profile Configuration Mode and enable the collection of QCI/ARPlevel statistics for a Stats Profile:configure

stats-profile stats_profile_nameqci { all | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | [ non-std { non-gbr | gbr } ] } { arp { all | [ 1 | 2 | 3 | 4 | 5 | 6 |

7 | 8 | 9 | 10 | 11 |12 | 13 | 14 | 15 ] + } }end

To disable the collection of QCI/ARP statistics:configure

stats-profile stats_profile_nameno qci { all | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | [ non-std { non-gbr | gbr } ] } { arp { all | [ 1 | 2 | 3 | 4 | 5 | 6 | 7

| 8 | 9 | 10 | 11 |12 | 13 | 14 | 15 ] + } }end

Notes:

• stats_proflle_name must be the name of an existing Stats Profile. The name must be an alphanumericstring from 1 to 64 characters in length.



• qci: configures the collection of ARP priority level statistics for the specified QCI(s).

• non-std: configures the collection of ARP priority level statistics for non-standard QCIs.

• non-gbr: configures the collection of ARP priority level statistics for non-standard non-guaranteed bitrate (GBR) QCIs.

• gbr: configures the collection of ARP priority level statistics for non-standard GBR QCIs.

• arp: configures the collection of ARP priority level statistics for the specified ARP values.

• no: disables the collection of ARP priority level statistics for the specified qci and arp settings.

Associate a Stats Profile with an APN

Use the following example to access APN Configuration Mode and associate a Stats Profile with an APN:configure

apn apn_namestats-profile stats_profile_nameend

To disassociate a Stats Profile from a specified APN:configure

apn apn_nameno stats-profileend

Notes:

• stats_profile_name: must be the name of an existing Stats Profile. The name must be an alphanumericstring from 1 to 63 characters in length.

• A maximum of 64 Stats Profiles can be configured per P-GW/SAEGW/GGSN service.

• no stats-profile: disassociates the Stats Profile from the APN.

If a Stats Profile is associated with more than 12 APNs, the following memory and performance impactwarning is provided:[WARNING] Configuring QCI/ ARP level statistics for more then 12 APNs will havememory and performance impact. Do you want to continue [Y/N]

Important

Verify the Configuration

Use the following procedure to verify the configuration:

First, verify that the Stats Profile is associated with the correct APN. In Exec Mode, enter the followingcommand:

show apn name apn_nameNotes:

• In the command output, look for the stats profile field. It should contain the name of the Stats Profilewhich is associated with this APN.



Next, verify that the Stats Profile configuration settings are correct. InExecMode, enter the following command:

show stats-profile name stats_profile_nameNotes:

•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 StatsProfile with the proper settings.

Monitoring Per QCI Packet Drop Counters and ARP Granularity for QCI Level CountersThis section describes how to monitor the Per QCI Packet Drop Counters and ARP Granularity for QCI LevelCounters feature.

Show Commands

This section provides the Exec Mode show commands that are available to support the Per Packet QCI DropCounters and ARP Granularity for QCI Level Counters feature.

show apn statisticsThe qci and arp keywords have been added to this command. The new keywords enable operators to viewoutput for four basic scenarios that apply to the Per QCI Packet Drop Counters and ARP Granularity for QCILevel Counters feature.

Scenario 1

View packet drop counters with granularity at the QCI/ARP level for a single APN. The output of this commandis useful for isolating network issues that may be affecting packet drops.

show apn statistics name apn_name 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 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:











Scenario 3

View the new packet drop counters at granularity of QCI level, and pre-existing QCI level counters for thespecified APN.

show apn statistics name apn_name qci { all | 1-9 | non-std { gbr | non-gbr } }Notes:











Scenario 4

View the packet drop counters at the granularity of the QCI level, and view pre-existing QCI countersconsolidated for all APNs.show apn statistics qci { all | 1-9 | non-std { gbr | non-gbr } }Notes:













The output of the show apn statistics name apn_name qci all arp all command has been enhanced to displaythe following new statistics:Data Statistics:

Uplink Bytes: 0 Downlink Bytes: 0Uplink Pkts: 0 Downlink Pkts: 0Uplink Bytes dropped: 0 Downlink Bytes dropped: 0Uplink Pkts dropped: 0 Downnlink Pkts dropped: 0

Uplink Dropped: Downlink Dropped:MBR Exceeded(Bytes): 0 MBR Exceeded(Bytes): 0MBR Exceeded(Pkts): 0 MBR Exceeded(Pkts): 0AMBR Exceeded(Bytes): 0 AMBR Exceeded(Bytes): 0AMBR Exceeded(Pkts): 0 AMBR Exceeded(Pkts): 0Miscellaneous(Bytes): 0 Miscellaneous(Bytes): 0Miscellaneous(Pkts): 0 Miscellaneous(Pkts): 0Overcharge Prtctn(Bytes) 0 Overcharge Prtctn(Bytes): 0Overcharge Prtctn(Pkts): 0 Overcharge Prtctn(Pkts): 0SGW Restoration(Bytes): 0 SGW Restoration(Bytes): 0SGW Restoration(Pkts): 0 SGW Restoration(Pkts): 0SDF Gate(Bytes): 0 SDF Gate(Bytes): 0SDF Gate(Pkts): 0 SDF Gate(Pkts): 0ITC Gate(Bytes): 0 ITC Gate(Bytes): 0ITC Gate(Pkts): 0 ITC Gate(Pkts): 0Flow Terminated(Bytes): 0 Flow Terminated(Bytes): 0Flow Terminated(Pkts): 0 Flow Terminated(Pkts): 0Subsession Terminated(Bytes): 0 Subsession Terminated(Bytes): 0Subsession Terminated(Pkts): 0 Subsession Terminated(Pkts): 0Call Terminated(Bytes): 0 Call Terminated(Bytes): 0Call Terminated(Pkts): 0 Call Terminated(Pkts): 0DCCA Discard(Bytes): 0 DCCA Discard(Bytes): 0DCCA Discard(Pkts): 0 DCCA Discard(Pkts): 0No Rule Match(Bytes): 0 No Rule Match(Bytes): 0No Rule Match(Pkts): 0 No Rule Match(Pkts): 0ICAP(Bytes): 0 ICAP(Bytes): N/AICAP(Pkts): 0 ICAP(Pkts): N/ASFW(Bytes): 0 SFW(Bytes): 0SFW(Pkts): 0 SFW(Pkts): 0Hierarchical ENF(Bytes): 0 Hierarchical ENF(Bytes): 0Hierarchical ENF(Pkts): 0 Hierarchical ENF(Pkts): 0Dynamic CA Gate(Bytes): 0 Dynamic CA Gate(Bytes): : 0Dynamic CA Gate(Pkts): 0 Dynamic CA Gate(Pkts): 0NAT64 Cancel(Bytes): 0 NAT64 Cancel(Bytes): 0NAT64 Cancel(Pkts): 0 NAT64 Cancel(Pkts): 0Bearer Not Found(Bytes): 0 Bearer Not Found(Bytes): 0Bearer Not Found(Pkts): 0 Bearer Not Found(Pkts): 0



4G Bearers Released By Reasons:QCI1 QCI2 QCI3 QCI4 QCI5 QCI6 QCI7 QCI8 QCI9

Admin disconnect: 0 0 0 0 0 0 0 0 0

ARP level distribution of 4G Bearer Released By Reasons:

Admin disconnect:QCI 1:

ARP 1: 0ARP 2: 0ARP 3: 0ARP 4: 0ARP 5: 0ARP 6: 0ARP 7: 0ARP 8: 0ARP 9: 0ARP 10: 0ARP 11: 0ARP 12: 0ARP 13: 0ARP 14: 0ARP 15: 0

.

.

.

QCI 9:ARP 1: 0ARP 2: 0ARP 3: 0ARP 4: 0ARP 5: 0ARP 6: 0ARP 7: 0ARP 8: 0ARP 9: 0ARP 10: 0ARP 11: 0ARP 12: 0ARP 13: 0ARP 14: 0ARP 15: 0

Subscriber QoS Statistics:

4G Bearers Released By Reasons:QCI1 QCI2 QCI3 QCI4 QCI5 QCI6 QCI7 QCI8 QCI9

Admin disconnect: 0 0 0 0 0 0 0 0 0

ARP level distribution of 4G Bearer Released By Reasons:

Admin disconnect:QCI 1:

ARP 1: 0ARP 2: 0ARP 3: 0ARP 4: 0ARP 5: 0ARP 6: 0ARP 7: 0ARP 8: 0ARP 9: 0ARP 10: 0ARP 11: 0ARP 12: 0



ARP 13: 0ARP 14: 0ARP 15: 0

.

.

.

QCI 9:ARP 1: 0ARP 2: 0ARP 3: 0ARP 4: 0ARP 5: 0ARP 6: 0ARP 7: 0ARP 8: 0ARP 9: 0ARP 10: 0ARP 11: 0ARP 12: 0ARP 13: 0ARP 14: 0ARP 15: 0

QCI 1:ARP 1:Bearer Active: 0 Bearer setup: 2Bearer Released: 2 Bearer Rejected: 0

Uplink Bytes forwarded: 0 Downlink Bytes forwarded: 0Uplink Pkts forwarded: 0 Downlink Pkts forwarded: 0Uplink Bytes dropped: 0 Downlink Bytes dropped: 0Uplink Pkts dropped: 0 Downlink Pkts dropped: 0


QCI 1:ARP 2:Bearer Active: 0 Bearer setup: 2



Bearer Released: 2 Bearer Rejected: 0



The output of the show apn statistics name apn_name qci all command has been enhanced to display thefollowing new statistics:Data Statistics:

Uplink Bytes: 0 Downlink Bytes: 0Uplink Pkts: 0 Downlink Pkts: 0Uplink Bytes dropped: 0 Downlink Bytes dropped: 0Uplink Pkts dropped: 0 Downnlink Pkts dropped: 0

Uplink Dropped: Downlink Dropped:MBR Exceeded(Bytes): 0 MBR Exceeded(Bytes): 0MBR Exceeded(Pkts): 0 MBR Exceeded(Pkts): 0AMBR Exceeded(Bytes): 0 AMBR Exceeded(Bytes): 0AMBR Exceeded(Pkts): 0 AMBR Exceeded(Pkts): 0Miscellaneous(Bytes): 0 Miscellaneous(Bytes): 0Miscellaneous(Pkts): 0 Miscellaneous(Pkts): 0Overcharge Prtctn(Bytes) 0 Overcharge Prtctn(Bytes): 0Overcharge Prtctn(Pkts): 0 Overcharge Prtctn(Pkts): 0SGW Restoration(Bytes): 0 SGW Restoration(Bytes): 0SGW Restoration(Pkts): 0 SGW Restoration(Pkts): 0SDF Gate(Bytes): 0 SDF Gate(Bytes): 0SDF Gate(Pkts): 0 SDF Gate(Pkts): 0ITC Gate(Bytes): 0 ITC Gate(Bytes): 0ITC Gate(Pkts): 0 ITC Gate(Pkts): 0Flow Terminated(Bytes): 0 Flow Terminated(Bytes): 0Flow Terminated(Pkts): 0 Flow Terminated(Pkts): 0Subsession Terminated(Bytes): 0 Subsession Terminated(Bytes): 0Subsession Terminated(Pkts): 0 Subsession Terminated(Pkts): 0



Call Terminated(Bytes): 0 Call Terminated(Bytes): 0Call Terminated(Pkts): 0 Call Terminated(Pkts): 0DCCA Discard(Bytes): 0 DCCA Discard(Bytes): 0DCCA Discard(Pkts): 0 DCCA Discard(Pkts): 0No Rule Match(Bytes): 0 No Rule Match(Bytes): 0No Rule Match(Pkts): 0 No Rule Match(Pkts): 0ICAP(Bytes): 0 ICAP(Bytes): N/AICAP(Pkts): 0 ICAP(Pkts): N/ASFW(Bytes): 0 SFW(Bytes): 0SFW(Pkts): 0 SFW(Pkts): 0Hierarchical ENF(Bytes): 0 Hierarchical ENF(Bytes): 0Hierarchical ENF(Pkts): 0 Hierarchical ENF(Pkts): 0Dynamic CA Gate(Bytes): 0 Dynamic CA Gate(Bytes): : 0Dynamic CA Gate(Pkts): 0 Dynamic CA Gate(Pkts): 0NAT64 Cancel(Bytes): 0 NAT64 Cancel(Bytes): 0NAT64 Cancel(Pkts): 0 NAT64 Cancel(Pkts): 0Bearer Not Found(Bytes): 0 Bearer Not Found(Bytes): 0Bearer Not Found(Pkts): 0 Bearer Not Found(Pkts): 0

4G Bearers Released By Reasons:

QCI1 QCI2 QCI3 QCI4 QCI5 QCI6 QCI7 QCI8 QCI9Admin disconnect: 0 0 0 0 0 0 0 0 0

Subscriber QoS Statistics:

QCI 1:Bearer Active: 0 Bearer setup: 0Bearer Released: 0 Bearer Rejected: 0





.

.

.QCI 9:

Bearer Active: 0 Bearer setup: 0Bearer Released: 0 Bearer Rejected: 0

Uplink Bytes forwarded: 0 Downlink Bytes forwarded: 0Uplink Pkts forwarded: 0 Downlink Pkts forwarded: 0Uplink Bytes dropped: 0 Downlink Bytes dropped: 0Uplink Pkts dropped: 0 Downlink Pkts dropped:

show configurationThe 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)

show stats-profile nameThis new command in Exec Mode shows the configuration settings for the specified Stats Profile.

• Stats Profile Name: <stats_profile_name>

• qci <qci number> arp <arp_number(s)>

• packet-drop <if packet drop is enabled>

Statistics Added for Congestion Control Service Drop/RejectCSCva16278 - No drop counter available for congestion control pgw-service drop


Feature ChangesNew statistics introduced to show how many Create Session Request messages are dropped/rejected due tocongestion policy.

Congestion control is enabled through the congestion-control policy CLI command in Global ConfigurationMode.

Performance Indicator Changes

show egtpc statistics verbose

New fields introduced to show output of existing command to display how many Create Session Requestmessages are dropped/rejected due to congestion policy.EGTPC Buffered Packet Stats :Total Buffered Packets: 0Total DSReq buffered: 0Buffer DSReq retrans detected: 0Buffer DSReq dropped: 0Buffer DSReq scheduled: 0


P-GW Changes in Release 20Statistics Added for Congestion Control Service Drop/Reject

Buffer DSReq processed: 0Buffer DSReq dropped due to timeout: 0Total UBRsp buffered: 0Buffer UBRsp retrans detected: 0Buffer UBRsp dropped: 0Buffer UBRsp scheduled: 0Buffer UBRsp processed: 0Buffer UBRsp dropped due to timeout: 0Total CBRsp buffered: 0Buffer CBRsp retrans detected: 0Buffer CBRsp dropped: 0Buffer CBRsp scheduled: 0Buffer CBRsp processed: 0Buffer CBRsp dropped due to timeout: 0Total DBCmd buffered: 0Buffer DBCmd retrans detected: 0Buffer DBCmd dropped: 0Buffer DBCmd scheduled: 0Buffer DBCmd processed: 0Buffer DBCmd dropped due to timeout: 0

EGTPC Demux Recovery Stats :Total Demux Recovery ueid_rec not found: 0

Congestion Statistics:Total CS Req Discarded: 0 Total CS Rejected: 0

Support for One Million S1-U Peers on the S-GWCSCux62892 - ASR5500 enhancement to support 1M GTP-U peers


Feature DescriptionDue to production forecasts, support has been added to the StarOS for one million S1-U connections on asingle S-GW.

The S1-U interface is the user plane interface carrying user data between an eNodeB and an S-GW receivedfrom the terminal. The StarOS now has the capability to scale the number of S1-U peers to one million perVPN 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 WorksThe gtpumgr uses the following guidelines while allocating peers:

•When a session installation comes from the SessionManager, a peer is created. If statistics are maintainedat 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 peersper gtpumgr instance.

• If the limit of one million peers is exceeded, then peer creation fails. It causes a call installation failurein the gtpumgr, which leads to an audit failure if an audit is triggered.


P-GW Changes in Release 20Support for One Million S1-U Peers on the S-GW

The feature changes impact all the interfaces/services using the gtpu-service includingGGSN/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 configuredfor 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 thresholdis equal to or greater than the previous release. This way the GTPU peer statistics are preserved duringthe upgrade. For example, if you are upgrading from StarOS release 19.0 to 20.2, and the StarOS 19.0system has 17,000 GTPU sessions, then configure the threshold on the StarOS 20.2 system to 17,000as well.

Configuration and Restrictions

• Due to the large number of GTP-U entities connecting to the StarOS, Cisco recommends disabling theGTP-U Path Management feature.

• The configured threshold is not the hard upper limit for statistics allocation because of the distributednature of system. It is possible that total GTP-U peers with statistics exceeds the configured thresholdvalue to some extent.

• It is assumed that all 1 million peers are not connected to the node in a point-to-point manner. They areconnected through routers.

• There will not be any ARP table size change for the StarOS to support this feature.

Configuring the FeatureThis section describes how to configure support for the One Million S1-U Peer Connections feature.

gtpu peer statistics threshold

This new command has been added to Context Configuration Mode to specify the number of S1-U peers forwhich the StarOS will maintain statistics.

Use the following example to configure the feature:configure



P-GW Changes in Release 20Support for One Million S1-U Peers on the S-GW

gtpu peer statistics threshold valueend

Notes :

• value represents the number of S1-U peers for which statistics will be maintained. Valid entries are from16000 to 128000. The default setting is 16000.

• The threshold cannot be configured to a lower value than the current value.

Show Command OutputThis section describes the show command output changes made to support the OneMillion S1-U Peers feature.

clear gtpu statistics peer-address

The all keyword has been added to this command to enable operators to clear statistics for all S1-U peers forwhich statistics are being maintained.clear gtpu statistics peer-address all

show gtpu statistics

The output of this command has been enhanced to show the total number of GTPU peers, and the total numberof GTPU peers configured for statistics collection.

• Total GTPU Peers:

• Total GTPU Peers with stats:

show session subsystem facility sessmgr

The output of this command has been enhanced to provide the total number of S1-U (GTP-U) peers that areconfigured for statistics collection.

• Total Gtpu Peers with stats

Unexpected Disconnection Rate in 'clear subscribers pace-out-interval'CSCuz68210 - Unexpected disconnection rate in "clear subscribers pace-out-interval"


Feature Changes

All calls are put under paced-out queue when clear subscribers all pace-out-interval <seconds> commandis executed.

Previous Behavior:When clear subscribers all pace-out-interval<seconds> command was executed, callswere put on paced-out queue only if dropping-callline-credit was crossed.

Each session manager (SessMgr) maintains dropping-callline-credits. When deleting any session, ifdropping-callline-wait-queue number was lesser than the credit, the call was deleted immediately instead ofpaced-drop.


P-GW Changes in Release 20Unexpected Disconnection Rate in 'clear subscribers pace-out-interval'

New Behavior: Now, when clear subscribers all pace-out-interval <seconds> command is executed, callsare put on paced-out queue irrespective of dropping-callline-credits per SessMgr.

Customer Impact: Unexpected initial burst/disconnection rate avoided.

Virtual APN SelectionCSCux54953 - Virtual APN selection based on combinations up to any 5 parameters.

CSCux57226 - add support for virtual APN selection based on serving network PLMN.


Feature ChangesEach "virtual" APN is a reference, or a link, to an alternate APN configured on the system. Each reference isconfigured with a rule that subscriber PDP contexts or PDN connections are compared against and a prioritythat dictates the comparison order.

Previous Behavior: Configure virtual APN selection rules based on one (or sometimes two) criteria fromavailable criteria at a time. Selection based on multiple criteria in a single virtual APN preference rule wasnot possible.

New Behavior: Virtual APN selection can now be done using all possible combinations of available criteriain a single virtual APN preference rule.

New criteria serv-gw-plmnid has also been added to virtual-apn preference CLI command. This keywordadds support for virtual APN selection based on serving network PLMN ID.

Customer Impact: Allowing combinations in virtual APN selection will help give more flexible networkdesign and deployment options in the field.

Restrictions/Limitations

• If the same option is provided multiple times in the same rule, then later option value is considered forselection.

• New configuration with multiple options for virtual APN selection cannot be applied to older StarOSbuilds without this feature support. Therefore, you must keep separate copy of the older configuration(without multiple options selected) for older StarOS builds.

• To modify an existing virtual APN rule, remove the current rule first and wait for atleast 2 seconds, andthen add a new rule with modified parameters at that same preference. This ensures that rules get appliedappropriately and virtual APN selection happens correctly.

This limitation is applicable only when you want to delete and add a new rule at thesame preference.

Important

• A maximum of 2048 virtual APN rules can be added across all APNs.


P-GW Changes in Release 20Virtual APN Selection

Command Changes

virtual-apn preference

The new serv-gw-plmnid keyword adds support for virtual APN selection based on serving network PLMNID.configure


virtual-apn preference priority apn apn_name [ IPv4 { ip_address | ipv4_address/mask } ] [ IPv6ipv6_address | ipv6_address/mask } ] [ bearer-access-service service_name ] [ cc-behavior cc_behavior_value] [ cc-profile cc_profile_index [ pre-rel-9.1-cc-behavior cc_behavior_value ] ] [ domain domain_name ] [mcc mcc_numbermnc mnc_number [ msin-range from msin_range_from to msin_range_to ] ] [msisdn-range frommsisdn_start_range tomsisdn_to_range ] [ pdp-type { ipv4 | ipv6 | ipv4v6 } ] [ rat-type{ eutran | gan | geran | hspa | utran | wlan } ] [ roaming-mode { home | roaming | visiting } ] [serv-gw-plmnid mccmcc_numbermnc mnc_number ] +

endNotes:

• +: Keywords can now be repeated or combined as needed in a single virtual-apn preference rule.


show subscribers pgw-only full all

The following output fields in this existing command show selected APNs:

• S5/S8/S2b/S2a-APN

• SGi-APN

P-GW Enhancements for 20.1This section identifies all of the P-GW enhancements included in this release:





P-GW Changes in Release 20P-GW Enhancements for 20.1


Important


• CF Enhancements







Release 20.0 introduces a number of security enhancements whichmay affect existing system deployments.Refer to the System Changes chapter in this guide for detailed information.

Important

P-GW to Initiate CRA IE in UBReq ImmediatelyCSCuy95645 - PGW to initiate CRA IE in UBReq immediately


Feature ChangesFor activating location reporting for a UE over Gx, RAR from PCRF was sent with the event trigger"USER_LOCATION_CHANGE". On receiving this event trigger, P-GW should typically send CRA IE with"Start Reporting " towards the MME to enable the Location-Change reporting for the UE in an MME.

Earlier, P-GWwas not initiating Update Bearer Request procedure explicitly to inform only CRA IE and wasrelying on any other procedure like QoS change happening at same time or in future. This resulted in delayin updating required action at the MME. After this feature change, P-GW would immediately initiate UpdateBearer Request, even for updating only CRA IE, if there are no other changes detected in RAR received withULI_LOCATION_CHANGE event trigger. If there are other changes detected in RAR, CRA IE would becombined with Update Bearer Request initiated for the same.

Previous Behavior: Earlier, P-GW initiated update Bearer procedure was not triggered when the ULI eventtrigger was received from a RAR than a CCA-U.

New Behavior: Now, P-GW initiated update bearer procedure for CRA IE is triggered, if RAR is receivedwith the ULI trigger.


P-GW Changes in Release 20P-GW to Initiate CRA IE in UBReq Immediately

SPGW Incorrectly Sending UDPv6 PacketsCSCuy78988- SPGW incorrectly sending UDPv6 packets with 0x0 checksum against RFC2460


Feature ChangesPrevious Behavior: Earlier, if the result of the UDPv6 checksum calculation is zero, GW used to send thesame, which effectively disables checksum for that packet. This was not compliant with the RFC2460, whichsuggests the checksum value to be set to 0xFFFF if derived calculation is zero.

NewBehavior: After the fix, the checksum value is set to 0xFFFF if the result checksum calculation is ZEROand the compliance is met.

Impact on customer: Packet drops might be seen at peer, which does not support of handling packet with0xFFFF checksum as suggested by the RFC.

P-GW Enhancements for 20.0This section identifies all of the P-GW enhancements included in this release:





Important


• CF Enhancements








P-GW Changes in Release 20SPGW Incorrectly Sending UDPv6 Packets

Release 20.0 introduces a number of security enhancements whichmay affect existing system deployments.Refer to the System Changes chapter in this guide for detailed information.

Important

Call Drops When S-GW Restoration is Detected During Handover from WiFito LTE

CSCuy16612 - Assert @sess/egtp/egtpu/egtpu_session.c: 1234


Feature Changes

Previous Behavior:Unexpected system reload was seen when S-GW restoration is detected during handoverfrom WiFi to LTE (when Handoff MBRequest is pending).

New Behavior:Call is dropped when S-GW restoration is detected during handover fromWiFi to LTE (whenHandoff MBRequest is pending).

Customer Impact: Unexpected system reload will not be seen when S-GW restoration is detected duringhandover from WiFi to LTE (when Handoff MBRequest is pending).

Change in Disconnect Reason for IPv6 Call for P-GWCSCuv81230 - Inconsistent behavior between v4 and v6 IP allocation rsp.


Feature Changes

Previous Behavior: When the CLI command busyout ipv6 pool all-dynamic was enabled, any IPv6 callwould be rejected with cause "No Resources Available."

New Behavior: When the CLI command busyout ipv6 pool all-dynamic is enabled, now any IPv6 call isrejected with cause "All Dynamic Addresses Occupied."

Customer Impact: Change in disconnect reason and its related statistics at P-GW.

Generate SNMP Traps When Setup Failure Thresholds Are CrossedCSCuw19140, CSCuv87109 - Threshold support for SM failure stats - application changesApplicable Products: ePDG, P-GW, SAEGW

Related ID: CSCuw39298 - Detection and Reporting of eHRPD Call Setup Failures

Feature ChangesTraps are now generated on certain thresholds for call setup failures for LTE calls. Detecting call failure setupsis needed so that subscriber impact can be addressed quickly.


P-GW Changes in Release 20Call Drops When S-GW Restoration is Detected During Handover from WiFi to LTE

With this feature, call failure rate at MAG and LMA for eHRPD sessions is also supported. Whenever thereare call setup failures per service, regardless of the root cause (on ASR 5x00 or external), the Operator willbe alerted about the increased fail rate by a generated trap.

SNMP traps are generated based on call failure rate. P-GW will use the formula below for detecting CreateSession Response failure rates. This failure rate is calculated based on statistics collected during a configuredpolling interval. This calculated failure rate is then validated against the configured threshold. Based onthreshold and actual failure rate calculation, alarms will be generated or cleared.

The failure rate is the percentage of failures as determined by this formula: 1 - (Create Session ResponseAccept / Create Session Request).

Create Session Response Accept and Create Session Request counters will be collected in similar ways as forCLI show egtpc statistics, but differentiated for S5 and S2b interface based on interface type.

This feature is supported per service.

Command Changes

threshold monitoring

Use this existing command to enable monitoring for the new thresholds egtpc-s2b-setup-fail-rate andegtpc-s5-setup-fail-rate.configure

threshold monitoring call-setupend

threshold egtpc-s2b-setup-fail-rate

This new CLI command configures the call setup failure threshold parameter for an S2b interface.configure

threshold egtpc-s2b-setup-fail-rate high_thresh [ clear low_thresh ]default threshold egtpc-s2b-setup-fail-rateend

Notes:

• default: Configures this command with the default threshold settings.

• high_thresh: Specifies the high threshold number of call setup failures that must be met or exceededwithin the polling interval to generate an alert or alarm.Must be an integer from 0 to 100.

A value of 0 disables the threshold.

• clear low_thresh: Specifies the low threshold number of call setup failures that maintains a previouslygenerated alarm condition. If the number of call setup failures falls beneath the low threshold within thepolling interval, a clear alarm will be generated.

low_thresh must be an integer from 0 to 100 that must be lower than high_thresh.



P-GW Changes in Release 20Generate SNMP Traps When Setup Failure Thresholds Are Crossed

threshold egtpc-s5-setup-fail-rate

This new CLI command configures the call setup failure threshold parameter for an S5 interface.configure

threshold egtpc-s5-setup-fail-rate high_thresh [ clear low_thresh ]default threshold egtpc-s5-setup-fail-rateend

Notes:

• default: Configures this command with the default threshold settings.

• high_thresh: Specifies the high threshold number of call setup failures that must be met or exceededwithin the polling interval to generate an alert or alarm. Must be an integer from 0 to 100.


• clear low_thresh: Specifies the low threshold number of call setup failures that maintains a previouslygenerated alarm condition. If the number of call setup failures falls beneath the low threshold within thepolling interval, a clear alarm will be generated.

low_thresh must be an integer from 0 to 100 that must be lower than high_thresh.


threshold poll egtpc-s2b-setup-fail-rate

This new command configures the polling interval for eGTP-C S2b call setup failure.configure

threshold poll egtpc-s2b-setup-fail-rate interval durationdefault threshold poll egtpc-s2b-setup-fail-rate intervalend

Notes:

• Default: 900 secondsSpecifies the amount of time (in seconds) that comprises the polling interval. Must be an integer from300 to 60000.

• All configured polling intervals are rounded up to the closest multiple of 30. For example, if a pollinginterval is configured for 130 seconds, the system uses a polling interval of 150 seconds.

• To enable an SNMP trap for monitoring this threshold, use the threshold monitoring call-setupcommand.

threshold poll egtpc-s5-setup-fail-rate

This new command configures the polling interval for eGTP-C S5 call setup failure.configure

threshold poll egtpc-s5-setup-fail-rate interval durationdefault threshold poll egtpc-s5-setup-fail-rate intervalend

Notes:

• Default: 900 seconds



Specifies the amount of time (in seconds) that comprises the polling interval. Must be an integer from300 to 60000.

• All configured polling intervals are rounded up to the closest multiple of 30. For example, if a pollinginterval is configured for 130 seconds, the system uses a polling interval of 150 seconds.

• To enable an SNMP trap for monitoring this threshold, use the threshold monitoring call-setupcommand.


show alarm outstanding all

This command displays the following output:MN Chassis <102:egtpc-s5-setup-fail-rate> has reached or exceeded the configured threshold<10%>, the measured value is <25%>. It is detected at <System>.MN Chassis <105:egtpc-s2b-setup-fail-rate> has reached or exceeded the configured threshold<10%>, the measured value is <50%>. It is detected at <System>.

show snmp trap history

This command displays the following output:Wed Nov 04 23:35:00 2015 Internaltrap notification 1312 (EGTPCS5SetupFailRate) threshold 10%measured value 25%Wed Nov 04 23:35:00 2015 Internaltrap notification 1318 (EGTPCS2BSetupFailRate) threshold 10%measured value 50%Wed Nov 04 23:50:00 2015 Internaltrap notification 1313 (EGTPCS5SetupFailRateClear) threshold 5%measured value 0%Wed Nov 04 23:50:00 2015 Internaltrap notification 1319 (EGTPCS2BSetupFailRateClear) threshold 5%measured value 0%Note: SNMP Trap Severity1312 #SEVERITY WARNING1313 #SEVERITY INFORMATIONAL1318 #SEVERITY WARNING1319 #SEVERITY INFORMATIONAL

show threshold

This command displays the following output:

Threshold operation model: ALARM

Configured thresholds:

Name: egtpc-s5-setup-fail-rateConfig Scope: SYSTEMThreshold: 10%Clear Threshold: 5%

Name: egtpc-s2b-setup-fail-rateConfig Scope: SYSTEMThreshold: 10%Clear Threshold: 5%

Active thresholds:Name: egtpc-s5-setup-fail-rateConfig Scope: SYSTEM



Threshold: 10%Clear Threshold: 5%Poll Interval: 300SecondsNext Poll Time: 2015-Nov-04+23:50:00

Name: egtpc-s2b-setup-fail-rateConfig Scope: SYSTEMThreshold: 10%Clear Threshold: 5%Poll Interval: 300SecondsNext Poll Time: 2015-Nov-04+23:50:00

Enabled threshold groups: (name,scope)call-setup SYSTEM

Non-default poll intervals:egtpc-s5-setup-fail-rate 300Secegtpc-s2b-setup-fail-rate 300Sec

Outstanding alarms:Threshold Name:egtpc-s5-setup-fail-rateAlarm Source: SystemLast Measured: 25%Raise Time: 2015-Nov-04+23:35:00

Threshold Name:egtpc-s2b-setup-fail-rateAlarm Source: SystemLast Measured: 50%Raise Time: 2015-Nov-04+23:35:00

GGSN Service Associated with Multiple P-GW ServicesCSCuv29195 - GGSN service associated with multiple PGW services

Applicable Products: GGSN, P-GW (GnGp configuration)

Feature Changes

Previous Behavior:When a GGSN /P-GW service is associated with one P-GW/GGSN service, any furtherattempt to associate the same GGSN/P-GW service with another P-GW/GGSN service allowed. Multipleassignments are allowed.

New Behavior:When a GGSN /P-GW service is associated with one P-GW/GGSN service, any furtherattempt to associate the sameGGSN/P-GW service with another P-GW/GGSN service shows a correspondingerror on CLI prompt. Multiple assignments are not allowed.

GGSN UPC Collision Handling

Feature DescriptionIn StarOS 14.0 and earlier, during collision between SGSN initiated UPC request and GGSN Initiated UPCrequest, 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 atGGSN 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. Duringcollision between SGSN initiated UPC request and GGSN initiated UPCRequest, SGSN initiated UPC request


P-GW Changes in Release 20GGSN Service Associated with Multiple P-GW Services

gets higher priority over NRUPC and there is no call or data loss during call establishment or during mid-callphase. This feature can be enabled or disabled using a CLI and is enabled by default.

How It WorksIn StarOS release 14.0 and earlier:

• Predefined rules were activated at GGSNwithout 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 atGGSN and were not activated in case of collision. There was no static catch-all rule defined in rulebase. Thiscaused packet drops.

In StarOS 20.0, the GGSN UPC Collision Handling feature addresses the problem of packet drops. Duringcollision between SGSN initiated UPC request and GGSN initiated UPCRequest, SGSN initiated UPC requestgets higher priority over NRUPC and there is no call or data loss during call establishment or during mid-callphase. 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 PDPcontext, NRUPC is retried (with different sequence number) after sending UPC Response.

•WhenGGSN detects collision between SGSN initiated UPC request for Inter-SGSN handoff and NRUPCwith TFT and after handoff BCM mode is changed from Mixed mode to MS-Only mode, NRUPC isretried (with different sequence number) after sending UPC Response, but without TFT.

•WhenGGSN 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, PCRFwill not be aware of this aborted transaction (rule failure).

Limitations• Behavior for GnGpGGSN has beenmodified for this feature, in this release. Behavior for GGSN remainsunaltered.

•When NRUPC received from Direct Tunnel (due to "Direct Tunnel Error Indication") collides withSGSN initiated UPC request, NRUPC is aborted and not retried. This does not affect the functionalityas, 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 remainsunchanged. In this case, the pending NRUPC request is aborted. If the NRUPC request received is forrule installation, the request remains in the pending state and the rule is not installed. As there is no staticrule and the rule installation request is in pending state, the PDP context stays up without an installedrule.


P-GW Changes in Release 20GGSN UPC Collision Handling

Configuring GGSN UPC Collision HandlingOperators can use the Command Line Interface (CLI) to configure the collision between SGSN initiated UPCrequest and network initiated UPC Request.

gtpc handle-collision

This command in the service configuration mode can be used to the collision between SGSN initiated UPCrequest and network initiated UPC Request.

GGSN Serviceconfigure

context context_nameggsn-service service_name

[ no | default ] gtpc handle-collision upc nrupcend

P-GW Serviceconfigure

context context_namepgw-service service_name


S-GW Serviceconfigure

context context_namesgw-service service_name


SAEGW Serviceconfigure

context context_namesaegw-service service_name


Notes:

• no: Disables collision handling between SGSN initiated UPC and NRUPC request.

• default: Sets default collision handling behavior between SGSN initiated UPC and NRUPC request.By default, collision handling is enabled.

• handle-collision upc nrupc: Enables/Disables collision handling between SGSN initiated UPC andnetwork requested UPC. By default, collision handling is enabled.


The configuration of this feature can be verified using the following commands from the exec mode:

• show configuration

• show configuration verbose



Please see theMonitoring and Troubleshooting GGSN UPC Collision Handling section for the commandoutput.

Monitoring and Troubleshooting GGSN UPC Collision HandlingThe following section describes commands available to monitor GGSN UPC Collision Handling.

Show Commands for GGSN UPC Collision Handling

show configurationThis command displays the following output:

ggsn-service ggsn-serviceassociate gtpu-service gtpu-serviceassociate pgw-service pgw_serviceassociate peer-map map_ggsn

no gtpc handle-collision upc nrupc

show configuration verboseThis command displays the following output:

ggsn-service ggsn-serviceassociate gtpu-service gtpu-serviceassociate pgw-service pgw_serviceassociate peer-map map_ggsn

no gtpc handle-collision upc nrupc

show ggsn-service name service_nameThis command displays the following output:

Service name: ggsn-serviceContext: ingress…Suppress NRUPC triggered by UPC: Disabled

Collision handling for UPC-NRUPC: Enabled/Disabled

show gtpc statisticsThis command displays the number of NRUPC and SGSN initiated UPC collisions happening for primaryand secondary PDP context for a GGSN service. This command displays the following output:Active Subscribers:Total: 12G: 03G: 1

……MS Info Change Reporting Messages:MS Info Chng Notif Req: 0 Accepted: 0Denied: 0 Discarded: 0

NRUPC UPC Collision:Primary PDP ctxt: 3 Secondary PDP ctxt: 0



QoS negotiation:CPC QoS Accepted: 3 CPC QoS Downgraded: 0UPC QoS Accepted: 3 UPC QoS Downgraded: 0

show gtpc statistics [ format1 | ggsn-service service_name | verbose ]This command displays the number of NRUPC and SGSN initiated UPC collisions happening for primaryand secondary PDP context for a GGSN service. This command displays the following output:Active Subscribers:Total: 12G: 03G: 1

……MS Info Change Reporting Messages:MS Info Chng Notif Req: 0 Accepted: 0Denied: 0 Discarded: 0

NRUPC UPC Collision:Primary PDP ctxt: 3 Secondary PDP ctxt: 0

QoS negotiation:CPC QoS Accepted: 3 CPC QoS Downgraded: 0UPC QoS Accepted: 3 UPC QoS Downgraded: 0

GTP-C Path Failure Enhancements and Improved Debugging ToolsCSCuw19376 - Path failure code cleanup & statistics


In StarOS release 20.0, enhancements have been added to optimize GTP-C path failure functionality, and toimprove the debug capability of the system for GTP-C path failure problems. These features will help Operatorsand Engineers to debug different aspects of the system that will help in identifying the root cause of GTP-Cpath failures in the network. These enhancements affect path failure detection via the S5, S8, S2b, and S2ainterfaces.

The following enhancements are added as part of this feature:

• The node can be configured so that it does not detect a path failure if a low restart counter is receiveddue to incorrect or spurious messages. This prevents call loss. The option to disable path failure due toEcho Request/Response and Control Message Request/Response messages is also available so that callloss is prevented in the event of a false path failure detection.

• More granularity has been added to GTP-C path failure statistics so that the root cause of issues in thenetwork can be diagnosed more quickly.

• A path failure history for the last five path failures per peer is available to assist in debugging pathfailures in the network.

• Seamless path failure handling is implemented so that call loss is avoided during redundancy events.

Support to Avoid False Path Failure Detection

Several enhancements have been made to facilitate the node's ability to avoid false path failure detection:


P-GW Changes in Release 20GTP-C Path Failure Enhancements and Improved Debugging Tools

• The software has been enhanced to avoid path failure detection due to spurious/incorrect messages froma peer. Thesemessages can cause a large burst in network traffic due to the number of service deactivationsand activations, resulting in network congestion. The gtpc command in eGTP-C Service ConfigurationMode has been enhanced to resolve this issue. Themax-remote-restart-counter-change keyword hasbeen added to ensure false path failure detections are not detected as GTP-C path failures. For example,if themax-remote-restart-counter-change is set to 10 and the current peer restart counter is 251, eGTPwill detect a peer restart only if the new restart counter is 252 through 255 or 0 through 5. Similarly, ifthe stored restart counter is 1, eGTP will detect a peer restart only if the new restart counter is 2 through11.

• Also as part of this enhancement, new keywords have been added to the path-failure detection-policycommand in eGTP-C Service Configuration Mode to enable or disable path failure detection.

• The show egtp-service all command has been enhanced to indicate whether Echo Request/EchoResponseRestart Counter Change and ControlMessage Restart Counter Change are enabled/disabled on the node.

Improved GTP-C Path Failure Statistics

Several improvements have been made to improve the quality of the GTP-C path failures so thatoperators/engineers can more quickly identify the cause of the failure.

• The output of the show egtpc statistics path-failure-reasons has been enhanced to show the numberand type of control message restart counter changes at the demuxmgr and sessmgr. This command outputhas also been enhanced to track the number of path failures detected that were ignored at the eGTP-Clayer.

• The show egtpc peers path-failure-history command output has been added to provide detailedinformation on the last five path failures per peer.

• The output of the show egtp-service all name and show configuration commands has been enhancedto show the current configuration settings specific to path GTP-C path failure detection policy.

Command Changes

gtpc

Themax-remote-restart-counter-change keyword has been added to the gtpc command in eGTP ServiceConfigurationMode. Configuring this keyword helps in avoiding path failure detection due to spurious/incorrectmessages from the peer.config

context context_nameegtp-service egtp_service_name

gtpc max-remote-restart-counter-change integerdefault gtpc max-remote-restart-counter-changeend

Where:

• max-remote-restart-counter-change integer is the counter change after which the P-GW will detecta peer restart. Note that a peer restart will be detected only if the absolute difference between the Newand old restart counters is less than the value configured. For example, if themax-remote-restart-counter-change is 10 and current peer restart counter is 251, then eGTPwill detecta peer restart only if the new restart counter is 252 through 255 or 0 through 5. Similarly, if the stored



restart counter is 1, eGTP will detect a peer restart only if the new restart counter is 2 through 11. Validsettings are from 1 to 255. The recommended setting is 32.

• default returns the setting to its default value of 255.

gtpc

The new echo-restart-counter-change and control-restart-counter-change keywords have been added asnew options for the detection policy keyword for the gtpc command in eGTP Service Configuration Mode.These keywords are used to enable/disable path failure detection policy.config

context context_nameegtp-service egtp_service_name

gtpc path-failure detection-policy { control-restart-counter-change | echo |echo-restart-counter-change }

{ default | no } gtpc path-failure detection policy [ control-restart-counter-change | echo |echo-restart-counter-change ]

endNotes:

• control-restart-counter-change: Enables path failure detection when the restart counter in ControlRequest/Control Response messages changes.

• echo-restart-counter-change: Enables path failure detection when the restart counter in EchoRequest/Echo Response messages changes.

• no: Disables the specified option.

• The default behavior for path failure detection is disabled.

show session disconnect-reasons

The pgw-only and sgw-only keywords have been added to this command to enable operators to view sessiondisconnect reasons specific to the P-GW and S-GW, respectively.show session disconnect-reasons [ pgw-only | sgw-only ]

Notes:

• The pgw-only keyword will provide output that reflects cumulative disconnect reasons specific to P-GW,SAEGW, and GGSN service calls. These include:

◦P-GW call

◦GGSN calls (for both a standalone GGSN service as well as a GGSN service associated with P-GWservice).

◦SAEGW calls that are P-GW-anchored

◦SAEGW calls that are GGSN-anchored

◦SAEGW calls that are co-located

• The sgw-only keyword will provide output that reflects cumulative disconnect reasons specific to S-GWcalls. S-GW calls include:



S-GW calls•

• SAEGW calls that are S-GW anchored only

• Use the existing clear session disconnect-reasons command in Exec Mode to clear the cumulativetotals for pgw-only and sgw-only disconnect reason statistics.


show configuration

The output of this command has been enhanced to provide the gtpc path-failure detection-policy configurationsetting.

For example, when gtpc path-failure detection-policy is enabled, operators would see one of the followinggtpc path-failure detection-policy settings:

• egtp-service egtp_service_name

◦gtpc path-failure detection-policy echo

◦gtpc path-failure detection-policy echo-restart-counter-change

◦gtpc path-failure detection-policy control-restart-counter-change

When gtpc path-failure detection-policy is disabled: operators would see one of the following gtpcpath-failure detection-policy settings:

• egtp-service egtp_service_name

• no gtpc path-failure detection-policy echo

• no gtpc path-failure detection-policy echo-restart-counter-change

• no gtpc path-failure detection-policy control-restart-counter-change

show egtpc peers

The path-failure-history keyword has been added to the show egtpc peers command. The output of thiscommand now includes detailed information on the last five path failures that occur per configured P-GWpeers. The enhanced output includes the following information for each configured peer:

• Peer Address

• Time of Path Failure

• Reason

• Event/Msg Type

• Old RC (Restart Counter)

• New RC (Restart Counter)

• Session Count



• IMSI

• Local TEID

• Remote TEID

• Path failure detection

show egtp-service { all | name <service_name> }

The output of this command has been enhanced to show the value configured via the gtpcmax-restart-counter-change command.

• Max Peer Restart Counter Change: <integer 1 to 255>

The output of this command has also been enhanced to indicate if path failure detection on Echo timeout,Echo Request/Response Restart Counter Change, or Control Message Restart Counter Change is enabled ordisabled.

• Echo Timeout < Enabled or Disabled>

• Echo Req/Rsp Restart Counter Change <Enabled or Disabled>

• Control Mesg Restart Counter Change <Enabled or Disabled>

show egtpc statistics

The path-failure-reasons keyword has been added to the show egtpc statistics command in Exec Mode. Useof this new keyword provides enhanced statistics related to:

• control message restart counter changes at the deumxmgr

• control message restart counter changes at the sessmgr

• reasons for path failure detections ignored at the egtpc layer

The specific path failure reasons added are:

• Control message restart counter change at demux:

◦Create Session Request:

◦Forward Relocation Request

◦MBMS Session Start Request

• Control message restart counter change at sessmgr:

◦Modify Bearer Request:

◦Create Session Response:

◦Modify Bearer Response:

◦Delete Session Response:

◦Delete Bearer Response:

◦Update Bearer Response:



◦Create Bearer Response:

◦Release Access Bearer Response:

◦Downlink Data Notification Acknowledge:

◦Delete Bearer Command Failure Indication:

◦Bearer Resource Command Failure Indication:

◦Modify Bearer Command Failure Indication:

◦Create Ind Data Forwarding Response:

◦Delete Ind Data Forwarding Response

◦Forward Relocation Complete Acknowledge:

◦MBMS Session Start Response:

◦MBMS Session Stop Response:

◦MBMS Session Update Response:

• Path failure detection ignored at EGTPC:

◦Echo Request/ Response restart counter change:

◦No Echo Response received:

◦Control message restart counter change:

◦Control Rsp message restart counter change:

GTP S5/S8, S2a, and S2b Interface Specific Bulkstats for P-GWCSCup36540 - GTP S5S8/S2a/S2b interface specific message,cause code & bulk stats


Feature ChangesSince P-GW anchors different GTPv2 based interfaces, such as S5/S8, S2a, and S2b, support has been addedto provide per-interface based GTP statistics and bulkstats.

Use of WiFi Integration functionality requires that a valid license key be installed. Contact your localSales or Support representative for information on how to obtain a license.

Important

With wider deployment of SP-WiFi networks and VoWiFi service, separate statistics on a per-GTP-interfacebasis will help Operators with analysis and debugging.


P-GW Changes in Release 20GTP S5/S8, S2a, and S2b Interface Specific Bulkstats for P-GW

If the first message from any peer is rejected/discarded, it won't be counted anywhere in the eGTP-Cinterface statistics.

Important

Command Changes

clear egtpc statistics

This command has been enhanced to clear statistics per the following eGTP-C sub-interfaces:

• S2a

• S2b

• S5/S8

The keywords s2a and s2b are only visible if WiFi Integration functionality is enabled. WiFi Integrationrequires that a valid license key be installed. Contact your local Sales or Support representative forinformation on how to obtain a license.

Important

clear egtpc statistics interface-type pgw-ingress interface { s2a | s2b | s5s8 }clear egtpc statistics egtp-service service_name interface-type { s2a | s2b | s5s8 }Notes:

• interface-type pgw-ingress interface { s2a | s2b | s5s8 }: Clears the eGTP-C interface statistics of aparticular sub-interface of P-GW ingress.

• egtp-service service_name interface-type { s2a | s2b | s5s8 }: Clears the eGTP-C sub-interface statisticsonly for the specified eGTP-C service.

• These commands do not clear all of the eGTP-C statistics, only the specified interface statistics.

show egtpc statistics

This command has been enhanced to display statistics per the following eGTP-C sub-interfaces:

• S2a

• S2b

• S5/S8

The keywords s2a and s2b are only visible if WiFi Integration functionality is enabled. WiFi Integrationrequires that a valid license key be installed. Contact your local Sales or Support representative forinformation on how to obtain a license.

Important

show egtpc statistics interface pgw-ingress interface-type { s2a | s2b | s5s8 } [ verbose ] [ | { grepgrep_options | more } ]



show egtpc statistics egtp-service service_name interface-type { s2a | s2b | s5s8 } [ verbose ] [ | { grepgrep_options | more } ]Notes:

• interface pgw-ingress interface-type { s2a | s2b | s5s8 }: Displays the eGTP-C interface statistics of aparticular sub-interface of P-GW ingress.

• egtp-service service_name interface-type { s2a | s2b | s5s8 }: Displays the eGTP-C sub-interfacestatistics only for the specified eGTP-C service.

• TX and RX counters have been optimized based on the applicable interface.

• verbose: All of the cause codes supported for GTPv2 are now displayed as part of this option. All thecause code values are shown for each of the messages.


P-GW Schema

The following counters have been added to collect GTP sub-interface data statistics:

• subdatastat-totulpktfwd-s5

• subdatastat-totdlpktfwd-s5

• subdatastat-totulbytefwd-s5

• subdatastat-totdlbytefwd-s5

• subdatastat-totulpktdrop-s5

• subdatastat-totdlpktdrop-s5

• subdatastat-totulbytedrop-s5

• subdatastat-totdlbytedrop-s5

• apnambrratelimit-uppktdrop-s5

• apnambrratelimit-downpktdrop-s5

• apnambrratelimit-upbytedrop-s5

• apnambrratelimit-downbytedrop-s5

• subdatastat-totulpktfwd-s8

• subdatastat-totdlpktfwd-s8

• subdatastat-totulbytefwd-s8

• subdatastat-totdlbytefwd-s8

• subdatastat-totulpktdrop-s8

• subdatastat-totdlpktdrop-s8

• subdatastat-totulbytedrop-s8

• subdatastat-totdlbytedrop-s8



• apnambrratelimit-uppktdrop-s8

• apnambrratelimit-downpktdrop-s8

• apnambrratelimit-upbytedrop-s8

• apnambrratelimit-downbytedrop-s8

• subdatastat-totulpktfwd-s2a

• subdatastat-totdlpktfwd-s2a

• subdatastat-totulbytefwd-s2a

• subdatastat-totdlbytefwd-s2a

• subdatastat-totulpktdrop-s2a

• subdatastat-totdlpktdrop-s2a

• subdatastat-totulbytedrop-s2a

• subdatastat-totdlbytedrop-s2a

• apnambrratelimit-uppktdrop-s2a

• apnambrratelimit-downpktdrop-s2a

• apnambrratelimit-upbytedrop-s2a

• apnambrratelimit-downbytedrop-s2a

• subdatastat-totulpktfwd-s2b

• subdatastat-totdlpktfwd-s2b

• subdatastat-totulbytefwd-s2b

• subdatastat-totdlbytefwd-s2b

• subdatastat-totulpktdrop-s2b

• subdatastat-totdlpktdrop-s2b

• subdatastat-totulbytedrop-s2b

• subdatastat-totdlbytedrop-s2b

• apnambrratelimit-uppktdrop-s2b

• apnambrratelimit-downpktdrop-s2b

• apnambrratelimit-upbytedrop-s2b

• apnambrratelimit-downbytedrop-s2b

pgw-egtpc-s2a Schema

This schema has been added to collect eGTP-C S2a interface statistics.




If WiFi Integration functionality is available, but S2a interface type is not configured for P-GW IngresseGTP service, all statistics will be displayed as zero.

Important

pgw-egtpc-s2b Schema

This schema has been added to collect eGTP-C S2b interface statistics.


If WiFi Integration functionality is available, but S2b interface type is not configured for P-GW ingresseGTP service, all statistics will be displayed as zero. This feature is currently only supported for P-GWingress interfaces.

Important

pgw-egtpc-s5s8 Schema

This schema has been added to collect eGTP-C S5/S8 interface statistics.

SAEGW Schema

The following counters have been added to collect eGTP-C interface statistics:

• pgw-subdatastat-totulpktfwd-s5

• pgw-subdatastat-totdlpktfwd-s5

• pgw-subdatastat-totulbytefwd-s5

• pgw-subdatastat-totdlbytefwd-s5

• pgw-subdatastat-totulpktdrop-s5

• pgw-subdatastat-totdlpktdrop-s5

• pgw-subdatastat-totulbytedrop-s5

• pgw-subdatastat-totdlbytedrop-s5

• pgw-apnambrratelimit-uppktdrop-s5

• pgw-apnambrratelimit-downpktdrop-s5

• pgw-apnambrratelimit-upbytedrop-s5

• pgw-apnambrratelimit-downbytedrop-s5

• pgw-subdatastat-totulpktfwd-s8

• pgw-subdatastat-totdlpktfwd-s8



• pgw-subdatastat-totulbytefwd-s8

• pgw-subdatastat-totdlbytefwd-s8

• pgw-subdatastat-totulpktdrop-s8

• pgw-subdatastat-totdlpktdrop-s8

• pgw-subdatastat-totulbytedrop-s8

• pgw-subdatastat-totdlbytedrop-s8

• pgw-apnambrratelimit-uppktdrop-s8

• pgw-apnambrratelimit-downpktdrop-s8

• pgw-apnambrratelimit-upbytedrop-s8

• pgw-apnambrratelimit-downbytedrop-s8

• pgw-subdatastat-totulpktfwd-s2a

• pgw-subdatastat-totdlpktfwd-s2a

• pgw-subdatastat-totulbytefwd-s2a

• pgw-subdatastat-totdlbytefwd-s2a

• pgw-subdatastat-totulpktdrop-s2a

• pgw-subdatastat-totdlpktdrop-s2a

• pgw-subdatastat-totulbytedrop-s2a

• pgw-subdatastat-totdlbytedrop-s2a

• pgw-apnambrratelimit-uppktdrop-s2a

• pgw-apnambrratelimit-downpktdrop-s2a

• pgw-apnambrratelimit-upbytedrop-s2a

• pgw-apnambrratelimit-downbytedrop-s2a

• pgw-subdatastat-totulpktfwd-s2b

• pgw-subdatastat-totdlpktfwd-s2b

• pgw-subdatastat-totulbytefwd-s2b

• pgw-subdatastat-totdlbytefwd-s2b

• pgw-subdatastat-totulpktdrop-s2b

• pgw-subdatastat-totdlpktdrop-s2b

• pgw-subdatastat-totulbytedrop-s2b

• pgw-subdatastat-totdlbytedrop-s2b

• pgw-apnambrratelimit-uppktdrop-s2b

• pgw-apnambrratelimit-downpktdrop-s2b

• pgw-apnambrratelimit-upbytedrop-s2b



• pgw-apnambrratelimit-downbytedrop-s2b

clear egtpc statistics

This command now clears all of the eGTP-C statistics, including interface statistics.

show egtpc statistics header-decoder-errors

This output of this command has been enhanced to show header-decoder errors for P-GW sub interfaces:

• Message header decoder errors at EGTPC:

• Incorrect GTP version:

• Unsupported msg received:

• Incorrect msg length:

• Invalid msg format:

• Invalid sequence number:

• Interface PGW Ingress:

• Interface-Type S5/S8:






• Interface-Type S2A:






• Interface-Type S2B:








clear egtpc statistics interface-type interface-pgw-ingress

This command now clears all of the eGTP-C statistics, including interface statistics of all the interfacesapplicable to the P-GW ingress.

show pgw-service statistics all

The output of this command has been enhanced to show eGTP-C statistics per interface:

• S5U Total Data Statistics:

• Uplink:

• Total Pkts:

• Total Bytes:

• Total Dropped Pkts:

• Total Dropped Bytes:

• Dropped Pkts Due To APN AMBR Rate Limit:

• Dropped Bytes Due To APN AMBR Rate Limit:

• Downlink:

• Total Pkts:

• Total Bytes:






• Uplink:

• Total Pkts:

• Total Bytes:





• Downlink:

• Total Pkts:

• Total Bytes:







• S2A Total Data Statistics:

• Uplink:

• Total Pkts:

• Total Bytes:





• Downlink:

• Total Pkts:

• Total Bytes:





• S2B Total Data Statistics:

• Uplink:

• Total Pkts:

• Total Bytes:





• Downlink:

• Total Pkts:

• Total Bytes:







show saegw-service statistics all function pgw

The output of this command has been enhanced to show P-GW eGTP-C statistics per interface:


• Uplink:

• Total Pkts:

• Total Bytes:





• Downlink:

• Total Pkts:

• Total Bytes:






• Uplink:

• Total Pkts:

• Total Bytes:





• Downlink:

• Total Pkts:



• Total Bytes:





• S2A Total Data Statistics:

• Uplink:

• Total Pkts:

• Total Bytes:





• Downlink:

• Total Pkts:

• Total Bytes:





• S2B Total Data Statistics:

• Uplink:

• Total Pkts:

• Total Bytes:





• Downlink:

• Total Pkts:

• Total Bytes:







IPv6 MTU Option Support in RA MessageCSCuw28238 - [GGSN] IPv6 MTU option support in RA message

CSCuw28212 - [PGW] IPv6 MTU option support in RA message

CSCuw28245 - [SAEGW] IPv6 MTU option support in RA message


Feature ChangesIn RFC-4861 there is a provision to send the Maximum Transmission Unit (MTU) in Router Advertisement(RA) messages. Prior to StarOS release 20.0, the Cisco P-GW did not support the IPv6 MTU option in RAmessages. In StarOS release 20.0 the P-GW now supports the sending of the IPv6 MTU option in RAs forIPv6 and IPv4v6 PDN types towards the UE. As a result, the UE can now send uplink data packets based onthe configured MTU and perform data fragmentation at the source, if required. This feature also reduces thenumber of ICMPv6 Packet Too Big Error messages in the customer's network.

The MTU size is configurable via the Command Line Interface (CLI) on the GGSN and P-GW.

Previous Behavior: Initial and periodic RA messages did not contain the IPv6 MTU option.

New Behavior: When this feature is enabled and configured in APN Configuration Mode, the RA messageswill contain the IPv6 MTU option for IPv6/Ipv4v6 PGW/SAEGW/GGSN calls.

Customer Impact: The UE now will receive the IPv6 MTU option in Router Advertisement messages.

Supported Functionality

To support the IPv6MTUOption in RAMessage feature, the P-GW/GGSN supports the following functionalityand behavior:

• The ipv6 initial-router-advt option mtu command in APN Configuration Mode is available toenable/disable this feature per APN. By default, this feature is enabled for all APNs.

◦For the P-GW and SAEGW, the session manager sends the MTU value that is configured via theCLI command data-tunnel mtu 1280-2000 in APN Configuration Mode.

◦For the GGSN, the RADIUS-returned value in the Framed-MTUAttribute Value Pair (AVP) takesprecedence over the value configured via the ppp mtu 100-2000 CLI command in APNConfiguration Mode.

• For the GGSN, if the RADIUS-returned MTU value is less than the minimum IPv6 MTU, then theminimum IPv6 MTU value of 1280 is sent in the IPv6 MTU option field in RA messages.


P-GW Changes in Release 20IPv6 MTU Option Support in RA Message

• For the GGSN, if the ppp mtu100-2000 CLI command is configured with an MTU value of less than1280, then the minimum IPv6 MTU value is sent in the IPv6 MTU option field in RA messages.

•When no MTU value comes from the RADIUS server and both the above mentioned CLI commandsare not configured, the default value of 1500 is used for the MTU.

• Support for the MTU option in RA messages is available in the GGSN/P-GW/SAEGW.

• This feature is supported on the P-GW independent of interfaces such as s2a/s2b/s5/s8.

• The MTU option in RA messages is supported for both IPv6 and IPv4v6 PDN types.

• The MTU option in RA messages is available in the output of themonitor protocol command.

• The same MTU value is sent by the gateway in initial and periodic RA messages for a callline.

• The behavior of sending the IPv6MTU option in RA for a PDN call is persistent across session recoveryand ICSR switchover.

• Existing MTU related data path behavior for the GGSN/P-GW/SAEGW is not changed.


Note the following restrictions/limitations for this feature:

• The GGSN/P-GW/SAEGW does not consider the GTP-U tunnel overhead while calculating the MTUvalue to be sent in the IPv6MTU option in RAs. Therefore, the operator has to configure the data-tunnelmtu by considering the tunnel overhead. Refer to the Link MTU Considerations section in Annex-C of3GPP TS 23.060.

• Existing MTU-related data path behavior for the GGSN/P-GW/SAEGW is unchanged.

• If there is a Gn/Gp Handover followed by session recovery, operators will see the following behavior:The stateless IPv6 session is recovered with the MTU value configured for the current GGSN/P-GWservice after the handover. This is existing behavior if the feature is not configured. With this featureenabled, the same recovered MTU value will be sent in periodic RA messages after such a handoveroccurs when followed by session recovery.

• This feature is not supported for eHRPD. As a result, in scenarios where an LTE-to-eHRPD toLTE-Handover or eHRPD-to-LTE Handover occurs, a new stateless IPv6 session is re-created usingthe latest APN configuration.

•With this feature enabled, there is no support for an MTU value received by the gateway via the S6binterface.

Command Changes

ipv6 initial-router-advt

The option mtu keywords have been added to this command in APN Configuration Mode. It configures thegateway to send the IPv6 MTU option in RAs for IPv6 and IPv4v6 PDN type towards the UE. As a result,the UE can send uplink data packets based on the configured MTU and perform fragmentation at the source,if required.configure



P-GW Changes in Release 20IPv6 MTU Option Support in RA Message

apn apn_name[ default | no ] ipv6 initial-router-advt option mtuend

Where:

• ipv6 initial-router-advt option mtu: Enables the gateway to send the IPv6 MTU option in RAs forIPv6 and IPv4v6 PDN types towards the UE.

• default: Returns the feature to its default behavior. The default is enabled.

• no: Disables the feature. The IPv6 MTU option will not be sent in RAs for IPv6 and IPv4v6 PDN typetowards the UE.


monitor protocol

The output of this command has been enhanced to show the Maximum Transmission Unit (MTU) size beingused for the IPv6 MTU Option Support in RA Message feature.

• (mtu: mtu-<MTU size>)

show configuration

The output of this command has been enhanced to provide the setting for the IPv6 MTU Option Support inRA Message feature.

• no ipv6 initial-router-advt option mtu (when feature is disabled)

• ipv6 initial-router-advt option mtu (when feature is enabled or set to default.

show apn name <apn_name>

The output of this command has been enhanced to provide the setting for the IPv6 MTU Option Support inRA Message feature.

• IPv6 initial router advertisements option MTU: <Enabled or Disabled>

IPv6 Prefix-Based Search Support for LTE-WiFi HandoffCSCuw29768, CSCuw29770 - [PGW] LTE-Wifi handoff to support v6Prefix based search


Feature ChangesPreviously, LTE-to-WiFi handoffs were failing for some UE devices for a specific customer during Inter-RATtesting for WiFi. The UE devices were using Stateless Address Auto Configuration.


P-GW Changes in Release 20IPv6 Prefix-Based Search Support for LTE-WiFi Handoff

This issue was only seen from specific UE devices when the UE is sending the changed IPv6 address onCreate Session Response (CSResp) messages during handoffs. Another vendor device had no issues for theLTE-to-WiFI handoff since it was sending the IPv6 address assigned initially during the CSResp from P-GW.

When the P-GW performed an IPv6 lookup of the existing LTE session based on the complete IPv6 128-bitaddress (Prefix + Intf ID), the handover would fail with the error EGTP_CONTEXT_NOT_FOUND.

In the current release, the P-GW performs the IPv6 lookup of the existing LTE session during an LTE-WiFihandoff using only the IPv6 prefix (64-bit). Operators now will see seamless handovers on these calls for UEdevices with Stateless Address Auto Configuration.

Previous Behavior: The P-GWperformed an IPv6 prefix lookup of an existing LTE session during LTE-WiFihandoff processing based on the complete IPv6 128-bit address (Prefix + Interface ID) instead of just IPv6prefix (64-bit).

New Behavior: The P-GW uses only the IPv6 prefix (64 bit) of an existing LTE session in the event of ahandover (LTE-to-WiFi) instead of using the complete 128-bit IPv6 address. This behavior will also occurfor other Inter-RAT handovers, such as WiFi-to-LTE and LTE-to-eHRPD and vice-versa.

There are no changes on external interfaces. The only change as part of this feature is that the internalsearch to find the existing session is performed using the 64-bit IPv6 prefix during handoff.

Important

Customer Impact: The P-GWwill not reject the handoff request if the UE uses a different interface-ID fromthe one provided during call creation during handoffs for PDN types IPv6 and IPv4v6.


With Stateless Auto Configuration, when the UE uses a different interface-ID from the one provided by P-GW.The UE then later moves to another location that results in an S1/X2 handover with an S-GW change. Asresult, the S-GW may have a different IPv6 address for a PDN from the one maintained by the P-GW (thatis, the IP Address provided during initial attach) for the same UE. This can result in a difference in theservedPDPPDNAddress element in the CDR from the P-GW and S-GW.

This restriction is due to an existing limitation in the 3GPP Modify procedure, such as Modify BearerRequest/Modify Bearer Response, where an exchange of the changed UE IPv6 address is not supportedbetween the P-GW and S-GW during the S1/X2 handover.

It is assumed that the mediation devices will look into the 64-bit prefix of the IPv6 address in CDRs forStateless Auto Configuration devices.

MS Info Change Notification RequestCSCuv56309 - GGSN support for "MS Info Change Notification Request" handling.



P-GW Changes in Release 20MS Info Change Notification Request

Feature Changes

MS Info Change Notification is a license-controlled feature. Contact your Cisco account or supportrepresentative for detailed licensing information.

Important

SGSN conveys its support of both MS Info Change Notification Request and MS Info Change NotificationResponse messages to GGSN for:

• Location Change Reporting mechanism using the GTP extension header

• CSG Information Change Reportingmechanism using the CCRSI flag defined in the Extended Commonflags IE

MS Info change notification message is sent by SGSN to GGSN when the GGSN has requested to receivethe User Location Information (ULI) change notifications or when GGSN has requested to receive User CSGInformation (UCI) change notifications. GGSN then sends the received location information to PCRF forfurther processing (if location reporting event trigger is enabled) and may receive the response containingreporting action. It then further interacts with accounting server and sends update to LI server. Operators canuse these reporting messages for LI, Billing, and Policy changes.

Support has been added to process and handle a MS Info Change notification received with valid informationto identify a PDN (non-zero TEID and/or IMSI+NSAPI) and with appropriate ULI and/or UCI information.In case of collision between MS-Info-change message and NRUPC, GGSN will process MS-info-changerequest first and send out its MS-info-change response. Then the NRUPC will be retried again.

CSG reporting is not yet supported on GGSN, P-GW, or SAEGW.Important


GTPC Schema

The following bulkstats have been added to display the MS Info Change Notification Request handling:

• ms-info-chng-total

• ms-info-chng-accept

• ms-info-chng-deny

• ms-info-chng-discard

show bulkstats variables gtpc | grep ms-info-chng

This command output has been modified to display the following:Subscriber session statistics:%ms-info-chng-total% Int32 0 Counter%ms-info-chng-accept% Int32 0 Counter


P-GW Changes in Release 20MS Info Change Notification Request

%ms-info-chng-deny% Int32 0 Counter%ms-info-chng-discard% Int32 0 Counter

show gtpc statistics

This command output has been modified to display the MS Info change related stats.MS Info Change Reporting Messages:MS Info Chng Notif Req: 8 Accepted: 5Denied: 3 Discarded: 0

New KPIs for IDLE Timeout FeatureCSCuy24886 - Missing KPIs for the MFL 2661

Applicable Products: GGSN, P-GW, and SAEGW

Feature ChangesNew statistics have been introduced for the "Idle Timeout" feature. The show apn statistics [ all | name<apn_name> | verbose ] command displays the newly added statistics. See Command Changes section formore information.


show apn statistics [ all | name apn_name | verbose ]

This command displays the following output.

QCI 9:Std QCI(Non-GBR):Bearer Released: 0 Dedicated Bearer Released due to Idle-Inactivity timeout:

0Std QCI(GBR):Bearer Released: 0 Dedicated Bearer Released due to Idle-Inactivity timeout:

0Non-Std QCI(Non-GBR):Bearer Active: 0 Bearer setup:

0Bearer Released: 0 Bearer Rejected:

0Dedicated Bearer Released due to Idle-Inactivity timeout:

0Non-Std QCI(GBR):Bearer Active: 0 Bearer setup:

0Bearer Released: 0 Bearer Rejected:

0Dedicated Bearer Released due to Idle-Inactivity timeout:

0

Notes:

1 "Dedicated Bearer Released due to Idle-Inactivity timeout" counter counts only dedicated bearers releaseddue to Idle timeout or bearer Inactivity timeout. These stats are applicable for P-GW/GGSN/SAEGWproducts.


P-GW Changes in Release 20New KPIs for IDLE Timeout Feature

2 "Bearer Released" is a cumulative counter for all bearers (default and dedicated) released, belonging toone of the above categories (Std QCI(Non-GBR), Std QCI(GBR)). This counter reflects sum of "BearerReleased" counter shown under QCI X(where X is in range 1 to 9) . For example, "Bearer Released" underStd QCI(GBR) reflects sum of all "Bearer Released" counter under QCI 1 to 4. Similarly, "Bearer Released"under Std QCI(Non-GBR) reflects sum of all "Bearer Released" counter under QCI 5 to 9.

3 If default bearer is released due to bearer inactivity timeout, then the associated dedicated bearers arecounted in "Dedicated Bearer Released due to Idle-Inactivity timeout" counter. Similarly, if PDN is releaseddue to Idle timeout then all the dedicated bearers of that PDN will be counted as part of "Dedicated BearerReleased due to Idle-Inactivity timeout".

Optimization for egtpinmgr RecoveryCSCup19513 - New CSReq processing is delayed after egtpinmgr crashed


Prior to StarOS release 20.0, when the egtpinmgr task restarted it took a significant amount of time for it torecover. As a result, the outage time when the GGSN, P-GW, SAEGW, and S-GW were unable to accept anynew calls during egtpinmgr recovery was high.

The software has been enhanced to optimize the recovery outage window in the event of an egtpinmgr taskrestart; this has been achieved by optimizing the internal algorithms of egtpinmgr recovery and the datastructures required. In addition, recovery time now is dependent only on the number of unique IMSIs and noton the number of sessions for an IMSI.

P-GW Handoff KPIs for VoWiFi

Feature ChangesCurrently, there are no statistics to determine the number of new sessions started on a particular RAT technologyand to monitor any inter-technology handovers per APN.

This feature introduces new session/handoff KPIs and P-GW VoWifi specific KPIs to monitor the following:

• the number of new sessions started on a particular RAT technology

• the inter-technology handover per APN from and to all access technologies

• subscriber activity for network planning

The statistical information is maintained per APN and per P-GW/SAEGW service type. CLIs are applicableonly for P-GW and SAEGW product. If eHRPD/PMIP/GGSN services are associated with a P-GW/SAEGWservice, then counters related to these services will be reflected under P-GW/SAEGW service statistics CLIoutput.

Benefits

With the introduction of this feature, operators can have KPIs to monitor per RAT Initiated Sessions andInter-technology handovers so that they can gauge 2G/3G/4G/WiFi/eHRPD coverage.

Operators can also:


P-GW Changes in Release 20Optimization for egtpinmgr Recovery

• get statistics that report on:

• new access technologies such as Wi-Fi that uses the ePDG

• how a session has been initiated

• how many handoffs have been done

• track subscriber activity in the network

• plan network accordingly

Limitations

• Initiated session statistics and handover statistics at APN-level are not maintained or incremented atdemux due to memory and CPU constraints. During congestion scenarios, for example, some of thecalls are rejected at the demux and so this count will not show up in the APN-level initiated sessioncounter.

• Bulkstats for eHRPD and S2b-PMIP are not supported under SAEGW schema.

Monitoring and Troubleshooting P-GW Handoff KPIs for VoWiFiThe following section describes commands available to monitor P-GW Handoff KPIs for VoWiFi.

HandOff KPIS for VoWiFi Show Commands

The following section describes commands available to monitor Handoff KPIs for VoWiFi.

show apn statistics [ all | name apn_name | verbose ]This command displays the following output.

Initiated Sessions per RAT Type:EUTRAN: 0 UTRAN: 0GERAN: 0 EHRPD: 0S2A GTP: 0 S2B GTP: 0S2B PMIP: 0

Inter Technology handover:GNGP-to-LTE handover: LTE-to-GNGP handover:Attempted: 0 Attempted: 0Succeeded: 0 Succeeded: 0Failed: 0 Failed: 0

GNGP-to-S4SGSN handover: S4SGSN-to-GNGP handover:Attempted: 0 Attempted: 0Succeeded: 0 Succeeded: 0Failed: 0 Failed: 0

S4SGSN-to-LTE handover: LTE-to-S4SGSN handover:Attempted: 0 Attempted: 0Succeeded: 0 Succeeded: 0Failed: 0 Failed: 0

LTE-to-eHRPD handover: eHRPD-to-LTE handover:Attempted: 0 Attempted: 0Succeeded: 0 Succeeded: 0Failed: 0 Failed: 0


P-GW Changes in Release 20P-GW Handoff KPIs for VoWiFi

LTE-to-S2bPMIP handover: S2bPMIP-to-LTE handover:Attempted: 0 Attempted: 0Succeeded: 0 Succeeded: 0Failed: 0 Failed: 0

eHRPD-to-S2bPMIP handover: S2bPMIP-to-eHRPD handover:Attempted: 0 Attempted: 0Succeeded: 0 Succeeded: 0Failed: 0 Failed: 0

S2bGTP-to-LTE handover: LTE-to-S2bGTP handover:Attempted: 0 Attempted: 0Succeeded: 0 Succeeded: 0Failed: 0 Failed: 0

S2bGTP-to-eHRPD handover: eHRPD-to-S2bGTP handover:Attempted: 0 Attempted: 0Succeeded: 0 Succeeded: 0Failed: 0 Failed: 0

S2aGTP-to-LTE handover: LTE-to-S2aGTP handover:Attempted: 0 Attempted: 0Succeeded: 0 Succeeded: 0Failed: 0 Failed: 0

show pgw-service statistics { all | name service_name }The command displays the following output:

Initiated PDNs By RAT-Type:EUTRAN: 0 UTRAN: 0GERAN: 0 EHRPD: 0S2A GTP: 0 S2B GTP: 0S2B PMIP: 0

show saegw-service statistics { all | name service_name } function pgwThe command displays the following output:

Initiated PDNs By RAT-Type:EUTRAN: 0 UTRAN: 0GERAN: 0 EHRPD: 0S2A GTP: 0 S2B GTP: 0S2B PMIP: 0

Schema for P-GW Handoff KPIs for VoWifi

This section lists the schemas added in for the P-GW Handoff KPIs for VoWifi Feature.

APN SchemaInitiated Sessions Statistics Information based on RAT Technology:

The following new counters have been added to display the number of Initiated Sessions per RAT type, perService/APN in this enhancement:

• initiated-eutran-sessions

• initiated-utran-sessions

• initiated-geran-sessions

• initiated-ehrpd-sessions

• initiated-s2a-gtp-sessions

• initiated-s2b-gtp-sessions



• initiated-s2b-pmip-sessions

Inter-Technology Handover Statistics:

The following new counters have been added to display the number of inter-technology handover statisticsper APN/Service have been added in this enhancement:

• apn-handoverstat-gngptolteatt

• apn-handoverstat-gngptoltesucc

• apn-handoverstat-gngptoltefail

• apn-handoverstat-ltetogngpatt

• apn-handoverstat-ltetogngpsucc

• apn-handoverstat-ltetogngpfail

• apn-handoverstat-gngptos4sgsnatt

• apn-handoverstat-gngptos4sgsnsucc

• apn-handoverstat-gngptos4sgsnfail

• apn-handoverstat-s4sgsntogngpatt

• apn-handoverstat-s4sgsntogngpsucc

• apn-handoverstat-s4sgsntogngpfail

• apn-handoverstat-s4sgsntolteatt

• apn-handoverstat-s4sgsntoltesucc

• apn-handoverstat-s4sgsntoltefail

• apn-handoverstat-ltetos4sgsnatt

• apn-handoverstat-ltetos4sgsnsucc

• apn-handoverstat-ltetos4sgsnfail

• apn-handoverstat-ltetoehrpdatt

• apn-handoverstat-ltetoehrpdsucc

• apn-handoverstat-ltetoehrpdfail

• apn-handoverstat-ehrpdtolteatt

• apn-handoverstat-ehrpdtoltesucc

• apn-handoverstat-ehrpdtoltefail

• apn-handoverstat-ltetos2bpmipatt

• apn-handoverstat-ltetos2bpmipsucc

• apn-handoverstat-ltetos2bpmipfail

• apn-handoverstat-s2bpmiptolteatt

• apn-handoverstat-s2bpmiptoltesucc

• apn-handoverstat-s2bpmiptoltefail



• apn-handoverstat-ehrpdtos2bpmipatt

• apn-handoverstat-ehrpdtos2bpmipsucc

• apn-handoverstat-ehrpdtos2bpmipfail

• apn-handoverstat-s2bpmiptoehrpdatt

• apn-handoverstat-s2bpmiptoehrpdsucc

• apn-handoverstat-s2bpmiptoehrpdfail

• apn-handoverstat-s2bgtptolteatt

• apn-handoverstat-s2bgtptoltesucc

• apn-handoverstat-s2bgtptoltefail

• apn-handoverstat-ltetos2bgtpatt

• apn-handoverstat-ltetos2bgtpsucc

• apn-handoverstat-ltetos2bgtpfail

• apn-handoverstat-s2bgtptoehrpdatt

• apn-handoverstat-s2bgtptoehrpdsucc

• apn-handoverstat-s2bgtptoehrpdfail

• apn-handoverstat-ehrpdtos2bgtpatt

• apn-handoverstat-ehrpdtos2bgtpsucc

• apn-handoverstat-ehrpdtos2bgtpfail

• apn-handoverstat-s2agtptolteatt

• apn-handoverstat-s2agtptoltesucc

• apn-handoverstat-s2agtptoltefail

• apn-handoverstat-ltetos2agtpatt

• apn-handoverstat-ltetos2agtpsucc

• apn-handoverstat-ltetos2agtpfail

P-GW SchemaInitiated Sessions Statistics Information based on RAT Technology: The following counters have beenadded to display the number of Initiated Sessions per RAT type, per Service /APN in this enhancement:

• sessstat-rat-init-eutran

• sessstat-rat-init-utran

• sessstat-rat-init-geran

• sessstat-rat-init-ehrpd

• sessstat-rat-init-s2a-gtp

• sessstat-rat-init-s2b-gtp

• sessstat-rat-init-s2b-pmip



SAEGW SchemaInitiated Sessions Statistics Information based on RAT Technology: The following counters have beenadded to display the number of Initiated Sessions per RAT type, per Service/APN in this enhancement:

• pgw-sessstat-pdn-rat-init-eutran

• pgw-sessstat-pdn-rat-init-utran

• pgw-sessstat-pdn-rat-init-geran

• pgw-sessstat-pdn-rat-init-s2a-gtp

• pgw-sessstat-pdn-rat-init-s2b-gtp

QoS-Capability AVP Sent in S6b AARCSCuy20832 - QoS-Capability AVP is sent in S6b AAR after eHRP-LTE HO for Stnd dict


Feature Changes

Previous Behavior: After eHRPD to LTE handover with standard S6b dictionary, QoS-Capability AVP wassent in S6b AAR message. This was an additional AVP for the AAA server.

New Behavior: After eHRPD to LTE handover with standard S6b dictionary, QoS-Capability AVP is nolonger sent in S6b AAR message.

Revised Marking for Subscriber Traffic

Feature Description802.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 theQCI-QoS table and configure the appropriate 802.1p or MPLS-EXP (L2 QoS) markings based on theinternal-qos value associated with particular row. However, the usage of internal-qos from the QCI-QoS tableis not configurable and uses the default values. In addition, L2 QoS (802.1p/MPLS EXP) marking is notsupported 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 CLIcommand has been introduced to support service specific configuration to mark subscriber traffic. ThisL2marking can be decided based on QCI and DSCPmarking together or solely based on DSCPmarking.

Limitations

• This feature does not control the behavior of the control packets. The control packets (GTP-C) continueto get L2 marked based on DSCP derived L2 marking.


P-GW Changes in Release 20QoS-Capability AVP Sent in S6b AAR

• This feature is not supported on standalone GGSN. It is supported on GnGp-GGSN node.

How It WorksYou 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. Todo this, use the CLI command to configure service specific configuration to mark subscriber traffic. This L2marking can be decided based on QCI and DSCP marking together or solely based on DSCP marking.

Behavior Changes for Different Services

This section describes behavior of this feature for different services. Please see theCommand Changes sectionfor more information on the CLI command options and its behavior:

GGSN/P-GW GTPv1 Calls:

Previous Behavior: Earlier, the traffic was not marked for data path. This was default behavior for GGSN.

New Behavior: A new CLI command has been introduced to mark the traffic 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. When the feature is notenabled, 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 L2marking, 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 behavioris executed. When the feature is not enabled, traffic is not marked.

Configuring Revised Marking for Subscriber TrafficEarlier, the traffic was not marked for data path. This was default behavior for GGSN. Now, internal prioritycan be configured in QCI-mapping table for the GGSN, GTPv1 P-GW, and SAEGW calls. Subscriber trafficcan also be marked with either 802.1p or MPLS-EXP to enable or disable L2 marking. To do this, use theCLI command to configure service specific configuration to mark subscriber traffic. This L2 marking can bedecided based on QCI and DSCP marking together or solely based on DSCP marking.


P-GW Changes in Release 20Revised Marking for Subscriber Traffic

Configuring Internal Priority

To configure internal priority in the QCI-mapping table for the GGSN, GTPv1 P-GW, and SAEGW calls,use the following service specific configuration. This command in the GGSN service configuration overridesthe behavior of QCI-QOS-mapping for data packets only.configure

context context_nameggsn-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-qosmapping table. If internal-qos priority is not configured in the qci-qos mapping table, then the datapackets are not marked.


The configuration of this feature can be verified using the following commands from the exec mode:

• show configuration

• show service-type { all | name service_name }

Please see theMonitoring and Troubleshooting RevisedMarking for Subscriber Traffic section for the commandoutput.

Monitoring and Troubleshooting Revised Marking for Subscriber TrafficThe following section describes commands available to monitor Revised Marking for Subscriber Traffic.

Internal Priority Show Commands

The following section describes commands available to monitor Internal Priority.

show configurationThis command displays the following output:

•When internal-qos data is configured as none:internal-qos data none

•When internal-qos data is configured as qci-derived:internal-qos data qci-derived


P-GW Changes in Release 20Revised Marking for Subscriber Traffic

•When internal-qos data is configured as dscp-derived:internal-qos data dscp-ds-derived

•When internal-qos data is not configured:no internal-qos data

show service-type { all | name service_name }This command displays the following output:

•When internal-qos data is configured as none:

Internal QOS Application: EnabledInternal QoS Policy: None

•When internal-qos data is configured as qci-derived:

Internal QOS Application: EnabledInternal QOS Policy: QCI Derived

•When internal-qos data is configured as dscp-derived:

Internal QOS Application: EnabledInternal QOS Policy: DSCP Derived

•When internal-qos data is not configured:

Internal QOS Application: Backward-compatible

Routing of UE Local IP Address/Port to AAA and PCRF ServersCSCuw45012 - Sending UE local IP address, port support on Diameter s6b i/f

Related CDETS IDs = CSCuw08581, CSCuw08571, CSCuw13501

Applicable Products: P-GW/SAEGW

Feature ChangesAs part of 3GPPRel.12 compliance, the following twoDiameter AVPs are introduced to support interoperabilitybetween ePDG and P-GW.

• UE-Local-IP-Address: This attribute is defined as either the public IP address assigned to the UEconnected to a Broadband Forum (BBF) access network via aWLAN by the BBF domain in the no-NATcase, or the public IP address assigned by the BBF domain to the NATed RG that is used for this UE.

• UDP-Source-Port: The ePDG includes this IE on S2b interface if NAT is detected and UE Local IPAddress is present for Fixed Broadband access network.

This feature is customer-specific. Contact your Cisco account representative for more information.Important

P-GW is enabled to receive both the AVPs from ePDG in Create Session Request (CSR) over S2b, and thenforward these two AVPs to PCRF in CCR-I over Gx. P-GW also sends UE-Local-IP-Address AVP to AAAserver in AAR message over S6b interface. In case of LTE to WiFi and eHRPD to WiFi handoff scenarios,P-GW sends the UE-Local-IP-Address and UDP-Source-Port AVPs in CCR-U towards PCRF.


P-GW Changes in Release 20Routing of UE Local IP Address/Port to AAA and PCRF Servers

P-GW does not support these AVPs when received in a Modify Bearer Request (MBReq) over S2b interface.P-GW does not send these AVPs over charging interfaces (Rf/Gy/CDR).

In order to support this feature, these AVPs are added to dpca-custom11 and r8-gx-standard dictionaries, andthe UE-Local-IP-Address AVP is added to aaa-custom21 dictionary.

The routing of these two AVPs to AAA server/PCRF is required for QoS support in Fixed Broadband Accessnetwork and also for PCRF to initiate gateway control session establishment towards Broadband Policy ControlFunction (BPCF). With this feature, the AAA server is able to identify if the UE is connected through aBBF-defined WLAN access network.

Session Disconnect Reasons EnhancementsCSCuq76444 - Session disconnect reasons enhancements


Feature ChangesOutput for the CLI command show session disconnect-reasons reflects cumulative session disconnect reasonsinformation for all services running in the system. New keywords have been added to see disconnect reasonsspecific to P-GW or S-GW service calls.

Command Changesclear session disconnect-reasons

This existing command will clear all session disconnect reason information; it will also clear both P-GW andS-GW specific disconnect reason information.

show session disconnect-reasons

The keywords pgw-only and sgw-only have been added to this command to show disconnect reasons specificto S-GW or P-GW service calls.show session disconnect-reasons pgw-only [ verbose ] [ | { grep grep_options | more } ] ]show session disconnect-reasons sgw-only [ verbose ] [ | { grep grep_options | more } ] ]

Notes:

• pgw-only: Displays cumulative session disconnect reason statistics specific to P-GW/GGSN calls.

The following call types will fall under this category:

◦P-GW Call

◦GGSNCall (both standaloneGGSN service as well as GGSN service associatedwith P-GW service)

◦SAEGW Call (P-GW-Anchored)

◦SAEGW Call (GGSN-Anchored)

◦SAEGW Call (Co-located)

• sgw-only: Displays cumulative session disconnect reason statistics specific to S-GW calls.

The following call types will fall under this category:


P-GW Changes in Release 20Session Disconnect Reasons Enhancements

◦S-GW Call

◦SAEGW Call (S-GW-Anchored)

Transaction Rate Key Performance IndicatorsCSCuv85579, CSCuw06248 - Transaction Rate KPI (SEPS and CEPS)

Applicable Products: eHRPD, ePDG, P-GW

Feature ChangesPreviously, key performance indicators (KPIs) did not differentiate between successful or unsuccessful PDNsession activations and deactivations. In addition, the KPIs did not provide any information related to theVoice-over-LTE (VoLTE) service.

In StarOS release 20.0, Session Events Per Second (SEPS) KPIs have been added. These KPIs measure thesignaling load on the P-GW/ePDG. Network initiated setup/teardown KPIs have been added to measure theevent rate for VoLTE call setup and tear down. Together, these measurements assist operators in performingnetwork dimensioning/planning for the P-GW/ePDG node.

For the P-GW, both types of KPIs are supported on the s5, s8, s2a, and s2b Interfaces. Also for the P-GW,SEPS KPIs are also supported for any associated eHRPD/PMIP service.

Specifically, the following KPIs have been implemented:

Session Events Per Second (SEPS)

Session Events per Second KPIs have been added to assist operators in measuring the signaling load on theP-GW/ePDG. These SEPS KPIs include the following:

• Total session events (session setup and teardown) per second.

• Successful Session Events (session setup and teardown) per second.

• Unsuccessful Session Events (session setup and teardown) per second.

N/w Initiated Setup/Tear down Events Per Second

Network initiated setup/teardown event KPIs have been added to assist operators in measuring Voice-over-LTE(VoLTE) call setup and teardown events rate at the P-GW/ePDG. The following events are accounted for inthese KPIs:

• Create Bearer Requests (CBReqs) and Delete Bearer Requests (DBReqs) originally initiated by theP-GW

• DBReqs initiated by the P-GW as a result of Home Subscriber Server (HSS)- and User Equipment (UE)-initiated event

The N/w Initiated Setup/Teardown Events Per Second KPIs include the following:

• Total N/w Initiated Setup/Teardown Events (VoLTE bearer setup and tear down) per second.

• Successful N/w Initiated Setup/Teardown Events (VoLTE bearer setup and tear down) per second.


P-GW Changes in Release 20Transaction Rate Key Performance Indicators

• Unsuccessful N/w Initiated Setup/Teardown Events (VoLTE bearer setup and tear down) per second.

Operation

The P-GW/ePDG contains eight buckets for transaction rate statistics collection for both session events persecond KPIs and N/w Initiated Setup/Teardown Events per Second KPIs. The buckets are based on aconfigurable bucket interval that is from 1 to 20 minutes in length. During the configured time interval, anaverage is computed and stored for the entire bucket interval.

After the first eight bucket intervals have elapsed and statistics collected, the P-GW continues sequentiallythrough the same eight bucket intervals and eventually overwrites the original eight bucket-intervals withmore recent data. In short, the eight bucket intervals provide a running value for the last eight bucket-intervalsfor which the KPIs have been computed. While the statistics are eventually overwritten with new values, allstatistic totals are added to the historical statistics, which are not overwritten.

Command Changes

clear transaction-rate pgw-service [ name <service_name> ]

This new command in Exec Mode clears Session Events per Second (SEPS) and N/w Intiated Setup/Teardown Events per Second KPI information for the specified P-GW service. If the variable name is not specified,the P-GW clears all P-GW-specific SEPS information.

default transaction-rate

This new command has been added to Global Configuration Mode. When this command is executed, it setsthe transaction-rate bucket-interval to the default setting of 2 minutes. It also sets thenw-initiated-setup-teardown-events qci value to the default that all QCI values are to be tracked for networkinitiated setup/tear down events.configure

default transaction-rateend

Notes

• The default for transaction-rate bucket-interval is 2 minutes.

• The default for transaction-rate nw-initiated-setup-teardown-events qci is to collect transaction ratestatistics for all QCI values (1 through 9 and 128 through 254).

• For more information, refer to the descriptions of the transaction-rate bucket-interval andtransaction-rate nw-initiated-setup-teardown-events qci commands in this section.

transaction-rate bucket-interval

This new command has been added toGlobal ConfigurationMode. It enables operators to set the time intervalused for gathering transaction rate Session Events per Second and N/w Initiated Setup/Tear down Events perSecond KPI information.configure

transaction-rate bucket-interval time-interval



default transaction-rate bucket-intervalend

Notes:

•Where bucket-interval is the time interval, in minutes, used for gathering transaction rate statistics.This setting must be an integer from 1 to 20 minutes. The default value is 2 minutes. If no entry is madefor the bucket-interval, then the default value of 2 minutes is used.

• To keep the number of buckets carrying new data across two consecutive bulk statistics sampling intervalsas constant, use the following recommended configuration:

◦Configure the bucket-interval so that the bulk statistic sampling interval is an integer (from 1 to8) multiple of the configured bucket-interval. This new integer multiple reflects the number ofbuckets with new information in a given sampling interval. For example:

1 If the bulk statistic sampling interval is 15, then the configured bucket interval should be 3 sothat the bucket interval is an integer multiple (3*5=15) of the sampling interval. In this case,5 indicates the number of buckets with new information in a given sampling interval.

2 Similarly, when the bulk statistic sampling interval is 16, then the bucket interval could be 2(so that 2*8=16). In this example 8 is the number of buckets with new information in a givensampling interval.

• The transaction rates statistics are lost if the sessmgr/demuxmgr restarts. Also the cumulative statisticsaccumulated to that point are also lost.

• If the sessmgr/demuxmgr restarts in the middle of a bucket interval, the transaction rates stats collectedto that point are lost.

transaction-rate nw-initiated-setup-teardown-events qci

This new command has been added to Global Configuration Mode. It allows operators to configurenetwork-initiated setup/tear down KPIs to measure the event rate for VoLTE call setup and teardown.configure

transaction-rate nw-initiated-setup-teardown-events qci { all | qci_value }default transaction-rate nw-initiated-setup-teardown-events qcino transaction-rate nw-initiated-setup-teardown-events qci qci_valueend

Notes:

• transaction-rate: Enables the configuration of transaction rate-specific parameters.

• nw-initiated-setup-teardown-events: Enables the configuration of network initiated setup/teardownevents.

• qci: Specifies the Quality of Service Class Identifier (QCI) value for whichnw-initiated-setup-teardown-events will be tracked. Only the QCI values of 1 through 9 and 128through 254 are supported as the setting for qci_value. A maximum of 4 unique QCI settings can beconfigured.

• no: Disables network initiated setup/tear down events for the specified QCI value.

• default: Returns this command function to its default behavior. The default behavior is to tracknetwork-initiated setup/teardown events for all QCIs.



• The transaction rates statistics are lost when the sessmgr/demux restarts.


P-GW Schema

The following bulk statistics have been added to support the Transaction Rate KPIs feature on the P-GW.

• transrate-sessevt-cumlt

• transrate-sessevt-bkt1








• transrate-succ-sessevt-cumlt

• transrate-succ-sessevt-bkt1








• transrate-unsucc-sessevt-cumlt

• transrate-unsucc-sessevt-bkt1










• transrate-nwinit-setupteardown-evt-cumlt

• transrate-nwinit-setupteardown-evt-bkt1








• transrate-succ-nwinit-setupteardown-evt-cumlt

• transrate-succ-nwinit-setupteardown-evt-bkt1








• transrate-unsucc-nwinit-setupteardown-evt-cumlt

• transrate-unsucc-nwinit-setupteardown-evt-bkt1








show configuration

The output of this command has been enhanced to show configuration settings for the Transaction Rate KPIsfeature.

• transaction-rate nw-initiated-setup-teardown-events { all | <qci_value>}

• default transaction-rate nw-initiated-setup-teardown-events qci

• no transaction-rate nw-initiated-setup-teardown-events-qci <qci_value>



• transaction-rate bucket-interval <time_interval>

• default transaction-rate-bucket-interval

• default transaction-rate

show transaction-rate pgw-service { all | name <service_name> }

This new command has been added to Exec Mode to enable operators to view transaction rate KPIs (persecond) for the specified P-GW service(s). This command displays the following output:

================================================================================

Historical Session Events Information (Per Sec)

====================================================================Bucket Timestamp Total Events Successful Unsuccessful====================================================================1 NA 0.000000 0.000000 0.0000002 NA 0.000000 0.000000 0.0000003 NA 0.000000 0.000000 0.0000004 NA 0.000000 0.000000 0.0000005 NA 0.000000 0.000000 0.0000006 NA 0.000000 0.000000 0.0000007 NA 0.000000 0.000000 0.0000008 NA 0.000000 0.000000 0.000000

Cumulative Session Events: 0Cumulative Successful Session Events: 0Cumulative Unsuccessful Session Events: 0

====================================================================

Historical N/w Initiated Setup/Teardown Events Information (Per Sec)

====================================================================Bucket Timestamp Total Events Successful Unsuccessful====================================================================1 NA 0.000000 0.000000 0.0000002 NA 0.000000 0.000000 0.0000003 NA 0.000000 0.000000 0.0000004 NA 0.000000 0.000000 0.0000005 NA 0.000000 0.000000 0.0000006 NA 0.000000 0.000000 0.0000007 NA 0.000000 0.000000 0.0000008 NA 0.000000 0.000000 0.000000

Cumulative N/w Initiated Setup/Teardown Events: 0Cumulative Successful N/w Initiated Setup/Teardown Events: 0Cumulative Unsuccessful N/w Initiated Setup/Teardown Events: 0

Wrong Disconnect Reason When S-GW Restoration Detected During WiFi toLTE Handoff

CSCuy34179 - Wrong disconnect reason when sgw-restoration detected during Wifi-LTE HO


Feature Changes

Correction of wrong disconnect reason seen for call drop due to S-GW restoration detection on P-GW duringWiFi to LTE handoff.


P-GW Changes in Release 20Wrong Disconnect Reason When S-GW Restoration Detected During WiFi to LTE Handoff

Previous Behavior:Call droppedwhen S-GW restorationwas detected duringWiFi to LTE handoff, disconnectreason was incorrectly set as "gtpc-path-failure."

New Behavior: Call dropped when S-GW restoration is detected during WiFi to LTE handoff; disconnectreason is now set correctly as "disconnect-irat-fail-hi-missing."


P-GW Changes in Release 20Wrong Disconnect Reason When S-GW Restoration Detected During WiFi to LTE Handoff

Documents

P-GW Changes in Release 20 - Cisco - Global Home · PDF fileP-GW Changes in Release 20 ... CLI Added for Third-party S-GW Inter-operation ... packet.Thisuser-datagrampacketDSCPvalueissentinDDNmessagebyS-GWtoMME/S4-SGSN