Introduction
This document describes the behavior on a Control and User Plane (CUPS UP) for a prepaid subscriber where Gy is used for quota management.
Prerequisites
Requirements
Cisco recommends that you have knowledge of the CUPS architecture.
Components Used
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.
Background Information
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:
OCS settings:
- Total quota: 5000000
- Quota grants: 500000
- Quota-threshold: 0
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.
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 792288
Uplink Volume: 155652
Downlink Volume: 636636
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 533220
Uplink Volume: 143376
Downlink Volume: 389844
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 682584
Uplink Volume: 332724
Downlink Volume: 349860
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 514380
Uplink Volume: 247620
Downlink Volume: 266760
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 519792
Uplink Volume: 209916
Downlink Volume: 309876
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 539508
Uplink Volume: 249624
Downlink Volume: 289884
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 690876
Uplink Volume: 341292
Downlink Volume: 349584
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 586632
Uplink Volume: 286176
Downlink Volume: 300456
The final grant from OCS:
SEID: 0x0018000000000003, Message type: SX_SESSION_MODIFICATION_REQUEST (0x34)
Total Volume: 140720
Uplink Volume: 70360
Downlink Volume: 70360
SEID: 0x0004000000000000, Message type: SX_SESSION_REPORT_REQUEST (0x38)
VOLUME MEASUREMENT:
Total Volume: 141372
Uplink Volume: 75684
Downlink Volume: 65688
Afterwards, all traffic on UP is dropped (as CC dropped) as can be seen on UP with this command:
[local]saegw-up1# show subs user-plane-only full all
CC Dropped Uplink Pkts: 2583 CC Dropped Downlink Pkts: 2551
CC Dropped Uplink bytes: 3687672 CC Dropped Downlink Bytes: 3642828
But, why are the volume measurements in the final usage report from UP not exceeding the grant?
The CP, in its final quota grant, creates a new FAR with action set to drop, and this is bound to the URR. This instructs VPP to drop traffic immediately after the final grant is consumed:
Wednesday March 10 2021
<<<<OUTBOUND 01:29:16:551 Eventid:221302(3)
[C-PLANE]PFCP Tx PDU, from 10.1.50.1:50007 to 10.1.50.3:8805 (163)
SEID: 0x0018000000000002, Message type: SX_SESSION_MODIFICATION_REQUEST (0x34)
Sequence Number: 0x00150B (5387)
…
INFORMATION ELEMENTS
CREATE FAR:
Type: 3
Value:
FAR ID:
Type: 108
Value: 0x0005
APPLY ACTION:
Type: 44
Value:
DROP: 1
FORW: 0
BUFF: 0
NOCP: 0
DUPL: 0
UPDATE URR:
Type: 13
Value:
URR ID:
Type: 81
Value: 0x80000027
MEASUREMENT METHOD:
Type: 62
Event: 0
Volume: 1
Duration: 1
REPORTING TRIGGERS:
Type: 37
Volume Quota: 1
Time Quota: 1
Envelope Closure: 0
Periodic Reporting: 0
Volume Threshold: 0
Time Threshold: 0
Quota Holding Time: 0
Start of Traffic: 0
Stop of Traffic: 0
Dropped DL Traffic Threshold: 0
Linked Usage Reporting: 0
VOLUME QUOTA:
Type: 73
Total Volume: 140720
Uplink Volume: 70360
Downlink Volume: 70360
TIME QUOTA:
Type: 74
Value: 1000
FAR ID:
Type: 108
Value: 0x0005
Note: This behavior on CUPS UP does not lead to overconsumption of quota as can be seen on the CP.
CP# show active-charging session full
…
Rating-Group: 100
Service-Identifier: 0
State: Final Unit
Checkpoint State: Current
Pending Update: No
Last Answer: 0h00m49s
Final-Unit-Action: Terminate
Quota Usage Total Usage
------------------ ------------- ------------- -------------
CC-Time: - 0 10
CC-Total-Octets: - 0 5000652
CC-Input-Octets: - 0 2042064
CC-Output-Octets: - 0 2958588
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).
Feedback