The Ultra Packet Core CUPS KPI Reference document describes the Key Performance Indicators (KPIs) used for performance analysis on the UPC CUPS node. Guidelines and procedures are provided for calculating KPIs from an Operational and Planning perspective.

For more information, contact your Cisco Account representative.

With this release, support has been added for the following Custom dictionary in CUPS:

• dpca-custom24 (Gx): Custom-defined Diameter Policy Control Application (DPCA) dictionary.

Note	This is a customer-specific feature. For more information about Diameter and GTPP dictionaries, see AAA Interface Administration and Reference and GTPP Interface Administration and Reference guide, or contact your Cisco Account representative.

After UP is up, the Day-0.5 configuration is executed on UP. When UPs register with RCM, the Controller pushes the hostID and SSH IP to UP along with the state. The SSH IP received may get configured and saved as a part of Day-0.5 configuration. To avoid that, we must defer the SSH IP installation until the Day-0.5 configuration is saved.

The Deferring SSH IP Installation functionality is CLI-controlled.

For more information, refer to the RCM Configuration and Administration Guide.

RCM HA switchover on mass UP failure is now supported in 5G-UPF.

Previous Behavior: RCM HA switchover occurs instantly when all UPs go down.

New Behavior: RCM HA switchover occurs after three minutes when all UPs go down.

Customer Impact: Reloading all UPs will not trigger RCM HA switchover in the usual RCM operation as the operator intentionally reloads all UPs.

Note	Undetected network isolation is not likely in this case as L2 VRRP protocol will cover any such network isolation case.

The Device ID in EDNS0 offers each enterprise with a customized domain blocking through Umbrella. To enable this functionality:

• The UP must reformat a subscriber DNS request into an EDNS0 request, and

• The UP must include an Umbrella “Device ID” in the EDNS0 packet so that the Umbrella DNS resolver can use the Device ID to apply the domain filter associated/configured with the Device ID in the EDNS0 packet.

Presently, the Control Plane (CP) receives the domain filtering policy ID from PCRF/PCF. The CP passes the domain filtering policy ID to the User Plane (UP) in the Subscriber Parameters. The UP uses the domain filtering policy ID to apply domain filtering functionality to the subscriber.

For more details, see the Device ID in EDNS0 Records chapter in the Ultra Packet Core CUPS Conrol Plane Administration Guide or the Ultra Packet Core CUPS User Plane Administration Guide.

Whenever you use an unauthorized DNS server, the request is modified to readdress the DNS IPs to use the authorized servers. Ruledef determines if a packet belongs to a DNS query and if the DNS query belongs to a set of authorized DNS servers or not. If the DNS query does not belong to the authorized DNS servers, the flow action is to pick up DNS servers from the readdress-server-list .

A readdress-server-list is configured under the active charging server. When the flow matches a ruledef , the flow action can be configured to use the servers from the readdress-server-list .

For more information, see VPP Support chapter in the Ultra Packet Core CUPS Control Plane Administration Guide or the Ultra Packet Core CUPS User Plane Administration Guide.

Applications such as SRP, SX, RCM, LI, and TACACS operate between nodes that are deployed across different networks. All these applications require quick turnaround while communicating with remote systems. Marking of Encapsulating Security Payload (ESP) packets with a Quality of Service (QoS) such as Differentiated Services Code Point (DSCP) helps to determine the traffic classification for these types of packets. This feature enables prioritization of IPsec packets within their IP core network, and improves scalability of interfaces such as Sx, and SRP using IPsec.

For more information, refer to the IPSEC in CUPS chapter in the Ultra Packet Core CUPS Control Plane Administration Guide or the Ultra Packet Core CUPS User Plane Administration Guide.

ECS supports generation of Interim EDRs – EDRs that are generated for ongoing flows based on a configurable timer.

Usually, EDRs are generated for flows only when the flow terminates or when the flow reaches the configured flow idle-timeout value. These flows could have time duration that is as long as 48 hours, which makes it difficult to track subscriber activity until an EDR is generated.

Thus, with interim EDRs, ongoing flow activities are tracked by configuring an interim timeout value for a flow. On expiration of the interim timer, an EDR is generated.

For configuring an interim EDR, a new CLI keyword, interim , is introduced. Based on the configuration, the interim timer is applied to newly created flows. On expiration of the timer, an interim EDR is generated along with the following reason: sn-closure-reason (23) . The information volume available until the expiration of the timer is populated in the EDR along with its respective timestamps.

For more information, refer to the Event Data Records in CUPS chapter in the Ultra Packet Core CUPS Control Plane Administration Guide or the Ultra Packet Core CUPS User Plane Administration Guide.

This feature allows suppression of CDRs with zero byte data count, so that the OCG node is not overloaded with a flood of CDRs. The CDRs can be categorized as follows:

• Final-cdrs: These CDRs are generated at the end of a context.

• Internal-trigger-cdrs: These CDRs are generated due to internal triggers such as volume limit, time limit, tariff change, or user-generated interims through the CLI commands.

• External-trigger-cdrs: These CDRs are generated due to external triggers such as QoS Change, RAT change and so on. All triggers which are not considered as final-cdrs or internal-trigger-cdrs are considered as external-trigger-cdrs.

The customers can select the CDRs they want to suppress.

The CLI command mentioned below helps suppress CDRs on different CDR triggers supported in CUPS:

• [ default | no ] gtpp suppress-cdrs zero-volume { external-trigger-cdr | final-cdr | internal-trigger-cdr }

The X-Header Insertion and X-Header Encryption features, collectively known as Header Enrichment, enables to append headers to HTTP/WSP GET and POST request packets, and HTTP Response packets for use by end applications, such as mobile advertisement insertion (MSISDN, IMSI, IP address, user-customizable, and so on).

For more information, refer to the X-Header Insertion and Encryption chapter in the Ultra Packet Core CUPS Control Plane Administration Guide or the Ultra Packet Core CUPS User Plane Administration Guide.

Hyperthreading uses the Parallel Computing technology to enhance the system performance on processing the packets.

For more information, refer to the IFTASK Hyperthreading chapter in the Ultra Packet Core CUPS Control Plane Administration Guide or the Ultra Packet Core CUPS User Plane Administration Guide.

With this release, the VPN limitation of 100 UPs per context has been removed.

For more information, refer to the IP Pool Management chapter in the Ultra Packet Core CUPS Control Plane Administration Guide or the Ultra Packet Core CUPS User Plane Administration Guide.

This feature supports multiple LI Mediation Systems. The Lawful Intercept in CUPS supports configuration of multiple LI servers. However existing design does not allow sending event or content information to multiple servers during same active session. This feature allows to configure two LI servers information for both event and content delivery, which makes it possible for two agencies to provision a single subscriber for interception.

For more information, refer to the Lawful Intercept in CUPS chapter in the Ultra Packet Core CUPS LI Guide

When Multiple CPs are connected to single UP, it allows a subscriber to connect to UP using any of the available CP. One of the primary use case of Multiple Sx feature is Active-Active redundancy. Even though it does not offer redundancy, as the calls are not recovered, multiple Sx allows the UPs connected to one CP to be still accessible in case of a CP failure. If a CP fails, the calls serviced by that CP are lost. When they re-attach, the calls are routed to other available CPs which reuses the same UP pool.

For more information, refer to the Multiple Control Plane Support on User Plane chapter in the Ultra Packet Core CUPS Control Plane Administration Guide or the Ultra Packet Core CUPS User Plane Administration Guide.

Remote CUPS allows progressive configuration rollout on an operator network. You can deploy and activate a pilot or canary version N+1 on a given CP or UPs pool, while the version N configuration is still active on the other CP or UP pool(s) until the operator decides to rollout this N+1 configuration to all the CP or UP pools after the monitoring period.

For more information, see Multiple UP Group Support chapter in the Ultra Packet Core CUPS Control Plane Administration Guide or the Ultra Packet Core CUPS User Plane Administration Guide.

The Cisco Network Service Orchestrator (NSO) based configuration management for 4G CUPS supports:

• Onboarding of Cisco Virtual Network Function (VNF) devices—CP, UP, and RCM.

• Centralized configuration management of 4G-based CPs, UPs, and RCMs for Day-N, Day-1, and Day-0.5 CUPS configuration push.

Managing customer configuration management for 4G CUPS deployments using NSO automation also exhibits reusability, standard notification management, and systematic device configuration governance.

For more information, refer to the NSO-based Configuration Management chapter in the Ultra Packet Core CUPS Control Plane Administration Guide or the Ultra Packet Core CUPS User Plane Administration Guide.

The Cisco Network Service Orchestrator (NSO) based VNF orchestration enables you to manage the lifecycle of newly created Virtual Network Function (VNF) devices such as CP, UP, and RCM.

The Cisco NSO Orchestration for 4G CUPS solution provides the following functions:

• Instantiation via NSO CLI, Web-Interface, or NSO RESTCONF API

• Onboarding of VNF devices such as CP, UP, and RCM upon successful instantiation

• Pushing of Day-0.5, and Day-1 CUPS configuration after successful instantiation

• Decommission of the VNF devices

For more information, refer to the NSO Orchestration for 4G CUPS chapter in the Ultra Packet Core CUPS Control Plane Administration Guide or the Ultra Packet Core CUPS User Plane Administration Guide.

This feature enables the RADIUS server to indicate the appropriate state regardless of the timing of keep-alive transmissions.

For more information, refer to the RADIUS Server State chapter in the Ultra Packet Core CUPS Control Plane Administration Guide.

CUPS supports backward compatibility of software releases on Control Plane (CP) and User Plane (UP). The feature allows seamless upgrade/downgrade of the software from/to one previous release (N-1)/ two previous releases (N-2)/ three previous releases (N-3). The functionality includes support for the following:

• N-1/N-2/N-3 compatibility of software releases on two CPs in ICSR mode—allows seamless upgrade of CPs from one version to another in CP 1:1 redundancy scenario.

• N-1/N-2/N-3 compatibility of software releases on two UPs in ICSR mode—allows seamless upgrade of UPs from one version to another in UP 1:1 redundancy scenario.

• N-1/N-2/N-3 compatibility of software releases between CP and UP—allows seamless upgrade of the associated CP or UP from one version to another.

• N-1/N-2/N-3 compatibility of software releases between CP and UP with multi-Sx—allows seamless upgrade of the associated CP or UP from one version to another in multi-Sx scenario.

For more information, refer to the Software Management Operations chapter in the Ultra Packet Core CUPS Control Plane Administration Guide or the Ultra Packet Core CUPS User Plane Administration Guide.

This feature supports regardless-of-other-triggers option in CLI for CUPS. regardless-of-other-triggers option enables eG-CDR or P-GW-CDR generation at the fixed time interval irrespective of any other eG-CDR or P-GW-CDR triggers that may occur in between. Therefore, when you enable this option although other CDR triggers occur, the Time Limit CDR gets triggered dynamically at every interval in seconds, that is, the Time Threshold calculation is based on the sum of the last threshold time and the interval. This option supports session recovery and ICSR.

For more information, see Overview chapter in the Ultra Packet Core CUPS Control Plane Administration Guide or the Ultra Packet Core CUPS User Plane Administration Guide.

This command displays charging action statistics for all or specified charging actions that are configured in the Active Charging Service (ACS). A charging action represents actions to be taken when a configured rule is matched. Actions range from generating accounting records to dropping the IP packet, and so on. The charging action also determines the metering principle—Whether to count retransmitted packets, and which protocol field to use for billing (L3/L4/L7, and so on).

For more information, see Monitoring and Troubleshooting User Plane in CUPS chapter in the Ultra Packet Core CUPS Control Plane Administration Guide or the Ultra Packet Core CUPS User Plane Administration Guide

This command displays statistics for all groups or a specified group of ruledefs configured in the active charging service. group-of-ruledefs is a collection of rule definitions that can be used in access policy creation.

For more information, see Monitoring and Troubleshooting User Plane in CUPS chapter in the Ultra Packet Core CUPS Control Plane Administration Guide or the Ultra Packet Core CUPS User Plane Administration Guide.

This command displays statistics for all or specified ruledef that is configured in an active charging service. ruledef represents a set of matching conditions across multiple L3 - L7 protocol that is based on protocol fields and state information. You can use each ruledef across multiple rule bases within the active charging service.

For more information, see Monitoring and Troubleshooting User Plane in CUPS chapter in the Ultra Packet Core CUPS Control Plane Administration Guide or the Ultra Packet Core CUPS User Plane Administration Guide.

With this feature, User Plane group can be selected based on Access Point Name (APN). The ability to configure Tracking Area Code (TAC) range, in rule combinations in virtual APN selection, helps in giving more flexible network design for location-based User Plane selection for edge computing and other services.

With 21.25 and later releases, support is added to configure TAC and Routing Area Code (RAC) profile in the Control Plane node. Using this feature, it is now possible to select APN based on discrete values of TAC/RAC profile instead of range.