簡介
本檔案介紹使用Gy進行定額管理的預付訂戶的控制和使用者平面(CUPS UP)上的行為。
必要條件
需求
思科建議您瞭解 CUPS架構。
採用元件
本文件所述內容不限於特定軟體和硬體版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。
背景資訊
信用控制組中存在以下配置選項：
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會觸發一個會話修改請求，請求到UP，其中包含剩餘配額，以及新建立的FAR和操作DROP（由於「pending-traffic-treatment quota-expired drop」配置）
- 這向UP表示流量應在使用最終配額後丟棄。
實驗演示
本實驗測試詳細說明了此行為：
OCS設定：
- 總配額： 5000000
- 配額授權： 500000
- Quota-threshold: 0
高速下載測試。
在整個會話期間，報告的使用率始終高於來自UP的SX會話報告請求中的500000個八位元的配額授予率。這是由於高速下載以及fastpath/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將在達到閾值時請求新的配額（在完全配額授予消耗之前）。
意見