Einleitung
Dieses Dokument beschreibt das Verhalten auf einer Kontroll- und Benutzerebene (CUPS UP) für einen Prepaid-Teilnehmer, wobei Gy für die Quotenverwaltung verwendet wird.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse der CUPS-Architektur.
Verwendete Komponenten
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.
Hintergrundinformationen
Diese Konfigurationsoption ist in der Kreditsteuerungsgruppe vorhanden:
credit-control-group xxx
pending-traffic-treatment quota-exhausted drop
Bei einem älteren PGW/SAEGW würde diese Konfiguration dazu führen, dass der Datenverkehr für diese Bewertungsgruppe verworfen wird:
- Wenn die Quotengewährung verbraucht wurde und eine neue Quotenanfrage läuft.
- Oder weil das Kontingent im letzten CCA vom OCS-Server vollständig ausgeschöpft ist (Attribut "Final-Unit-Indication" ist mit "Final-Unit-Action" vorhanden).
Relevanz für die CUPS-Umgebung
In einer CUPS-Umgebung sieht die Situation etwas anders aus. Der Fluss auf dem UP ist:
- Wenn ein Kontingent für eine Bewertungsgruppe erschöpft ist, benachrichtigt VPP sessmgr-U, und sessmgr-U fragt die Nutzung von VPP ab. Hier gibt es eine kleine Verzögerung.
- Während dieser Zeit lässt VPP den Datenverkehr nicht fallen.
- Der Sessmgr-U sendet Sitzungsberichte mit der Anforderung des Typs: Nutzungsbericht. Sie enthält folgende Informationen:
- Auslösung des Nutzungsberichts: Mengenkontingent
- Volumenmessung: Gesamtvolumen/Uplink-Volumen/Downlink-Volumen
Anmerkung: Die Mengen können höher sein als das zugeteilte Kontingent. Dies liegt an der Verzögerung zwischen der vpp-Benachrichtigung und dem Abruf der Volume-Statistiken durch sessmgr-U.
4. Sobald das neue Kontingent empfangen wurde, wird der auf UP zählende Datenverkehr wieder aufgenommen (die Daten, die bereits gesendet wurden, während das neue Kontingent angefordert wurde, werden berücksichtigt).
5. Der gleiche Ereigniszyklus findet bei jeder Kontingentaktualisierung statt.
(6) Bei Erhalt der endgültigen Kontingentsbeihilfe geschieht Folgendes:
- Auf CP wird ein CCA-U mit Final-Unit-Indication (und Final-Unit-Action) empfangen.
- CP löst eine Anforderung zur Sitzungsänderung an UP aus, die das verbleibende Kontingent enthält, zusammen mit einem neu erstellten FAR mit Aktion DROP (aufgrund der Konfiguration 'ausstehender Verkehr - Behandlung - Kontingent - ausgeschöpfter Tropfen').
- Dies bedeutet für UP, dass der Datenverkehr bei Nutzung des endgültigen Kontingents verworfen werden soll.
Demo aus Labor
Dieser Labortest veranschaulicht dieses Verhalten genauer:
OCS-Einstellungen:
- Gesamtkontingent: 5000000
- Quotenzuschüsse: 500000
- Kontingentsschwellenwert: 0
Download-Test mit hoher Geschwindigkeit.
Während der Sitzung wird eine konsistent höhere Nutzung gemeldet als Quota-Vergabe von 500000 Oktetten in den Berichtsanforderungen der SX-Sitzung von UP. Dies liegt an der Hochgeschwindigkeits-Download in Kombination mit der Verzögerung zwischen fastpath/sessmgr, um die aktualisierten Volume-Statistiken bei Quotenerschöpfung zu erhalten. Dieser Unterschied ist größer, wenn der Durchsatz in dieser Zeit höher ist.
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
Der endgültige Zuschuss der 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
Anschließend wird der gesamte Datenverkehr auf UP verworfen (da CC verworfen wird), wie dies auf UP mit dem folgenden Befehl zu sehen ist:
[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
Warum aber überschreiten die Volumenmessungen im endgültigen Nutzungsbericht von UP nicht den Zuschuss?
Die KP erstellt in ihrem endgültigen Quotenzuschuss eine neue FAR mit einzustellenden Maßnahmen, die an die URR gebunden sind. Dadurch wird VPP angewiesen, Datenverkehr unmittelbar nach der letzten Gewährung zu verwerfen:
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
Anmerkung: Dieses Verhalten bei CUPS UP führt nicht zu einer Überbelegung von Kontingenten, wie auf dem CP zu sehen ist.
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
Anmerkung: Dieses Verhalten wird deutlich, da auf dem OCS ein Kostenvoranschlag-Grenzwert von Null konfiguriert wurde. Wenn ein Schwellenwert konfiguriert ist, der nicht 0 (null) ist, fordert UP ein neues Kontingent an, wenn der Schwellenwert erreicht ist (bevor die gesamte Kontingentzuteilung verwendet wird).
Feedback