Introduzione
Questo documento descrive il comportamento su un Control and User Plane (CUPS UP) per un sottoscrittore prepagato in cui Gy viene utilizzato per la gestione delle quote.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei Architettura CUPS.
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
Questa opzione di configurazione è presente nel gruppo di controllo del credito:
credit-control-group xxx
pending-traffic-treatment quota-exhausted drop
Nel PGW/SAEGW legacy, questa configurazione causerebbe l'interruzione del traffico per il gruppo di classificazione:
- Quando viene utilizzata la concessione di quota ed è in corso una nuova richiesta di quota.
- Oppure perché la quota è completamente consumata (l'attributo Final-Unit-Indication è presente con Final-Unit-Action) nell'ultima CCA dal server OCS.
Rilevanza per l'ambiente CUPS
In un ambiente CUPS, la situazione è un po' diversa. Il flusso nell'UP è:
- Quando si esaurisce una quota per un gruppo di valutazione, il VPP notifica sessmgr-U e sessmgr-U interroga l'utilizzo dal VPP. C'è un piccolo ritardo qui.
- Il VPP non scarta il traffico in questo periodo.
- Sessmgr-U invia una sessione segnalando la richiesta di tipo: report di utilizzo. Contiene le seguenti informazioni:
- trigger report utilizzo: quota di volume
- misurazione del volume: volume totale/volume uplink/volume downlink
Nota: I volumi potrebbero essere superiori alla quota concessa. Ciò è dovuto al ritardo tra la notifica vpp e il recupero dello stato del volume da parte di sessmgr-U.
4. Una volta ricevuta la nuova quota, il traffico che conta su UP viene ripreso (tenendo conto dei dati già inviati durante la richiesta della nuova quota).
5. Lo stesso ciclo di eventi si verifica per ogni aggiornamento della quota.
6. Al ricevimento della concessione finale del contingente si verifica quanto segue:
- Su CP si riceve un CCA-U con indicazione dell'unità finale (e azione dell'unità finale).
- CP attiva una richiesta di modifica della sessione per UP che contiene la quota rimanente, insieme a un FAR appena creato con l'azione DROP (a causa della configurazione 'in sospeso-quota-trattamento-esaurimento')
- Ciò indica a UP che il traffico deve essere ridotto al momento del consumo della quota finale.
Dimostrazione da Lab
Questo test di laboratorio illustra più dettagliatamente questo comportamento:
Impostazioni OCS:
- Quota totale: 5000000
- Concessioni di quote: 500000
- Soglia di quota: 0
Test di download ad alta velocità.
Nel corso della sessione, viene segnalato un utilizzo sempre più elevato rispetto alla concessione di una quota di 500000 ottetti nelle richieste di report della sessione SX da UP. Ciò è dovuto al download ad alta velocità in combinazione con il ritardo tra fastpath/sessmgr per ottenere lo stato aggiornato del volume al momento dell'esaurimento della quota. Questa differenza è maggiore quando il throughput è più elevato durante questo periodo.
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 sovvenzione finale dell'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
In seguito, tutto il traffico su UP viene interrotto (a causa di un calo di CC) come mostrato su UP con questo comando:
[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
Ma, perché le misurazioni di volume nel report finale di utilizzo da UP non superano la sovvenzione?
Il PC, nella concessione finale delle quote, crea un nuovo FAR con l'azione destinata a cadere, e questo è legato all'URR. In questo modo il VPP scarta il traffico subito dopo aver utilizzato la concessione 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
Nota: Questo comportamento su CUPS UP non porta a un sovraconsumo della quota come si può vedere sul PC.
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
Nota: Questo comportamento è evidente perché su OCS è stata configurata una soglia di quotazione pari a zero. Se viene configurata una soglia di quota diversa da zero, l'UP richiederà una nuova quota quando viene raggiunta la soglia (prima del consumo totale delle concessioni di quota).
Feedback