Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Relevanz für die CUPS-Umgebung

Demo aus Labor

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:

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

2. Während dieser Zeit lässt VPP den Datenverkehr nicht fallen.

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