Downlink Data Notification

Feature Summary and Revision History

Summary Data


Applicable Product(s) or Functional Area	5G-UPF
Applicable Platform(s)	VPC-SI SMI
Feature Default Setting	Disabled – Configuration Required
Related Changes in this Release	Not Applicable
Related Documentation	UCC 5G UPF Configuration and Administration Guide

Revision History


Revision Details	Release
First introduced.	2021.02.0

Feature Description

The Downlink Data Notification (DDN) messages with support for DDN Delay and DDN Throttling, and buffering in SAEGW when UE is in Idle State, is supported in 5G-UPF.

How It Works

This section provides an overview of how this feature works.

Buffering is supported at SAEGW-U.
Support of buffering starts when UE moves to IDLE state due to Release Access Bearer.
ACTIVE to IDLE transition:
- When the UE moves to ECM-IDLE state, since the SAEGW supports buffering capability and decides to activate buffering in SAEGW-U for the session, the SAEGW-C informs the SAEGW-U through an Sx session modification.
- After the buffering starts, when the first downlink packet arrives on any bearer, the SAEGW-U informs the SAEGW-C. The SAEGW-U sends an Sx reporting message to the SAEGW-C, unless specified otherwise, and identifies the S5/S8 bearer on which the downlink packet is received.
- On receiving the reporting message, the SAEGW-C decides whether to send a DDN message to the MME, as defined in 3GPP TS 23.401 [2]. The DDN notification is sent with the Sx-Usage-Report.
IDLE to ACTIVE transition:
- At the UE transition to ECM-CONNECTED state, the SAEGW-C updates the SAEGW-U through Sxa interface with the F-TEIDu of the eNodeB/RNC/SGSN. The buffered data packets, if any, are then forwarded to the eNodeB/RNC/SGSN by the SAEGW-U.
If the Apply Action is BUFFER, and SGW-U recovers, the SGW-U initiates Sx Report (with DLDR Report Type) on arrival of the downlink data packet.
In SGW-U, a timer is implemented that starts after each Sx Report (with DLDR report Type) is sent. If the Apply Action is not changed, then on timer expiry, Sx Report (with DLDR Report Type) gets initiated again.
ARP of the bearer is included in the DDN message.
In a multi-PDN session, if the DDN is initiated for one PDN and then data is received on another PDN, wherein the bearer has higher priority, then the DDN is initiated again with the higher priority ARP value.

Downlink Data Notification – Delay (DDN-D) Support

Under certain conditions, when UE triggers a service request, uplink and downlink data is triggered and is received at the SGW-C even before the Modify Bearer Request (MBR) is received causing unnecessary Downlink Packet Notification messages sent that increases the load in MME.

In such cases, the MME monitors the rate at which these events occur. If the rate becomes significant (as configured by the operator) and the MME's load exceeds an operator-configured value, the MME indicates "Delay Downlink Packet Notification Request" with parameter D to the Serving Gateway, where D is the requested delay given as an integer with multiples of 50 milliseconds, or zero. The S-GW then uses this delay in between receiving downlink data and sending the Downlink Data Notification message.

The Downlink Data Notifications are supported for both Collapsed and Pure-S calls.

Due to the distributed nature of the system, sessions from a particular MME are offloaded on different session managers. Therefore, all session managers are notified when a session is offloaded. Also, the functionality is designed to not allow all session managers to message the DEMUX manager.

In DDN Delay feature, DDN delay timer support is at Session Management Function.
When first data packet arrives, Sx/N4 Report message is initiated but DDN message is initiated from Session Management Function after the expiry of Delay timer.
DDN Delay feature is a peer level feature and so, it is applied for all the session on that peer from where the DDN Delay value is received.
In case a previous delay value was received from a peer and it is absent in the current message, the delay value will be considered as 0.

Session Recovery and ICSR is supported for DDNs.

5G SMF Calls

Downlink Data Notification - 5G UE

When UE turns to Idle state in the 5G call mode, SMF sends Sx_Modify_Request with FAR Apply Action set to BUFFER value. For every QFI (default/dedicated), the FAR Apply Action is set to BUFFER value.

Once the Downlink packet is received from the server, UPF sends the Sx_Report_Request with Downlink Data Notification with Rule Id (PDR Id)/QFI as per packet rulematch. UPF continues buffering packets until the packet limit reaches 5 for every FAR.

When UE is active, Sx_Modify_Request reaches UPF with FAR Apply Action set to FWD (Forward) and TEID (Tunnel Endpoint Identifier). UPF debuffers the packets and sends them to UE as FIFO. For each packet, rule match will take place after the debuffering process.

DDN Throttling Support

Too many DDN requests toward MME from SGW-C could lead to processing overload at MME. To reduce this load, MME dynamically requests SGW-C to reduce a certain percentage of DDN messages sent toward it for a given period time.

For DDN throttling, S-GW is required to drop a given percentage of DDNs over a given period of time. S-GW implements this functionality using a probabilistic algorithm at each session manager.

Whereas the conventional implementation of DDN throttling requires each session manager to share its list of pending DDNs for low-priority bearers with a central entity that would then calculate the net load of pending DDNs and then decide how many DDNs each session manager would have to drop. This implementation would require buffering of DDN messages at session manager. Also, due to distributed processing nature of software subsystem in chassis, it would require considerable amount of messaging between the session managers and the central entity (demuxmgr in case of Boxer) at regular intervals.

Implementing a probabilistic algorithm removes the need for buffering at session manager and also messaging with demuxmgr. Accuracy of probabilistic algorithm increase with increasing low ARP priority paging load at session manager. Even with lower paging load, accuracy would be fairly close to the throttling factor provided.

For non-release 10 compliant MME, SGW_C provides option to enable throttling through the CLI.

Threshold ARP values for low-priority bearer must be configured through S-GW Service Configuration. For example, if configured ARP value is 9, any bearer with ARP > 9 is considered low-priority bearer. DDN throttling is enabled through this configuration. If DDN throttling is enabled through SGW service configuration, each DDN message toward MME would contain the ARP IE.

No User Connect Timer Support

Timer is introduced when a Modify Bearer Request is not received after positive Downlink Data Notification acknowledgment.
It is initiated at SGW-C when DDN acknowledgment is received.
On arrival of Modify Bearer Request, SGW-C stops this timer.
On timer expiry SGW-C informs SGW-U to drop buffered packets.

DDN Call Flows

DDN Success Scenario

MME sends Release Access Bearer request to SGW-C to release downlink remote TEIDs of all the bearers for that UE.
On arrival of Release Access Bearer request, SGW-C informs the same to SGW-U by updating FAR with Apply Action as BUFFER in Sx Modification Request for all the PDNs.
SGW-U send Sx Modification response after applying Buffering in SGW-U for corresponding PDN.
SGW-C sends Release Access Bearer response to MME.
First Downlink data arriving in SGW-U triggers Sx Report Request (with Report Type as Downlink Data Report) towards SGW-C.
On arrival of Sx Report Request message, the SGW-C initiates Downlink Data Notification request message towards MME.
SGW-C sends Sx Report Response message towards SGW-U.
If MME is able to send a paging request towards UE, it sets the cause as “Request Accepted” in Downlink Data Notification Acknowledgment Message and sends it to SGW-C.
On successful paging, MME sends a Modify Bearer request to the S-GW with eNodeB TEIDs that sets up the S1-U connection at the SGW.
SGW-C sends Sx Modification request with updated FAR for new TEID information to SGW-U. SGW-U can now forward all the buffered data to UE through eNodeB.
SGW-U sends Sx Modification response to SGW-C.

DDN Failure Scenario

MME sends Release Access Bearer request to SGW-C to release downlink remote TEIDs of all the bearers for that UE.
On arrival of Release Access Bearer request, SGW-C informs the same to SGW-U by updating FAR with Apply Action as BUFFER in Sx Modification Request for all the PDNs.
SGW-U send Sx Modification response after applying Buffering in SGW-U for corresponding PDN.
SGW-C sends Release Access Bearer response to MME.
First Downlink data arriving in SGW-U triggers Sx Report Request (with Report Type as Downlink Data Report) toward SGW-C.
On arrival of Sx Report Request message, the SGW-C initiates Downlink Data Notification request message toward MME.
SGW-C sends Sx Report Response message toward SGW-U.
If MME is not able to page UE then it can reject Downlink Data Notification Request with relevant cause.

OR

If MME accepts Downlink Data Notification Request. But later sends Downlink Data Notification Failure indication in order to indicate SGW-C that the UE did not respond to paging.
SGW-C received DDN failure and hence to stop sending next DDN immediately , SGW-C starts DDN Failure Timer. SGW-C sends Sx Modification Request with DROBU flag to discard buffered packets and Apply Action as DROP to drop subsequent packets.
SGW-U sends Sx Modification Response to SGW-C.
On DDN Failure Timer Expiry SGW-C initiates Sx Modification with Apply Action as BUFFER in order to start buffering again.

Further steps are continued from Step 3 in the DDN Success Scenario call flow.

No User Connect Timer Support

MME sends Release Access Bearer request to SGW-C to release downlink remote TEIDs of all the bearers for that UE.
On arrival of Release Access Bearer request, SGW-C informs the same to SGW-U by updating FAR with Apply Action as BUFFER in Sx Modification Request for all the PDNs.
SGW-U send Sx Modification response after applying Buffering in SGW-U for corresponding PDN.
SGW-C sends Release Access Bearer response to MME.
First Downlink data arriving in SGW-U triggers Sx Report Request (with Report Type as Downlink Data Report) towards SGW-C.
On arrival of Sx Report Request message, the SGW-C initiates Downlink Data Notification request message towards MME.
SGW-C sends Sx Report Response message towards SGW-U.
Downlink Data Notification Acknowledgment is received from MME.SGW-C starts no-user-connect timer.
If the Modify Bearer request with eNodeB TEID information is not received and no-user-connect timer expires, SGW-C sends Downlink Data Notification again.
Downlink Data Notification Acknowledgment is received from MME. SGW-C initiates the no-user-connect timer again.
SGW-C initiates Sx Session Modification request towards SGW-U with DROBU flag set in the message. On receiving this flag SGW-U drops the buffered data. New data will be buffered, and the subsequent first packet initiates a Sx Report message for initiating Downlink Data Notification message.
SGW-U sends Sx Modification Response.

DDN Delay Timer

MME sends Release Access Bearer request to SGW-C to release downlink remote TEIDs of all the bearers for that UE.
On arrival of Release Access Bearer request, SGW-C informs the same to SGW-U by updating FAR with Apply Action as BUFFER in Sx Modification Request for all the PDNs.
SGW-U send Sx Modification response after applying Buffering in SGW-U for corresponding PDN.
SGW-C sends Release Access Bearer response to MME.
First Downlink data arriving in SGW-U triggers Sx Report Request (with Report Type as Downlink Data Report) towards SGW-C.
On arrival of Sx Report Request message, the SGW-C initiates Downlink Data Notification request message towards MME.
SGW-C sends Sx Report Response message towards SGW-U.
Downlink Data Notification Acknowledgment is received from MME with DDN Delay Timer value. This timer value will be saved for this peer , and now onwards every Downlink Data notification that we initiate should be after this delay for that peer.
On success paging, MME sends a Modify bearer request to the SGW with eNodeB TEIDs that sets up the S1-U connection at the SGW.
SGW-C sends Sx Modification Request with updated FAR for new TEID information to SGW-U. SGW-U can now forward all the buffered data to UE via eNodeB.
SGW-C sends Modify Bearer Response to MME.
SGW-U sends Sx Modification Response to SGW-C.
MME sends Release Access Bearer Request to SGW-C to release downlink remote TEIDs of all the bearers for that UE.
On arrival of Release Access Bearer Request, SGW-C inform the same to SGW-U via updating FAR with Apply Action as BUFFER in Sx Modification Request for all the PDNs.
SGW-U send Sx Modification Response after applying Buffering in SGW-U for corresponding PDN.
SGW-C sends Release Access Bearer Response to MME.
First Downlink data arriving in SGW-U triggers Sx Report Request (with Report Type as Downlink Data Report) towards SGW-C.
On arrival of Sx Report Request message, SGW-C starts DDN Delay Timer. On DDN Delay timer expiry SGW-C Initiates Downlink Data Notification message towards MME.

Sx Interface

Sx Session Level Reporting Procedure

Detection of first Downlink Data for Idle-Mode UE (by SAEGW-U):

When SAEGW-U receives the downlink packet but no S1-bearer for transmission and the buffering is performed by SAEGW-U, it reports the detection of first downlink data to SAEGW-C, for the purpose of paging the UE.

PFCP Session Report Request

The PFCP Session Report Request is sent over the Sxab interface by the User Plane function to report information related to a PFCP session to the Control Plane function.


Information elements	P	Condition / Comment	Appl.				IE Type
Information elements	P	Condition / Comment	Sxa	Sxb	Sxc	N4	IE Type
Report Type	M	This IE shall indicate the type of the report.	X	X	X	X	Report Type
Downlink Data Report	C	This IE shall be present if the Report Type indicates a Downlink Data Report.	X	-	-	X	Downlink Data Report

Downlink Data Report IE within PFCP Session Report Request

The Downlink Data Report grouped IE is encoded as shown in the following table.


Octet 1 and 2		Downlink Data Report IE Type = 83 (decimal)
Octets 3 and 4		Length = n
Information elements	P	Condition / Comment	Appl.				IE Type
			Sxa	Sxb	Sxc	N4
PDR ID	M	This IE shall identify the PDR for which downlink data packets have been received at the UP function. More than one IE with this type may be included to represent multiple PDRs having received downlink data packets.	X	-	-	X	PDR ID

Notification to User Plane Function for DDN Failure

The Control Plane function notifies User Plane function for any failure so that buffered packets can be dropped and DDN related flags can be reset through DROBU flag in PFCP Sx Modification message.


PFCPSMReq-Flags	C	DROBU (Drop Buffered Packets): The CP function shall set this flag if the UP function is requested to drop the packets currently buffered for this PFCP session (see NOTE 1).

Limitations

Following are the known limitations of this feature:

SAEGW Buffering is done for five data packets per PDN session.
DDN profile configuration is not supported.
Support for buffered data (data packet stream) that get deleted due to Flow Idle Timeout or other cases, is not present.

DDN Throttling for non-Release 10 Compliant MME

Use the following configuration to configure DDN throttling for a non-release 10 MME:

configure 
   context context_name 
      sgw-service service_name 
         ddn throttle arp-watermark arp_value [ rate-limit limit time-factor seconds throttle-factor percent increment-factor percent [ poll-interval seconds ] throttle-time-sec seconds [ throttle-time-min minutes ] [ throttle-time-hour hour ] stab-time-sec seconds [ stab-time-min minutes ] [ stab-time-hour hour ] 
         no ddn throttle 
         end

NOTES:

rate-limit : DDN permitted per second.
time-factor : Time period in seconds over which SGW makes throttling decision (valid range 1-300 seconds).
arp-value : Valid ARP value between 1 and 15. All the packets which have ARP greater than the configured values are throttled as per the throttling factor.
throttling-factor : Percentage of DDN to be dropped upon detecting DDN surge (valid range between 1-100).
throttling-time-sec : Time period in seconds over which DDN is throttled at SGW (valid range between 0-59 seconds).
throttling-time-min : Time period in minutes over which DDN is throttled at SGW (valid range between 0-59 minutes).
throttling-time-hour : Time period in hours over which DDN is throttled at SGW (valid range between 0-310 hours).
increment-factor : Percentage value by which throttling factor is incremented dynamically, if existing throttling factor is insufficient to curb the DDN surge.
poll-interval : Time in seconds (optional argument, default value = 1 second, poll interval < time-factor)
stab-time-sec/min/hours : Stabilization time factor, time period over which if DDN rate returns to normal, then throttling need not be applied over the entire throttling time period.

DDN throttling for non-Release-10 compliant MME makes use of existing Release-10 throttling implementation at SGW. By providing a configuration mechanism for SGW service, operator can still apply ddn throttling without needing any feedback from MME. Some salient points of this feature are described below:

The CLI configuration is applied per MME/S4-SGSN. Throttling parameters are tracked independently per MME/S4-SGSN.
On configuring this feature through CLI, demuxmgr polls each sessmgr for number of DDNs sent. By default, polling is done every second. This time interval can be changed by configuring the poll-interval time. Greater the poll interval time, lesser the number of internal messages within the chassis. However, it would take longer to detect a DDN surge.
By configuring time-factor, operator can specify the time interval for S-GW to apply throttling, if needed. It allows for some surge of DDNs if the net DDN rate is within specified limit over time-factor time interval. For example, time-factor= 10 seconds, ddn rate = 1000, poll interval = 2 seconds. Demux would poll each sessmgr every 2 seconds. Acceptable DDN rate limit is 1000*10 = 10000 DDNs every 10 seconds. Say after 2 seconds, 4000 DDNs were sent, in that case S-GW wouldn’t apply throttling until rate limit of 10000 DDNs is crossed within time period of 10 seconds. This allows for intermittent bursts of DDNs.
DDN rate limit is configured through CLI. For example, if DDN rate limit is 1000 and poll interval = 1 second, time-factor = 5 seconds, then acceptable rate limit is 5000 DDNs over 5 seconds. If the number of DDNs sent by S-GW is greater than 5000 after 5 seconds, demuxmgr would ask all sessmgrs to initiate throttling.
Percentage of DDNs to be throttled is configured through throttling-factor.
Operator can specify increment-factor to increment throttling factor if the existing throttling factor is insufficient to curb the DDN surge. For example, if throttling-factor = 10%, ddn-rate = 1000, increment-factor=10%. Once throttling is applied, S-GW drops ~10% DDNs. However, if DDN rate is still greater than 1000, S-GW would increase throttling-factor to 20%. If this is still not sufficient, it would be incremented to 30%. After incrementing throttling factor, if number of DDNs dropped are greater than expected, throttling-factor would then be decrement by increment-factor. For example, in this case, after increasing throttling factor to 30%, if DDNs sent is less than 1000 per second (taking time-factor and poll-interval into consideration), throttling factor would be decremented to 20. The cap for decrementing throttling-factor would be the configured value (10% in this case).
Operator can configure the time duration for which throttling is applicable at S-GW. This could be a large value in order of days (for example: 10 days or 240 hours). The operator has an option to stop throttling if DDN rate is well under control by configuring stabilization time factor. In such a case, DDNs won’t be needlessly dropped. For example, throttling-time =10 days, stab-time = 8 hours. After S-GW starts DDN throttling, in a time span of 8 hours, DDNs sent + DDNs dropped < ddn-rate * 8 hours, throttling would be stopped.

DDN Throttling for Release 10 Compliant MME

DDN throttling is enabled through Call Control Profile by providing the ARP value. For example, if the ARP value provided is 10, then all bearers with ARP value between 10-15 are treated as low priority bearers and are given throttling treatment. Throttling would not be enabled if ARP value is not provided through S-GW service configuration. Also, ARP IE in DDN message towards MME would not be included unless DDN throttling is configured using S-GW service. If MME is Release 10 compliant, the user need not configure the duration value as the DDN Acknowledgment would have the throttling IE. Otherwise, throttling can be enabled at S-GW by setting the duration value. If it’s set to 0, S-GW would apply throttling recurringly. To enable throttling only for a given duration of time (in non Rel-10 compliant MME), user needs to set the value in hours and minutes. From the time of configuration, throttling would be applied at S-GW until the timer duration expires. For example, if user sets hours = 10, minutes = 30, S-GW would apply throttling for next 10 hours 30 minutes.

On re-configuration, all the parameters will be set with new values, but they will be applicable only from the next recalibration except from polling time and time factor.

Use the following configuration to configure DDN throttling for release 10 MME:

configure 
   context context_name 
      sgw-service service_name 
         [ no ] ddn throttle arp-watermark arp_value 
         end

NOTES:

arp-value: Valid ARP value between 1 and 15. All the packets which have ARP greater than the configured values will be throttled as per the throttling factor.

Idle Timer for SAE-GW Sessions

An Idle Timer is supported to identify and remove idle sessions that occur in the SAE-GW.

A session becomes idle in some cases where the session is removed from other network nodes, but due to a technical mishap the session could still remain on the SAE-GW leading to resources being held by these idle sessions.

The Idle Timer, once configured, removes those sessions that remain idle for longer than the configured time limit effectively utilizing the system capacity.

Important

This feature is currently restricted to Pure-P and Collapsed Call.

Limitations

The Idle Timer feature does not support recovery of Idle Timer in case of redundancy events.

Configuring Idle Timer for SAE-GW Sessions

The Idle Timer is configurable at APN level.

Use the following commands to configure the idle timer for SAE-GW sessions:

configure 
   context context_name 
      apn apn_name 
         timeout idle timeout_value 
         no timeout idle 
         default timeout idle 
         end

no : Disables the idle timer configuration.
default : Configures the default value for subscriber’s time out settings. The default idle timeout value is 0.
idle timeout_value : Designates the maximum duration a session can remain idle, in seconds, before system automatically terminates the session. Must be followed by number of seconds between 0 and 4294967295. Zero indicates function is disabled.

S-GW Session Idle Timeout

This chapter describes the Idle Timeout Handling feature for S-GW sessions. On the ASR5500 platform, subscriber session is represented by call-line. The S-GW product call-line interfaces to its peers through MME/S4-SGSN on S11/S4 and P-GW on S5/S8. In some scenarios, peer sessions are deleted by respective peers, S-GW does not receive or miss deletion messages, and as a result S-GW session remains idle. Such idle or stale sessions are counted toward valid call-lines in system for effectively consuming resources and causing capacity reduction. In such cases, S-GW triggers to get the new subscriber session, which results in the removal of old session for same subscriber. The Idle Timeout Handling support enables the identification of such sessions and initiates deletion to release the resources.

The following points describe the idle timeout handling for S-GW sessions:

The subscriber session is idle when there is no data traffic activity for the subscriber. The session manager keeps track of the call-line state, when no data traffic is recorded for call-line, such sessions are moved to idle state.
Session which is idle for defined timeframe referred as idle timeout is considered for idle timeout handling. In idle timeout session, S-GW initiates the deletion of session toward its peers.
Idle timeout is configured in seconds depending on the network requirements. The timeout range is 1-4294967295 seconds.
The idle timeout configuration is applicable on S-GW service level for enabling the idle timeout handling for set of subscribers handled by that service.

Configuring Session Idle Timeout

The session idle timer for S-GW sessions is configurable from S-GW service.

To configure Session Idle Timeout for S-GW, use the following configuration:


configure 
   context context_name 
      sgw-service service_name 
         [ no | default] timeout idle timeout_duration 
         end

NOTES:

timeout idle timeout_duration : Specifies the maximum duration a session can remain idle for, in seconds, before the system automatically terminates the session. timeout_duration must be an integer in the range of 1-4294967295. 0 disables the feature. By default, it is disabled for the S-GW service.

Show Commands Input and/or Outputs

This section provides information regarding show commands and their outputs in support of the feature.

show subscribers user-plane-only full all

The output of this command displays the following fields in support of this feature:

buffered pkts
buffered bytes
buffer overflow drop pkts
buffer overflow drop bytes

show subscribers user-plane-only full callid <call_id>

Use the following configuration to check the buffering per subscriber:

DDN buffered packets
DDN buffered bytes
DDN buffer overflow drop packets
DDN buffer overflow drop bytes

When the buffered packets are debuffered the state changes back to zero.

Each time the packet limit reaches 5, the additional packets get dropped as overflow drops.

UCC 5G UPF Configuration and Administration Guide, Release 2024.03

Bias-Free Language

Book Title

UCC 5G UPF Configuration and Administration Guide, Release 2024.03

Chapter Title

Downlink Data Notification

Results

Chapter: Downlink Data Notification

Downlink Data Notification

Feature Summary and Revision History

Summary Data

Revision History

Feature Description

How It Works

Downlink Data Notification – Delay (DDN-D) Support

5G SMF Calls

Downlink Data Notification - 5G UE

DDN Throttling Support

No User Connect Timer Support

DDN Call Flows

DDN Success Scenario

DDN Failure Scenario

No User Connect Timer Support

DDN Delay Timer

Sx Interface

Sx Session Level Reporting Procedure

Limitations

DDN Throttling for non-Release 10 Compliant MME

DDN Throttling for Release 10 Compliant MME

Idle Timer for SAE-GW Sessions

Limitations

Configuring Idle Timer for SAE-GW Sessions

S-GW Session Idle Timeout

Configuring Session Idle Timeout

Show Commands Input and/or Outputs

show subscribers user-plane-only full all

show subscribers user-plane-only full callid <call_id>

Was this Document Helpful?

Contact Cisco