MÉTODO PARA EL CONTROL DE POLÍTICAS Y DE COBROS SOBRE FLUJOS DE DATOS EN UNA RED CON CAPACIDAD Gx.

Método para el control de políticas y de cobros sobre flujos de datos en una red con capacidad Gx

Comprende proporcionar de forma dinámica reglas PCC desde una PCRF a una PCEF,

a través de una interfaz de Gx aplicando AVP, y llevar a cabo las siguientes etapas:

- solicitar, la PCRF a la PCEF, ser notificada por esta última acerca de la detección de flujos de datos para uno o más servicios específicos, indicados por la PCRF o predefinidos en la PCEF, y

- detectar, por medio de la PCEF, flujos de datos para los uno o más servicios específicos indicados y notificar dicha detección a la PCRF.

Dichas etapas se llevan a cabo generando uno o más nuevos AVP y/o incluyendo uno o más nuevos valores en un AVP conocido, y aplicando el AVP obtenido a través de dicha interfaz de Gx.

Método para el control de políticas y de cobros sobre flujos de datos en una red con capacidad gx

Campo de la técnica La presente invención se refiere, en general, a un método para el control de políticas y de cobros sobre flujos de datos en una red con capacidad Gx, y en particular a un método que permite la notificación desde PCEF a PCRF respecto a la detección de un determinado flujo de datos de servicio, generando un nuevo AVP y/o incluyendo un nuevo valor en un AVP conocido, y aplicando el AVP obtenido a través de una interfaz de Gx.

Estado de la técnica anterior El control de políticas y de cobros para el entorno de servicios de IP ha evolucionado hasta incluir funciones cada vez más complejas. Al principio, las políticas que se debían evaluar e implementar eran simples (por ejemplo control de acceso a Internet o una red corporativa) , estáticas (es decir, previamente proporcionadas en los puntos de implementación) y la granularidad apenas abarcaba política por servicio o por abonado.

Varios foros de normalización han definido diferentes enfoques para solucionar el mismo problema: proporcionar un control de políticas y de cobros dinámico que tiene en cuenta el servicio y el usuario sobre la red de acceso. Para esas tecnologías de acceso con recursos de ancho de banda limitado, tal como acceso de banda ancha móvil, la gestión adecuada de la QoS es una cuestión clave. La especificación adoptada de manera más generalizada con respecto al control de la QoS de banda ancha móvil es 3GPP TS 23.203 "Policy and Charging and Control Architecture" (PCC) .

PCC permite un control de cobros (fuera de línea y en línea) y un control de políticas sobre flujos de datos. Aunque al principio se enfocaba a redes de acceso 3G, en las últimas versiones también proporciona recomendaciones a otras tecnologías inalámbricas, tales como WiFi y WiMax.

Tal como se muestra mediante la figura 1, la arquitectura PCC está compuesta principalmente por un nodo central, una PCRF (función de reglas de políticas y de cobros) que actúa como un punto de decisión de políticas que puede evaluar la regla adecuada que ha de implementarse en la PCEF (función de implementación de políticas y de cobros) en las capas de acceso/transporte a través de la interfaz de Gx. Además, la PCRF recibirá peticiones de reserva de QoS desde la AF (función de aplicación) a través de la interfaz de Rx. En este sentido, la PCRF enlaza la capa de aplicación y la capa de acceso/transporte, garantizando la QoS autorizada.

Normalmente, en el acceso de banda ancha móvil, el papel de la PCEF lo desempeñará un GGSN (nodo de soporte de GPRS de pasarela) . Otra opción es una plataforma DPI (inspección profunda de paquetes) que podría insertarse en línea con otros nodos de acceso/transporte para realizar un análisis de tráfico especializado, usado o bien métodos estáticos basándose en información de flujo de datos de servicio que se conoce bien, tal como la dirección IP y el número de puerto, o métodos heurísticos basándose en algoritmos que pueden identificar protocolos de nivel 7, tal como P2P. Los nodos DPI a menudo pueden controlar la QoS de flujos de datos de servicio por abonado y por servicio según lo indique una PCRF.

Para sesiones IMS, el papel de la AF lo desempeñará normalmente una P-CSCF (función de control de sesión de llamada Proxy) o un SBC (controlador frontera de servicio) . La función AF es opcional en la arquitectura PCC, en el sentido de que el control de flujos de datos de servicio podría implementarse sin ninguna interacción de capa de aplicación.

La PCRF puede recibir como entrada para la evaluación de políticas, información desde la PCEF, desde la AF (si forma parte del escenario) y desde el SPR (repositorio de perfiles de abonado) , que contiene información con respecto al abonado, tal como servicio permitido, parámetros de QoS y categoría de abonado. Basándose en esto, la PCRF decidirá las reglas PCC que se aplican a cada caso y las transmitirá a la PCEF.

Hay tres tipos de regla PCC:

• Regla PCC dinámica, generada sobre la marcha basándose en el proceso de evaluación y transmitida a la PCEF por la PCRF. Una regla PCC se compone de información para detectar el flujo de datos de servicio e información acerca de los parámetros de cobro y la QoS para que los implemente la PCEF.

• Regla PCC predefinida, ya definida en la PCEF aunque bajo el control de la PCRF, que es posible activar/desactivar basándose en el proceso de evaluación. El flujo de datos de servicio correspondiente y los parámetros de QoS/de cobro se definen en la PCEF (es decir, la PCRF simplemente activa/desactivar la regla PCC invocando el nombre de la regla PCC) .

• Regla PCC estática, ya definida en la PCEF y no está bajo el control de la PCRF (no se conoce siquiera) .

ES 2 382 855 Al La arquitectura PCC simplemente se encarga de reglas de políticas dinámicas y predefinidas, siendo la primera el medio más flexible para resolver casos de uso de control de QoS de operadores móviles. La figura 2 representa el flujo y las órdenes básicos:

(1) El terminal intenta establecer una portadora IP-CAN y la PCEF solicita las políticas que ha de implementar a la PCRF (2) . La PCRF evalúa la información (3) desde la PCEF, el SPR y desde la propia PCRF y toma una decisión sobre las políticas que han de aplicarse, que se transmiten a la PCEF (4) .

(9) Las políticas pueden actualizarse en cualquier momento durante la sesión (debido a una petición (6) de aplicación o cualquier otro evento) .

La solicitud internacional WO2010077684A1 da a conocer un método para realizar optimización de flujos de paquetes con control de políticas y de cobros, en el que una PCRF, o un mecanismo similar, crea y envía a una PCEF segundas reglas PCC basándose en un flujo de datos detectado, con el fin de optimizar el flujo de datos. La detección se lleva a cabo usando criterios definidos en las primeras reglas PCC. El documento WO2010077684A1 se centra en políticas predefinidas para acceso por radio y, aunque se indica que la PCRF se suscribe a activadores de detección de flujo, dicho documento no define dichos activadores, ni su uso, ni la descripción del flujo que va a detectarse, ni la notificación que va a recibirse.

El documento EP2146458A1 da a conocer llevar a cabo una detección de granularidad baja de un evento asociado con una regla PCC específica, y su aplicación a 3GPP. Con este fin, la PCRF enlaza un parámetro de activador de evento con una regla PCC, y lo envía a una PCEF, que detecta el estatus de una portadora IP-CAN correspondiente a dicha regla PCC asociada con un evento indicado por dicho parámetro de activador de evento. Entre las muchas realizaciones descritas por el documento EP2146458A1, se propone que la PCEF también detecte, además del estado de la portadora IP-CAN, el estado de evento, y que la PCRF genere y envíe nuevas reglas PCC basándose en tales detecciones.

El documento EP2146458A1 se centra en mejorar el nivel de granularidad para los activadores ya definidos en 3GPP (nivel de política de flujo o contexto o sesión) . Los activadores definidos en 3GPP se refieren a eventos en la red (por ejemplo, cambio de célula, desconexión, falta de saldo) , y no permiten la detección y notificación de un flujo dado con un tipo de tráfico particular.

Problemas con las soluciones existentes:

En el mercado existe una demanda respecto a nuevos servicios de conectividad que forman parte del portafolio de los operadores de red móvil, siendo crítica la capacidad para detectar, informar y reaccionar de forma dinámica a determinados flujos de servicio, de modo que pueda aplicarse la QoS adecuada. Aunque 3GPP proporciona varios mecanismos para implementar un amplio conjunto de reglas PCC, aún no se ha aprovechado completamente la ventaja ni de nuevos nodos, tales como DPI independientes, ni las nuevas generaciones de GGSN, tal como la capacidad de detectar determinados tipos de tráfico de servicio, incluyendo análisis de L7.

En este sentido, 3GPP no ofrece:

• Ninguna notificación desde la PCEF a la PCRF con respecto a la detección de un determinado flujo de datos de servicio.

• Patrones de flujo de datos de servicio complejos (es decir, filtro (s) para detectar un flujo de datos de servicio) . Los filtros para determinado tipo de tráfico que se han vuelto muy populares en los últimos años, tal como flujo continuo o P2P, tienen que predefinirse en el nodo correspondiente (por ejemplo DPI) ya que los filtros 3GPP sólo... [Seguir leyendo]

1. Método para el control de políticas y de cobros sobre flujos de datos en una red con capacidad Gx, que comprende al menos proporcionar de forma dinámica reglas de control de políticas y de cobros, PCC, desde una función de reglas de políticas y de cobros, PCRF, a una función de implementación de control de políticas, PCEF, a través de una interfaz de Gx aplicando pares de valores de atributo, AVP, caracterizado porque comprende llevar a cabo las siguientes etapas:

- solicitar, dicha PCRF a dicha PCEF, ser notificada por esta última acerca de la detección de flujos de datos para al menos un servicio específico, al menos indicado por la PCRF o predefinido en la PCEF, y

- detectar, por medio de dicha PCEF, flujos de datos para dicho al menos un servicio específico indicado y notificar dicha detección a dicha PCRF;

en el que dichas etapas se llevan a cabo generando al menos un AVP adicional y/o incluyendo al menos un valor adicional en un AVP conocido, y aplicando el AVP obtenido a través de dicha interfaz de Gx.

2. Método según la reivindicación 1, que comprende proporcionar dicha petición de dicha PCRF por medio de una suscripción a una detección de servicio.

3. Método según la reivindicación 2, que comprende llevar a cabo dicha suscripción generando un AVP de detección de servicio, incluyéndolo en un AVP Instalar-Regla-Cobro y enviando este último, como una orden CCA o RAR, a la PCEF.

4. Método según la reivindicación 3, que comprende proporcionar dicha notificación de dicha PCEF incluyendo un valor adicional en el AVP Status_Regla_PCC, indicando dicho valor adicional si se ha realizado la detección solicitada, e incluyendo dicho AVP Status_Regla_PCC en un AVP Nombre-Regla-Cobro y enviando este último, como una orden CCR, a la PCRF.

5. Método según cualquiera de las reivindicaciones anteriores, que comprende llevar a cabo dicha indicación de dicho al menos un servicio específico, y su descripción, al menos proporcionando de forma dinámica, dicha PCRF a dicha PCEF, al menos un patrón de flujo de datos de servicio incluido en al menos un AVP.

6. Método según la reivindicación 5, que comprende proporcionar una pluralidad de dichos patrones de flujo de datos de servicio, para diferentes servicios específicos.

7. Método según la reivindicación 5 ó 6, en el que al menos parte de dichos patrones de flujo de datos de servicio comprende al menos un filtro que describe un respectivo servicio específico con el fin de detectar flujos de datos relacionados con el mismo por la PCEF.

8. Método según la reivindicación 7, en el que algunos o todos los patrones de flujo de datos de servicio mencionados comprenden varios campos de datos que incluyen datos que definen varios filtros correspondientes que describen varios servicios específicos posibles respectivos.

9. Método según la reivindicación 8, en el que al menos parte de dichos filtros definidos por dichos datos de dichos campos de datos son filtros de flujo de datos de servicio L4-L7.

10. Método según la reivindicación 8 ó 9, en el que parte de dichos campos de datos están previstos para incluir información acerca de los tipos de filtros y parte de dichos campos de datos están previstos para incluir información complementaria a cada tipo de filtro.

11. Método según la reivindicación 10, en el que cada uno de dichos tipos de filtro describe servicios asociados a determinados tipos de tráfico seleccionados del grupo que incluye: flujo continuo, P2P y VoIP.

12. Método según cualquiera de las reivindicaciones 5 a 11, que comprende asociar a dichos uno o más patrones de flujo de datos de servicio, o a otros patrones de flujo de datos de servicio, peticiones de acciones que ha de llevar a cabo la PCEF, además de o en lugar de dicha notificación, y proporcionar de forma dinámica dicha información asociada junto con los patrones de flujo de datos de servicio correspondientes desde la PCRF a la PCEF.

13. Método según cualquiera de las reivindicaciones 5 a 12, que comprende proporcionar cada uno de dichos al menos un patrón de flujo de datos de servicio a dicha PCEF generando un AVP Descripción-Flujo_Extendido, incluyéndolo en un AVP Instalar-Regla-Cobro, concretamente en el AVP Definición-Regla-Cobro, y enviando este último, como una orden CCA o RAR, a la PCEF.

14. Método según la reivindicación 13 cuando depende de la reivindicación 3, en el que dicha orden CCA o RAR enviada a la PCEF incluye tanto dicho AVP Descripción-Flujo-Extendido como dicho AVP Detección-Servicio.

15. Método según la reivindicación 12, en el que dichas acciones solicitadas se refieren al menos a bloquear o permitir el paso de un determinado tipo de tráfico de datos.

16. Método según cualquiera de las reivindicaciones anteriores, que comprende transmitir de forma dinámica, desde la PCRF a la PCEF, información de reglas PCC que ha de asociarse a reglas PCC al menos

parcialmente predefinidas configuradas en la PCEF, para modificar y/o complementar con datos adicionales dichas reglas PCC al menos parcialmente predefinidas.

17. Método según la reivindicación 16, en el que dichos datos adicionales se refieren a información de QoS.

18. Método según la reivindicación 16 ó 17, que comprende proporcionar dicha información de reglas PCC a dicha

PCEF generando un AVP Tipo-Regla-Cobro, incluyéndolo en un AVP Instalar-Regla-Cobro, concretamente en 10 el AVP Definición-Regla-Cobro, y enviando este último, como una orden CCA o RAR, a la PCEF.

ES 2 382 855 Al Figura 1

Figura 2

ES 2 382 855 Al Figura 3

Figura 4

ES 2 382 855 Al Figura 5