PDF(10.8 KB) View with Adobe Reader on a variety of devices
ePub(90.2 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(79.1 KB) View on Kindle device or Kindle app on multiple devices
Updated:August 21, 2021
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.
This document describes the behavior on a Control and User Plane (CUPS UP) for a prepaid subscriber where Gy is used for quota management.
Cisco recommends that you have knowledge of the CUPS architecture.
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
This configuration option is present in the credit-control-group:
credit-control-group xxx pending-traffic-treatment quota-exhausted drop
In legacy PGW/SAEGW, this configuration would cause traffic to be dropped for that rating group:
When quota grant is consumed, and a new quota request is in progress.
Or because the quota is fully consumed (Final-Unit-Indication attribute is present with Final-Unit-Action) in the last CCA from the OCS server.
Relevance to CUPS Environment
In a CUPS environment, the situation is a bit different. The flow on the UP is:
When a quota is exhausted for a rating group, VPP notifies sessmgr-U, and sessmgr-U queries the usage from VPP. There is a minor delay here.
VPP does not drop the traffic during this time.
The Sessmgr-U sends a session reports the request of type: usage report. It contains this information:
usage report trigger: volume quota
volume measurement: total volume/uplink volume/downlink volume
Note: The volumes might be higher than the granted quota. This is due to the delay between the vpp notification and sessmgr-U retrieving the volume stats.
4. Once the new quota is received, the traffic counting on UP is resumed (take into account the data that is already sent while the new quota was being requested).
5. The same cycle of events happens for every quota refresh.
6. When the final quota grant is received, the following happens:
On CP a CCA-U is received with Final-Unit-Indication (and Final-Unit-Action).
CP triggers a session modification request to UP that contains the remaining quota, along with a newly created FAR with action DROP (due to the 'pending-traffic-treatment quota-exhausted drop' configuration)
This indicates to UP that traffic should be dropped upon consumption of the final quota.
Demonstration from Lab
This lab test illustrates this behavior in more detail:
Total quota: 5000000
Quota grants: 500000
High-speed download test.
Throughout the session, consistently higher usage is reported than quota grant of 500000 octets in the SX session report requests from UP. This is due to the high-speed download in combination with the delay between fastpath/sessmgr to get the updated volume stats upon quota exhaustion. This difference is higher when throughput is higher during this time.
Note: This behavior is clearly seen because a quote threshold of zero was configured on the OCS. If a non-zero quota threshold is configured, the UP would request a new quota when the threshold is hit (before full quota grant consumption).