目录

简介

先决条件

要求

使用的组件

背景信息

与CUPS环境的关联性

实验演示

简介

本文档介绍使用Gy进行配额管理的预付用户的控制和用户平面(CUPS UP)上的行为。

先决条件

要求

思科建议您了解 CUPS架构。

使用的组件

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

背景信息

此配置选项位于credit-control-group中：

credit-control-group xxx

pending-traffic-treatment quota-exhausted drop

在传统PGW/SAEGW中，此配置将导致该评级组的流量被丢弃：

- 当配额授予已用时，且新的配额请求正在处理中。

- 或者因为配额已完全耗尽（Final-Unit-Indication属性与Final-Unit-Action一起存在）在来自OCS服务器的最后一个CCA中。

与CUPS环境的关联性

在CUPS环境中，情况略有不同。UP上的流为：

1. 当配额已用完时，VPP会通知sessmgr-U，而sessmgr-U会从VPP查询使用情况。这里有个小延迟。

2. 在此期间，VPP不会丢弃流量。

3. Sessmgr-U发送会话报告以下类型的请求：使用情况报告.它包含以下信息：

- 使用情况报告触发器：卷配额

- 体积计量：总量/上行链路容量/下行链路容量

注意：卷可能高于授予的配额。这是因为vpp通知和sessmgr-U检索卷统计信息之间存在延迟。

4.收到新配额后，继续计数UP的流量（考虑到请求新配额时已发送的数据）。

5.每次配额更新都会发生相同的事件周期。

6.收到最终配额授权后，将发生以下情况：

- 在CP上，接收的CCA-U带有Final-Unit-Indication（和Final-Unit-Action）。

- CP会触发会话修改请求，该请求包含剩余配额以及新创建的FAR和操作DROP（由于“pending-traffic-treatment quota-expired drop”配置）

- 这向UP表明流量应在使用最终配额后丢弃。

实验演示

本实验测试将更详细地说明此行为：

OCS设置：

- 总配额：     5000000

- 配额授权：   500000

- 配额阈值：         0

高速下载测试。

在整个会话期间，报告的使用率始终高于来自UP的SX会话报告请求中的500000个八位组的配额授予。这是由于高速下载以及快速路径/sessmgr之间的延迟导致配额耗尽后获取更新的卷统计信息。如果在此期间吞吐量较高，则此差异会更大。

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

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

之后，UP上的所有流量都会被丢弃（CC已丢弃），在UP上可通过以下命令看到这一点：

[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

但是，为什么UP的最终使用情况报告中的数量测量值不会超过授权值？

CP在其最终配额授予中创建新的FAR，操作设置为drop，并且此操作绑定到URR。这指示VPP在最终授权使用后立即丢弃流量：

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

注意：CUPS UP上的这种行为不会导致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

注意：由于在OCS上配置了零的报价阈值，因此可以清楚地看到此行为。如果配置了非零配额阈值，则UP将在达到阈值时请求新的配额（在完全配额授权消耗之前）。