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 :
- 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.
- VPP ne supprime pas le trafic pendant ce temps.
- 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).
Commentaires