简介
本文档介绍使用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上的流为：
- 当配额已用完时，VPP会通知sessmgr-U，而sessmgr-U会从VPP查询使用情况。这里有个小延迟。
- 在此期间，VPP不会丢弃流量。
- 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将在达到阈值时请求新的配额（在完全配额授权消耗之前）。
反馈