Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Informations générales

Pertinence pour l'environnement CUPS

Démonstration du laboratoire

Introduction

Ce document décrit le comportement sur un plan de contrôle et d'utilisateur (CUPS UP) pour un abonné prépayé où Gy est utilisé pour la gestion des quotas.

Conditions préalables

Conditions requises

Cisco vous recommande de connaître les Architecture CUPS.

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Cette option de configuration est présente dans le groupe de contrôle de crédit :

credit-control-group xxx

pending-traffic-treatment quota-exhausted drop

Dans les anciens PGW/SAEGW, cette configuration entraînerait l'abandon du trafic pour ce groupe de classification :

- Lorsque l'allocation de quota est utilisée et qu'une nouvelle demande de quota est en cours.

- Ou parce que le quota est entièrement consommé (l'attribut Final-Unit-Indication est présent avec Final-Unit-Action) dans le dernier CCA du serveur OCS.

Pertinence pour l'environnement CUPS

Dans un environnement CUPS, la situation est un peu différente. Le flux sur l'UP est :

1. Lorsqu'un quota est épuisé pour un groupe d'évaluation, VPP avertit sessmgr-U et ce dernier interroge l'utilisation à partir de VPP. Il y a un léger retard ici.

2. VPP ne supprime pas le trafic pendant ce temps.

3. Le Sessmgr-U envoie une session qui signale la requête de type : rapport d'utilisation. Il contient les informations suivantes :

- déclencheur de rapport d'utilisation : quota de volume

- mesure du volume : volume total/volume de liaison montante/volume de liaison descendante

Note: Les volumes peuvent être supérieurs au quota accordé. Cela est dû au délai entre la notification vpp et la récupération par sessmgr-U de l'état du volume.

4. Une fois le nouveau quota reçu, le trafic comptant sur UP est repris (prenez en compte les données déjà envoyées lors de la demande du nouveau quota).

5. Le même cycle d’événements se produit pour chaque actualisation de quota.

6. À la réception de l'allocation de quota finale, les situations suivantes se présentent :

- Sur le PC, un CCA-U est reçu avec une indication d'unité finale (et une action d'unité finale).

- CP déclenche une demande de modification de session vers UP qui contient le quota restant, ainsi qu'un FAR nouvellement créé avec l'action DROP (en raison de la configuration 'pending-traffic-treatment quota-extused drop')

- Cela indique à UP que le trafic doit être abandonné lors de la consommation du quota final.

Démonstration du laboratoire

Ce test de TP illustre ce comportement plus en détail :

Paramètres OCS :

- Quota total :     5000000

- Octrois de quotas :    500000

- Quota-threshold :         0

Test de téléchargement haut débit.

Tout au long de la session, une utilisation toujours plus élevée est signalée que l'attribution de quota de 500000 octets dans les requêtes de rapport de session SX de UP. Cela est dû au téléchargement à haut débit en combinaison avec le délai entre fastpath/sessmgr pour obtenir les statistiques de volume mises à jour lors de l'épuisement du quota. Cette différence est plus élevée lorsque le débit est plus élevé pendant ce temps.

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

La subvention finale de l'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

Ensuite, tout le trafic sur UP est abandonné (comme CC abandonné) comme on peut le voir sur UP avec cette commande :

[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

Mais, pourquoi les mesures de volume dans le rapport d'utilisation final de l'UP ne dépassent-elles pas la subvention ?

Le CP, dans son allocation de quota finale, crée un nouveau FAR avec une action définie pour abandonner, et ceci est lié à l'URR. Cette commande indique à VPP d'abandonner le trafic immédiatement après l'utilisation de l'autorisation finale :

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

Note: Ce comportement sur CUPS UP n'entraîne pas de surconsommation de quota comme on peut le voir sur le 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

Note: Ce comportement est clairement visible car un seuil de devis de zéro a été configuré sur l'OCS. Si un seuil de quota différent de zéro est configuré, l'UP demande un nouveau quota lorsque le seuil est atteint (avant la consommation totale de l'allocation de quota).