Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Premesse

Rilevanza per l'ambiente CUPS

Dimostrazione da Lab

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 è:

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

2. Il VPP non scarta il traffico in questo periodo.

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