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:
- 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í.
- VPP no descarta el tráfico durante este tiempo.
- 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).
Comentarios