Contents

Introduction

Prerequisites

Requirements

Components Used

Background Information

Relevance to CUPS Environment

Demonstration from Lab

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:

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

2. VPP does not drop the traffic during this time.

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