Política de 3GPP y control de cobro para el aprovisionamiento y la contabilidad de cableado
Descripción general de la política de 3GPP y el control de cobro para el aprovisionamiento y la contabilidad de cableado
La Política y el Control de Carga (PCC) del Proyecto de Asociación de 3ª Generación (3GPP) proporciona la unificación del aprovisionamiento de cableado y la contabilidad para los clientes. La Figura 1 muestra los componentes de una arquitectura PCC 3GPP general.
la arquitectura 3GPP PCC
Los cuatro componentes principales de la arquitectura de PCC son:
-
Función de políticas y reglas de cobro (PCRF): un punto de decisión de política centralizado que despliega políticas empresariales y reglas de cobro para asignar recursos de red de banda ancha y administra cargos basados en el flujo para suscriptores y servicios. PCRF lleva las reglas a la Función de cumplimiento de políticas y cargos (PCEF) mediante el protocolo 3GPP Gx y la interfaz de políticas en línea.
-
Función de cumplimiento de políticas y cargos (PCEF): una función que proporciona manejo del tráfico del usuario y QoS en la puerta de enlace, proporciona detección de flujo de datos de servicio y aplica las reglas recibidas del PCRF. Opcionalmente, PCEF interactúa con la función de cobro en línea (OCF) dentro del sistema de cobro en línea (OCS) mediante el protocolo 3GPP Gy para recuperar políticas y autorización de cobro para cuotas y control de crédito.
-
Sistema de carga en línea (OCS): el componente responsable de interactuar con el PCEF. Opcionalmente, el PCEF informa del uso y recibe autorizaciones adicionales de la OCS mediante el protocolo 3GPP Gy. Las interacciones de PCEF de banda ancha (BPCEF) con el OCS utilizan la carga de sesiones en línea con determinación de unidad centralizada y clasificación centralizada.
-
Sistema de carga fuera de línea (OFCS): un proceso en el que la información de carga para el uso de recursos de red se recopila simultáneamente con ese uso de recursos. Si no se requiere autorización basada en créditos, el PCEF aplica políticas e informa el uso al OFCS mediante el protocolo 3GPP Gz. También puede utilizar el OCS como destino principal de contabilidad y utilizar el OFCS como copia de seguridad.
La Tabla 1 enumera las diferencias de funcionalidad entre PCRF y PCEF.
| Funcionalidad |
PCRF |
PCEF |
|---|---|---|
| Implementación de la vigilancia de la carga |
Involucrado en diferentes niveles; agrega información dentro de la red de alojamiento y se considera parte de la arquitectura de PCC. |
Involucrado en diferentes niveles; ubicado en la puerta de entrada. |
| Funciones incluidas |
Incluye principalmente funciones de control de políticas, decisiones y control basadas en flujos. |
Incluye funciones de cumplimiento de políticas y cobro basado en el flujo. |
| Reglas de PCC predefinidas |
La activación o desactivación de las reglas PCC predefinidas solo puede ser realizada por la PCRF. |
Preconfigurado por el PCEF. |
| Interacciones de carga en línea y fuera de línea |
No compatible |
Compatible |
Los otros tres componentes que componen la arquitectura de PCC en la Figura 1 son:
-
Función de aplicación (AP): la función de aplicación interactúa con aplicaciones o servicios que requieren PCC dinámica. La función de aplicación extrae información de sesión de la señalización de la aplicación y proporciona información relacionada con la sesión de aplicación al PCRF utilizando el protocolo Rx.
-
Repositorio de perfiles de suscripción (SPR): SPR contiene información de suscriptor y suscripción según la red de datos por paquete (PDN). El protocolo SP permite a la PCRF solicitar información de suscripción relacionada con el servicio o la sesión de un suscriptor.
-
Función de vinculación de portadores y notificación de eventos (BBERF): la regla PCC debe asignarse a un portador IP determinado para garantizar que los paquetes reciban el tratamiento de QoS adecuado. La asociación entre una regla PCC y un portador se denomina vinculación al portador. La ubicación de BBERF depende de la tecnología de acceso. Para 3GPP, el BBERF se encuentra en la puerta de enlace de servicio y utiliza el protocolo Gxx.
Beneficios de la arquitectura de control de cobro y política de 3GPP
-
Proporciona un marco unificado para el aprovisionamiento y la contabilidad de los suscriptores por cable.
Descripción general de la función de cumplimiento de políticas y cobro para suscriptores de banda ancha por cable
La Función de Cumplimiento de Políticas y Carga (PCEF) es uno de los cuatro componentes principales de la arquitectura de Política y Control de Carga (PCC) del Proyecto de Asociación de Tercera Generación (3GPP) en la Figura 2.
de la arquitectura 3GPP PCC
PCEF proporciona manejo del tráfico del usuario y calidad del servicio (QoS) en la puerta de enlace, proporciona detección de flujo de datos de servicio y aplica las reglas recibidas de la función de reglas de control y cobro de políticas (PCRF). 3GPP define Gx como el protocolo de política en línea entre la PCRF y la PCEF para proporcionar control sobre la política y los cargos basados en el flujo para los suscriptores. El PCRF es un punto de decisión de política centralizado que despliega reglas de políticas empresariales para asignar recursos de red de banda ancha y administra cargos basados en flujo para suscriptores y servicios. Opcionalmente, el PCEF interactúa con el sistema de cobro en línea (OCS) mediante el protocolo 3GPP Gy para recuperar políticas y autorización de cobro para cuotas y control de crédito.
PCEF proporciona soporte para los siguientes entornos:
Entorno de acceso por cable
En el caso de los abonados móviles, el equipo de usuario solicita servicios; para suscriptores de banda ancha por cable, la PCRF solicita servicios. En el entorno alámbrico, PCRF funciona como solicitante de servicio y PCEF funciona como receptor y ejecutor de servicios.
La adaptación del modelo PCC en un entorno de cableado proporciona estos beneficios:
Conveniencia
Tecnología avanzada
Ya implementado por la rama inalámbrica del operador que a menudo proporciona un negocio mucho más grande que la rama de línea fija
El PCRF controla el PCEF impulsando reglas de carga. Las reglas de cobro se reutilizan como reglas de servicio (política) para impulsar políticas. Las reglas de carga también pueden tener un grupo de clasificación asociado o una clave de carga. Como resultado, la configuración PCEF debe definir reglas de cobro y asignación entre los servicios de control de crédito (cc-services) y los grupos de calificación.
En muchos casos, tanto OCS como los servicios de contabilidad 3GPP del sistema de cobro fuera de línea (OFCS) requieren que se utilice el número de directorio internacional de suscriptores de la estación móvil (MSISDN) para la identificación del suscriptor. El MSISDN se pasa como ID de suscripción. Aunque cada dispositivo de equipo de usuario móvil tiene un MSISDN asociado, esta información no está disponible para los suscriptores de línea fija. Para permitir que la PCRF pase dinámicamente los parámetros de ID de suscripción y admita una variedad de configuraciones de autenticación, autorización y aprovisionamiento, los pares atributo-valor (AVP) de Juniper en la tabla 2 se asignaron desde el atributo específico del proveedor (VSA) del espacio de ID de proveedor de Juniper (2636).
Si no se recibe ningún ID de suscripción dinámica, no se inician las comunicaciones OCS ni OFCS.
Nombre AVP |
ID de proveedor |
Tipo de AVP |
Tipo de diámetro |
Bandera de diámetro |
|---|---|---|---|---|
Indicador de suscripción juniper-dyn |
2636 |
10001 |
Enumeración |
V |
juniper-dyn-subscription-id |
2636 |
10002 |
Agrupado |
VM |
Tipo de ID de suscripción de juniper-dyn |
2636 |
10003 |
Entero32 |
VM |
juniper-dyn-subscription-id-data |
2636 |
10004 |
Cadena UTF8 |
VM |
El sistema cliente (enrutador) envía el AVP Juniper-Dyn-Subscription-ID-Indicator para indicar que admite la asignación dinámica del ID de suscripción. El atributo Juniper-Dyn-Subscription-Id-Indicator tiene dos valores:
DYN_SUBSCRIPtION_NOT_SUPPORTED (0)
DYN_SUBSCRIPTION_SUPPORTED (1)
Luego, el servidor envía el AVP de Juniper-Dyn-Subscription-ID al cliente que indicó la compatibilidad. Se trata de un AVP agrupado que contiene los valores que se enviarán como Subscription-Id-Type y Subscription-Id-Data.
El servidor PCRF puede utilizar AVP de ID de suscripción estándar para comunicar el ID de suscripción dinámica al enrutador.
Si la PCRF envía tanto Juniper-Dyn-Subscription-ID como Subscription-Id, se utiliza el valor de Subscription-ID.
En muchos casos, los suscriptores de línea fija admiten solo una familia IP, que es información requerida tanto para el servicio AAA como para PCRF. Para indicar esta información, el AVP de Juniper-Network-Family-Indicator se asignó desde el espacio de ID de proveedor de Juniper (2636) VSA en la Tabla 3.
Nombre AVP |
ID de proveedor |
Tipo de AVP |
Tipo de diámetro |
Bandera de diámetro |
|---|---|---|---|---|
Indicador de familia de red de Juniper |
2636 |
10010 |
Enumeración |
V |
El sistema cliente (enrutador) envía el AVP Juniper-Network-Family-Indicator para indicar qué familias de red están asociadas con la solicitud de servicio y son compatibles con el suscriptor. Cuando configure el AVP Juniper-Network-Family-Indicator para indicar la familia de red asociada, el sistema envía la información al PCRF. El atributo Juniper-Network-Family-Indicator tiene cuatro valores:
SIN ESPECIFICAR (0)
IPV4_FAMILY (1)
IPV6_FAMILY (2)
IPV4_IPV6_FAMILY (3)
Los clientes de Wireline a menudo controlan los servicios de usuario únicamente a través del PCRF y utilizan el OCS como un mecanismo conveniente de monitoreo del uso en tiempo real en lugar de como una unidad de cumplimiento. Para disminuir el número de posibles configuraciones erróneas de OCS, incluya la force-continue instrucción en el [edit access ocs partition partition-name] nivel de jerarquía para forzar al PCEF de banda ancha (BPCEF) a limitar el impacto de las respuestas negativas del OCS y los vencimientos de cuotas, y para evitar el envío de notificaciones de OCS para los grupos de calificación afectados. Cada vez que el PCEF recibe una respuesta negativa a cualquier grupo informado, deja de informar este grupo a la OCS.
Entorno de Junos OS
Hay tres categorías de perfiles dinámicos en el entorno de Junos OS:
perfiles dinámicos de clientes
cos-service-dynamic-profiles
perfiles dinámicos de servicio de firewall
Los perfiles dinámicos del cliente y los perfiles dinámicos de servicios cos, definen el ancho de banda y otras características de los servicios prestados a un suscriptor; Los perfiles de servicio de firewall realizan el filtrado y el conteo de usos. Para todas las categorías de perfiles dinámicos, el nombre service-dynamic-profile se utiliza como valor de un AVP de nombre de regla de carga.
Cuando el perfil dinámico de servicio no tiene variables o cuando se solicitan valores predeterminados proporcionados en la definición del perfil dinámico de servicio, no se requieren elementos adicionales. Para proporcionar valores personalizados para un perfil dinámico de servicio, use el AVP de definición de reglas de cobro con VSA adicionales.
La PCRF utiliza los VSA de sustitución de Juniper existentes (ID de proveedor 2636 y tipo 2024) para proporcionar atributos como pares nombre-valor. El PCRF también puede incluir parámetros como notación posicional para parte del nombre de la regla. El AVP de información de redireccionamiento (ID de proveedor 10415 y tipo 1085) proporciona un valor para el parámetro URL de redireccionamiento.
Para cada nombre de parámetro de perfil dinámico de servicio posible solicitado por los clientes, se define un nuevo VSA de parámetro de Juniper. En la Tabla 4 se describe el conjunto inicial de VSA fijos de parámetros de Juniper.
Parámetro |
Nombre VSA |
ID de proveedor |
Tipo |
Tipo de diámetro |
|---|---|---|---|---|
cos-tcp |
juniper-param-cos-tcp |
2636 |
10005 |
Cadena UTF8 |
v4-firewall-entrada-filtro |
Filtro de entrada de firewall juniper-param-v4 |
2636 |
10006 |
Cadena UTF8 |
v4-firewall-output-filter |
Filtro de salida de firewall juniper-param-v4 |
2636 |
10007 |
Cadena UTF8 |
v6-firewall-input-filter |
Filtro de entrada de firewall juniper-param-v6 |
2636 |
10008 |
Cadena UTF8 |
v6-firewall-output-filter |
Filtro de salida de firewall juniper-param-v6 |
2636 |
10009 |
Cadena UTF8 |
Si se requiere que la PCRF indique los parámetros o el identificador de servicio y el grupo de calificación, se utiliza el AVP de definición de regla de carga; de lo contrario, se utiliza el AVP de nombre de regla de carga.
Charging-Rule-Definition ::= < AVP Header: 1003 >
{ Charging-Rule-Name }
[ Service-Identifier ]
[ Rating-Group ]
[ Online ]
[ Precedence ]
[ Juniper-Param-VSA ]
[ AVPs ] – standard AVPs used as parameters
En los casos en que exista una combinación de identificador de servicio y grupo de calificación, o cuando solo se especifique el identificador de servicio o solo el grupo de calificación, la combinación debe ser única entre las reglas instaladas para un suscriptor. Configure el service-context-id en el enrutador.
Descripción de las interacciones Gx entre el enrutador y el PCRF
Las secuencias de mensajes de Diameter se intercambian por medio del protocolo Gx del Proyecto de Asociación de 3ª Generación (3GPP) entre la Función de Control de Políticas y Carga de Reglas (PCRF) y el enrutador que actúa como una Función de Aplicación de Políticas y Carga (PCEF).
A partir de Junos OS versión 17.3R1, se agrega soporte para funciones OCS y PCRF adicionales mediante los protocolos Gy y Gx. Las nuevas declaraciones:
accept-sdrse agrega para la partición PCRF en el nivel[edit access pcrf partition partition-name]de jerarquía .alternative-partition-namese agrega para la partición OCS en el nivel[edit access ocs partition partition-name]de jerarquía .
Interactúan para realizar las siguientes tareas de acceso de los suscriptores:
- Inicio de sesión de suscriptor
- Recuperación de errores de inicio de sesión de suscriptor
- Actualización del suscriptor
- Cerrar sesión de suscriptor
- Desconexión de suscriptores
- Recuperación de errores de conectividad
Inicio de sesión de suscriptor
El enrutador envía una solicitud CCR de diámetro que contiene un conjunto fijo de información requerida a un administrador de políticas (PCRF) y recibe una respuesta CCA que contiene políticas y otra información. El aprovisionamiento de Gx se habilita para los suscriptores cuando se incluye la provisioning-order pcrf instrucción en el nivel de [edit access profile profile-name] jerarquía. Cuando una aplicación solicita a AAA que active la sesión del suscriptor, el enrutador envía un mensaje CCR-GX-I (donde I representa INITIAL_REQUEST) al PCRF para solicitar un conjunto fijo de información de aprovisionamiento para la sesión suscriptor, y recibe un mensaje de respuesta CCA-GX-I que contiene políticas y otra información, incluido el código de resultado AVP (código AVP 268).
Cuando configure la provisioning-order instrucción en el perfil de acceso, el módulo PCEF de banda ancha (BPCEF) envía una solicitud de aprovisionamiento al PCRF durante la activación del cliente. Los siguientes ejemplos muestran un intercambio de paquetes CCR-GX-I y CCA-GX-I:
Ejemplo de paquete CCR-GX-I
CCR-GX-I ::= <Diameter Header: 272, REQ, PXY 16777238>
{ <Session-Id> }
{ Auth-Application-Id: 16777238 }
{ Origin-Host: <configurable-string> }
{ Origin-Realm: <configurable-string> }
{ Destination-Realm: <configurable-string> }
{ CC-Request-Type: INITIAL_REQUEST(1) }
{ CC-Request-Number: 0 }
{ Subscription-Id:
{ Subscription-Id-Type: <configurable-integer> }
{ Subscription-Id-Data: <configurable-string> }
}
}
[ Destination-Host: <configurable-string> ] -- if configured
[ Origin-State-Id: <u32> ] -- if configured to send
[ Framed-IP-Address: <ipv4-address-in-radius-encoding> ] -- if available
[ Framed-IPv6-Prefix: <ipv6-prefix-in-radius-encoding> ] -- if available
{ IP-CAN-Type: <configurable-integer> }
{ Online: ENABLE_ONLINE (1) }
[ User-Name: <string> ]
[ NAS-Port-Id: <string> ] -- if included by config
[ Juniper-Virtual-Router: <virtual-router-name> ] -- if included by config
[ Event-Timestamp: <timestamp> ] -- login timestamp, if included by config
{ Juniper-Dyn-Subscription-Indicator: DYN_SUBSCRIPTION_SUPPORTED(1) }
{ Juniper-Network-Family-Indicator: <subscriber-family> }
El bit T (mensaje potencialmente retransmitido) se vuelve a calcular cuando se reenvía el CCR-GX-I. Esta marca se establece después de un procedimiento de tolerancia a fallos de vínculo para eliminar solicitudes duplicadas.
Ejemplo de paquete CCA-GX-I
CCA-GX-I ::= <Diameter Header: 272, PXY, 16777238>
{ <Session-Id> }
{ Result-Code: <integer> }
{ Auth-Application-Id: 16777238 }
{ Origin-Host: <string> } -- should match destination-host if configured
{ Origin-Realm: <string> } -- should match destination-realm
{ Result-Code: <integer> }
{ CC-Request-Type: INITIAL_REQUEST(1) }
{ CC-Request-Number: 0 }
[ Juniper-Dyn-Subscription-Id:
{Juniper-Dyn-Subscription-Id-Type: <value-to-be-used-for-ocs-interactions> }
{Juniper-Dyn-Subscription-Id-Data: <value-to-be-used-for-ocs-interactions> }
]
*[ Supported-Features ] -- ignored
[ Origin-State-Id: <u32> ] -- Indicates restart PCRF side
*[ Downstream data units ]
Si no se define ningún AVP de instalación de reglas en CCA-GX-I, se instala la regla predeterminada.
Se aceptan todos los desencadenantes de eventos, incluidos los que aún no se han definido. Sin embargo, solo unos pocos desencadenadores de eventos generan realmente eventos cuando se implementan.
El PCRF devuelve un mensaje CCA-GX-I que incluye el código de resultado AVP (código AVP 268) que se asigna a las categorías de resultados enumeradas en la Tabla 5.
Valor del código de resultado de AVP |
Categoría de resultados |
|---|---|
SUCCESS(2001), LIMITED_SUCCSS(2002) y mensaje válido |
Subvención |
AUTHENTICATION_REJECTED(4001), UNKNOWN_SESSION_ID(5002), AUTHORIZATION_REJECTED(5003) y USER_UNKNOWN(5030) |
Denegar |
UNABLE_TO_DELIVER(3002), REALM_NOT_SERVED(3003), TOO_BUSY(3004), LOOP_DETECTED(3005) y REDIRECT_INDICATION(3006) |
Fracaso |
Todos los demás AVP de código de resultado de falla permanente de diámetro mayores e iguales que 5000 y todos los AVP de código de resultado de error de protocolo de diámetro mayores e iguales que 3000 y menores de 4000 |
Falla permanente |
Otros AVP de código de resultado para mensaje no válido o sin respuesta |
Fracaso |
Como se muestra en la Tabla 6, el procesamiento de la respuesta CCA-GX-I depende de tres factores:
Si el tiempo de espera de decisión local ha expirado
El establecimiento de la decisión local
La categoría de resultados
La Tabla 6 también contiene acciones de expiración de tiempo de espera de decisión local de PCRF.
Tiempo de espera de decisión local de PCRF |
Decisión local de PCRF |
Categoría de resultados |
Acción |
|---|---|---|---|
No caducado |
– |
Subvención |
Borre el temporizador de decisión local, aplique las reglas del CCA-GX-I, notifique al Sistema de Cobro en Línea (OCS) y luego confirme la activación del suscriptor. |
No caducado |
– |
Denegar |
Borre el temporizador de decisión local y falle la activación del suscriptor. |
No caducado |
– |
Fracaso |
Vuelva a intentar el CCA-GX-I hasta que se agote el tiempo de espera de la decisión local. |
No caducado |
Subvención |
Falla permanente |
Borre el temporizador de decisión local, aplique la regla predeterminada, confirme la activación del suscriptor y luego siga reintentando el CCA-GX-I. |
No caducado |
Denegar |
Falla permanente |
Se produce un error en la activación del suscriptor e inicia el proceso de cierre de sesión del suscriptor. |
Al vencimiento |
Subvención |
– |
Aplique la regla predeterminada, siga reintentando el CCA-GX-I indefinidamente y confirme la activación del suscriptor. |
Al vencimiento |
Denegar |
– |
Se produce un error en la activación del suscriptor e inicia el proceso de cierre de sesión del suscriptor. |
Caducado |
Subvención |
Subvención |
Si CCA-GX-I contiene reglas, elimine las reglas predeterminadas e instale las reglas recibidas y, a continuación, notifique a la OCS y confirme la activación del suscriptor. |
Caducado |
Subvención |
Denegar |
Cierre la sesión del cliente. |
Caducado |
Subvención |
Fracaso |
Siga reintentando el CCA-GX-I indefinidamente. |
Caducado |
Subvención |
Falla permanente |
Tome una pausa larga y luego reinicie el reintento del CCA-GX-I. |
Caducado |
Denegar |
Denegar |
Si el suscriptor sigue cerrando sesión, ignore al suscriptor; de lo contrario, no se requiere ninguna acción. |
El inicio de sesión de un suscriptor inicia la siguiente secuencia de eventos:
Una aplicación cliente, como DHCP, PPP o sesiones de suscriptor estáticas, solicita a AAA que autentique al suscriptor.
La autenticación comienza si el perfil de acceso del suscriptor especifica la autenticación de RADIUS. El inicio de sesión continúa cuando la autenticación se realiza correctamente. Se produce un error en el inicio de sesión cuando la
authentication-orderinstrucción del perfil no especifica la autenticación de RADIUS o ninguna autenticación. El inicio de sesión también falla cuando falla la autenticación.Los servicios predeterminados se activan para el suscriptor. Se activan todos los servicios que el servidor de autenticación incluya en la concesión de autenticación. Además, es posible que se haya configurado un servicio predeterminado para la aplicación cliente.
Si el perfil de acceso del suscriptor especifica el aprovisionamiento de Gx, el enrutador inicia el intercambio de mensajes Gx mediante el envío de un mensaje CCR-GX-I a la PCRF. El enrutador espera a que la PCRF responda con un mensaje CCA-GX-I dentro de un período de tiempo de espera no configurable.
Cuando el PCRF responde dentro del período de tiempo de espera e incluye el AVP Charging-Rule-Install en el mensaje CCA-GX-I, el inicio de sesión del suscriptor se retrasa mientras el enrutador desactiva los servicios predeterminados e intenta activar los servicios especificados.
Si se activan todos los servicios especificados, se completará el inicio de sesión.
Si no se puede activar alguno de los servicios, el enrutador envía al PCRF un mensaje CCR-GX-U (donde U representa UPDATE_REQUEST) con el estado de los servicios (un informe de reglas). El PCRF responde a este mensaje con un CCA-GX-U que puede contener un nuevo conjunto de servicios para su activación.
El enrutador ignora cualquier servicio predeterminado, incluso si el mensaje CCA-GX-I no incluye ningún servicio. En esta circunstancia, no se activa ningún servicio.
Si la PCRF no devuelve un CCA-GX-I dentro del período de tiempo de espera, el inicio de sesión del suscriptor se completa.
El enrutador busca primero los servicios devueltos por el servidor de autenticación y activa los que encuentra. Si no se encuentra ninguno de estos servicios, el enrutador activa los servicios predeterminados configurados localmente. El inicio de sesión de suscriptor se completa cuando la activación del servicio predeterminado se realiza correctamente, pero falla cuando algún servicio predeterminado no se activa. Dado que no es necesario que los servicios predeterminados estén presentes, el inicio de sesión también se completa cuando no se encuentran servicios predeterminados.
Si el inicio de sesión se completa (con o sin un servicio predeterminado), el enrutador reenvía periódicamente el mensaje CCR-GX-I al PCRF. Si el PCRF devuelve posteriormente un CCA-GX-I, el enrutador desactiva el servicio predeterminado, si lo hubiera, y luego activa cualquier servicio incluido en el CCA-GX-I. Si el mensaje no incluye ningún servicio, entonces no se activa ningún servicio, ni siquiera un servicio predeterminado.
Si no se puede activar alguno de los servicios incluidos en el CCA-GX-I, el enrutador envía al PCRF un mensaje CCR-GX-U con el estado de los servicios (un informe de reglas). El PCRF responde a este mensaje con un CCA-GX-U que puede contener un nuevo conjunto de servicios para su activación.
Recuperación de errores de inicio de sesión de suscriptor
A partir de la versión 20.1R1 de Junos, puede configurar el enrutador para que se recupere de ciertos errores del servidor PCRF reinicializando la sesión del suscriptor para volver a sincronizar los estados del enrutador y del servidor PCRF. Es posible que algunos servidores PCRF no manejen adecuadamente una situación en la que se pierdan los mensajes CCA-GX-I que envió al enrutador. Cuando el enrutador vuelve a intentar enviar el CCR-GX-I al PCRF, el servidor no está sincronizado con el enrutador porque ya envió una respuesta y no es consciente de que el enrutador no recibió el mensaje. Esta discrepancia en el estado puede dar lugar a cualquiera de los siguientes errores:
El servidor PCRF responde al reintento con un CCA-GX-I que contiene el código de resultado de diámetro AVP (código 268) con un valor de 5012 (DIÁMETRO NO PUEDE CUMPLIR). Esto se considera una falla permanente (Tabla 5).
El servidor PCRF envía un RAR. El servidor espera que la sesión esté activa porque envió el CCA-GX-I al enrutador y no es consciente de que no se recibió el mensaje. El servidor puede enviar cualquiera de los siguientes mensajes RAR:
RAR-GX-D para desconectar la sesión porque considera que la sesión es mala
RAR-GX-A para leer información sobre la mala sesión
RAR-GX-U para actualizar la sesión porque considera que la sesión funciona normalmente.
Puede utilizar la configuración PCRF local-decision para reinicializar la sesión del suscriptor en respuesta a uno o ambos errores.
Incluye la opción para el
reinit-on-failureerror de falla permanente.Incluir
reinit-on-raropción para el error RAR.
La operación de reinicialización tiene estos requisitos de configuración adicionales:
Debe configurar la opción de decisión
grantlocal.Debe configurar el enrutador para que utilice un ID de sesión extendido a fin de que pueda mantener el estado de la sesión original y la nueva vinculada al mismo evento de inicio de sesión. Para ello, configure la opción PCRF
use-session-stamp.
La operación de reinicialización consta de los siguientes pasos en ambos casos:
El enrutador envía una solicitud de finalización de sesión, CCR-GX-T, al PCRF para finalizar la sesión. Esto se hace en un intento de conseguir que el enrutador y el servidor PCRF tengan el mismo estado para esta sesión.
El enrutador espera un período de tiempo de espera de reinicialización para recibir un CCA-GX-T. Puede utilizar la
reinit-timeoutopción para especificar un período diferente al predeterminado.Si el enrutador recibe un CCA-GX-T dentro del período de tiempo de espera o un CCA-GX-T no llega antes de que expire el tiempo de espera, el enrutador envía un CCR-GX-I al PCRF con un ID de sesión nuevo y extendido. El ID de sesión extendido se transmite en el Diameter Session-ID AVP (código AVP 263).
El enrutador forma el ID de sesión extendido anexando una marca de sesión que consiste en la hora UTC en que el enrutador crea el CCR-GX-I. Por ejemplo, considere el siguiente AVP con ID de sesión de diámetro. El ID de sesión es 23 y
use-session-stampno está configurado:test-host1;0000000000;0000000023;
Con
use-session-stampconfigured, la marca de tiempo de la sesión se anexa al valor AVP:test-host1;0000000000;0000000023;1557788595;
En la tabla 7 se proporcionan detalles acerca de cómo reacciona el enrutador a estos errores en función del estado local actual de PCRF.
Estado local |
Acción cuando se produce un error de PCRF |
|
El enrutador hace lo siguiente:
|
|
Cuando se completa el aprovisionamiento predeterminado, el enrutador hace lo siguiente:
|
|
El enrutador hace lo siguiente cuando no se configuran servicios predeterminados:
El enrutador hace lo siguiente cuando se configuran servicios predeterminados:
Cuando se completa el aprovisionamiento predeterminado, el enrutador hace lo siguiente:
|
Actualización del suscriptor
Cada vez que se produce un evento desencadenante en el enrutador, se envía una solicitud de actualización al PCRF. Los siguientes ejemplos muestran un intercambio de paquetes CCR-GX-U (donde U representa UPDATE_REQUEST) y CCA-GX-U:
Ejemplo de paquete CCR-GX-U
CCR-GX-U ::= <Diameter Header: 272, REQ, PXY 16777238>
{ <Session-Id> }
{ Auth-Application-Id: 16777238 }
{ Origin-Host: <configurable-string> }
{ Origin-Realm: <configurable-string> }
{ Destination-Realm: <configurable-string> }
{ CC-Request-Type: UPDATE_REQUEST(2) }
{ CC-Request-Number: <u32> }
[ Destination-Host: <configurable-string> ] -- if configured
[ Origin-State-Id: <u32> ] -- if configured to send
*[ Upstream data units ]
El bit T se vuelve a calcular cuando se reenvía el CCR-GX-U.
Ejemplo de paquete CCA-GX-U
CCA-GX-U ::= <Diameter Header: 272, PXY, 16777238>
{ <Session-Id> }
{ Auth-Application-Id: 16777238 }
{ Origin-Host: <string> } -- should match destination-host if configured
{ Origin-Realm: <string> } -- should match destination-realm
{ Result-Code: <integer> }
{ CC-Request-Type: UPDATE_REQUEST(2) }
{ CC-Request-Number: <u32> }
[ Origin-State-Id: <u32> ] -- Indicates PCRF restart
*[ Downstream data units ]
El PCRF devuelve un mensaje CCA-GX-U que incluye el AVP de código de resultado (código AVP 268) que se asigna a las categorías de resultados enumeradas en la Tabla 8.
Valor del código de resultado de AVP |
Categoría de resultados |
|---|---|
SUCCESS(2001), LIMITED_SUCCSS(2002) y mensaje válido |
¡Todo listo |
UNABLE_TO_DELIVER(3002), REALM_NOT_SERVED(3003), TOO_BUSY(3004), LOOP_DETECTED(3005) y REDIRECT_INDICATION(3006) |
Fracaso |
Todos los demás AVP de código de resultado de falla permanente de diámetro mayores e iguales que 5000 y todos los AVP de código de resultado de error de protocolo de diámetro mayores e iguales que 3000 y menores de 4000 |
¡Todo listo |
Otros AVP de código de resultado para mensaje no válido o sin respuesta |
Fracaso |
Cerrar sesión de suscriptor
Cuando la aplicación cliente envía un aviso de cierre de sesión suscriptor a AAA, Gx envía un mensaje CCR-GX-T (donde T representa TERMINATION_REQUEST) para notificar a la PCRF que la sesión de suscriptor aprovisionada está finalizando.
Cada vez que se produce un evento desencadenante en el enrutador, se envía una solicitud de terminación al PCRF. Los siguientes ejemplos muestran un intercambio de paquetes CCR-GX-T y CCA-GX-T:
Ejemplo de paquete CCR-GX-T
CCR-GX-T ::= <Diameter Header: 272, REQ, PXY 16777238>
{ <Session-Id> }
{ Auth-Application-Id: 16777238 }
{ Origin-Host: <configurable-string> }
{ Origin-Realm: <configurable-string> }
{ Destination-Realm: <configurable-string> }
{ CC-Request-Type: TERMINATION_REQUEST(3) }
{ CC-Request-Number: <u32> }
[ Destination-Host: <configurable-string> ] -- if configured
{ Termination-Cause: DIAMETER_LOGOUT(1) }
[ Origin-State-Id: <u32> ] -- if configured to send
*[ Upstream data units ]
El bit T se vuelve a calcular cuando se reenvía el CCR-GX-T.
Ejemplo de paquete CCA-GX-T
CCA-GX-T ::= <Diameter Header: 272, PXY, 16777238>
{ <Session-Id> }
{ Auth-Application-Id: 16777238 }
{ Origin-Host: <string> } -- should match destination-host if configured
{ Origin-Realm: <string> } -- should match destination-realm
{ Result-Code: <integer> }
{ CC-Request-Type: TERMINATION_REQUEST(3) }
{ CC-Request-Number: <u32> }
[ Origin-State-Id: <u32> ] -- Indicates PCRF restart
*[ Downstream data units ]
El PCRF devuelve un mensaje CCA-GX-T que incluye el código de resultado AVP (código AVP 268) que se asigna a las categorías de resultados enumeradas en la Tabla 9.
Valor del código de resultado de AVP |
Categoría de resultados |
|---|---|
SUCCESS(2001), LIMITED_SUCCSS(2002) y mensaje válido |
¡Todo listo |
UNABLE_TO_DELIVER(3002), REALM_NOT_SERVED(3003), TOO_BUSY(3004), LOOP_DETECTED(3005) y REDIRECT_INDICATION(3006) |
Fracaso |
Todos los demás AVP de código de resultado de falla permanente de diámetro mayores e iguales que 5000 y todos los AVP de código de resultado de error de protocolo de diámetro mayores e iguales que 3000 y menores de 4000 |
¡Todo listo |
Otros AVP de código de resultado para mensaje no válido o sin respuesta |
Fracaso |
Si el valor del código de resultado es Correcto, Gx notifica a AAA y AAA notifica a la aplicación que el cierre de sesión se ha completado. Si Gx no recibe un mensaje CCA-GX-T, o si el AVP del código de resultado tiene algún otro valor o falta, la solicitud de terminación se vuelve a intentar hasta que el mensaje CCA-GX-T se devuelva con éxito. El enrutador notifica al PCRF sobre los cierres de sesión del suscriptor mediante el envío de otra solicitud CCR para que se confirme mediante una respuesta CCA. La PCRF también puede utilizar solicitudes RAR para forzar el cierre de sesión del suscriptor o para cambiar los servicios aplicados.
Si el valor del código de resultado es Error, se vuelve a intentar la solicitud.
Desconexión de suscriptores
Para realizar desconexiones de suscriptores, el PCRF envía un RAR-GX-D (donde D representa DISCONNECT) y el BPCEF responde con un mensaje RAA-GX-D.
Los siguientes ejemplos muestran un intercambio de paquetes RAR-GX-D y RAA-GX-D:
Ejemplo de paquete RAR-GX-D
RAR-GX-D ::= <Diameter Header: 258, PXY, 16777238>
{ <Session-Id> }
{ Auth-Application-Id: 16777238 }
{ Origin-Host: <string> } -- should match destination-host if configured
{ Origin-Realm: <string> } -- should match destination-realm
{ Destination-Realm: <string> } -- should match origin-realm
{ Destination-Host: <string> } -- should match origin-host
{ Re-Auth-Request-Type: AUTHORIZE_ONLY(0) }
[ Origin-State-Id: <u32> ] -- Indicates PCRF restart
{ Session-Release-Cause: <enum> }
*[ Downstream data units ] -- ignored
Ejemplo de paquete RAA-GX-D
RAA-GX-D ::= <Diameter Header: 272, REQ, PXY, 16777238>
{ <Session-Id> }
{ Auth-Application-Id: 16777238 }
{ Origin-Host: <configurable-string> }
{ Origin-Realm: <configurable-string> }
{ Result-Code: <integer> }
[ Origin-State-Id: <u32> ]
*[ Upstream data units ]
El PCRF devuelve un mensaje RAA-GX-T que incluye el código de resultado AVP (código AVP 268) que se asigna a las categorías de resultados enumeradas en la Tabla 10.
Valor del código de resultado de AVP |
Categoría de resultados |
|---|---|
DIAMETER_SUCCESS(2001) |
La desconexión del suscriptor está en curso o no se encuentra el suscriptor. |
DIAMETER_UNABLE_TO_COMPLY(5012) |
El suscriptor no es extraíble |
DIAMETER_TOO_BUSY(3004) |
Demasiadas solicitudes de desconexión pendientes |
El BPCEF contiene espacio de almacenamiento en búfer para al menos 512 mensajes RAR-GX-D o RAA-GX-D.
Recuperación de errores de conectividad
Gx no se basa en el estado de conexión entre dispositivos para detectar interrupciones del enrutador o PCRF, ya que algunos eventos no afectan el estado de la conexión y otros no se detectan cuando hay un relé o proxy de diámetro entre los dispositivos.
Para mitigar los errores de conectividad con la PCRF, el enrutador utiliza los siguientes procedimientos de recuperación de errores:
Si la PCRF no está disponible y si instaló y configuró un servicio predeterminado, el inicio de sesión del suscriptor procede en consecuencia.
Las solicitudes de aprovisionamiento no reconocidas se reproducen indefinidamente o hasta que el suscriptor cierre la sesión.
Las solicitudes de cierre de sesión esperan a que se complete el interrogatorio final de OCS y, luego, las solicitudes de cierre de sesión no reconocidas se reproducen durante 24 horas.
El enrutador utiliza redundancia de transporte de diámetro estándar para comunicarse con PCRF redundantes.
Un aspecto importante de la tolerancia a errores de Gx es que las solicitudes de inicio de sesión y terminación del suscriptor se reintentan (reproducen) 24 horas hasta que se recibe una respuesta satisfactoria del PCRF. Puede emitir el clear network-access pcrf subscribers comando para borrar todos los suscriptores de PCRF.
Descripción de las interacciones de Gy entre el enrutador y el OCS
La información o las preguntas se intercambian por medio del protocolo Gy del Proyecto de Asociación de 3ª Generación (3GPP) entre el Sistema de Carga en Línea (OCS) y el enrutador que actúa como una Función de Cumplimiento de Políticas y Carga (PCEF). Las interacciones de PCEF de banda ancha (BPCEF) con el OCS utilizan la carga de sesiones en línea con determinación de unidad centralizada y clasificación centralizada. Opcionalmente, PCEF informa del uso y recibe autorizaciones adicionales de la OCS mediante el protocolo Gy.
A partir de Junos OS versión 17.3R1, se agrega soporte para funciones OCS y PCRF adicionales mediante los protocolos Gy y Gx. Las nuevas declaraciones:
accept-sdrse agrega para la partición PCRF en el nivel[edit access pcrf partition partition-name]de jerarquía .alternative-partition-namese agrega para la partición OCS en el nivel[edit access ocs partition partition-name]de jerarquía .
A partir de Junos OS versión 18.1R1, el PCEF de banda ancha proporciona la copia de seguridad de archivos para los datos de OCS cuando las rutas principal y alternativa a OCS no están disponibles. Las tramas CCR-GY-T se almacenan en los archivos en una ubicación remota. La copia de seguridad se admite en la jerarquía [edit access ocs partition partition-name].
Una vez completado el aprovisionamiento de suscriptores entre la función de control de políticas y carga de reglas (PCRF) y PCEF, el enrutador comienza a enviar las siguientes interrogaciones entre OCS y PCEF:
- Primer interrogatorio a la OCS
- Interrogatorio intermedio a la OCS
- Interrogatorio final a la OCS
- Recuperación de errores de conectividad
- Anular solicitudes de sesión
Primer interrogatorio a la OCS
Durante la primera interrogación, el enrutador envía una solicitud Diameter CCR que contiene un conjunto fijo de información requerida al servidor de carga OCS. Luego, el servidor de carga de OCS responde con tiempo de validez, grupos de calificación y cuotas de uso.
Para esta fase de implementación, el enrutador permite el acceso del suscriptor sin esperar a que la OCS responda, y la OCS siempre concede las cuotas necesarias.
Para configurar una lista de servicios de carga para comunicar información con la OCS a través del protocolo Gy, configure la charging-service-list ocs instrucción en el [edit access profile profile-name] nivel jerárquico. Los siguientes ejemplos muestran un intercambio de paquetes CCR-GY-I y CCA-GY-I:
El bit T (mensaje potencialmente retransmitido) se vuelve a calcular cuando se reenvía el CCR-GY-I. Esta marca se establece después de un procedimiento de tolerancia a fallos de vínculo para ayudar a eliminar las solicitudes duplicadas.
Ejemplo de paquete CCR-GY-I
CCR-GY-I ::= <Diameter Header: 272, REQ, PXY 16777238>
{ <Session-Id> }
{ Origin-Host: <configurable-string> }
{ Origin-Realm: <configurable-string> }
{ Destination-Realm: <configurable-string> }
{ Auth-Application-Id: 4 }
{ Service-Context-Id: 98924@customer.com }
{ CC-Request-Type: INITIAL_REQUEST(1) }
{ CC-Request-Number: 0 }
[ Destination-Host: <configurable-string> ] -- if configured
[ User-Name: <string> ]
[ Origin-State-Id: <u32> ] -- if configured to send
[ Event-Timestamp: <timestamp> ] -- login timestamp, if included by config
{ Subscription-Id:
{ Subscription-Id-Type: <received-from-pcrf> }
{ Subscription-Id-Data: <received-from-pcrf> }
}
{ Multiple-Services-Indicator: MULTIPLE_SERVICES_SUPPORTED(1) }
{ Multiple-Services-CC:
{ Service-Identifier: 7 }
{ Rating-group: 292 }
}
{ Multiple-Services-CC:
{ Service-Identifier: 7 }
{ Rating-group: 293 }
}
{ Multiple-Services-CC:
{ Service-Identifier: 7 }
{ Rating-group: 292 }
}
{ Multiple-Services-CC:
{ Service-Identifier: 1 }
{ Rating-group: 17 }
}
Ejemplo de paquete CCA-GY-I
CCA-GY-I ::= <Diameter Header: 272, REQ, PXY 16777238>
{ <Session-Id> }
{ Result-Code: DIAMETER_SUCCESS(2001) }
{ Origin-Host: <string> } -- should match dest-host if configured
{ Origin-Realm: <string> } -- should match dest-realm
{ Auth-Application-Id: 4 }
{ CC-Request-Type: INITIAL_REQUEST(1) }
{ CC-Request-Number: 0 }
{ CC-Session-Failover: FAILOVER_NOT_SUPPORTED(0) } -– ignored
}
{ Multiple-Services-CC:
{ Granted-Service-Unit:
{ CC-Time: 123456 }
{ CC-Total-Octets: 123455999000 }
}
{ Service-Identifier: 7 }
{ Rating-group: 292 }
{ Validity-Time: 7200 }
{ Result-Code: DIAMETER_SUCCESS(2001) }
}
{ Multiple-Services-CC:
{ Service-Identifier: 7 }
{ Rating-group: 293 }
{ Result-Code: DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE(4011) }
}
{ Multiple-Services-CC:
{ Service-Identifier: 7 }
{ Rating-group: 292 }
{ Result-Code: DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE(4011) }
}
{ Multiple-Services-CC:
{ Granted-Service-Unit:
{ CC-Time: 123456 }
{ CC-Total-Octets: 123455999000 }
}
{ Service-Identifier: 1 }
{ Rating-group: 17 }
{ Result-Code: DIAMETER_SUCCESS(2001) }
}
{ CC-Failure-Handling: TERMINATE(0) }
Interrogatorio intermedio a la OCS
Después de que el enrutador haya enviado un conjunto fijo de información requerida al servidor de carga de OCS, el servidor de carga de OCS responde con tiempo de validez, grupos de calificación y cuotas de uso. El tiempo de validez y los vencimientos de cuota activan eventos de interrogación intermedios.
Cada vez que se produce un evento desencadenante en el enrutador, se envía una solicitud de actualización a la OCS. Los siguientes ejemplos muestran un intercambio de paquetes CCR-GY-U (donde U representa UPDATE_REQUEST) y CCA-GY-U:
Ejemplo de paquete CCR-GY-U
CCR-GY-U ::= <Diameter Header: 272, REQ, PXY 16777238>
{ <Session-Id> }
{ Origin-Host: <configurable-string> }
{ Origin-Realm: <configurable-string> }
{ Destination-Realm: <configurable-string> }
{ Auth-Application-Id: 4 }
{ Service-Context-Id: 98924@customer.com }
{ CC-Request-Type: UPDATE_REQUEST(2) }
{ CC-Request-Number: <integer> }
[ Destination-Host: <configurable-string> ] -- if configured
[ User-Name: <string> ]
[ Origin-State-Id: <u32> ] -- if configured to send
[ Event-Timestamp: <timestamp> ] -- change timestamp, if included by config
{ Multiple-Services-Indicator: MULTIPLE_SERVICES_SUPPORTED(1) }
{ Multiple-Services-CC:
{ Used-Service-Unit:
{ Reporting-Reason: VALIDITY_TIME(4) }
{ CC-Time: 7200 }
{ CC-Total-Octets: 12345 }
{ CC-Input-Octets: 10000 }
{ CC-Output-Octets: 2345 }
}
{ Service-Identifier: 7 }
{ Rating-group: 292 }
}
{ Multiple-Services-CC:
{ Used-Service-Unit:
{ Reporting-Reason: FINAL(2) }
{ CC-Time: 334556 }
{ CC-Total-Octets: 12345 }
{ CC-Input-Octets: 10000 }
{ CC-Output-Octets: 2345 }
}
{ Service-Identifier: 1 }
{ Rating-group: 17 }
}
*[ More Multiple-Services-CC]
Ejemplo de paquete CCA-GY-U
CCA-GY-U ::= <Diameter Header: 272, REQ, PXY 16777238>
{ <Session-Id> }
{ Result-Code: DIAMETER_SUCCESS(2001) }
{ Origin-Host: <string> } -- should match dest-host if configured
{ Origin-Realm: <string> } -- should match dest-realm
{ Auth-Application-Id: 4 }
{ CC-Request-Type: UPDATE_REQUEST(1) }
{ CC-Request-Number: <integer> }
{ Multiple-Services-CC:
{ Granted-Service-Unit:
{ CC-Time: 123456 }
{ CC-Total-Octets: 123455999000 }
}
{ Service-Identifier: 7 }
{ Rating-group: 292 }
{ Validity-Time: 7200 }
{ Result-Code: DIAMETER_SUCCESS(2001) }
}
*[ More Multiple-Services-CC]
Interrogatorio final a la OCS
Cuando la aplicación cliente envía un aviso de cierre de sesión de suscriptor a AAA, Gy envía un mensaje CCR-GY-T (donde T representa TERMINATION_REQUEST) para notificar al OCS que el suscriptor aprovisionado se está terminando.
Cada vez que se produce un evento desencadenante en el enrutador, se envía una solicitud de terminación al OCS. Los siguientes ejemplos muestran un intercambio de paquetes CCR-GY-T y CCA-GY-T:
Ejemplo de paquete CCR-GY-T
CCR-GY-T ::= <Diameter Header: 272, REQ, PXY 16777238>
{ <Session-Id> }
{ Origin-Host: <configurable-string> }
{ Origin-Realm: <configurable-string> }
{ Destination-Realm: <configurable-string> }
{ Auth-Application-Id: 4 }
{ Service-Context-Id: 98924@customer.com }
{ CC-Request-Type: TERMINATE_REQUEST(2) }
{ CC-Request-Number: <integer> }
[ Destination-Host: <configurable-string> ] -- if configured
[ User-Name: <string> ]
[ Origin-State-Id: <u32> ] -- if configured to send
[ Event-Timestamp: <timestamp> ] -- logout timestamp, if included by config
{ Termination-Cause: DIAMETER_LOGOUT(1) }
{ Multiple-Services-CC:
{ Used-Service-Unit:
{ Reporting-Reason: FINAL(2) }
{ CC-Total-Octets: 12345 }
{ CC-Input-Octets: 10000 }
{ CC-Output-Octets: 2345 }
}
{ Service-Identifier: 7 }
{ Rating-group: 292 }
}
*[ More Multiple-Services-CC]
Ejemplo de paquete CCA-GY-T
CCA-GY-T ::= <Diameter Header: 272, REQ, PXY 16777238>
{ <Session-Id> }
{ Result-Code: DIAMETER_SUCCESS(2001) }
{ Origin-Host: <string> } -- should match dest-host if configured
{ Origin-Realm: <string> } -- should match dest-realm
{ Auth-Application-Id: 4 }
{ CC-Request-Type: TERMINATE_REQUEST(1) }
{ CC-Request-Number: <integer> }
Recuperación de errores de conectividad
Gy no se basa en el estado de conexión entre dispositivos para detectar interrupciones del enrutador u OCS, ya que algunos eventos no afectan el estado de la conexión y otros no se detectan cuando hay un proxy o relé de diámetro entre los dispositivos.
Para mitigar los errores de conectividad con el OCS, el enrutador utiliza los siguientes procedimientos de recuperación de errores:
Si OCS no está disponible, puede configurar para permitir el tráfico de suscriptores estableciendo la
force-continueinstrucción en el[edit access ocs partition partition-name]nivel de jerarquía.Nota:La
force-continueinstrucción es una instrucción de configuración obligatoria.Las preguntas no reconocidas primeras e intermedias se reproducen indefinidamente o hasta que el suscriptor cierre la sesión.
Los interrogatorios finales no reconocidos se repiten hasta por 24 horas.
El enrutador utiliza redundancia de transporte de diámetro estándar para comunicarse con OCS redundantes.
Puede configurar eventos de redundancia de transporte para desencadenar errores en el tráfico de la aplicación.
Un aspecto importante de la tolerancia a errores de Gy es que las solicitudes de inicio de sesión y terminación del suscriptor se reintentan (reproducen) 24 horas hasta que se recibe una respuesta satisfactoria de la OCS. Puede ejecutar el clear network-access ocs statistics comando para borrar todas las estadísticas de OCS.
Anular solicitudes de sesión
La OCS puede emitir una ASR (solicitud de interrupción de sesión) cuando el enrutador de la serie MX receptor recopila los datos finales y publica la interrogación final. Después de que el enrutador de la serie MX recibe la respuesta, detiene la actualización del OCS para la sesión involucrada.
Descripción general de la copia de seguridad de archivos Gy
El protocolo Gy, también conocido como OCS, se basa en informes de uso incremental mientras conserva los datos intermedios. Por lo tanto, el servidor OCS incluye múltiples mecanismos de protección contra fallas, como la redundancia de transporte de diámetro, la ruta alternativa a OCS y la copia de seguridad de archivos. A partir de Junos OS versión 18.1R1, PCEF de banda ancha proporciona la copia de seguridad de archivos cuando no hay rutas principales ni alternativas disponibles. Las tramas CCR-GY-T se almacenan en los archivos en una ubicación remota.
La copia de seguridad de OCS entra en vigor cuando caduca el tiempo de espera de respuesta final de OCS. Los datos se ponen en cola para el proceso de copia de seguridad y el cierre de sesión del suscriptor continúa con la finalización de la sesión pcrf. En todos los casos, las operaciones de copia de seguridad se controlan mediante los siguientes parámetros de configuración:
backup-limit: límite en el número total de entradas de copia de seguridad. Una vez alcanzado el límite, se produce un error en el inicio de sesión del nuevo suscriptor o se eliminan las entradas de copia de seguridad más antiguas en función de la configuración de desbordamiento de copia de seguridad.
backup-timeout— tiempo de espera para la operación de respaldo.
backup-overflow: controla la acción cuando el número de entradas de copia de seguridad supera el límite de copia de seguridad.
Copia de seguridad SFTP de OCS
stfp-backup es el primer mecanismo de copia de seguridad implementado. Las operaciones se controlan mediante los siguientes parámetros:
tiempo de espera de acumulación: los archivos se escriben después del tiempo de acumulación de archivos del primer envío CCR-GY-T.
acumulation-count: los archivos se escriben después de que se complete el número de solicitudes para file-account-count.
tamaño de acumulación: los archivos se escriben después de que su tamaño alcanza el límite de tamaño de acumulación.
retry-interval: cada operación de escritura fallida se vuelve a intentar después de este intervalo hasta que se acumula el tiempo de espera de copia de seguridad.
response-timeout: el tiempo de espera de la respuesta de un comando sftp individual.
El servidor OCS SFTP-Backup se configura por su dirección, inicio de sesión, contraseña, directorio y prefijo de archivo. Existe un directorio de destino de forma predeterminada, si no, se crea el directorio. Si ya existe un archivo de destino con el mismo nombre, se sobrescribirá.
Beneficios de Gy File Backup
Proporciona otra forma de lidiar con la inestabilidad de la red interna.
Comprender las interacciones entre PCRF, PCEF y OCS
La Función de Política y Reglas de Cobro (PCRF), la Función de Cumplimiento de Políticas y Cobro (PCEF) y el Sistema de Cobro en Línea (OCS) interactúan para proporcionar y cobrar por los servicios del suscriptor. Estas interacciones incluyen el inicio de sesión del suscriptor, las actualizaciones del servicio a las sesiones existentes, la conexión y el monitoreo, y la terminación y el cierre del suscriptor.
La Figura 3 muestra los componentes de una arquitectura general de Política y Control de Carga (PCC) del Proyecto de Asociación de 3ª Generación (3GPP). El PCRF envía las reglas al PCEF en el enrutador de la serie MX mediante el protocolo 3GPP Gx. El PCEF proporciona detección de flujo de datos de servicio y aplica las reglas recibidas del PCRF. Opcionalmente, el PCEF interactúa con la OCS mediante el protocolo 3GPP Gy para recuperar políticas y autorización de cobro por cuotas y control de crédito. Las interacciones de PCEF de banda ancha (BPCEF) con el OCS utilizan la carga de sesiones en línea con determinación de unidad centralizada y clasificación centralizada.
la arquitectura 3GPP PCC
El PCRF también puede impulsar cambios en las reglas aplicadas a una sesión existente. Sin embargo, no se admiten modificaciones en los grupos de calificación. También debe establecer la force-continue instrucción en el nivel .[edit access ocs partition partition-name] hierarchy level
- Interacciones de inicio de sesión
- Interacciones de actualización
- Interacciones de vencimiento de cuota y tiempo de validez
- Interacciones de conexión y monitoreo
- Interacciones de cierre de sesión
Interacciones de inicio de sesión
Esta secuencia de eventos de inicio de sesión se activa mediante la detección del flujo de datos de servicio en el PCEF. Esto suele ser un paquete DHCP DISCOVER o PPPoE PADI enviado por el suscriptor (el CPE):
El PCEF envía un CCR-GX-I al PCRF con información que identifica al suscriptor.
El PCRF responde con un CCA-GX-I al PCEF con instrucciones sobre qué reglas aplicar para el suscriptor.
El PCEF instala los servicios/reglas solicitados para el suscriptor.
Si se utiliza OCS, el PCEF envía la primera interrogación a la OCS utilizando un mensaje CCR-GY-I, y la OCS envía los informes aplicables a la PCRF utilizando un mensaje CCA-GY-I.
Si está configurado, el PCEF envía una notificación por medio de un mensaje CCR-GX-U al PCRF después de que se procesen los servicios/reglas solicitados.
La regla se notifica al PCRF como inactiva cuando se cumplen las dos condiciones siguientes:
Se produce un error en la creación de instancias de perfil dinámico de servicio.
Resource-Allocation-Notification (ENABLE_NOTIFICATION) está configurado para la regla de cobro.
Cuando la regla se notifica como inactiva, no afecta al inicio de sesión del suscriptor ni a otras reglas.
La regla se informa al PCRF como activa cuando se cumplen todas las condiciones siguientes:
La creación de instancias de perfil dinámico de servicio se realiza correctamente.
Resource-Allocation-Notification (ENABLE_NOTIFICATION) está configurado para la regla de cobro.
El desencadenador del evento SUCCESSFUL_RESOURCE_ALLOCATION se establece en la solicitud.
El informe no se envía cuando no hay reglas para informar.
El PCRF responde con un mensaje CCA-GX-U.
El PCEF activa los servicios para el suscriptor.
Interacciones de actualización
Esta secuencia de eventos de actualización se activa mediante un mensaje RAR-GX-U recibido por el PCEF del PCRF.
Si la solicitud de actualización contiene alguna instalación o modificación de reglas con grupos de calificación, el PCEF rechaza la solicitud; de lo contrario, acusa recibo de la solicitud enviando un mensaje RAA-GX-U al PCRF.
El PCEF inicia el proceso de eliminación e instalación del servicio.
El PCEF espera a que se complete el proceso de eliminación e instalación del servicio y, si corresponde, inicia el proceso de recopilación de datos final para informar a la OCS. Cuando se recopilan las estadísticas finales, el PCEF envía una solicitud CCR-GY-U para notificar a la OCS. Esto forma parte del proceso de eliminación de un servicio existente en cada uno de los siguientes casos:
Cuando el servicio que se va a quitar tiene un grupo de calificación.
Cuando se agregó una nueva regla con un grupo de calificación.
Cuando se eliminaron y agregaron reglas con un grupo de calificación.
El PCEF envía los informes aplicables al PCRF mediante un mensaje CCR-GX-U.
La regla se notifica al PCRF como inactiva cuando se cumplen las dos condiciones siguientes:
Se produce un error en la creación de instancias de perfil dinámico de servicio.
Resource-Allocation-Notification (ENABLE_NOTIFICATION) está configurado para la regla de cobro.
Cuando la regla se notifica como inactiva, no afecta a la actualización ni a otras reglas.
La regla se informa al PCRF como activa cuando se cumplen todas las condiciones siguientes:
La creación de instancias de perfil dinámico de servicio se realiza correctamente.
Resource-Allocation-Notification (ENABLE_NOTIFICATION) está configurado para la regla de cobro.
El desencadenador del evento SUCCESSFUL_RESOURCE_ALLOCATION se establece en la solicitud.
El informe no se envía cuando no hay reglas para informar.
Interacciones de vencimiento de cuota y tiempo de validez
Para las caducidades de cuota y las interacciones de tiempo de validez, el enrutador envía una interrogación intermedia a la OCS mediante un mensaje CCR-GY-U y procesa la respuesta de la OCS.
Interacciones de conexión y monitoreo
Al establecer una conexión con el servidor PCRF, OCS o Diameter Relay/Proxy, el daemon Diameter realiza una transacción estándar de solicitud de intercambio de capacidades (CER)/respuesta de intercambio de capacidades (CEA). Utilice la infraestructura existente de Junos OS Diameter para configurar una topología adecuada con las funciones de redundancia necesarias. Además, puede usar la misma conexión de diámetro para comunicaciones PCRF y OCS, y otras aplicaciones.
Los siguientes ejemplos muestran dos escenarios diferentes de conexión de comunicación:
Ejemplo de CER con una conexión dedicada utilizada para comunicarse con la PCRF
CER ::= <Diameter Header: 257, REQ>
{ Origin-Realm: CSim.PCRF.net }
{ Origin-Host: MX-GWR3 }
{ Host-IP-Address: 10.8.52.91 }
{ Vendor-Id: 2636 }
{ Product-Name: JUNOS }
[ Origin-State-Id: 7777 ] -- if configured
{ Supported-Vendor-Id: 10415 }
{ Supported-Vendor-Id: 2636 } -- have Juniper VSAs
{ Auth-Application-Id: 16777238 }
{ Vendor-Specific-Application-Id {
{ Vendor-Id: 10415 }
{ Auth-Application-Id: 16777238 }
{ Acct-Application-Id: 16777238 }
}
Si establece la send-origin-state-id instrucción para el enrutador en el nivel de jerarquía o[edit access ocs partition partition-name], el ID de estado de origen se incluye en mensajes [edit access pcrf partition partition-name] de nivel de diámetro, tales como: CER, Solicitud de guardián de dispositivos (DWR)/Respuesta de guardián de dispositivos (DWA) y Solicitud de par de desconexión (DPR)/Respuesta de par de desconexión (DPA).
Ejemplo de CER con una conexión dedicada utilizada para comunicarse con PCRF y OCS
CER ::= <Diameter Header: 257, REQ>
{ Origin-Realm: CSim.PCRF.net }
{ Origin-Host: MX-GWR3 }
{ Host-IP-Address: 10.8.52.91 }
{ Vendor-Id: 2636 }
{ Product-Name: JUNOS }
[ Origin-State-Id: 7777 ] -- if configured
{ Supported-Vendor-Id: 10415 }
{ Supported-Vendor-Id: 2636 } -- have Juniper VSAs
{ Auth-Application-Id: 4 } -- this is the difference with previous
{ Auth-Application-Id: 16777238 }
{ Vendor-Specific-Application-Id {
{ Vendor-Id: 10415 }
{ Auth-Application-Id: 16777238 }
{ Acct-Application-Id: 16777238 }
}
El campo y el valor Auth-Application-Id: 4 es el ID de la aplicación de autenticación para el OCS. Esta es la diferencia entre el primer y el segundo ejemplo.
Las conexiones se supervisan y administran mediante mensajes DWR/DWA y DPR/DPA estándar.
Interacciones de cierre de sesión
Esta secuencia de eventos de cierre de sesión se activa por cualquiera de los siguientes procedimientos:
Una solicitud de cierre de sesión del suscriptor, como un paquete RELEASE DHCP o PPPoE PADT.
El PCEF recibe un RAR del PCRF con una solicitud para finalizar una sesión de suscriptor.
La siguiente secuencia se produce cuando se activa el cierre de sesión:
La infraestructura del sistema notifica a OCS que se ha iniciado el cierre de sesión del suscriptor.
Si corresponde, la OCS inicia el proceso final de recopilación de datos.
Si el servicio que se va a quitar tiene un grupo de calificación, se deben informar los datos finales de este servicio. La OCS comienza la recopilación final de datos según sea necesario.
Tanto el PCRF como el PCEF esperan a que se complete el proceso final de interrogatorio.
El PCEF envía una solicitud de terminación (mensaje CCR-GX-T) al PCRF y luego espera la respuesta (mensaje CCA-GX-T) del PCRF.
El PCEF completa el proceso de cierre de sesión del suscriptor.
Descripción de los mensajes ascendentes y descendentes para la PCRF
El enrutador de la serie MX implementa una serie de medidas para proteger contra la sobrecarga de datos para las transacciones descendentes y ascendentes. Las transacciones posteriores están protegidas mediante la limitación de la entrada de la red en condiciones de sobrecarga. Las transacciones ascendentes se protegen limitando tanto el número de solicitudes pendientes como utilizando reintentos lentos del primer mensaje no reconocido para una recuperación confiable.
Las funciones integradas del entorno de la Función de cumplimiento de políticas y cobros (PCEF) proporcionan protección contra la sobrecarga resultante de una tasa de inicio de sesión excesiva de suscriptores. Si hay demasiados cambios de reglas y operaciones de desconexión debido a mensajes de solicitud de reautorización (RAR-GX), el enrutador envía una respuesta de respuesta de reautorización (RAA-GX) con el código de resultado: DIAMETER_TOO_BUSY (3004).
Dentro del componente AAA del enrutador, una sesión representa una entrada de sesión de suscriptor (cliente) en la base de datos de sesiones (SDB).
Esta es una representación de la sesión del suscriptor solamente; No es un identificador permanente independiente de la conexión, similar a un número de teléfono. Si el suscriptor se desconecta y se vuelve a conectar, y recibe un ID de sesión diferente para la segunda conexión.
El ID de sesión se transmite en el ID de sesión (código AVP 263). Existe una correspondencia uno a uno entre una sesión y el valor de ID de sesión. El ID de sesión es global y eternamente único porque está vinculado a la identidad única del enrutador y se utiliza para identificar una sesión de usuario sin ninguna referencia a otra información. El mismo suscriptor podría asignarse a varias sesiones, como una de un evento de desconectar y volver a conectarse. Sin embargo, la sesión siempre está asociada con un único suscriptor. El AVP con ID de sesión tiene el siguiente formato predeterminado:
Session-Id AVP ::=<DiameterIdentity>;
<upper 32 bits of the AAA COMPONENT session-id>;
<lower 32 bits of the AAA COMPONENT session-id>;
El DiameterIdentity campo es el valor que configura para el host de origen de Diameter. Los ID de sesión internos son enteros de 64 bits asignados en orden ascendente. Ambas partes numéricas de la cadena de ID de sesión se generan mediante %010u el formato, lo que garantiza que los valores de AVP de ID de sesión estén en el mismo orden lexicográficamente que las sesiones internas de 64 bits.
También puede configurar el enrutador para que utilice un ID de sesión extendido, en el que anexa una marca de sesión al ID. La marca de sesión consiste en la hora UTC en que el enrutador crea el CCR-GX-I. En este caso, el AVP de ID de sesión tiene el siguiente formato:
Session-Id AVP ::=<DiameterIdentity>;
<upper 32 bits of the AAA COMPONENT session-id>;
<lower 32 bits of the AAA COMPONENT session-id>;
<32 bits of UTC time>;
Los primeros 64 bits del AVP permanecen sin cambios, lo que permite al PCRF rastrear reinicializaciones.
Siempre configure el enrutador para que utilice el ID de sesión extendido cuando reinicialice la sesión en respuesta a errores del servidor PCRF. Consulte Descripción de las interacciones Gx entre el enrutador y el PCRF para obtener más información.
La función de políticas y reglas de cobro (PCRF) envía reglas y mensajes al PCEF mediante el protocolo 3GPP Gx y la interfaz de políticas en línea. Los protocolos PCRF y Gx incluyen los siguientes mensajes:
Mensajes ascendentes comunes
Los mensajes ascendentes para Credit Control Response for Initiation, Update, and Termination (CCR-GX-I, CCR-GX-U y CCR-GX-T) y RAA-GX pueden incluir las siguientes reglas, parámetros y datos:
- Marca de tiempo del evento AVP
- Notificaciones de instalación de reglas de carga
- Comandos de activación de eventos
Marca de tiempo del evento AVP
A continuación se muestra un AVP para los mensajes CCR-GX-I, CCR-GX-U y CCR-GX-T, y RAA-GX entre el PCRF y Gx:
{ Event-Timestamp: <timestamp> }
Si configura el AVP de marca de tiempo del evento, se incluye en el mensaje descendente. La definición del mensaje en la Tabla 11 varía según la transacción.
Mensaje |
Definición |
|---|---|
CCR-GX-I |
Marca de tiempo de inicio de sesión del suscriptor |
Notificaciones de instalación de reglas de carga
Las siguientes notificaciones muestran un ejemplo de instalación fallida y un ejemplo de instalación correcta de instalación de reglas de carga para mensajes CCR-GX-U entre el PCRF y Gx:
Si los informes no reconocidos aún están pendientes en el momento del cierre de sesión del cliente, estas reglas de cobro se incluyen en los mensajes CCR-GX-T.
Notificación que informa de un error en la instalación de una regla
{ Charging-Rule-Report
{ Charging-Rule-Name: <string> }
{ Charging-Rule-Name: <string> }
{ PCC-Rule-Status: INACTIVE(1) }
{ Rule-Failure-Code: UNKNOWN_RULE_NAME(1) }
}
Notificación que informa de que la instalación de una regla se ha realizado correctamente
{ Charging-Rule-Report
{ Charging-Rule-Name: <string> }
{ Charging-Rule-Name: <string> }
{ PCC-Rule-Status: ACTIVE(0) }
}
Comandos de activación de eventos
A continuación se muestra un comando de activación de evento predefinido para los mensajes CCR-GX y RAA-GX entre el PCRF y Gx:
{ Event-Trigger: SUCCESSFUL_RESOURCE_ALLOCATION(22) }
Mensajes descendentes comunes
Los mensajes posteriores para Credit Control Answer for Initiation and Update (CCA-GX-I y CCA-GX-U) y RAR-GX pueden incluir las siguientes reglas predefinidas con parámetros y datos:
El mensaje CCA-GX-T (terminación) no se incluye como mensaje descendente.
- Comandos de instalación de reglas de carga
- Comandos de eliminación de reglas de carga
- Comandos de activación de eventos
Comandos de instalación de reglas de carga
En el ejemplo siguiente se muestran comandos de instalación de reglas predefinidos para mensajes CCA-GX y RAR-GX entre PCRF y Gx:
{ Charging-Rule-Install
{ Charging-Rule-Name: “fixed-cos” }
{ Charging-Rule-Definition:
{ Charging-Rule-Name: “firewall” }
{ Service-Identifier: 10 }
{ Rating-Group: 292 }
{ Juniper-Param-V4-Input-Filter: “my_input_filter” }
{ Juniper-Param-V4-Output-Filter: “my_output_filter” }
}
[ Resource-Allocation-Notification: ENABLE_NOTIFICATION(0) ]
}
Es posible que algunos PCRF no puedan generar un AVP de notificación de asignación de recursos. Como resultado, la report-resource-allocation instrucción en el nivel de [edit access pcrf partition partition-name] jerarquía proporciona informes generados de forma predeterminada.
Comandos de eliminación de reglas de carga
En el ejemplo siguiente se muestran comandos de eliminación de reglas predefinidos para mensajes CCA-GX y RAR-GX entre PCRF y Gx:
{ Charging-Rule-Remove
{ Charging-Rule-Name: “predefined-ftp” }
{ Charging-Rule-Name: “firewall” }
}
El enrutador procesa todas las operaciones de eliminación de reglas antes de cualquier operación de instalación de reglas, lo que le permite solicitar simultáneamente la eliminación de una regla existente y la instalación de una regla que tenga el mismo nombre base en una sola transacción.
Comandos de activación de eventos
A continuación se muestra un comando de activación de eventos predefinido para los mensajes CCA-GX y RAR-GX entre el PCRF y Gx:
{ Event-Trigger: SUCCESSFUL_RESOURCE_ALLOCATION(22) }
Si existe el valor de activación SUCCESSFUL_RESOURCE_ALLOCATION (22) en los datos descendentes, el PCEF de banda ancha informa de las instalaciones correctas de las reglas marcadas con Resource-Allocation-Notification AVP en el AVP Charging-Rule-Install.
Es posible que algunos PCRF no puedan generar este desencadenador de eventos. Como resultado, la report-successful-resource-allocation instrucción en el nivel de [edit access pcrf partition partition-name] jerarquía proporciona informes generados de forma predeterminada.
Configuración de la partición OCS
El sistema de carga en línea (OCS) funciona dentro de un contexto específico de instancia lógica system:enrutamiento, denominado partición.
Actualmente, solo se admite una partición única; Debe configurarlo en el contexto predeterminado de instancia lógica System:Routing.
Antes de configurar la partición OCS, realice la siguiente tarea:
Configure la instancia de Diameter en el
[edit diameter]nivel de jerarquía. Consulte Configuración de diámetro.
La configuración de la partición OCS consiste en asignar un nombre a la partición y, a continuación, definir o asociar numerosos parámetros para definir las características de la partición.
Para configurar la partición OCS:
Configuración de la partición PCRF
La función de control de políticas y carga de reglas (PCRF) funciona dentro de un contexto específico de instancia de enrutamiento y sistema, denominado partición.
Actualmente, solo se admite una partición única; Debe configurarlo en el contexto predeterminado de instancia lógica System:Routing.
Antes de configurar la partición PCRF, realice la tarea siguiente:
Configure la instancia de Diameter en el
[edit diameter]nivel de jerarquía. Consulte Configuración de diámetro.
La configuración de la partición PCRF consiste en asignar un nombre a la partición y, a continuación, definir o asociar numerosos parámetros para definir las características de la partición.
Para configurar la partición PCRF:
Configuración de parámetros globales de OCS
Puede configurar atributos globales del sistema de cobro del servicio de control de crédito de diámetro del Proyecto de asociación de 3ª generación (3GPP) para el sistema de cobro en línea (OCS), que interactúa con la función de cumplimiento de políticas y cobro (PCEF).
Actualmente, el único atributo global configurable es el identificador de contexto de servicio asignado por el operador o proveedor de servicios. Este valor corresponde al Service-Context-Id AVP, que junto con Service-Identifier-AVP identifica de forma única y global el servicio de control de créditos de Diameter.
Para configurar los parámetros globales de OCS:
Configure el identificador de contexto del servicio.
[edit access ocs global] user@host# set service-context-id service-context
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.