Gating Control Using Additional QER

The number of QERs per PDR supported in UPF is increased from two to three in this release.

All rules and filters are sent to UPF through PDRs. SMF sends an additional QER for dynamic rules installed on default QFI/bearer. The Gate Status IE indicates whether the gate is open or closed.

Default Setting: Not Applicable

Liveliness Check between UPF and RCM using Heartbeat Communication

The application-level heartbeat mechanism allows you to monitor the liveliness of the TCP connection between UPF and RCM. This feature will resolve the half-closed TCP connections between RCM checkpoint managers and UP session managers.

RCM sends a heartbeat message every 3 seconds. It checks if it has received the heartbeat message from UPF in the last 60 seconds. RCM will close the TCP connection if it has not received the message. This behavior is applicable for both Active UP to RCM and RCM to Standby UP communication.

UPF also behaves similarly where it sends a heartbeat message every 3 seconds. UPF checks if it has received the heartbeat from RCM in the last 60 seconds. If UPF has not received the message, then it will close the TCP connection.

The heartbeat functionality is configurable on RCM and UPF using the following commands:

• RCM—k8 smf profile rcm-config-ep enable-up-heartbeat { true | false } in Config mode

• UPF—up-sm-heartbeat { enable | disable } in Redundancy Configuration Module mode

The following show commands on RCM and UPF display the total number of heartbeat messages received and sent:

• RCM—rcm show-statistics checkpointmgr-endpointstats

• UPF—show rcm checkpoint statistics sessmgr all

Default Setting: Disabled – Configuration required to enable

Accurate Correlation of Application Instance IDs for Traffic Optimization

When you configure the adc app-notification once-per-app CLI in ACS Rulebase, UPF optimizes the reporting once per application. Upon detecting traffic for an application, UPF sends an APP-START notification to SMF with an Application Instance ID. This ID is the flow-id for the first data flow of an application.

Previous Behavior: When the last data flow of the application gets terminated, the flow-id of that data flow is used as the Application Instance ID in APP-STOP notification. This causes issues for PCF to correlate the APP-START and APP-STOP notifications.

New Behavior: UPF caches the Application Instance ID from the first data flow. When the last data flow of an application terminates, UPF sends the cached Instance ID with the APP-STOP notification. This behavior enables PCF to correlate the APP-START and APP-STOP notifications and identify the application traffic appropriately.

LCI Reporting to Control Plane

UPF sends the load control information (LCI) to the control plane, to inform the operating status of its resources at the node level. The control plane uses this information to augment UPF selection procedures.

Previous Behavior: UPF reported only one LCI per session manager to the control plane because of which some associated CPs did not receive the LCI.

New Behavior: UPF reports one LCI to each PFCP peer per session manager. The control plane will be able to distribute calls evenly over multiple UPFs.

• For cnSGW or legacy S-GW, LCI is reported only if the CP sends the load bit in the CP Function Features IE during Sx Association Setup or Update.

• By default, UPF enables LCI reporting to SMF. Hence, the load bit in CP Function Features IE is optional for SMF.

• The debug CLI show session subsystem facility sessmgr all debug-info displays the current and reported load metrics on UPF.

• Error logs will be generated when the load metric is reported to the control plane.

  The following is an example of an error log:

  2024-Mar-15+08:12:54.517 [sx 221333 info] [1/0/8083 <sessmgr:6> sx_fsm.c:1311] [context: EPC2-UP, contextID: 2] [software internal system critical-info syslog] LCI with load-metric = 19 and sequence-number = 1710489965 sent to Peer: 20.20.20.54

Customer Impact: Each CP that supports LCI reporting will now receive multiple messages with the same LCI value from a UPF.

Redirected Packet Drop Statistics

Previous Behavior: The drop counters were not incremented for redirected packets when the flow action redirect-url CLI was configured.

New Behavior: The drop counter is incremented for redirected packets with the flow action redirect-url configuration.

The new Redirect-URL field under Flow apply action in the output of the show user-plane-service statistics drop-counter command displays the number of redirected packets that are dropped.

Customer Impact: For each redirected packet, you can view the incremented packet drop counter.

SxDemux Stops IP Pool Deregistration Request towards VPNmgr on Standby UPF

Previous Behavior: After receiving the Sx peer delete checkpoint, SxDemux initiated the IP pool deregistration request towards VPNMgr on a standby UPF. This behavior led to IP chunk deletion resulting in call preallocation failure on a standby UPF.

New Behavior: SxDemux does not initiate the IP pool deregistration request towards VPNMgr on a standby UPF, after receiving the Sx peer delete checkpoint. This behavior prevents call preallocation failure on a standby UPF.