Política de 3GPP y control de carga para aprovisionamiento y contabilidad por cable
Política de 3GPP y descripción general del control de carga para aprovisionamiento y contabilidad por cable
La política de control de carga (PCC) del proyecto de asociación de tercera generación (3GPP) ofrece la unificación del aprovisionamiento y la contabilidad por cable para los clientes. La Figura 1 muestra los componentes de una arquitectura general de 3GPP PCC.
Los cuatro componentes principales de la arquitectura PCC son:
Función de políticas y reglas de carga (PCRF): un punto de decisión de políticas centralizadas que implementa políticas empresariales y reglas de carga para asignar recursos de red de banda ancha y administra los cargos basados en el flujo para suscriptores y servicios. La PCRF lleva las reglas a la función de cumplimiento de políticas y carga (PCEF) mediante el protocolo Gx 3GPP y la interfaz de política en línea.
Función de cumplimiento de políticas y carga (PCEF): una función que proporciona control de tráfico de 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 carga en línea (OCF) dentro del sistema de carga en línea (OCS) mediante el protocolo 3GPP Gy para recuperar la política y la autorización de carga por cuotas y control de crédito.
Sistema de carga en línea (OCS): es el componente responsable de interactuar con el PCEF. Opcionalmente, el PCEF informa el uso y recibe autorizaciones adicionales de OCS mediante el protocolo 3GPP Gy. Las interacciones de PCEF de banda ancha (BPCEF) con el OCS utilizan carga de sesión en línea con determinación unitaria centralizada y clasificación centralizadas.
Sistema de carga fuera de línea (OFCS): un proceso en el que se recopila la información de carga para el uso de recursos de red al mismo tiempo que ese uso de recursos. Si no se requiere autorización basada en crédito, el PCEF aplica políticas e informa el uso de la OFCS mediante el protocolo 3GPP Gz. También puede usar OCS como destino principal de la contabilidad y usar la OFCS como copia de seguridad.
La tabla 1 enumera las diferencias de funcionalidad entre PCRF y PCEF.
Funcionalidad |
PCRF |
PCEF |
|---|---|---|
Carga de la implementación de políticas |
Involucrado en diferentes niveles; agrega información dentro de la red de alojamiento y se considera parte de la arquitectura PCC. |
Involucrado en diferentes niveles; ubicado en la puerta de enlace. |
Funciones incluidas |
Incluye principalmente decisiones de control de políticas y funciones de control basadas en el flujo. |
Incluye el cumplimiento de políticas y funciones de carga basadas en el flujo. |
Reglas PCC predefinidas |
La activación o desactivación de reglas PCC predefinidas solo puede ser realizada por el PCRF. |
Preconfigurado por el PCEF. |
Interacciones de carga en línea y fuera de línea |
No compatible |
Apoyado |
Los otros tres componentes que componen la arquitectura 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 una PCC dinámica. La función de aplicación extrae la información de sesión de la señalización de la aplicación y proporciona información relacionada con la sesión de la aplicación al PCRF mediante el protocolo Rx.
Repositorio de perfiles de suscripción (SPR): el SPR contiene información de suscriptores y suscripciones según la red de datos por paquete (PDN). El protocolo Sp permite que el PCRF solicite información de suscripción relacionada con el servicio o sesión de un suscriptor.
Función de notificación de eventos y enlace al portador (BBERF): la regla de PCC debe asignarse a un portador de IP en particular para garantizar que los paquetes reciban el tratamiento QoS adecuado. La asociación entre una regla de PCC y un portador se denomina vinculante al portador. La ubicación del 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 política 3GPP y la arquitectura de control de carga
Proporciona un marco de trabajo 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 carga para suscriptores de cable de banda ancha
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 de tráfico de usuario y calidad de 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 control de políticas y reglas de carga (PCRF). 3GPP define Gx como el protocolo de política en línea entre el PCRF y el PCEF para proporcionar control sobre las políticas 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ítica empresarial para asignar recursos de red de banda ancha y administra los cargos basados en flujos para suscriptores y servicios. Opcionalmente, el PCEF interactúa con el sistema de carga en línea (OCS) mediante el protocolo 3GPP Gy para recuperar la política y la autorización de carga por cuotas y control de crédito.
PCEF ofrece soporte para los siguientes entornos:
Entorno de acceso por cable
Para los suscriptores móviles, el equipo del usuario solicita servicios; para los suscriptores de cable de banda ancha, el PCRF solicita servicios. En el entorno de cable, PCRF funciona como el solicitante de servicio, y el PCEF funciona como receptor y ejecutor de servicios.
La adaptación del modelo PCC en un entorno de cable ofrece los siguientes beneficios:
Conveniencia
Tecnología avanzada
Ya implementado por la sucursal inalámbrica de la operadora que a menudo proporciona un negocio mucho más grande que la sucursal por cable
El PCRF controla el PCEF mediante la inserción de reglas de carga. Las reglas de carga se reutilizan como reglas de servicio (política) para insertar políticas. Las reglas de carga también pueden tener un grupo de calificación asociado o una clave de carga. Como resultado, la configuración de PCEF debe definir reglas de carga y asignación entre los servicios de control de crédito (cc-services) y los grupos de calificación.
En muchos casos, los servicios de contabilidad 3GPP del sistema de carga sin conexión (OCS) y el sistema de carga sin conexión (OFCS) requieren que el número de directorio internacional de suscriptores de la estación móvil (MSISDN) se utilice 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 una MSISDN asociada, esta información no está disponible para los suscriptores de línea por cable. Para permitir que el PCRF pase dinámicamente los parámetros de ID de suscripción y admita una variedad de configuración de autenticación, autorización y aprovisionamiento, los pares de atributo-valor (AVP) de Juniper en la tabla 2 se asignaron desde el espacio de ID de proveedor de Juniper (2636) atributo específico del proveedor (VSA).
Si no se recibe ningún ID de suscripción dinámica, no se inician ni las comunicaciones de OCS ni OFCS.
Nombre de AVP |
ID de proveedor |
Tipo AVP |
Tipo de diámetro |
Marca de diámetro |
|---|---|---|---|---|
Indicador de suscripción de Juniper Dyn |
2636 |
10001 |
Enum |
V |
Juniper-Dyn-Subscription-Id |
2636 |
10002 |
Agrupados |
VM |
Juniper-Dyn-Subscription-Id-Type |
2636 |
10003 |
Entero32 |
VM |
Juniper-Dyn-Subscription-Id-Data |
2636 |
10004 |
UTF8String |
VM |
El sistema de cliente (enrutador) envía el AVP juniper-Dyn-Subscription-Id-Indicator para indicar compatibilidad con 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ó soporte. 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 usar un AVP de id de suscripción estándar para comunicar el ID de suscripción dinámica al enrutador.
Si el PCRF envía Juniper-Dyn-Subscription-Id y Subscription-Id, se utilizará el valor Del id de suscripción.
En muchos casos, los suscriptores por cable solo admiten una familia de IP, que es información necesaria tanto para el servicio AAA como para el PCRF. Para indicar esta información, el AVP del indicador de la familia de la red de Juniper se asignó del VSA del espacio de ID de proveedor de Juniper (2636) en la tabla 3.
Nombre de AVP |
ID de proveedor |
Tipo AVP |
Tipo de diámetro |
Marca de diámetro |
|---|---|---|---|---|
Indicador de la familia de red de Juniper |
2636 |
10010 |
Enum |
V |
El sistema de cliente (enrutador) envía el AVP del indicador de la familia de red de Juniper para indicar qué familias de red están asociadas con la solicitud de servicio y son compatibles con el suscriptor. Cuando configure el AVP del indicador de la familia de red de Juniper para indicar la familia de red asociada, el sistema envía la información al PCRF. El indicador de la familia de la red de Juniper tiene cuatro valores:
NO ESPECIFICADO (0)
IPV4_FAMILY (1)
IPV6_FAMILY (2)
IPV4_IPV6_FAMILY (3)
Los clientes de cable a menudo controlan los servicios de usuario únicamente a través de la PCRF y utilizan el OCS como un mecanismo conveniente de monitoreo de uso en tiempo real, en lugar de como una unidad de cumplimiento. Para reducir el número de posibles configuraciones de OCS erróneas, incluya la force-continue instrucción en el [edit access ocs partition partition-name] nivel jerárquico para obligar al PCEF de banda ancha (BPCEF) a limitar el impacto de las respuestas negativas de los OCS y los vencimientos de cuotas, e impedir 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 a este grupo al OCS.
Entorno de Junos OS
Hay tres categorías de perfiles dinámicos dentro del entorno de Junos OS:
perfiles dinámicos de cliente
cos-service-dynamic-profiles
firewall-service-dynamic-profiles
Los perfiles dinámicos del cliente y los perfiles de cos-service-dynamic definen el ancho de banda y otras características de los servicios que se proporcionan a un suscriptor; los perfiles de servicio de firewall realizan filtrado y conteo de uso. Para todas las categorías de perfiles dinámicos, el nombre del servicio-dynamic-profile se utiliza como el valor de un AVP de regla de carga.
Cuando el service-dynamic-profile no tiene variables o cuando se solicitan los valores predeterminados proporcionados en la definición de service-dynamic-profile, no se requieren elementos adicionales. Para proporcionar valores personalizados para un perfil dinámico de servicio, utilice el AVP de carga-regla-definición con VSA adicionales.
La PCRF usa 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 posicionaal para parte del nombre de regla. El AVP de información de redirección (ID de proveedor 10415 y tipo 1085) proporciona un valor para el parámetro Redirect-URL.
Para cada nombre posible de parámetro de perfil dinámico de servicio solicitado por los clientes, se define un nuevo VSA de parámetros de Juniper. En la Tabla 4 se describe el conjunto inicial de VSA de parámetros de Juniper fijos.
Parámetro |
Nombre de VSA |
ID de proveedor |
Tipo |
Tipo de diámetro |
|---|---|---|---|---|
Cos-Tcp |
Juniper-Param-Cos-Tcp |
2636 |
10005 |
UTF8String |
Firewall-entrada-filtro V4 |
Juniper-Param-V4-Firewall-Input-Filter |
2636 |
10006 |
UTF8String |
Firewall-salida-filtro V4 |
Juniper-Param-V4-Firewall-Output-Filter |
2636 |
10007 |
UTF8String |
Firewall-entrada-filtro V6 |
Juniper-Param-V6-Firewall-Input-Filter |
2636 |
10008 |
UTF8String |
Firewall-salida-filtro V6 |
Juniper-Param-V6-Firewall-Output-Filter |
2636 |
10009 |
UTF8String |
Si el PCRF requiere que el PCRF indique parámetros o el Service-Identifier and Rating Group, se utilizará el AVP de la regla de carga y definición; de lo contrario, se utiliza el AVP de la 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 haya una combinación de Identificador de servicio y Rating-Group, o cuando solo se especifique el Service-Identifier o solo el Rating-Group, 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 Diámetro se intercambian mediante el protocolo Gx del proyecto de asociación de tercera 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 cumplimiento de políticas y carga (PCEF).
A partir de Junos OS versión 17.3R1, se agrega compatibilidad con funciones adicionales de OCS y PCRF mediante los protocolos Gy y Gx. Las nuevas instrucciones:
accept-sdrse agrega para la partición PCRF en el nivel jerárquico[edit access pcrf partition partition-name].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 suscriptores:
- Inicio de sesión del suscriptor
- Recuperación de errores de inicio de sesión del suscriptor
- Actualización del suscriptor
- Cerrar sesión del suscriptor
- Desconexión del suscriptor
- Recuperación de errores de conectividad
Inicio de sesión del suscriptor
El enrutador envía una solicitud CCR de diámetro que contiene un conjunto fijo de información necesaria a un administrador de políticas (PCRF) y recibe una respuesta de CCA que contiene políticas y otra información. El aprovisionamiento de Gx está habilitado para los suscriptores cuando se incluye la provisioning-order pcrf instrucción en el [edit access profile profile-name] nivel de jerarquía. Cuando una aplicación solicita AAA para activar la sesión del suscriptor, el enrutador envía un mensaje CCR-GX-I (donde represento INITIAL_REQUEST) al PCRF para solicitar un conjunto fijo de información de aprovisionamiento para la sesión del suscriptor, y recibe un mensaje de respuesta CCA-GX-I que contiene políticas y otra información, incluido el AVP de código de resultado (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 recalcula cuando se resiente el CCR-GX-I. Este indicador se establece después de un procedimiento de conmutación por error de vínculo para quitar 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 regla en el CCA-GX-I, se instala la regla predeterminada.
Todos los activadores de eventos, incluidos los que aún no están definidos, son aceptables. Sin embargo, solo unos pocos activadores de eventos realmente generan eventos cuando se implementan.
El PCRF devuelve un mensaje CCA-GX-I que incluye el AVP del código de resultado (código AVP 268) que se asigna a las categorías de resultados enumeradas en la tabla 5.
Valor de código de resultado-AVP |
Categoría de resultados |
|---|---|
SUCCESS(2001), LIMITED_SUCCSS(2002) y mensaje válido |
Conceder |
AUTHENTICATION_REJECTED(4001), UNKNOWN_SESSION_ID(5002), AUTHORIZATION_REJECTED(5003) y USER_UNKNOWN(5030) |
Negar |
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 y iguales que 5000, y todos los AVP de código de resultado de error de protocolo de diámetro mayores y iguales que 3000 y menores que 4000 |
Falla permanente |
Otros AVPs de código de resultados para mensajes no válidos o sin respuesta |
Fracaso |
Como se muestra en la Tabla 6, el procesamiento de respuestas CCA-GX-I depende de tres factores:
Si el tiempo de espera de la decisión local ha vencido
El marco de la decisión local
La categoría de resultados
La tabla 6 también contiene acciones de vencimiento de tiempo de espera de decisión local PCRF.
Tiempo de espera de la decisión local de PCRF |
Decisión local de PCRF |
Categoría de resultados |
Acción |
|---|---|---|---|
No vencido |
– |
Conceder |
Desactive el temporizador de decisión local, aplique las reglas del CCA-GX-I, notifique al sistema de carga en línea (OCS) y, luego, reconozca la activación del suscriptor. |
No vencido |
– |
Negar |
Desactive el temporizador de decisión local y no se active el suscriptor. |
No vencido |
– |
Fracaso |
Vuelva a intentar el CCA-GX-I hasta que el tiempo de espera de la decisión local. |
No vencido |
Conceder |
Falla permanente |
Desactive el temporizador de decisión local, aplique la regla predeterminada, reconozca la activación del suscriptor y, luego, vuelva a intentar el CCA-GX-I. |
No vencido |
Negar |
Falla permanente |
No se active el suscriptor e inicie el proceso de cierre de sesión del suscriptor. |
A la fecha de vencimiento |
Conceder |
– |
Aplique la regla predeterminada, vuelva a intentar el CCA-GX-I por tiempo indeterminado y reconozca la activación del suscriptor. |
A la fecha de vencimiento |
Negar |
– |
No se active el suscriptor e inicie el proceso de cierre de sesión del suscriptor. |
Caducado |
Conceder |
Conceder |
Si el CCA-GX-I contiene reglas, quite las reglas predeterminadas e instale las reglas recibidas y, luego, notifique al OCS y confirme la activación del suscriptor. |
Caducado |
Conceder |
Negar |
Cierre sesión en el cliente. |
Caducado |
Conceder |
Fracaso |
Siga reintentar el CCA-GX-I por tiempo indeterminado. |
Caducado |
Conceder |
Falla permanente |
Haga una pausa larga y, luego, vuelva a intentar el CCA-GX-I. |
Caducado |
Negar |
Negar |
Si el suscriptor sigue sin iniciar 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 AAA para autenticar al suscriptor.
La autenticación comienza si el perfil de acceso del suscriptor especifica la autenticación RADIUS. El inicio de sesión continúa cuando la autenticación se realiza correctamente. El inicio de sesión falla cuando la
authentication-orderinstrucción del perfil no especifica autenticación RADIUS o no autenticación. El inicio de sesión también falla cuando se produce un error en 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 al PCRF. El enrutador espera a que el 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 de carga, regla de instalación en el mensaje CCA-GX-I, el inicio de sesión del suscriptor se retrasa mientras el enrutador desactiva cualquier servicio predeterminado e intenta activar los servicios especificados.
Si se activan todos los servicios especificados, el inicio de sesión se completará.
Si no se puede activar cualquiera 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 la 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 activan servicios.
Si el PCRF no devuelve un CCA-GX-I dentro del período de tiempo de espera, se completará el inicio de sesión del suscriptor.
El enrutador busca primero los servicios devueltos desde el servidor de autenticación y activa los que encuentre. Si no se encuentra ningún servicio de este tipo, el enrutador activa los servicios predeterminados configurados localmente. El inicio de sesión del suscriptor se completa cuando la activación predeterminada del servicio se realiza correctamente, pero falla cuando cualquier 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 se completa el inicio de sesión (con o sin un servicio predeterminado), el enrutador reenvia periódicamente el mensaje CCR-GX-I al PCRF. Si el PCRF posteriormente devuelve un CCA-GX-I, el enrutador desactiva el servicio predeterminado, si lo hubiera, y luego activa cualquier servicio incluido en la CCA-GX-I. Si el mensaje no incluye ningún servicio, entonces no se activan servicios, ni siquiera un servicio predeterminado.
Si no se puede activar cualquiera 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 la activación.
Recuperación de errores de inicio de sesión del suscriptor
A partir de Junos versión 20.1R1, puede configurar el enrutador para recuperarse de ciertos errores del servidor PCRF reiniciando 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 correctamente una situación en la que se pierden los mensajes CCA-GX-I que envió al enrutador. Cuando el enrutador vuelve a 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 discordancia en el estado puede dar lugar a cualquiera de los siguientes errores:
El servidor PCRF responde al reintentos 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 INCAPAZ DE 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 sabe que el mensaje no se recibió. 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 sesión mala
RAR-GX-you para actualizar la sesión porque considera que la sesión funciona con normalidad.
Puede usar la configuración de PCRF local-decision para volver a inicializar la sesión del suscriptor en respuesta a uno de esos errores o a ambos.
Incluya la
reinit-on-failureopción para el error de falla permanente.Opción incluir
reinit-on-rarpara 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 use un ID de sesión extendido para 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 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 usar la
reinit-timeoutopción para especificar un punto 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, entonces el enrutador envía un CCR-GX-I al PCRF con un nuevo ID de sesión extendido. El ID de sesión extendido se transmite en el AVP del ID de sesión de diámetro (código AVP 263).
El enrutador forma el ID de sesión extendido anexando una marca de sesión que consta de la hora UTC cuando el enrutador crea el CCR-GX-I. Por ejemplo, considere el siguiente AVP del 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-stampconfigurado, la marca de hora de la sesión se anexa al valor AVP:test-host1;0000000000;0000000023;1557788595;
En la tabla 7 , se proporcionan detalles sobre cómo reacciona el enrutador ante estos errores según el estado actual de PCRF local.
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 los servicios predeterminados:
Cuando se completa el aprovisionamiento predeterminado, el enrutador hace lo siguiente:
|
Actualización del suscriptor
Cada vez que se produce un evento de activación 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 recalcula cuando se resiente 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 del código de resultado (código AVP 268) que se asigna a las categorías de resultados enumeradas en la tabla 8.
Valor de código de resultado-AVP |
Categoría de resultados |
|---|---|
SUCCESS(2001), LIMITED_SUCCSS(2002) y mensaje válido |
Éxito |
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 y iguales que 5000, y todos los AVP de código de resultado de error de protocolo de diámetro mayores y iguales que 3000 y menores que 4000 |
Éxito |
Otros AVPs de código de resultados para mensajes no válidos o sin respuesta |
Fracaso |
Cerrar sesión del suscriptor
Cuando la aplicación cliente envía un aviso de cierre de sesión del suscriptor a AAA, Gx envía un mensaje CCR-GX-T (donde T representa TERMINATION_REQUEST) para notificar al PCRF que la sesión del suscriptor aprovisionado se está finalizando.
Cada vez que se produce un evento de activación en el enrutador, se envía una solicitud de cancelació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 recalcula cuando se resiente 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 de código de resultado-AVP |
Categoría de resultados |
|---|---|
SUCCESS(2001), LIMITED_SUCCSS(2002) y mensaje válido |
Éxito |
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 y iguales que 5000, y todos los AVP de código de resultado de error de protocolo de diámetro mayores y iguales que 3000 y menores que 4000 |
Éxito |
Otros AVPs de código de resultados para mensajes no válidos o sin respuesta |
Fracaso |
Si el valor del código de resultado es éxito, Gx notifica a AAA y AAA notifica a la aplicación que se ha completado la sesión. Si Gx no recibe un mensaje CCA-GX-T, o si el AVP del código de resultado tiene otro valor o falta, la solicitud de finalización se vuelve a tratar hasta que el mensaje CCA-GX-T se devuelve con Éxito. El enrutador notifica al PCRF acerca de las cierres de sesión del suscriptor mediante el envío de otra solicitud CCR para que una respuesta de CCA reconozca. El PCRF también puede usar solicitudes RAR para forzar la cierre de sesión del suscriptor o para cambiar los servicios aplicados.
Si el valor del código de resultado es Error, la solicitud se vuelve a activar.
Desconexión del suscriptor
Para realizar desconexiones de suscriptores, el PCRF envía un RAR-GX-D (donde D representa LA DESCONEXIÓN) 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 AVP de código de resultado (código AVP 268) que se asigna a las categorías de resultados enumeradas en la tabla 10.
Valor de código de resultado-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 memoria intermedia para al menos 512 mensajes RAR-GX-D o RAA-GX-D.
Recuperación de errores de conectividad
Gx no depende del estado de conexión entre dispositivos para detectar interrupciones de enrutador o PCRF, ya que algunos eventos no afectan al estado de conexión y otros no se detectan cuando hay un relé o proxy Diameter entre los dispositivos.
Para mitigar los errores de conectividad con el PCRF, el enrutador utiliza los siguientes procedimientos de recuperación de errores:
Si el PCRF no está disponible y si instaló y configuró un servicio predeterminado, el inicio de sesión del suscriptor procede como corresponda.
Las solicitudes de aprovisionamiento no reconocido se vuelven a reproducir de forma indeterminada o hasta que el suscriptor cierra sesión.
Las solicitudes de cierre de sesión esperan a que se complete la interrogación final de OCS y, luego, se vuelven a reproducir las solicitudes de cierre de sesión no reconocidas 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 finalización del suscriptor se vuelven a reproducir (se vuelven a reproducir) 24 horas hasta que se recibe una respuesta satisfactoria de la 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 los interrogatorios se intercambian mediante el protocolo Gy del Proyecto de asociación de tercera 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 carga de sesión en línea con determinación unitaria centralizada y clasificación centralizadas. Opcionalmente, PCEF informa el uso y recibe autorizaciones adicionales de OCS mediante el protocolo Gy.
A partir de Junos OS versión 17.3R1, se agrega compatibilidad con funciones adicionales de OCS y PCRF mediante los protocolos Gy y Gx. Las nuevas instrucciones:
accept-sdrse agrega para la partición PCRF en el nivel jerárquico[edit access pcrf partition partition-name].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, 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 ubicación remota. La copia de seguridad se admite en la jerarquía [edit access ocs partition partition-name].
Después de completar el aprovisionamiento del suscriptor entre la función de carga de reglas y control de políticas (PCRF) y PCEF, el enrutador comienza a enviar las siguientes interrogaciones entre ocs y PCEF:
- Primer interrogatorio al OCS
- Interrogación intermedia al OCS
- Interrogación final al OCS
- Recuperación de errores de conectividad
- Cancelar las solicitudes de sesión
Primer interrogatorio al OCS
Durante la primera interrogación, el enrutador envía una solicitud DE DIÁMETRO CCR que contiene un conjunto fijo de información necesaria 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 el OCS responda, y ocs siempre otorga las cuotas necesarias.
Para configurar una lista de servicios de carga para comunicar información con el OCS a través del protocolo Gy, configure la charging-service-list ocs instrucción en el [edit access profile profile-name] nivel de jerarquía. Los siguientes ejemplos muestran un intercambio de paquetes CCR-GY-I y CCA-GY-I:
El bit T (mensaje potencialmente retransmitido) se recalcula cuando se resiente el CCR-GY-I. Este indicador se establece después de un procedimiento de conmutación por error de vínculo para ayudar a la eliminación de 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) }
Interrogación intermedia al OCS
Después de que el enrutador envió un conjunto fijo de información necesaria 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. Los vencimientos de tiempo de validez y cuota desencadenan eventos de interrogación intermedios.
Cada vez que se produce un evento de activación en el enrutador, se envía una solicitud de actualización al 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]
Interrogación final al OCS
Cuando la aplicación de cliente envía un aviso de cierre de sesión del suscriptor a AAA, Gy envía un mensaje CCR-GY-T (donde T representa TERMINATION_REQUEST) para notificar al OCS que el suscriptor aprovisionado está siendo terminado.
Cada vez que se produce un evento de activación en el enrutador, se envía una solicitud de cancelació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 depende del estado de conexión entre dispositivos para detectar interrupciones de enrutador o OCS, ya que algunos eventos no afectan al estado de conexión y otros no se detectan cuando hay un relé o proxy Diameter entre los dispositivos.
Para mitigar los errores de conectividad con ocs, el enrutador utiliza los siguientes procedimientos de recuperación de errores:
Si el OCS no está disponible, puede configurar para permitir tráfico de suscriptor 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.Los interrogatorios primero e intermedios no reconocidos se repiten por tiempo indeterminado o hasta que el suscriptor cierra sesión.
Los interrogatorios finales no reconocidos se repiten durante hasta 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 aplicaciones.
Un aspecto importante de la tolerancia a fallas de Gy es que las solicitudes de inicio de sesión y finalización de los suscriptores se vuelven a reproducir 24 horas hasta que se recibe una respuesta satisfactoria del OCS. Puede emitir el clear network-access ocs statistics comando para borrar todas las estadísticas DE OCS.
Cancelar las solicitudes de sesión
El OCS puede emitir un ASR (Abort-Session-Request) 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, deja de actualizar el OCS para la sesión involucrada.
Descripción general de copia de seguridad de archivo 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 de fallas, como redundancia de transporte de diámetro, ruta alternativa a OCS y copia de seguridad de archivos. A partir de Junos OS versión 18.1R1, PCEF de banda ancha proporciona la copia de seguridad del archivo cuando no hay rutas principales ni alternativas disponibles. Las tramas CCR-GY-T se almacenan en los archivos en ubicación remota.
La copia de seguridad de OCS entra en vigor cuando caduca el tiempo de espera final de respuesta de OCS. Los datos se colan para el proceso de copia de seguridad y la salida de sesión del suscriptor procede a la terminación de la sesión del 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 para el número total de entradas de respaldo. Después de alcanzar el límite, se produce un error en el inicio de sesión del nuevo suscriptor o se pierden las entradas de respaldo más antiguas según la configuración de desbordamiento de respaldo.
backup-timeout— tiempo de espera para la operación de respaldo.
backup-overflow—controla la acción cuando el número de entradas de respaldo supera el límite de respaldo.
Respaldo de SFTP de OCS
El stfp-backup es el primer mecanismo de respaldo implementado. Las operaciones se controlan mediante los siguientes parámetros:
tiempo de acumulación de espera: los archivos se escriben después del tiempo de acumulación de archivos de la primera entrega CCR-GY-T.
recuento de acumulación: los archivos se escriben después de que se cumpla el número de solicitudes para el recuento de archivo-cuenta.
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.
intervalo de reintentos: cada operación de escritura fallida se vuelve a intentar después de este intervalo hasta que se acumula el tiempo de espera de la copia de seguridad.
tiempo de espera de respuesta: el tiempo de espera en la respuesta de comando sftp individual.
El servidor SFTP-Backup de OCS está configurado por su dirección, inicio de sesión, contraseña, directorio y prefijo de archivo. De forma predeterminada, existe un directorio de destino, si no, se crea el directorio. Si ya existe un archivo de destino con el mismo nombre, se sobrescribirá.
Beneficios de Gy File Backup
Ofrece otra forma de lidiar con la inestabilidad de la red interna.
Descripción de las interacciones entre PCRF, PCEF y OCS
La función de políticas y reglas de carga (PCRF), la función de cumplimiento de políticas y carga (PCEF) y el sistema de carga 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 de las sesiones existentes, la conexión y el monitoreo, y la terminación y cierre de sesión del suscriptor.
La Figura 3 muestra los componentes de una arquitectura general de política de control de carga (PCC) del proyecto de asociación de tercera generación (3GPP). El PCRF envía las reglas al PCEF en el enrutador serie MX mediante el protocolo Gx 3GPP. El PCEF proporciona detección de flujo de datos de servicio y aplica las reglas recibidas del PCRF. Opcionalmente, el PCEF interactúa con el OCS usando el protocolo Gy 3GPP para recuperar la política y la autorización de carga por cuotas y control de crédito. Las interacciones de PCEF de banda ancha (BPCEF) con el OCS utilizan carga de sesión en línea con determinación unitaria centralizada y clasificación centralizadas.
El PCRF también puede insertar 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 .[edit access ocs partition partition-name] hierarchy level
- Interacciones de inicio de sesión
- Actualizar interacciones
- Vencimiento de cuotas e interacciones de tiempo de validez
- Interacciones de conexión y monitoreo
- Cerrar sesión de interacciones
Interacciones de inicio de sesión
Esta secuencia de inicio de sesión de eventos se activa mediante la detección del flujo de datos del servicio en el PCEF. Por lo general, se trata de 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 o reglas solicitados para el suscriptor.
Si se utiliza OCS, el PCEF envía la primera interrogación al OCS mediante un mensaje CCR-GY-I, y el OCS envía los informes correspondientes al PCRF mediante un mensaje CCA-GY-I.
Si está configurado, el PCEF envía una notificación mediante un mensaje CCR-GX-U al PCRF después de procesar los servicios o reglas solicitados.
La regla se informa al PCRF como inactiva cuando se cumple lo siguiente:
Se produce un error en la instanciación del perfil dinámico del servicio.
La asignación de recursos (ENABLE_NOTIFICATION) se establece para la regla de carga.
Cuando se informa que la regla está inactiva, no afecta el inicio de sesión del suscriptor ni a otras reglas.
La regla se informa al PCRF como activa cuando todo lo siguiente es cierto:
La instanciación de perfil dinámico del servicio se hace correctamente.
La asignación de recursos (ENABLE_NOTIFICATION) se establece para la regla de carga.
El desencadenador de evento SUCCESSFUL_RESOURCE_ALLOCATION se establece en la solicitud.
El informe no se envía cuando no hay reglas que informar.
El PCRF responde con un mensaje CCA-GX-U.
El PCEF activa los servicios para el suscriptor.
Actualizar interacciones
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, la PCEF rechaza la solicitud; de lo contrario, reconoce la solicitud mediante el envío de 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 final de recopilación de datos para la presentación de informes al OCS. Cuando se recopilan las estadísticas finales, el PCEF envía una solicitud CCR-GY-U para notificar al OCS. Esta es una parte del proceso de eliminación de un servicio existente en cada uno de los casos siguientes:
Cuando el servicio que se elimina 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 correspondientes al PCRF mediante un mensaje CCR-GX-U.
La regla se informa al PCRF como inactiva cuando se cumple lo siguiente:
Se produce un error en la instanciación del perfil dinámico del servicio.
La asignación de recursos (ENABLE_NOTIFICATION) se establece para la regla de carga.
Cuando la regla se informa como inactiva, no afecta a la actualización ni a otras reglas.
La regla se informa al PCRF como activa cuando todo lo siguiente es cierto:
La instanciación de perfil dinámico del servicio se hace correctamente.
La asignación de recursos (ENABLE_NOTIFICATION) se establece para la regla de carga.
El desencadenador de evento SUCCESSFUL_RESOURCE_ALLOCATION se establece en la solicitud.
El informe no se envía cuando no hay reglas que informar.
Vencimiento de cuotas e interacciones de tiempo de validez
Para las expiraciones de cuotas y las interacciones de tiempo de validez, el enrutador envía una interrogación intermedia al OCS mediante un mensaje CCR-GY-U y procesa la respuesta de OCS.
Interacciones de conexión y monitoreo
Al establecer una conexión con el PCRF, OCS o el servidor de proxy/relé de diámetro, el demonio Diameter realiza una transacción estándar de solicitud de intercambio de capacidades (CER)/respuesta de intercambio de capacidades (CEA). Utilice la infraestructura de Diámetro de Junos OS existente 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 ejemplos siguientes muestran dos escenarios de conexión de comunicación diferentes:
Ejemplo de CER con una conexión dedicada que se utiliza para comunicarse con el 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 instrucción para el send-origin-state-id enrutador en el [edit access pcrf partition partition-name] nivel de jerarquía o [edit access ocs partition partition-name] , entonces el Id de estado de origen se incluye en los mensajes de nivel de diámetro, como: CER, Solicitud de control del dispositivo (DWR)/Respuesta del guardián del dispositivo (DWA) y Solicitud de desconexión del par (DPR)/Desconexión de respuesta de par (DPA).
Ejemplo de CER con una conexión dedicada que se utiliza 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 valor Auth-Application-Id: 4 es el ID de aplicación de autenticación para ocs. Esta es la diferencia entre el primer y el segundo ejemplo.
Puede monitorear y administrar conexiones mediante mensajes DWR/DWA y DPR/DPA estándar.
Cerrar sesión de interacciones
Esta secuencia de eventos de cierre de sesión se activa mediante cualquiera de los siguientes elementos:
Una solicitud de cierre de sesión del suscriptor, como un paquete DHCP RELEASE 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 la sesión:
La infraestructura del sistema notifica al OCS que se inició el cierre de sesión del suscriptor.
Si corresponde, el OCS inicia el proceso final de recopilación de datos.
Si el servicio que se elimina tiene un grupo de calificación, se deben informar los datos finales de este servicio. El OCS inicia la recopilación final de datos según sea necesario.
Tanto el PCRF como el PCEF esperan que se complete el proceso de interrogación final.
El PCEF envía una solicitud de terminación (mensaje CCR-GX-T) al PCRF y, luego, espera la respuesta (mensaje CCA-GX-T) desde el PCRF.
El PCEF completa el proceso de cierre de sesión del suscriptor.
Descripción de los mensajes ascendentes y descendentes para el PCRF
El enrutador serie MX implementa una serie de medidas para proteger contra la sobrecarga de datos tanto para transacciones descendentes como ascendentes. Las transacciones descendentes están protegidas por la limitación de la entrada de la red en condiciones de sobrecarga. Las transacciones ascendentes están protegidas mediante la limitación del número de solicitudes pendientes y el uso de reintentos lentos del primer mensaje no reconocido para una recuperación confiable.
Las funciones integradas del entorno de la función de aplicación de políticas y carga (PCEF) proporcionan protección contra la sobrecarga como resultado de una velocidad 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 sesión (SDB).
Esta es una representación solo de la sesión de suscriptor; no es un identificador permanente independiente de la conexión similar a un número de teléfono. Si el suscriptor se desconecta y 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). Hay una correspondencia uno a uno entre una sesión y el valor del Id de sesión. El ID de sesión es global y eternamente único, ya que 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 desde un evento de desconexión y reconexión. Sin embargo, la sesión siempre está asociada a un único suscriptor. El AVP del 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 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 formato, lo que garantiza que los valores AVP de Session-Id se encuentren en el mismo orden lexicográficamente que las sesiones internas de 64 bits.
También puede configurar el enrutador para que use un ID de sesión extendido, en el que anexa una marca de sesión al ID. La marca de sesión consta de la hora DE UTC cuando el enrutador crea el CCR-GX-I. En este caso, el AVP del 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 inalterados, lo que permite al PCRF rastrear las reinitializaciones.
Siempre configure el enrutador para que use el ID de sesión extendido cuando reinicia 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ítica y reglas de carga (PCRF) lleva las reglas y mensajes al PCEF mediante el protocolo Gx 3GPP y la interfaz de política en línea. Los protocolos PCRF y Gx incluyen los siguientes mensajes:
Mensajes ascendentes comunes
Los mensajes ascendentes de respuesta de control de crédito para iniciación, actualización y terminación (CCR-GX-I, CCR-GX-U y CCR-GX-T) y RAA-GX pueden incluir las siguientes reglas, parámetros y datos:
- AVP de marca de hora del evento
- Notificaciones de instalación de reglas de carga
- Comandos de activación de eventos
AVP de marca de hora del evento
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 la AVP de marca de hora de evento, se incluye en el mensaje descendente. La definición de mensaje de la tabla 11 varía según la transacción.
Mensaje |
Definición |
|---|---|
CCR-GX-I |
Marca de hora de inicio de sesión del suscriptor |
Notificaciones de instalación de reglas de carga
Las siguientes notificaciones muestran un ejemplo de instalación fallido y un ejemplo de instalación correcta de instalación de reglas de carga para mensajes CCR-GX-U entre pcrf y Gx:
Si los informes no reconocidos siguen pendientes en el momento de la salida del cliente, estas reglas de carga se incluyen en los mensajes CCR-GX-T.
Notificación de error de 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 correcto
{ 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 predefinido de desencadenador de eventos para los mensajes CCR-GX y RAA-GX entre el PCRF y Gx:
{ Event-Trigger: SUCCESSFUL_RESOURCE_ALLOCATION(22) }
Mensajes descendentes comunes
Los mensajes descendentes de respuesta de control de crédito para iniciación y actualización (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 regla de carga
- Comandos de eliminación de reglas de carga
- Comandos de activación de eventos
Comandos de instalación de regla de carga
En el siguiente ejemplo, se muestran los comandos de instalación de reglas predefinidos para mensajes CCA-GX y RAR-GX entre el 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 algunas PCRF no puedan generar una AVP de asignación de recursos y notificación. Como resultado, la instrucción en el report-resource-allocation [edit access pcrf partition partition-name] nivel de jerarquía proporciona informes generados de forma predeterminada.
Comandos de eliminación de reglas de carga
En el siguiente ejemplo, se muestran los comandos predefinidos de eliminación de reglas para mensajes CCA-GX y RAR-GX entre el 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 tanto la eliminación de una regla existente como 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 desencadenador de eventos predefinido para mensajes CCA-GX y RAR-GX entre el PCRF y Gx:
{ Event-Trigger: SUCCESSFUL_RESOURCE_ALLOCATION(22) }
Si el valor de activación de SUCCESSFUL_RESOURCE_ALLOCATION (22) existe en los datos descendentes, el PCEF de banda ancha informa la instalación correcta de reglas marcadas con AVP de asignación de recursos y notificación en el AVP de instalación de reglas de carga.
Es posible que algunas PCRF no puedan generar este desencadenador de eventos. Como resultado, la instrucción en el report-successful-resource-allocation [edit access pcrf partition partition-name] nivel de 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 de instancia de sistema lógico:enrutamiento específico, llamado partición.
Actualmente, solo se admite una sola partición; debe configurarlo en el contexto predeterminado de instancia de sistema lógico:enrutamiento.
Antes de configurar la partición OCS, realice la siguiente tarea:
Configure la instancia de Diameter en el
[edit diameter]nivel jerárquico. Consulte Configuración de diámetro.
La configuración de la partición OCS consiste en dar nombre a la partición y, luego, definir o asociar varios 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 carga de reglas y control de políticas (PCRF) funciona dentro de un contexto de instancia de sistema lógico:enrutamiento específico, llamado partición.
Actualmente, solo se admite una sola partición; debe configurarlo en el contexto predeterminado de instancia de sistema lógico:enrutamiento.
Antes de configurar la partición PCRF, realice la siguiente tarea:
Configure la instancia de Diameter en el
[edit diameter]nivel jerárquico. Consulte Configuración de diámetro.
La configuración de la partición PCRF consiste en dar nombre a la partición y, luego, 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 carga del servicio de control de crédito de diámetro del proyecto de asociación de tercera generación (3GPP) para el sistema de carga en línea (OCS), que interactúa con la función de cumplimiento de políticas y carga (PCEF).
Actualmente, el único atributo global configurable es el identificador de contexto del servicio asignado por el operador u operador de telecomunicaciones. Este valor corresponde al Service-Context-Id AVP, que junto con el Service-Identifier-AVP identifica de manera única y global el servicio de control de crédito De Diámetro.
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