CUPS UP - Gy Behavior, wenn "pending-traffic-treatment quota-ausgelaugt drop" konfiguriert ist

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