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

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

Info

Publication number
ES2382855B1
ES2382855B1 ES201001482A ES201001482A ES2382855B1 ES 2382855 B1 ES2382855 B1 ES 2382855B1 ES 201001482 A ES201001482 A ES 201001482A ES 201001482 A ES201001482 A ES 201001482A ES 2382855 B1 ES2382855 B1 ES 2382855B1
Authority
ES
Spain
Prior art keywords
avp
pcef
pcrf
service
rule
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
ES201001482A
Other languages
English (en)
Other versions
ES2382855A1 (es
Inventor
María Dolores Vallecillo Álvarez
María Antonia López Ajenjo
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonica SA
Original Assignee
Telefonica SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonica SA filed Critical Telefonica SA
Priority to ES201001482A priority Critical patent/ES2382855B1/es
Priority to PCT/EP2011/004040 priority patent/WO2012065657A1/en
Priority to ARP110104035A priority patent/AR083664A1/es
Publication of ES2382855A1 publication Critical patent/ES2382855A1/es
Application granted granted Critical
Publication of ES2382855B1 publication Critical patent/ES2382855B1/es
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1403—Architecture for metering, charging or billing
    • H04L12/1407—Policy-and-charging control [PCC] architecture
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/66—Policy and charging system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24—Accounting or billing

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Meter Arrangements (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

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.

Description

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 l
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 consideraban la tupla IP5: origen/destino, puerto de origen/destino y protocolo sobre IP (por ejemplo TCP).
•
PCC parcialmente predefinida. Las reglas PCC predefinidas se usan principalmente debido a la incapacidad de definir un filtro específico para detectar el flujo de datos de servicio de interés. En estos casos, 3GPP recomienda el uso de reglas PCC predefinidas completamente configuradas en la PCEF aunque se activan/desactivan desde la PCRF, pero no hay ninguna opción de transmitir de forma dinámica alguna información de regla PCC, tal como características de cobro o QoS.
Descripción de la invención
Es necesario ofrecer una alternativa al estado de la técnica que cubra los huecos encontrados en la misma e indicados anteriormente.
Con este fin, la presente invención proporciona un 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 (y modificar, actualizar o recuperar si es necesario) de forma dinámica reglas de control de políticas y de cobros, PCC, desde una función de reglas de políticas y
ES 2 382 855 l
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.
A diferencia de las divulgaciones de la técnica anterior, el método de la invención comprende, de una manera característica, 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 uno o más servicios específicos, al menos indicados por la PCRF o predefinidos en la PCEF, y
-
detectar, por medio de dicha PCEF, flujos de datos para dichos uno o más servicios específicos indicados y notificar dicha detección a dicha PCRF.
Dichas etapas se llevan a cabo mediante generación de uno o más nuevos AVP (entendiendo “nuevo AVP” como un AVP no conocido en la técnica anterior) 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.
El método de la invención comprende también, en otra realización, llevar a cabo dicha indicación de dichos uno
o más servicios específicos, y su descripción, al menos proporcionando de forma dinámica, dicha PCRF a dicha PCEF, uno o más patrones de flujo de datos de servicio incluidos en uno o más AVP, para uno o más servicios específicos correspondientes.
Parte de o todos los patrones de flujo de datos de servicio mencionados comprenden, en diferentes realizaciones, uno o más filtros que describen un respectivo servicio específico con el fin de detectar flujos de datos relacionados con el mismo por la PCEF.
En una realización, 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.
Según una realización del método de la invención, 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.
Preferiblemente parte de o todos los filtros mencionados definidos por dichos datos de dichos campos de datos son más complejos que la tupla IP 5, y particularmente son filtros de flujo de datos de servicio L4-L7.
El método de la invención comprende, en algunas realizaciones, 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 (tales como bloquear o permitir el paso de un determinado tipo de tráfico de datos) 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.
Aunque la característica que se refiere a dichos patrones de flujo de datos de servicio se ha reivindicado como una característica dependiente (ya que tiene el mismo fin común que el de las características de la reivindicación 1, es decir, el de mejorar el control de políticas y de cobros sobre flujos de datos en una red con capacidad Gx), es evidente que puede ser una característica independiente de la de solicitar y notificar un flujo de datos de servicio específico detectado, en particular cuando los patrones de flujo de datos de servicio están asociados a dichas peticiones de acciones indicadas en el párrafo anterior.
En otra realización de la invención, el método 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 (tal como datos que se refieren a información de QoS) dichas reglas PCC al menos parcialmente predefinidas.
Las características relacionadas con dicha realización con respecto a dicha transmisión dinámica de información de reglas PCC se han reivindicado como características dependientes (ya que tienen el mismo fin común que el de las características de la reivindicación 1, es decir, el de mejorar el control de políticas y de cobros sobre flujos de datos en una red con capacidad Gx), aunque es evidente que también pueden ser características independientes de la de solicitar y notificar un flujo de datos de servicio específico detectado, ya que la instrucción de la PCRF a la PCEF de que modifique y/o complemente con datos adicionales una regla PCC predefinida en dicha PCEF no tiene que activarse necesariamente mediante la notificación anteriormente descrita.
Según las diferentes realizaciones anteriormente descritas, la presente invención mejora mecanismos 3GPP para aprovecharse de la información de flujo de datos de servicio definiendo extensiones sobre la interfaz de Gx 3GPP (TS 29.212). Permite:
•
La definición de patrones de flujo de datos de servicio complejos que van a proporcionarse de forma dinámica desde la PCRF a la PCEF.
•
La notificación desde la PCED a la PCRF con respecto a la detección de un determinado flujo de datos de servicio, basándose en los patrones de flujo de datos de servicio complejos ya mencionados
o basándose en flujos de datos de servicio específico indicados por otros medios o predefinidos en la PCEF.
•
La mejora de las reglas PCC predefinidas, añadiendo una nueva característica para que la PCRF proporcione de forma dinámica a la PCEF los parámetros de QoS que se aplican a los patrones de flujo de datos de servicio, en los casos en los que no pueden implementarse reglas PCC dinámicas (por ejemplo, el filtro para detectar el tráfico no puede describirse de manera sencilla y tiene que predefinirse en la PCEF).
ES 2 382 855 l
Breve descripción de los dibujos
Las ventajas y características anteriores y otras se entenderán más completamente a partir de la siguiente descripción detallada de realizaciones, algunas de ellas con referencia a los dibujos adjuntos (algunos de los cuales ya se han descrito en la sección de estado de la técnica anterior), que deben considerarse de manera ilustrativa y no limitativa, en los que:
la figura 1 muestra de forma esquemática una arquitectura PCC simplificada;
la figura 2 muestra un flujo básico de arquitectura PCC;
la figura 3 muestra un diálogo llevado a cabo entre una PCRF y una PCEF en una realización de los procedimientos de suscripción y notificación del método de la invención;
la figura 4 muestra un intercambio de órdenes entre una PCRF y una PCEF, en una realización del método de la presente invención en relación con una regla PCC parcialmente predefinida; y
la figura 5 muestra otra realización del método de la invención, en la que la PCRF está enviando una orden CCA a la PCEF que contiene la definición de un filtro de flujo de datos de servicio complejo.
Descripción detallada de varias realizaciones
La presente invención propone mejoras a la interfaz de Gx de una arquitectura PCC 3GPP (véase la figura 1), añadiendo estas características nuevas:
•
Nuevos filtros de flujo de datos de servicio que pueden describir flujo de tráfico más complejo que un IP de tupla 5.
•
Notificación desde la PCEF a la PCRF con respecto a la detección de flujos de datos de servicio específicos.
•
Reglas PCC parcialmente predefinidas.
La siguiente descripción aborda estos tres aspectos en diferentes realizaciones, describiendo en detalle las ilustradas por las figuras 3 a 5.
Notificación de detección de flujo de datos de servicio:
Para que la PCRF pueda recibir notificaciones desde la PCEF con respecto a la detección de un flujo de datos de servicio específico, tienen que considerarse dos operaciones:
•
Suscripción: la PCRF debe indicar a la PCEF que se necesita una notificación específica suscribiéndose a una detección de servicio.
•
Notificación: la PCEF debe notificar a la PCRF acerca de la información solicitada.
Suscripción:
El punto de referencia de Gx prevé que el AVP Instalar-Regla-Cobro (código de AVP 1001) sea de tipo agrupado, y se usa para activar, instalar o modificar reglas PCC según indique la PCRF a la PCEF. La presente invención propone que un nuevo AVP forme parte del AVP Instalar-Regla-Cobro.
El AVP Detección-Servicio (código de AVP xxxx) es el nuevo AVP propuesto por esta invención para que la PCRF se suscriba a la detección de servicio. El AVP Detección-Servicio es de tipo enumerado y se define el siguiente valor:
ES 2 382 855 l
HABILITAR_NOTIFICACIÓN (0)
Este valor debe usarse para indicar que es necesaria una notificación cuando se detecta el patrón de flujo de datos de servicio especificado en el AVP Instalar-Regla-Cobro, concretamente en el AVP Definición-Regla-Cobro (código de AVP 1003). Si se usan reglas PCC predefinidas, este valor permitirá la notificación del patrón de flujo de datos de servicio predefinido en la PCEF e identificado por un AVP Nombre-Regla-Cobro (código AVP 1005) o un AVP Nombre-Base-Regla-Cobro (código de AVP 1004).
Este AVP debe usarse en órdenes CCA y RAR por la PCRF para indicar que, tras la detección en la PCRF de un determinado servicio/grupo de flujos de datos de servicio, deben solicitarse reglas PCC.
La combinación de los elementos AVP Instalar-Regla-Cobro permitirá notificaciones pero ninguna implementación mediante el uso en una orden CCR, un AVP Definición-Regla-Cobro y el AVP detección-Servicio propuesto y omitiendo información de QoS e información de cobro (es decir, no deben implementarse políticas de cobro y QoS en la PCEF).
Notificación:
El punto de referencia de Gx prevé que el AVP Nombre-Regla-Cobro (código de AVP 1018) sea de tipo agrupado, y se usa para notificar el estatus de reglas PCC. Incluye el AVP Status-Regla-PCC (código AVP 1019) de tipo enumerado que describe el status de una o un grupo de reglas PCC. La presente invención propone la adición de un nuevo valor:
DETECTADO (3)
Este valor se usa para indicar que se ha(n) detectado el(los) flujo(s) de datos de servicio descritos en el AVP Nombre Base/Nombre Definición-Regla-Cobro.
Este AVP debe usarse en la orden CCR por la PCEF para indicar la detección de un determinado servicio/grupo de flujos de datos de servicio y para solicitar nuevas reglas PCC si es relevante.
La figura 3 muestra una realización de dichos procedimientos de suscripción y notificación, en la que la PCRF envía, en (2), una orden CCA a la PCEF que incluye el nuevo AVP Detección-Servicio propuesto por esta invención y el nuevo valor HABILITAR_NOTIFICACIÓN (0), indicando que solicita a la PCEF que notifique si detecta el servicio específico indicado por el AVS “Nombre-Regla-Cobro”, es decir, “Servicio0”, y la PCEF detecta, en (3), el flujo de datos para “Servicio0” y envía a la PCRF una orden CCR que incluye el nuevo valor anteriormente descrito “DETECTADO (3)” como nuevo uso de la regla conocida “Status-Regla-PCC”, notificando así dicha detección a la PCRF.
Reglas PCC parcialmente predefinidas:
3GPP proporciona las reglas PCC predefinidas que están previamente configuradas en la PCEF y que pueden activarse o desactivarse por la PCRF en cualquier momento, identificadas por el AVP Nombre-Regla-Cobro o, en caso de un grupo de reglas PCC, el AVP Nombre-Base-Regla-Cobro. El flujo de datos de servicio correspondiente y los parámetros de QoS/cobro se predefinen en la PCEF. La presente invención propone cambiar la definición de la regla PCC predefinida a un tipo de regla PCC parcialmente predefinida, en el sentido de que algunas características PCC pueden estar configuradas en la PCEF pero otras pueden transmitirse de forma dinámica, tal como información de QoS y de cobro.
El punto de referencia de Gx proporciona el AVP Definición-Regla-Cobro (código de AVP 1003) que define la regla PCC para un flujo de servicio enviado por la PCRF a la PCEF. La presente invención propone añadir un nuevo AVP para que forme parte del AVP Definición-Regla-Cobro.
El AVP Tipo-Regla-Cobro (código de AVP xxxx) es el nuevo AVP propuesto por esta invención para que la PCRF indique en órdenes CCA/RAR a la PCEF el tipo de regla PCC. El AVP Tipo-Regla-Cobro es de tipo enumerado y se definen los siguientes valores:
DINÁMICO (0)
Este valor debe usarse para indicar que la regla PCC definida por el AVP Definición-Regla-Cobro es una regla PCC dinámica.
ES 2 382 855 l
PARCIALMENTE_PREDEFINIDO (1)
Este valor debe usarse para indicar que la regla PCC definida por el AVP Definición-Regla-Cobro es una regla PCC parcialmente predefinida. Cuando se establece este valor, la PCEF debe tener en cuenta la combinación del conjunto de características transmitidas de forma dinámica en el AVP Definición-Regla-Cobro y ya predefinidas en la propia PCEF, teniendo prioridad la primera.
5 La figura 4 muestra una realización de dicho procedimiento de reglas PCC parcialmente predefinidas, en la que la PCRF envía, en (1), una orden RAR a la PCEF que incluye el nuevo AVP Tipo-Regla-Cobro propuesto por esta invención y el nuevo valor PARCIALMENTE_PREDEFINIDO (1), que indica que “Regla1” es una regla PCC parcialmente predefinida que debe activarse por la PCEF con los parámetros de QoS indicados en la orden RAR. En (2) la PCEF activa la Regla1 con dichos parámetros de QoS, y después envía una orden RAA correspondiente a la PCRF.
10 Filtros de flujo de datos de servicio complejos:
La arquitectura PCC indica que, si es necesaria la extensión de la inspección de paquetes más allá de la tupla de IP 5, debe usarse una regla PCC predefinida en la PCEF. El punto de referencia de Gx prevé que el AVP Información-Flujo (código de AVP 1058) incluido en el AVP Definición-Regla-Cobro sea de tipo agrupado y se envía desde la PCRF a la PCEF y contiene la información de un único filtro de paquetes de flujo IP que incluye la descripción
15 de flujo. El AVP Descripción-Flujo (código de AVP 507) es de tipo ReglaFiltroIP y no proporcionan los medios para definir filtros de flujo de datos de servicio complejos.
La presente invención propone añadir un nuevo AVP para que forme parte del AVP Información-Flujo.
El AVP Descripción-Flujo-Extendido (código de AVP xxxx) es el nuevo AVP propuesto por esta invención para que la PCRF defina filtros de flujo de datos de servicio L4-L7 que van a proporcionarse a la PCEF en órdenes CCA/RAR. 20 El AVP Descripción-Flujo-Extendido es de tipo agrupado y éste es su formato.
Descripción-Flujo-Extendido ::= < Cabecera AVP: xxxx > [Tipo-Filtro] [Info-Filtro]
El AVP Tipo-Filtro (código de AVP xxxx) es de tipo enumerado y los valores definidos son: URI (0) Este valor debe usarse para indicar que el filtro se definirá mediante un URI. El valor URI se establecerá en el AVP Info-Filtro. 25 P2P (1) Este valor se usará para indicar que el filtro detectará tráfico P2P. En caso necesario, se establecerá un protocolo P2P específico en el AVP Información-Filtro (por ejemplo BitTorrent). VoIP (2) Este valor se usará para indicar que el filtro detectará tráfico VoIP. En caso necesario, se establecerá un 30 protocolo de VoIP específico en el AVP Info-Filtro (por ejemplo Skype). Flujo continuo (3) Este valor se usará para indicar que el filtro detectará tráfico de flujo continuo. En caso necesario, se establecerá un protocolo de medios de flujo continuo específico en el AVP Info-Filtro (por ejemplo RSTP). Otros (4) 35 Este valor se usará para indicar que no se aplica ninguno de los valores anteriores pero se proporciona alguna información complementaria en el AVP Info-Filtro. El AVP Info-Filtro (código de AVP xxxx) es de tipo CadenaOcteto y define información complementaria, dependiendo del AVP Tipo-Filtro:
• Para URI (0), el AVP Info-Filtro definirá un valor URI. 40 • Para P2P (1), el AVP Info-Filtro definirá un protocolo específico de P2P (por ejemplo BitTorrent).
•
Para VoIP (2), el AVP Info-Filtro definirá un protocolo específico de VoIP (por ejemplo Skype).
•
Para flujo continuo (3), el AVP Info-Filtro definirá un protocolo de medios de flujo continuo (por ejemplo, HTTP, RTSP, MMS, RTMP).
ES 2 382 855 l
Para Otros (4), el AVP Info-Filtro definirá cualquier tipo de información adicional que la PCEF pueda procesar para establecer un filtro de tráfico. La figura 5 muestra una realización de dicho procedimiento de reglas PCC de filtros de flujo de datos de servicio complejos, en la que la PCRF envía, en (2), una orden CCA a la PCEF que incluye el nuevo AVP Descripción-Flujo-Extendido propuesto por esta invención con el fin de bloquear el tráfico BitTorrent (3).
Ventajas de la invención:
La invención mejora la arquitectura PCC 3GPP existente incluyendo nuevas características para aprovechar las capacidades de nuevos nodos PCEF, tales como DPI y GGSN de próxima generación definiendo patrones de datos de servicio complejos, mecanismos de notificación acerca de la detección de flujos de datos de servicio y regla PCC parcialmente predefinida que incluirá parámetros de QoS y de cobro dinámicos. Las principales ventajas de la invención respecto a soluciones existentes son las siguientes:
•
La invención proporciona algunos mecanismos sencillos y de bajo coste para mejorar la flexibilidad del control dinámico de servicios de conectividad, ya que es una extensión de un punto de referencia generalmente adoptado entre nodos PCEF.
•
La invención aumentará la eficacia de la asignación de recursos de radio ya que la capacidad de notificar de forma dinámica acerca de la detección de flujos de datos de servicio permitirá a la PCRF ajustar los recursos de radio necesarios en su implementación en las pasarelas de radio (por ejemplo, GGSN). Esto es una ventaja respecto a soluciones basadas en la implementación de reglas predefinidas en nodos DPI, ya que los DPI no pueden renegociar contexto PDP con SGSN.
•
La invención reducirá el tiempo necesario para la introducción en el mercado y ampliará de manera sencilla el portafolio de nuevos servicios de conectividad, ya que la red de acceso/transporte tendrá en cuenta flujos de datos de servicio que incluso comparten el mismo contexto PDP y notificará a la PCRF que dará instrucciones de manera correspondiente al nodo de PCEF correspondiente para que bloquee, conforme o redireccione el tráfico para este flujo.
•
La invención simplificará las tareas de aprovisionamiento de los nodos de acceso/transporte, ya que amplía la capacidad de la PCRF para proporcionar de forma dinámica tanta información como sea posible, incluyendo nuevos filtros y reglas PCC parcialmente predefinidas, lo que reduce el número de reglas PCC que tienen que definirse en las propias PCEF.
Un experto en la técnica puede introducir cambios y modificaciones en las realizaciones descritas sin apartarse del alcance de la invención tal como se define en las reivindicaciones adjuntas.
SIGLAS Y ABREVIATURAS
PCC Control de políticas y de cobros
PCEF Función de implementación de control de políticas
PCRF Función de reglas de políticas y de cobros
UMTS Universal Mobile Telecommunication System (Sistema Universal de Telecomunicaciones Móviles)
BIBLIOGRAFÍA
[1] TS 23.203 “3rd Generation Partnership Project: Policy and Charging Control Architecture”
[2] TS 29.212 “3rd Generation Partnership Project: Gx reference point”
[3] TS 29.214 “3rd Generation Partnership Project: Rx reference point”
ES 2 382 855 l

Claims (19)

  1. REIVINDICACIONES
    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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
    ES 2 382 855 l
    5 parcialmente predefinidas configuradas en la PCEF, para modificar y/o complementar con datos adicionales dichas reglas PCC al menos parcialmente predefinidas.
  17. 17.
    Método según la reivindicación 16, en el que dichos datos adicionales se refieren a información de QoS.
  18. 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 l
    Figura 1
    Figura 2
    ES 2 382 855 l
    Figura 3
    Figura 4
    ES 2 382 855 l
    Figura 5
    OFICINA ESPAÑOLA DE PATENTES Y MARCAS
    N.º solicitud: 201001482
    ESPAÑA
    Fecha de presentación de la solicitud: 19.11.2010
    Fecha de prioridad:
    INFORME SOBRE EL ESTADO DE LA TECNICA
    51 Int. Cl. : H04L12/14 (2006.01) H04W4/24 (2009.01)
    DOCUMENTOS RELEVANTES
    Categoría
    56 Documentos citados Reivindicaciones afectadas
    X
    EP 2107728 A1 (HUAWEI TECH CO LTD) 07.10.2009, todo el documento. 1-18
    X
    WO 2010077684 A1 (QUALCOMM INC et al.) 08.07.2010, todo el documento. 1-4,12,13,15-18
    Y
    5-11
    Y
    WO 2009149341 A2 (CAMIANT INC; BANIEL URI et al.) 10.12.2009, párrafos [0050-0054]. 5-11
    A
    PASTOR et al. “Policy and charging control in the evolved packet system”. IEEE Communications 1-18
    Magazine Volumen 4, Issue 2, páginas 68 a 74. IEEE Piscataway, NJ, USA. 1.02.2009. Doi:10.1109/MCOM.2009.4785382. Todo el documento.
    Categoría de los documentos citados X: de particular relevancia Y: de particular relevancia combinado con otro/s de la misma categoría A: refleja el estado de la técnica O: referido a divulgación no escrita P: publicado entre la fecha de prioridad y la de presentación de la solicitud E: documento anterior, pero publicado después de la fecha de presentación de la solicitud
    El presente informe ha sido realizado • para todas las reivindicaciones • para las reivindicaciones nº:
    Fecha de realización del informe 30.03.2012
    Examinador M. Rivas Sáiz Página 1/4
    INFORME DEL ESTADO DE LA TÉCNICA
    Nº de solicitud: 201001482
    Documentación mínima buscada (sistema de clasificación seguido de los símbolos de clasificación) H04L, H04W Bases de datos electrónicas consultadas durante la búsqueda (nombre de la base de datos y, si es posible, términos de
    búsqueda utilizados) INVENES, EPODOC, WPI, INSPEC
    Informe del Estado de la Técnica Página 2/4
    OPINIÓN ESCRITA
    Nº de solicitud: 201001482
    Fecha de Realización de la Opinión Escrita: 30.03.2012
    Declaración
    Novedad (Art. 6.1 LP 11/1986)
    Reivindicaciones 2-4,10,11,13,14,18 Reivindicaciones 1,5,9,12,15,16,17 SI NO
    Actividad inventiva (Art. 8.1 LP11/1986)
    Reivindicaciones Reivindicaciones 2-4,10,11,13,14,18 SI NO
    Se considera que la solicitud cumple con el requisito de aplicación industrial. Este requisito fue evaluado durante la fase de examen formal y técnico de la solicitud (Artículo 31.2 Ley 11/1986).
    Base de la Opinión.-
    La presente opinión se ha realizado sobre la base de la solicitud de patente tal y como se publica.
    Informe del Estado de la Técnica Página 3/4
    OPINIÓN ESCRITA
    Nº de solicitud: 201001482
    1. Documentos considerados.-
    A continuación se relacionan los documentos pertenecientes al estado de la técnica tomados en consideración para la realización de esta opinión.
    Documento
    Número Publicación o Identificación Fecha Publicación
    D01
    EP 2107728 A1 (HUAWEI TECH CO LTD) 07.10.2009
  19. 2. Declaración motivada según los artículos 29.6 y 29.7 del Reglamento de ejecución de la Ley 11/1986, de 20 de marzo, de Patentes sobre la novedad y la actividad inventiva; citas y explicaciones en apoyo de esta declaración
    El documento D01 se considera el más próximo del estado de la técnica a la invención solicitada.
    Con relación a la reivindicación 1, D01 describe un 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, (resumen y párrafo 0050). El método está 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 (párrafo 0056), y
    -
    detectar, por medio de dicha PCEF, flujos de datos para dicho al menos un servicio específico indicado (párrafo 0058 y 0059) y notificar dicha detección a dicha PCRF (párrafo 0044);
    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 (párrafo 0059).
    A la vista de lo expuesto anteriormente la reivindicación 1 no es nueva (Artículo 6 LP.).
    Las reivindicaciones 2 y 3 indican cómo realizar la subscripción utilizando AVPs determinados en órdenes CCA y RAR. D01 define una forma de realizar la subscripción utilizando diferentes AVPs en órdenes CCA o RAR. La utilización de un AVP u otro no produce ningún efecto técnico diferenciador ya que en ambos casos se transmite la información necesaria para la subscripción; es simplemente un acuerdo entre la PCEF y la PCRF para interpretar la información que se envía. Por tanto las reivindicaciones 2 y 3 no implican actividad inventiva (Artículo 8 LP.).
    De la misma manera la reivindicación 4 indica la utilización de un AVP específico para indicar la notificación de la detección enviándolo en una orden CCR. D01 utiliza un AVP diferente en una orden CCA. Si se aplica el mismo razonamiento anterior se concluye la reivindicación 4 no cumple el requisito de actividad inventiva (Artículo 8 LP.).
    D01 describe como la PCRF proporciona un o más patrones de flujo de datos a la PCEF. Los patrones incluyen filtro que definen servicios específicos, comprendiendo datos de servicio L4-L7 (párrafos 0059 a 0065). Por tanto las reivindicaciones 5 a 9 no son nuevas (Artículo 6 LP.).
    La reivindicación 10 indica que se incluye información complementaria a los filtros. Esto no está descrito en D01 pero se considera una opción de diseño obvia para un experto en la materia. D01 define diferentes tipos de servicio entre los que incluye flujo continuo, P2P y voz sobre IP. Por tanto se considera que las reivindicaciones 10 y 11 no implican actividad inventiva (Artículo 8 LP.).
    Las reivindicaciones 12 y 15 están descritas en D01 en el párrafo 0062. Por consiguiente dichas reivindicaciones no son nuevas (Artículo 6 LP.).
    Las reivindicaciones 13 y 14 describen los AVPs específicos para enviar la información. Al igual que en reivindicaciones anteriores no se utilizan exactamente los mismos AVPs pero la información transmitida es la misma para tener la funcionalidad deseada. El hecho de utilizar un AVP u otro no produce ningún efecto técnico diferenciador. Por tanto las reivindicaciones 13 y 14 no implican actividad inventiva (Artículo 8 LP.).
    En el párrafo 0095 de D01 la PCRF envía un AVP con información QoS para ser aplicado a un flujo de servicio por consiguiente las reivindicaciones 16 y 17 no son nuevas (Artículo 6 LP.). La reivindicación 18 no implica actividad inventiva puesto que, tal como se ha indicado anteriormente, únicamente define unos AVPs específicos para llevar a cabo la funcionalidad anterior.
    Informe del Estado de la Técnica Página 4/4
ES201001482A 2010-11-19 2010-11-19 MÉTODO PARA EL CONTROL DE POLÍTICAS Y DE COBROS SOBRE FLUJOS DE DATOS EN UNA RED CON CAPACIDAD Gx. Expired - Fee Related ES2382855B1 (es)

Priority Applications (3)

Application Number Priority Date Filing Date Title
ES201001482A ES2382855B1 (es) 2010-11-19 2010-11-19 MÉTODO PARA EL CONTROL DE POLÍTICAS Y DE COBROS SOBRE FLUJOS DE DATOS EN UNA RED CON CAPACIDAD Gx.
PCT/EP2011/004040 WO2012065657A1 (en) 2010-11-19 2011-08-11 A method for policy and charge control over data flows in a gx-enabled network
ARP110104035A AR083664A1 (es) 2010-11-19 2011-10-31 METODO PARA EL CONTROL DE POLITICAS Y DE COBROS SOBRE FLUJOS DE DATOS EN UNA RED CON CAPACIDAD Gx

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ES201001482A ES2382855B1 (es) 2010-11-19 2010-11-19 MÉTODO PARA EL CONTROL DE POLÍTICAS Y DE COBROS SOBRE FLUJOS DE DATOS EN UNA RED CON CAPACIDAD Gx.

Publications (2)

Publication Number Publication Date
ES2382855A1 ES2382855A1 (es) 2012-06-14
ES2382855B1 true ES2382855B1 (es) 2013-01-29

Family

ID=44651610

Family Applications (1)

Application Number Title Priority Date Filing Date
ES201001482A Expired - Fee Related ES2382855B1 (es) 2010-11-19 2010-11-19 MÉTODO PARA EL CONTROL DE POLÍTICAS Y DE COBROS SOBRE FLUJOS DE DATOS EN UNA RED CON CAPACIDAD Gx.

Country Status (3)

Country Link
AR (1) AR083664A1 (es)
ES (1) ES2382855B1 (es)
WO (1) WO2012065657A1 (es)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9319273B2 (en) 2012-11-09 2016-04-19 Hewlett Packard Enterprise Development Lp Policy coordination between policy enforcement points
CN106301805B (zh) 2015-05-11 2019-12-17 华为技术有限公司 一种策略和计费执行功能装置、在线计费装置及在线计费方法
US10187217B1 (en) 2017-07-11 2019-01-22 Oracle International Corporation Methods, systems, and computer readable media for efficient mapping of rule precedence values and filter priority values
CN111866951B (zh) * 2020-07-24 2022-07-12 中国联合网络通信集团有限公司 一种业务处理方法及装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101291233B (zh) 2007-04-20 2011-04-20 华为技术有限公司 一种实现事件检测的方法及***
CN101325780B (zh) * 2007-06-15 2010-07-07 华为技术有限公司 策略控制实现方法和***、及策略和计费执行实体
CN102160452B (zh) * 2008-06-05 2015-02-04 凯敏公司 用于在网络中提供移动性管理的方法及***
US8325638B2 (en) * 2008-12-09 2012-12-04 Qualcomm Incorporated Performing packet flow optimization with policy and charging control

Also Published As

Publication number Publication date
AR083664A1 (es) 2013-03-13
WO2012065657A1 (en) 2012-05-24
ES2382855A1 (es) 2012-06-14

Similar Documents

Publication Publication Date Title
US11083033B2 (en) Small data usage enablement in 3GPP networks
EP2384587B1 (en) Group session management for policy control
JP6685243B2 (ja) Ｓｄｎネットワークに基づくアプリケーションサービスチェインに対するポリシおよび課金制御の方法および装置
US9756016B2 (en) Security services for end users that utilize service chaining
US10602000B2 (en) Policy decisions based on offline charging rules when service chaining is implemented
CN104335638B (zh) 用于接入网发现和选择的方法、***和设备
EP2599293B1 (en) Method and apparatuses for policy decisions on usage monitoring
EP2873256B1 (en) Methods, systems, and computer readable media for policy-based local breakout (lbo)
US20140086052A1 (en) Congestion control for radio access networks (ran)
JP5947403B2 (ja) アプリケーション層データに対して課金制御を実行するための方法および装置
EP3172908B1 (en) Methods and apparatuses of service function chain based on pcc architecture
ES2382855B1 (es) MÉTODO PARA EL CONTROL DE POLÍTICAS Y DE COBROS SOBRE FLUJOS DE DATOS EN UNA RED CON CAPACIDAD Gx.
WO2009046678A1 (fr) Procédé et dispositif pour obtenir la capacité de fonction d&#39;application de politique et de facturation
WO2011100630A2 (en) Methods, systems, and computer readable media for diameter application loop prevention
US9992122B2 (en) Method and device for processing packet
CN103686654B (zh) Pcc会话关联方法、以及pcef单元和pa单元
US20160156529A1 (en) Methods and Apparatuses for Control of Usage of One or More Services for a User
Mueller et al. Towards a generic application aware network resource control function for Next-Generation-Networks and beyond
CN104639340B (zh) 数据计费的方法、装置和***
US20150222710A1 (en) Policy decision point management
Pencheva et al. External network control on quality of service of M2M mission-critical applications in 4G
WO2014040254A1 (en) Policy coordination between policy enforcement points

Legal Events

Date Code Title Description
FG2A Definitive protection

Ref document number: 2382855

Country of ref document: ES

Kind code of ref document: B1

Effective date: 20130129

FD2A Announcement of lapse in spain

Effective date: 20210915