Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Antecedentes

Relevancia para el entorno CUPS

Demostración desde el laboratorio

Introducción

Este documento describe el comportamiento en un Plano de Control y Usuario (CUPS UP) para un suscriptor de prepago donde Gy se utiliza para la administración de cuotas.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento de la Arquitectura CUPS.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

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 tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Esta opción de configuración está presente en el grupo de control de crédito:

credit-control-group xxx

pending-traffic-treatment quota-exhausted drop

En PGW/SAEGW heredado, esta configuración haría que el tráfico se descartara para ese grupo de clasificación:

- Cuando se consume la concesión de cuota y hay una nueva solicitud de cuota en curso.

- O porque la cuota está totalmente consumida (el atributo Final-Unit-Indication está presente con Final-Unit-Action) en la última CCA del servidor OCS.

Relevancia para el entorno CUPS

En un entorno CUPS, la situación es un poco diferente. El flujo en la UP es:

1. Cuando se agota una cuota para un grupo de clasificación, VPP notifica a sessmgr-U y sessmgr-U consulta el uso desde VPP. Hay un pequeño retraso aquí.

2. VPP no descarta el tráfico durante este tiempo.

3. El Sessmgr-U envía un informe de sesión del tipo de solicitud: informe de uso. Contiene esta información:

- desencadenador de informe de uso: cuota de volumen

- medición del volumen: volumen total/volumen de enlace ascendente/volumen de enlace descendente

Nota: Los volúmenes pueden ser superiores a la cuota concedida. Esto se debe al retraso entre la notificación de vpp y sessmgr-U que recupera el estado del volumen.

4. Una vez recibida la nueva cuota, se reanuda el recuento de tráfico en UP (tenga en cuenta los datos que ya se envían mientras se solicitaba la nueva cuota).

5. El mismo ciclo de eventos se produce para cada actualización de cuota.

6. Cuando se recibe la concesión final de cuota, sucede lo siguiente:

- En CP se recibe una CCA-U con Indicación-Unidad-Final (y Acción-Unidad-Final).

- CP activa una solicitud de modificación de sesión a UP que contiene la cuota restante, junto con un FAR recién creado con la acción DROP (debido a la configuración 'caída agotada de la cuota de tratamiento de tráfico pendiente')

- Esto indica a UP que el tráfico debería descartarse al consumir la cuota final.

Demostración desde el laboratorio

Esta prueba de laboratorio ilustra este comportamiento con más detalle:

Configuración de OCS:

- Cuota total:     5000000

- Subvenciones de cuota:    500000

- Umbral de cuota:         0

Prueba de descarga de alta velocidad.

A lo largo de la sesión, se informa de manera constante un mayor uso que la concesión de la cuota de 500000 octetos en las solicitudes de informe de sesión SX de UP. Esto se debe a la descarga de alta velocidad en combinación con el retraso entre fastpath/sessmgr para obtener las estadísticas de volumen actualizadas tras el agotamiento de la cuota. Esta diferencia es mayor cuando el rendimiento es mayor durante este tiempo.

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 subvención final de 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

Después, todo el tráfico en UP se descarta (como CC descartado) como se puede ver en UP con este 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

Pero, ¿por qué las mediciones de volumen en el informe de uso final de UP no exceden la subvención?

El PC, en su concesión de cuota final, crea un nuevo FAR con la acción establecida en descartar, y esto está vinculado al URR. Esto indica a VPP que descarte el tráfico inmediatamente después de que se consume la concesión final:

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: Este comportamiento en CUPS UP no conduce a un consumo excesivo de cuota como se puede ver en el 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

Nota: Este comportamiento se ve claramente porque se configuró un umbral de presupuesto de cero en el OCS. Si se configura un umbral de cuota distinto de cero, el grupo UP solicitará una nueva cuota cuando se alcance el umbral (antes del consumo total de la concesión de cuota).