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 Control Plane.

• When first data packet arrives, Sx Report message is initiated but DDN message is initiated from Control Plane 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.

Too many DDN requests towards 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 towards 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 towards MME would contain the ARP IE.

• 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.

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.

Downlink Data Report IE within PFCP Session Report Request

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

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.

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 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.

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 will be 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 are throttled at SGW (valid range between 0-59 seconds).

• throttling-time-min : Time period in minutes over which DDN are throttled at SGW (valid range between 0-59 minutes).

• throttling-time-hour : Time period in hours over which DDN are 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 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:

1. The CLI configuration is applied per MME/S4-SGSN. Throttling parameters are tracked independently per MME/S4-SGSN.

2. 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.

3. 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 till rate limit of 10000 DDNs is crossed within time period of 10 seconds. This allows for intermittent bursts of DDNs.

4. 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.

5. Percentage of DDNs to be throttled is configured through throttling-factor.

6. Operator can specify increment-factor to increment throttling factor if 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. E.g. 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).

7. 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.

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