release change reference, staros release 21.8/ultra ...€¦ · chapter 2...

Release Change Reference, StarOS Release 21.8/Ultra Services PlatformRelease 6.2First Published: 2018-04-26

Last Modified: 2020-07-14

Americas HeadquartersCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706USAhttp://www.cisco.comTel: 408 526-4000

800 553-NETS (6387)Fax: 408 527-0883

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITHTHE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY,CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version ofthe UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHERWARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS.CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUTLIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERSHAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, networktopology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentionaland coincidental.

All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version.

Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL:https://www.cisco.com/c/en/us/about/legal/trademarks.html. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply apartnership relationship between Cisco and any other company. (1721R)

© 2018-2020 Cisco Systems, Inc. All rights reserved.

https://www.cisco.com/c/en/us/about/legal/trademarks.html

C H A P T E R 1Release 21.8 Features and Changes QuickReference

• Release 21.8/6.2 Features and Changes, on page 1

Release 21.8/6.2 Features and ChangesRelease Introduced /Modified

Applicable Product(s) /Functional Area

New Features and Functionality / Behavior Changes

6.0UASDeprecation of Manual Scaling, on page 149

21.8.5All products using LIMaximumSegment Size for Outgoing TCP Packets,on page 201

21.8.4SGSNTriggering Iu Release Command Procedure, on page279

21.8.3P-GWNAT64 Support, on page 217

21.8.2IPSG4G Sessions in IPSG, on page 19

21.8.2SystemICSR Switchover Configuration Support for SFFailures, on page 169

21.8MME5G NSA for MME, on page 21

21.8SAEGW5G NSA for SAEGW, on page 41

6.2USPAPI-based AutoDeploy, AutoIT and AutoVNFUpgrade Process , on page 71

6.2USPAPI-based VNFM Upgrade Process, on page 63

6.2USPAutomatic Disabling of UnusedOpenStack Services,on page 79

6.2USPAutomatic Enabling of Syslogging for CephServices, on page 81

Release Change Reference, StarOS Release 21.8/Ultra Services Platform Release 6.21

Release Introduced /Modified



21.8SystemBGP Peer Limit, on page 83

21.8IPSGCisco Ultra Traffic Optimization, on page 87

21.8.10P-GWCLI Support for P-GW to include AVPs in CCR-UMessages, on page 107

21.8SystemConfiguration Support for Heartbeat Value, on page111

21.8MMEDedicated Core Networks on MME, on page 115

21.8P-GW, SAEGWDiameter Proxy Consolidation, on page 151

21.8SystemDI-Network RSS Encryption, on page 155

6.2USPESC Event Integration with Ultra M Manager, onpage 157

21.8SystemEvent Logging Support for VPP, on page 159

21.8P-GWHash-Value Support in Header Enrichment, on page165

21.8.10P-GWHandling NPLI Requests, on page 163

21.8ePDGIMEI Validation Failure, on page 173

21.8SystemIncreasedMaximum IFtask Thread Support, on page175

21.8MMEIncreased Subscriber Map Limits, on page 177

21.8P-GWInline TCP Optimization, on page 179

21.8MMEIPv6 PDN Type Restriction, on page 189

21.8SystemLimiting Cores on Local File Storage, on page 193

21.8P-GW, SAEGWLTE to Wi-Fi (S2bGTP) Seamless Handover, onpage 195

21.8SystemMonitor VPC-DI Network, on page 203

21.8P-GW, SAEGW, S-GWMultiple IP Versions Support, on page 211

21.8ePDGNon-MCDMACores for Crypto Processing, on page221

21.8P-GW, SAEGW, S-GWOverride Control Enhancement, on page 223

21.8P-GWPacket Count in G-CDR, on page 227


Release 21.8 Features and Changes Quick ReferenceRelease 21.8/6.2 Features and Changes

Release Introduced /Modified



21.8P-GW, SAEGWS6B-bypass Support for eMPS Session, on page 231

21.8MMEShort Message Service, on page 235

21.8SystemSNMP IF-MIB and Entity-MIB Support forDI-Network Interface, on page 267

6.2.b3

21.6.13

USP

StarOS

StarOS Release 21.6.x Interoperability with USPRelease 6.2.bx, on page 277

6.2USPUAS and UEM Login Security Enhancements, onpage 283

6.2USPUEM Patch Upgrade Process, on page 285

6.2.b3USPUltra M C2.1 MicroPod Deployment with CVIM,on page 295

6.2USPUltra M Manager Integration with AutoIT, on page297

6.2USPUltraMManager SNMP Fault Suppression, on page303

6.2USPUSP Software Version Updates, on page 305



C H A P T E R 2Feature Defaults Quick Reference

• Feature Defaults, on page 5

Feature DefaultsThe following table indicates what features are enabled or disabled by default:

DefaultFeature

Enabled - Always-on4G Sessions in IPSG

Disabled - Configuration Required5G Non Standalone for MME

Disabled - Configuration Required5G Non Standalone for SAEGW

Disabled - Configuration RequiredAPI-based AutoDeploy, AutoIT and AutoVNF Upgrade Process

Disabled - Configuration RequiredAPI-based VNFM Upgrade Process

DisabledAutomatic Disabling of Unused OpenStack Services

Enabled - Always-onAutomatic Enabling of Syslogging for Ceph Services

Disabled - Configuration RequiredBGP Peer Limit

Disabled - License RequiredCisco Ultra Traffic Optimization

Disabled - License RequiredCLI Support for P-GW to include AVPs in CCR-U Messages

Disabled - Configuration RequiredConfiguration Support for Heartbeat Value

Enabled - Configuration RequiredDedicated Core Networks on MME

Disabled - Configuration RequiredDeprecation of Manual Scaling

Disabled - Configuration RequiredDiameter Proxy Consolidation

Disabled - Configuration RequiredDI-Network RSS Encryption

Enabled - Always-onESC Event Integration with Ultra M Manager


DefaultFeature

Disabled - Configuration RequiredEvent Logging Support for VPP

Disabled - Configuration RequiredHandling NPLI Requests

Disabled - Configuration RequiredHash-Value Support in Header Enrichment

Disabled - Configuration RequiredICSR Switchover Configuration Support for SF Failures

Enabled - Always-onIMEI Validation Failure

Enabled - Always-onIncreased Maximum IFtask Thread Support

Disabled - Configuration RequiredIncreased Subscriber Map Limits

Disabled - Configuration RequiredInline TCP Optimization

Disabled - Configuration RequiredIPv6 PDN Type Restriction

Disabled - Configuration RequiredLimiting Cores on Local File Storage

Disabled - Configuration RequiredLTE to Wi-Fi (S2bGTP) Seamless Handover

Disabled - Configuration RequiredMaximum Segment Size for Outgoing TCP Packets

Enabled - Always-onMonitor VPC-DI Network

Disabled - Configuration RequiredMultiple IP Versions Support

Disabled - Configuration RequiredNAT64 Support

Enabled - Always-onNon-MCDMA Cores for Crypto Processing

Disabled - Configuration RequiredOverride Control Enhancement

Disabled - Configuration RequiredPacket Count in G-CDR

Disabled - Configuration RequiredS6B-bypass Support for eMPS Sessions

Disabled - Configuration RequiredShort Message Service

Enabled - Always-onSNMP IF-MIB and Entity-MIB Support Added for DI-NetworkInterface

Enabled - Always-onStarOS Release 21.6.x Interoperability with USP Release 6.2.bx

Disabled - Configuration RequiredTriggering Iu Release Procedure

Enabled – Always-onUAS and UEM Login Security Enhancements

Disabled - Configuration RequiredUEM Patch Upgrade Process

Disabled - Configuration RequiredUltra M C2.1 MicroPod Deployment with CVIM

Disabled - Configuration RequiredUltra M Manager Integration with AutoIT


Feature Defaults Quick ReferenceFeature Defaults

DefaultFeature

Disabled - Configuration RequiredUltra M Manager SNMP Fault Suppression

Disabled - Configuration RequiredUSP Software Version Updates



C H A P T E R 3Bulk Statistics Changes Quick Reference

This chapter identifies bulk statistics changes added to, modified for, or deprecated from the StarOS 21.8software release.

For more information regarding bulk statistics identified in this section, see the latest version of theBulkstatStatistics_document.xls spreadsheet supplied with the release.

Important

Bulk statistics changes for 21.8 include:

• New Bulk Statistics, on page 9• Modified Bulk Statistics, on page 16• Deprecated Bulk Statistics, on page 17

New Bulk StatisticsThis section identifies new bulk statistics and new bulk statistic schemas introduced in release 21.8.

APN Schema

The following bulk statistics are added in the APN schema in support of the LTE toWi-Fi (S2bGTP) SeamlessHandover feature.

DescriptionBulk Statistics

Indicates the number of LTE to S2bGTP handoversucceeded on Timer Expiry.

apn-handoverstat-ltetos2bgtpsucc-timerexpiry

Indicates the number of LTE to S2bGTP handoversucceeded on Uplink Data on S2b tunnel.

apn-handoverstat-ltetos2bgtpsucc-uplnkdata

Diameter-Auth Schema

Table 1:

DescriptionBulks Statistics

Indicates the number of times failure handling action“continue” is taken using the eMPS template.

fh-continue-retry-emp


DescriptionBulks Statistics

Indicates the number of times the failure handlingaction “continue without retry” is taken using eMPStemplate.

fh-continue-wo-retry-emps

Indicates the number of times failure handling “retryand terminate” is taken using eMPS template.

fh-retry-and-term-emps

Indicates the number of times failure handling “retryand terminate without STR” is taken using eMPStemplate.

fh-retry-and-term-wo-str-emps

Indicates the number of times failure handling“terminate” is taken using eMPS template.

h-terminate-emps

Indicates the number of times failure handling“terminate without STR” is taken using eMPStemplate.

fh-terminate-wo-str-emps

ePDG Schema

The following bulk statistic is added in the ePDG schema to indicate the IMEI validation failure.


The total number of sessions disconnected due toInvalid IMEI received from the UE.

sess-disconnect-invalid-imei

ICSR Schema

This section displays the new bulk statistc added for the ICSR Switchover Configuration Support for SFFailures feature.


Indicates the reason for the ICSR switchover.switchover reason

MME Schema

The following bulk statistics are added in the MME schema in support of the 5G Non Standalone (NSA)feature.


The current total number of attached Subscriberswhich are capable of operating in DCNR.

attached-dcnr-subscriber

The current total number of Subscribers which arecapable of operating in DCNR and in connected state.

connected-dcnr-subscriber

The current total number of Subscribers which arecapable of operating in DCNR and in idle state.

idle-dcnr-subscriber


Bulk Statistics Changes Quick ReferenceNew Bulk Statistics


The total number of Attach Request received withDCNR supported.

dcnr-attach-req

The total number of Attach Accept sent with DCNRallowed.

dcnr-attach-acc-allowed

The total number of Attach Accept sent with DCNRdenied.

dcnr-attach-acc-denied

The total number of DCNR requested AttachesRejected.

dcnr-attach-rej

The total number of Attach Complete received forDCNR supported attaches.

dcnr-attach-comp

The total number of Intra-TAURequest received withDCNR supported.

dcnr-intra-tau-req

The total number of Intra-TAU Accept sent withDCNR allowed.

dcnr-intra-tau-acc-allowed

The total number of Intra-TAU Accept sent withDCNR denied.

dcnr-intra-tau-acc-denied

The total number of Intra-TAU Complete receivedfor DCNR supported requests.

dcnr-intra-tau-comp

The total number of Inter-TAURequest received withDCNR supported.

dcnr-inter-tau-req

The total number of Inter-TAU Accept sent withDCNR allowed.

dcnr-inter-tau-acc-allowed

The total number of Inter-TAU Accept sent withDCNR denied.

dcnr-inter-tau-acc-denied

The total number of DCNR requested Inter-TAUrequests Rejected.

dcnr-inter-tau-rej

The total number of Inter-TAU Complete receivedfor DCNR supported requests.

dcnr-inter-tau-comp

The total number of S1 Application Protocol - E-RABModification Indication messages received from alleNodeBs.

s1ap-recdata-eRabModInd

The total number of E-RAB ModificationConfirmation messages sent by the MME to theeNodeB.

s1ap-transdata-eRabModCfm

This proprietary counter tracks the number of bearersfor which ERAB Modification Indication messagewas sent.

erab-modification-indication-attempted




This proprietary counter tracks the number of bearersfor which ERAB Modification Indication messagewas sent.

erab-modification-indication-success

This proprietary counter tracks the number of bearersfor which ERAB Modification Indication failed asshown in ERAB Modification Indication Confirmmessage.

erab-modification-indication-failures

The total number of EPSMobilityManagement events- Path Update - attempted.

emmevent-path-update-attempt

The total number of EPSMobilityManagement events- Path Update - successes.

emmevent-path-update-success

The total number of EPSMobilityManagement events- Path Update - failures.

emmevent-path-update-failure

Indicates the number of times SGW DNS selectionprocedures are performed with DNS RR excludingNR network capability. This counter increments onlywhen the DNS RR with +nc-nr is absent.

dcnr-dns-sgw-selection-common

Indicates the number of times SGW DNS selectionprocedures were performed with DNS RR includingNR network capability. This counter increments onlywhen the DNS RR with +nc-nr is present.

dcnr-dns-sgw-selection-nr

Indicates the number of times SGW selectionprocedures were performed with locally configuredSGW address, without considering the NR networkcapability.

dcnr-dns-sgw-selection-local

Indicates the number of times PGW DNS selectionprocedures were performed with DNS RR excludingNR network capability. This counter increments onlywhen the DNS RR with +nc-nr is absent.

dcnr-dns-pgw-selection-common

Indicates the number of times PGW DNS selectionprocedures were performed with DNS RR includingNR network capability. This counter increments onlywhen the DNS RR with +nc-nr is present.

dcnr-dns-pgw-selection-nr

Indicates the number of times PGW selectionprocedures were performed with locally configuredPGW address, without considering the NR networkcapability.

dcnr-dns-pgw-selection-local

The following bulk statistics are new in the MME schema, and added in support of the Dedicated CoreNetworks feature.




Indicates the total number of inbound handovers from the servicearea where DCN is supported.

mme-decor-handover-srv-area-dcn

Indicates the total number of inbound handovers from the servicearea where DCN is not supported.

mme-decor-handover-srv-area-non-dcn

Indicates the number of explicit AIR messages during Attach.mme-decor-explicit-air-attach

Indicates the number of explicit AIR messages during inboundrelocation.

mme-decor-explicit-air-in-reallocation

Indicates the number of explicit AIR messages during inboundrelocation using TAU.

mme-decor-explicit-air-tau-in-reallocation

MME Decor Schema

The MME Decor schema is new in release 21.8.

The following bulk statistics for a specific DÉCOR profile are new in the MME Decor schema, and added insupport of the DECOR feature.


Indicates the name of the DECOR profile.mme-decor-profile-name

Indicates the total number of subscribers on the MME which isacting as a DCN.

mme-decor-profile-attached-subscriber

Indicates the total number of Initial Attach Requests acceptedby the MME that is acting as a DCN.

mme-decor-profile-initial-attach-req-accept

Indicates the total number of Initial Attach Requests which arererouted by the MME that is acting as a DCN.

mme-decor-profile-initial-attach-req-reroute

Indicates the total number of Initial Attach Rejects due to NoReroute Data and not handled by the MME that is acting as aDCN.

mme-decor-profile-initial-attach-req-reject

Indicates the total number of Rerouted Attach Requests whichare accepted by the MME that is acting as a DCN.

mme-decor-profile-reroute-attach-req-accept

Indicates the total number of Rerouted Attach Requests whichare rejected by the MME that is acting as a DCN.

mme-decor-profile-reroute-attach-req-reject

Indicates the total number of Initial TAU Reuquests acceptedby the MME that is acting as a DCN.

mme-decor-profile-initial-tau-req-accept

Indicates the total number of Initial TAU Reuquests which arererouted by the MME that is acting as a DCN.

mme-decor-profile-initial-tau-req-reroute

Indicates the total number of Initial TAU Rejects due to NoReroute Data and not handled by the MME that is acting as aDCN.

mme-decor-profile-initial-tau-req-reject




Indicates the total number of Rerouted TAU Requests whichare accepted by the MME that is acting as a DCN.

mme-decor-profile-reroute-tau-req-accept

Indicates the total number of Rerouted TAU Requests whichare rejected by the MME that is acting as a DCN.

mme-decor-profile-reroute-tau-req-reject

Indicates the total number of times UE Usage Type is receivedfrom the HSS and used by the MME.

mme-decor-profile-ue-usage-type-src-hss

Indicates the total number of times UE Usage Type is fetchedfrom the local DB Record and used by the MME.

mme-decor-profile-ue-usage-type-src-ue-ctxt

Indicates the total number of times UE Usage Type is receivedfrom the peer MME and used by the MME.

mme-decor-profile-ue-usage-type-src-peer-mme

Indicates the total number of times UE Usage Type is receivedfrom the peer SGSN and used by the MME.

mme-decor-profile-ue-usage-type-src-peer-sgsn

Indicates the total number of times UE Usage Type is fetchedfrom the local configuration and used by the MME.

mme-decor-profile-ue-usage-type-src-cfg

Indicates the total number of times UE Usage Type is receivedfrom the eNodeB and used by the MME.

mme-decor-profile-ue-usage-type-src-enb

Indicates the total number of times S-GW is selected throughDNS from a common pool (DNS records without UE UsageType).

mme-decor-profile-sgw-sel-dns-common

Indicates the total number of times S-GW is selected throughDNS from a dedicated pool (DNS records with matching UEUsage Type).

mme-decor-profile-sgw-sel-dns-dedicated

Indicates the total number of times S-GW is selected from thelocal configuration without UE Usage Type.

mme-decor-profile-sgw-sel-local-cfg-common

Indicates the total number of times P-GW is selected throughDNS from a common pool (DNS records without UE UsageType).

mme-decor-profile-pgw-sel-dns-common

Indicates the total number of times P-GW is selected throughDNS from a dedicated pool (DNS records with matching UEUsage Type).

mme-decor-profile-pgw-sel-dns-dedicated

Indicates the total number of times P-GW is selected from thelocal configuration without UE Usage Type.

mme-decor-profile-pgw-sel-local-cfg-common

Indicates the total number of times MME is selected throughDNS from a common pool (DNS records without UE UsageType).

mme-decor-profile-mme-sel-dns-common




Indicates the total number of times MME is selected throughDNS from a dedicated pool (DNS records with matching UEUsage Type).

mme-decor-profile-mme-sel-dns-dedicated

Indicates the total number of times MME is selected from thelocal configuration without UE Usage Type.

mme-decor-profile-mme-sel-local-cfg-common

Indicates the total number of times SGSN is selected throughDNS from a common pool (DNS records without UE UsageType).

mme-decor-profile-sgsn-sel-dns-common

Indicates the total number of times SGSN is selected throughDNS from a dedicated pool (DNS records with matching UEUsage Type).

mme-decor-profile-sgsn-sel-dns-dedicated

Indicates the total number of times SGSN is selected from thelocal configuration without UE Usage Type.

mme-decor-profile-sgsn-sel-local-cfg-common

Indicates the total number of timesMMEGI is selected throughDNS from a dedicated pool (DNS records with matching UEUsage Type).

mme-decor-profile-mmegi-sel-dns

Indicates the total number of times MMEGI is selected fromthe local configuration.

mme-decor-profile-mmegi-sel-local-cfg

Indicates the total number of times MMEGI selection failed.mme-decor-profile-mmegi-sel-fail

Indicates the number of GUTI Reallocation proceduresattempted due to UE-Usage-Type Change from HSS throughISDR OR after connected mode handover and UE-Usage-Typenot served by this MME (NAS GUTI Reallocation Commandmessage was sent by MME).

mme-decor-profile-guti-reallocation-attempted

Indicates the number of successful GUTI Reallocationprocedures.

mme-decor-profile-guti-reallocation-success

Indicates the number of failed GUTI Reallocation procedures.mme-decor-profile-guti-reallocation-failures

Indicates the number of ISDRMessages received with differentUE-Usage-Type from the HSS.

mme-decor-profile-isdr-ue-usage-type-change

Indicates the number of explicit AIR messages during Attach.mme-decor-profile-explicit-air-attach


mme-decor-profile-explicit-air-in-relocation


mme-decor-profile-explicit-air-tau-in-relocation

Indicates the total number of inbound handovers from servicearea where DCN is supported.

mme-decor-profile-handover-srv-area-dcn




Indicates the total number of inbound handovers from servicearea where DCN is not supported.

mme-decor-profile-handover-srv-area-non-dcn

P-GW Schema

The following bulk statistics are added in the P-GW schema in support of the LTE toWi-Fi (S2bGTP) SeamlessHandover feature.


Handover Statistics - Indicates the number of LTE toGTP S2b successful handovers on Timer Expiry.

handoverstat-ltetos2bgtpsucc-timerexpiry

Handover Statistics - Indicates the number of LTE toGTP S2b successful handovers on Uplink Data onS2b tunnel.

handoverstat-ltetos2bgtpsucc-uplnkdata

SAEGW Schema

The following bulk statistics are added in the SAEGW schema in support of the LTE to Wi-Fi (S2bGTP)Seamless Handover feature.


P-GW Handover Statistics - Indicates the number ofLTE to GTP S2b successful handover on TimerExpiry.

pgw-handoverstat-ltetos2bgtpsucc-timerexpiry

P-GW Handover Statistics - Indicates the number ofLTE to GTP S2b successful handover on Uplink Dataon S2b tunnel.

pgw-handoverstat-ltetos2bgtpsucc-uplnkdata

SGSN Schema

The following bulk statistics are added in the SGSN schema in support of the Triggering Iu Release CommandProcedure feature.


Total number of Iu interface release commands dueto RAB Release Request with radio lost received.

Iu-release-command-with-radio-lost-ue

Total number of Iu interface release commands dueto RAB Assignment Response with radio lostreceived.

Iu-release-command-rab-ass-rsp-with-radio-lost-ue

Modified Bulk StatisticsThis section identifies bulk statistics that have been modified in release 21.8.

Mon-Di-Net Schema


Bulk Statistics Changes Quick ReferenceModified Bulk Statistics

The following bulk statistics are added in the mon-di-net schema in support of the Monitor the VPC-DINetwork feature.


Indicates the average Control Plane loss in prior 5 minutes.cp-loss-5minave

Indicates the average Control Plane loss in prior 60 minutes.cp-loss-60minave

Indicates the average Data Plane loss in prior 5 minutes.dp-loss-5minave

Indicates the average Data Plane loss in prior 60 minutes.dp-loss-60minave

Deprecated Bulk StatisticsThis section identifies bulk statistics that are no longer supported in release 21.8.

None in this release.


Bulk Statistics Changes Quick ReferenceDeprecated Bulk Statistics


Bulk Statistics Changes Quick ReferenceDeprecated Bulk Statistics

C H A P T E R 44G Sessions in IPSG

• Feature Summary and Revision History, on page 19• Feature Changes, on page 19

Feature Summary and Revision HistorySummary Data

IPSGApplicable Product(s) or FunctionalArea

ASR 5500

VPC - DI

VPC - SI

Applicable Platform(s)

Enabled - Always-onDefault Setting

Not ApplicableRelated Changes in This Release

IPSG Administration GuideRelated Documentation

Revision History

ReleaseRevision Details

21.8.2First introduced.

Feature ChangesPrevious Behavior: 4G session were rejected when the 3GPP-Negotiated-QoS-Profile received in theAccount-Start message contained hexadecimal characters.

New Behavior: 4G calls are accepted even if the 3GPP-Negotiated-QoS-Profile received in the Account-Startmessage contains hexadecimal characters.


Customer Impact: 4G sessions will not be rejected due to hexadecimal characters present in the“3GPP-Negotiated-QoS-Profile” received in the Account-Start message.


4G Sessions in IPSGFeature Changes

C H A P T E R 55G NSA for MME

• Feature Summary and Revision History, on page 21• Feature Description, on page 22• How It Works, on page 25• Configuring 5G NSA for MME, on page 30• Monitoring and Troubleshooting, on page 34


MMEApplicable Product(s) or Functional Area

• ASR 5000

• ASR 5500

• VPC-DI

• VPC-SI


Disabled - Configuration RequiredFeature Default

Not applicableRelated Changes in This Release

• 5G Non Standalone Solution Guide

• AAA Interface Administration and Reference

• Command Line Interface Reference

• MME Administration Guide

• Statistics and Counters Reference

Related Documentation

Revision History



21.5The 5G NSA solution is qualified on the ASR 5000 platform.

21.8First introduced.

Feature DescriptionCisco 5G Non Standalone (NSA) solution leverages the existing LTE radio access and core network (EPC)as an anchor for mobility management and coverage. This solution enables operators using the Cisco EPCPacket Core to launch 5G services in shorter time and leverage existing infrastructure. Thus, NSA providesa seamless option to deploy 5G services with very less disruption in the network.

Overview

5G is the next generation of 3GPP technology, after 4G/LTE, defined for wireless mobile data communication.The 5G standards are introduced in 3GPP Release 15 to cater to the needs of 5G networks.

The two solutions defined by 3GPP for 5G networks are:

• 5GNon Standalone (NSA): The existing LTE radio access and core network (EPC) is leveraged to anchorthe 5G NR using the Dual Connectivity feature. This solution enables operators to provide 5G serviceswith shorter time and lesser cost.

The 5G NSA solution is supported in this release.Note

• 5G Standalone (SA): An all new 5G Packet Core will be introduced with several new capabilities builtinherently into it. The SA architecture comprises of 5G New Radio (5G NR) and 5G Core Network(5GC).

Network Slicing, CUPS, Virtualization, Multi-Gbps support, Ultra low latency, and other such aspectswill be natively built into the 5G SA Packet Core architecture.

Dual Connectivity

The E-UTRA-NRDual Connectivity (EN-DC) feature supports 5GNewRadio (NR)with EPC.AUE connectedto an eNodeB acts as a Master Node (MN) and an en-gNB acts as a Secondary Node (SN). The eNodeB isconnected to the EPC through the S1 interface and to the en-gNB through the X2 interface. The en-gNB canbe connected to the EPC through the S1-U interface and other en-gNBs through the X2-U interface.

The following figure illustrates the E-UTRA-NR Dual Connectivity architecture.


5G NSA for MMEFeature Description

Figure 1: EN-DC Architecture

If the UE supports dual connectivity with NR, then the UE must set the DCNR bit to "dual connectivity withNR supported" in the UE network capability IE of the Attach Request/Tracking Area Update Request message.

If the UE indicates support for dual connectivity with NR in the Attach Request/Tracking Area Update Requestmessage, and the MME decides to restrict the use of dual connectivity with NR for the UE, then the MMEsets the RestrictDCNR bit to "Use of dual connectivity with NR is restricted" in the EPS network featuresupport IE of the Attach Accept/Tracking Area Update Accept message.

If the RestrictDCNR bit is set to "Use of dual connectivity with NR is restricted" in the EPS network featuresupport IE of the Attach Accept/Tracking Area Update Accept message, the UE provides the indication thatdual connectivity with NR is restricted to the upper layers.

If the UE supports DCNR and DCNR is configured on MME, and if HSS sends ULA/IDR with"Access-Restriction" carrying "NR as Secondary RAT Not Allowed", MME sends the "NR Restriction" bitset in "Handover Restriction List" IE during Attach/TAU/Handover procedures. Similarly, MME sets theRestrictDCNR bit to "Use of dual connectivity with NR is restricted" in the EPS network feature support IEof the Attach Accept/Tracking Area Update Accept message. Accordingly, UE provides the indication thatdual connectivity with NR is restricted to the upper layers.

The "Handover Restriction List" IE is present in the "Initial Context Setup Request" message for Attach andTAU procedure with data forwarding procedure, in the "Handover Required" message for S1 handoverprocedure, in the "Downlink NAS Transport" message for TAU without active flag procedure.

The 5G NSA solution for MME supports the following functionalities:

• E-RAB Modification Procedure:

When SCG (Secondary Cell Group) bearer option is applied to support DCNR, this procedure allowsthe Master eNodeB to switch a bearer to Secondary eNodeB without changing the S1-MME association.

• NR Capable S-GW/P-GW Selection:

When DCNR capable UE attempts to register in MME and when all DCNR validations are successful(for example DCNR feature configuration on MME, HSS not sending access-restriction for NR, and soon), for dynamic S-GW and P-GW selection, MME uses the following service parameters received fromDNS server (in NAPTR response) over other service parameters to select NR capable S-GW/P-GW.

• x-3gpp-sgw:x-s5-gtp+nc-nr



• x-3gpp-pgw:x-s5-gtp+nc-nr

When the dynamic selection of S-GW/P-GW fails for any other reasons, MME falls back and selects thelocally configured S-GW/P-GW.

• Dynamic S-GW/P-GW Selection:

Dynamic S-GW and P-GW selection by MME for DCNR capable UE is supported. When a DCNRcapable UE attempts to register in MME and when all DCNR validations are successful (DCNR featureconfiguration on MME, HSS not sending access-restriction for NR, and so on), the MME sets the "UPFunction Selection Indication Flags" IE with DCNR flag set to 1 in "Create Session Request" message.This feature supports the CUPS architecture for SGW-C and PGW-C to select SGW-U and PGW-U andsupport dual connectivity with NR. When S-GW receives this IE over S11, it sends the IE over S5 toP-GW. If S-GW receives the IE in a non-CUPS deployment, it is ignored.

• URLCC QCI Support:

For Ultra-Reliable and Low Latency Communications (URLCC), MME supports — QCI 80 (Non-GBRresource type), QCI 82 (GBR resource type), and QCI 83 (GBR resource type). MME establishes thedefault bearers with URLLC QCI 80, which is typically used by low latency eMBB applications. MMEestablishes the dedicated bearers with URLLCQCI 82 and QCI 83 (also with QCI 80 if dedicated bearersof non-GBR type to be established), which is typically used by discrete automation services (industrialautomation).

• High Throughput:

5G NR offers downlink data throughput up to 20 Gbps and uplink data throughput up to 10 Gbps. Someinterfaces in EPC have the support to handle (encode/decode) 5G throughput ranges. For example, NASsupports up to 65.2 Gbps (APN-AMBR) and S5/S8/S10/S3 (GTP-v2 interfaces) support up to 4.2 Tbps.The diameter interfaces such as S6a and Gx support only up to 4.2Gbps throughput, S1-AP supportsonly up to 10 Gbps and NAS supports up to 10 Gbps (MBR, GBR). New AVP/IE are introduced in S6a,Gx , S1-AP and NAS interfaces to support 5G throughput rates. See the How It Works section for moreinformation.

• Extended QoS:

MME supports the extended QoS values towards S-GW in legacy IEs - APN-AMBR, Bearer QoS, andFlow QoS.

• Supported IEs:

S1-AP interface:

• Extended UE-AMBR Downlink

• Extended UE-AMBR Uplink

• Extended E-RAB Maximum Bit Rate Downlink

• Extended E-RAB Maximum Bit Rate Uplink

• Extended E-RAB Guaranteed Maximum Bit Rate Downlink

• Extended E-RAB Guaranteed Maximum Bit Rate Uplink

NAS interface:

• Extended EPS quality of service



• Extended APN aggregate maximum bit rate

How It Works

ArchitectureThis section describes the external interfaces required to support the 5G NSA architecture.

S6a (HSS) Interface

The S6a interface supports new AVPs "Extended-Max-Requested-BW-UL" and"Extended-Max-Requested-BW-DL" in grouped AVP "AMBR" to handle the 5G throughput ranges. Whenthe maximum bandwidth value for UL (or DL) traffic is higher than 4294967295 bits per second, the"Max-Requested-Bandwidth-UL" AVP (or DL) must be set to the upper limit 4294967295 and the"Extended-Max-Requested-BW-UL" AVP (or DL) must be set to the requested bandwidth value in kilobitsper second.

S1AP (eNodeB) Interface

Extended UE-AMBR

The S1AP interface supports new IEs "ExtendedUEAggregateMaximumBit Rate Downlink" and "ExtendedUE Aggregate Maximum Bit Rate Uplink" in the grouped IE "UE Aggregate Maximum Bit Rate", where theunits are bits/second. If the Extended UE Aggregate Maximum Bit Rate Downlink/Uplink IE is included,then the UE Aggregate Maximum Bit Rate Downlink/Uplink IE must be ignored.

Extended E-RAB MBR/GBR

The S1AP interface supports new AVPs "Extended E-RAB Maximum Bit Rate Downlink/Uplink" and"Extended E-RABGuaranteed Bit Rate Downlink/Uplink" in the "GBRQoS Information" grouped IE, wherethe units are bits/second.

NAS (UE) Interface

Extended APN Aggregate Maximum Bit Rate

The new IE "Extended APN aggregate maximum bit rate" is added in all applicable NAS messages to conveythe 5G throughput (beyond 65.2Gbps) over NAS. The existing IE inNAS "APN-AMBR" supports APN-AMBRvalues up to 65.2Gbps.

Extended EPS Quality of Service

The new IE "Extended EPS Quality of Service" is added in all applicable NAS messages to convey the 5Gthroughput (beyond 10Gbps) over NAS. The existing IE in NAS "EPS Quality of Service" supports MBRand GBR values up to 10Gbps.

LimitationsThis section describes the known limitations for the 5G NSA feature:

• DCNR for S3 interface is supported only for inbound handover of UE from 2G/3G to 4G.


5G NSA for MMEHow It Works

• MME does not support the NR capable gateway selection during connected mode inbound handoverfrom Gn-SGSN.

FlowsThis section describes the call flow procedures related to MME for 5G NSA.

Initial Registration ProcedureThe following call flow illustrates the Initial Registration procedure for DCNR capable UE.

Initial Registration of DCNR Capable UE

DescriptionStep

The DCNR capable UE sets the "DCNR bit" in NAS message "Attach Request"in "UE Network Capability" IE.

DCNR must be enabled at MME service or call control profile depending uponthe operator requirement.

1


5G NSA for MMEFlows

DescriptionStep

MME successfully authenticates the UE.2

As part of the authorization process, while sending ULR to HSS, MME advertisesthe DCNR support by sending the "NR as Secondary RAT" feature bit in"Feature-List-ID-2".

3

HSS sends ULA by advertising the DCNR by sending "NR as Secondary RAT"feature bit in "Feature-List-ID-2", "Max-Requested-Bandwidth-UL" as 4294967295bps, "Max-Requested-Bandwidth-DL" as 4294967295 bps, and the extendedbandwidth values in AVPs "Extended-Max-Requested-BW-UL" and"Extended-Max-Requested-BW-DL".

If HSS determines that the UE is not authorized for DCNR services, then HSSsends Subscription-Data with "Access-Restriction" carrying "NR as SecondaryRAT Not Allowed".

4

MME sends the Create Session Request message with the extended APN-AMBRvalues in existing AMBR IE. As the APN-AMBR values in GTPv2 interface areencoded in kbps, the existing AMBR IE handles the 5G NSA bit rates.

5

P-GW sends CCR-I to PCRF advertising the DCNR by sending"Extended-BW-NR" feature bit in "Feature-List-ID-2","APN-Aggregate-Max-Bitrate-UL" as 4294967295 bps,"APN-Aggregate-Max-Bitrate-DL" as 4294967295 bps, and the extendedbandwidth values in AVPs "Extended-APN-AMBR-UL" and"Extended-APN-AMBR-DL".

6

PCRF sends CCA-I advertising the DCNR by sending "Extended-BW-NR" featurebit in "Feature-List-ID-2", "APN-Aggregate-Max-Bitrate-UL" as 4294967295bps, "APN-Aggregate-Max-Bitrate-DL" as 4294967295 bps, and the extendedbandwidth values in AVPs "Extended-APN-AMBR-UL" and"Extended-APN-AMBR-DL". PCRF can offer the same extended APN-AMBRvalues that are requested by PCRF or modify the extended APN-AMBR values.P-GW enforces the APN-AMBR values accordingly.

7

P-GW honors the APN-AMBR values as offered by PCRF and sends the extendedAPN-AMBR values in existing APN-AMBR IE in the Create Session Responsemessage.

8


5G NSA for MMEInitial Registration Procedure

DescriptionStep

MME computes the UE-AMBR values and sends the extended UE-AMBR valuesin new IEs "ExtendedUEAggregateMaximumBit Rate Downlink" and "ExtendedUE Aggregate Maximum Bit Rate Uplink" by setting the legacy "UE AMBRUplink" and "UE AMBR Downlink" values to the maximum allowed value10000000000 bps (10 Gbps) in the "Initial Context Setup Request" message.

MME sends the APN-AMBR values up to 65.2 Gbps in existing APN-AMBR IEin NAS Activate Default EPS Bearer Context Request – Attach Accept. If theAPN-AMBRvalues are beyond 65.2 Gbps,MME sends the extendedAPN-AMBRvalues in "Extended APN Aggregate Maximum Bit Rate" IE.

If ULA is received with "Access-Restriction" carrying "NR as Secondary RATNot Allowed", MME sends the Initial Context Setup Request message with "NRRestriction" bit set in Handover Restriction List IE. MME sets the RestrictDCNRbit to "Use of dual connectivity with NR is restricted" in the EPS network featuresupport IE of the Attach Accept message. UE provides the indication that dualconnectivity with NR is restricted to the upper layers accordingly.

If the DCNR feature is not configured at MME service or call control profile, thenMME sets the RestrictDCNR bit to "Use of dual connectivity with NR is restricted"in the EPS network feature support IE of the Attach Accept message. UE providesthe indication that dual connectivity with NR is restricted to the upper layersaccordingly.

9

eNodeB sends the Initial Context Setup Response message. If master eNodeBdetermines to establish the bearer on secondary eNodeB, F-TEID of the secondaryeNodeB may be sent (transport layer address and TEID of secondary eNodeB). Itis transparent to MME if the bearer is established on master eNodeB or secondaryeNodeB.

10

eNodeB sends Uplink NAS Transport with NAS message "Complete - ActivateDefault EPS Bearer Context Accept".

11

MME sends the Modify Bearer Request message to S-GW with S1-U F-TEIDdetails as received in the Initial Context Setup Response message.

12

MME receives the Modify Bearer Response message from S-GW.13

E-RAB Modification ProcedureWhen Secondary Cell Group (SCG) bearer option is applied to support DCNR, the E-RAB Modificationprocedure is used to transfer bearer contexts to and from secondary eNodeB or secondary gNodeB.


5G NSA for MMEE-RAB Modification Procedure

Figure 2: E-RAB Modification Procedure by Master eNodeB

DescriptionStep

The master eNodeB (MeNB) sends an E-RAB Modification Indication message(eNodeB address(es) and TEIDs for downlink user plane for all the EPS bearers)to the MME. The MeNB indicates if each bearer is modified or not. The "E-RABto be Modified List" IE contains both "E-RAB to BeModified Item" and "E-RABnot to BeModified Item" IEs. For the bearer that need to be switched to secondaryeNodeB/gNodeB (SeNB), the "E-RAB to Be Modified Item" IE contains thetransport layer address of gNodeB and TEID of gNodeB.

1

The MME sends a Modify Bearer Request message (eNodeB address(es) andTEIDs for downlink user plane for all the EPS bearers) per PDN connection tothe S-GW, only for the affected PDN connections.

2

The S-GW returns a Modify Bearer Response message (S-GW address and TEIDfor uplink traffic) to theMME as a response to theModify Bearer Request message.

3

For the bearers transferred to SeNB, S-GW sends one or more end marker packetson the old path (to MeNB) immediately after switching the path.

4


5G NSA for MMEE-RAB Modification Procedure

DescriptionStep

The MME confirms E-RAB modification with the E-RABModification Confirmmessage. The MME indicates if each bearer was successfully modified, retained,unmodified or already released by the EPC.

5

Standards ComplianceCisco's implementation of the 5G NSA feature complies with the following standards:

• 3GPP 23.003 Release 15.2.0 - Numbering, addressing and identification.

• 3GPP 23.401 Release 15.2.0 - General Packet Radio Service (GPRS) enhancements for Evolved UniversalTerrestrial Radio Access Network (E-UTRAN) access

• 3GPP 29.272 Release 15.2.0 - Evolved Packet System (EPS); Mobility Management Entity (MME) andServing GPRS Support Node (SGSN) related interfaces based on Diameter protocol

• 3GPP 29.274 Release 15.2.0 - 3GPP Evolved Packet System (EPS); Evolved General Packet RadioService (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3

• 3GPP 29.303 Release 15.2.0 - Domain Name System Procedures

Configuring 5G NSA for MMEThis section describes how to configure 5G NSA to support MME.

Configuring 5G NSA on MME involves:

• Enabling DCNR in MME Service, on page 30

• Enabling DCNR in Call Control Profile, on page 31

• Configuring APN AMBR Values, on page 31

• Configuring Dedicated Bearer MBR Values, on page 32

• Configuring UE AMBR Values , on page 33

Enabling DCNR in MME ServiceUse the following configuration to enable DCNR to support 5G NSA.

configurecontext context_name

mme-service service_name

[ no ] dcnrend

NOTES:


5G NSA for MMEStandards Compliance

• mme-service service_name: Creates an MME service or configures an existing MME service in thecurrent context. service_name specifies the name of the MME service, name must be an string from 1to 63 characters.

• no: Disables the DCNR configuration.

• The dcnr CLI command is disabled by default.

Enabling DCNR in Call Control ProfileUse the following configuration to enable Dual Connectivity with New Radio (DCNR) to support 5G NonStandalone (NSA).

configurecall-control-profile profile_name

[ no | remove ] dcnrend

NOTES:

• call-control-profile profile_name: Creates an instance of a call control profile. profile_name specifiesthe name of the call control profile, it must be an string from 1 to 64 characters.

• no: Disables the DCNR configuration in the call control profile.

• remove: Removes the DCNR configuration from the call control profile.


Configuring APN AMBR ValuesUse the following configuration to configure the APN aggregate maximum bit rate (AMBR) that will be storedin the Home Subscriber Server (HSS).

configureapn-profile profile_name

qos apn-ambr max-ul mbr_up max-dl mbr_down

remove qos apn-ambrend

NOTES:

• apn-profile profile_name: Creates an instance of an access point name (APN) profile. profile_namespecifies the name of the APN profile as an alphanumeric string of 1 to 64 characters.

• qos: Configures the quality of service (QoS) parameters to be applied.

• apn-ambr: Configures the aggregate maximum bit rate (AMBR) for the APN.

• max-ul mbr_up: Defines the maximum bit rates for uplink traffic. mbr_up must be an integer from 1 to4000000000000 (4 Tbps).

• max-dl mbr_down: Defines the maximum bit rates for downlink traffic.mbr_upmust be an integer from1 to 4000000000000 (4 Tbps).

• remove: Removes the APN AMBR changes from the configuration for this APN profile.


5G NSA for MMEEnabling DCNR in Call Control Profile

Configuring Pre-Release 8 QoS Mapping QCIUse the following configuration to configuremapping of EPCQOS (non-standard QCIs) to 3GPP Pre-Release8 QOS.

configurebearer-control-profile profile_name

pre-rel8-qos-mapping qci qci_val

remove pre-rel8-qos-mapping qciend

NOTES:

• bearer-control-profile profile_name: Creates an instance of a bearer control profile. profile_namespecifies the name of the bearer control profile as an alphanumeric string of 1 to 64 characters.

• remove: Removes the DCNR configuration from the call control profile.

• qci qci_val: Specifies the QoS Class Identifier. qci_val must be an integer between 1 to 9, 65, 66, 69,70, 80, 82, and 83.

Configuring Dedicated Bearer MBR ValuesUse the following configuration to configure the quality of service maximum bit rate (MBR) values for thededicated bearer.

configureapn-profile apn_profile_name

qos dedicated-bearer mbr max-ul mbr_up max-dl mbr_down

remove qos dedicated-bearerend

NOTES:

• apn-profile apn_profile: Creates an instance of an Access Point Name (APN) profile. apn_profile_namespecifies the name of the APN profile as an alphanumeric string of 1 to 64 characters.


• dedicated-bearer mbr: Configures the maximum bit rate (MBR) for the dedicated bearer.

• max-ul mbr_up: Defines the maximum bit rate for uplink traffic. mbr_up must be an integer from 1 to4000000000000 (4 Tbps).

• max-dl mbr_down: Defines the maximum bit rate for downlink traffic. mbr_down must be an integerfrom 1 to 4000000000000 (4 Tbps).

• remove: Deletes the dedicated bearer MBR changes from the configuration for this APN profile.

Configuring Dedicated Bearer MBR ValuesUse the following configuration to configure the quality of service maximum bit rate (MBR) values for thededicated bearer.


5G NSA for MMEConfiguring Pre-Release 8 QoS Mapping QCI

configurebearer-control-profile profile_name

dedicated-bearer { mbr mbr-up mbr_up mbr-down mbr_down | gbr gbr-up gbr_up

gbr-down gbr_down

remove dedicated-bearer { gbr | mbr }end

NOTES:

• bearer-control-profile profile_name: Creates an instance of a bearer control profile. profile_namespecifies the name of the bearer control profile as an string from 1 to 64 characters.

• dedicated-bearer mbr: Configures the maximum bit rate (MBR) for the dedicated bearer.

• gbr-up gbr_up: Defines the guaranteed bit rate for uplink traffic. gbr_up must be an integer from 1 to4000000000000 (4 Tbps).

• gbr-down gbr_down: Defines the guaranteed bit rate for downlink traffic. gbr_down must be an integerfrom 1 to 4000000000000 (4 Tbps).

• mbr-up mbr_up: Defines the maximum bit rate for uplink traffic. mbr_up must be an integer from 1 to4000000000000 (4 Tbps).

• mbr-down mbr_down: Defines the maximum bit rate for downlink traffic.mbr_downmust be an integerfrom 1 to 4000000000000 (4 Tbps).

• remove: Deletes the dedicated bearer MBR changes from the configuration for this bearer control profile.

Configuring UE AMBR ValuesUse the following configuration to configure the values for aggregate maximum bit rate stored on the UE (UEAMBR).


qos ue-ambr { max-ul mbr_up max-dl mbr_down }remove qos ue-ambrend

NOTES:

• call-control-profile profile_name: Creates an instance of a call control profile. profile_name specifiesthe name of a call control profile entered as an alphanumeric string of 1 to 64 characters.


• ue-ambr: Configures the aggregate maximum bit rate stored on the UE (UE AMBR).

• max-ul mbr_up: Defines the maximum bit rate for uplink traffic. mbr_up must be an integer from 1 to4000000000000 (4 Tbps).

• max-dl mbr_down: Defines the maximum bit rate for uplink traffic. mbr_down must be an integer from1 to 4000000000000 (4 Tbps).

• remove: Deletes the configuration from the call control profile.


5G NSA for MMEConfiguring UE AMBR Values

Monitoring and TroubleshootingThis section provides information regarding show commands and bulk statistics available to monitor andtroubleshoot the 5G NSA feature.

Show Commands and Outputs

show mme-service db record imsi

The output of this command includes the following fields:

ARD:

• Dual-Connectivity-NR-not-allowed—Displays True or False to identify if the ARD received from HSSindicates the DCNR feature is allowed for the given IMSI or not.

show mme-service name <mme_svc_name>

The output of this command includes the "DCNR" field to indicate if the DCNR feature is enabled or disabledat MME service.

show mme-service session full all


UE DC-NR Information:

• DC-NR capable UE — Indicates whether the UE is DCNR capable.

• DC-NR operation allowed— Indicates whether the DCNR operation is allowed by MME for the DCNRcapable UE.

show mme-service statistics

• Dual Connectivity with NR Statistics:

Attach Procedure

• Attach Request Rcvd — The number of Attach Request messages received with UE advertisingDCNR support.

• Attach Acc DCNR allowed — The number of Attach Accept messages sent by the MMEacknowledging the DCNR support for UE (Restrict DCNR bit not set in Attach Accept).

• Attach Acc DCNR denied — The number of Attach Accepts sent by MME rejecting the DCNRsupport for the UE (Restrict DCNR bit set in Attach Accept).

• Attach Reject Sent — The number of Attach Reject messages sent by MME whose correspondingAttach Request messages have DCNR support capability.

• Attach Complete Rcvd — The number of Attach Complete messages received by MME whosecorresponding Attach Request messages have DCNR support capability.


5G NSA for MMEMonitoring and Troubleshooting

Intra-MME TAU Procedure

• TAU Request Rcvd — The number of TAU Request messages received for Intra-MME TAUprocedure with UE advertising DCNR support.

• TAU Accept DCNR allowed — The number of TAU Accept messages sent by the MMEacknowledging the DCNR support for UE (Restrict DCNR bit not set in TAUAccept) for Intra-MMETAU procedure.

• TAU Accept DCNR denied — The number of TAU Accept messages sent by the MME rejectingthe DCNR support for UE (Restrict DCNR bit set in TAU Accept) for Intra-MME TAU procedure.

• TAU Complete Rcvd — The number of TAU Complete messages received by the MME whosecorresponding Intra-MME TAU Requests have DCNR support capability.

Inter-MME TAU Procedure

• TAU Request Rcvd — The number of TAU Request messages received for Inter-MME TAUprocedure with UE advertising DCNR support.

• TAU Accept DCNR allowed — The number of TAU Accept messages sent by the MMEacknowledging the DCNR support for UE (Restrict DCNR bit not set in TAUAccept) for Inter-MMETAU procedure.

• TAU Accept DCNR denied — The number of TAU Accept messages sent by the MME rejectingthe DCNR support for UE (Restrict DCNR bit set in TAU Accept) for Inter-MME TAU procedure.

• TAU Reject Sent — The number of TAU Reject messages sent by the MME whose correspondingInter-MME TAU Requests have DCNR support capability.

• TAU Complete Rcvd — The number of TAU Complete messages received by the MME whosecorresponding Inter-MME TAU Requests have DCNR support capability.

Dual Connectivity with NR Subscribers

• Attached Calls — The number of DCNR supported UEs attached with the MME.

• Connected Calls — The number of DCNR supported UEs in connected mode at the MME.

• Idle Calls — The number of DCNR supported UEs in idle mode at the MME.

Node Selection:

SGW DNS:

• Common — The number of times S-GW DNS selection procedures are performed with DNS RRexcluding the NR network capability.

• NR Capable — The number of times S-GW DNS selection procedures are performed with DNSRR including the NR network capability.

SGW Local Config

• Common—The number of times S-GW selection procedures are performed with locally configuredS-GW address, without considering the NR network capability.

PGW DNS:


5G NSA for MMEShow Commands and Outputs

• Common — The number of times P-GW DNS selection procedures are performed with DNS RRexcluding the NR network capability.

• NR Capable — The number of times P-GW DNS selection procedures are performed with DNSRR including the NR network capability.

PGW Local Config:

• Common—The number of times P-GW selection procedures are performed with locally configuredP-GW address, without considering the NR network capability.

When UE is defined with "UE usage type" and "NR Capable", S-GW/P-GW viaDNS is selected in the following order:

1. MME chooses S-GW/P-GW that support both +ue and +nr services.

2. If step 1 fails, MME selects S-GW/P-GW that supports +nr service only.

3. If step 2 fails, MME selects S-GW/P-GW that supports +ue service only.

4. If step 3 fails, MME selects S-GW/P-GW without +nr or +ue service.

Important

• Handover Statistics:

• Bearer Statistics

• ERAB Modification Indication

• Attempted — The number of bearers for which the E-RAB Modification Indicationprocedure is attempted (bearer level stats).

• Success—The number of bearers for which the E-RABModification Indication procedurehas succeeded (bearer level stats).

• Failures—The number of bearers for which the E-RABModification Indication procedurehas failed (bearer level stats).

show mme-service statistics s1ap


S1AP Statistics:

Transmitted S1AP Data:

• E-RAB Modification Cfm — Indicates the number of E-RAB Modification Confirm messages sent byMME upon successful E-RAB modification procedure.

Received S1AP Data

• E-RAB Mod Ind — Indicates the number of E-RAB Modification Indication messages received fromthe master eNodeB.


5G NSA for MMEShow Commands and Outputs

show subscribers mme-service

The output of this command includes the "DCNR Devices" field to indicate the number of DCNR devicesthat are attached to the MME.

Bulk StatisticsThis section provides information on the bulk statistics for the 5G NSA feature on MME.

MME SchemaThe following 5G NSA feature related bulk statistics are available in the MME schema.


The current total number of attached subscriberscapable of operating in DCNR.

attached-dcnr-subscriber

The current total number of subscribers capable ofoperating in DCNR and in connected state.

connected-dcnr-subscriber

The current total number of subscribers capable ofoperating in DCNR and in idle state.

idle-dcnr-subscriber

The total number of Attach Request messages that arereceived with DCNR supported.

dcnr-attach-req

The total number of Attach Accept messages that aresent with DCNR allowed.

dcnr-attach-acc-allowed

The total number of Attach Accept messages that aresent with DCNR denied.

dcnr-attach-acc-denied

The total number of DCNR requested Attach Rejectedmessages.

dcnr-attach-rej

The total number of Attach Complete messages thatare received for DCNR supported attaches.

dcnr-attach-comp

The total number of Intra-TAURequest messages thatare received with DCNR supported.

dcnr-intra-tau-req

The total number of Intra-TAU Accept messages thatare sent with DCNR allowed.

dcnr-intra-tau-acc-allowed

The total number of Intra-TAU Accept messages thatare sent with DCNR denied.

dcnr-intra-tau-acc-denied

The total number of Intra-TAU Complete messagesthat are received for DCNR supported requests.

dcnr-intra-tau-comp

The total number of Inter-TAURequest messages thatare received with DCNR supported.

dcnr-inter-tau-req


5G NSA for MMEBulk Statistics


The total number of Inter-TAU Accept messages thatare sent with DCNR allowed.

dcnr-inter-tau-acc-allowed

The total number of Inter-TAU Accept messages thatare sent with DCNR denied.

dcnr-inter-tau-acc-denied

The total number of DCNR requested Inter-TAURequest messages that are rejected.

dcnr-inter-tau-rej

The total number of Inter-TAU Complete messagesthat are received for DCNR supported requests.

dcnr-inter-tau-comp

The total number of S1 Application Protocol - E-RABModification Indication messages received from alleNodeBs.

s1ap-recdata-eRabModInd

The total number of E-RAB ModificationConfirmation messages sent by the MME to theeNodeB.

s1ap-transdata-eRabModCfm

The total number of bearers for which E-RABModification Indication messages were sent.

erab-modification-indication-attempted

The total number of bearers for which E-RABModification Indication messages were sent.

erab-modification-indication-success

The total number of bearers for which E-RABModification Indication failed as shown in E-RABModification Indication Confirm message.

erab-modification-indication-failures

The total number of EPSMobilityManagement events- Path Update attempted.

emmevent-path-update-attempt

The total number of EPSMobilityManagement events- Path Update successes.

emmevent-path-update-success

The total number of EPSMobilityManagement events- Path Update failures.

emmevent-path-update-failure

The total number of times S-GW DNS selectionprocedures are performed with DNS RR excludingNR network capability.

dcnr-dns-sgw-selection-common

The total number of times S-GW DNS selectionprocedures were performed with DNS RR includingNR network capability.

dcnr-dns-sgw-selection-nr

The total number of times S-GW selection procedureswere performed with locally configured S-GWaddress, without considering the NR networkcapability.

dcnr-dns-sgw-selection-local


5G NSA for MMEMME Schema


The total number of times P-GW DNS selectionprocedures were performed with DNS RR excludingNR network capability.

dcnr-dns-pgw-selection-common

The total number of times P-GW DNS selectionprocedures were performed with DNS RR includingNR network capability.

dcnr-dns-pgw-selection-nr

The total number of times P-GW selection procedureswere performed with locally configured P-GWaddress, without considering the NR networkcapability.

dcnr-dns-pgw-selection-local



C H A P T E R 65G NSA for SAEGW

• Feature Summary and Revision History, on page 41• Feature Description, on page 43• How It Works, on page 45• Configuring 5G NSA for SAEGW, on page 49• Monitoring and Troubleshooting, on page 53


• P-GW

• S-GW

• SAEGW

Applicable Product(s) or Functional Area

• ASR 5000

• ASR 5500

• VPC-DI

• VPC-SI





• 5G Non Standalone Solution Guide

• AAA Interface Administration and Reference


• P-GW Administration Guide

• S-GW Administration Guide

• SAEGW Administration Guide



Revision History

21.11The 5GNSA solution for SAEGWsupports dcca-custom1, dcca-custom7and dcca-custom8 dictionaries additionally.

21.10The 5G NSA solution for SAEGW supports the following functionalityin this release:

• P-GW Custom Dictionaries support over Gz for extended bitrate

• S-GW Custom Dictionaries support over Gz for extended bitrate

• P-GW Custom Dictionaries support over Gy and Rf for extendedbitrate

• S-GW support of Secondary RAT Data Usage Report in Gz CDRs


• P-GW support of Secondary RAT Data Usage Report in Gz CDRs

• P-GW support of Secondary RAT Data Usage Report in Rf CDRs

• S-GW and P-GW support of statistics for DCNR PDNs

21.5The 5G NSA solution is qualified on the ASR 5000 platform.


• Feature License

• Dedicated Bearers

• Gy interface

• URLLC QCI



5G NSA for SAEGWFeature Summary and Revision History

Feature DescriptionCisco 5G Non Standalone (NSA) solution leverages the existing LTE radio access and core network (EPC)as an anchor for mobility management and coverage. This solution enables operators using the Cisco EPCPacket Core to launch 5G services in shorter time and leverage existing infrastructure. Thus, NSA providesa seamless option to deploy 5G services with very less disruption in the network.

Overview

5G is the next generation of 3GPP technology, after 4G/LTE, defined for wireless mobile data communication.The 5G standards are introduced in 3GPP Release 15 to cater to the needs of 5G networks.

The two solutions defined by 3GPP for 5G networks are:

• 5GNon Standalone (NSA): The existing LTE radio access and core network (EPC) is leveraged to anchorthe 5G NR using the Dual Connectivity feature. This solution enables operators to provide 5G serviceswith shorter time and lesser cost.

The 5G NSA solution is supported in this release.Note

• 5G Standalone (SA): An all new 5G Packet Core will be introduced with several new capabilities builtinherently into it. The SA architecture comprises of 5G New Radio (5G NR) and 5G Core Network(5GC).

Network Slicing, CUPS, Visualization, Multi-Gbps support, Ultra low latency, and other such aspectswill be natively built into the 5G SA Packet Core architecture.

Dual Connectivity

The E-UTRA-NRDual Connectivity (EN-DC) feature supports 5GNewRadio (NR)with EPC.AUE connectedto an eNodeB acts as a Master Node (MN) and an en-gNB acts as a Secondary Node (SN). The eNodeB isconnected to the EPC through the S1 interface and to the en-gNB through the X2 interface. The en-gNB canbe connected to the EPC through the S1-U interface and other en-gNBs through the X2-U interface.

The following figure illustrates the E-UTRA-NR Dual Connectivity architecture.


5G NSA for SAEGWFeature Description

Figure 3: EN-DC Architecture

If the UE supports dual connectivity with NR, then the UE must set the DCNR bit to "dual connectivity withNR supported" in the UE network capability IE of the Attach Request/Tracking Area Update Request message.

If the UE indicates support for dual connectivity with NR in the Attach Request/Tracking Area Update Requestmessage, and the MME decides to restrict the use of dual connectivity with NR for the UE, then the MMEsets the RestrictDCNR bit to "Use of dual connectivity with NR is restricted" in the EPS network featuresupport IE of the Attach Accept/Tracking Area Update Accept message.

If the RestrictDCNR bit is set to "Use of dual connectivity with NR is restricted" in the EPS network featuresupport IE of the Attach Accept/Tracking Area Update Accept message, the UE provides the indication thatdual connectivity with NR is restricted to the upper layers.

If the UE supports DCNR and DCNR is configured on MME, and if HSS sends ULA/IDR with"Access-Restriction" carrying "NR as Secondary RAT Not Allowed", MME sends the "NR Restriction" bitset in "Handover Restriction List" IE during Attach/TAU/Handover procedures. Similarly, MME sets theRestrictDCNR bit to "Use of dual connectivity with NR is restricted" in the EPS network feature support IEof the Attach Accept/Tracking Area Update Accept message. Accordingly, UE provides the indication thatdual connectivity with NR is restricted to the upper layers.

The "Handover Restriction List" IE is present in the "Initial Context Setup Request" message for Attach andTAU procedure with data forwarding procedure, in the "Handover Required" message for S1 handoverprocedure, in the "Downlink NAS Transport" message for TAU without active flag procedure.

5G NSA feature is license controlled from release 21.8 onwards. Contact your Cisco account representativefor detailed information on specific licensing requirements.

Important

The 5G NSA solution for SAEGW supports the following functionalists:

• High Throughput

5G NR offers downlink data throughput up to 20 Gbps and uplink data throughput up to 10 Gbps. Someinterfaces in EPC have the support to handle (encode/decode) 5G throughput. For example, NAS supportsup to 65.2 Gbps (APN-AMBR) and S5/S8/S10/S3 (GTP-v2 interfaces) support up to 4.2 Tbps. Thediameter interfaces S6a and Gx support only up to 4.2Gbps throughput, S1-AP supports only up to 10


5G NSA for SAEGWFeature Description

Gbps and NAS supports up to 10 Gbps (MBR, GBR). New AVP/IE have been introduced in S6a, Gx ,S1-AP, and NAS interfaces to support 5G throughput. See theHow It Works section for more information.

• DCNR Support on P-GW:

Supports configuration of DCNR feature at the P-GW-service, by configuring “Extended-BW-NR”feature in IMSA service. Advertises the DCNR feature support by sending “Extended-BW-NR” featurebit in “Feature-List-ID-2” towards PCRF. Forwards AVP "Extended-APN-AMBR-UL" and"Extended-APN-AMBR-DL" in CCRmessageswhen it receivesAPN-AMBRvalues greater than 4.2Gbpsfrom MME/S-GW. Decodes the extended AVP "Extended-APN-AMBR-UL" and"Extended-APN-AMBR-DL" when it is received from PCRF.

• Sends AVP "Extended-Max-Requested-BW-UL", "Extended-Max-Requested-BW-DL","Extended-GBR-UL" and "Extended-GBR-DL" when it receives MBR and GBR values greater than4.2Gbps from MME/S-GW. Decodes the AVP "Extended-Max-Requested-BW-UL","Extended-Max-Requested-BW-DL", "Extended-GBR-UL" and "Extended-GBR-DL" when receivedfrom PCRF. Supports dedicated bearer establishment with extended QoS. Sends AVPExtended-Max-Requested-BW-UL and "Extended-Max-Requested-BW-DL" in Gy records.

• Ultra Low Latency Support:

Supports 5G requirements of Ultra-Reliable and Low Latency Communications (URLLC). 3GPPintroduced URLCC QCI 80 (Non-GBR resource type), QCI 82 and 83 (GBR resource type). P-GWestablishes default bearers with URLLC QCI 80, which is typically used by low latency eMBBapplications. P-GW establishes dedicated bearers with URLLC QCI 82 and 83 (also with QCI 80 ifdedicated bearers of Non-GBR type to be established), which is typically used by discrete automationservices (industrial automation).

• Dynamic S-GW and P-GW selection by MME for DCNR capable UE

When DCNR capable UE attempts to register in MME and when all DCNR validations are successful(for example DCNR feature configuration on MME, HSS not sending access-restriction for NR, and sonon), the MME sets “UP Function Selection Indication Flags” IE with DCNR flag set to 1 in “CreateSession Request” message. This feature is relevant for CUPS architecture to help SGW-C and PGW-Cto select SGW-U and PGW-U which supports dual connectivity with NR. When S-GW receives this IEover S11, it sends this IE over S5 to P-GW. S-GW ignores IE if it receives it in Non-CUPS deployment.

How It Works

ArchitectureThis section describes the architecture for Gx (PCRF), Gy (OCS), Gz (P-GW), and Rf (P-GW) interfaces withrespect to 5G NSA for SEAEGW feature.

Gx (PCRF)

The Gx interface supports new AVPs to handle 5G throughput for default bearers and dedicated bearers. Gxinterface introduced new "AVP Extended-APN-AMBR-UL" and "Extended-APN-AMBR-DL" in grouped"AVPQoS-Information" and "Conditional-APN-Aggregate-Max-Bitrate" to handle 5G throughput for defaultbearers. New AVPs "Extended-GBR-UL", "Extended-GBR-DL", "Extended-Max-Requested-BW-UL" and"Extended-Max-Requested-BW-DL" are added in grouped AVP "QoS-Information" for dedicated bearers.


5G NSA for SAEGWHow It Works

When the maximum bandwidth value set for UL or DL traffic is higher than 4294967295 bits per second, the"Max-Requested-Bandwidth-UL" or DL, AVP must be present, and set to its upper limit 4294967295 alongwith the "Extended-Max-Requested-BW-UL" or DL must be present, and set to the requested bandwidthvalue in kilobits per second. The same principal applies for "Extended-GBR-UL/DL" and"Extended-APN-AMBR-UL/DL".

The following new AVPs are introduced in the grouped AVP QoS-Information:

• Extended-Max-Requested-BW-UL

• Extended-Max-Requested-BW-DL

• Extended-GBR-UL

• Extended-GBR-DL

• Extended-APN-AMBR-UL

• Extended-APN-AMBR-DL

the following new AVPs are introduced in the grouped AVP Conditional-APN-Aggregate-Max-Bitrate.

• Extended-APN-AMBR-UL

• Extended-APN-AMBR-DL

Gy (OCS)

New AVPs "Extended-Max-Request-BW-UL", "Extended-Max-Requested-BW-DL", "Extended-GBR-UL","Extended-GBR-DL", "Extended-APN-AMBR-UL" and "Extended-APN-AMBR-DL" in grouped AVP“QoS-Information” are introduced Gy interface to handle 5G throughput for dedicated bearers.

When the maximum bandwidth value set for UL/DL traffic is higher than 4294967295 bits per second, P-GWsets the "Max-Requested-Bandwidth-UL/DL" AVP to its upper limit 4294967295 and sets the"Extended-Max-Requested-BW-UL/DL" to the required bandwidth value in kilobits per second inCCR-I/CCR-U messages. The same principal applies for "Extended-GBR-UL/DL" and"Extended-APN-AMBR-UL/DL".

5G NSA feature supports Gy dcca-custom1, dcca-custom7, dcca-custom8 and standard dcca-custom13dictionaries.

Gz(S-GW)

New sequence of container in SGWRecord for SGW-CDR to support RAN secondary RAT usage data reportis introduced in Gz interface. AVPs "listOfRANSecondaryRATUsageReports" and"RANSecondaryRATUsageReport" are introduced.

NewAVPs "Extended-Max-Requested-BW-UL", "Extended-Max-Requested-BW-DL", "Extended-GBR-UL","Extended-GBR-DL", "Extended-APN-AMBR-UL" and "Extended-APN-AMBR-DL" are introduced overGz interface as part of existing "EPCQoSInformation" AVP to handle 5G throughput for default and dedicatedbearers.

LimitationsThis section describes the known limitations for 5G NSA feature


5G NSA for SAEGWLimitations

• 5G NSA has been implemented for Gy dictionaries dcca-custom1, dcca-custom7, dcca-custom8 andstandard dcca-custom13. In order to support NSA for other Gx and Gy dictionaries, dynamic dictionarymust be built. Contact your Cisco Account representative for more details.

FlowsThis section describes the following call flows related to the DCNR feature.

Initial Registration by DCNR Capable UE

DescriptionStep

The DCNR capable UE sets the "DCNR bit" in the NAS message "Attach Request"of "UE Network Capability" IE.

1

MME successfully authenticates the UE.2

As part of the authorization process, while sending ULR to HSS, MME advertisesthe DCNR support by sending “NR as Secondary RAT" feature bit in“Feature-List-ID-2".

3

HSS sends ULA by advertising the DCNR by sending "NR as Secondary RAT" featurebit in “Feature-List-ID-2" and sends Max-Requested-Bandwidth-UL as 4294967295bps, Max-Requested-Bandwidth-DL as 4294967295 bps and the extended bandwidthvalues in new AVPs "Extended-Max-Requested-BW-UL" and"Extended-Max-Requested-BW-DL".

If HSS determines that the UE is not authorized for DCNR services, HSS sendsSubscription-Data with “Access-Restriction" carrying “NR as Secondary RAT NotAllowed".

4

MME sends Create Session Request with the extended APN-AMBR values in existingAMBR IE. As the APN-AMBR values in GTP-v2 interface are encoded in kbps, theexisting AMBR IE handles the 5G NSA bit rates.

5


5G NSA for SAEGWFlows

DescriptionStep

P-W sends CCR-I to PCRF advertising the DCNR by sending “Extended-BW-NR"feature bit in “Feature-List-ID-2". P-GWalso sends "APN-Aggregate-Max-Bitrate-UL"as 4294967295 bps, "APN-Aggregate-Max-Bitrate-DL" as 4294967295 bps and theextended bandwidth values in new AVPs "Extended-APN-AMBR-UL" and"Extended-APN-AMBR-DL".

6

PCRF sends CCA-I advertising the DCNR by sending the “Extended-BW-NR" featurebit in “Feature-List-ID-2". PCRF also sends "APN-Aggregate-Max-Bitrate-UL" as4294967295 bps and "APN-Aggregate-Max-Bitrate-DL" as 4294967295 bps and theextended bandwidth values in new "AVPs Extended-APN-AMBR-UL" and"Extended-APN-AMBR-DL". PCRF offers the same extended APN-AMBR valuesrequested by PCEF or modify the extended APN-AMBR values. P-GW enforces theAPN-AMBR values accordingly.

7

P-GW honors the APN-AMBR values as offered by PCRF and sends the extendedAPN-AMBR values in existing IE APN-AMBR in the Create Session Responsemessage.

8

MME computes the UE-AMBR values and sends the extended UE-AMBR values innew IEs “Extended UE Aggregate Maximum Bit Rate Downlink" and “Extended UEAggregate Maximum Bit Rate Uplink" by setting the legacy “UE AMBR Uplink"and “UE AMBR Downlink" values to the maximum allowed value 10000000000bps(10 Gbps) in Initial Context Setup Request.

MME sends the APN-AMBR values up to 65.2 Gbps in existing IE APN-AMBR inNAS Activate Default EPS Bearer Context Request – Attach Accept. If theAPN-AMBR values are beyond 65.2 Gbps, MME sends the extended APN-AMBRvalues in new IE “Extended APN aggregate maximum bit rate.

If ULA is received with “Access-Restriction" carrying “NR as Secondary RAT NotAllowed", MME sends the “Initial Context Setup Request" with “NR Restriction" bitset in “Handover Restriction List" IE. AlsoMME sets the "RestrictDCNR" bit to "Useof dual connectivity with NR is restricted" in the EPS network feature support IE ofthe Attach Accept message. Accordingly, UE provides the indication that DCNR isrestricted to the upper layers.

If DCNR is not configured at MME service or call control profile level, MME setsthe RestrictDCNR bit to "Use of dual connectivity with NR is restricted" in the EPSnetwork feature support IE of the Attach Accept message. Accordingly, UE providesthe indication that DCNR is restricted to the upper layers.

9

eNodeB sends the Initial Context Setup Response message. If master eNodeBdetermines to establish the bearer on secondary eNodeB, F-TEID of secondary eNodeBmay be sent in this step (Transport layer address and TEID of secondary eNodeB). Itis transparent to MME if the bearer is established on master eNodeB or secondaryeNodeB.

10

eNodeB sends Uplink NAS Transport with NASmessage Attach Complete - ActivateDefault EPS Bearer Context Accept.

11

MME sends Modify Bearer Request to S-GW with S1-U FTEID details as receivedin the Initial Context Setup Response message.

12


5G NSA for SAEGWFlows

DescriptionStep

MME receives the Modify Bearer Response message from S-GW.13

Supported StandardsCisco's implementation of the 5G NSA complies with the following standards:


• 3GPP 29.212 Release 15.2.0 - Policy and Charging Control (PCC)

• 3GPP 29.274 Release 15.2.0 - 3GPP Evolved Packet System (EPS); Evolved General Packet RadioService (GPRS) Tunneling Protocol for Control plane (GTPv2-C); Stage 3

Configuring 5G NSA for SAEGWThis section describes how to configure 5G NSA to support SAEGW.

Configuring 5G NSA on SAEGW involves:

• Enabling DCNR in P-GW Service, on page 49

• Configuring Bearer Duration Statistics for URLLC QCI, on page 50

• Configuring EGTPC QCI Statistics for URLLC QCI, on page 50

• Configuring Extended Bandwidth with New Radio, on page 51

• Configuring Network-Initiated Setup/Teardown Events for URLLC QCI, on page 51

• Configuring URLLC QCI in APN Configuration, on page 52

• Configuring URLCC QCI In Charging Action, on page 52

• Configuring URLCC QCI in QCI QOS Mapping Table , on page 53

Enabling DCNR in P-GW ServiceUse the following configuration to enable Dual Connectivity with New Radio (DCNR) to support 5G NonStandalone (NSA).


pgw-service service_name

[ no ] dcnrend

NOTES:

• pgw-service service_name: Creates an P-GW service or configures a existing P-GW service. service_namemust be an alphanumeric string of 1 to 63 characters.


5G NSA for SAEGWSupported Standards

• no: Disables the DCNR configuration.


Configuring Bearer Duration Statistics for URLLC QCIUse the following configuration to configure QCI based duration statistics for URLLC QCI.


apn apn_name

[ no ] bearer-duration-stats qci qci_val

end

NOTES:

• apn apn_name: Creates or deletes Access Point Name (APN) templates and enters the APNConfigurationMode within the current context. apn_name specifies a name for the APN template as an alphanumericstring of 1 through 62 characters that is case insensitive.

• bearer-duration-stats: Enables or disables per QCI call duration statistics for dedicated bearers.

• qci qci_val: Specifies the QoS Class Identifier. qci_val must be an integer between 1 to 9, 80, 82, and83.

• no: Disables per QCI call duration statistics.

Configuring EGTPC QCI Statistics for URLLC QCIUse the following configuration to configure QCI based EGTPC QCI statistics for URLLC QCI.


apn apn_name

[ no ] egtpc-qci-stats { qci80 | qci82 | qci83 }default egtpc-qci-statsend

Notes:

• apn apn_name: Creates or deletes Access Point Name (APN) templates and enters the APNConfigurationMode within the current context. apn_name specifies a name for the APN template as an alphanumericstring of 1 through 62 characters that is case insensitive.

• egtpc-qci-stats: Enables/Disables an APN candidate list for the apn-expansion bulkstats schema.

• qci80: Configure apn-qci-egtpc statistics for QCI 80.



• no: Disables APN candidate list(s) for the apn-expansion bulkstats schema.

• default: Disables an APN candidate list for the apn-expansion bulkstats schema.


5G NSA for SAEGWConfiguring Bearer Duration Statistics for URLLC QCI

Configuring Extended Bandwidth with New RadioUse the following configuration to configure extended bandwidth with new radio in IMS authorization servicemode.


ims-auth-service ims_auth_service_name

policy-controldiameter encode-supported-features extended-bw-newradio[ no ] diameter encode-supported-featuresend

NOTES:

• ims-auth-service ims_auth_service_name: Creates an IMS authentication service. ims_auth_service_namemust be an alphanumeric string of 1 through 63 characters.

• policy-control: Configures Diameter authorization and policy control parameter for IMS authorization.

• extended-bw-newradio: Enables extended bandwidth with New-Radio feature.

• diameter encode-supported-features: Enables/Disables encoding and sending of Supported-FeaturesAVP.

• no: Removes the configuration of extended bandwidth with new-radio in IMS authorization servicemode.

Configuring Network-Initiated Setup/Teardown Events for URLLC QCIUse the following configuration to configure network initiated setup or teardown events KPI for URLCCQCI.

configuretransaction-rate nw-initiated-setup-teardown-events qci qci_val

[ default | no ] transaction-rate nw-initiated-setup-teardown-eventsqci

end

NOTES:

• transaction-rate nw-initiated-setup-teardown-events: Enables operators to set the Quality of ClassIdentifier (QCI) value for use in tracking Network Initiated Setup/Tear down Events per Second keyperformance indicator (KPI) information.

• qci qci_val: Specifies the QoS Class Identifier. qci_val must be an integer between 1 to 9, 65, 66, 69,70, 80, 82, 83, and 128 to 254.

• no: Disables the collection of network-initiated setup/teardown events for the specified QCI value.

• default: Returns the setting to its default value. The default is for network-initiated setup/teardown eventsto be tracked for all supported QCI values.


5G NSA for SAEGWConfiguring Extended Bandwidth with New Radio

Configuring URLLC QCI in APN ConfigurationUse the following configuration to configure URLCC QCI in the APN Configuration mode.


apn apn_name

qos rate-limit direction { downlink | uplink } qci qci_val

no qos rate-limit direction { downlink | uplink }end

NOTES:

• apn apn_name: Allows to specify the APN name as a condition. apn_name must be an alphanumericstring of 1 through 63 characters.

• qos rate-limit: Configures the action on a subscriber traffic flow that violates or exceeds thepeak/committed data rate under traffic shaping and policing functionality.

• direction { downlink | uplink }: Specifies the direction of traffic on which this QoS configuration needsto be applied.

• downlink: Apply the specified limits and actions to the downlink.

• uplink: Apply the specified limits and actions to the uplink.

• qci qci_val: Specifies the QoS Class Identifier. qci_val must be an integer between 1 to 9, 80, 82, and83.

• no: Disables the QoS data rate limit configuration for the APN.

Configuring URLCC QCI In Charging ActionUse the following configuration to configure URLCC QCI in the Charging Action Configuration mode.

configureactive-charging service service_name

charging-action charging_action_name

qos-class-identifier qos_class_identifier

no qos-class-identifierend

NOTES:

• active-charging service service_name: Specifies name of the active charging service. service_namemust be an alphanumeric string of 1 through 15 characters.

• charging-action charging_action_name : Creates a charging action. qos_class_identifier must be analphanumeric string of 1 through 63 characters.

• qos-class-identifier qos_class_identifier: Specifies the QoS Class Identifier. qos_class_identifier mustbe an integer between 1 to 9, 65, 66, 69, 70, 80, 82, and 83.

• no: Disables the QoS Class Identifier.


5G NSA for SAEGWConfiguring URLLC QCI in APN Configuration

Configuring URLCC QCI in QCI QOS Mapping TableUse the following configuration to configure URLCC QCI in the QCI QOS Mapping Table.

configureqci-qos-mapping name

[ no ] qci qci_value

end

NOTES:

• qci-qos-mapping name: Specifies the map name. name must be an alphanumeric string of 1 through 63characters.

• qci qci_val: Specifies the QoS Class Identifier. qci_val must be an integer between 1 to 9, 65, 66, 69,70, 80, 82, and 83.

• no: Disables the QCI value.

Monitoring and TroubleshootingThis section provides information regarding show commands and bulk statistics available to monitor andtroubleshoot the 5G NSA feature.

Show Commands and OutputsThis section provides information on show commands and their corresponding outputs for the DCNR feature.

show pgw-service name

The output of this command includes the "DCNR" field to indicate if the DCNR feature is enabled or disabledat P-GW service.

show ims-authorization service name


Diameter Policy Control:

Supported Features:

• extended-bw-nr

show gtpu statistics


• Uplink Packets — Displays the total number of QCI 80, QCI 82, and QCI 83 uplink packets.

• Uplink Bytes — Displays the total number of QCI 80, QCI 82, and QCI 83 uplink bytes.

• Downlink Packets — Displays the total number of QCI 80, QCI 82, and QCI 83 downlink packets.

• Downlink Bytes — Displays the total number of QCI 80, QCI 82, and QCI 83 downlink bytes.


5G NSA for SAEGWConfiguring URLCC QCI in QCI QOS Mapping Table

• Packets Discarded — Displays the total number of discarded QCI 80, QCI 82, and QCI 83 packets.

• Bytes Discarded — Displays the total number of discarded QCI 80, QCI 82, and QCI 83 bytes.

show apn statistics all


4G Bearers Released By Reasons:

Admin disconnect — Displays dedicated bearers released due to administration clear from P-GW for QCI80, QCI 82, and QCI 83.

• Bearer Active — Displays the total number for QCI 80, QCI 82, and QCI 83 active bearers.

• Bearer setup — Displays the total number for QCI 80, QCI 82, and QCI 83 bearers setup.

• Bearer Released — Displays the total number for QCI 80, QCI 82, and QCI 83 released bearers.

• Bearer Rejected —

• Uplink Bytes Forwarded — Displays the total number for QCI 80, QCI 82, and QCI 83 uplink packetsforwarded.

• Uplink pkts forwarded — Displays the total number for QCI 80, QCI 82, and QCI 83 downlink packetsforwarded.

• Uplink Bytes dropped — Displays the total number for QCI 80, QCI 82, and QCI 83 uplink bytesforwarded.

• Downlink Bytes forwarded — Displays the total number for QCI 80, QCI 82, and QCI 83 downlinkbytes forwarded.

• Uplink pkts dropped — Displays the total number for QCI 80, QCI 82, and QCI 83 uplink packetsdropped.

• Downlink Bytes dropped — Displays the total number for QCI 80, QCI 82, and QCI 83 downlink bytesdropped.

• Uplink Bytes dropped(MBR Excd)—Displays the total number for QCI 80, QCI 82, and QCI 83 uplinkbytes dropped due to MBR being exceeded.

• Uplink pkts dropped(MBR Excd) — Displays the total number for QCI 80, QCI 82, and QCI 83 uplinkpackets dropped due to MBR being exceeded.

• Downlink pkts forwarded—Displays the total number for QCI 80, QCI 82, and QCI 83 downlink packetsforwarded.

• Downlink pkts dropped—Displays the total number for QCI 80, QCI 82, and QCI 83 downlink packetsdropped.

• Downlink Bytes dropped(MBR Excd) — Displays the total number for QCI 80, QCI 82, and QCI 83downlink bytes dropped due to MBR being exceeded.

• Downlink pkts dropped(MBR Excd) — Displays the total number for QCI 80, QCI 82, and QCI 83downlink packets dropped due to MBR being exceeded.


5G NSA for SAEGWShow Commands and Outputs

show pgw-service statistics all verbose


Bearers By QoS characteristics:

• Active — Displays the total number of active bearers for QCI 80, QCI 82, and QCI 83.

• Released — Displays the total number of bearers released for QCI 80, QCI 82, and QCI 83.

• Setup — Displays the total number of bearers setup for QCI 80, QCI 82, and QCI 83.

Data Statistics Per PDN-Type:

Uplink:

• Packets — Displays the total number of uplink packets forwarded for QCI 80, QCI 82, and QCI 83.

• Bytes — Displays the total number of uplink bytes forwarded for QCI 80, QCI 82, and QCI 83.

• Dropped Packets — Displays the total number of uplink packets dropped for QCI 80, QCI 82, and QCI83.

• Dropped Bytes — Displays the total number of uplink bytes dropped for QCI 80, QCI 82, and QCI 83.

Downlink:

• Packets — Displays the total number of downlink packets forwarded for QCI 80, QCI 82, and QCI 83.

• Bytes — Displays the total number of downlink bytes forwarded for QCI 80, QCI 82, and QCI 83.

• Dropped Packets — Displays the total number of downlink packets dropped for QCI 80, QCI 82, andQCI 83.

• Dropped Bytes — Displays the total number of downlink bytes dropped for QCI 80, QCI 82, and QCI83.

show sgw-service statistics all verbose



• Active — Displays the total active EPS Bearers for QCI 80, QCI 82, and QCI 83.

• Released — Displays the total number of EPS Bearers released for QCI 80, QCI 82, and QCI 83.

• Setup — Displays the total number of EPS bearers setup for QCI 80, QCI 82, and QCI 83.

• Modified — Displays the total number of EPS bearers modified for QCI 80, QCI 82, and QCI 83.

Dedicated Bearers Released By Reason:

• P-GW Initiated — Displays the total number of dedicated EPS bearers for QCI 80, QCI 82, and QCI 83released with the reason P-GW initiated on the S-GW.

• S1 Error Indication— Displays the total number of dedicated EPS bearers for QCI 80, QCI 82, and QCI83 released with the reason S1 error indication on the S-GW.





• S12 Error Indication — Displays the total number of dedicated EPS bearers for QCI 80, QCI 82, andQCI 83 released with the reason S12 error indication on the S-GW.

• Local — Displays the total number of dedicated EPS bearers for QCI 80, QCI 82, and QCI 83 releasedwith the reason local error indication on the S-GW.

• PDN Down — Displays the total number of dedicated EPS bearers for QCI 80, QCI 82, and QCI 83released due to PDN cleanup on the S-GW.

• Path Failure S1-U — Displays the total number of dedicated EPS bearers for QCI 80, QCI 82, and QCI83 released with the reason S1-U path failure on the S-GW.

• Path Failure S5-U — Displays the total number of dedicated EPS bearers for QCI 80, QCI 82, and QCI83 released with the reason S5-U path failure on the S-GW.

• Path Failure S5 — Displays the total number of dedicated EPS bearers for QCI 80, QCI 82, and QCI 83released with the reason S5 path failure on the S-GW.

• Path Failure S11 — Displays the total number of dedicated bearers for QCI 80, QCI 82, and QCI 83released due to path failure on the S11 interface.

• Path Failure S4-U — Displays the total number of dedicated bearers for QCI 80, QCI 82, and QCI 83released due to path failure on S4-U interface.

• Path Failure S12 — Displays the total number of dedicated bearers for QCI 80, QCI 82, and QCI 83released due to path failure on S12 interface.

• Inactivity Timeout — Displays the total number of dedicated bearers for QCI 80, QCI 82, and QCI 83released due to the inactivity timeout.

• Other — Displays the total number of dedicated bearers for QCI 80, QCI 82, and QCI 83 released dueto other reasons.

Data Statistics Per Interface:

S1-U/S11-U/S4-U/S12/S5-U/S8-U Total Data Statistics:

Uplink:

• Packets — Displays the total number of uplink data packets received by the S-GW for a bearer with QCI80, QCI 82, and QCI 83.

• Bytes — Displays the total number of uplink data bytes received by the S-GW for a bearer with QCI 80,QCI 82, and QCI 83.

• Dropped Packets — Displays the total number of uplink data packets dropped by the S-GW for a bearerwith a QCI 80, QCI 82, and QCI 83.

• Dropped Bytes—Displays the total number of uplink data bytes dropped by the S-GW for a bearer withQCI 80, QCI 82, and QCI 83.

Downlink:



• Packets — Displays the total number of downlink data packets received by the S-GW for a bearer withQCI 80, QCI 82, and QCI 83.

• Bytes — Displays the total number of downlink data bytes received by the S-GW for a bearer with QCI80, QCI 82, and QCI 83.

• Dropped Packets—Displays the total number of downlink data packets dropped by the S-GW for bearerwith QCI 80, QCI 82, and QCI 83.

• Dropped Bytes — Displays the total number of downlink data bytes dropped by the S-GW for a bearerwith QCI 80, QCI 82, and QCI 83.

show saegw-service statistics all verbose



• Active — Displays the total number of QCI 80, QCI 82, and QCI 83 active bearers.

• Released — Displays the total number of QCI 80, QCI 82, and QCI 83 released bearers.

• Setup — Displays the total number of QCI 80, QCI 82, and QCI 83 bearers setup.

Data Statistics Per PDN-Type:

Uplink:

• Packets — Displays the total number of QCI 80, QCI 82, and QCI 83 uplink packets forwarded.

• Bytes — Displays the total number of QCI 80, QCI 82, and QCI 83 uplink bytes forwarded.

• Dropped Packets — Displays the total number of QCI 80, QCI 82, and QCI 83 uplink packets dropped.

• Dropped Bytes — Displays the total number of QCI 80, QCI 82, and QCI 83 uplink bytes dropped.

Downlink:

• Packets — Displays the total number of QCI 80, QCI 82, and QCI 83 downlink packets forwarded.

• Bytes — Displays the total number of QCI 80, QCI 82, and QCI 83 downlink bytes forwarded.

• Dropped Packets—Displays the total number of QCI 80, QCI 82, and QCI 83 downlink packets dropped.

• Dropped Bytes — Displays the total number of QCI 80, QCI 82, and QCI 83 downlink bytes dropped.

Bulk StatisticsThe following statistics are added in support of the 5G NSA feature.

APN SchemaThe following 5G NSA feature related bulk statistics are available in the APN schema.


The total number of QCI80 active bearers.qci80-actbear


5G NSA for SAEGWBulk Statistics




The total number of QCI80 bearers setup.qci80-setupbear



The total number of QCI80 released bearers.qci80-relbear



The total number of QCI80 uplink packets forwarded.qci80-uplinkpkt-fwd



The total number of QCI80 downlink packetsforwarded.

qci80-dwlinkpkt-fwd


qci82-dwlinkpkt-fwd


qci83-dwlinkpkt-fwd

The total number of QCI80 uplink bytes forwarded.qci80-uplinkbyte-fwd



The total number of QCI80 downlink bytes forwarded.qci80-dwlinkbyte-fwd



The total number of QCI80 uplink packets dropped.qci80-uplinkpkt-drop



The total number of QCI80 downlink packets dropped.qci80-dwlinkpkt-drop




5G NSA for SAEGWAPN Schema


The total number of QCI80 uplink bytes dropped.qci80-uplinkbyte-drop



The total number of QCI80 downlink bytes dropped.qci80-dwlinkbyte-drop



The total number of QCI80 uplink packets droppeddue to MBR being exceeded.

qci80-uplinkpkt-drop-mbrexcd





The total number of QCI80 downlink packets droppeddue to MBR being exceeded.

qci80-dwlinkpkt-drop-mbrexcd





The total number of QCI80 uplink bytes dropped dueto MBR being exceeded.

qci80-uplinkbyte-drop-mbrexcd






qci80-dwlinkbyte-drop-mbrexcd





The total number of QCI80 rejected bearers.qci80-rejbearer




5G NSA for SAEGWAPN Schema


The total number dedicated bearers released due toadmin clear from P-GW for QCI80.

sessstat-bearrel-ded-admin-clear-qci80





System SchemaThe following 5G NSA feature related bulk statistics are available in the System schema.


The current number of bearer sessions with a durationof 5 seconds and having a QCI of 80.

sess-bearerdur-5sec-qci80

















The current number of bearer sessions with a durationof 1 minute and having a QCI of 80.

sess-bearerdur-1min-qci80






5G NSA for SAEGWSystem Schema


The current number of bearer sessions with a durationof 2 minutes and having a QCI of 80.
























The current number of bearer sessions with a durationof 1 hour and having a QCI of 80.

sess-bearerdur-1hr-qci80





The current number of bearer sessions with a durationof 4 hours and having a QCI of 80.





















The current number of bearer sessions with a durationof over 24 hours and having a QCI of 80.

sess-bearerdur-over24hr-qci80





The current number of bearer sessions with a durationof 2 days and having a QCI of 80.

sess-bearerdur-2day-qci80



















C H A P T E R 7API-based VNFM Upgrade Process

• Feature Summary and Revision History, on page 63• Feature Description, on page 64• VNFM Upgrade Workflow, on page 64• Initiating the VNFM Upgrade, on page 66• Limitations, on page 69


AllApplicable Product(s) or FunctionalArea

UGPApplicable Platform(s)

Disabled - Configuration requiredFeature Default

Not ApplicableRelated Features in this Release

• Ultra Gateway Platform System Administration Guide

• Ultra M Solutions Guide

• Ultra Services Platform Deployment Automation Guide


Revision History




Feature Description

In 6.2, this feature was not fully qualified and was made available only for testing purposes. For moreinformation, contact your Cisco Accounts representative.

Important

In releases prior to 6.2, the USP-based VNF would have to be completely terminated in order to perform anupgrade of the ESC-based VNFM.

With this release, the ESC-based VNFM can optionally be upgraded as part of a rolling patch upgrade processin order to preserve the operational state of the VNF and UAS deployments.

The VNFM upgrade process is supported for Ultra M deployments that leverage the Hyper-Convergedarchitecture and for stand-alone AutoVNF deployments.

Important

VNFM Upgrade WorkflowThis section describes the sequence in which the rolling patch upgrade of VNFM occurs.

Figure 4: VNFM Upgrade Process Flow, on page 65 illustrates the VNFM upgrade process for Ultra Mdeployments. For stand-aloneAutoVNF deployments, the upgrade software image is uploaded to the onboardingserver (step 1) and the upgrade command is executed from AutoVNF (step 3).


API-based VNFM Upgrade ProcessFeature Description

Figure 4: VNFM Upgrade Process Flow

1. Onboard the new USP ISO containing the VNFM upgrade image to the Ultra M Manager node.

2. Update the deployment network service descriptor (NSD) to identify the new package and onboard it.

nsd nsd_name_including_vnfm_vnfd

vnf-package [ previous_package_desriptor_name upgrade_package_descriptor_name ]

Package information is defined in the VNF package descriptor (vnf-packaged) as follows:<---SNIP--->vnf-packaged <upgrade_package_descriptor_name>

location <package_url>

validate-signature falseconfiguration starosexternal-url /home/ubuntu/system.cfg

<---SNIP--->

The package must then be referenced in the virtual descriptor unit (VDU) pertaining to the UEM:<---SNIP--->vdu escvdu-type cisco-esclogin-credential esc_loginnetconf-credential esc_netconfimage vnf-packagevnf-rack vnf-rack1vnf-package primary <upgrade_package_descriptor_name>

vnf-package secondary <previous_package_descriptor_name>


API-based VNFM Upgrade ProcessVNFM Upgrade Workflow

…<---SNIP--->

The secondary image is used as a fallback in the event an issue is encountered through the upgrade process.If no secondary image is specified, the upgrade process will stop and generate an error log.

Important

3. The rolling upgrade request is triggered through AutoDeploy which initiates the process with AutoVNF.

4. AutoVNF determines which VNFM VM is active and which is standby by communicating with eachof the VMs over the management interface.

5. AutoVNF triggers the shutdown of the standby VNFM via the VIM.

6. AutoVNF waits until the VIM confirms that the standby VNFM VM has been completely terminated.

7. AutoVNF initiates the deployment of a new VNFM VM via the VIM using the upgrade image. TheVNFM VM is deployed in standby mode.

8. The standby VNFM VM synchronizes data with the active VNFM VM.

9. AutoVNF waits until the VIM confirms that the new VM has been deployed and is in standby mode.If it detects that there is an issue with the VM, AutoVNF re-initiates the VNFM VM with the previousimage. If no issues are detected, AutoVNF proceeds with the upgrade process.

10. Repeat the steps 4, on page 66 to 7, on page 66 for the VNFM VM that is currently active.

Initiating the VNFM UpgradeVNFM upgrades are initiated through a remote procedure call (RPC) executed from the ConfD command lineinterface (CLI) or via a NETCONF API.

Via the CLITo perform an upgrade using the CLI, log in to AutoDeploy (Ultra M deployments) or AutoVNF (stand-aloneAutoVNF deployments) as the ConfD CLI admin user and execute the following command:

update-sw nsd-id <nsd_name> rolling { true | false } vnfd <vnfd_name>

vnf-package <pkg_id>

NOTES:

• <nsd_name> and <vnfd_name> are the names of the network service descriptor (NSD) file and VNFdescriptor (VNFD) (respectively) in which the VNF component (VNFC) for the VNFMVNF componentis defined.

• If the rolling false operator is used, the upgrade terminates the entire deployment. In this scenario, thevnfd<vnfd_name> operator should not be included in the command. If it is included, a transaction IDfor the upgrade is generated and failed. The AutoVNF upstart log reflects this status.

• <pkg_id> is the name of the USP ISO containing the upgraded VNFM VM image.

• Ensure that the upgrade package is defined as a VNF package descriptor within the NSD and that it isspecified as the primary package in the VNFM VDU configuration.


API-based VNFM Upgrade ProcessInitiating the VNFM Upgrade

• Ensure that the current (pre-upgrade) package is specified as the secondary package in the VNFM VDUconfiguration in order to provide rollback support in the event of errors.

Via the NETCONF APIOperation: nsd:update-sw

Namespace: xmlns:nsd="http://www.cisco.com/usp/nfv/usp-nsds"

Parameters:

DescriptionTypeRequiredParameter Name

NSD namestringMnsd

Specifies if the rolling isenabled (true) /disabled(false)

booleanMrolling

VNFD name, mandatoryin case of rolling upgrade

stringMvnfd

Package descriptor namethat should be used toupdate the vnfd instancementioned by “vnfd”

stringMpackage

NOTES:


• Ensure that the upgrade package is defined as a VNF package descriptor within the NSD and that it isspecified as the primary package in the VNFM VDU configuration.

• Ensure that the current (pre-upgrade) package is specified as the secondary package in the VNFM VDUconfiguration in order to provide rollback support in the event of errors.

Example RPC

<nc:rpc message-id="urn:uuid:bac690a2-08af-4c9f-8765-3c907d6e12ba" <nsdxmlns="http://www.cisco.com/usp/nfv/usp-nsds">

<nsd-id>fremont-autovnf</nsd-id><vim-identity>vim1</vim-identity><vnfd xmlns="http://www.cisco.com/usp/nfv/usp-nsds"><vnfd-id>esc</vnfd-id><vnf-type>esc</vnf-type><version>6.0</version><configuration><boot-time>1800</boot-time><set-vim-instance-name>true</set-vim-instance-name>

</configuration><external-connection-point><vnfc>esc</vnfc><connection-point>eth0</connection-point>


API-based VNFM Upgrade ProcessVia the NETCONF API

</external-connection-point><high-availability>true</high-availability><vnfc><vnfc-id>esc</vnfc-id><health-check><enabled>false</enabled>

</health-check><vdu><vdu-id>esc</vdu-id>

</vdu><connection-point><connection-point-id>eth0</connection-point-id><virtual-link><service-vl>mgmt</service-vl>

</virtual-link></connection-point><connection-point><connection-point-id>eth1</connection-point-id><virtual-link><service-vl>orch</service-vl>

</virtual-link></connection-point>

</vnfc></vnfd>

</nsd><vim xmlns="http://www.cisco.com/usp/nfv/usp-uas-common"><vim-id>vim1</vim-id><api-version>v2</api-version><auth-url>http://172.21.201.218:5000/v2.0</auth-url><user>vim-admin-creds</user><tenant>abcxyz</tenant>

</vim><secure-token xmlns="http://www.cisco.com/usp/nfv/usp-secure-token"><secure-id>vim-admin-creds</secure-id><user>abcxyz</user><password>******</password>

</secure-token><vdu xmlns="http://www.cisco.com/usp/nfv/usp-uas-common"><vdu-id>esc</vdu-id><vdu-type>cisco-esc</vdu-type><flavor><vcpus>2</vcpus><ram>4096</ram><root-disk>40</root-disk><ephemeral-disk>0</ephemeral-disk><swap-disk>0</swap-disk>

</flavor><login-credential>esc_login</login-credential><netconf-credential>esc_netconf</netconf-credential><image><vnf-package>usp_throttle</vnf-package>

</image><vnf-rack>abcxyz-vnf-rack</vnf-rack><vnf-package><primary>usp_6_2t</primary><secondary>usp_throttle</secondary>

</vnf-package><volume/>

</vdu><secure-token xmlns="http://www.cisco.com/usp/nfv/usp-secure-token"><secure-id>esc_login</secure-id><user>admin</user><password>******</password>

</secure-token>


API-based VNFM Upgrade ProcessVia the NETCONF API

<secure-token xmlns="http://www.cisco.com/usp/nfv/usp-secure-token"><secure-id>esc_netconf</secure-id><user>admin</user><password>******</password>

</secure-token><vnf-packaged xmlns="http://www.cisco.com/usp/nfv/usp-uas-common"><vnf-package-id>usp_throttle</vnf-package-id><location>http://192.168.200.61:5000/isos/fremont-autovnf_usp_throttle</location><validate-signature>false</validate-signature><configuration><name>staros</name>

<external-url>http://192.168.200.61:5000/isos/fremont-autovnf_usp_throttle_staros</external-url>

</configuration></vnf-packaged>

</config>

LimitationsThe following limitations exist with the VNFM upgrade feature:

• This functionality is only available after upgrading to the 6.2 release.

• The rolling VNFM patch upgrade process can only be used to upgrade to new releases that have acompatible database schema. As new releases become available, Cisco will provide information as towhether or not this functionality can be used to perform the upgrade.

• For Ultra M deployments, AutoDeploy and AutoIT must be upgraded before using this functionality.Upgrading these products will terminate the VNF deployment.

• For stand-alone AutoVNF deployments, AutoVNF must be upgraded before using this functionality.Upgrading these products will terminate the VNF deployment.

• Make sure there are no additional operations running while performing an upgrade/rolling upgradeprocess.

• Upgrade/rolling upgrade procedure should be done only in a maintenance window.


API-based VNFM Upgrade ProcessLimitations


API-based VNFM Upgrade ProcessLimitations

C H A P T E R 8API-based AutoDeploy, AutoIT and AutoVNFUpgrade Process

• Feature Summary and Revision History, on page 71• Feature Description (AutoDeploy and AutoIT), on page 72• AutoDeploy and AutoIT Upgrade Workflow, on page 72• Upgrading AutoDeploy or AutoIT, on page 72• Feature Description (AutoVNF), on page 73• AutoVNF Upgrade Workflow, on page 74• Initiating the AutoVNF Upgrade, on page 75• Limitations, on page 78










Revision History




Feature Description (AutoDeploy and AutoIT)


Important

In releases prior to 6.2, the USP-based VNF would have to be completely terminated in order to perform anupgrade of AutoDeploy and AutoIT.

With this release, these UAS modules can optionally be upgraded as part of a rolling upgrade process in orderto preserve the operational state of the VNF and UAS deployments. The rolling upgrade process is possibleas long as the AutoDeploy and AutoIT were deployed in high availability (HA) mode. This allows their CDBsto be synchronized between the active and standby instances.

The AutoDeploy and AutoIT rolling upgrade processes are supported for Ultra M deployments that leveragethe Hyper-Converged architecture and for stand-alone AutoVNF deployments.

Important

AutoDeploy and AutoIT Upgrade WorkflowThe rolling upgrade process for AutoDeploy and AutoIT occurs as follows:

1. Onboard the new USP ISO containing the UAS upgrade image to the Ultra M Manager node.

2. The rolling upgrade is triggered via a script on baremetal server or undercloud system, wherever theAutoDeploy/AutoIT is deployed.

3. The script terminates the first AutoDeploy or AutoIT VM instance.

4. Upon successful termination of the VM, the script deploys a new VM instance. If it detects that there isan issue with the VM, the script re-initiates the VM with the previous image. If no issues are detected,the script proceeds with the upgrade process.

5. Repeat the steps 3, on page 72 and 4, on page 72 for the second AutoDeploy or AutoIT VM instance.

If AutoDeploy and AutoIT were not deployed with HA mode enabled, or if you prefer to perform an upgradethrough a complete reinstall, you must first terminate the current installation using the information andinstructions in the Ultra Services Platform Deployment Automation Guide.

Important

Upgrading AutoDeploy or AutoITAutoDeploy and AutoIT upgrades are performed by executing a script manually.

1. Log on to the AutoDeploy VM as the root user.


API-based AutoDeploy, AutoIT and AutoVNF Upgrade ProcessFeature Description (AutoDeploy and AutoIT)

2. Initiate the upgrade from another VM:

a. Execute the upgrade script:

./boot_uas.py --kvm { --autodeploy | --autoit } --upgrade-uas

b. Enter the password for the user ubuntu at the prompt.

c. Enter the path and name for the upgrade image at the prompt.

3. Upon completion of the upgrade, check the software version.

a. Login to the ConfD CLI as the admin user.

confd_cli –u admin –C

b. View the status.

show uas

Example command output:uas version 6.2.0uas state activeuas external-connection-point 172.28.185.132INSTANCE IP STATE ROLE-------------------------------------172.28.185.133 alive CONFD-MASTER172.28.185.134 alive CONFD-SLAVE

NAME LAST HEARTBEAT------------------------------------AutoIT-MASTER 2018-03-24 21:24:30USPCFMWorker 2018-03-24 21:24:30USPCHBWorker 2018-03-24 21:24:30USPCWorker 2018-03-24 21:24:30

Feature Description (AutoVNF)


Important

In releases prior to 6.2, the USP-based VNF would have to be completely terminated in order to perform anupgrade of AutoVNF.

With this release, AutoVNF can optionally be upgraded as part of a rolling upgrade process in order to preservethe operational state of the VNF and UAS deployments.

The AutoVNF upgrade process is supported for Ultra M deployments that leverage the Hyper-Convergedarchitecture and for stand-alone AutoVNF deployments.

Important


API-based AutoDeploy, AutoIT and AutoVNF Upgrade ProcessFeature Description (AutoVNF)

AutoVNF Upgrade WorkflowThis section describes the sequence in which the AutoVNF upgrade procedure will be performed.

Figure 5: AutoVNF Upgrade Process Flow, on page 74 illustrates the AutoVNF upgrade process for UltraM deployments. For stand-alone AutoVNF deployments, the upgrade software image is uploaded to theonboarding server (step 1) and the upgrade command is executed from AutoVNF (step 3).

Figure 5: AutoVNF Upgrade Process Flow

1. Onboard the new USP ISO containing the UAS upgrade image to the Ultra M Manager node.







<---SNIP--->


API-based AutoDeploy, AutoIT and AutoVNF Upgrade ProcessAutoVNF Upgrade Workflow

The package must then be referenced in the virtual descriptor unit (VDU) pertaining to the UEM:<---SNIP--->vdu autovnfvdu-type automation-servicelogin-credential autovnf_loginscm scmimage vnf-packagevnf-rack vnf-rack1vnf-package primary <upgrade_package_descriptor_name>

vnf-package secondary <previous_package_descriptor_name>…<---SNIP--->


Important

3. The rolling upgrade request is triggered through AutoDeploy which initiates the process with the VIMthrough AutoIT.

4. AutoIT determines which AutoVNF VM is active and which is standby by communicating with eachof the VMs over the management interface.

5. AutoIT triggers the shutdown of the standby AutoVNF VM via the VIM.

6. AutoIT waits until the VIM confirms that the standby AutoVNF VM has been completely terminated.

7. AutoIT initiates the deployment of a new AutoVNF VM via the VIM using the upgrade image. TheAutoVNF VM is deployed in standby mode.

8. The standby AutoVNF VM synchronizes data with the active AutoVNF VM.

9. AutoIT waits until the VIM confirms that the new VM has been deployed and is in standby mode. If itdetects that there is an issue with the VM, AutoIT re-initiates the AutoVNF VM with the previousimage. If no issues are detected, AutoIT proceeds with the upgrade process.

10. Repeat the steps 4, on page 75 to 7, on page 75 for the AutoVNF VM that is currently active.

Initiating the AutoVNF UpgradeAutoVNF upgrades are initiated through a remote procedure call (RPC) executed from the ConfD commandline interface (CLI) or via a NETCONF API.




NOTES:


API-based AutoDeploy, AutoIT and AutoVNF Upgrade ProcessInitiating the AutoVNF Upgrade

• <nsd_name> and <vnfd_name> are the names of the network service descriptor (NSD) file and VNFdescriptor (VNFD) (respectively) in which the VNF component (VNFC) for the VNFMVNF componentis defined.


• <pkg_id> is the name of the USP ISO containing the upgraded VNFM VM image.

• Ensure that the upgrade package is defined as a VNF package descriptor within the NSD and that it isspecified as the primary package in the AutoVNF VDU configuration.

• Ensure that the current (pre-upgrade) package is specified as the secondary package in the AutoVNFVDU configuration in order to provide rollback support in the event of errors.



Parameters:


NSD namestringMnsd


booleanMrolling


stringMvnfd


stringMpackage

NOTES:


• Ensure that the upgrade package is defined as a VNF package descriptor within the NSD and that it isspecified as the primary package in the AutoVNF VDU configuration.

• Ensure that the current (pre-upgrade) package is specified as the secondary package in the AutoVNFVDU configuration in order to provide rollback support in the event of errors.


API-based AutoDeploy, AutoIT and AutoVNF Upgrade ProcessVia the NETCONF API

Example RPC









</vnfc></vnfd>




</flavor>


API-based AutoDeploy, AutoIT and AutoVNF Upgrade ProcessVia the NETCONF API

<login-credential>esc_login</login-credential><netconf-credential>esc_netconf</netconf-credential><image><vnf-package>usp_throttle</vnf-package>




</secure-token><secure-token xmlns="http://www.cisco.com/usp/nfv/usp-secure-token"><secure-id>esc_netconf</secure-id><user>admin</user><password>******</password>




</config>

LimitationsThe following limitations exist with the API-based AutoDeploy, AutoIT and AutoVNF upgrade feature:


• Regardless of the UAS component (AutoDeploy, AutoIT, or AutoVNF), the rolling patch upgrade processcan only be used to upgrade to new releases that have a compatible database schema. As new releasesbecome available, Cisco will provide information as to whether or not this functionality can be used toperform the upgrade.

• For Ultra M deployments, AutoDeploy and AutoIT must be upgraded before using this functionality toupgrade AutoVNF. Upgrading these products will terminate the VNF deployment.




API-based AutoDeploy, AutoIT and AutoVNF Upgrade ProcessLimitations

C H A P T E R 9Automatic Disabling of Unused OpenStackServices





DisabledFeature Default






Revision History



Feature ChangesIn previous releases, the OpenStack ceilometer service was automatically started when UAS was used todeploy the VIM and VIM Orchestrator even though the system did not leverage any of its capabilities.


As of this release, in order to conserve system resources and improve performance, the ceilometer serviceand other related telemetry services like aodh and gnocchi are disabled in Ultra M setup.

Fault monitoring is automatically enabled for all OpenStack services even though the aodh, ceilometer andgnocchi OpenStack services are not supported in Ultra M setup. You have to manually exclude these servicesin your fault management configuration.

Important


Automatic Disabling of Unused OpenStack ServicesFeature Changes

C H A P T E R 10Automatic Enabling of Syslogging for CephServices





Enabled - Always-onFeature Default






Revision History



Feature ChangesPreviously, the Ultra M Manager automatically started syslogging for the following OpenStack services:

• Nova


• Cinder

• Kinder

• Glance

With this release, the following Ceph OpenStack services are also automatically started through the Ultra MManager:

• Ceph monitor (on Controller nodes)

• Ceph OSD (on OSD Compute nodes)


Automatic Enabling of Syslogging for Ceph ServicesFeature Changes

C H A P T E R 11BGP Peer Limit

• Feature Summary and Revision History, on page 83• Feature Description, on page 84• How It Works, on page 84• Configuring BGP Peer Limit, on page 84• Monitoring and Troubleshooting, on page 86


AllApplicable Product(s) or Functional Area

VPC - DIApplicable Platform(s)



Related Documentation • Command Line Interface Reference


• VPC-DI System Administration Guide

Revision History




Feature DescriptionIn the Cisco Virtualized Packet Core Distributed Instance (VPC-DI)UGP architecture, the flexibility of BGPpeering is provided across packet processing cards namely, Session Function (SF) cards, including the demuxSF cards.

In deployment setups based on “contrail” model of the SDN , each packet processing card has a vRouterwithin the compute node. In this model, with the current flexible BGP peering scheme, the BGP configurationsneeds to be implemented on each of those vRouters. This poses a challenge to service providers when thereare large number of SF cards in their network. The number of lines of configuration required, poses a scalingchallenge.

To overcome this challenge, the BGP Peer Limit feature is introduced that restricts BGP peering to only twoSF cards in the VPC-DI architecture. This feature mandates that the routing table has only two routescorresponding to the two SF cards, with a third route being a “blackhole” or a “null” route. To ensure that thenew routes are longest-prefix-match routes, provisioning of only host-addresses only (/32 bitmask) is enforced.This drastically reduces the amount of configuration and the routing table size.

How It WorksThis feature is implemented using the ip route kernel command.When configured, BGP peering is restrictedto only the two SF cards with the special route.

When the blackhole keyword is configured, it enables the kernel routing engine to block or drop packetsgoing out of the node. This is not limited to any interface and defaults to a wildcard interface.

For information on configuring the BGP Peer Limit feature, see the "Configuring BGP Peer Limit" section.

Limitations• This feature support is limited only to the context level.

• There is no support provided at the VRF level.

• This feature is supported only for IPv4.

Configuring BGP Peer LimitThe following section provides the configuration command to enable or disable the functionality.

Configuring Packet Processing Card RoutesUse the following CLI commands to add the special (static) route to any two packet processing interfaces (SFcards) defined in the context configuration.


[ no ] ip route kernel ip_address/ip_address_mask_combo egress_intrfc_name


BGP Peer LimitFeature Description

cost number

end

NOTES:

• no: Deletes the added routes.

• kernel: Allows static route in the kernel routing table options.

• ip_address/ip_address_mask_combo: Specifies a combined IP address subnet mask bits to indicatewhat IP addresses the route applies to. ip_address_mask_combo must be specified using CIDR notationwhere the IP address is specified using IPv4 dotted-decimal notation and the mask bits are a numericvalue, which is the number of bits in the subnet mask.

• egress_intrfc_name : Specifies the name of an existing egress interface as an alphanumeric string of 1through 79 characters.

• cost number : Defines the number of hops to the next gateway. The cost must be an integer from 0 through255 where 255 is the most expensive. Default is 0.

• This functionality is disabled by default.

Configuring Blackhole RouteUse the following CLI commands to block or drop packets going out of the node.


[ no ] ip route kernel ip_address/ip_address_mask_combo egress_intrfc_name

cost number blackholeend

NOTES:

• no: Deletes the added routes.

• kernel: Allows static route in the kernel routing table options.

• ip_address/ip_address_mask_combo: Specifies a combined IP address subnet mask bits to indicatewhat IP addresses the route applies to. ip_address_mask_combo must be specified using CIDR notationwhere the IP address is specified using IPv4 dotted-decimal notation and the mask bits are a numericvalue, which is the number of bits in the subnet mask.

• egress_intrfc_name : Specifies the name of an existing egress interface as an alphanumeric string of 1through 79 characters. The default is “*”, that is, a wildcard interface.

• cost number : Defines the number of hops to the next gateway. The cost must be an integer from 0 through255 where 255 is the most expensive. The default is 0.

• blackhole: Defines the blackhole route to install in the kernel to to block or drop packets.

• This functionality is disabled by default.


BGP Peer LimitConfiguring Blackhole Route

Monitoring and TroubleshootingThis section provides information regarding the CLI command available in support of monitoring andtroubleshooting the feature.

Show Command(s) and/or OutputsThis section provides information regarding the show command and/or its output in support of this feature.

show ip routeThis show command CLI now includes the value for the following new field when a static route is added toany two packet processing interfaces (SF cards).

kernel-only


BGP Peer LimitMonitoring and Troubleshooting

C H A P T E R 12Cisco Ultra Traffic Optimization

This chapter describes the following topics:

• Feature Summary and Revision History, on page 87• Overview, on page 88• How Cisco Ultra Traffic Optimization Works, on page 88• Configuring Cisco Ultra Traffic Optimization, on page 91• Multi-Policy Support for Traffic Optimization, on page 97• Monitoring and Troubleshooting, on page 103


Applicable Product(s) or Functional Area • IPSG

• P-GW

Applicable Platform(s) • ASR 5500

• Ultra Gateway Platform

Disabled - License RequiredFeature Default



• IPSG Administration Guide

Revision History


21.8With this release, Cisco Ultra Traffic Optimization is qualified on IPSG.


OverviewIn a high-bandwidth bulk data flow scenario, user experience is impacted due to various wireless networkconditions and policies like shaping, throttling, and other bottlenecks that induce congestion, especially in theRAN. This results in TCP applying its saw-tooth algorithm for congestion control and impacts user experience,and overall system capacity is not fully utilized.

The Cisco Ultra Traffic Optimization solution provides clientless optimization of TCP and HTTP traffic. Thissolution is integrated with Cisco P-GW and has the following benefits:

• Increases the capacity of existing cell sites and therefore, enables more traffic transmission.

• Improves Quality of Experience (QoE) of users by providing more bits per second.

• Provides instantaneous stabilizing andmaximizing per subscriber throughput, particularly during networkcongestion.

How Cisco Ultra Traffic Optimization WorksThe Cisco Ultra Traffic Optimization achieves its gains by shaping video traffic during times of high networkload/congestion. It monitors and profiles each individual video flow that passes through the gateway and usesits machine learning algorithms to determine whether that flow is traversing a congested channel. Cisco UltraTraffic Optimization then flow-controls video to varying levels and time, depending on the degree of detectedcongestion, and efficiently aligns delivery of the video traffic to less-congested moments while still providingadequate bandwidth to videos to maintain their quality. The result is less network latency and higher userthroughputs while maintaining HD video. Cisco Ultra Traffic Optimization does not drop packets or modifydata payloads in any way.

The Cisco Ultra Traffic Optimization integrates with standard Cisco P-GW functions such as ApplicationDetection and Control (ADC), allowing mobile operators to define optimization policies that are based on thetraffic application type as well as APN, QCI, and other common traffic delineations. Cisco Ultra TrafficOptimization is fully radio network aware, allowing management on a per eNodeB cell basis.

ArchitectureStarOS has a highly optimized packet processing framework, the Cisco Ultra Traffic Optimization engine,where the user packets (downlink) are processed in the operating systems user space. The high-speed packetprocessing, including the various functions of the P-GW, is performed in the user space. The Cisco UltraTraffic Optimization engine is integrated into the packet processing path of Cisco’s P-GWwith a well-definedApplication Programming Interface (API) of StarOS.

The following graphic shows a high-level overview of P-GW packet flow with traffic optimization.


Cisco Ultra Traffic OptimizationOverview

Handling of Traffic Optimization Data RecordThe Traffic Optimization Data Record (TODR) is generated only on the expiry of idle-timeout of the CiscoUltra Traffic Optimization engine. No statistics related to session or flow from P-GW is included in thisTODR. The data records are a separate file for the Traffic Optimization statistics, and available to externalanalytics platform.

List of Attributes and File FormatAll TODR attributes of traffic optimization is enabled by a single CLI command. The output is always commaseparated, and in a rigid format.

Standard TODR

The following is the format of a Standard TODR:instance_id,flow_type,srcIP,dstIP,policy_id, proto_type, dscp,flow_first_pkt_rx_time_ms,flow_last_pkt_rx_time_ms,flow_cumulative_rx_bytes

Example:

1,0,173.39.13.38,192.168.3.106,0,1,0,1489131332693,1489131335924,342292

Where:

• instance_id: Instance ID.

• flow_type: Standard flow (0)

• srcIP: Indicates the source IP address.


Cisco Ultra Traffic OptimizationHandling of Traffic Optimization Data Record

• dstIP: Indicates the destination IP address.

• policy_id: Indicates the traffic optimization policy ID.

• proto_type: Indicates the IP protocol being used. The IP protocols are: TCP and UDP.

• dscp: Indicates the DSCP code for upstream packets.

• flow_first_pkt_rx_time_ms: Indicates the timestamp when the first packet was detected during trafficoptimization.

• flow_last_pkt_rx_time_ms: Indicates the timestamp when the last packet was detected during trafficoptimization.

• flow_cumulative_rx_bytes: Indicates the number of bytes transferred by this flow.

Large TODR

The following is a sample output of a Large TODR.19,1,,22.22.0.1,1.1.1.8,custom1,2,0,1588858362158,1588858952986,16420806,1588858364162,419,351,7000,0,0,1,19:2:15,2,0,0,2,1,1,,1588858364162,80396,1472,0,0,0,2,1,,1588858366171,146942,1937,7000,0,0,2

Where:

• instance_id: Instance ID.

• flow_type: Large flow (1)

• srcIP: Indicates the source IP address.

• dstIP: Indicates the destination IP address.

• policy_name: Identifies the name of the configured traffic optimization policy.

• policy_id: Indicates the traffic optimization policy ID.

• proto_type: Indicates the IP protocol being used. The IP protocols are: TCP and UDP.

• dscp: Indicates the DSCP code for upstream packets.

• flow_first_pkt_rx_time_ms: Indicates the timestamp when the first packet was detected during trafficoptimization.

• flow_last_pkt_rx_time_ms: Indicates the timestamp when the last packet was detected during trafficoptimization.

• flow_cumulative_rx_bytes: Indicates the number of bytes transferred by this flow.

• large_detection_time_ms: Indicates the timestamp when the flow was detected as Large.

• avg_burst_rate_kbps: Indicates the average rate in Kbps of all the measured bursts.

• avg_eff_rate_kbps: Indicates the average effective rate in Kbps.

• final_link_peak_kbps: Indicates the highest detected link peak over the life of the Large flow.

• recovered_capacity_bytes: Indicates the recovered capacity in Kbps for this Large flow.

• recovered_capacity_ms: Indicates the timestamp of recovered capacity for this Large flow.


Cisco Ultra Traffic OptimizationList of Attributes and File Format

• phase_count: Indicates the Large flow phase count.

• min_gbr_kbps: Indicates the Minimum Guaranteed Bit Rate (GBR) in Kbps.

• max_gbr_kbps: Indicates the Maximum Guaranteed Bit Rate (MBR) in Kbps.

• phase_count_record: Indicates the number of phases present in this record.

• end_of_phases: 0 (not end of phases) or 1 (end of phases).

• Large flow phase attributes:

• phase_type: Indicates the type of the phase

• phase_start_time_ms: Indicates the timestamp for the start time of the phase.

• burst_bytes: Indicates the burst size in bytes.

• burst_duration_ms: Indicates the burst duration in milliseconds.

• link_peak_kbps: Indicates the peak rate for the flow during its life.

• flow_control_rate_kbps: Indicates the rate at which flow control was attempted (or 0 if non-flowcontrol phase).

• max_num_queued_packets: Identifies the maximum number of packets queued.

• policy_id: Identifies the traffic optimization policy ID.

LicensingThe Cisco Ultra Traffic Optimization is a licensed Cisco solution. Contact your Cisco account representativefor detailed information on specific licensing requirements. For information on installing and verifying licenses,refer to the Managing License Keys section of the Software Management Operations chapter in the SystemAdministration Guide.

Limitations and RestrictionsThe values which the P-GW chooses to send to the Cisco Ultra Traffic Optimization engine are the valuesassociated from the bearer GBR and bearer MBR. In the current implementation, only downlink GBR andMBR are sent to the engine for traffic optimization.

The IPSG supports only certain triggers for which the information is available with the IPSG service.

Configuring Cisco Ultra Traffic OptimizationThis section provides information on enabling support for the Cisco Ultra Traffic Optimization solution.

Loading Traffic OptimizationUse the following configuration under the Global Configuration Mode to load the Cisco Ultra TrafficOptimization as a solution:


Cisco Ultra Traffic OptimizationLicensing

configurerequire active-charging traffic-optimizationend

After you configure this command, you must save the configuration and then reload the chassis for thecommand to take effect. For information on saving the configuration file and reloading the chassis, refer tothe System Administration Guide for your deployment.

Important

Enabling or disabling the traffic optimization can be done through the Service-scheme framework.Important

After you configure the require active-charging traffic-optimization CLI command, you must save theconfiguration and then reload the chassis for the command to take effect. For information on saving theconfiguration file and reloading the chassis, refer to the System Administration Guide for your deployment.

Important

In 21.3, and 21.5 and later releases, the dependency on the chassis reboot is not valid anymore. The CiscoUltra Traffic Optimization engine is loaded by default. The Cisco Ultra Traffic Optimization configurationCLIs are available when the license is enabled. As such, the traffic-optimization keyword has been deprecated.

Important

Enabling Cisco Ultra Traffic Optimization Configuration ProfileUse the following configuration under ACSConfigurationMode to enable the Cisco Ultra Traffic Optimizationprofile:


traffic-optimization-profileend

NOTES:

• The above CLI command enables the Traffic Optimization Profile Configuration, a new configurationmode.

Configuring the Operating ModeUse the following CLI commands to configure the operating mode under Traffic Optimization ProfileConfiguration Mode for the Cisco Ultra Traffic Optimization engine:


traffic-optimization-profilemode [ active | passive ]end


Cisco Ultra Traffic OptimizationEnabling Cisco Ultra Traffic Optimization Configuration Profile

Notes:

• mode: Sets the mode of operation for traffic optimization.

• active: Active mode where both traffic optimization and flow monitoring is done on the packet.

• passive: Passive mode where no flow-control is performed but monitoring is done on the packet.

Configuring Threshold ValueUse the following CLI commands to configure the threshold value for the TCP flow to be considered for thetraffic optimization:


traffic-optimization-profileheavy-session detection-threshold bytes

end

Notes:

• detection-threshold bytes: Specifies the Detection Threshold (in bytes), beyond which it is consideredas heavy session.

bytes must be an integer from 1 to 4294967295.

For optimum traffic optimization benefits, it is recommended to set the threshold above 3 MB.

Enabling Cisco Ultra Traffic Optimization Configuration Profile UsingService-scheme Framework

The service-scheme framework is used to enable traffic optimization at APN, rule base, QCI, and Rule level.There are two main constructs for the service-scheme framework:

• Subscriber-base – This helps in associating subscribers with service-scheme based on the subs-classconfiguration.

• subs-class – The conditions defined under subs-class enables in classifying the subscribers basedon rule base, APN, v-APN name. The conditions can also be defined in combination, and both ORas well as AND operators are supported while evaluating them.

• Service-scheme – This helps in associating actions based on trigger conditions which can be triggeredeither at call-setup time, Bearer-creation time, or flow-creation time.

• trigger-condition – For any trigger, the trigger-action application is based on conditions definedunder the trigger-condition.

• trigger-actions – Defines the actions to be taken on the classified flow. These actions can be trafficoptimization, throttle-suppress, and so on.


Cisco Ultra Traffic OptimizationConfiguring Threshold Value

Session Setup TriggerThe any-match = TRUE, a wildcard configuration, is the only supported condition for this trigger and sothis is applicable to all the flows of the subscriber.

Use the following configuration to setup a Session Trigger:


trigger-action trigger_action_name

traffic-optimizationexit

trigger-condition trigger_condition_name1

any-match = TRUEexit

service-scheme service_scheme_name

trigger sess-setuppriority priority_value trigger-condition trigger_condition_name1


exitsubs-class sub_class_name

apn = apn_name

exitsubscriber-base subscriber_base_name

priority priority_value subs-class sub_class_name bind service-schemeservice_scheme_name

end

Sample Configuration

Following is a sample configuration for Session Setup Trigger:service-scheme SS1

trigger sess-setuppriority 1 trigger-condition sess-setup trigger-action sess-setup

#exittrigger-condition sess-setupany-match = TRUE

#exittrigger-action sess-setuptraffic-optimization policy sess-setup

#exit

Bearer Creation TriggerThe trigger conditions related to QCI can be used for this trigger, and so this is applicable to all the flows ofspecific bearers.

The following is a sample configuration:






Cisco Ultra Traffic OptimizationSession Setup Trigger



qci = qci_value

exitservice-scheme service_scheme_name

trigger bearer-creationpriority priority_value trigger-condition trigger_condition_name2


exitexit

subs-class sub_class_name

apn = apn_name

exitsubscriber-base subscriber_base_name


end

Flow Creation TriggerThe trigger conditions related to rule-name and QCI can be used here, and so this is related to specific flow.

The following is a sample configuration:







qci = qci_value

exittrigger-condition trigger_condition_name3

rule-name = rule_name

exitservice-scheme service_scheme_name

trigger bearer-creationpriority priority_value trigger-condition trigger_condition_name3


exitexit

subs-class sub_class_name

apn = apn_nameexit

subscriber-base subscriber_base_name


end


Cisco Ultra Traffic OptimizationFlow Creation Trigger

Notes:

• trigger_condition_name3 can have only rules, only QCI, both rule and QCI, or either of rule and QCI.

The following table illustrates the different levels of Traffic Optimization and their corresponding SubscriberClass configuration and Triggers.

Subscriber Class configuration and TriggersTraffic Optimization Levels

subs-class sc1


Sessetup trigger condition is any-match = TRUE

Applicable to all the calls or flows

subs-class sc1

rulebase = prepaidexit


Applicable to all calls or flows of arulebase

subs-class sc1

apn = cisco.comexit


Applicable to all calls or flows of anAPN

trigger-condition TC1

qci = 1exit

Bearer creation trigger condition is TC1

Applicable to all flows of a Bearer

trigger-condition TC1

qci = 1rule-name = tcpmulti-line-or all-linesexit

Flow creation trigger condition is TC1

Applicable to a particular flow

In case of LTE to eHRPD handover, since QCI is not valid for eHRPD, it is recommended to configurerule-name as the trigger-condition under service-scheme.

Important

Generating TODRUse the following CLI commands under ACSConfigurationMode to enable Traffic Optimization Data Record(TODR) generation:


traffic-optimization-profile


Cisco Ultra Traffic OptimizationGenerating TODR

data-recordend

NOTES:

• If previously configured, use the no data-record command to disable generating TODR.

Configuring Rulebase to Allow UDP Traffic Optimization

From Release 21.8 onwards, it is recommended to enable TCP and UDP protocol for Traffic Optimizationby using the CLI commands mentioned in the Enabling TCP and UDP section of this chapter.

Important

Use the following configuration in ACSRulebase ConfigurationMode to turn ON/OFF the traffic optimizationfor UDP traffic.

Enabling/Disabling the Cisco Ultra Traffic Optimization solution is controlled by Service-scheme Framework.Important


rulebase rulebase_name

[ no ] traffic-optimization udpend

NOTES:

• udp: Specifies traffic optimization for UDP traffic.

• By default, UDP traffic optimization is disabled.

• If previously configured, use the no traffic-optimization udpCLI command to disable traffic optimizationfor UDP traffic.

Multi-Policy Support for Traffic OptimizationCisco Ultra Traffic Optimization engine supports Traffic Optimization for multiple policies and providesTraffic Optimization for a desired location. It supports a maximum of 32 policies that include two pre-configuredpolicies, by default. Operators can configure several parameters under each Traffic Optimization policy.

This feature includes the following functionalities:

• By default, Traffic Optimization is enabled for TCP and UDP data for a particular Subscriber, Bearer,or Flow that use the Service-Schema.

PORT 443 supports UDP or QUIC-based Traffic Optimization.Important


Cisco Ultra Traffic OptimizationConfiguring Rulebase to Allow UDP Traffic Optimization

• Selection of a policy depends on the priority configured. A trigger-condition is used to prioritize a trafficoptimization policy. The priority is configurable regardless of a specific location where the trafficoptimization policy is applied. Based on the configured priorities, a traffic optimization policy can beoverridden by another policy.

• A configuration to associate a traffic optimization policy with a Trigger Action, under the Service-Schema.

• A configuration to select a Traffic Optimization policy for a Location Trigger. Currently, only ECGIChange Detection is supported under the Local Policy Service Configuration mode.

Location Change Trigger is not supported with IPSG.Important

Policy ID for a flow is not recovered after a Session Recovery (SR) or Inter-Chassis Session Recovery (ICSR).Important

The Multi-Policy Support feature requires the same Cisco Ultra Traffic Optimization license key be installed.Contact your Cisco account representative for detailed information on specific licensing requirements.

Important

How Multi-Policy Support Works

Policy Selection

Cisco’s Ultra Traffic Optimization engine provides two default policies – Managed and Unmanaged. WhenUnmanaged policy is selected, traffic optimization is not performed.

WhenManaged policy is selected, traffic optimization is performed using default parameters.Managed policyis applied when a policy is not specified in a Trigger Action where traffic optimization is enabled withoutspecifying a policy.

WhenManaged policy is selected, traffic optimization is performed using default parameters.Managed policyis applied when a policy is not specified in a Trigger Action where traffic optimization is enabled withoutspecifying a policy.

• Session Setup Trigger – If a Trigger Action is applied only for a Session Setup in a Service-Schema,then the trigger action is only applied to new sessions only.

• Bearer Setup Trigger – If a trigger action is applied only for a Bearer Setup, changes in the trigger actionwill be applicable to newly created bearers and its flows.

• Flow Creation Trigger – Under a trigger condition corresponding to a flow create, conditions can beadded based on a rule-name, local-policy-rule or an IP protocol in addition to the trigger condition:any-match.

When traffic optimization on existing flows is disabled because of a trigger condition, then the trafficoptimization engine will apply the default Unmanaged policy on them.


Cisco Ultra Traffic OptimizationHow Multi-Policy Support Works

Deleting a Policy

Before deleting a Policy profile, all association to a traffic optimization policy should be removed.

For more information on deletion of a policy, refer to the Traffic Optimization Policy Configuration section.

Configuring Multi-Policy SupportThe following sections describes the required configurations to support the Multi-Policy Support.

Configuring a Traffic Optimization ProfileUse the following CLI commands to configure a Traffic Optimization Profile.

configurerequire active-chargingactive-charging service service_name

traffic-optimization-profile profile_name

data-record

[ no ] efd-flow-cleanup-interval cleanup_interval

[ no ] stats-interval stats_interval

[ no ] stats-options { flow-analyst [ flow-trace ] | flow-trace [flow-analyst ] }

end

NOTES:

• require active-charging: Enables the configuration requirement for an Active Charging service.

After you configure this command, you must save the configuration and thenreload the chassis for the command to take effect. For information on saving theconfiguration file and reloading the chassis, refer to the System AdministrationGuide for your deployment.

Important

• data-record: Enables the generation of traffic optimization data record.

• efd-flow-cleanup-interval: Configures the EFD flow cleanup interval. The interval value is an integerthat ranges 10–5000 milliseconds.

• stats-interval: Configures the flow statistics collection and reporting interval in seconds. The intervalvalue is an integer that ranges 1–60 seconds.

• stats-options: Configures options to collect the flow statistics. It only specifies whether the stream mustbe a Flow Trace or a Flow Analyst or both, to an external server.

From Release 21.6 onwards, the heavy-session command is deprecated.Note


Cisco Ultra Traffic OptimizationConfiguring Multi-Policy Support

Configuring a Traffic Optimization PolicyUse the following CLI commands to configure a Traffic Optimization Policy.


[ no ] traffic-optimization-policy policy_name

bandwidth-mgmt { backoff-profile [ managed | unmanaged ] [min-effective-rate effective_rate [ min-flow-control-rate flow_rate ] |min-flow-control-rate flow_rate [ min-effective-rate effective_rate ] ] |min-effective-rate effective_rate [ backoff-profile [ managed | unmanaged ][ min-flow-control-rate flow_rate ] | min-flow-control-rate control_rate [backoff-profile [ managed | unmanaged ] ] | min-flow-control-rate [ [backoff-profile [ managed | unmanaged ] [ min-effective-rate effective_rate

] | [ min-effective-rate effective_rate ] [ backoff-profile [ managed |unmanaged ] ] }

[ no ] bandwidth-mgmtcurbing-control { max-phases max_phase_value [ rate curbing_control_rate

[ threshold-rate threshold_rate [ time curbing_control_duration ] ] ] | ratecurbing_control_rate [ max-phases [ threshold-rate threshold_rate [ timecurbing_control_duration ] ] ] | threshold-rate [ max-phases max_phase_value [rate curbing_control_rate [ time curbing_control_duration ] ] ] | time [ max-phasesmax_phase_value [ rate curbing_control_rate [ threshold-rate threshold_rate] ] ]}

[ no ] curbing-controlheavy-session { standard-flow-timeout [ threshold threshold_value |

threshold threshold_value [ standard-flow-timeout timeout_value ] }[ no ] heavy-sessionlink-profile { initial-rate initial_seed_value [ max-rate

max_peak_rate_value [ peak-lock ] ] | max-rate [ initial-rate initial_seed_value

[ peak-lock ] ] | peak-lock [ initial-rate initial_seed_value [ max-ratemax_peak_rate_value ] ] }

[ no ] link-profilesession-params { tcp-ramp-up tcp_rampup_duration [ udp-ramp-up

udp_rampup_duration ] | udp-ramp-up udp_rampup_duration [ tcp-ramp-uptcp_rampup_duration ] }

[ no ] session-paramsend

NOTES:

• no: Overwrites the configured parameters with default values. The operator must remove all associatedpolicies in a policy profile before deleting a policy profile. Otherwise, the following error message isdisplayed:Failure: traffic-optimization policy in use, cannot be deleted.

• bandwidth-mgmt: Configures bandwidth management parameters.

• backoff-profile: Determines the overall aggressiveness of the back off rates.

• managed: Enables both traffic monitoring and traffic optimization.

• unmanaged: Only enables traffic monitoring.


Cisco Ultra Traffic OptimizationConfiguring a Traffic Optimization Policy

• min-effective-rate: Configures minimum effective shaping rate in Kbps. The shaping rate value is aninteger ranging 100–10000.

• min-flow-control-rate: Configures the minimum rate that is allowed in Kbps to control the flow ofheavy-session-flows during congestion. The control rate value is an integer ranging 100–10000.

• curbing-control: Configures curbing flow control related parameters.

• max-phases: Configures consecutive phases where the target shaping rate is below threshold-rate totrigger curbing flow control. The maximum phase value is an integer ranging 2–10.

• rate: Configures the curbing flow-control at a fixed rate in Kbps instead of a dynamic rate. The controlrate value is an integer ranging 0–10000. To disable the fixed flow control rate, set the flow control ratevalue to 0.

• threshold-rate: Configures the minimum target shaping rate in kbps to trigger curbing. The thresholdrate is an integer ranging 100–10000.

• time: Configures the duration of a flow control phase in milliseconds. The flow control duration valueis an integer ranging 0–600000. To disable flow control, set the flow control duration value to 0.

• heavy-session: Configures parameters for heavy-session detection.

• standard-flow-timeout: Configures the idle timeout in milliseconds, for expiration of standard flows.The timeout value is an integer ranging 100–3000.

• threshold: Configures heavy-session detection threshold in bytes. On reaching the threshold, the flowis monitored and potentially managed. The threshold value is an integer ranging 0–100000000.

• link-profile: Configures link profile parameters.

• initial-rate: Configures the initial seed value of the acquired peak rate in Kbps for a traffic session. Theinitial seed value is an integer ranging 100–30000.

• max-rate: Configures the maximum learned peak rate that is allowed in Kbps for a traffic session. Themax rate value is an integer ranging 100–30000.

• peak-lock: Confirms with the link peak rate available at the initial link peak rate setting.

• session-params: Configures session parameters.

• tcp-ramp-up: Configures the ramp-up-phase duration in milliseconds, for TCP traffic. The TCP ramp-upduration is an integer ranging 0–5000.

• udp-ramp-up: Configures the ramp-up-phase duration in milliseconds, for the UDP traffic. The UDPramp-up duration is an integer ranging 0–5000.

After you configure require active-charging command, you must save the configuration and then reload thechassis for the command to take effect. For information on saving the configuration file and reloading thechassis, refer to the System Administration Guide for your deployment.

Important

Traffic Optimization Policy - Default Values

Bandwidth-Mgmt:


Cisco Ultra Traffic OptimizationConfiguring a Traffic Optimization Policy

Backoff-Profile : ManagedMin-Effective-Rate : 600 (kbps)Min-Flow-Control-Rate : 250 (kbps)

Curbing-Control:

Time : 0 (ms)Rate : 600 (kbps)Max-Phases : 2Threshold-Rate : 600 (kbps)

Heavy-Session:

Threshold : 4000000 (bytes)Standard-Flow-Timeout : 500 (ms)

Link-Profile:

Initial-Rate : 7000 (kbps)Max-Rate : 10000 (kbps)Peak-Lock : Disabled

Session-Params:

Tcp-Ramp-Up : 5000 (ms)Udp-Ramp-Up : 0 (ms)

Associating a Trigger Action to a Traffic Optimization PolicyUse the following CLI commands to associate a Trigger Action to a Traffic Optimization Policy.



traffic-optimization policy policy_name

[ no ] traffic-optimizationend

NOTES:

• traffic-optimization policy: Configures a traffic optimization policy.

• no: Removes the configured traffic optimization policy.

Enabling TCP and UDPUse the following CLI commands to enable TCP and UDP protocol for Traffic Optimization:


trigger-condition trigger_condition_name

[ no ] ip protocol = [ tcp | udp ]end

NOTES:

• no: Deletes the Active Charging Service related configuration.


Cisco Ultra Traffic OptimizationAssociating a Trigger Action to a Traffic Optimization Policy

• ip: Establishes an IP configuration.

• protocol: Indicates the protocol being transported by the IP packet.

• tcp: Indicates the TCP protocol to be transported by the IP packet.

• udp: Indicates the UDP protocol to be transported by the IP packet.

After you configure this command, you must save the configuration and then reload the chassis for thecommand to take effect. For information on saving the configuration file and reloading the chassis, refer tothe System Administration Guide for your deployment.

Important

Service-Scheme Configuration for Multi-Policy SupportThe service-schema framework enables traffic optimization at APN, rule base, QCI, and Rule level. With theMulti-Policy Support feature, traffic optimization in a service-scheme framework allows the operator toconfigure multiple policies and to configure traffic optimization based on a desirable location.

The service-scheme framework helps in associating actions based on trigger conditions, which can be triggeredeither at call-setup time, Bearer-creation time, or flow-creation time.

Monitoring and TroubleshootingThis section provides information regarding commands available to monitor and troubleshoot the Cisco UltraTraffic Optimization solution on the P-GW.

Cisco Ultra Traffic Optimization Show Commands and/or OutputsThis section provides information about show commands and the fields that are introduced in support of CiscoUltra Traffic Optimization solution.

show active-charging rulebase name <rulebase_name>The output of this show command has been enhanced to display if the UDP traffic optimization is Enabledor Disabled. Following are the fields that has been introduced:

• Traffic Optimization:

• UDP: Enabled/Disabled

show active-charging traffic-optimization countersThe show active-charging traffic-optimization counters sessmgr { all | instance number } CLI commandis introduced where:

• counters – Displays aggregate flow counters/statistics from Cisco Ultra Traffic Optimization engine.


Cisco Ultra Traffic OptimizationService-Scheme Configuration for Multi-Policy Support

This CLI command is license dependent and visible only if the license is loaded.Important

Following are the new field/counters:

• Traffic Optimization Flows:

• Active Normal Flow Count:

• Active Large Flow Count:

• Active Managed Large Flow Count:

• Active Unmanaged Large Flow Count:

• Total Normal Flow Count:

• Total Large Flow Count:

• Total Managed Large Flow Count:

• Total Unmanaged Large Flow Count:

• Total IO Bytes:

• Total Large Flow Bytes:

• Total Recovered Capacity Bytes:

• Total Recovered Capacity ms:

On executing the above command, the following new fields are displayed for theMulti-Policy Support feature:

This CLI command is license dependent and visible only if the license is loaded.Important

• TCP Traffic Optimization Flows:









• Total IO Bytes:



Cisco Ultra Traffic Optimizationshow active-charging traffic-optimization counters



• UDP Traffic Optimization Flows:









• Total IO Bytes:




show active-charging traffic-optimization infoThis show command has been introduced in Exec Mode, where:

• traffic-optimization – Displays all traffic optimization options.

• info – Displays Cisco Ultra Traffic Optimization engine information.

The output of this CLI command displays the version, mode, and configuration values.

Following are the new fields/counters:

• Version:

• Mode:

• Configuration:

• Data Records (TODR)

• Statistics Options

• EFD Flow Cleanup Interval

• Statistics Interval


Cisco Ultra Traffic Optimizationshow active-charging traffic-optimization info

show active-charging traffic-optimization policyOn executing the above command, the following new fields are displayed for theMulti-Policy Support feature:

• Policy Name

• Policy-Id

• Bandwidth-Mgmt

• Backoff-Profile

• Min-Effective-Rate

• Min-Flow-Control-Rate

• Curbing-Control

• Time

• Rate

• Max-phases

• Threshold-Rate

• Heavy-Session

• Threshold

• Standard-Flow-Timeout

• Link-Profile

• Initial-Rate

• Max-Rate

• Peak-Lock

• Session-Params

• Tcp-Ramp-Up

• Udp-Ramp-Up


Cisco Ultra Traffic Optimizationshow active-charging traffic-optimization policy

C H A P T E R 13CLI Support for P-GW to include AVPs in CCR-UMessages

• Feature Summary and Revision History, on page 107• Feature Changes, on page 108• Command Changes, on page 108• Performance Indicator Changes, on page 109


P-GWApplicable Product(s) or Functional Area

ASR 5500Applicable Platform(s)






Revision History

Revision history details are not provided for features introduced before releases 21.2 and N5.5.Important


21.11.3This Behavior Change was introduced in 21.4.14. With this release, CLI supportfor P-GW to include AVPs in CCR-U messages is also applicable to 21.11.3



21.8.10This Behavior Change was introduced in 21.4.14. With this release, CLI supportfor P-GW to include AVPs in CCR-U messages is also applicable to 21.8.10

21.4 .14For Wi-Fi calls, when P-GW receives the AVPs - UDP-SOURCE-PORT andUE-Local-IP-Address, in the CB Rsp or UB Rsp or DB Rsp message, it sendsthese AVPs in the CCR-U messages towards the PCRF even if there are nochanges in the AVP values.

Pre 21.2First introduced.

Feature ChangesFor Wi-Fi calls, when P-GW receives the AVPs - UDP-SOURCE-PORT and UE-Local-IP-Address, in theCB Rsp or UB Rsp or DB Rsp message, it sends these AVPs in the CCR-U messages towards the PCRF evenif there are no changes in the AVP values.

To support the above functionality, a new keyword - ue-ip-udp-port, is added to the diameterencode-supported-features command in the Policy Control Configuration Mode. By default, this keywordis disabled.

Previous Behavior: For Wi-Fi calls, if P-GW receives the AVPs - UDP-SOURCE-PORT and/orUE-Local-IP-Address in the CB Rsp, UB Rsp or DB Rsp, it checks for a change in the AVP values with thevalue received earlier. If there are no changes in the AVP values, then the P-GW does not send these AVPsin the CCR-U message towards PCRF. Otherwise, the P-GW only sends the UE-Local-IP-Address IE in theCCR-U message towards PCRF.

New Behavior: For Wi-Fi calls, when the CLI is configured with the keyword ue-ip-udp-port enabled, theP-GW sends the AVPs - UDP-SOURCE-PORT and UE-Local-IP-Address in the CCR-U message towardsPCRF.

If P-GW does not receive the above mentioned AVPs in the CB Rsp, UB Rsp or DB Rsp message, it does notsend the AVPs in the CCR-U message towards PCRF.

Note

Command Changes

diameter encode-supported-featuresIn the Policy Control Configuration mode, the diameter encode-supported-features command’snetloc-untrusted-wlan is supported with the ue-ip-udp-port keyword which facilitates the P-GW to includethe UDP-SOURCE-PORT and UE-Local-IP-Address AVPs in the CCR-U message sent towards PCRF.

To enable this functionality, use the following configuration:



CLI Support for P-GW to include AVPs in CCR-U MessagesFeature Changes

ims-auth-service service_name

policy-controldiameter encode-supported-features netloc-untrusted-wlan

ue-ip-udp-portno diameter encode-supported-featuresend

NOTES:

• The ue-ip-udp-port keyword is displayed only if netloc-untrusted-wlan is configured.

• ue-ip-udp-port: Sends the UDP-SOURCE-PORT and UE-Local-IP-Address AVPs in CCR-Umessagesfor Wi-Fi calls even though the AVP values remain unchanged.

• no: Disables this functionality at an IMS-Auth service level.

Performance Indicator Changes

show ims-authorization service all verboseThe output of this command includes the following fields in support of this functionality:

• Supported Features

• netloc-untrusted-wlan ue-ip-udp-port


CLI Support for P-GW to include AVPs in CCR-U MessagesPerformance Indicator Changes


CLI Support for P-GW to include AVPs in CCR-U Messagesshow ims-authorization service all verbose

C H A P T E R 14Configuration Support for Heartbeat Value

• Feature Summary and Revision History, on page 111• Feature Changes, on page 112• Command Changes, on page 112• Monitoring and Troubleshooting, on page 113




• VPC - DI



Related Documentation • ASR 5500 System Administration Guide




Revision History


21.8In this release, the default heartbeat value betweenthe management and data processing card can bemodified to prevent the management card fromincorrectly detecting and reporting the packetprocessing card as failed.




Feature ChangesIn certain deployment scenarios, the management card reports the packet processing card as failed when it isunable to detect a heartbeat for about two seconds. This assumed failure is observed when the hearbeat isdelayed or lost due to congestion in the internal DI network.

This release addresses this issue.

Previous Behavior: The management card reports the packet processing card as failed due to its inability todetect the heartbeat within the default value of two seconds, thereby causing an unplanned switchover.

New Behavior: To prevent the management card from incorrectly detecting and reporting the packet processingcard as failed, the default heartbeat value between the management and data processing card can now bemodified.

Customer Impact: Prevents the management card from wrongful reporting of the data processing card andunplanned switchover.

Command Changes

high-availability fault-detectionThe above CLI command is enhanced to include the card hb-loss value keyword, which is used to configurethe heartbeat value between the management and packet processing cards. This command is configured inthe Global Configuration Mode.

configure[default] high-availability fault-detection card hb-loss value

end

NOTES:

• default: Restores the heartbeat value to the default value of 2 heartbeats.

• card: Specifies the packet processing card.

• hb-loss value: Configures the heartbeat loss value. The default value is 2 heartbeats.

• The heartbeat value between a management to management card is set to the default value of 2 heartbeats.

• This command modifies the heartbeat value only between the management and packet processing cards.

• By default, this CLI is disabled.


Configuration Support for Heartbeat ValueFeature Changes

Monitoring and TroubleshootingThis section provides information regarding show commands and/or their outputs in support of this feature.

show heartbeat statistics hb-loss allThis show command now includes the value for the following new fields for the all packet processing cards.

• Max Bounces

• Total HB Miss

• Total HB Card Failure

• Card/Cpu

• Total

• Age/Intf/Seqno/TimeStamp

• AFD(oldest first)

show heartbeat statistics hb-loss card <card-number>This show command now includes the value for the following new fields for the specified packet processingcard.

• Max Bounces

• Total HB Miss

• Total HB Card Failure

• Card/Cpu

• Total

• Age/Intf/Seqno/TimeStamp

• AFD(oldest first)


Configuration Support for Heartbeat ValueMonitoring and Troubleshooting


Configuration Support for Heartbeat Valueshow heartbeat statistics hb-loss card <card-number>

C H A P T E R 15Dedicated Core Networks on MME

This chapter describes the Dedicated Core Networks feature in the following sections:

• Feature Summary and Revision History, on page 115• Feature Description, on page 116• How It Works, on page 119• Configuring DECOR on MME, on page 127• Monitoring and Troubleshooting, on page 132


MMEApplicable Product(s) or FunctionalArea

• ASR 5500

• VPC-DI

• VPC-SI


Enabled - Configuration RequiredFeature Default







Revision History


21.8In release 21.8, the DECOR feature is enhanced to support:

• Association of DCNs to a specific RAT Type under call-control-profile

• Association of multiple DCN profiles (to designate dedicated or default corenetwork) under call-control-profile

• DNS selection of S-GW / P-GW / MME / S4-SGSN/ MMEGI lookup forspecified UE Usage Type or DCN-ID

• DIAMETER_AUTHENTICATION_DATA_UNAVAILABLE result code forthe S6a (HSS) interface

• When UE moves from a service area where DCN is not used to another areawhere DCN is supported, thenMME does not receive the UE-Usage-Type frompeer. In this case, MME will do an explicit AIR towards HSS for UE-Usagelookup.

21.7The enhancements to the DECOR feature in release 21.6 are fully qualified.

21.6The enhancements to the DECOR feature in release 21.6 are not fully qualified andare available only for testing purposes.

In release 21.6, the DECOR feature is enhanced to support:

• DNS based MMEGI selection

• DCN-ID IE in Attach/TAU Accept and GUTI Reallocation Command messagetowards UE

• DCN-ID IE in INITIAL UE MESSAGE from eNodeB

• HSS initiated DCN reselection

• MME initiated DCN reselection

• Network sharing with same MMEGI for different PLMNs

• Network sharing with different MMEGIs for different PLMNs

• Served DCNs Items IE in S1 Setup Response and MME Configuration Updatemessages towards eNodeBs


Feature DescriptionThe Dedicated Core (DECOR) Networks feature allows an operator to deploy one or more dedicated corenetwork within a PLMN, with each core network dedicated for a specific type of subscriber. The specificdedicated core network that serves a UE is selected based on subscription information and operator


Dedicated Core Networks on MMEFeature Description

configuration, without requiring the UEs to be modified. This feature aims to route and maintain UEs in theirrespective DCNs.

The DECOR feature can either provide specific characteristics and functions to the UE or subscriber, or isolatethem to a UE or subscriber. For example, Machine-to-Machine (M2M) subscribers, subscribers belonging toa specific enterprise or separate administrative domain, and so on.

OverviewDedicated Core Networks (DCN) enable operators to deploymultiple core networks consisting of one or moreMME/SGSN and optionally one or more S-GW/P-GW/PCRF.

If a network deploys a DCN selection based on both LAPI indication and subscription information(MME/SGSN), then DCN selection based on the subscription information provided byMME/SGSN overridesthe selection based on the Low Access Priority Indication (LAPI) by RAN.

A new optional subscription information parameter,UE Usage Type, stored in the HSS, is used by the servingnetwork to select the DCNs that must serve the UE. The operator can configure DCNs and its serving UEUsage Type as required. Multiple UE Usage Types can be served by the same DCN. The HSS provides theUEUsage Type value in the subscription information of the UE to theMME/SGSN/MSC. The serving networkchooses the DCN based on the operator configured (UEUsage Type to DCN)mapping, other locally configuredoperator's policies, and the UE related context information available at the serving network.

One UE subscription can be associated only with a single UE Usage Type, which describes its characteristicsand functions.

Note

External InterfacesThe following components are enhanced to support the DECOR feature on the MME:

DNS

S-GW or P-GW Selection

MME performs S-GW or P-GW selection from DCNs serving UE Usage Type or DCN-ID, based on theconfiguration in the decor profile.

The existing service parameters of the SNAPTR records are enhanced by appending the character string"+ue-<ue usage type>" or "+ue-<dcn-id>” to the "app-protocol" name identifying the UE usage type(s) orDCN-ID for which the record applies.

For example: S-GW service parameter — x-3gpp-sgw:x-s11+ue-1.10.20 will represent the S-GW which ispart of a DCN serving UE usage types or DCN-ID 1, 10, and 20.

For example: P-GW service parameter— x-3gpp-pgw:x-s5-gtp+ue-1.10.20:x-s8-gtp+ue-1.10.20will representthe P-GW which is part of a DCN serving UE usage types or DCN-ID 1, 10, and 20.

MMEGI Retrieval

MMEuses local configuration forMMEGI corresponding to theUEUsage Type andDNSSNAPTRprocedures.


Dedicated Core Networks on MMEOverview

The configuration options for static (local) or DNS or both are provided under decor-profile. If both optionsare enabled, then DNS is given preference. When DNS lookup fails, static (local) value is used as fallback.

To retrieve the MMEGI identifying the DCN serving a particular UE usage type, the SNAPTR procedureuses the Application-Unique String set to the TAI FQDN. The existing service parameters are enhanced byappending the character string "+ue-<ue usage type>" or "+ue-<dcn-id>” to the "app-protocol" name identifyingthe UE usage type for which the discovery and selection procedures are performed.

For example:MMEwill discover theMMEGI for a particular UE usage type or DCN-ID by using the "ServiceParameters" of "x-3gpp-mme:x-s10+ue-<ue usage type>" or "x-3gpp-mme:x-s10+ue-<dcn-id>". The serviceparameters are enhanced to identify the UE usage type(s) for which the record applies. The MMEGI will beprovisioned in the host name of the records and MMEGI will be retrieved from the host name.

MME or S4-SGSN Selection

To perform MME/S4-SGSN selection from the same DCN during handovers, the existing service parametersare enhanced by appending the character string "+ue-<ue usage type>" or "+ue-<dcn-id>" to the "app-protocol"name identifying the UE usage type.

If the MME fails to find a candidate list for the specific UE Usage Type, it falls back to the legacy DNSselection procedure.

For example:

For an MME to find a candidate set of target MMEs — "x-3gpp-mme:x-s10+ue-<ue usage type>" or"x-3gpp-mme:x-s10+ue-<dcn-id>"

For an MME to find a candidate set of target SGSNs — "x-3gpp-sgsn:x-s3+ue-<ue usage type>" or"x-3gpp-sgsn:x-s3+ue-<dcn-id>"

I-RAT handovers between MME and Gn-SGSN is not supported in this release.Note

S6a (HSS) InterfaceTo request the UE Usage Type from HSS, MME sets the "Send UE Usage Type" flag in the AIR-Flags AVP,in the AIR command.

The AIR-Flag is set only if the decor s6a ue-usage-type CLI command is enabled under MME-service orCall-Control-Profile.

HSS may include the UE-Usage-Type AVP in the AIA response command in the case ofDIAMETER_SUCCESS or DIAMETER_AUTHENTICATION_DATA_UNAVAILABLE result code.MMEwill store the UE Usage Type in the UE context for both the result codes.

GTPv2 (MME or S4-SGSN)MME supports the UE Usage Type IE in Identification Response, Forward Relocation Request, and ContextResponseMessages. If the subscribed UEUsage Type is available, it will be set to the available value, otherwisethe MME encodes the length field of this IE with 0.

Similarly, MME will parse and store the UE Usage Type value when received from the peer node.


Dedicated Core Networks on MMES6a (HSS) Interface

How It WorksMME obtains the UE Usage type and determines the MMEGI that serves the corresponding DCN.

The MME then compares this MMEGI with its own MMEGI to perform a reroute or process further. In caseof reroute, the request message is redirected to the appropriate MME. Refer to the ATTACH/TAU Procedure,on page 121 call flow for more information.

The following deployment scenarios are supported when DECOR is enabled on the MME:

• MME can be deployed where the initial request is sent by RAN (eNodeB) when sufficient informationis not available to select a specific DCN.

• MME can be deployed as a part of DCN to serve one or more UE Usage Types.

• MME can be deployed as part of a Common Core Network (CCN) or Default Core Network, to serveUE Usage Types for which specific DCN is not available.

AnMME can service initial RAN requests and also be a part of a DCN or a CCN. However, a particular MMEservice can only belong to one DCN or CCN within a PLMN domain.

Note

The Dedicated Core Network implements the following functionalities on the MME:

• NAS Message Redirection

• ATTACH and TAU and Handover Procedures

• UE Usage Type support on S6a and GTPv2 interfaces

• S-GW/P-GW DNS selection procedures with UE Usage Type or DCN-ID

• MME/S4-SGSN selection procedures with UE Usage Type or DCN-ID during handovers

• Roaming

• Network Sharing

• DNS based MMEGI selection with UE-Usage-Type or DCN-ID

• DCN ID Support

• HSS/MME initiated DCN reselection

• When UE moves from a service area where DCN is not used to another area where DCN is supported,then MME does not receive the UE-Usage-Type from peer. In this case, MME will do an explicit AIRtowards HSS for UE-Usage lookup.

FlowsThis section describes the call flows related to the DECOR feature.

• UE Assisted Dedicated Core Network Selection, on page 120

• NAS Message Redirection Procedure, on page 120


Dedicated Core Networks on MMEHow It Works

• ATTACH/TAU Procedure, on page 121

• HSS Initiated Dedicated Core Network Reselection, on page 124

UE Assisted Dedicated Core Network SelectionThe UE assisted Dedicated Core Network Selection feature selects the correct DCN by reducing the need forDECOR reroute by using DCN-ID sent from the UE and DCN-ID used by RAN.

1. The DCN-ID will be assigned to the UE by the serving PLMN and is stored in the UE per PLMN-ID.Both standardized and operator specific values for DCN-ID are acceptable. The UE will use the PLMNspecific DCN-ID whenever it is stored for the target PLMN.

2. The HPLMN may provision the UE with a single default standardized DCN-ID that will be used by theUE only if the UE has no PLMN specific DCN-ID of the target PLMN. When a UE configuration ischanged with a new default standardized DCN-ID, the UEwill delete all stored PLMN specific DCN-IDs.

3. The UE provides the DCN-ID to RAN at registration to a new location in the network, that is, in Attach,TAU, and RAU procedures.

4. RAN selects the serving node MME based on the DCN-ID provided by UE and configuration in RAN.For E-UTRAN, the eNodeB is conveyed with DCNs supported by the MME during setup of the S1connection in S1 Setup Response.

NAS Message Redirection ProcedureReroute NAS message is used to reroute a UE from one CN node to another CN node during Attach, TAU,or RAU procedure. This is also used by theMME/SGSN or HSS initiated Dedicated Core Network Reselectionprocedure.

When the first MME determines the UE Usage Type, it fetches the DCN configuration serving the UE andthe correspondingMMEGI (from configuration or DNS). If theMME’sMMEGI is not the same as theMMEGIof the DCN, MME moves the UE to another MME using the NAS messaging redirection procedure.

The following call flow illustrates the NAS Message Redirection procedure:


Dedicated Core Networks on MMEUE Assisted Dedicated Core Network Selection

Figure 6: NAS Message Redirection Procedure

DescriptionStep

The first new MME sends a Reroute NASMessage Request to eNodeB includingUE Usage Type and MMEGI among other parameters.

1

RAN selects a new MME based on MMEGI. If no valid MME can be obtainedfromMMEGI, it selects MME from the CCN or forwards to the same first MME.

2

The second newMME determines from the MMEGI field if the incoming requestis a re-routed NAS request or not. Now, if the received MMEGI belongs to thesecond MME, the call is serviced, else the call is rejected. No further rerouting isperformed.

If the UE Usage Type is received by the second MME, it is used for S-GW/P-GWselection.

3

ATTACH/TAU ProcedureThe following figure illustrates a detailed flow of the ATTACH or TAU procedure.


Dedicated Core Networks on MMEATTACH/TAU Procedure

Figure 7: ATTACH and TAU Procedure

DescriptionStep

In the RRC Connection Complete message transferring the NAS Request message,the UE provides the DCN-ID, if available. If the UE has a PLMN specific DCN-ID.the UE provides this value and if no PLMN specific DCN-ID exists, then thepre-provisioned default standardized DCN-ID will be provided, if pre-provisionedin the UE.

The RAN node selects a DCN and a serving MME/SGSN within the network ofthe selected core network operator based on the DCN-ID and configuration in theRAN node. The NAS Request message is sent to the selected node. The DCN-IDis provided by the RAN to theMME/SGSN together with the NASRequest message.

1



DescriptionStep

The first new MME does not receive the MMEGI from eNodeB. The MMEdetermines the UE Usage Type as follows:

1. It may receive the UE Usage Type from the peer MME/S4-SGSN.

2. It may determine from the locally available UE context information.

3. It sends an AIR message to the HSS requesting the UE Usage Type by addingthe parameter "Send UE Usage Type" flag in the message. If authenticationvectors are available in the database or received from peer, MME will not sendthe Immediate-Response-Preferred flag in the AIR message.

4. It may determine from the local configuration.

2

When UE Usage Type is available, and if the MME has to send an AIR messageto the HSS to fetch authentication vectors, then the “Send UE Usage Type” flag isnot set in the AIR message.

3

The first new MME determines to handle the UE:

1. When there is a configured DCN and the first newMMEbelongs to theMMEGIserving the DCN.

2. It will continue with the call flow.

3. The MME/SGSN sends the DCN-ID, if available, for the new DCN to the UEin the NAS Accept message. The UE updates its stored DCN-ID parameter forthe serving PLMN if DCN-ID for serving PLMN is changed.

4

The first new MME determines to reject the UE:

1. When UE Usage Type is available but without a matching DCN.

2. The NAS message is rejected with parameters (for example: T3346 backofftimer) such that the UE does not immediately re-initiate the NAS procedure.

5

The first new MME determines to reroute the UE:

1. When there is a configured DCN and the first new MME does not belong tothe MMEGI.

2. The first new MME sends a Context Acknowledge message with cause codeindicating that the procedure is not successful. The old MME/SGSN willcontinue as if Context Request was never received.

3. The first new MME performs the NAS redirection procedure and the requestmay be routed by RAN to a second new MME.

6

The second newMME determines to handle the UE or reject it; the MME does notperform another re-route. The process of handling the UE or rejecting the UE issimilar to the procedure used in the case of the first new MME.

The second new MME does not fetch the UE Usage Type from HSS. It is receivedeither from the RAN node or the old MME.

7



HSS Initiated Dedicated Core Network ReselectionThis procedure is used by the HSS to update (add, modify, or delete) the UEUsage Type subscription parameterin the serving node. This procedure may result in change of serving node of the UE.

The following call flow illustrates the HSS Initiated DCN Reselection procedure.

Figure 8: HSS Initiated Dedicated Core Network Reselection Procedure

DescriptionStep

The HSS sends an Insert Subscriber Data Request (IMSI, Subscription Data)message to the MME. The Subscription Data includes the UE Usage Typeinformation.

1

The MME updates the stored Subscription Data and acknowledges the InsertSubscriber Data Request message by returning an Insert Subscriber Data Answer(IMSI) message to the HSS. The procedure ends if the MME/SGSN continues toserve the UE.

2


Dedicated Core Networks on MMEHSS Initiated Dedicated Core Network Reselection

DescriptionStep

As per this callflow, one of the following steps occur:

• Steps 3 through 6 occur in case the UE is already in connected mode or UE enters connected mode byinitiating data transfer.

• Step 7 occurs in case the UE is in idle mode and performs a TAU/RAU procedure.

Paging is not supported in this release. If the UE is in idle mode, MMEwaits until the UE becomesactive.

Important

The UE initiates NAS connection establishment either by uplink data or by sendinga TAU/RAU Request.

3

TheMME triggers the GUTI re-allocation procedure and includes a non-broadcastTAI.

4

The MME releases RAN resources and UE is moved to idle mode.5

The non-broadcast TAI triggers the UE to immediately start the TAU procedure.The MME receives the TAU Request message.

6

The UE performs a TAU request. The MME receives the TAU Request message7

The MME triggers the NAS Message redirection procedure to redirect the UE if:

• the UE Usage Type for the UE has been added or modified and if it is notserved by the MME

• the UE Usage Type has been withdrawn from the HSS subscription data andsubscriptions without UE Usage Type are not served by the MME

HSS Initiated UE Usage Type withdrawal is not supported. Theaddition or change in usage type is supported.

Note

8

Impact to Handover ProceduresThis section describes the impact during handover procedures:

• In a forward relocation request, the source MME includes the UE-Usage-Type, if available.

• If an S-GW needs to be relocated, MME applies the UE-Usage-Type or DCN-ID based DNS selection,that is similar to the Attach/TAU procedure.

• MME or S4-SGSN selection during handover considers UE-Usage-Type or DCN-ID.

• The following two scenarios apply to DCNs deployed partially or heterogeneously:

• Handover from service area where DCN is not used to an area where DCN is supported. In thiscase, MME does not receive the UE-Usage-Type from peer andMME does an Explicit AIR towardsHSS for UE-Usage lookup.

• The target MME or SGSN obtains the UE-Usage-Type information from the HSS during thesubsequent TAU or RAU procedure.


Dedicated Core Networks on MMEImpact to Handover Procedures

• If the target MME/SGSN determines that the S-GW does not support the UE-Usage-Type, thetargetMME/SGSNmust trigger the S-GW relocation as part of the handover procedure. S-GWrelocation is not supported in this release.

• If the target MME/SGSN does not serve the UE-Usage-Type, the handover procedure mustcomplete successfully and the target MME initiates the GUTI re-allocation procedure withnon-broadcast TAI to change the serving DCN of the UE.

RoamingMME in the visited PLMN provides an operator policy that allows to serve a UE whose home PLMN doesnot support DCNs. MME also provides operator policies that support the UE Usage Type parameter receivedfrom the HPLMN HSS.

Network SharingMME supports DCN selection based on the selected PLMN information received from the UE.

LimitationsThe DECOR feature has the following limitations:

• Only one MMEGI can be configured per DCN.

• DCN deployments as part of a PLMN is not supported. The ability to configure DCN for a set of TAI/TACis not supported.

• HSS Initiated UE usage type withdrawal is not supported. Only change in UE usage type is supported.

• DCNs can be deployed partially or heterogeneously.

• The target MME or SGSN obtains the UE Usage Type information from the HSS during thesubsequent TAU or RAU procedure. If the target MME/SGSN determines that the S-GW does notsupport the UE Usage Type, the target MME/SGSN must trigger the S-GW relocation as part ofthe handover procedures.

In this release, S-GW relocation is not supported.

Standards ComplianceThe DECOR feature complies with the following standards:


• 3GPP 29.272 Release 14.6.0 - Digital cellular telecommunications system (Phase 2+) (GSM); UniversalMobile Telecommunications System (UMTS); LTE; Diameter applications; 3GPP specific codes andidentifiers


Dedicated Core Networks on MMERoaming

• 3GPP 29.274 Release 14.5.0 - Universal Mobile Telecommunications System (UMTS); LTE; 3GPPEvolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol forControl plane (GTPv2-C); Stage 3

• 3GPP 29.303 Release 14.3.0 - Universal Mobile Telecommunications System (UMTS); LTE; DomainName System Procedures; Stage 3

Configuring DECOR on MMEThis section describes the CLI commands to configure the DECOR feature.

This feature supports the following configurations:

• DCN profile with

• UE-Usage-Type

• Static MMEGI

• DNS lookup for MMEGI

• PLMN

• DCN-ID

• Relative Capacity for the served DCN

• DNS Service parameters using UE Usage Type or DCN-ID for S-GW / P-GW / MME / S4-SGSNselection / MMEGI lookup using DNS

• Associate DCNs to a specific RAT Type under MME service

• Associate multiple DCN profiles (to designate dedicated or default core network) under MME service

• Associate DCNs to a specific RAT Type under Call-Control-Profile

• Associate multiple DCN profiles (to designate dedicated or default core network) underCall-Control-Profile

• Non-broadcast TAI

• Request UE-Usage-Type from HSS on S6a interface

• UE-Usage-Type per IMSI/IMEI range

Configuring DECOR ProfileUse the following configuration to create and configure a DECOR profile by specifying the MMEGI hostingthe DCN and the associated UE usage type using that DCN.

configure[ no ] decor-profile profile_name [ -noconfirm ]

dcn-id dcn_id

dns service-param ue-usage-type[ no ] mmegi { mmegi_value | dns }


Dedicated Core Networks on MMEConfiguring DECOR on MME

plmn-id mcc mcc_id mnc mnc_id

served-dcn [ relative-capacity capacity ][ no ] ue-usage-types num_ue_usage_types

no { dcn-id | dns service-param | plmn-id | served-dcn }end

NOTES:

• decor-profile profile_name: Configures the DECOR feature as deployed by operator. A DECOR profilewithout any UE Usage Types configuration is treated as a Common Core Network. profile_name mustbe an alphanumeric string of 1 through 63 characters.

Entering the decor-profile profile_name command results in the following prompt and changes to theDecor Profile Configuration mode:[context_name]host_name(config-decor-profile-<profile_name>)#

• dns service-param ue-usage-type: Configures the service parameter to select peer nodes using UEUsage Type or DCN-ID for S-GW / P-GW / MME / S4-SGSN / MMEGI lookup using DNS.

• service-param: Configures the service parameter types used for DNS peer lookup.

• ue-usage-type: Configures the UE Usage type that will be used for DNS service parameter.

• For UE Usage Type based DECOR configuration:

• If only UE-USAGE-TYPE is configured, DNS lookup uses UE-USAGE-TYPE.

• If only DCN-ID is configured, DNS lookup uses DCN-ID without dns service-paramue-usage-type CLI command or UE-USAGE-TYPE with dns service-param ue-usage-typeCLI (default profile).

• If both UE-USAGE-TYPE and DCN-ID are configured, DCN-ID is used without dnsservice-param ue-usage-type CLI command or UE-USAGE-TYPE with dns service-paramue-usage-type CLI command.

• If both UE-USAGE-TYPE and DCN-ID are not configured, DNS lookup usesUE-USAGE-TYPE (default profile).

• dcn-id dcn_id: Configures the DCN identifier for the specified DECOR profile. dcn_idmust be an integerfrom 0 to 65535.

• mmegi { mmegi_value | dns }: Identifies the MME Group Identifier (MMEGI) of the configured DCN.mmegi_value must be an integer from 32768 to 65535.

dns: Enables DNS for MMEGI retrieval using UE Usage Type.

The mmegi dns command will work only when the dns peer-mme command is enabled underMME-service.

• plmn-id mcc mcc_id mnc mnc_id: Configures the PLMN identifier for the specified DECOR profile.This supports network sharing with different MMEGIs for different PLMNs.

mcc mcc_id: Configures the mobile country code (MCC) for the specified DECOR profile.mcc_id mustbe a 3-digit number between 000 to 999.

mnc mnc_id: Configures the mobile network code (MNC) for the specified DECOR profile. mnc_idmust be a 2- or 3-digit number between 00 to 999.


Dedicated Core Networks on MMEConfiguring DECOR Profile

• served-dcn [ relative-capacity capacity ]: Configures the MME that is serving the DCN and its relativecapacity. These values are sent by MME to eNodeB during S1 Setup Response to indicate DCN-IDsserved by the MME and their relative capacity.

relative-capacity capacity: Set the relative capacity of this DCN. capacity must be an integer from 0 to255. The default relative-capacity is 255.

• ue-usage-types num_ue_usage_types: Specifies the number of UE Usage Types in the dedicated corenetwork. num_ue_usage_types is an integer from 0 to 255.

A maximum number of 20 UE Usage Types are supported per DCN.

• no: Removes the specified DECOR parameters from the Global Configuration.

• MME will send the "MME CONFIGURATION UPDATE" message to all connected eNodeBs when anew DECOR profile is created with served-dcn relative-capacity and dcn-id CLI commands.

• MMEwill send the "MMECONFIGURATIONUPDATE"message to all connected eNodeBs wheneverthere is a change in served-dcn relative-capacity or dcn-id CLI commands in a DECOR profile.

Associating a DECOR Profile under MME ServiceUse the following configuration to associate a DECOR profile with an MME service.



[ no ] associate decor-profile profile_name access-type { all | eutran| nb-iot }

end

NOTES:

• associate: Associates a DECOR profile with an MME service.

• decor-profile profile_name: Specifies the DECOR profile that is associated with the MME Service.

• access-type: Configures the type of network access — E-UTRAN, NB-IoT, or both.

• all : Specifies to allow all access types.

• eutran: Specifies the access type as E-UTRAN.

• nb-iot: Specifies the access-type as NB-IoT.

• no: Removes the specified DECOR profile from the configuration.

• A maximum number of 16 DECOR profiles can be associated to an MME service.

Associating a DECOR Profile under Call Control ProfileUse the following configuration to associate a DECOR profile under call control profile.


[ remove ] associate decor-profile profile_name [ access-type { all |


Dedicated Core Networks on MMEAssociating a DECOR Profile under MME Service

eutran | nb-iot } ]end

NOTES:

• associate: Associates a DECOR profile under call control profile.

• decor-profile profile_name: Specifies the DECOR profile that is associated with the call control profile.profile_name must be an alphanumeric string of 1 through 63 characters.

• access-type: Configures the type of network access for the DECOR profile — E-UTRAN, NB-IoT, orboth.

• all : Specifies allows all access types.

• eutran: Specifies the access type as E-UTRAN.

• nb-iot: Specifies the access-type as NB-IoT.

• remove: Removes the specified DECOR profile from the configuration.

• A maximum number of 16 DECOR profile associations can be configured for the call control profile.

Configuring UE Usage Type over S6a Interface under MME ServiceUse the following configuration to advertise or request UE Usage Type over S6a interface.



[ no ] decor s6a ue-usage-typeend

NOTES:

• decor: Specifies the DECOR configuration.

• s6a: Configures the S6a interface.

• ue-usage-type: Specifies the UE Usage Type that needs to be sent in theAuthentication-Information-Request message over S6a interface.

• no: Disables the specified configuration.

Configuring UE Usage Type over S6a Interface under Call Control ProfileUse the following configuration to disable UE Usage Type requests over the S6a interface.


decor s6a ue-usage-type [ suppress ]remove decor s6a ue-usage-typeend

NOTES:


Dedicated Core Networks on MMEConfiguring UE Usage Type over S6a Interface under MME Service


• s6a: Enables the DECOR S6a configuration.

• ue-usage-type: Requests the UE Usage Type in S6a Authentication-Information-Request message.

• suppress: Suppresses sending the UE Usage Type in S6a Authentication-Information-Request message.

• remove: Removes the DECOR configuration.

• The configuration under call control profile overrides the MME service configuration.

Configuring UE Usage Type under Call Control ProfileUse the following configuration to locally configure the UE Usage Types for UEs matching the Call ControlProfile criteria.


decor ue-usage-type usage_type_value

remove decor ue-usage-typeend

NOTES:


• ue-usage-type usage_type_value: Configures a UE Usage Type locally. usage_type_value must be aninteger from 0 to 255.

• remove: Removes the specified configuration.

Configuring Non-Broadcast TAIUse the following configuration to configure non-broadcast TAI. The configuration is added in support ofHSS Initiated Dedicated Core Network Reselection.

When HSS sends ISDRwith different UE-Usage-Type value other than what is already used by the subscriberand MME decides to move that UE to a new DCN, MME will send the GUTI Reallocation command withunchanged GUTI and non-broadcast TAI.



tai non-broadcast mcc mcc_id mnc mnc_id tac tac_id

no tai non-broadcastend

NOTES:

• tai non-broadcast mcc mcc_id mnc mnc_id tac tac_id: Specifies the Tracking Area Identity (TAI)which is not assigned to any area.

mcc mcc_id: Configures the mobile country code (MCC) for the specified decor profile. mcc_id mustbe a 3-digit number between 000 to 999.


Dedicated Core Networks on MMEConfiguring UE Usage Type under Call Control Profile

mnc mnc_id: Configures the mobile network code (MNC) for the specified decor profile. mnc_id mustbe a 2- or 3-digit number between 00 to 999.

tac tac_id: Configures the tracking area code (TAC) for the specified decor profile. tac_id must be aninteger from 0 to 65535.

• no: Deletes the specified configuration.

Monitoring and TroubleshootingThis section provides information on the show commands available to support DECOR on MME.

Show Commands and/or OutputsThis section provides information regarding show commands and/or their outputs in support of the DECORfeature.

show decor-profile full allThe output of this command includes the following information

• Decor Profile Name — Displays the configured decor-profile name.

• UE Usage Types — Displays the configured UE usage types.

• MMEGI — Displays the MMEGI value.

• DNS — Indicates whether DNS is enabled or disabled.

• DCN Id — Displays the configured DCN identifier. Displays "Not Defined" if not configured.

• PLMN Id — Displays the configured PLMN identifier. Displays "Not Defined" if not configured.

• Serving DCN— Indicates whether MME is serving the DCN. Displays "Not Defined" if not configured.

• Relative capacity — Indicates the configured relative capacity.

• DNS Service Param — Displays the configured DNS service parameter.

show mme-service name <mme_svc_name>The output of this command includes the following information:

• Non-Broadcast TAI — Displays the configured values for MCC, MNC, and TAC.

show mme-service session full allThe output of this command includes the following DECOR information:

• DECOR Information:

• UE Usage type

• DCN Id


Dedicated Core Networks on MMEMonitoring and Troubleshooting

show mme-service statistics decor decor-profile <decor_profile_name>This show command displays the DECOR statistics for a specified DECOR profile. The DECOR profile levelstatistics are pegged only if a DECOR profile is configured.

The output of this command includes the following information:

• Decor Statistics

• Attached Calls

• Initial Requests

• ATTACH

• Accepts

• Reroutes

• Rejects

• TAU

• Accepts

• Reroutes

• Rejects

• Rerouted Requests

• ATTACH

• Accepts

• Rejects

• TAU

• Accepts

• Rejects

• UE-Usage-Type Source

• HSS

• UE Context

• Peer MME

• Peer SGSN

• Config

• eNB

• GUTI Reallocation Cmd due to UE-Usage-Type Change

• Attempted


Dedicated Core Networks on MMEshow mme-service statistics decor decor-profile <decor_profile_name>

• Success

• Failures

• Handover from service area

• DCN

• Non DCN

• Explicit AIR

• Attach

• Inbound relocation

• Inbound relocation using TAU procedure

• ISDR UE-Usage-Type Change

• MMEGI Selection

• DNS

• Local

• Failure

• Node Selection

• SGW DNS

• Common

• Dedicated

• SGW Local Config

• Common

• PGW DNS

• Common

• Dedicated

• PGW Local Config

• Common

• MME DNS

• Common

• Dedicated

• MME Local Config

• Common


Dedicated Core Networks on MMEshow mme-service statistics decor decor-profile <decor_profile_name>

• SGSN DNS

• Common

• Dedicated

• SGSN Local Config

• Common

show mme-service statistics decorThe output of this command includes the following information:


• Attached Calls


• ATTACH

• Accepts

• Reroutes

• Rejects

• TAU

• Accepts

• Reroutes

• Rejects


• ATTACH

• Accepts

• Rejects

• TAU

• Accepts

• Rejects


• HSS

• UE Context

• Peer MME


Dedicated Core Networks on MMEshow mme-service statistics decor

• Peer SGSN

• Config

• eNodeB


• Attempted

• Success

• Failures


• DCN

• Non DCN

• Explicit AIR

• Attach




• MMEGI Selection

• DNS

• Local

• Failure

• Node Selection

• SGW DNS

• Common

• Dedicated


• Common

• PGW DNS

• Common

• Dedicated


• Common


Dedicated Core Networks on MMEshow mme-service statistics decor

• MME DNS

• Common

• Dedicated


• Common

• SGSN DNS

• Common

• Dedicated


• Common

show mme-service statisticsThe output of this command includes the following information at an MME service level:

• S1AP Statistics

• Reroute NAS Requests


• Attached Calls


• ATTACH

• Accepts

• Reroutes

• Rejects

• TAU

• Accepts

• Reroutes

• Rejects


• ATTACH

• Accepts

• Rejects


Dedicated Core Networks on MMEshow mme-service statistics

• TAU

• Accepts

• Rejects


• HSS

• UE Context

• Peer MME

• Peer SGSN

• Config

• eNodeB


• Attempted

• Success

• Failures


• DCN

• Non DCN

• Explicit AIR

• Attach




• MMEGI Selection

• DNS

• Local

• Failure

• Node Selection

• SGW DNS

• Common

• Dedicated


Dedicated Core Networks on MMEshow mme-service statistics


• Common

• PGW DNS

• Common

• Dedicated


• Common

• MME DNS

• Common

• Dedicated


• Common

• SGSN DNS

• Common

• Dedicated


• Common

show mme-service statistics recovered-valuesThe output of this command includes the following information:

Decor Statistics:


• ATTACH

• Accepts

• Reroutes

• Rejects

• TAU

• Accepts

• Reroutes

• Rejects


Dedicated Core Networks on MMEshow mme-service statistics recovered-values


• ATTACH

• Accepts

• Rejects

• TAU

• Accepts

• Rejects

Bulk StatisticsThe MME schema and MME Decor schema include the supported bulk statistics for the DECOR feature.

MME SchemaThe following bulk statistics are added in the MME schema:


Indicates the number of MME sessions attached that have anassociated UE usage type.

mme-decor-attached-subscriber

Indicates the total number of Initial Attach Requests acceptedby the MME, which functions as a DCN.

mme-decor-initial-attach-req-accept

Indicates the total number of Initial Attach Requests which arererouted by the MME, which functions as a DCN.

mme-decor-initial-attach-req-reroute

Indicates the total number of Initial Attach Rejects due to NoReroute data and not handled by the MME, which functions asa DCN.

mme-decor-initial-attach-req-reject

Indicates the total number of Rerouted Attach Requests whichare accepted by the MME, which functions as a DCN.

mme-decor-reroute-attach-req-accept

Indicates the total number of Rerouted Attach Requests whichare rejected by the MME, which functions as a DCN.

mme-decor-reroute-attach-req-reject

Indicates the total number of Initial TAU Requests accepted bythe MME, which functions as a DCN.

mme-decor-initial-tau-req-accept

Indicates the total number of Initial TAU Requests which arererouted by the MME, which functions as a DCN.

mme-decor-initial-tau-req-reroute

Indicates the total number of Initial TAU Rejects due to NoReroute data and not handled by the MME, which functions asa DCN.

mme-decor-initial-tau-req-reject


Dedicated Core Networks on MMEBulk Statistics


Indicates the total number of Rerouted TAU Requests whichare accepted by the MME, which functions as a DCN.

mme-decor-reroute-tau-req-accept

Indicates the total number of Rerouted TAU Requests whichare rejected by the MME, which functions as a DCN.

mme-decor-reroute-tau-req-reject

Indicates the number of MME subscriber sessions, where UEusage type was obtained from HSS/AUC.

mme-decor-ue-usage-type-src-hss

Indicates the number of MME subscriber sessions, where UEusage type was obtained from MME DB record.

mme-decor-ue-usage-type-src-ue-ctxt

Indicates the number of MME subscriber sessions, where UEusage type was obtained from peer MME as part of handover.

mme-decor-ue-usage-type-src-peer-mme

Indicates the number of MME subscriber sessions, where UEusage type was obtained from peer SGSN as part of handover.

mme-decor-ue-usage-type-src-peer-sgsn

Indicates the number of MME subscriber sessions, where UEusage type was obtained from local configuration.

mme-decor-ue-usage-type-src-cfg

Indicates the number of MME subscriber sessions, where UEusage type was obtained from the eNodeB, in the S1 messageas part of reroute.

mme-decor-ue-usage-type-src-enb

Indicates the number of times S-GWDNS selection procedureswere performed with DNS RR excluding UE usage type.

This counter increments only when the DNSRRwith UE usagetype is absent.

mme-decor-sgw-sel-dns-common

Indicates the number of times S-GWDNS selection procedureswere performed with DNS RR including UE usage typeparameter(s).

This counter increments only when the DNSRRwith UE usagetype is present.

mme-decor-sgw-sel-dns-dedicated

Indicates the number of times S-GW selection procedures wereperformed with locally configured S-GW address, withoutconsidering the UE usage type.

mme-decor-sgw-sel-local-cfg-common

Indicates the number of times PGW DNS selection procedureswere performed with DNS RR excluding UE usage type.


mme-decor-pgw-sel-dns-common

Indicates the number of times S-GWDNS selection procedureswere performed with DNS RR including UE usage typeparameter(s).


mme-decor-pgw-sel-dns-dedicated


Dedicated Core Networks on MMEMME Schema


Indicates the number of times P-GW selection procedures wereperformed with locally configured P-GW address withoutconsidering the UE usage type.

mme-decor-pgw-sel-local-cfg-common

Indicates the number of times MMEDNS selection procedureswere performed with DNS RR excluding UE usage type.


mme-decor-mme-sel-dns-common

Indicates the number of times MMEDNS selection procedureswere performed with DNS RR including UE usage typeparameter(s).


mme-decor-mme-sel-dns-dedicated

Indicates the number of times MME selection procedures wereperformed with locally configured MME address withoutconsidering the UE usage type.

mme-decor-mme-sel-local-cfg-common

Indicates the number of times SGSNDNS selection procedureswere performed with DNS RR excluding UE usage type.


mme-decor-sgsn-sel-dns-common

Indicates the number of times SGSNDNS selection procedureswere performed with DNS RR including UE usage typeparameter(s).


mme-decor-sgsn-sel-dns-dedicated


This counter increments for every inbound handover fromDCNservice area.

mme-decor-handover-srv-area-dcn


This counter increments for every inbound handover from nonDCN service area.

mme-decor-handover-srv-area-non-dcn

Indicates the number of explicit AIR messages during Attach.

This counter increments when MME triggers an explicit AIRduring Attach.

mme-decor-explicit-air-attach





This counter increments when MME triggers explicit an AIRduring inbound relocation.

mme-decor-explicit-air-in-reallocation


This counter increments when MME triggers an explicit AIRduring inbound relocation using TAU.

mme-decor-explicit-air-tau-in-reallocation

Indicates the number of times SGSN selection procedures wereperformed with locally configured SGSN address withoutconsidering the UE usage type.

mme-decor-sgsn-sel-local-cfg-common

Indicates the number of S1 Reroute NASRequestMessage sentby MME.

s1ap-transdata-reroutenasreq

Indicates the total number of timesMMEGI is selected throughDNS from a dedicated pool (DNS records having UE UsageType which is matching).

mme-decor-mmegi-sel-dns

Indicates the total number of times MMEGI is selected fromlocal configuration.

mme-decor-mmegi-sel-local-cfg

Indicates the total number of times MMEGI is selected fromfailure.

mme-decor-mmegi-sel-fail

This proprietary counter tracks the number of GUTIReallocationprocedures attempted due to UE-Usage-Type Change fromHSSthrough ISDR OR after connected mode handover andUE-Usage-Type not served by the MME (NAS GUTIReallocation Command message was sent by MME).

mme-decor-guti-reallocation-attempted

Tracks the number of GUTI Reallocation procedures successful.mme-decor-guti-reallocation-success

Tracks the number of GUTI Reallocation procedure failures.mme-decor-guti-reallocation-failures

Tracks the number of ISDR Messages received with differentUE-Usage-Type from the HSS.

mme-decor-isdr-ue-usage-type-change

Indicates the total number of Initial Attach Requests acceptedby the MME, which functions as a DCN.

recovered-mme-decor-initial-attach-req-accept

Indicates the total number of Initial Attach Requests which arererouted by the MME, which functions as a DCN.

recovered-mme-decor-initial-attach-req-reroute

Indicates the total number of Initial Attach Rejects without thereroute data and that are not handled by the MME, whichfunctions as a DCN.

recovered-mme-decor-initial-attach-req-reject




Indicates the total number of Rerouted Attach Requests whichare accepted by the MME, which functions as a DCN.

recovered-mme-decor-reroute-attach-req-accept

Indicates the total number of Rerouted Attach Requests whichare rejected by the MME, which functions as a DCN.

recovered-mme-decor-reroute-attach-req-reject

Indicates the total number of Initial TAU Requests accepted bythe MME, which functions as a DCN.

recovered-mme-decor-initial-tau-req-accept

Indicates the total number of Initial TAU Requests which arererouted by the MME, which functions as a DCN.

recovered-mme-decor-initial-tau-req-reroute

Indicates the total number of Initial TAU Rejects due to NoReroute data and not handled by the MME, which functions asa DCN.

recovered-mme-decor-initial-tau-req-reject

Indicates the total number of Rerouted TAU Requests whichare accepted by the MME, which functions as a DCN.

recovered-mme-decor-reroute-tau-req-accept

Indicates the total number of Rerouted TAU Requests whichare rejected by the MME, which functions as a DCN.

recovered-mme-decor-reroute-tau-req-accept

MME Decor SchemaThe following bulk statistics for a specific decor-profile are added in the MME Decor schema:


Indicates the name of the DECOR profile.mme-decor-profile-name

Indicates the total number of subscribers on the MME which isacting as a DCN.

mme-decor-profile-attached-subscriber

Indicates the total number of Initial Attach Requests acceptedby the MME that is acting as a DCN.

mme-decor-profile-initial-attach-req-accept

Indicates the total number of Initial Attach Requests which arererouted by the MME that is acting as a DCN.

mme-decor-profile-initial-attach-req-reroute

Indicates the total number of Initial Attach Rejects due to NoReroute Data and not handled by the MME that is acting as aDCN.

mme-decor-profile-initial-attach-req-reject

Indicates the total number of Rerouted Attach Requests whichare accepted by the MME that is acting as a DCN.

mme-decor-profile-reroute-attach-req-accept

Indicates the total number of Rerouted Attach Requests whichare rejected by the MME that is acting as a DCN.

mme-decor-profile-reroute-attach-req-reject

Indicates the total number of Initial TAU Reuquests acceptedby the MME that is acting as a DCN.

mme-decor-profile-initial-tau-req-accept


Dedicated Core Networks on MMEMME Decor Schema


Indicates the total number of Initial TAU Reuquests which arererouted by the MME that is acting as a DCN.

mme-decor-profile-initial-tau-req-reroute

Indicates the total number of Initial TAU Rejects due to NoReroute Data and not handled by the MME that is acting as aDCN.

mme-decor-profile-initial-tau-req-reject

Indicates the total number of Rerouted TAU Requests whichare accepted by the MME that is acting as a DCN.

mme-decor-profile-reroute-tau-req-accept

Indicates the total number of Rerouted TAU Requests whichare rejected by the MME that is acting as a DCN.

mme-decor-profile-reroute-tau-req-reject

Indicates the total number of times UE Usage Type is receivedfrom the HSS and used by the MME.

mme-decor-profile-ue-usage-type-src-hss

Indicates the total number of times UE Usage Type is fetchedfrom the local DB Record and used by the MME.

mme-decor-profile-ue-usage-type-src-ue-ctxt

Indicates the total number of times UE Usage Type is receivedfrom the peer MME and used by the MME.

mme-decor-profile-ue-usage-type-src-peer-mme

Indicates the total number of times UE Usage Type is receivedfrom the peer SGSN and used by the MME.

mme-decor-profile-ue-usage-type-src-peer-sgsn

Indicates the total number of times UE Usage Type is fetchedfrom the local configuration and used by the MME.

mme-decor-profile-ue-usage-type-src-cfg

Indicates the total number of times UE Usage Type is receivedfrom the eNodeB and used by the MME.

mme-decor-profile-ue-usage-type-src-enb

Indicates the total number of times S-GW is selected throughDNS from a common pool (DNS records without UE UsageType).

mme-decor-profile-sgw-sel-dns-common

Indicates the total number of times S-GW is selected throughDNS from a dedicated pool (DNS records with matching UEUsage Type).

mme-decor-profile-sgw-sel-dns-dedicated

Indicates the total number of times S-GW is selected from thelocal configuration without UE Usage Type.

mme-decor-profile-sgw-sel-local-cfg-common

Indicates the total number of times P-GW is selected throughDNS from a common pool (DNS records without UE UsageType).

mme-decor-profile-pgw-sel-dns-common

Indicates the total number of times P-GW is selected throughDNS from a dedicated pool (DNS records with matching UEUsage Type).

mme-decor-profile-pgw-sel-dns-dedicated

Indicates the total number of times P-GW is selected from thelocal configuration without UE Usage Type.

mme-decor-profile-pgw-sel-local-cfg-common




Indicates the total number of times MME is selected throughDNS from a common pool (DNS records without UE UsageType).

mme-decor-profile-mme-sel-dns-common

Indicates the total number of times MME is selected throughDNS from a dedicated pool (DNS records with matching UEUsage Type).

mme-decor-profile-mme-sel-dns-dedicated

Indicates the total number of times MME is selected from thelocal configuration without UE Usage Type.

mme-decor-profile-mme-sel-local-cfg-common

Indicates the total number of times SGSN is selected throughDNS from a common pool (DNS records without UE UsageType).

mme-decor-profile-sgsn-sel-dns-common

Indicates the total number of times SGSN is selected throughDNS from a dedicated pool (DNS records with matching UEUsage Type).

mme-decor-profile-sgsn-sel-dns-dedicated

Indicates the total number of times SGSN is selected from thelocal configuration without UE Usage Type.

mme-decor-profile-sgsn-sel-local-cfg-common

Indicates the total number of timesMMEGI is selected throughDNS from a dedicated pool (DNS records with matching UEUsage Type).

mme-decor-profile-mmegi-sel-dns

Indicates the total number of times MMEGI is selected fromthe local configuration.

mme-decor-profile-mmegi-sel-local-cfg

Indicates the total number of times MMEGI selection failed.mme-decor-profile-mmegi-sel-fail

Indicates the number of GUTI Reallocation proceduresattempted due to UE-Usage-Type Change from HSS throughISDR OR after connected mode handover and UE-Usage-Typenot served by this MME (NAS GUTI Reallocation Commandmessage was sent by MME).

mme-decor-profile-guti-reallocation-attempted

Indicates the number of successful GUTI Reallocationprocedures.

mme-decor-profile-guti-reallocation-success

Indicates the number of failed GUTI Reallocation procedures.mme-decor-profile-guti-reallocation-failures

Indicates the number of ISDRMessages received with differentUE-Usage-Type from the HSS.

mme-decor-profile-isdr-ue-usage-type-change

Indicates the number of explicit AIR messages during Attach.mme-decor-profile-explicit-air-attach


mme-decor-profile-explicit-air-in-relocation


mme-decor-profile-explicit-air-tau-in-relocation





mme-decor-profile-handover-srv-area-dcn


mme-decor-profile-handover-srv-area-non-dcn



C H A P T E R 16Deprecation of Manual Scaling



UASApplicable Product(s) or Functional Area





• Ultra Services Platform Deployment AutomationGuide


Revision History


6.0 through 6.14The support for manual scale-in and scale-outfunctionality has been deprecated in this release.

6.0First introduced

Feature ChangesPrevious Behavior: In previous releases, the Service Function (SF) scaling (including the manual scale-inand scale-out) feature was supported.


New Behavior: In this release, the manual scale-out and scale-in functionalities have been deprecated. Formore information, contact your Cisco account representative.


Deprecation of Manual ScalingFeature Changes

C H A P T E R 17Diameter Proxy Consolidation




All products that use Diameter ProxyApplicable Product(s) or FunctionalArea


Disabled - Configuration RequiredDefault Setting




• SAE-GW administration Guide


Revision History




Feature ChangesThe operator can control the number of Diameter proxy connections towards a peer during a VPC-DI/SCALEsetup. ADiameter proxy runs on a card serving all sessionmanagers and AAAmanagers. In a VPC-DI/SCALEenvironment, a single Diameter proxy is spawned per SF card. With the increase in the support for more SFcards in the VPC-DI/SCALE setup, the number of Diameter proxy increases proportionally, in turn increasingthe number of connections towards the Diameter peers.

To limit the number of Diameter proxies spawned, a new keywordmax is added to the require diameter-proxycommand in the Global Configuration mode.

The VPC-DI/SCALE setup supports the following mode of operation of the Diameter proxy, which is CLIcontrolled:

• Single mode (existing mode): In this mode of operation, only one Diameter proxy operates for the entiresetup that serves all SF cards.

• Multiple mode (existing mode): In this mode of operation each SF card supports only one Diameterproxy, at any point of time, serving all session managers and AAA managers on that card.

• Max mode: In this new mode of operation, each SF card supports a maximum of one Diameter proxy.Here, one Diameter proxy serves session managers and AAA managers on multiple SF cards.

SF cards that do not to have a Diameter proxy running in it are mapped to SF cards that have Diameterproxies running on it.

The Max mode of operation includes the following functionalities:

• This mode operates only in a VPC-DI/SCALE environment.

• The total number of Diameter proxy spawned in the system is CLI controlled.

• Diameter proxies are spawned with a maximum of one Diameter proxy per VM.

• For SF cards where Diameter proxy is not spawned, Diameter proxy is allocated in a round-robin process.

• Increase in Diameter proxies during run-time is applied under the following conditions:

• Only for new VMs that have started during run-time.

• In an existing VM, the Diameter proxies are increased only when the inactive VMs are activatedduring run-time.

For example, in a 16 VM setup that has 12 SF VM active (for session manager), the configurationapplies only 6 Diameter proxies. Now, increasing the number of Diameter proxies is possible onlyif the other inactive VMs (4 VMs) become active. Until then no new Diameter proxy is spawned.

• There will be no reduction in the number of Diameter proxies spawned after initial configuration, unlessthe system is rebooted.

• The Diameter proxy functionality continues with its existing behavior. Each Diameter proxy continuesto support all applications such as: Gx, Gy, Rf, S6B and so on.


Diameter Proxy ConsolidationFeature Changes

LimitationsDuring unplanned card migration, if there is no standby card available and if there is a Diameter proxy thatis down, then all associated cards of this Diameter proxy instance can have session loss.

Command ChangesThis section describes the CLI configuration required to enable the Diameter proxy Consolidation feature.

require diameter-proxy maxUse the following CLI to configure the maximum number of Diameter proxies to be spawned in a system:

configurerequire diameter-proxy max count

[ no ] require diameter-proxyend

NOTES:

• require diameter-proxy: This command enables the Diameter proxy mode.

• max : Configures themaximum number of Diameter proxies to be spawned in the system. count specifiesthe number Diameter proxies to be spawned in the system. The count value is an integer ranging from1 to 48.

• no: Disables the Diameter proxy mode.

• In the above configuration, if the count value is specified as 1, only one Diameter proxy is spawned inthe VPC-DI/SCALE environment for all SF cards. A single Diameter proxy is started on the activenon-DEMUX card. Spawning of one Diameter proxy in this configuration is different than the “requirediameter-proxy single” configuration, which spawns a Diameter proxy on a DEMUX card.

• The count: value configured as 48 is similar to the require diameter-proxy multiple configuration.

Performance Indicator ChangesThis section provides information regarding show commands and/or their outputs in support of this feature.

show diameter diactrl proxy-vm-mapIf the MAX mode is configured and if the Diameter proxy to VM mapping is available, the following newfields are displayed:

• diamproxy instance: Indicates the Diameter proxy instance

• Started on VM: Indicates the VM on which the Diameter proxy instance exists.

• VM served: Indicates the number of VMs served for a particular Diameter proxy instance.


Diameter Proxy ConsolidationLimitations

If theMAXmode is configured and if Diameter proxy to VMmapping is not available, the following messageis displayed:Error: no valid diameter proxy to VM mapping present in diactrl

If MAX mode is not configured, the following message is displayed:Info: proxy-vm-map CLI is valid only for max mode configuration of diamproxy


Diameter Proxy Consolidationshow diameter diactrl proxy-vm-map

C H A P T E R 18DI-Network RSS Encryption

• Feature Summary and Revision History, on page 155• Feature Changes, on page 156• Command Changes, on page 156



VPC-DIApplicable Platform(s)



VPC-DI System Administration GuideRelated Documentation

Revision History



21.8The default setting for Distributed Instance Network (DI-network) RSS traffiic isnow disabled and can be enabled with a new CLI command. In prior releases, thiswas functionality was automatically enabled and was not configurable.



Feature ChangesPrevious Behavior: In Releases prior to 21.8, Receive Side Scaling (RSS) was enabled by default for alltraffic on the internal Distributed Instance network (DI-network) for virtualized StarOS instances.

New Behavior: In Release 21.8 and later, RSS is disabled by default and can be enabled via a new CLI.

Command Changes

iftask di-net-encrypt-rssThis new CLI command has been added to control the enablement of RSS on encrypted traffic on theDI-network.

configure[no] iftask di-net-encrypt-rssend

The default setting is disabled.Note


DI-Network RSS EncryptionFeature Changes

C H A P T E R 19ESC Event Integration with Ultra M Manager











Revision History


N6.0First introduced.

6.2Though this feature was introduced in N6.0, it was not fully qualified. It is now fullyqualified as of this release.


Feature ChangesThough introduced in N6.0, this feature was not fully qualified in that release. It was made available only fortesting purposes.

In 6.2, this feature has been fully qualified for use in the appropriate deployment scenarios. Refer to the UltraServices Platform Deployment Automation Guide for more information.


ESC Event Integration with Ultra M ManagerFeature Changes

C H A P T E R 20Event Logging Support for VPP





• ASR 5500

• VPC-SI





• VPC-SI System Administration Guide


Revision History





Feature ChangesEvent logging facility for Vector Packet Processing (VPP) is added in this release.

Previous Behavior: The VPP event logging facility was not supported in previous releases.

New Behavior: The VPP event logging facility is supported in this release.

Customer Impact: The VPP event logging facility improves maintainability, debugging, and ease of use.

Command Changes

logging filter (Exec Mode)The logging filterCLI command in the Execmode is enhanced to support the Vector Packet Processing (VPP)event logging facility.

logging filter active facility facility level severity_level [ critical-info| no-critical-info ]

Notes:

• facility facility: Specifies the facility to modify the filtering of logged information. The vpp event loggingfacility is added in this release.

• level severity_level: Specifies the level of information to be logged from the following list which isordered from highest to lowest:

• critical - reports critical errors

• error - reports error notifications

• warning - reports warning messages

• unusual - reports unusual errors

• info - reports informational messages

• trace - reports trace information

• debug - reports debug information

• critical-info: Specifies that events with a category attribute of critical information are to be displayed.Examples of these types of events can be seen at bootup when system processes and tasks are beinginitiated. This is the default setting.

• no-critical-info: Specifies that events with a category attribute of critical information are not to bedisplayed.


Event Logging Support for VPPFeature Changes

logging filter (Global Configuration Mode)The logging filter CLI command in the Global Configuration mode is enhanced to support the Vector PacketProcessing (VPP) event logging facility.

configurelogging filter runtime facility facility level severity_level [ critical-info

| no-critical-info ]end

Notes:

• facility facility: Specifies the facility to modify the filtering of logged information. The vpp event loggingfacility is added in this release.

• level severity_level: Specifies the level of information to be logged from the following list which isordered from highest to lowest:

• critical - reports critical errors

• error - reports error notifications

• warning - reports warning messages

• unusual - reports unusual errors

• info - reports informational messages

• trace - reports trace information

• debug - reports debug information

• critical-info: Specifies that events with a category attribute of critical information are to be displayed.Examples of these types of events can be seen at bootup when system processes and tasks are beinginitiated. This is the default setting.

• no-critical-info: Specifies that events with a category attribute of critical information are not to bedisplayed.


Event Logging Support for VPPlogging filter (Global Configuration Mode)


Event Logging Support for VPPlogging filter (Global Configuration Mode)

C H A P T E R 21Handling NPLI Requests




ASR 5500Applicable Platform(s)






Revision History



21.11.3This Behavior Change was introduced in 21.4.15. With this release, HandlingNPLI Requests is also applicable in 21.11.3

21.8.10This Behavior Change was introduced in 21.4.15. With this release, HandlingNPLI Requests is also applicable in 21.8.10

21.4 .15The Update Bearer procedure on default bearer is generated with PCRF requestingfor the NPLI Information even if the CLI no policy-controlupdate-default-bearer is configured.




Feature ChangesThe Update Bearer procedure on default bearer is generated with PCRF requesting for the NPLI Informationeven if the CLI no policy-control update-default-bearer is configured.

Previous Behavior: The Update Bearer procedure on default bearer was not generated to retrieve the UElocation information for Bearer Independent NPLI procedures when NPLI requests were received on thePCEF from the PCRF.

With reference to 3GPP 23.842 Section 6.4.4 “Bearer Independent NPLI fetch by P-CSCF,” the P-GW mustgenerate Update Bearer Request to retrieve the current location of a User. This feature was not achievablewhen the CLI no policy-control update-default-bearer was configured.

New Behavior: A functionality has been added to handle NPLI requests received on PCEF (P-GW) from thePCRF. The Update Bearer procedure on default bearer is now generated even if the CLI no policy-controlupdate-default-beareris configured.

The functionality is restricted to CCA-U and RAR messages. It is not included for CCR-I messages becausethe functionality is considered only for a default bearer setup and not a mid-call User location fetch fromPCRF. Calls coming from a 3G network to a 4G network, CCA-U for RAT_TYPE acknowledgment NPLIrequest will not be considered.

Note


Handling NPLI RequestsFeature Changes

C H A P T E R 22Hash-Value Support in Header Enrichment




P-GWApplicable Product(s) or FunctionalArea

• ASR 5500

• VPC - DI

• VPC - SI







Revision History



21.8Hash-Value strings are implemented as a part of the Header Enrichment feature.




Feature ChangesHash-Value strings are implemented as a part of the Header Enrichment feature. P-GW is enhanced to receiveand store hash values that are received from the PCRF for each subscriber. The stored hash value is insertedin the HTTP/WSP header making it available for operators to handle subscriber profiles.

Somemobile advertisement platforms generate a hashed string based on a subscriber’s MSISDN value.Whena hashed string is sent to content providers, they identify the subscriber’s profile information and in turn insertadvertisements on the subscriber’s browser based on the user profile.

To receive hash-values from the PCRF over the Gx interface, a new AVP: Hash-Value; with an octet-stringdata-type is implemented. The AVP supports a maximum length of 80 characters. The P-GW ignores thehashed string if it exceeds the maximum length. The hash-value received from the PCRF is inserted in theHTTP/WSP header only if HTTP Header Enrichment is enabled for a subscriber.

The X-Header field is used to insert a hash-value in the HTTP/WSP headers. The hash-value can be encryptedbased on the existing encryptionmechanism of X-Header fields. These hash values (encrypted or un-encrypted)are inserted in the HTTP/WSP header based on the x-header format configured under the Charging Actionconfiguration.

A hash-value is check-pointed as a part of the subscriber’s session information. It is check-pointed immediately,once received from the PCRF.

Note

Command Changes

gx hash-valueUse the following configuration to receive the hash-value string over the Gx interface

configurerequire active-chargingactive-charging serviceservice_name

xheader-format format_name

insert xheader_field_name variable gx hash-valueend

NOTES:

• insert: This command allows you to configure the x-header fields to be inserted in HTTP/WSP GETand POST request packets. The xheader_field_name specifies the x-header field name to be inserted inthe packets. It must be an alphanumeric string of 1 through 31 characters.

• variable: Specifies the name of the x-header field whose value must be inserted in the packets.


Hash-Value Support in Header EnrichmentFeature Changes

• gx: Specifies the Gx interface.

• hash-value: Specifies the hash value string received in the Hash-Value AVP.


Hash-Value Support in Header Enrichmentgx hash-value


Hash-Value Support in Header Enrichmentgx hash-value

C H A P T E R 23ICSR Switchover Configuration Support for SFFailures

• Feature Summary and Revision History, on page 169• Feature Description, on page 170• Configuring ICSR Switchover Support for SF Failures, on page 171• Monitoring and Troubleshooting, on page 171







• SNMP MIB Reference Guide



Revision History




21.8.2From this release, a new configurable CLI, monitor system card-fail is introducedthat supports Interchassis Session Recovery (ICSR) switchover for multiple SF cardfailures.


Feature DescriptionIn certain scenarios, multiple SF card failures are observed on the DI-network that lead to capacity or subscriberloss (or both). This occurs when the Standby SF card is unavailable when the second SF card fails, therebyleading to mulitple SF card failures.

In this release, this limitation is addressed with the new configurable CLI, monitor system card-fail. ThisCLI implements Interchassis Session Recovery (ICSR) switchover for multiple SF card failures.

How It WorksWhen the monitor system card-fail CLI is configured, the VPN monitor checks the card failure status toassess if it is feasible to trigger an ICSR switchover. Therefore, when the VPN detects a card monitor failure,it forcefully triggers an SRP switchover with the switchover reason as "Multiple card failure".

An ICSR switchover on the VPC-DI platform is triggered in the following scenarios:

• When any Active SF card fails without Standy card.

• During a planned SF card migration failure without a Standby card available.

LimitationsThe ICSR Switchover Configuration Support for SF Failures has the following limitations.

• If the Standby ICSR instance has any failures and is unstable, ICSR is not triggered from the ActiveICSR instance.

• A single Active SF card failure that already has an available Standby SFcard to take over in a Standby ICSR chassis is not treated as a failure .

• Session Manager recovery in the Standby chassis is not treated as a failure.

Note

• Standby ICSR instance must be in a good state to trigger ICSR to avoid cyclic switchovers.

• When the Active ICSR instance checks the status of the Standby ICSR instance on monitor failure andfinds that the Standby ICSR has other configured monitor failures (multiple SF card failures, BGP, BFD,AAA, or Diameter), then ICSR switchover is not triggered.


ICSR Switchover Configuration Support for SF FailuresFeature Description

Configuring ICSR Switchover Support for SF FailuresThe following section provides information about the CLI command available to enable or disable the feature.

monitor system card-failThis new CLI command is added to enable or disable card failure monitoring on the VPC-DI system. Thiscommand is configured in the Service Redundancy Protocol Configuration Mode.

configure[ no ] monitor system card-failend

NOTES:

• no: Disables card failure monitoring.

• By default, this CLI is disabled.

Monitoring and TroubleshootingThis section provides information regarding CLI commands available in support of monitoring andtroubleshooting the feature.

Show Command(s) and/or OutputsThis section provides information regarding show commands and/or their outputs in support of this feature.

show srp call-loss statisticsThis show command now includes a new value for the "Switchover Reason" field to indicate mulitiple cardfailure.

Multiple Card Failure

Bulk StatisticsThis section lists all the bulk statistics that have been added, modified, or deprecated to support this feature.

ICSR SchemaThis section displays the new bulk statistc added for the ICSR Switchover Configuration Support for SFFailures feature.


Indicates the reason for the ICSR switchover.switchover reason


ICSR Switchover Configuration Support for SF FailuresConfiguring ICSR Switchover Support for SF Failures


ICSR Switchover Configuration Support for SF FailuresICSR Schema

C H A P T E R 24IMEI Validation Failure


• Feature Summary and Revision History, on page 173• Feature Changes, on page 174• Performance Indicator Changes, on page 174


ePDGApplicable Product(s) or FunctionalArea

• ASR 5500

• VPC-DI

• VPC-SI




• ePDG Administration Guide



Revision History


21.4.17Introduced to release 21.4.



Feature ChangesIf invalid IMEI was received from the UE in CFG payload of the first IKE_AUTH request, multiple SessMgrrestart was observed. In this release, graceful handling is added to avoid SessMgr restart.

A new disconnect reason and bulk statistic are added to indicate the IMEI validation failure.


ePDG SchemaThe following new bulk statistic is added in the ePDG schema:

• sess-disconnect-invalid-imei— The total number of sessions disconnected due to Invalid IMEI receivedfrom the UE.

show epdg-service statisticsThe Invalid IMEI field added to the output of this command indicates the total number of sessions disconnecteddue to Invalid IMEI received from the UE.

show session disconnect-reasons verboseThe epdg-invalid-imei(661) field added to the output of this command indicates the total number of sessionsdisconnected due to Invalid IMEI received from the UE.


IMEI Validation FailureFeature Changes

C H A P T E R 25Increased Maximum IFtask Thread Support







VPC-DI System Administration GuideRelated Documentation

Revision History



21.8From this release, the maximum number of IFtask threads configuration supportedis increased to 22 cores.



Feature ChangesWhen the number of DPDK Internal Forwarder (IFTask) threads configured (in /tmp/iftask.cfg) are greaterthan 14 cores, the IFTask drops packets or displays an error.

Previous Behavior: Currently, the maximum number of IFtask threads configuration is limited to only 14cores.

New Behavior: From Release 21.8, the maximum number of IFtask threads configuration supported isincreased to 22 cores.


Increased Maximum IFtask Thread SupportFeature Changes

C H A P T E R 26Increased Subscriber Map Limits





• ASR 5500

• VPC-DI

• VPC-SI







Revision History




21.8The subscriber-map limit to configure IMSI/IMEI groups is increased from 1024 to10000.


Feature ChangesIn this release, the subscriber-map limit to configure IMSI/IMEI groups is increased from 1024 to 10000.

Previous Behavior: The subscriber-map configuration allowed precedence configuration of 1024.

New Behavior: The subscriber-map configuration allows precedence configuration of 10000.

Customer Impact: Different services can be provided to more user groups.

See the Operator Policy Selection Based on IMEI-TAC chapter in the MME Administration Guide for moreinformation.

Command Changes

precedenceThis command in the LTE Subscriber Map Configuration mode specifies the precedence level defined by theoperator to resolve the selection of the operator policy when multiple variable combinations match for aparticular UE. The lowest precedence number takes greater priority during selection.

In this release, the limit of subscriber-map entries is increased from 1024 to 10000.

configurelte-policy

subscriber-map map_name

precedence precedence_number match-criteria imei-tac group group_name [imsi mcc mcc mnc mnc [ msin { first start_msin_value last end_msin_value } ] ][ operator-policy-name policy_name ]

end

Notes:

• precedence_number must be an integer from 1 to 10000, where 1 has the highest precedence.


Increased Subscriber Map LimitsFeature Changes

C H A P T E R 27Inline TCP Optimization

This chapter includes the following topics:

• Feature Summary and Revision History, on page 179• Feature Description, on page 180• How It Works, on page 180• Configuring Inline TCP Optimization, on page 181• Monitoring and Troubleshooting, on page 184




• VPC - DI

• VPC - SI






Revision History


21.10In this release, the throughput gain has been increased. KPIs - separate counters forIP versions (IPv4/IPv6) and application protocols (HTTP/HTTPs), are added.



21.9.1In this release, two new commands - accl-flags and cwnd-gain, are added to theTCP Acceleration Profile Parameters configuration. Configuring these commandsincreases throughput gain and optimized mid-flow proxy engagement proceduresfor TCP accelerated flows.

Also, the output for the show tcp-acceleration-profile command has been updated.

21.9Inline TCP Optimization engine is enhanced to dynamically engage the TCPacceleration module at mid-flow.


Feature DescriptionInline TCP Optimization is an integrated solution to service providers to increase the TCP flow throughputfor TCP connections. This solution enables faster transmission of data for a better user experience.

The Inline TCP Optimization solution ensures accelerated TCP flows using a proprietary algorithm thatprovides efficient and optimal throughput at a given time. A TCP proxy has been integrated with this solutionto monitor and control the TCP congestion window for optimal throughput.

The Inline TCPOptimization solution also supports split TCP sessions to accommodate wireless requirementsand provides feature parity with other existing inline services.

Optimization only applies to the downlink data on the Gn interface.Note

The Inline TCP Optimization feature is license controlled. Contact your Cisco account representative fordetailed information on specific licensing requirements. For information on installing and verifying licenses,refer to the Managing License Keys section of the Software Management Operations chapter in the SystemAdministration Guide.

How It WorksThe TCP Optimization feature includes the following functionalities:

• TCP Connection Splicing: The TCP connections are split into two connections; one connection towardsGn and the other connection towards Gi, inside P-GW. The connections are split in a transparent mannerin the P-GW so that the UE and the Gi servers are transparent to the connection being split.

• TCP Proxy ensures seamless movement of data across these two TCP split connections.

• TCP Optimization is deployed on the Gn interface (towards the UE) of the TCP stack. A user-space TCPstack in P-GW is used.

• Cisco library for TCP optimization:

• Provides algorithms that are designed to increase the TCP throughput.


Inline TCP OptimizationFeature Description

• Interfaces with the User-space TCP stack (Gn interface) and notifies appropriate events that occurin the TCP connection and takes actions accordingly.

• Provides APIs to integrate the Cisco Library (for TCP optimization) and StarOS.

TCP Acceleration is enabled during the start of the TCP flow (when SYN packet is received). It cannot bedisabled later during the flow.

Note

Configuring Inline TCP Optimization

Enabling TCP Acceleration under Active Charging ServiceUse the following configuration to enable TCP acceleration:


tcp-accelerationend

NOTES:

• tcp-acceleration: Enables TCP acceleration under the ACS Configuration mode.

Enabling TCP Acceleration under Trigger ActionUse the following configuration to enable TCP acceleration:



tcp-acceleration profile profile_name

end

NOTES:

• tcp-acceleration: Enables TCP acceleration under the ACS Trigger Action Configuration mode.

• profile: Identifies the TCP acceleration profile. The profile_name is a string ranging from 1 to 63characters.

Configuring a TCP Acceleration ProfileUse the following configuration to configure a TCP Acceleration Profile:


Inline TCP OptimizationConfiguring Inline TCP Optimization


[ no ] tcp-acceleration-profile profile_name

end

NOTES:

• tcp-acceleration-profile: Configures the TCP Acceleration feature profile for inline TCP optimization.

• no: Disables the TCP Acceleration profile.

Configuring TCP Acceleration Profile ParametersUse the following commands to configure the TCP acceleration profile parameters:


[ no ] tcp-acceleration-profile profile_name

accl-flags flag_value

default accl-flagsbuffer-size { [ downlink [ 128KB | 256KB | 512KB | 1024KB | 1536KB

| 2048KB | 2560KB | 3072KB | 3584KB | 4096KB ] [ uplink [ 128KB | 256KB| 512KB | 1024KB | 1536KB | 2048KB | 2560KB | 3072KB | 3584KB | 4096KB] ] ] | [ uplink [ 128KB | 256KB | 512KB | 1024KB | 1536KB | 2048KB |2560KB | 3072KB | 3584KB | 4096KB ] [ downlink [ 128KB | 256KB | 512KB |1024KB | 1536KB | 2048KB | 2560KB | 3072KB | 3584KB | 4096KB ] ] ] }

cwnd-gain { dynamic { off | on } [ factor factor_value ] | factorfactor_value [ dynamic { off | on } ] }

default cwnd-gaindefault buffer-size [ downlink | uplink ]initial-cwnd-size window_size

default initial-cwnd-sizemax-rtt max_rtt_value

default max-rttmss mss_value

default mssend

NOTES:

• default: Assigns or restores default values to its following commands.

• accl-flags: Configures TCP acceleration related optimization flags. The flag_value is an integer rangingfrom 0 to 65535.

• buffer-size: Configures the TCP Proxy buffer size for downlink and uplink data in Kilobytes.

This command is supported from 21.9.1 and later releasesNote


Inline TCP OptimizationConfiguring TCP Acceleration Profile Parameters

• cwnd-gain: Configures the TCP congestion window gain. This command is used by the TCP optimizationengine to continuously calculate the actual congestion window size. Scaling the window size allows theTCP optimization engine to manage the in-flight of data in the engine.

• The dynamic option in this command automatically scales-up the congestion window gain to ensurethat it is sized correctly to allow for RTT variation during the flow.

• The factor option configures the TCP congestion window gain factor. The factor_value is an integerranging from 1 to 16378.

This command is supported from 21.9.1 and later releasesNote

• initial-cwnd-size: Configures the initial congestion window size in segments. The window_size is aninteger ranging from 1 to 65535.

• max-rtt: Configures the maximum RTT value in milliseconds. The max_rtt_value is an integer rangingfrom 1 to 10000.

• mss: Configures the maximum segment size for TCP in Bytes. Themss_value is an integer ranging from496 to 65535.

Configuring Post-Processing Rule Name under Trigger ConditionUse the following commands to configure the post-processing rule names:


trigger-condition trigger_condition_name

post-processing-rule-name { = | contains | ends-with | starts-with} rule_name

[ no ] post-processing-rule-name rule_name

end

NOTES:

• post-processing-rule-name: Sets condition for a particular post-processing rule. The following operatorsspecify how the rules are matched:

• =: Equals

• !=: Not Equals

• contains: Contains

• ends-with: Ends with.

• starts-with: Starts with

• name: Specifies the name of the post-processing rule.


Inline TCP OptimizationConfiguring Post-Processing Rule Name under Trigger Condition

Configuring TCP Acceleration Related EDR AttributesUse the following configuration to configure the EDR attributes:


edr-format edr_format_name

rule-variable tcp [ sn-tcp-accl | sn-tcp-accl-reject-reason |sn-tcp-min-rtt | sn-tcp-rtt ] priority priority_value

end

NOTES:

• rule variable: Assigns a rule variable attributes for EDR or UDR.

• tcp: Specifies Transmission Control Protocol (TCP) related fields.

• sn-tcp-accl: Specifies the TCP Acceleration status for the TCP flow.

• 0: TCP Acceleration is not enabled on the flow.

• 1: TCP Acceleration is enabled on the flow.

• 2: Flow is eligible and attempted, but not TCP Accelerated.

• 3: Flow is eligible, but not attempted for TCP Acceleration

• sn-tcp-accl-reject-reason: Specifies reason for not accelerating the TCP flow.

• sn-tcp-min-rtt: Specifies min RTT observed for accelerated TCP flow.

• sn-tcp-rtt: Specifies smoothed RTT for accelerated TCP flow.

• priority: Specifies the CSV position of the field (protocol rule) in the EDR. Priority must be an integerfrom 1 through 65535.

Monitoring and TroubleshootingThis section provides information regarding monitoring and troubleshooting the feature.


show configurationThe output of this command displays the following fields for this feature::

• tcp-acceleration

• tcp-accelration profile tap

• buffer-size downlink size uplink size


Inline TCP OptimizationConfiguring TCP Acceleration Related EDR Attributes

• initial-cwnd-size

• max-rtt

• mss

show tcp-acceleration-profile { [ all ] | [ name profile-name ] }The output of this command displays the following fields for this feature:

• TCP Acceleration Profile Name

• Initial Congestion Window

• Max RTT

• MSS

• Buffer Size (Downlink)

• Buffer Size (Uplink)

• Cwnd Gain Factor

• Cwnd Gain Dynamic

• Accl Flags

• Total tcp-acceleration-profile found

show active-charging tcp-acceleration infoThe output of this command displays the following fields for this feature:

• TCP Acceleration Library Information

• Version

show active-charging tcp-acceleration statistics sessmgr allThe output of this command displays the following fields for this feature:

• TCP acceleration Statistics

• Total Accelerated Flows

• Current Accelerated Flows

• Released Accelerated Flows

• Rejected Accelerated Flows

• Feature Not Supported

• RAT Type Not Supported

• Bearer Not Supported

• Resource Not Available (Memory)


Inline TCP Optimizationshow tcp-acceleration-profile { [ all ] | [ name profile-name ] }

• Others

• Subscriber Level Statistics

• Total Accelerated Subscribers

• Current Accelerated Subscribers

• Protocol Level Statistics

• Total Flows (IPv4 and IPv6)

• TCP

• HTTP

• HTTPS

• Active Flows (IPv4 and IPv6)

• TCP

• HTTP

• HTTPS

• Current Idle Flows (IPv4 and IPv6)

• TCP

• HTTP

• HTTPS

• Clearer by Idle Timer (IPv4 and IPv6)

• TCP

• HTTP

• HTTPS

• Control Statistics

• IPv4 (User-Side and Inet-Side)

• TCP Terminations Rx

• TCP Terminations Tx

• IPv6 (User-Side and Inet-Side)

• TCP Terminations Rx

• TCP Terminations Tx


Inline TCP Optimizationshow active-charging tcp-acceleration statistics sessmgr all

show active-charging flows full allThe output of this command displays the following fields for this feature::

• TCP Acceleration

show active-charging trigger-action name trigger_action_nameOn executing the above command, the following new field(s) are displayed for this feature:

• TCP Acceleration

show active-charging trigger-condition name nameThe output of this command displays the following fields for this feature:

• Post-Processing Rule-name/GOR

•

Bulk StatisticsThe following bulk statistics are added in theCUSP schema in support of the Inline TCP Optimization (Phase2) feature.


Indicates the total number of TCP accelerated flows.tcpaccl-totflows

Indicates the number of current TCP acceleratedflows.

tcpaccl-currflows

Indicates the total number of IPv4 TCP acceleratedpackets received from the UE.

tcpaccl-usr-ipv4totpkts-rx

Indicates the total number of IPv4 TCP acceleratedbytes received from the UE.

tcpaccl-usr-ipv4totbytes-rx

Indicates the total number of IPv4 TCP acceleratedpackets sent towards the UE.

tcpaccl-usr-ipv4totpkts-tx

Indicates the total number of IPv4 TCP acceleratedbytes sent towards the UE.

tcpaccl-usr-ipv4totbytes-tx

Indicates the total number of IPv4 TCP acceleratedpackets received from the internet.

tcpaccl-inet-ipv4totpkts-rx

Indicates the total number of IPv4 TCP acceleratedbytes received from the internet.

tcpaccl-inet-ipv4totbytes-rx

Indicates the total number of IPv4 TCP acceleratedpackets sent towards the internet.

tcpaccl-inet-ipv4totpkts-tx


Inline TCP Optimizationshow active-charging flows full all


Indicates the total number of IPv4 TCP acceleratedbytes sent towards the internet.

tcpaccl-inet-ipv4totbytes-tx

Indicates the total number of IPv6 TCP acceleratedpackets received from the UE.

tcpaccl-usr-ipv6totpkts-rx

Indicates the total number of IPv6 TCP acceleratedbytes received from the UE.

tcpaccl-usr-ipv6totbytes-rx

Indicates the total number of IPv6 TCP acceleratedpackets sent towards the UE.

tcpaccl-usr-ipv6totpkts-tx

Indicates the total number of IPv6 TCP acceleratedbytes sent towards the UE.

tcpaccl-usr-ipv6totbytes-tx

Indicates the total number of IPv6 TCP acceleratedpackets received from the internet.

tcpaccl-inet-ipv6totpkts-rx

Indicates the total number of IPv6 TCP acceleratedbytes received from the internet.

tcpaccl-inet-ipv6totbytes-rx

Indicates the total number of IPv6 TCP acceleratedpackets sent towards the internet.

tcpaccl-inet-ipv6totpkts-tx

Indicates the total number of IPv6 TCP acceleratedbytes sent towards the internet.

tcpaccl-inet-ipv6totbytes-tx


Inline TCP OptimizationBulk Statistics

C H A P T E R 28IPv6 PDN Type Restriction





• ASR 5500

• VPC-DI

• VPC-SI








Revision History




21.8Support is added to enable the MME to allow only IPv4 addresses to a PDNconnection.


Feature ChangesThis enhancement enables the MME to restrict IPv6 PDN connection in roaming networks.

Previous Behavior: MME allowed the UE to include IPv6 address if the UE had requested and subscribedfor IPv6 address.

New Behavior: MMEwill not allow the UE to include IPv6 address even if the UE has requested and subscribedfor the IPv6 address.

The pdn-type-override ipv4-only CLI command is added in the Call Control Profile Configuration mode.MME will ensure that PDN will not receive any IPv6 address either by rejecting with PDN ConnectivityRequest or by overriding it only with IPv4 address.

The following table explains the behavior of MME when pdn-type-override ipv4-only CLI is enabled.

BehaviorHSS SubscriptionUE Requested PDN Type

PDN is assigned with IPv4 addressonly.

IPv4v6IPv4


IPv4IPv4

PDNReject with cause 32 "Serviceoption not supported".

IPv6IPv4


IPv4v6IPv6

PDNReject with cause "Only IPv4is supported".

IPv4IPv6


IPv6IPv6


IPv4v6IPv4v6


IPv4IPv4v6


IPv6IPv4v6


IPv6 PDN Type RestrictionFeature Changes

Command Changes

pdn-type-overrideIn the Call Control Profile Configuration mode, the pdn-type-override CLI command is enhanced to enablethe MME to allow only IPv4 addresses to a PDN connection. The ipv4-only keyword is new in this release.


[ remove ] pdn-type-override ipv4-onlyend

NOTES:

• remove pdn-type-override ipv4-only: Disables the MME from allowing only IPv4 addresses to a PDNconnection.

Once the CLI is removed, MME will not restrict the IPv6 addresses to be allocated to the PDN.

• The default behavior allows PDN to have IPv6 addresses when subscription allows it.


show call-control-profile full allThe PDN Type IPv6 Denied field added to the output of this command displays "Configured" or "NotConfigured" to indicate whether the MME is enabled to allow only IPv4 addresses to a PDN connection.


IPv6 PDN Type RestrictionCommand Changes


IPv6 PDN Type Restrictionshow call-control-profile full all

C H A P T E R 29Limiting Cores on Local File Storage





• ASR 5500

• VPC-DI

• VPC-SI




• ASR 5500 System Administration Guide



• VPC-SI System Administration Guide


Revision History




21.8The maximum number of core files to retain on the local storage before rotation canbe configured in this release.


Feature ChangesThe limitation on the maximum number of full cores that can be stored on either /flash or /hd-raid is changedin this release.

Previous Behavior: The maximum number of core files was limited to 15 full cores if the destination URLwas configured to local storage such as /flash or /hd-raid. The oldest core files would be rotated to retain thelatest 15 full cores.This behavior was applicable only to the VPC-DI/VPC-SI platforms.

New Behavior: The maximum number of core files to be retained before rotation is configurable using thecrash enable CLI command and not limited to 15 full cores. The destination URL storage path to externalserver using SFTP/HTTP is configured to retain the core files generated. This behavior is applicable to ASR5500 and VPC-DI/VPC-SI platforms.

Command Changes

crash enableIn the Global Configuration mode, the crash enable CLI command is enhanced to configure the maximumnumber of core files that can be retained before rotation. The rotate keyword is new in this release.

configurecrash enable { url crash_url [ rotate num_cores ] }end

Notes:

• url crash_url: Specifies the location to store crash files. crash_url refers to a local or remote file.

• rotate num_cores: Specifies the number of core dumps to retain on the local storage. num_cores mustbe an integer from 1 to 256.

Default: 15


Limiting Cores on Local File StorageFeature Changes

C H A P T E R 30LTE to Wi-Fi (S2bGTP) Seamless Handover


• Feature Summary and Revision History, on page 195• Feature Description, on page 196• How It Works, on page 196• Configuring LTE to Wi-Fi Seamless Handover, on page 198• Monitoring and Troubleshooting, on page 198


Applicable Product(s) or Functional Area • P-GW

• SAEGW


• VPC - DI

• VPC - SI








Revision History

Revision history details are not provided for features introduced before release 21.2 and N5.1.Important


21.8With this release, support has been added for seamlesshandover of subscribers from LTE to Wi-Fi(S2bGTP).


Feature DescriptionWhen handover is initiated from LTE to Wi-Fi, the Delete Bearer Request (DBR) is sent over the LTE tunnelimmediately when the Create Session Response (CSR) is sent on the Wi-Fi tunnel. This causes some packetloss because of the IPSec tunnel establishment delay at the ePDG. To address the issue of packet loss, anenhancement is introduced, in Release 21.8, that holds both the tunnels (LTE andWi-Fi) and sends the DeleteBearer Request on LTE tunnel only when uplink data is seen on theWi-Fi tunnel or on expiry of the configuredhandover timer (when there is no uplink data), whichever is earlier. As long as the LTE tunnel is active, uplinkand downlink data is exchanged on the LTE tunnel. When handover is complete, uplink and downlink datais exchanged on the Wi-Fi tunnel. This prevents packet loss.

With this enhancement, the following benefits can be seen:

• Minimum packet loss during LTE to Wi-Fi (S2bGTP) handover and making the handover seamless (thatis, MAKE before BREAK).

• LTE procedures are handled gracefully over the LTE tunnel when both tunnels are established with theP-GW.

• Wi-Fi procedures are handled gracefully over the Wi-Fi tunnel when both tunnels are established withthe P-GW.

• When there are two tunnels (LTE andWi-Fi) established for the same subscriber, GTP-U error indicationand GTP-U path failure on the LTE or Wi-Fi tunnel (default or dedicated bearer) are handled properlyduring the transition period.

How It WorksThe LTE to Wi-Fi (S2bGTP) Seamless Handover works as explained in the following sections.

LTE to Wi-Fi HandoffThe LTE to Wi-Fi handoff occurs as follows:

1. The P-GW delays sending the DBR to the S-GW until:


LTE to Wi-Fi (S2bGTP) Seamless HandoverFeature Description

• CSR expiry is sent to the ePDG (default behavior).

• Uplink data is sent on the Wi-Fi tunnel.

• Handover timer has expired. If timer expires, the ePDG does not send the Modify Bearer Request(MBR) to notify handoff completion.

2. After CSR for LTE to Wi-Fi handoff is received, Control Plane GTPv2 (GTP-C) messages from LTEaccess are not handled at the P-GW. These messages are blocked at the EGTPC.

3. LTE tunnel carries GTP-U traffic during the transition period. Transition period is defined as time betweenCSR (for LTE to Wi-Fi handoff is received) and handover completion. MBR for handoff completion isnot expected in this scenario.

4. In case of multiple outstanding CCR-Us being supported, all requests before the handoff request aredropped. This is done at IMSA.

5. During the transition period:

• If Modify Bearer Command (MBC) is received inWi-Fi, it is rejected with Service-Denied message.

• If Delete Bearer Command for dedicated bearer is received in LTE, it is discarded.

• If PCRF sends RAR for policy change, it is processed after handover is complete.

• New tunnel (that is, Wi-Fi) does not carry any GTP-U traffic. Any GTP-U traffic that is received onthe Wi-Fi during the transition period is dropped or ignored. Similarly, any downlink traffic that isreceived on the Wi-Fi is sent on an older tunnel (that is, LTE tunnel) until DBR is sent on the Wi-Fitunnel. This is true even when CSR is sent on the Wi-Fi tunnel. Any uplink traffic that is receivedon theWi-Fi tunnel before timer expiry triggers the handover completion, and from then on all trafficis forwarded only through the Wi-Fi tunnel.

• Any pending transactions on LTE access are discarded. For example, if CBR or UBR is sent for LTEaccess and handoff is initiated before completion of CBR or UBR transaction, then CBR or UBR isignored at the P-GW. PCRF is not notified about failure.

• If ASR is received, then call drop occurs and both tunnels go down.

• If session-release occurs from PCRF, then call is dropped and CSR is sent with cause as“no-resources”.

• GTP-U or GTP-C path failure over LTE leads to call drop for LTE access while the Wi-Fi callcontinues.

• GTP-U or GTP-C path failure over Wi-Fi leads to call drop. Both tunnels are cleared.

• If the user moves back to LTE (that is, back to back handoff from LTE toWi-Fi to LTE) with HO-Indset to 1 (after guard timer), then the HO is processed successfully and user session is moved to LTEagain.

• If the user moves back to LTE (that is, back to back handoff from LTE toWi-Fi to LTE) with HO-Indset to 0, then it leads to context replacement. Old call is cleared on Wi-Fi access with reason ascontext replacement and call is processed like a new call over LTE.


LTE to Wi-Fi (S2bGTP) Seamless HandoverLTE to Wi-Fi Handoff

Session Recovery and ICSRDuring the transition period, old access is considered as stable state and Full Checkpoint is triggered oncehandover is complete from LTE to Wi-Fi (S2bGTP). This is done for both Session Recovery and ICSR.

Configuring LTE to Wi-Fi Seamless HandoverThe following section provides information about the CLI commands available to enable or disable the feature.

Configuring LTE to Wi-Fi Handover TimerUse the following CLI commands to configure LTE to Wi-Fi handover timer.


apn apn_name

lte-s2bgtp-first-uplink timeout

{ default | no } lte-s2bgtp-first-uplinkend

NOTES:

• default: Enables the LTE to Wi-Fi handover completion to occur when the Create Session Response issent on the Wi-Fi tunnel.

• no: Disables the feature and handover completion occurs on Create Session Response.

• lte-s2bgtp-first-uplink timeout: Configures LTE to S2bGTP handover completion timeout in multiplesof 100 milliseconds. The valid range is from 100 to 3000. The recommended configuration is 1000milliseconds.

• By default, the LTE to Wi-Fi handover completion happens when Create Session Response is sent onthe Wi-Fi tunnel. However, after handover timeout is configured, the handover is delayed until timeoutor on receipt of uplink data on the Wi-Fi tunnel.



show apn statistics name <name>The output of this CLI command has been enhanced to display the following new fields for the APN:

• LTE-to-S2bGTP handover Succeeded on First Uplink Data on S2b tunnel – Specifies the number ofhandovers due to uplink packets.


LTE to Wi-Fi (S2bGTP) Seamless HandoverSession Recovery and ICSR

• LTE-to-S2bGTP handover Succeeded on Timer Expiry – Specifies the number of handovers due to timerexpiry.

NOTES:

The new fields, introduced as part of this feature, are also displayed for the following CLI commands:

• show pgw-service statistics name service_name verbose

• show pgw-service statistics all verbose

• show saegw-service statistics all function pgw verbose

Bulk StatisticsThe following statistics are included in support of this feature.

APN SchemaThe following bulk statistics are added for APN in the APN schema in support of the LTE to Wi-Fi SeamlessHandover feature.


Number of LTE to S2bGTP handover succeeded onTimer Expiry.

apn-handoverstat-ltetos2bgtpsucc-timerexpiry

Number of LTE to S2bGTP handover succeeded onUplink Data on the S2b tunnel.

apn-handoverstat-ltetos2bgtpsucc-uplnkdata

P-GW SchemaThe following bulk statistics are added for P-GW in the P-GW schema in support of the LTE toWi-Fi SeamlessHandover feature.


Handover Statistics - Number of LTE to GTP S2bsuccessful handovers on Timer Expiry.

handoverstat-ltetos2bgtpsucc-timerexpiry

Handover Statistics - Number of LTE to GTP S2bsuccessful handovers on Uplink Data on S2b tunnel.

handoverstat-ltetos2bgtpsucc-uplnkdata

SAEGW SchemaThe following bulk statistics are added for SAEGW in the SAEGW schema in support of the LTE to Wi-FiSeamless Handover feature.


P-GW Handover Statistics - Number of LTE to GTPS2b successful handover on Timer Expiry.

pgw-handoverstat-ltetos2bgtpsucc-timerexpiry


LTE to Wi-Fi (S2bGTP) Seamless HandoverBulk Statistics


P-GW Handover Statistics - Number of LTE to GTPS2b successful handover on Uplink Data on S2btunnel.

pgw-handoverstat-ltetos2bgtpsucc-uplnkdata


LTE to Wi-Fi (S2bGTP) Seamless HandoverSAEGW Schema

C H A P T E R 31Maximum Segment Size for Outgoing TCPPackets



All products using LI.Applicable Product(s) or FunctionalArea

• ASR 5500

• VPC - DI

• VPC - SI




Lawful Intercept Configuration GuideRelated Documentation

Revision History


21.9.1In 21.9.1 and later releases, the Maximum Segment Size (MSS) value foroutgoing TCP packets is configurable.

This change in behavior is also integrated with release 21.8.5.



Feature ChangesIn 21.8.5 and later releases, a new CLI keyword is added to configure the MSS value at Lawful Interceptwhich determines the packet size on a TCP connection.

For additional information, contact your Cisco Account representative.Important


Maximum Segment Size for Outgoing TCP PacketsFeature Changes

C H A P T E R 32Monitor VPC-DI Network

• Feature Summary and Revision History, on page 203• Feature Description, on page 203• How It Works, on page 204• Configuring the Monitor VPC-DI Network Feature, on page 205









Revision History



Feature DescriptionIn a DI-network, packet loss occurs when the DI-network ports are saturated or the underlying networkinfrastructure is unreliable. TheMonitor VPC-DI network feature enables the identification and quantificationof Control Plane and Data Plane packet loss on the VPC-DI system.


VPC-DI collects and aggregates the Control Plane and Data Plane monitor data for use in CLI reports andthreshold alarms.

The feature also provides the ability to set the criteria for the VPC-DI to declare a card fault. Currently, a cardfault is raised when a fixed number of High Availability Task (HAT) Control Plane heartbeats between theActive CF and an SF cards are consecutively bounced. The number of consecutive misses can be configuredusing this feature. This feature adds a secondary Data Plane configuration parameter that can be used toeffectively discriminate between the DI-network packet loss and packet processing failure scenarios.

How It WorksThe Control Plane and Data Plane monitors generate two fundamental DI-network traffic types on a fixed orrecurring basis and tracks losses. The tracking data is meant to provide a view into DI-network communicationloss or disruption.

Control Plane packets are typically unicast bi-directional UDP/TCP streams between cards; essentially requestand response pairs between StarOS proclets.

Data Plane traffic consists of unicast IP protocol 254 packets transferred between cards. This traffic is serviceport ingress or egress that the StarOs internally transfers to the appropriate application instance (ingress) orservice port interface (egress) and is not acknowledged (that is, there are no response packets). For example,an ingress packet arriving on an SF3 port that the Session Manager instance services on SF5, traverses theDI-network from SF3 to SF5.

All operational cards (that is, CFs and SFs with an Active or Standby operational state) transmit and receivemonitor packets. The monitor traffic is fully meshed wherein all cards transmit monitor packets to all othercards and receive monitor packets from all other cards.

Data Plane packets are generated at a rate of 10 per second. Control Plane monitor packets are generated ata rate of 5 per second. The packet headers for both are marked with default priority.

StarOS collects and aggregates the monitor transmit, receive, and drop data for all card connections. The showcloud monitor controlplane and show cloud monitor dataplane CLI commands display current 15 second,5 minute, and 60 minute data. The 5 minute and 60 minute loss percentages are available as variables in thebulkstats mon-di-net schema. The 5 minute and 60 minute loss percentages are also accessible as thresholdalarms/traps.

Note that low or non-zero drop percentages are normal. Because measurements involve correlation acrosscard pairs that are not perfectly synchronized, a response can arrive in the interval adjacent to the one in whichthe request was generated. This is reflected as a drop in the request interval.

When seen on a sustained basis, higher drop or loss percentages may indicate DI-network configuration oroperational issues, traffic overload, or VM or Host issues. The cloud monitor provides the ability to see andcharacterize DI-network traffic loss; further investigation is typically required to identify the root cause.

LimitationsThe Monitor VPC-DI Network feature has the following limitations.

• Only supported on the VPC-DI platform.

• Not license-controlled.


Monitor VPC-DI NetworkHow It Works

Configuring the Monitor VPC-DI Network FeatureThe following section provides information about the CLI commands available to enable or disable the feature.

Configuring Card Fault DetectionUse the following commands to configure secondary card fault detection criteria. This command is configuredin the Global Configuration mode.

configurehigh-availability fault-detection card dp-outage seconds

end

NOTES:

• default: Restores the default dp-outage value. The default value is 2 seconds.

• Note that the dp-outage deferral is limited. If the consecutive heartbeat bounces are 5 greater than theconfigured hb-loss parameter, then card failure is declared regardless of the dp-outage configuration.

• The dp-outage parameter is restricted to Administrator access on the VPC-DI platform.

• If this CLI is not configured, then the default dp-outage value is 2 seconds.

Configuring Packet Loss Threshold on Control PlaneUse the following commands to measure percentage packet loss over the corresponding time interval on theControl plane. The threshold alarm and SNMP trap are raised for any card to card connection that exceedsthe configured loss percentage over the indicated time period. This command is configured in the GlobalConfiguration mode.

configure[ default ] threshold cp-monitor-5min-loss pct [ clear pct ]end

[ default ] threshold poll cp-monitor-5min-loss interval duration

configure[default] threshold cp-monitor-60min-loss pct [ clear pct ]end

[default] threshold poll cp-monitor-60min-loss interval duration

NOTES:

• default: Clears the configured thresholds for the Control Plane.

• clear pct : Clears the configured percentage of packet loss.

• interval duration: Specifies the amount of time (in seconds) that comprises the polling interval. durationmust be an integer from 60 through 60000. The default is 300 seconds.

• This command is disabled by default.


Monitor VPC-DI NetworkConfiguring the Monitor VPC-DI Network Feature

For supplemental information related to this feature, refer to the Global Configuration Mode Commandssection of the Command Line Reference.

Note

The following alarms/traps are generated when these thresholds are exceeded:

• ThreshControlPlaneMonitor5MinsLoss / ThreshClearControlPlaneMonitor5MinsLoss

• ThreshControlPlaneMonitor60MinsLoss / ThreshControlPlaneMonitor60MinsLoss

See the SNMP MIB Reference for more details about these alarms/traps.

Configuring Packet Loss Threshold on Data PlaneUse the following commands to measure percentage packet loss over the corresponding time interval on theData plane. The threshold alarm and SNMP trap are raised for any card to card connection that exceeds theconfigured loss percentage over the indicated time period. This command is configured in the GlobalConfiguration mode.

configure[ default ] threshold dp-monitor-5min-loss pct [ clear pct ]end

[ default ] threshold poll dp-monitor-5min-loss interval duration

configure[default] threshold dp-monitor-60min-loss pct [ clear pct ]end

[ default ] threshold poll dp-monitor-60min-loss interval duration

NOTES:

• default: Disables the configured thresholds for the Data Plane.

• clear pct : Clears the configured packet loss.

• interval duration: Specifies the amount of time (in seconds) that comprises the polling interval. durationmust be an integer from 60 through 60000. The default is 300 seconds.


For supplemental information related to this feature, refer to the Global Configuration Mode Commandssection of the Command Line Reference.

Note

The following alarms/traps are generated when these thresholds are exceeded:

• ThreshDataPlaneMonitor5MinsLoss / ThreshClearDataPlaneMonitor5MinsLoss

• ThreshDataPlaneMonitor60MinsLoss / ThreshDataPlaneMonitor60MinsLoss

See the SNMP MIB Reference for more details about these alarms/traps.


Monitor VPC-DI NetworkConfiguring Packet Loss Threshold on Data Plane



show cloud monitor controlplane

This new show command is introduced to display the following output for the most recent Control Planemonitor information.show cloud monitor controlplane

Cards 15 Second Interval 5 Minute Interval 60 Minute IntervalSrc Dst Xmit Recv Miss% Xmit Recv Miss% Xmit Recv Miss%--- --- ------ ------ ------ ------ ------ ------ ------ ------ ------01 02 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%01 03 75 75 0.0% 1500 1500 0.0% 18000 17996 0.0%01 04 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%01 05 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%01 06 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%

02 01 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%02 03 75 75 0.0% 1500 1500 0.0% 18000 17997 0.0%02 04 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%02 05 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%02 06 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%

03 01 75 75 0.0% 1500 1500 0.0% -incomplete-03 02 75 75 0.0% 1500 1500 0.0% -incomplete-03 04 75 75 0.0% 1500 1500 0.0% -incomplete-03 05 75 75 0.0% 1500 1500 0.0% -incomplete-03 06 75 75 0.0% 1500 1500 0.0% -incomplete-

04 01 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%04 02 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%04 03 75 75 0.0% 1500 1500 0.0% 18000 17996 0.0%04 05 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%04 06 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%

05 01 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%05 02 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%05 03 75 75 0.0% 1500 1500 0.0% 18000 17996 0.0%05 04 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%05 06 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%

06 01 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%06 02 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%06 03 75 75 0.0% 1500 1500 0.0% 18000 17997 0.0%06 04 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%06 05 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%

show cloud monitor dataplane

This new show command is introduced to display the following output for the most recent Data Plane monitorinformation.show cloud monitor dataplane


Monitor VPC-DI NetworkMonitoring and Troubleshooting

Cards 15 Second Interval 5 Minute Interval 60 Minute IntervalSrc Dst Miss Hit Pct Miss Hit Pct Miss Hit Pct--- --- ------ ------ ------ ------ ------ ------ ------ ------ ------02 01 0 150 0.0% 0 3000 0.0% 0 36000 0.0%03 01 0 150 0.0% 0 3000 0.0% -incomplete-04 01 0 151 0.0% 0 3000 0.0% 0 36000 0.0%05 01 0 151 0.0% 0 3000 0.0% 0 36001 0.0%06 01 0 150 0.0% 0 3000 0.0% 2 35998 0.0%

01 02 0 150 0.0% 0 3000 0.0% 0 36000 0.0%03 02 0 150 0.0% 0 3000 0.0% -incomplete-04 02 0 150 0.0% 0 3000 0.0% 0 36000 0.0%05 02 0 150 0.0% 0 3000 0.0% 0 36000 0.0%06 02 0 151 0.0% 0 3001 0.0% 1 35999 0.0%

01 03 0 151 0.0% 0 3000 0.0% -incomplete-02 03 0 151 0.0% 0 3000 0.0% -incomplete-04 03 0 150 0.0% 0 3000 0.0% -incomplete-05 03 0 150 0.0% 0 3000 0.0% -incomplete-06 03 0 151 0.0% 0 3000 0.0% -incomplete-

01 04 0 150 0.0% 0 3001 0.0% 0 36001 0.0%02 04 0 150 0.0% 0 3000 0.0% 0 36000 0.0%03 04 0 150 0.0% 0 3000 0.0% -incomplete-05 04 1 149 0.7% 1 2999 0.0% 0 36001 0.0%06 04 0 150 0.0% 0 3000 0.0% 2 35998 0.0%

01 05 1 149 0.7% 1 2999 0.0% 0 36000 0.0%02 05 0 150 0.0% 0 3000 0.0% 0 36000 0.0%03 05 0 150 0.0% 0 3000 0.0% -incomplete-04 05 0 150 0.0% 1 2999 0.0% 1 35999 0.0%06 05 0 150 0.0% 0 3000 0.0% 2 35998 0.0%

01 06 0 150 0.0% 0 3001 0.0% 0 36001 0.0%02 06 0 151 0.0% 0 3000 0.0% 1 35999 0.0%03 06 0 150 0.0% 0 3001 0.0% -incomplete-04 06 0 150 0.0% 0 3000 0.0% 0 36000 0.0%05 06 0 150 0.0% 0 3000 0.0% 0 36000 0.0%

Bulk StatisticsThe following statistics are included in support of this feature.

mon-di-net Schema

The following bulk statistics are added in the mon-di-net schema in support of the Monitor the VPC-DINetwork feature.


Indicates the average Control Plane loss in prior 5minutes.

cp-loss-5minave

Indicates the average Control Plane loss in prior 60minutes.

cp-loss-60minave

Indicates the average Data Plane loss in prior 5minutes.

dp-loss-5minave


Monitor VPC-DI NetworkBulk Statistics


Indicates the average Data Plane loss in prior 60minutes.

dp-loss-60minave


Monitor VPC-DI Networkmon-di-net Schema


Monitor VPC-DI Networkmon-di-net Schema

C H A P T E R 33Multiple IP Versions Support


• Feature Summary and Revision History, on page 211• Feature Description, on page 212• How it Works, on page 212• Configuring Multiple IP Version Support, on page 214• Monitoring and Troubleshooting, on page 215


• P-GW

• S-GW

• SAEGW


• ASR 5500

• VPC - DI

• VPC - SI






• S-GW Administration Guide




Revision History

Revision history details are not provided for features introduced before release 21.2 and N5.1.Important


21.8This feature enables P-GW, S-GW, and SAEGW nodes to support the controlmessages received on all the transport addresses exchanged during the session setup.


Feature DescriptionThis feature enables P-GW, S-GW, and SAEGW nodes to support the control messages received on all thetransport addresses exchanged during the session setup. Prior to this release P-GW, S-GW, and SAEGW didnot support BRCmd,MBCmd, and DBCmdmessages on transport other than the transport used for establishingsession.

A new CLI command has been introduced at the egtp-service level to control the behavior of the BRCmd,MBCmd, and DBCmd messages.

How it WorksThis section describes the working of this feature. Following is the sample call flow for MBCmd.

The following figure illustrates call flow when the feature is disabled:


Multiple IP Versions SupportFeature Description

The following figure illustrates the call flow when feature is enabled:

When a session is being established, P-GW, S-GW, and SAEGW node uses the IPv6 address as transport.This transport is used for establishing tunnel with peer node. If IPv4 and IPv6 addresses are exchanged incontrol FTEID then the node should handle MBCmd, BRCmd, and DBCmd messages on IPv4 transport bythe nodes.


Multiple IP Versions SupportHow it Works

When a session is being established, if IPv4 address is used as a transport and is being used for establishingtunnel with peer node, and if IPv4 and IPv6 addresses are exchanged in control FTEID, then the MBCmd,BRCmd, and DBCmd messages are also handled on the IPv6 transport by the nodes.

When a session is being established, if IPv4 and IPv6 addresses are exchanged in data F-TEID by both peers,then the GTP-U data packets get handled on both IPv6 and IPv4 transport.

When a session is being established, if IPv4 address is used as a transport, however, C-TEID does not containIPv4 address, then that message is rejected by the node. The nodes exhibit similar behavior for IPv6 addresses.

When a session is being established, if IPv4 and IPv6 addresses are exchanged in data F-TEID by both peers,then GTP-U data packets get handled on IPv6 and IPV4 transport both.

The following table displays the message handling behavior in different session establishment scenarios:

Table 2: Message Handling Behavior in Different Session Establishment Scenarios

Message Sent onTransport

C-FTEID Sent DuringSession Establishment

Transport Used forSession Establishment

Messages

IPv4IPv4/IPv6IPv6MBR/DSR

IPv4IPv4/IPv6IPv6MBC/DBC/BRC

IPv4IPv4/IPv6IPv6Change Notification

IPv4IPv4/IPv6IPv6Suspend/Resume

IPv6IPv4/IPv6IPv4MBR/DSR

IPv6IPv4/IPv6IPv4MBC/DBC/BRC

IPv6IPv4/IPv6IPv4Change Notification

IPv6IPv4/IPv6IPv4Suspend/Resume

IPv4IPv6IPv6MBR/DSR

IPv4IPv6IPv6MBC/DBC/BRC

IPv4IPv6IPv6Change Notification

IPv4IPv6IPv6Suspend/Resume

IPv6IPv4IPv4MBR/DSR

IPv6IPv4IPv4MBC/DBC/BRC

IPv6IPv4IPv4Change Notification

IPv6IPv4IPv4Suspend/Resume

Configuring Multiple IP Version SupportThis section provides information on CLI commands available in support of this feature.


Multiple IP Versions SupportConfiguring Multiple IP Version Support

By default, this feature is enabled.


egtp-service service_name

[no] gtpc command-messages dual-ip-stack-supportend

NOTES:

• no: Disables the feature.

• command-messages: Configures MBC or DBC or BRC messages on S-GW and P-GW.

• dual-ip-stack-support: Enables P-GW, S-GW, SAEGW nodes to handle command messages on bothIPv4/IPv6 transport, if supported.

Monitoring and TroubleshootingThis section provides information on how to monitor and troubleshoot the Override Control Enhancementfeature.

Show Commands and OutputsThis section provides information on show commands and their corresponding outputs for the Override ControlEnhancement feature.

show configurationThe following new fields are added to the output of this command:

• gtpc command-messages dual-ip-stack-support - Specifies the command messages on both IPv4/IPv6transport if supported.

show egtp-service allThe following new fields are added to the output of this command:

• GTPC Command Messages Dual IP Support - Specifies the command messages on both IPv4/IPv6transport if supported.


Multiple IP Versions SupportMonitoring and Troubleshooting


Multiple IP Versions Supportshow egtp-service all

C H A P T E R 34NAT64 Support

• Feature Summary and Revision History, on page 217• Feature Description, on page 217• Configuring NAT64 Support, on page 218


P-GWApplicable Product(s) or FunctionalArea

• ASR 5500

• VPC - DI

• VPC - SI







Revision History


21.8.3First introduced.

Feature DescriptionNAT64 is implemented to reuse an existing IPv4 configuration to process DPI for IPv6 addresses.


All IPv4 based IP addresses are converted to IPv6 by appending a predetermined 96 bit prefix to an existingIPv4 address.

The P-GW allows the operator to configure a limited set of prefixes. The configured prefix is used to parsean IPv6 address and to extract the IPv4 address. The extracted IPv4 address is then used in DPI rule matchingat the gateway for NAT-based subscribers, while the IPv6 addresses performs charging-based actions.

This feature is currently applicable to Server-IP only.Note

Configuring NAT64 SupportThe following configurations are required to implement NAT64:

• Configuring the Prefix Set

• Configuring Rulebase for a Prefix Set

Once the NAT64 support is configured, rule-matching is applicable only to the newly connected flows. Theexisting flows use the previous rule-matching configuration.

Note

Configuring the Prefix SetThe prefix-set command is configured in the Active Charging Configuration mode. The configured prefixset is then associated to the Rulebase.

Use the following configuration to configure a prefix set:


prefix-set prefix_set_nameipv6_prefix_address/mask_bitsend

NOTES:

• prefix-set: Configures a list of prefixes that is used for DPI rule matching.

• ipv6_prefix_address/mask_bits: Specifies the IPv6 address along with the masked bits (96 bits).

Configuring Rulebase for a Prefix SetThe configured prefix-set is applied in the Rulebase using the following configuration. If the IPv6 addressfirst 96 bits matches with one of the configured prefix in the prefix set then the remaining 32 bits will beconverted to IPv4 address and used in rule matching.


NAT64 SupportConfiguring NAT64 Support


rulebase rulebase_name

strip server-ipv6 prefix-len prefix_length prefix-set prefix_set_name

end

NOTES:

• strip: Extracts the IPv4 address from the IPv6 address.

• server-ipv6: Specifies the IPv6 address of the server.

• prefix-len: Specifies the length of the IPv6 prefix.

• prefix-set: Specifies the name of the prefix set to be used for rule match.


NAT64 SupportConfiguring Rulebase for a Prefix Set


NAT64 SupportConfiguring Rulebase for a Prefix Set

C H A P T E R 35Non-MCDMA Cores for Crypto Processing




• ePDG

• IPSec

Applicable Product(s) or FunctionalArea

• VPC-DI

• VPC-SI




• ePDG Administration GuideRelated Documentation

Revision History



21.8All non-MCDMA IFTASK cores present in the system are used for crypto processing.



Feature ChangesThe cores in the VPC-DI/VPC-SI platforms are used for crypto processing to limit the throughput while usingsoftware path for encryption/decryption. In this release, all non-MCDMA IFTASK cores present in the systemare used instead of using the four cores for crypto processing.

Previous Behavior: The core allocation for a particular SA was done based on its IPSec policy number anddistributed among four or lesser number of cores for crypto processing.

New Behavior: In this release, the SA index will be used to distribute the sessions across all non-MCDMAcores present in the system for crypto processing.

The following configuration is added to limit the number of cores to be used for crypto.

IFTASK_MAX_CRYPTO_CORES=<percentage>

By default, all non-MCDMA cores will be used. The value is configured in percentage of the maximumnumber of IFTASK cores present in the system. This configuration is added in the /boot1/param.cfg file underthe debug shell of each SF before reload.

Customer Impact: The performance will be proportionally improved with the number of non-MCDMAIFTASK cores present in the system.


Non-MCDMA Cores for Crypto ProcessingFeature Changes

C H A P T E R 36Override Control Enhancement


• Feature Summary and Revision History, on page 223• Feature Changes, on page 224• Monitoring and Troubleshooting, on page 224


• P-GW

• S-GW

• SAEGW


• ASR 5500

• VPC - DI

• VPC - SI




• ECS Administration Guide

• Stats and Counters Reference Guide


Revision History




21.8The Override Control (OC) feature, introducedin an earlier release, allowed you to dynamicallymodify the parameters of static or predefined ruleswith parameters sent by the PCRF over the Gxinterface. This feature allows you to merge rulelevel or charging action level override controlwith Wildcard OC.


Feature ChangesThe Override Control (OC) feature, introduced in an earlier release, allowed you to dynamically modify theparameters of static or predefined rules with parameters sent by the PCRF over the Gx interface. OC allowsyou to specify the overridden parameters with the ability to exclude certain rules.

The PCRF sends these overrides as Override-Control grouped AVP in a CCA or RAR message.

Currently, if a rule or charging-action level andWildcard level OC parameters are received in a single message,then the rule level or charging-action level OC parameters are applied without merging any of the parameterswith the Wildcard OC parameters.

A new Diameter AVP "Override-Control-Merge-Wildcard" is added to the grouped AVP"Override-Charging-Action-Parameters" and included in the 'dpca-custom8' dictionary. This AVP is requiredto indicate that an OC needs to be merged with a Wildcard OC.

On receiving this new AVP, the gateway merges the parameters of received OC with the Wildcard OC. Themerged OC is applied to the rules matching rule-name/ca-name criteria of the received OC. If the WildcardOC is not present, then the received OC is applied as it is.

While applying OC on the rules of a rulebase, if the rule is present in the Exclude-Rule list of Wildcard OCthen for such rule, unmerged or original rule level or charging-action level OC is applied.

Important

Monitoring and TroubleshootingThis section provides information on how to monitor and troubleshoot the Override Control Enhancementfeature.

Show Commands and OutputsThis section provides information on show commands and their corresponding outputs for the Override ControlEnhancement feature.


Override Control EnhancementFeature Changes

show active charging sessions full allThe following new fields are added to the output of this command:

• Merge with Wildcard

• Received

• Succeeded

• Failed

show active-charging subscribers callid callid_name override-controlThe following new fields are added to the output of this command:

Merge with Wildcard: TRUE/FALSE

show active-charging rulebase statistics name statistics_nameThe following new fields are added to the output of this command:

• Merge with Wildcard

• Received

• Succeeded

• Failed


Override Control Enhancementshow active charging sessions full all


Override Control Enhancementshow active-charging rulebase statistics name statistics_name

C H A P T E R 37Packet Count in G-CDR


• Feature Summary and Revision History, on page 227• Feature Description, on page 228• How It Works, on page 228• Configuring Packet Count in G-CDR, on page 228• Monitoring and Troubleshooting, on page 229




• VPC - DI

• VPC - SI



P-GW Administration GuideRelated Documentation

Revision History



21.14With this release, the P-GW accepts the ModifyBearer Request message that is without BearerContext, and with old F-TEID.




Feature DescriptionWhen an IoT UE is attached, they send a message, as needed, and go into Power Saving Mode (PSM) untilthe time they have to transmit the next message. The IoT UE does not detach (that is, session termination)after every message. By assessing the number of such messages through CDRs generated for the IoT UEsession, the Operator can implement billing for IoT devices by including the packet counts in offline billingrecords.

This feature is applicable to custom24 GTPP dictionary.Important

How It WorksAs part of this feature, two new attributes are introduced for the packet count: datapacketsFBCDownlink anddatapacketsFBCUplink. These two attributes are CLI-controlled and visible only when the CLI is enabled.The existing attributes are not modified or removed.

Configuring Packet Count in G-CDRThis section provides information about the CLI commands available in support of the feature.

Enabling Packet Count in G-CDRUse the following commands to enable or disable sending of packet counts in G-CDR under the GTPP ServerGroup Configuration mode.


gtpp group group_name

[ no ] gtpp attribute packet-countend

NOTES:

• no: Disables sending of uplink and downlink packet count in G-CDR.

• packet-count: Specifying this option includes the optional field of "datapacketFBCUplink" and"datapacketFBCDownlink" in the CDR.

• By default, the gtpp attribute packet-count CLI command is disabled.


Packet Count in G-CDRFeature Description

Monitoring and TroubleshootingThis section provides information regarding CLI commands available for monitoring and troubleshooting thefeature.


show configurationThe output of this CLI command has been enhanced to display the following new field when the feature isenabled: gtpp attribute packet-count

show gtpp group name <name>The output of this CLI command has been enhanced to display the following new field when the feature isenabled: Packet count present


Packet Count in G-CDRMonitoring and Troubleshooting


Packet Count in G-CDRshow gtpp group name <name>

C H A P T E R 38S6B-bypass Support for eMPS Session




• P-GW

• SAE-GW

Applicable Product(s) or FunctionalArea

• ASR 5500

• VPC - DI

• VPC - SI






• SAE-GW Administration Guide


Revision History


21.8S6B bypass is implemented during S6B authorization/re-authorization failuresfor eMPS Sessions




Feature ChangesEnhanced Multimedia Priority Services (eMPS) sessions can be created successfully in case of S6Bauthorization/re-authorization failures by using locally configured S6B values. To ensure continuous eMPSsessions, S6B bypass is implemented during S6B authorization/re-authorization failures. The S6B bypass isimplemented in the following scenarios:

• For advance priority users when processing the Create Session Request (WPS ARP).

• When P-GW performs authorization and re-authorization for existing eMPS sessions.

A new keyword emps is added as part of the failure-handling-template configuration in the AAA ServerGroup Configurationmode to provide S6B bypass only for eMPS subscribers during S6B failures. The operatorshould configure the emps keyword with the failure-handling-template to provide failure handling for eMPSsubscribers. If failure-handling-template is configured without emps keyword, failure handling is applied toall subscribers.

Failure handling for eMPS subscribers in AAAGroup is implemented only with the failure-handling templatemechanism.

Note

The S6B-bypass for an eMPS session functionality includes the following:

• Once P-GW assumes bypass for an eMPS session, it doesn’t not perform authorization/re-authorizationfor subsequent scenarios.

• In a new call establishment or in aWIFI to LTE hand-off scenario, the S6B authorization/re authorizationAAR messages for eMPS is sent on the basis of default bearer ARP only because the type of dedicatedbearer; whether eMPS or not, is unknown. S6B authorized/reauthorized request initiation will occurbefore the PCRF communication for creating a dedicated bearer.

• Changes to the configuration during run-time is applied to all S6B transactions initiated after theconfiguration change

The S6B-bypass Support for eMPS Sessions is license controlled. Contact your Cisco account representativefor detailed information on specific licensing requirements. For information on installing and verifying licenses,refer to the Managing License Keys section of the Software Management Operations chapter in the SystemAdministration Guide

Command ChangesThis section describes the CLI configuration required to enable S6B-bypass Support for eMPS Sessions


S6B-bypass Support for eMPS SessionFeature Changes

empsThe emps keyword implements the failure-handling template for eMPS subscribers during S6Bauthorization/re-authorization failures.

Use the following configuration to enable failure-handling for eMPS subscribers:


aaa groupgroup_namediameter authentication failure-handling-template template_name emps

[ no ] diameter authentication failure-handling-template empsend

NOTES:

• failure-handling template: Associates a previously created failure handling template with theauthentication application in the AAA group. The template_name specifies the name for a pre-configuredfailure handling template. The template_namemust be an alphanumeric string of 1 through 63 characters.By default, the template is not associated in the AAA group.

• emps: This keyword specifies the failure-handling behavior for eMPS Sessions applicable during S6Bauthorization and re-authorization.

• no: Disassociates the failure-handling template with the AAA group authentication.

Performance Indicator ChangesThis section provides information regarding show commands and/or their outputs in support of this feature.

show diameter aaa-statistics allOn executing the above command the following new field is displayed for this feature:

• FH Behavior (eMPS)

• Continue

• With Retry

• Without Retry

• Retry and Terminate

• Retry and Terminate

• Retry Term without STR

• Termination

• Terminate

• Terminate without STR


S6B-bypass Support for eMPS Sessionemps

Bulk StatisticsThe following bulk statistics are added in the Diameter-Auth Schema for the S6B Bypass Support for eMPSSessions feature

• fh-continue-retry-emp: Indicates the number of times failure handling action “continue” is taken usingthe eMPS template..

• fh-continue-wo-retry-emps: Indicates the number of times the failure handling action “continue withoutretry” is taken using eMPS template.

• fh-retry-and-term-emps: Indicates the number of times failure handling “retry and terminate” is takenusing eMPS template.

• fh-retry-and-term-wo-str-emps: Indicates the number of times failure handling “retry and terminatewithout STR” is taken using eMPS template.

• fh-terminate-emps: Indicates the number of times failure handling “terminate” is taken using eMPStemplate.

• fh-terminate-wo-str-emps: Indicates the number of times failure handling “terminate without STR” istaken using eMPS template.


S6B-bypass Support for eMPS SessionBulk Statistics

C H A P T E R 39Short Message Service

• Feature Summary and Revision History, on page 235• Feature Description, on page 236• How It Works, on page 236• Configuring SMS Support, on page 245• Monitoring and Troubleshooting, on page 251



• ASR 5500

• UGP

• VPC-DI

• VPC-SI









Revision History


21.8.9"New sub traffic type SMS added under traffic PS to configure Heuristic paging"was introduced in release 21.11. With this release, this feature is also applicable torelease 21.8.9.

21.11New sub traffic type SMS added under traffic PS to configure Heuristic paging.


Feature DescriptionThe ShortMessage Service (SMS) is ameans of sendingmessages of limited size to and fromGSM/UMTS/EPSdevices. SMS is a Store and Forward service, where messages are first sent to an entity called the ShortMessage Service Center (SMSC) and then forwarded to the recipient instead of transmitting directly to thedestination.

If the recipient is not connected, the message is saved in the SMSC and when the receiver becomes available,the network will contact the SMSC and forward the SMS. Thus, a GSM/UMTS/EPS PLMN supports thetransfer of short messages between service centers and UEs.

SMS is delivered over LTE through the following methods:

• SMS over SGs: The LTE UE device sends and retrieves circuit switched (CS) based SMS messagesthrough the SGs interface. This method is already supported by the MME.

• SMS over IP: SIP based SMS messages are carried through IMS. The SMS to be transmitted isencapsulated in the SIP message. This method is not supported in this release.

• SMS in MME: SMS in MME delivers SMS services over the SGd interface to the SMSC. This methodis intended for networks that do not deploy GERAN or UTRAN. This method is supported in this release.

How It WorksThe SGd interface enables the transfer of short messages between the MME and the SMSC using Diameterprotocol. SCTP is used as the transport protocol.

The Short Message Control Protocol (SM-CP) and Short Message Relay Protocol (SM-RP) are traditionalSMS protocols between MSC/VLR and UE. The SMS will be sent by the MME bypassing the MSC/VLR.

SM-CP transmits the SMS and protects against loss caused by changing the dedicated channel. SM-RPmanagesthe addressing and references.

With the new interface configuration towards SMSC, MME will setup an SCTP association with the peerSMSC and the Diameter capability exchange will be performed.

LimitationsThis section lists the known limitations for the SMS feature:


Short Message ServiceFeature Description

• MME will attempt to fallback to the SGs mode if SGd and SGs are enabled and if HSS rejects SMS inMME. This functionality is not supported in this release.

• Multiple SMSC service association is not supported. Only one endpoint will be associated with anMMEservice. If multiple SMSC services are required, then the SMS router must be used.

• The Serving Node Identity AVP is not supported in the Alert-Service-Centre-Request command. HenceSMSC needs to perform the "Send Routing Info for SM" procedure to retrieve the address of the newserving node from the HSS.

• Sending or processing of the "Pending MT Short Message Indication" flag under Forward RelocationRequest will not be supported.

• Sending and processing of "MME number for MT SMS" and "MME Identifier for MT SMS" underForward Relocation Request/Response are not supported.

• SMS will not be processed when the MME common procedure is ongoing.

• Notify Request to HSS for each UE due to removal of SMSC service is not supported.

• Notify Request to HSS is not supported if UE does an IMSI Detach.

• Delete Subscription Data Request from HSS is not supported for MO/MT SMS.

• CDR generation is not supported.

FlowsThis section describes the call flows related to the SMS feature.

Obtaining UE capability for SMSIf the UE requests "SMS-only" in the Additional Update Type IE of combined attach and the network acceptsthe Attach Request for EPS services and "SMS-only", the network will indicate "SMS-only" in the AdditionalUpdate Result IE. If the SMS services are provided by SGd in the MME, the network will provide a TMSIand non-broadcast LAI in the Attach Accept message.

SMS Capability with HSSA UE supporting SMS in MME needs to perform a registration with the HSS.

The following call flow illustrates the request for registration with the HSS.


Short Message ServiceFlows

Figure 9: SMS Capability with HSS

DescriptionStep

The UE initiates combined Attach Update or combined TAU/LAU to an MME.1

The MME sends an Update Location Request message to the HSS with thefollowing data:

• SMS bit set in Feature-List in Supported-Features AVP. The Feature-List IDwill be set to 2.

• "SMS-only" indication bit set in ULR-Flags AVP.

• MME address for MT-SMS routing in MME-Number-for-MT-SMS AVP.

• "SMS-only" indication set in SMS-Register-Request AVP.

2

HSS registers the UE for SMS support in MME.3

If the HSS accepts to register theMME identity as anMSC identity for terminatingSMS services, then the HSS cancels the MSC/VLR registration from the HSS.

4

For successful registrations, HSS sends a Location Update Answer (indicationthat the MME has registered for SMS) message to the MME. HSS sets the "MMERegistered for SMS" bit in ULA-Flags AVP.

5

HSS-initiated Removal of Registration for SMSThe following procedure is applied when the HSS needs to indicate to the MME that it is no longer registeredfor SMS.


Short Message ServiceHSS-initiated Removal of Registration for SMS

Figure 10: Removal of Registration for SMS

DescriptionStep

An event will trigger the cancellation of the MME being registered for SMS. Forexample, removal of the SMS subscription for the UE, CS location update, andso on.

1

The HSS sends an Insert Subscriber Data Request (Remove SMS registration)message to the MME to inform that it is no more registered for SMS in MME.

2

The MME sets the "MME Registered for SMS" parameter as not registered forSMS and the "SMS Subscription Data" is considered by the MME as invalid. Itacknowledges with an Insert Subscriber Data Answer message to the HSS.

3

MO Forward Short Message ProcedureThe MO Forward Short Message procedure is used between the serving MME and the SMSC to forwardmobile originated short messages from a mobile user to a service center. MME checks the SMS relatedsubscription data and forwards the short message.


Short Message ServiceMO Forward Short Message Procedure

Figure 11: MO Forward Short Message Procedure

DescriptionStep

The UE sends mobile originated SMS to MME in the Uplink NAS Transportmessage.

1

MME will encapsulate the SMS in CP-DATA+RP-DATA.2

The message will be encoded into MO-Forward-Short-Message-Request (OFR)message and sent to SMSC.

3

MME acknowledges the received SMS by sending CP-ACK toUE in the DownlinkNAS Transport message.

4

SMSC processes the received OFR message and responds backs withMO-Forward-Short-Message-Answer (OFA) message to MME.

5

MME forwards the acknowledgement from SMSC in CP-DATA+RP-ACK to UE.6

UE acknowledges the SMS delivery by sending CP-ACK to MME in the UplinkNAS Transport message.

7


Short Message ServiceMO Forward Short Message Procedure

MT Forward Short Message ProcedureThe MT Forward Short Message procedure is used between the SMSC and the serving MME to forwardmobile terminated short messages.

• When receiving the MT Forward Short Message Request, the MME checks if the user is known.

If it is an unknown user, an Experimental-Result-Code set to DIAMETER_ERROR_USER_UNKNOWNis returned.

• The MME attempts to deliver the short message to the UE.

If the delivery of the short message to the UE is successful, the MME returns a Result-Code set toDIAMETER_SUCCESS.

• If the UE is not reachable via the MME, the MME sets the MNRF flag and returns anExperimental-Result-Code set to DIAMETER_ERROR_ABSENT_USER.

• If the delivery of the mobile terminated short message failed because the memory capacity exceeded,UE error, or UE not SM equipped, the MME returns an Experimental-Result-Code set toDIAMETER_ERROR_SM_DELIVERY_FAILURE with a SM Delivery Failure Cause indication.

Figure 12: MT Forward Short Message


Short Message ServiceMT Forward Short Message Procedure

DescriptionStep

The SMSC sends mobile terminated SMS to MME in theMT-Forward-Short-Message-Request (TFR) message.

1

If the UE is in IDLE mode then MME initiates paging and establishes an S1APconnection provided UE replies with paging response.

2

Once the UE is in CONNECTED mode, MME forwards the SMS inCP-DATA+RP-DATA to UE using the Downlink NAS Transport message.

3

The UE acknowledges the received message by sending CP-ACK in the UplinkNAS Transport message.

4

The UE processes the received SMS and sends CP-DATA+RP-ACK to MME.5

The MME sends the MT-Forward-Short-Message-Answer (TFA) command toSMSC and forwards CP-ACK to the UE in the Downlink NAS Transport message.

6

MT Forward Short Message Procedure (UE Unreachable)The MT Forward Short Message procedure is used between the SMSC and the serving MME to forwardmobile terminated short messages for an UE that is unreachable.


Short Message ServiceMT Forward Short Message Procedure (UE Unreachable)

Figure 13: MT Forward Short Message Procedure (UE Unreachable)

DescriptionStep

The SMSC sends mobile terminated SMS to MME in theMT-Forward-Short-Message-Request (TFR) message.

1

If the UE is paged but is not reachable, MME sets the MNRF flag and sends theMT-Forward-Short-Message-Answer (TFA)messagewith Subscriber-absent causeto the SMSC.

2

When the UE becomes available and gets connected to the core network, MMEclears the MNRF flag.

MME sends the Alert-Service-Centre-Request (ALR)message to SMSC to informthat UE is reachable and that SMS delivery can be re-attempted. This is controlledby the mme sgd send message alr trigger mnrf CLI command and disabled bydefault.

3


Short Message ServiceMT Forward Short Message Procedure (UE Unreachable)

DescriptionStep

The SMSC responds with the Alert-Service-Centre-Answer (ALA) command tothe MME and then follows the route procedure of sending MT SMS to UE.

4

Also, the Notify Request to HSS will be sent with alert reason "user available".This is controlled by themme s6a send message nor trigger mnrfCLI commandand enabled by default.

5

MT Forward Short Message Procedure (UE Memory Unavailable)This procedure is used between the SMSC and the servingMME to forwardmobile terminated short messagesfor an UE that has unavailable memory.

DescriptionStep

The SMSC sends mobile terminated SMS to MME in theMT-Forward-Short-Message-Request (TFR) message, but UEmemory is full andreturns the RP Error with cause code "Memory capacity exceeded". MME setstheMNRF flag and sends theMT-Forward-Short-Message-Answer (TFA)messagewith cause code "SM Delivery Failure" and failure cause "Memory capacityexceeded" to SMSC.

1

Once the UE memory is available, it will send RP-SMMA message to MME.MME clears the MNRF flag and sends the Alert-Service-Centre-Request (ALR)message to SMSC to inform that UE memory is available and the SMS deliverycan be re-attempted. This is controlled by themme sgd send message alr triggermnrf CLI command and disabled by default.

2


3

The Notify Request to HSS will also be sent with alert reason "user memoryavailable". This is controlled by the mme s6a send message nor trigger mnrfCLI command and enabled by default.

4

MT Forward Short Message Procedure (UE Moves due to HO)This procedure is used between the SMSC and the servingMME to forwardmobile terminated short messagesfor an UE that moves due to handover.

DescriptionStep

While the MNRF flag is set due to UE unreachable or UE memory unavailable,UE may do a handover (HO) and move to another MME or SGSN.

1

Since the MNRF flag was set, MME will send the Alert-Service-Centre-Request(ALR)message to SMSC to inform that UE hasmoved to anotherMME or SGSN.This is controlled by themme sgd send message alr trigger mnrf CLI commandand disabled by default.

2


3


Short Message ServiceMT Forward Short Message Procedure (UE Memory Unavailable)

DescriptionStep

The Notify Request to HSS will also be sent with alert reason "user memoryavailable". This is controlled by the mme s6a send message nor trigger mnrfCLI command and enabled by default.

4

This procedure has the following limitations:

• New Serving Node Identity AVP is not supported and SMSC needs to perform the "Send Routing Infofor SM" procedure to retrieve the new serving node's address from the HSS.

• Sending or processing of the "Pending MT Short Message Indication" flag under Forward RelocationRequest will not be supported.

Important

Standards ComplianceThe SMS feature complies with the following standards:

• 3GPP TS 23.040 version 12.2.0: Digital cellular telecommunications system (Phase 2+); UniversalMobile Telecommunications System (UMTS); Technical realization of the Short Message Service (SMS)

• 3GPP TS 24.011 version 12.0.0: Digital cellular telecommunications system (Phase 2+); UniversalMobile Telecommunications System (UMTS); LTE; Point-to-Point (PP) Short Message Service (SMS)support on mobile radio interface

• 3GPP TS 24.301 version 13.12.0: Non-Access-Stratum (NAS) protocol for Evolved Packet System(EPS); Stage 3

• 3GPP TS 24.301 version 15.1.0: Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS);Stage 3

• 3GPP TS 29.272 version 12.11.0: Evolved Packet System (EPS); Mobility Management Entity (MME)and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol

• 3GPP TS 29.272 version 15.2.0: Evolved Packet System (EPS); Mobility Management Entity (MME)and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol

• 3GPP TS 29.338 version 13.4.0: Diameter based protocols to support Short Message Service (SMS)capable Mobile Management Entities (MMEs)

• 3GPP TS 29.338 version 14.3.0: Diameter based protocols to support Short Message Service (SMS)capable Mobile Management Entities (MMEs)

Configuring SMS SupportThis section provides information on the CLI commands to configure the SMSC service for SMS support inMME.


Short Message ServiceStandards Compliance

Creating and Configuring SMSC ServiceUse the following configuration to enable the SMSC service and configure the parameters in SMSC serviceto support MO/MT SMS delivery between SMSC, MME, and UE.


smsc-service smsc_svc_name

diameter { dictionary standard | endpoint endpoint_name }mme-address mme_address

tmsi tmsi_value non-broadcast mcc mcc_value mnc mnc_value lac lac_value

default diameter dictionaryno { diameter endpoint | mme-address | tmsi }end

NOTES:

• context context_name: Creates or specifies an existing context and enters the Context Configurationmode. context_name specifies the name of a context entered as an alphanumeric string of 1 to 79 characters.

• smsc-service smsc_svc_name: Creates and configures an SMSC Peer service to allow communicationwith SMSC peer. smsc_svc_name specifies the name of the SMSC service as an alphanumeric string of1 to 63 characters.

Entering this command in the Context mode results in the following prompt:

[context_name]host_name(config-smsc-service)#

• diameter { dictionary standard | endpoint endpoint_name }: Configures the Diameter interface to beassociated with the SMSC service.

• dictionary standard: Configures the standard SGd dictionary.

• endpoint endpoint_name: Enables Diameter to be used for accounting and specifies which Diameterendpoint to use. endpoint_name must be an alphanumeric string of 1 to 63 characters.

• mme-address mme_address: Configures the MME address to send SMS on the SGd interface.mme_address specifies the MME address (ISDN identity) as an integer from 1 to 15.

• tmsi tmsi_value non-broadcast mcc mcc_value mnc mnc_value lac lac_value: Configures the TMSIto be sent to UE. tmsi_value specifies the 4-byte M-TMSI as an integer from 1 to 4294967295.

• non-broadcast: Configures the non-broadcast Location Area Identifier (LAI).

• mcc mcc_value: Configures the mobile country code (MCC) portion of non-broadcast LAI for theSMSC service as an integer from 100 through 999.

• mnc mnc_value: Configures the mobile network code (MNC) portion of non-broadcast LAI for theSMSC service as a 2- or 3-digit integer from 00 through 999.

• lac lac_value: Configures the location area code (LAC) value as an integer from 1 to 65535.

• default: Configures the standard Diameter SGd dictionary by default.

• no: Disables the specified configuration.


Short Message ServiceCreating and Configuring SMSC Service

Verifying the Configuration

Use the following command to verify the configuration for all SMSC services or a specified SMSC service:

show smsc-service { all | name smsc_svc_name | statistics { all | namesmsc_svc_name | summary } }

Configuring MME Preference for SMSUse the following configuration to configure the MME preference for SMS and SMSC address.


sms-in-mme { preferred [ smsc-address smsc_address ] | smsc-addresssmsc_address | subscribe [ notify ue ] }

no sms-in-mme { preferred [ smsc-address ] | smsc-address | subscribe[ notify ue ] }

default sms-in-mme { subscribe [ notify ue ] }end

NOTES:


• sms-in-mme: Configures the SMS capability (SGd interface for SMS) in MME.

• preferred: Configures the SMS preference in MME.

• smsc-address smsc_address: Configures the SMSC address (ISDN identity) for the MME to send SMSon the SGd interface. smsc_address must be an integer from 1 to 15.

• subscribe [ notify ue ]: Enables the Subscription Request for SMS services (via SGd) to HSS for allusers.

• notify: Configures the notification to be sent to the users.

• ue: Sends SMS-Only indication to UE in Attach/TAU Accept message (only if HSS accepts SMSRegistration for SGd).

• default: Restores the default configuration, which is to enable the Subscription Request for SMS services(via SGd) to HSS for all users.

• no: Deletes the specified configuration.

Associating SMSC Service with MME ServiceUse the following configuration to associate an SMSC service with the MME service.



associate smsc-service smsc_svc_name [ context ctx_name ]end

NOTES:


Short Message ServiceConfiguring MME Preference for SMS


• mme-service service_name: Creates an MME service or configures an existing MME service in thecurrent context. service_name specifies the name of the MME service as an alphanumeric string of 1 to63 characters.

• associate smsc-service smsc_svc_name: Associates an SMSC service with the MME service.smsc_svc_name specifies the name for a pre-configured SMSC service to associate with theMME serviceas an alphanumeric string of 1 to 63 characters.

• context ctx_name: Identifies a specific context name where the named service is configured. If thiskeyword is omitted, the named service must exist in the same context as the MME service. ctx_namemust be an alphanumeric string of 1 to 63 characters.

Configuring Alert SC Request on SGd interfaceUse the following configuration to control sending the Alert SC Request (ALR) on SGd interface.

The user sends the Alert SC Request on SGd interface to SMSC in the event of user availability to receivedSMS (if user moved to active state from idle or user's memory is available). It is also sent if the user did ahandover to the new MME/SGSN and any MT SMS was pending for the user.


[ no ] mme sgd send message alr trigger mnrfend

NOTES:


• mme: Configures MME capability.

• sgd: Configures MME capability on SGd interface.

• send: Configures MME capability to send on SGd interface.

• message: Configures MME capability to send message on SGd interface.

• alr: Configures MME capability to send Alert SC Request (ALR) on SGd interface.

• trigger: Configures trigger to send the message.

• mnrf: Sends message to trigger MNRF flag on SGd interface (SMS in MME).

• no: Disables sending the ALR on SGd interface.



Use the following command to verify whether Alert SC Request (MME SGd Message Options) is enabled ordisabled:

show call-control-profile full all


Short Message ServiceConfiguring Alert SC Request on SGd interface

Configuring Notify Request on S6a InterfaceUse the following configuration to control sending the Notify Request (NOR) on S6a interface.

The user sends the Notify Request on S6a interface to HSS in the event of user availability to received SMS(user moved to active state from idle or user's memory is available).


[ no ] mme s6a send message nor trigger mnrfend

NOTES:


• mme: Configures MME capability.

• s6a: Configure MME capbility on S6a interface.

• send: Configures MME capability to send on S6a interface.

• message: Configures MME capability to send message on S6a interface.

• nor: Configures MME capability to send Notify Request (NOR) on S6a interface.

• trigger: Configures trigger to send the message.

• mnrf: Sends message to trigger MNRF flag on S6a interface (SMS in MME).

• no: Disables sending the NOR on S6a interface.

• This command is enabled by default.


Use the following command to verify whether Notify Request (MME S6a Message Options) is enabled ordisabled:

show call-control-profile full all

Configuring Queue TimersUse the following configuration to configure the MT Queue, TC1N, TR1N, and TR2N timers.


mme-service mme_svc_name

emm { mt-queue-timeout mtq_timer | tc1n-timeout tc1n_timer |tr1n-timeout tr1n_timer | tr2n-timeout tr2n_timer }

default emm { mt-queue-timeout | tc1n-timeout | tr1n-timeout |tr2n-timeout }

end

NOTES:


Short Message ServiceConfiguring Notify Request on S6a Interface



• mt-queue-timeout mtq_timer: Configures the timer to hold MT SMS in MT queue. MT SMS will bepresent in the queue while the previous SMS is being processed. The timer expiry will return error toSMSC for an absent subscriber. mtq_timer specifies the timeout in seconds, as an integer from 1 to 300.

Default: 30 seconds

• tc1n-timeout tc1n_timer: Configures the retransmission timer to send CP SMS data to UE for MO/MTscenario. tc1n_timer specifies the timeout in seconds, as an integer from 1 to 20.

Default: 5 seconds

• tr1n-timeout tr1n_timer: Configures the wait time to receive RP-Ack from UE for MT SMS, beforesending error to SMSC. tr1n_timer specifies the timeout in seconds, as an integer from 1 to 300.

Default: 30 seconds

• tr2n-timeout tr2n_timer: Configures the wait time to send RP-Ack to UE for MO SMS, before sendingprotocol error to UE. tr2n_timer specifies the timeout in seconds, as an integer from 1 to 300.

Default: 30 seconds

• default: Resets the specified timer timeout to the default value.


Use the following command to verify the configuration for TC1N, TR1N, TR2N, and MT Queue timeout:

show mme-service [ all | name service_name ]

Configuring CP Data RetransmissionsUse the following configuration to configure the maximum number of retransmissions of CP data for MO orMT SMS scenario in MME.



[ default ] cp-data-max-retransmissions num_retrans

end

NOTES:




Short Message ServiceConfiguring CP Data Retransmissions

• cp-data-max-retransmissions num_retrans: Configures the number of times CP Data for SMS isretransmitted. num_retrans must be an integer from 1 to 10.

• default: Sets the default value to 2.


Use the following command to verify the count for maximum retransmissions of CP Data:

show mme-service [ all | name service_name ]

Configuring Heuristic paging for PS-SMS traffic via MMEUse the following configuration to configure Heuristic paging for PS-SMS traffic via MME.


lte-policypaging-map LTE_paging_map_name

precedence map_precedence traffic-type ps sms paging-profileLTE_paging_profile_name

end

NOTES:

• sms: Configures paging profile for SMS via SGd.

For more information on Heuristic paging seeHeuristic and Intelligent Paging section ofMME AdministrationGuide.

Important

Monitoring and TroubleshootingThis section provides information on the show commands and bulk statistics available for the SMS Supportfeature.

Show Commands and/or OutputsThis section provides information regarding show commands and their outputs for the SMS Support feature.

show call-control-profile full allThe output of this command includes the following fields:

• SMS in MME— Displays the configured value (preferred / not-preferred) for SMS in MME.

• SMSC Address — Displays the configured SMSC address.

• Send SMS Subscription Request to HSS — Indicates whether the SMS Subscription Request to HSS isenabled or disabled.


Short Message ServiceConfiguring Heuristic paging for PS-SMS traffic via MME

• Send SMS Subscription Notification to UE — Indicates whether the SMS Subscription Notification toUE is enabled or disabled.

• MME S6a Message Options:

• Notify Req (Trigger : MNRF flag) — Indicates whether the MNRF flag trigger for Notify Requestis enabled or disabled.

• MME SGd Message Options:

• Alert SC Request (Trigger : MNRF flag) — Indicates whether the MNRF flag trigger for Alert SCRequest is enabled or disabled.

show mme-service allThe output of this command includes the following fields:

• SMSC Context — Displays the name of the context in which SMSC service is configured.

• SMSC Service — Displays the name of the SMSC service associated with the MME service.

• TC1N Timeout — Displays the timeout duration configured for the TC1N timer. This timer can beconfigured to any value between 1 and 20 seconds. By default, it is 5 seconds.

• TR1N Timeout — Displays the timeout duration configured for the TR1N timer. This timer can beconfigured to any value between 1 and 300 seconds. By default, it is 30 seconds.

• TR2N Timeout — Displays the timeout duration configured for the TR2N timer. This timer can beconfigured to any value between 1 and 300 seconds. By default, it is 30 seconds.

• MT Queue Timeout — Displays the timeout duration configured for the MT Queue timer. This timercan be configured to any value between 1 and 300 seconds. By default, it is 30 seconds.

• CP DataMax Retransmissions Count—Displays the number of times CPData for SMS is retransmitted.

show mme-service session full allThe output of this command includes the following fields:

• SMS Capability Information:

• SGd Enabled — Displays Yes or No to indicate whether SGd is enabled or not.

• MS Not Reachable — Displays Yes or No to indicate whether MS Not Reachable is enabled or not.

• MS Memory Capacity Exceeded — Displays Yes or No to indicate whether MS memory capacityhas exceeded.

show mme-service statisticsThe output of this command includes the following fields:

• Paging Initiation for PS SMS Events:

• Attempted—The total number of ECM statistics-related PS SMS Paging Initiation events that wereattempted.


Short Message Serviceshow mme-service all

• Success — The total number of ECM statistics-related PS SMS Paging Initiation events that weresuccessful.

• Failures — The total number of ECM statistics-related PS SMS Paging Initiation events that failed.

• Success at Last n eNB — The total number of ECM statistics-related PS SMS Paging Initiationevents that succeeded at the last known eNodeB.

• Success at Last TAI— The total number of ECM statistics-related PS SMS Paging Initiation eventsthat succeeded at an eNodeB in the TAI from which the UE was last heard.

• Success at TAI List — The total number of ECM statistics-related PS SMS Paging Initiation eventsthat succeeded at an eNodeB in all TAIs present in the TAI list assigned to the UE.

show smsc-service name <smsc_svc_name>The output of this command includes the following fields:

• Service name — Displays the name of the configured SMSC service.

• Context — Displays the name of the configured context.

• Status — Displays the status of the SMSC service.

• Diameter endpoint — Displays the configured Diameter endpoint name.

• Diameter dictionary — Displays the configured Diameter dictionary.

• Tmsi — Displays the configured TMSI value.

• Non-broadcast-Lai — Displays the configured non-broadcast MCC, MNC, and LAC values.

• MME-address — Displays the configured MME address.

show smsc-service statistics allThe output of this command includes the following fields:

• Session Stats:

• Total Current Sessions — Displays the total number of current SMSC sessions.

• Sessions Failovers — Displays the number of SMSC session failovers.

• Total Starts — Displays the total number of SMSC session starts.

• Total Session Updates — Displays the total number of SMSC session updates.

• Total Terminated — Displays the total number of terminated SMSC sessions.

• Message Stats:

• Total Messages Rcvd — Displays the total number of messages received.

• Total Messages Sent — Displays the total number of messages sent.

• OF Request — Displays the total number of OF requests.

• OF Answer — Displays the total number of OF answers.


Short Message Serviceshow smsc-service name <smsc_svc_name>

• OFR Retries — Displays the total number of OFR retries.

• OFR Timeouts — Displays the total number of OFR timeouts.

• OFA Dropped — Displays the total number of OFA dropped.

• TF Request — Displays the total number of TF requests.

• TF Answer — Displays the total number of TF answers.

• TFR Retries — Displays the total number of TFR retries.

• TFA Timeouts — Displays the total number of TFA timeouts.

• TFA Dropped — Displays the total number of TFA dropped requests.

• AL Request — Displays the total number of AL requests.

• AL Answer — Displays the total number of AL answers.

• ALR Retries — Displays the total number of ALR retries.

• ALR Timeouts — Displays the total number of ALR timeouts.

• ALA Dropped — Displays the total number of ALA dropped.

• Message Error Stats:

• Unable To Comply — Displays the total number of message errors containing the result code"Unable To Comply".

• User Unknown — Displays the total number of message errors containing the result code "UserUnknown".

• User Absent—Displays the total number of message errors containing the result code "User Absent".

• User Illegal—Displays the total number of message errors containing the result code "User Illegal".

• SMDelivery Failure—Displays the total number of message errors containing the result code "SMDelivery Failure".

• User Busy for MT SMS — Displays the total number of message errors containing the result code"User Busy for MT SMS".

• Other Errors — Displays the total number of message errors containing the result code "OtherErrors".

• Bad Answer Stats:

• Auth-Application-Id — Displays the absence or unexpected value in Auth-Application-Id AVP.

• Session-Id — Displays the absence or unexpected value in Session-Id AVP.

• Origin-Host — Displays the absence of Origin-Host AVP.

• Origin Realm — Displays the absence of Origin-Realm AVP.

• Parse-Message-Errors — Displays the total number of parse errors in the message.

• Parse-Mscc-Errors — Displays the total number of parse errors in MSCC AVP.


Short Message Serviceshow smsc-service statistics all

• Miscellaneous — Displays the total number of other miscellaneous errors.

show smsc-service statistics summaryThe output of this command includes the following fields:

• SMSC Session Stats:

• Total Current Sessions — Displays the total number of current SMSC sessions.

• Sessions Failovers — Displays the total number of SMSC session failovers.

• Total Starts — Displays the total number of SMSC session starts.

• Total Session Updates — Displays the total number of SMSC session updates.

• Total Terminated — Displays the total number of terminated SMSC sessions.

show sms statistics mme-only verboseThe output of this command includes the following fields:

SMS Statistics:

Session Statistics:

• MO SMS (In Progress) — The total number of mobile originated (MO) SMS messages that are waitingin the MME to be delivered.

• MT SMS (In Progress) — The total number of mobile terminated (MT) SMS messages that are waitingin the MME to be delivered.

• MT SMS (In Queue ) — The total number of mobile terminated SMS messages in the queue.

• SMMA (In Progress) — The total number of procedures for retrieval of available SMS memory inprogress.

• MO-SMS Attempted — The total number of mobile originated SMS messages that are attempted to bedelivered by the network.

• MO-SMS Successful — The total number of mobile originated SMS messages that are successfullydelivered by the network.

• MT-SMS Attempted — The total number of mobile terminated SMS messages that are attempted to bedelivered by the network.

• MT-SMS Successful — The total number of mobile terminated SMS messages that are successfullydelivered by the network.

• SMMAAttempted— The total number of procedures for retrieval of available SMSmemory attempted.

• SMMASuccessful—The total number of procedures for retrieval of available SMSmemory successful.

Message Statistics:

• CP Layer Messages:

• CP Data (Tx) — The total number of protocol data units sent during connection setup.


Short Message Serviceshow smsc-service statistics summary

• CP Data (Rx) — The total number of protocol data units received during connection setup.

• CP Ack (Tx) — The total number of Ack messages sent during connection setup.

• CP Ack (Rx) — The total number of Ack messages received during connection setup.

• CP Error (Tx) — The total number of protocol errors during connection setup in Tx message.

• CP Error (Rx) — The total number of protocol errors during connection setup in Rx message.

• CP Error Cause Stats:

• Network Failure (Tx)/(Rx) — The total number of protocol errors during connection setup due tonetwork failure in Tx/Rx message.

• Congestion (Tx)/(Rx) — The total number of protocol errors during connection setup due tocongestion in Tx/Rx message.

• Invalid TID (Tx)/(Rx)—The total number of protocol errors during connection setup due to invalidtransaction ID (TID) in Tx/Rx message.

• Invalid Semantic (Tx)/(Rx) — The total number of protocol errors during connection setup due toinvalid semantics in Tx/Rx message.

• Invalid Mand Info (Tx)/(Rx) — The total number of protocol errors during connection setup asmandatory information in Tx/Rx message is invalid.

• Invalid Msg Type (Tx)/(Rx) — The total number of protocol errors during connection setup due toinvalid Tx/Rx message type.

• Invalid Prot State (Tx)/(Rx) — The total number of protocol errors during connection setup asprotocol state in Tx/Rx message is invalid.

• Invalid IE (Tx)/(Rx) — The total number of protocol errors during connection setup as informationelement in Tx/Rx message is invalid.

• Protocol Error (Tx)/(Rx)—The total number of protocol errors during connection setup as protocolerror in Tx/Rx message.

• Undefined Cause (Tx)/(Rx) — The total number of protocol errors during connection setup due tounspecified error in Tx/Rx message.

• Message Drop Counters:

• CP Data — The total number of CP data packets dropped during connection setup.

• Retransmission Drops — The total number of data packets dropped during retransmission.

• Unknown TID Drops — The total number of data packets dropped during connection setupdue to unknown transaction ID (TID).

• Invalid TID Drops — The total number of data packets dropped during connection setup dueto invalid transaction ID (TID) received.

• CP Ack — The total number of CP acknowledgement messages dropped during connection setup.

• CP-ACKDrop for Invalid TID Rcvd—The total number of CP-Ackmessages dropped duringconnection setup due to invalid transaction ID (TID) received.


Short Message Serviceshow sms statistics mme-only verbose

• CP Error — The total number of CP data packets dropped during connection setup due to error inconnection.

• CP-ERRDrop for Invalid TIDRcvd—The total number of CP-ERRmessages dropped duringconnection setup due to invalid transaction ID (TID) received.

• RP Layer Messages:

• RP Data (Tx) — The total number of protocol data units sent during message relay.

• RP Data (Rx) — The total number of protocol data units received during message relay.

• RP Ack (Tx) — The total number of Ack messages sent during message relay.

• RP Ack (Rx) — The total number of Ack messages received during message relay.

• RP Error (Tx) — The total number of protocol errors during message relay in Tx message.

• RP Error (Rx) — The total number of protocol errors during message relay in Rx message.

• RP SMMA (Rx) — The total number RP SMMA messages received.

• RP Error Cause Stats:

• Unassigned Number (Tx) — The total number of protocol errors sent during message relay due tounassigned protocol number.

• Opr. Determined Barring (Tx) — The total number of protocol errors sent during message relaydue to operator determined barring.

• Call Barred (Tx)—The total number of protocol errors sent during message relay due to call barring.

• Reserved (Tx) — The total number of protocol errors sent during message relay due to reservedresources.

• SM Transfer Rejected (Tx) — The total number of protocol errors sent during message relay dueto session manager transfer rejection.

• Destination Out Of Order (Tx) — The total number of protocol errors sent during message relaydue to out of order on destination.

• Unidentified Subscriber (Tx) — The total number of protocol errors sent during message relay dueto unidentified subscriber.

• Facility Rejected (Tx) — The total number of protocol errors sent during message relay due tofacility rejection.

• Unknown Subscriber (Tx) — The total number of protocol errors sent during message relay due tounknown subscriber.

• Network Out Of Order (Tx) — The total number of protocol errors sent during message relay dueto out-of-order network.

• Temporary Failure (Tx) — The total number of protocol errors sent during message relay due totemporary failure in network.

• Congestion (Tx)—The total number of protocol errors sent during message relay due to congestionin network.



• Not Subscribed (Tx)—The total number of protocol errors sent duringmessage relay as this serviceis not subscribed by subscriber.

• Not Implemented (Tx) — The total number of protocol errors sent during message relay as thisservice is not yet implemented.

• Interworking Error (Tx) — The total number of protocol errors sent during message relay due tointerworking error between two networks or technology.

• Resource Un-available (Tx) — The total number of protocol errors sent during message relay asresources are not available.

• Memory Capacity Exceeded (Rx) — The total number of protocol errors received during messagerelay as capacity is exceeded.

• Invalid Reference Number (Tx)/(Rx) — The total number of protocol errors during message relayas invalid reference in Tx/Rx message.

• Invalid Semantic (Tx)/(Rx) — The total number of protocol errors during message relay due toinvalid semantics in Tx/Rx message.

• Invalid Mandatory Info (Tx)/(Rx) — The total number of protocol errors during message relay asmandatory information in Tx/Rx message is invalid.

• Invalid Message Type (Tx)/(Rx) — The total number of protocol errors during message relay dueto invalid Tx/Rx message type.

• Invalid Protocol State (Tx)/(Rx) — The total number of protocol errors during message relay asprotocol state in Tx/Rx message is invalid.

• Invalid IE (Tx)/(Rx) — The total number of protocol errors during message relay as informationelement in Tx/Rx message is invalid.

• Protocol Error (Tx)/(Rx)— The total number of RP ERRORmessages sent/received with the causeProtocol Error in the message header.

• Undefined Error (Tx)/(Rx) — The total number of protocol errors during message relay due tounspecified error in Tx/Rx message.

• Message Drop Counters:

• RP Data — The total number of RP data packets dropped during message relay.

• RP Ack — The total number of RP acknowledgement messages dropped during message relay.

• RP Error — The total number of RP data packets dropped during message relay due to error inconnection.

• RP Decode Failures — The total number of messages dropped during message relay due to invalidtransaction ID (TID) received.

General Statistics:

• Concatenated MO SMS — The total number of concatenated mobile originated SMS messages.

• CP Timer Expiry — The total number of events when timer expired during connection setup.



• TR1N Timer — The total number of events when TR1N timer expired during mobile terminated SMSis in wait state for RP-ACK.

• TR2N Timer — The total number of events when TR2N timer expired during mobile terminated SMSis in wait state to send RP-ACK.

• CP Data Retrans — The total number of protocol data units retransmitted during connection setup.

• RP Msg Encode Fail — The total number of message encoding failures during message relay.

• CP Data Tx Fail — The total number of protocol data units with Tx messages failed during connectionsetup.

• CP Data Inv TID — The total number of protocol data units with invalid transaction ID (TID) duringconnection setup.

• Max Retrans Reached — The total number of events when retransmission limit is exhausted duringconnection setup.

• SMSC Addr Restricted — The total number of SMSC addresses restricted.

• MO SMSC Addr Restricted — The total number of mobile originated SMSC addresses restricted.

• MT SMSC Addr Restricted — The total number of mobile terminated SMSC addresses restricted.

• CP-DATA No Cp Ack Rx — The total number of mobile terminated messages failed as noacknowledgement is received during connection setup.

• Release Indication Waiting MO CP-ACK Delivery — The total number of release indicationswaiting to be transferred between network and MS for mobile originated control protocolacknowledgement messages that are being delivered.

• Release Indication Waiting MO CP-DATA Delivery — The total number of release indicationswaiting to be transferred between network and MS for mobile originated control protocol datamessages that are being delivered.

• Release IndicationWaitingMOCP-ERRDelivery—The total number of release indications waitingto be transferred between network and MS for mobile originated control protocol error messagesthat are being delivered.

• Release Indication Waiting MT CP-DATA Delivery — The total number of release indicationswaiting to be transferred between network and MS for mobile terminated control protocol datamessages that are being delivered.

• Release IndicationWaitingMTCP-ACKDelivery—The total number of release indications waitingto be transferred between network andMS for mobile terminated control protocol acknowledgementmessages that are being delivered.

• Release IndicationWaitingMTCP-ERRDelivery—The total number of release indications waitingto be transferred between network and MS for mobile terminated control protocol error messagesthat are being delivered.

• MT-SMS Failures:

• IMSI Record Not Found — The total number of mobile terminated messages failed as IMSI recordis not available.

• Busy Subscriber — The total number of mobile terminated messages failed due to busy subscriber.



• Detached Subscriber — The total number of mobile terminated messages failed due to detachedsubscriber.

• MT Queue Full — The total number of mobile terminated messages failed as messaged queue wasfull.

Bulk StatisticsThis section provides information on the bulk statistics supported for the SMS feature.

MME SchemaThe following SMS feature related bulk statistics are available in the MME schema.


The total number of PS SMS Paging Initiation eventsthat were attempted.

ps-sms-paging-init-events-attempted

The total number of PS SMS Paging Initiation eventsthat were successful.

ps-sms-paging-init-events-success

The total number of PS SMS Paging Initiation eventsthat failed.

ps-sms-paging-init-events-failures

The total number of PS SMS Paging Initiation eventsthat succeeded at the last known eNodeB.

ps-sms-paging-last-enb-success

The total number of PS SMS Paging Initiation eventsthat succeeded at an eNodeB in the TAI from whichthe UE was last heard.

ps-sms-paging-last-tai-success

The total number of PS SMS Paging Initiation eventsthat succeeded at an eNodeB in all TAIs present inthe TAI list assigned to the UE.

ps-sms-paging-tai-list-success

MME-SMS SchemaThe following SMS feature related bulk statistics are available in the MME-SMS schema.


The total number of mobile originated (MO) SMSmessages that are waiting in theMME to be delivered.

mo-sms-in-progress

The total number of mobile terminated (MT) SMSmessages that are waiting in theMME to be delivered.

mt-sms-in-progress

The total number of mobile terminated SMSmessagesin the queue.

mt-sms-in-queue


Short Message ServiceBulk Statistics


The total number of procedures for retrieval ofavailable SMS memory in progress.

sms-memory-available-in-progress

The total number of mobile originated SMSmessagesthat are attempted to be delivered by the network.

mo-sms-attempted

The total number of mobile originated SMSmessagesthat are successfully delivered by the network.

mo-sms-successful

The total number of mobile terminated SMSmessagesthat are attempted to be delivered by the network.

mt-sms-attempted

The total number of mobile terminated SMSmessagesthat are successfully delivered by the network.

mt-sms-successful

The total number of procedures for retrieval ofavailable SMS memory attempted.

sms-memory-available-attempted

The total number of procedures for retrieval ofavailable SMS memory successful.

sms-memory-available-successful

The total number of protocol data units sent duringconnection setup.

conn-prot-data-tx

The total number of protocol data units receivedduring connection setup.

conn-prot-data-rx

The total number of Ack messages sent duringconnection setup.

conn-prot-ack-tx

The total number of Ack messages received duringconnection setup.

conn-prot-ack-rx

The total number of protocol errors during connectionsetup in Tx message.

conn-prot-error-tx

The total number of protocol errors during connectionsetup in Rx message.

conn-prot-error-rx

The total number of protocol errors during connectionsetup due to network failure in Tx message.

conn-prot-error-nwt-fail-tx

The total number of protocol errors during connectionsetup due to network failure in Rx message.

conn-prot-error-nwt-fail-rx

The total number of protocol errors during connectionsetup due to congestion in Tx message.

conn-prot-error-congestion-tx

The total number of protocol errors during connectionsetup due to congestion in Rx message.

conn-prot-error-congestion-rx


Short Message ServiceMME-SMS Schema


The total number of protocol errors during connectionsetup due to invalid transaction ID (TID) in Txmessage.

conn-prot-error-invalid-tid-tx

The total number of protocol errors during connectionsetup due to invalid transaction ID (TID) in Rxmessage.

conn-prot-error-invalid-tid-rx

The total number of protocol errors during connectionsetup due to invalid semantics in Tx message.

conn-prot-error-invalid-semantic-tx

The total number of protocol errors during connectionsetup due to invalid semantics in Rx message.

conn-prot-error-invalid-semantic-rx

The total number of protocol errors during connectionsetup as mandatory information in Tx message isinvalid.

conn-prot-error-invalid-mand-info-tx

The total number of protocol errors during connectionsetup as mandatory information in Rx message isinvalid.

conn-prot-error-invalid-mand-info-rx

The total number of protocol errors during connectionsetup due to invalid Tx message type.

conn-prot-error-invalid-msg-type-tx

The total number of protocol errors during connectionsetup due to invalid Rx message type.

conn-prot-error-invalid-msg-type-rx

The total number of protocol errors during connectionsetup as protocol state in Tx message is invalid.

conn-prot-error-invalid-prot-state-tx

The total number of protocol errors during connectionsetup as protocol state in Rx message is invalid.

conn-prot-error-invalid-prot-state-rx

The total number of protocol errors during connectionsetup as information element in Txmessage is invalid.

conn-prot-error-invalid-ie-tx

The total number of protocol errors during connectionsetup as information element in Rxmessage is invalid

conn-prot-error-invalid-ie-rx

The total number of protocol errors during connectionsetup as protocol error in Tx message.

conn-prot-error-protocol-error-tx

The total number of protocol errors during connectionsetup as protocol error in Rx message.

conn-prot-error-protocol-error-rx

The total number of protocol errors during connectionsetup due to unspecified error in Tx message.

conn-prot-error-undefined-cause-tx

The total number of protocol errors during connectionsetup due to unspecified error in Rx message.

conn-prot-error-undefined-cause-rx




The total number of data packets dropped duringconnection setup.

conn-prot-data-dropped

The total number of Ack messages dropped duringconnection setup.

conn-prot-ack-dropped

The total number of data packets dropped duringconnection setup due to error in connection.

conn-prot-error-dropped

The total number of messages dropped duringconnection setup due to invalid transaction ID (TID)received.

conn-prot-inval-tid-rcvd

The total number of protocol data units sent duringmessage relay.

relay-prot-data-tx

The total number of protocol data units receivedduring message relay.

relay-prot-data-rx

The total number of Ack messages sent duringmessage relay.

relay-prot-ack-tx

The total number of Ack messages received duringmessage relay.

relay-prot-ack-rx

The total number of protocol errors during messagerelay in Tx message.

relay-prot-err-tx

The total number of protocol errors during messagerelay in Rx message.

relay-prot-err-rx

The total number of protocol errors during messagerelay due to unassigned protocol number.

relay-prot-err-unassigned-num

The total number of protocol errors during messagerelay due to operator determined barring.

relay-prot-err-opr-determ-barring

The total number of protocol errors during messagerelay due to call barring.

relay-prot-err-call-barred

The total number of protocol errors during messagerelay due to reserved resources.

relay-prot-err-reserved

The total number of protocol errors during messagerelay due to session manager transfer rejection.

relay-prot-err-sm-transfer-rej

The total number of protocol errors during messagerelay due to out of order on destination.

relay-prot-err-dest-out-of-order

The total number of protocol errors during messagerelay due to unidentified subscriber.

relay-prot-err-unidentified-subs




The total number of protocol errors during messagerelay due to facility rejection.

relay-prot-err-facility-rej

The total number of protocol errors during messagerelay due to unknown subscriber.

relay-prot-err-unknown-subs

The total number of protocol errors during messagerelay due to out-of-order network.

relay-prot-err-netwk-out-of-order

The total number of protocol errors during messagerelay due to temporary failure in network.

relay-prot-err-temp-fail

The total number of protocol errors during messagerelay due to congestion in network.

relay-prot-err-congestion

The total number of protocol errors during messagerelay as this service is not subscribed by subscriber.

relay-prot-err-not-subscribed

The total number of protocol errors during messagerelay as this service is not yet implemented.

relay-prot-err-not-implemented

The total number of protocol errors during messagerelay due to interworking error between two networksor technology.

relay-prot-err-interworking-err

The total number of protocol errors during messagerelay as resources are not available.

relay-prot-err-res-unavail

The total number of protocol errors during messagerelay as capacity is exceeded.

relay-prot-err-mem-capacity-exceed

The total number of protocol errors during messagerelay as invalid reference in Tx message.

relay-prot-err-inval-ref-num-tx

The total number of protocol errors during messagerelay as invalid reference in Rx message.

relay-prot-err-inval-ref-num-rx

The total number of protocol errors during messagerelay due to invalid semantics in Tx message.

relay-prot-err-inval-semantic-tx

The total number of protocol errors during messagerelay due to invalid semantics in Rx message.

relay-prot-err-inval-semantic-rx

The total number of protocol errors during messagerelay as mandatory information in Tx message isinvalid.

relay-prot-err-inval-mand-info-tx

The total number of protocol errors during messagerelay as mandatory information in Rx message isinvalid.

relay-prot-err-inval-mand-info-rx

The total number of protocol errors during messagerelay due to invalid Tx message type.

relay-prot-err-inval-msg-type-tx




The total number of protocol errors during messagerelay due to invalid Rx message type.

relay-prot-err-inval-msg-type-rx

The total number of protocol errors during messagerelay as protocol state in Tx message is invalid.

relay-prot-err-inval-prot-state-tx

The total number of protocol errors during messagerelay as protocol state in Rx message is invalid.

relay-prot-err-inval-prot-state-rx

The total number of protocol errors during messagerelay as information element in Txmessage is invalid.

relay-prot-err-inval-ie-tx

The total number of protocol errors during messagerelay as the information element in Rx message isinvalid.

relay-prot-err-inval-ie-rx

The total number of RP ERROR messages sent withthe cause Protocol Error in the message header.

relay-prot-err-protocol-error-rx

The total number of protocol errors during messagerelay when there are protocol errors in the transmittedmessage.

relay-prot-err-protocol-error-tx

The total number of protocol errors during messagerelay due to unspecified error in Tx message.

relay-prot-err-unidentified-error-tx

The total number of protocol errors during messagerelay due to unspecified error in Rx message.

relay-prot-err-unidentified-error-rx

The total number RP SMMA messages received.relay-prot-smma-rx

The total number of data packets dropped duringmessage relay.

relay-prot-data-dropped

The total number of Ack messages dropped duringmessage relay.

relay-prot-ack-dropped

The total number of data packets dropped duringmessage relay due to error in connection.

relay-prot-error-dropped

The total number ofmessages dropped duringmessagerelay due to invalid transaction ID (TID) received.

relay-prot-decode-failure

The total number of concatenated mobile originatedSMS messages.

concat-mo-sms

The total number of events when timer expired duringconnection setup.

conn-prot-timer-expiry

The total number of events when TR1N timer expiredduring mobile terminated SMS is in wait state forRP-ACK.

tr1n-timer-expiry




The total number of events when TR2N timer expiredduring mobile terminated SMS is in wait state to sendRP-ACK.

tr2n-timer-expiry

The total number of protocol data units retransmittedduring connection setup.

conn-prot-data-retrans

The total number of message encoding failures duringmessage relay.

relay-prot-msg-encode-fail

The total number of protocol data units with Txmessages failed during connection setup.

conn-prot-data-tx-fail

The total number of protocol data units with invalidtransaction ID (ID) during connection setup.

conn-prot-data-inval-tid

The total number of events when retransmission limitis exhausted during connection setup.

conn-prot-max-retrans-reached

The total number of mobile terminated messagesfailed as database record is not available.

mt-fail-no-db-rec

The total number of mobile terminated messagesfailed as no acknowledgement is received duringconnection setup.

mt-fail-conn-prot-data-no-ack-rcvd

The total number of mobile terminated messagesfailed due to busy subscriber.

mt-fail-fwd-busy-subs

The total number of mobile terminated messagesfailed due to detached subscriber.

mt-fail-fwd-detached-subs

The total number of mobile terminated messagesfailed as messaged queue was full.

mt-fail-mt-queue-full



C H A P T E R 40SNMP IF-MIB and Entity-MIB Support forDI-Network Interface

• Feature Summary and Revision History, on page 267• Feature Changes, on page 268• Command Changes, on page 268• SNMP MIB Object Changes, on page 268






• SNMP MIB Reference Guide



Revision History



21.8From this release, the SNMP IF-MIB and Entity-MIB now include the DI-networkinterface statistics.




Feature ChangesQVPC-DI platform provides Service andManagement information statistics. It does not include anyDistributedInstance network (DI-network) interface statistics information.

Previous Behavior: Currently, IF-MIB and Entity-MIBs are not supported for the DI-network interface onthe QVPC-DI platform.

New Behavior: From Release 21.8, IF-MIB and Entity-MIBs are supported for the DI-network interface onthe QVPC-DI platform.

Customer Impact: These MIBs provide additional debug information about the DI-network interface.

Command Changes

show port dinetThis new show command is introduced with the following fields to display the DI-network port statistics.

• counters

• SLOT/CPU/NPU

• utilization

• SLOT/CPU/NPU

• bps

• pps

• verbose

SNMP MIB Object ChangesThis section displays a sample of the MIB information for the DI-network port details along with themanagement and service port details.

• DiNet Virtual Ethernet - 1/0

• Mgmt Virtual Ethernet - 1/1


• Mgmt Virtual Ethernet - 2/1


SNMP IF-MIB and Entity-MIB Support for DI-Network InterfaceFeature Changes


• Srvc Virtual Ethernet - 4/10

• Srvc Virtual Ethernet - 4/11

For information on SNMP MIBs changes for a specific release, refer to the SNMP MIB Changes in Releasexx chapter of the appropriate version of the Release Change Reference.

Note


SNMP IF-MIB and Entity-MIB Support for DI-Network InterfaceSNMP MIB Object Changes


SNMP IF-MIB and Entity-MIB Support for DI-Network InterfaceSNMP MIB Object Changes

C H A P T E R 41SNMP MIB Changes in StarOS 21.8 and USP 6.2

This chapter identifies SNMP MIB objects, alarms and conformance statements added to, modified for, ordeprecated from the StarOS 21.8 and Ultra Services Platform (USP) 6.2 software releases.

• SNMP MIB Object Changes for 21.8, on page 271• SNMP MIB Alarm Changes for 21.8, on page 272• SNMP MIB Conformance Changes for 21.8, on page 273• SNMP MIB Object Changes for 6.2, on page 273• SNMP MIB Alarm Changes for 6.2, on page 274• SNMP MIB Conformance Changes for 6.2, on page 275

SNMP MIB Object Changes for 21.8This section provides information on SNMP MIB alarm changes in release 21.8.

For more information regarding SNMP MIB alarms in this section, see the SNMP MIB Reference for thisrelease.

Important

New SNMP MIB Object

This section identifies new SNMP MIB alarms available in release 21.8.

The following alarms are new in this release:

• starSxInterfaceType

• starSxSelfAddr

• starSxPeerAddr

• starSxPeerNewRecTimeStamp

• starSxPeerOldRecTimeStamp

• starSxFailureCause

•


Modified SNMP MIB Object

This section identifies SNMP MIB alarms modified in release 21.8.

The following alarms have been modified in this release:

• None in this release.

Deprecated SNMP MIB Object

This section identifies SNMP MIB alarms that are no longer supported in release 21.8.

The following alarms have been deprecated in this release:


SNMP MIB Alarm Changes for 21.8This section provides information on SNMP MIB alarm changes in release 21.8.


Important

New SNMP MIB Alarms



• starSxPathFailure

• starSxPathFailureClear

• starThreshDataPlaneMonitor5MinsLoss

• starThreshClearDataPlaneMonitor5MinsLoss

• starThreshDataPlaneMonitor60MinsLoss

• starThreshClearDataPlaneMonitor60MinsLoss

• starThreshControlPlaneMonitor5MinsLoss

• starThreshClearControlPlaneMonitor5MinsLoss

• starThreshControlPlaneMonitor60MinsLoss

• starThreshClearControlPlaneMonitor60MinsLoss

Modified SNMP MIB Alarms




SNMP MIB Changes in StarOS 21.8 and USP 6.2SNMP MIB Alarm Changes for 21.8


Deprecated SNMP MIB Alarms




SNMP MIB Conformance Changes for 21.8This section provides information on SNMP MIB alarm changes in release 21.8.


Important

New SNMP MIB Conformance




Modified SNMP MIB Conformance




Deprecated SNMP MIB Conformance




SNMP MIB Object Changes for 6.2This section provides information on SNMPMIB object changes in the UltraMMIB corresponding to release6.2.


SNMP MIB Changes in StarOS 21.8 and USP 6.2SNMP MIB Conformance Changes for 21.8

For more information regarding SNMP MIB objects in this section, see the Ultra M Solutions Guide for thisrelease.

Important

New SNMP MIB Objects

This section identifies new SNMP MIB objects available in release 6.2.

The following objects are new in this release:

• cultramSiteId

Modified SNMP MIB Objects

This section identifies SNMP MIB objects modified in release 6.2.

The following objects have been modified in this release:

• cultramFaultIndex – The object ID was changed from 1 to 2.

• cultramNFVIdenity – The object ID was changed from 2 to 3.

• cultramFaultDomain – The object ID was changed from 3 to 4.

• cultramFaultSource – The object ID was changed from 4 to 5.

• cultramFaultCreationTime – The object ID was changed from 5 to 6.

• cultramFaultSeverity – The object ID was changed from 6 to 7.

• cultramFaultCode – The object ID was changed from 7 to 8.

• cultramFaultDescription – The object ID was changed from 8 to 9.

Deprecated SNMP MIB Objects

This section identifies SNMP MIB objects that are no longer supported in release 6.2.

The following objects have been deprecated in this release:


SNMP MIB Alarm Changes for 6.2This section provides information on SNMPMIB alarm changes in the Ultra MMIB corresponding to release6.2.

For more information regarding SNMP MIB alarms in this section, see the Ultra M Solutions Guide for thisrelease.

Important


SNMP MIB Changes in StarOS 21.8 and USP 6.2SNMP MIB Alarm Changes for 6.2

New SNMP MIB Alarms




Modified SNMP MIB Alarms




Deprecated SNMP MIB Alarms




SNMP MIB Conformance Changes for 6.2This section provides information on SNMP MIB conformance statement changes in the Ultra M MIBcorresponding to release 6.2.

For more information regarding SNMPMIB conformance statements in this section, see theUltra M SolutionsGuide for this release.

Important

New SNMP MIB Conformance Statements

This section identifies new SNMP MIB conformance statements available in release 6.2.

The following conformance statements are new in this release:


Modified SNMP MIB Conformance Statements

This section identifies SNMP MIB conformance statements that are modified in release 6.2.

The following conformance statements have been modified in this release:


Deprecated SNMP MIB Conformance Statements

This section identifies SNMP MIB conformance statements that are no longer supported in release 6.2.



The following conformance statements have been deprecated in this release:




C H A P T E R 42StarOS Release 21.6.x Interoperability with USPRelease 6.2.bx




USP, StarOSApplicable Platform(s)






• StarOS Reference documents


Revision History


6.2.bx

21.6.x

First introduced.


Feature ChangesThe StarOS release 21.6.13 (21.6.x) has been validated for use with USP 6.2.b3 (6.2.bx). For information onthe StarOS features, see the documents under Release 21.6 in this link https://www.cisco.com/c/en/us/support/wireless/asr-5000-series/products-installation-and-configuration-guides-list.html.


StarOS Release 21.6.x Interoperability with USP Release 6.2.bxFeature Changes

https://www.cisco.com/c/en/us/support/wireless/asr-5000-series/products-installation-and-configuration-guides-list.html

https://www.cisco.com/c/en/us/support/wireless/asr-5000-series/products-installation-and-configuration-guides-list.html

C H A P T E R 43Triggering Iu Release Command Procedure


• Feature Summary and Revision History, on page 279• Feature Description, on page 280• Configuring RAB Messages with Cause 46, on page 281• Monitoring and Troubleshooting, on page 282


SGSNApplicable Product(s) or FunctionalArea

• ASR 5500

• VPC-DI

• VPC-SI





• SGSN Administration Guide



Revision History




21.8SGSN triggers the Iu Release procedure when it receives:

• RAB Release Request with cause 46 "Radio Connection With UE Lost".

• RAB Assignment Response with cause 46 "Radio Connection With UE Lost".

This feature is available in 21.8.4 and 21.9 releases.


Feature DescriptionSGSN triggers the Iu Release Command procedure to RNC when it receives the RAB Release Request withcause 46 "Radio Connection With UE Lost" and the RAB Assignment Response with cause 46 "RadioConnection With UE Lost".

Support for RAB Release Request with cause 46

In releases prior to 21.8: When SGSN receives the RAB Release Request with cause "Radio ConnectionWithUELost" fromRNC, it responds with the same cause code in RABAssignment Request (cause RABRelease).RNC then sends the RAB Assignment Response with cause RAB Release followed by Iu Release Commandwith cause "No Remaining RAB" to SGSN.

In 21.8 and later releases: When SGSN receives the RAB Release Request with cause "Radio ConnectionWith UE Lost" from RNC, it triggers the Iu Release Command with cause "Normal Release". RNC then sendsthe Iu Release Complete message to SGSN.

The Iu release procedure is handled through the ranap rabrel-with-radiolost CLI command configured inthe RNC Configuration mode.

SGSN proceeds with the following steps when it receives the RAB Release Request with cause "RadioConnection With UE Lost":

• SGSN verifies if the ranap rabrel-with-radiolost CLI command is enabled.

• If the ranap rabrel-with-radiolostCLI command is enabled, then SGSN triggers the Iu Release commandtowards the RNC to release the Iu connection for that specific UE.

Support for RAB Assignment Response with cause 46

In releases prior to 21.8: When RNC sends the RAB Assignment Response with cause "Radio ConnectionWith UE Lost", SGSN sends the RABAssignment Request with the cause "Radio ConnectionWith UE Lost".Multiple retries are done before RNC sends the Iu Release Request message.

In 21.8 and later releases: When RNC sends the RAB Assignment Response with cause "Radio ConnectionWith UE Lost", SGSN sends the Iu Release Command immediately and there are no RABAssignment Requestretries.

The Iu release procedure is handled through the ranap rab-arsp-ue-radio-lost CLI command configured inthe RNC Configuration mode.


Triggering Iu Release Command ProcedureFeature Description

SGSN proceeds with the following steps when it receives the RAB Assignment Response with cause "RadioConnection With UE Lost":

• SGSN verifies if the ranap rab-arsp-ue-radio-lost CLI command is enabled.

• If the ranap rab-arsp-ue-radio-lost CLI command is enabled, then SGSN triggers the Iu ReleaseCommand towards the RNC to release the Iu connection for that specific UE.

Configuring RAB Messages with Cause 46This section describes how to trigger the Iu Release Command procedure with cause 46 "Radio ConnectionWith UE Lost".

Configuring RAB Assignment ResponseUse the following configuration to enable or disable handling of the RAB Assignment Response with cause46 (Radio ConnectionWith UE Lost). SGSN sends the Iu Release Command with normal cause to RNCwhenit receives the RAB Assignment Response with cause 46.


iups-service service_name

rnc id rnc_id

[ no ] ranap rab-arsp-ue-radio-lostend

NOTES:

• iups-service service_name: Creates an IuPS service instance and enters the IuPS Service Configurationmode. This mode defines the configuration and usage of IuPS interfaces between the SGSN and theRNCs in the UMTS radio access network (UTRAN).

service_name specifies the IuPS service name as a unique alphanumeric string of 1 through 63 characters.

• rnc id rnc_id: Sets the identification number of the RNC configuration instance. rnc_id must be aninteger from 0 to 65535.

• When no ranap rab-arsp-ue-radio-lost is configured, SGSN will send the RAB Assignment Requestwith RAB Release to RNC.

• This command applies to Gn-SGSN only.


Configuring RAB Release RequestUse the following configuration to enable or disable handling of the RAB Release Request with cause 46(Radio Connection With UE Lost). SGSN sends the Iu Release Command to RNC when it receives the RABRelease Request with cause 46.



Triggering Iu Release Command ProcedureConfiguring RAB Messages with Cause 46

iups-service service_name

rnc id rnc_id

[ no ] ranap rab-release-with-radiolostend

NOTES:

• iups-service service_name: Creates an IuPS service instance and enters the IuPS Service Configurationmode. This mode defines the configuration and usage of IuPS interfaces between the SGSN and theRNCs in the UMTS radio access network (UTRAN).

service_name specifies the IuPS service name as a unique alphanumeric string of 1 through 63 characters.

• rnc id rnc_id: Sets the identification number of the RNC configuration instance. rnc_id must be aninteger from 0 to 65535.

• When no ranap rab-release-with-radiolost is configured, SGSNwill send the RABAssignment Requestwith RAB Release to RNC.

• This command applies to Gn-SGSN only.


Monitoring and TroubleshootingThis section provides information regarding show commands and bulk statistics available to monitor andtroubleshoot this feature.

Show Commands and Outputs

show iups-service allThe output of this command includes the following fields:

• Rab release with Radio lost—Indicates whether RABRelease Request with cause 46 "Radio ConnectionWith UE Lost" is enabled or disabled.

• Rab assignment response with UE Radio lost — Indicates whether RAB Assignment Response withcause 46 "Radio Connection With UE Lost" is enabled or disabled.

Bulk StatisticsThe following bulk statistics are available in the SGSN schema.

• Iu-release-command-with-radio-lost-ue — Total number of Iu interface release commands due to RABRelease Request with radio lost received.

• Iu-release-command-rab-ass-rsp-with-radio-lost-ue — Total number of Iu interface release commandsdue to RAB Assignment Response with radio lost received.


Triggering Iu Release Command ProcedureMonitoring and Troubleshooting

C H A P T E R 44UAS and UEM Login Security Enhancements

• Feature Summary and Revision History, on page 283• Feature Description, on page 283


Ultra Automation Services (UAS)Applicable Product(s) or FunctionalArea

UGP running on the Ultra M SolutionApplicable Platform(s)

Enabled – Always-onFeature Default





Revision History




Feature DescriptionFor UAS and UEM components, the following login security restrictions are supported:


• You will be locked out of the system for 10 minutes upon the third incorrect attempt to login to a UASor UEM VM.

• Should you need/want to change your password, the new password must be different than any of the lastfive previously configured passwords.


UAS and UEM Login Security EnhancementsFeature Description

C H A P T E R 45UEM Patch Upgrade Process

• Feature Summary and Revision History, on page 285• Feature Description, on page 286• UEM Upgrade Workflow, on page 286• Initiating the UEM Patch Upgrade, on page 290• Limitations, on page 292










Revision History




Feature Description


Important

In releases prior to 6.2, the USP-based VNF would have to be completely terminated in order to perform anupgrade of the UEM. Furthermore, the UEM patch upgrade functionality that existed was limited and manual.

With this release, the UEM can optionally be upgraded as part of a rolling patch upgrade process in order topreserve the operational state of the VNF, UAS, and VNFM deployments.

UEM Upgrade WorkflowIn the rolling patch upgrade process, each of the VMs in the UEM Zookeeper cluster is upgraded one at atime. By default, the upgrade attempts to upgrade the slave VM first and the Zookeeper-elected leader VMlast as illustrated in Figure 15: UEM Patch Upgrade Process Flow, on page 288.


UEM Patch Upgrade ProcessFeature Description

Figure 14: UEM VM Upgrade Order for 3 VM based UEM Cluster

The UEM patch upgrade process is supported for Ultra M deployments that leverage the Hyper-Convergedarchitecture and for stand-alone AutoVNF deployments.

Important

Figure 15: UEM Patch Upgrade Process Flow, on page 288 illustrates the UEM patch upgrade process forUltra M deployments. For stand-alone AutoVNF deployments, the upgrade software image is uploaded to theonboarding server (step 1) and the upgrade command is executed from AutoVNF (step 3).


UEM Patch Upgrade ProcessUEM Upgrade Workflow

Figure 15: UEM Patch Upgrade Process Flow

1. Onboard the new USP ISO containing the UEM upgrade image to the Ultra M Manager node.







<---SNIP--->

The package must then be referenced in the virtual descriptor unit (VDU) pertaining to the UEM:<---SNIP--->vdu emvdu-type element-managerlogin-credential em_loginscm scmimage vnf-packagevnf-rack vnf-rack1vnf-package primary <upgrade_package_descriptor_name>

vnf-package secondary <previous_package_descriptor_name>…<---SNIP--->




Important

3. The rolling upgrade request is triggered through AutoDeploy which initiates the process with AutoVNF.

4. AutoVNF obtains the UEM HA VIP from the Oper data and communicates with the correspondingUEM to determine the IP addresses of the eth0 interface for each VM in the UEM cluster. Thisinformation is maintained in a file on the VM named ip.txt.

AutoVNF then uses the address information to communicatewith eachUEM to determine their Zookeeperstate (master, slave, and standby).

The upgrade order is illustrated in Figure 14: UEM VM Upgrade Order for 3 VM based UEM Cluster,on page 287. The rest of this procedure assumes that that the standbyUEMVM is the Zookeeper-electedleader.

5. AutoVNF triggers the shutdown of the slave UEM VM via the VNFM.

6. The VNFM works with VIM to remove the slave UEM VM.

7. AutoVNF waits until the VNFM confirms that the slave UEM VM has been completely terminated.

8. AutoVNF initiates the deployment of a new UEM VM via the VNFM using the upgrade image.

9. The VNFM works with the VIM to deploy the new UEM VM.

• If the ESC does not receive the “SERVICE UPDATE” notification for the newly added VM instances,the upgrade will fail and require a manual intervention.

• If ESC state (service/VM state ) is not ‘ACTIVE’, then the upgrade will not proceed. You need to manuallyverify the logs to determine the reason for the inactive state.

Important

10. The slave UEM VM synchronizes data with the master UEM VM.

11. AutoVNF waits until the VNFM confirms that the new VM has been deployed and is in slave mode.

If AutoVNF detects that there is an issue with the VM, it re-initiates the UEM VM with the previousimage if it was identified as a secondary image in the UEM VDU.

If no issues are detected, AutoVNF proceeds with the upgrade process.

12. Repeat the steps 4, on page 289 to 10, on page 289 for the UEM VM that is currently the master. Oncethe master goes down, the slave UEM becomes the master.

If an issue is encountered during the upgrade of the second UEM VM (e.g. the master UEM VM in thisscenario), then the process stops completely and AutoVNF upstart logs are generated.

13. Repeat the steps 4, on page 289 to 8, on page 289 for the standbyVM. In this case, the UEM is re-deployedas the standby VM.



Initiating the UEM Patch UpgradeUEM patch upgrades are initiated through a remote procedure call (RPC) executed from the ConfD commandline interface (CLI) or via a NETCONF API.




NOTES:

• <nsd_name> and <vnfd_name> are the names of the network service descriptor (NSD) file and VNFdescriptor (VNFD) (respectively) in which the VNF component (VNFC) for the UEM VNF componentis defined.


• <pkg_id> is the name of the USP ISO containing the upgraded UEM VM image.

• Ensure that the upgrade package is defined as a VNF package descriptor within the NSD and that it isspecified as the primary package in the UEM VDU configuration.

• Ensure that the current (pre-upgrade) package is specified as the secondary package in the UEM VDUconfiguration in order to provide rollback support in the event of errors.



Parameters:


NSD namestringMnsd


booleanMrolling


stringMvnfd


UEM Patch Upgrade ProcessInitiating the UEM Patch Upgrade



stringMpackage

NOTES:


• Ensure that the upgrade package is defined as a VNF package descriptor within the NSD and that it isspecified as the primary package in the UEM VDU configuration.

• Ensure that the current (pre-upgrade) package is specified as the secondary package in the UEM VDUconfiguration in order to provide rollback support in the event of errors.

Example RPC









</vnfc></vnfd>


UEM Patch Upgrade ProcessVia the NETCONF API




</flavor><login-credential>esc_login</login-credential><netconf-credential>esc_netconf</netconf-credential><image><vnf-package>usp_throttle</vnf-package>




</secure-token><secure-token xmlns="http://www.cisco.com/usp/nfv/usp-secure-token"><secure-id>esc_netconf</secure-id><user>admin</user><password>******</password>




</config>

LimitationsThe following limitations exist with the UEM upgrade feature:


UEM Patch Upgrade ProcessLimitations


• The rolling UEMpatch upgrade process can only be used to upgrade to new releases that have a compatibledatabase schema. As new releases become available, Cisco will provide information as to whether ornot this functionality can be used to perform the upgrade.

• For Ultra M deployments, AutoDeploy and AutoIT must be upgraded before using this functionality.Upgrading these products will terminate the VNF deployment.

• For stand-alone AutoVNF deployments, AutoVNF must be upgraded before using this functionality.Upgrading these products will terminate the VNF deployment.





C H A P T E R 46Ultra M C2.1 MicroPod Deployment with CVIM

• Feature Summary and Revision History, on page 295• Feature Description, on page 295






• Ultra M Solutions Guide with CVIM



Revision History


6.2.bxFirst introduced.

Feature DescriptionThe Ultra M C2.1 micropod deployment model is currently available. It is based on OpenStack 10 andimplements a All-in-one architecture that combines the Controller, Ceph Storage and Compute nodes. Theconverged node is referred to as a Micropod node.


This model can have one SF per compute node and/or two SFs per compute node. It can support one or twoVNFs. The VNFs are deployed on Cisco VIM (CVIM). For more information on CVIM, see the CiscoVirtualized Infrastructure Manager Installation Guide.

For detailed information on the hardware/software recommendations and the Ultra M solution deployment,see the Ultra M Solutions Guide with CVIM.


Ultra M C2.1 MicroPod Deployment with CVIMFeature Description

C H A P T E R 47Ultra M Manager Integration with AutoIT











Revision History


N6.0First introduced.

6.2Though this feature was introduced in N6.0, it was not fully qualified. It is now fullyqualified as of this release.


Feature ChangesIn previous software releases, the Ultra MManager was distributed as an RPM bundle which was distributedboth within the USP ISO and as a separate RPM.

In this release, the functionality enabled through the Ultra M Manager is now part of AutoIT and AutoVNF.Once these UAS modules are installed, health monitoring features and functionality are available forconfiguration and use.

The integrated UltraMManager functionality is currently supported only with UltraMUGPVNF deploymentsbased on OSP 10 and that leverage the Hyper-Converged architecture. The Ultra M Manager RPM is stilldistributed separately and is intended only for use in specific deployment scenarios. Contact your local salesor support representative for more information.

Important

Event Aggregation Functionality

With its integration into AutoIT, the Ultra M Manager event aggregation (fault management) configurationprocess has also changed.

Previously, Ultra M Manager event aggregation configuration was performed through the ultram_cfg.yamlfile.

As of this release, this functionality is now configured through NETCONF API-based remote procedure callsinvoked via AutoIT or through a network service descriptor (NSD) configuration file activated throughAutoDeploy. In either scenario, the parameters related to this functionality are defined by/within the faultmanagement descriptor (FMD).

This API is used to configure:

• Fault domains: The specific components within the Ultra M solution for which fault management is tobe performed. During configuration, the individual domains for which you wish to perform eventaggregation can be specified. Alternatively, if no domains are specified, then the default behavior is tomonitor all domains.

• Event severity: Configures the lowest-level severity of the events that are to be monitored. The severitycan be specified as one of the following (arranged highest to lowest severity):

• emergency -- System level FAULT impacting multiple VNFs/Services

• critical -- Critical Fault specific to VNF/Service

• major -- component level failure within VNF/service.

• alert -- warning condition for a service/VNF may eventually impact service.

• informational -- informational only does not impact service

Configuring the lowest-level severity means that events of that severity and higher are monitored. Forexample, if a severity of “major” is configured, then “major”, “critical” and “emergency” events aremonitored.

If no severity is specified, “informational” is used as the default.


Ultra M Manager Integration with AutoITFeature Changes

• SNMP descriptor: Configures parameters related to the version(s) of SNMP that are supported. SNMPv2c and v3 are supported.

• VIM parameters: Configures VIM parameters and the specific aspects of OpenStack to be monitored:

• Modules (e.g. ceph, cinder, nova, etc.)

• Controller services (e.g. cinder, glance, heat, etc.)

• Compute services (e.g. ceph-mon.target, ceph-radosgw.target, ceph.target, etc.)

• OSD compute services (e.g. ceph-mon.target, ceph-radosgw.target, ceph.target, etc.)

Individual modules and services can be configured. If no specific modules are configured, then eventaggregation is enabled for all modules.

Controller, compute, and OSD compute services cannot be configured unless thesystemctl module is enabled.

Important

Though the FMD configuration can be included in the NSD configuration file, it is recommended that theconfiguration for this functionality be maintained in a separate, FMD-specific NSD configuration file.

Refer to the Cisco Ultra Services Platform NETCONF API Guide for more information on configuringparameters related to the FMD.

Ultra M MIB Changes

A new object called cultramSiteId was added to the cultramFaultTable in the Ultra M MIB. The addition ofthis object resulted in the object IDs for all other objects in cultramFaultTable being incremented by 1.

Refer to SNMP MIB Changes in StarOS 21.8 and USP 6.2, on page 271 for details on this change.

Syslog Proxy Functionality

Syslog proxy functionality is supported at the following levels:

• Syslogging for UCS Hardware

Syslogs for the UCS servers that comprise the Ultra M solution are proxied through AutoIT.

The server list is based on the configuration specified in the VIMOrchestrator andVIMNSD configurationfile. As such, syslog proxy functionality for the hardware must be performed after the VIM has beendeployed.

• Syslogging for OpenStack services

AutoIT can be configured to serve as a proxy for OpenStack service syslogs.

The list of servers on which OpenStack is running is based on the configuration specified in the VIMOrchestrator and VIMNSD configuration file. As such, syslog proxy functionality for the hardware mustbe performed after the VIM has been deployed.

Syslogging is automatically enabled for the following services:

• Nova

• Cinder



• Keystone

• Glance

• Ceph monitor (Controller nodes only)

• Ceph OSD (OSD Compute nodes only)

• Syslogging for UAS Modules

Each UAS software module can be configured to send logs and syslogs to one or more external collectionservers.

• AutoDeploy and AutoIT

Logs and syslogs are sent directly to one or more external syslog collection servers configured whenthese modules are first installed. The configured collection servers are also the receivers for UCSserver hardware and OpenStack services for which AutoIT is a proxy.

The following logs are sent:

• AutoDeploy:

• /var/log/upstart/autodeploy.log

• /var/log/syslog

• AutoIT:

• /var/log/upstart/autoit.log

• /var/log/syslog

In order to support syslogging functionality, additional operators were added to the boot_uas.pyscript used to install these modules:

• --syslog-ip<ext_syslog_server_address>

• --port<syslog_port_number>

• --severity<syslog_severity_to_send>

Multiple collection server addresses can be configured.

Furthermore, the following additional AutoIT installation parameters have been added to theProvisioning Network Details:

• Provisional Network HA VIP: The VIP address to be assigned to AutoIT's provisional networkinterface.

• AutoVNF

AutoVNF serves as the syslog proxy for the VNFM, UEM, and CF VNF components (VNFCs). Italso sends its own logs to the same external syslog collection server:

• /var/log/upstart/autovnf.log

• /var/log/syslog



Syslogging for the AutoVNF module is configured through the AutoVNF VNFC configurationwithin the VNF Rack and VNF NSD configuration file.

• Syslogging for VNFM, UEM, and CF VNFCs

AutoVNF can be configured as the syslog proxy for the following VNFM, UEM, and CFVNF component(VNFC) logs:

• VNFM (ESC): /var/log/messages

escmanager and mona logs are not configured as part of syslog automation. ESCcan be manually configured to send these logs to the syslog proxy or to an externalsyslog collection server.

Note

• UEM:

• /var/log/em/vnfm-proxy/vnfm-proxy

• /var/log/em/ncs/ncs-java-vm

• /var/log/em/zookeeper/zookeeper

• /var/log/syslog

• CF: All syslogs configured within the StarOS.

Syslogging for the VNFM, UEM, and CF is configured through their respective VNFC configurationswithin the VNF Rack and VNF NSD configuration file.

UCS Server Utility Integration with AutoIT

TheUltraMManager provided utilities to simplify the process of upgrading the UCS server software (firmware)within the Ultra M solution. The integration of Ultra M Manager into AutoIT include full support for theseutilities. Additionally, there is no difference in function or use except that the utilities are executed from theAutoIT VM.

Refer to the Ultra M Solutions Guide for more information.



C H A P T E R 48Ultra M Manager SNMP Fault Suppression











Revision History



6.2First introduced in a FCS release. (It had been previously released in the 5.1.9 ER.)


Feature ChangesIn past releases, the fault suppression feature was made available through the Ultra M Manager utility (UltraM Manager RPM software). In this release,the fault suppression functionality is automated and managedthrough the NETCONF API.

Fault suppression functionality is configured through a fault management descriptor (FMD) configurationfile that is comprised of the required NETCONF parameters.

Depending on the configuration of this functionality, the faults can be suppressed at the following levels:

• UCS server:

• UCS cluster: All events for all UCS nodes are suppressed.

• UCS fault object distinguished names (DNs): All events for one or more specified UCS objectDNs within are suppressed.

• UCS faults: One or more specified UCS faults are suppressed.

Fault suppression can be simultaneously configured at both the UCS object DNand fault levels.

Important

• UAS and VNF components:

• UAS component cluster: All events for all UAS components are suppressed.

• UAS component events: One or more specified UAS component events are suppressed.

When faults are suppressed, event monitoring occurs as usual and the log report file shows the faults. However,suppressed faults are not reported over SNMP. Within the log file, suppress faults are preceded by the word“Skipping”.

Refer to the Ultra M Solutions Guide for details on configuring SNMP Fault Suppression.


Ultra M Manager SNMP Fault SuppressionFeature Changes

C H A P T E R 49USP Software Version Updates











Revision History



Feature ChangesCisco ESC Software Version Update

The Cisco Elastic Services Controller (ESC) product is used as the virtual network function manager (VNFM)within the Ultra Services Platform.


The supported ESC version in this release has been updated from 3.1.0.145 to 4.0.0.104.

This is the default ESC version included as part of the USP 6.2 release package and must be installed beforeusing it.

RedHat Software Version Update

This release includes support for RedHat version 7.4 to incorporate bug fixes and performance improvements.

RedHat 7.4 has been validated and is recommended for use only with Ultra M deployments based on OSP 10and that leverage the Hyper-Converged architecture.

Cisco UCS C240 M4S Software Version Updates

The Cisco UCS C240 M4S server is used within the Ultra M solution. The following software/firmwareversions have been validated and recommended for use with this release:

• CIMC: 3.0(4a)

• System BIOS: C240M4.3.0.4a.0.0226182314


USP Software Version UpdatesFeature Changes

release change reference, staros release 21.8/ultra ...€¦ · chapter 2...

Documents