UCC 5G UPF Configuration and Administration Guide, Release 2024.03

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

• About this Guide
• 5G Architecture
• 5G-UPF Overview
• Features and Functionality
  • 1:1 Redundancy
  • ADC for Dynamic Rules
  • APN ACL Support
  • APN AMBR Traffic Policing
  • Bulk Statistics Support
  • Charging Support
  • Cisco Ultra Traffic Optimization with VPP
  • Collection and Reporting of Usage Data over N4 Interface
  • Control Plane-Initiated N4 Association Support
  • Converged Datapath
  • Deep Packet Inspection and Inline Services
  • Device ID in EDNS0 Records
  • Downlink Data Notification
  • DSCP Markings For Collapse Calls
  • Dynamic and Static PCC Rules
  • ECS Regular Expression
  • GTP-U Support
  • Heartbeat Support for N4/Sx Interface
  • Idle Mode Buffering and Paging
  • Indirect Forwarding Tunnel
  • IPsec Support for IPv6
  • LTE - Wi-Fi Seamless Handover
  • Monitor Subscriber
  • MPLS Support on UPF
  • Multiple cnSGW Support
  • Multiple N4/Sx Interfaces
  • Nexthop Forwarding Support
  • N:M Redundancy and Redundancy Configuration Manager
  • N3 Transfer of PDU Session Information
  • N4 Interface Compliance with 3GPP Specification
  • N4 Interface Configuration
  • N4/Sx over IPSec
  • N4 Session Management, Node Level, and Reporting Procedures
  • NRF Support
  • Password Expiration Notification
  • QCI 80 Support on UPF
  • QoS Group of Ruledefs Support
  • Roaming Support
  • Secure Group Tag-based Access Control
  • Session Recovery
  • Session Report Rejection Procedure
  • Smart Licensing
  • Software Management Operations
  • Standard QCI Support
  • System Logs
  • UPF Ingress Interfaces
  • UPF Local Configuration
  • UPF Reporting of Load Control Over N4 Interface
  • UPF Usage Monitoring over PCF
  • Virtual Routing and Forwarding
  • Voice over New Radio
  • WPS Prioritization
  • X-Header Insertion and Encryption
  • UPF Troubleshooting Information
  • Sample UPF Configuration
  Find Matches in This Book Log in to Save Content Available Languages Download Options

  Book Title

  UCC 5G UPF Configuration and Administration Guide, Release 2024.03

  Software Management Operations

  • PDF - Complete Book (12.98 MB)PDF - This Chapter (1.04 MB) View with Adobe Reader on a variety of devices

  Results

  Updated: July 31, 2024

  Chapter: Software Management Operations

  Chapter Contents
  • Software Management Operations
  • Feature Summary and Revision History
    • Summary Data
    • Revision History

    Software Management Operations

    Feature Summary and Revision History

    Summary Data

    Applicable Product(s) or Functional Area

    Feature Default Setting

    Related Changes in This Release:

    Revision History

    Overview

    5G UPF supports backward compatibility of software releases on the SMF and the UPF. The feature allows seamless upgrade/downgrade of the software from/to one previous release (N-1). The functionality includes support for the following:

    • N-1 compatibility of software releases on two UPFs in ICSR mode—allows seamless upgrade of UPFs from one version to another in UPF 1:1 redundancy scenario.
    • N-1 compatibility of software releases between SMF and UPF—allows seamless upgrade of the associated SMF or UPF from one version to another.
    • N-1 compatibility of software releases between SMF and UPF with multi-Sx—allows seamless upgrade of the associated SMF or UPF from one version to another in multi-Sx scenario.

    Contact your Cisco Account representative for procedural assistance prior to upgrading or downgrading your software versions.

    Version Exchange between SMF and UPF

    Version/release information is exchanged when SMF and UPF pairs. The release information exchange also occurs when the UPF pairs with a Standby UPF (in 1:1 redundancy scenario) through the heart beat message exchanged between Active and Standby.

    When incompatible releases are paired, an Alarm (SNMP trap) is raised. For details, see SNMP Traps section.

    To indicate the peer version during the exchange of release information, the following new IE is included in the association request and heartbeat request messages.

    Used to specify the peer GR/PFCP version and StarOS version

    SNMP Traps

    The following SNMP traps are raised when pairing is done with an incompatible release.

    SNMP Trap	Description
    SRPPeerUnsupportedVersion	The Active/Standby UPF in higher version raises the SNMP trap when the peer is in a version lower than N-1.
    SRPPeerUnsupportedVersionClear	The Active/Standby UPF in higher version raises the SNMP trap to clear the SRPPeerUnsupportedVersion.
    SxPeerUnsupportedVersion	The UPF in higher version raises the SNMP trap when the peer is in a version lower than N-1.
    SxPeerUnsupportedVersionClear	The UPF in higher version raises an SNMP trap to clear the SxPeerUnsupportedVersion.

    Limitations

    The following are the known limitations of the feature:

    When the peer version is determined to be lower than the supported N-1 version, the association/pairing is allowed. However, functional aspect of the same isn't guaranteed.

    Caution

    Don't attempt to upgrade from incompatible versions. Contact your Cisco Account representative for the upgrade path and steps.

    Health Checks

    Perform the following health checks after every operation of upgrade, downgrade, or reload of chassis.

    1. Check the Service Redundancy Protocol (SRP) information on the Active chassis to avoid issues during an SRP switchover and decide if proactive analysis must be done before the SRP switchover. Use the following CLI commands:
       • srp validate-configuration
       • srp validate-switchover
       • show srp info

    The following is a sample output.

    Peer Configuration Validation: Complete Last Peer Configuration Error: None Last Peer Configuration Event: Wed Mar 18 15:34:02 2022 (1602 seconds ago) Last Validate Switchover Status: None Connection State: Connected

    Check the following parameters:

    • Peer Configuration Validation: Complete—If it shows "In Progress," you must wait and then execute the show srp info CLI command again after 15 seconds (approximately).
    • Last Peer Configuration Error: None—If you see "Peer Checksum Validation Failure," then it indicates that there are configuration differences between Active and Standby chassis that must be fixed.

    Note	If you see any error in Last Peer Configuration Error , validate the configuration using the show configuration srp CLI command on both the Active and Standby UPFs.

    show subscribers summary | grep Total Total Subscribers: 100

    On the Standby chassis, execute the show srp checkpoint statistics | grep allocated CLI command. The following is a sample output.

    show srp checkpoint statistics | grep allocated Current pre-allocated calls: 100

    Session Recovery Status: Overall Status : Ready For Recovery Last Status Update : 7 seconds ago ----sessmgr--- ----aaamgr---- demux cpu state active standby active standby active status 1/0 Active 8 1 8 1 17 Good

    Number of Sessmgrs: 1 Sessmgrs in Active-Connected state: 0 Sessmgrs in Standby-Connected state: 8 Sessmgrs in Pending-Active state: 0

    show card table Slot Card Type Oper State SPOF Attach ----------- ------------------------ ----------- ----- ------ 1: VC 5-Port Virtual Card Active -

    Build Upgrade

    Backup Configuration

    1. Back up the current configuration—Save the current configuration that is used in case of downgrade/upgrade, which probably has all the features and configuration present until now.
    2. Collect the show support details on both Active and Standby chassis before making any changes or upgrade.
    3. Perform Health Checks.

    Upgrade Procedure

    1. Perform chassis Health Checks on both the nodes.
    2. On the secondary chassis (ICSR), which is in Standby state, change boot priority with N+1 build.
    3. Reload to the latest build version.
    4. Do the new configuration change on Standby chassis (For example, any new CLI, license, or configuration changes).
    5. Perform Health Check on the reloaded chassis. Check for any crashes or errors.

    Perform Switchover

    1. Before SRP switchover from Active to Standby on both chassis, check:
       1. On Active chassis: show subscriber summary | grep Total
       2. On Standby chassis: show srp checkpoint statistics | grep allocated

       Note	The count must be same for both chassis.

       ||||| Sx Service No of ||||| ID Restart ||||| | Recovery | Current Max Peer vvvvv v Group Name Node ID Peer ID Timestamp v Sessions Sessions State ----- ---- ----------------- ------------------------- ------------------- ------ --------- --------- -------- CAAXD 22 CPGROUP21 209.165.200.225 50331649 2021-03-17:02:33:55 0 0 0 NONE Total Peers: 1 

       Note	Peer state must be Active and associated. Peer ID must match on both the chassis.

       Note	"Number of Sessmgrs" must be equal to the "Sessmgrs in Standby-Connected state".

       1. srp validate-configuration : This CLI command initiates a configuration validation check in the Active chassis. If the validation doesn't have any error, the output of this CLI command is blank.
       2. srp validate-switchover : Validates if both Active and Standby chassis are ready for a planned SRP switchover. If the chassis is ready for switchover, then the output of this CLI command is blank.
       3. show srp info | grep "Last Validate Switchover Status" : Output of this CLI command must be as follows.

       Last Validate Switchover Status: Remote Chassis - Ready for Switchover

       1. Perform chassis Health Checks on both the nodes. Also check Step 1a and Step 1c under the Perform Switchover section. There can be a difference of 5%.
       2. Perform call testing since new sessions are serviced on the new Active chassis.
       3. Upgrade the old Active as mentioned in Step 2 through Step 5 under the Upgrade Procedure section.

       UPF Upgrade

       This section describes the procedure for UPF upgrade.

       1. Perform Health Check procedure on both the UPF nodes as mentioned in the Health Checks section.
       2. Perform Upgrade on Standby UPF as mentioned in the Build Upgrade section.
       3. Do "sx-peer configuration" on the upgraded Standby chassis.
       4. Perform Health Check on both the UPF nodes, and then do UPF switchover.
       5. Upgrade the new Standby UPF as mentioned in the Build Upgrade section.

       UPF Downgrade

       Perform the following steps to downgrade the UPF:

       1. Perform Health Check on the UPF.
       2. Change boot priority to the N-1 build on the Standby UPF. Reload the Standby UPF.
       3. Do "sx-peer configuration" on the downgraded Standby UPF.
       4. Perform Health Check on both the UPF nodes and then do UPF switchover.
       5. Perform Step 1 to Step 3 on the new Standby UPF.