ES2425185T3 - Método para el control de criterios y de cargo, servidor y programa informático para ello - Google Patents

Abstract

Un método para el control de políticas o criterios y de cargo, llevado a cabo por un nodo de red que incluye unafunción de aplicación, AF, por un primer servidor que incluye una función de reglas de criterios y de cargo, PCRF,por un segundo servidor que incluye una función de cumplimiento de criterios y de cargo, PCEF, y por un equipo deusuario, UE (300), configurado para interactuar con el nodo de red, de tal manera que el método incluye las etapasde crear (12), por parte de la PCRF, primeras reglas de control de criterios y de cargo, PCC, basándose en informaciónde sesión negociada entre el UE (300) y la AF; instalar (14), en el establecimiento de una sesión en el plano del usuario asociada con el UE (300), las primerasreglas de PCC en la PCEF; e iniciar (16) un servicio asociado con el UE (300) de acuerdo con las primeras reglas de PCC, de tal manera que elservicio implica una pluralidad de medios de soporte; de tal manera que el método incluye, adicionalmente, las etapas de, durante el tiempo de duración de la sesión en elplano del usuario: transmitir (21), por parte del UE (300), al nodo de red, una petición de cambio de calidad de servicio, QoS, según uncriterio por cada medio de soporte, al activarse una orden de interfaz de usuario en el UE (300), de tal modo que lapetición de cambio de QoS es específica de un medio de soporte particular del servicio; crear (22), por parte de la PCRF, segundas reglas de PCC basándose en la petición de cambio de QoS, según uncriterio por cada medio de soporte; instalar (24), en la PCEF, las segundas reglas de PCC, mediante el reemplazo de las primeras reglas de PCC porlas segundas reglas de PCC; continuar (26) el servicio asociado con el UE (300) de acuerdo con las segundas reglas de PCC.

Description

Método para el control de criterios y de cargo, servidor y programa informático para ello

[Campo técnico] La presente invención se refiere a un método para el control de criterios y de cargo que se lleva a cabo por una pluralidad de nodos de red o servidores. La invención también se refiere a un servidor que implementa una función de reglas de criterios y de cargo (PCRF –“policy and charging rules function”), a un servidor que implementa una función de cumplimiento de criterios y de cargo (PCEF –“policy and charging enforcement function”), y a programas informáticos que comprenden instrucciones configuradas para, cuando se llevan a cabo en un servidor, hacer que el servidor lleve a cabo procedimientos para el control de criterios y de cargo.

[Antecedentes] En las redes de comunicación, tales como redes de telecomunicación, una llamada o un servicio a menudo implica, por una parte, un plano de control o plano de señalización y, por otra parte, un plano de usuario. El plano de control

o plano de señalización está a cargo de establecer y gestionar una conexión entre dos puntos de la red. El plano de usuario o plano de medios de soporte se encarga de transportar los datos de usuario.

En este contexto, los operadores de red a menudo desean definir y hacer cumplir un conjunto de reglas en la red. Un conjunto de reglas constituye políticas o criterios. Un marco de criterios para gestionar y hacer cumplir estos criterios incluye, por lo común, al menos tres elementos, o funciones: un repositorio de criterios para almacenar las reglas de criterio que pueden ser específicas del usuario, un elemento, función o punto de decisión sobre criterios, y un elemento, función o punto de cumplimiento de los criterios. Los propósitos de un marco de criterios incluyen el control del acceso de abonados a redes y servicios.

Un marco de criterios trata, sobre todo, de las decisiones en cuanto a si el abonado está intitulado, o autorizado, para disfrutar un servicio y a si la red puede proporcionar el servicio al abonado.

Las arquitecturas o estructuras de control de los criterios y del cargo, tales como la arquitectura descrita en la TS [Especificación Técnica –“Technical Specification”] del 3GPP [Proyecto de Sociedad de 3ª Generación –“3rd Generation Partnership Project”] 23.203, v8.1.1 (marzo de 2008), Technical Specification Group Services and System Aspects (Servicios y aspectos de sistema del grupo de especificaciones técnicas), Policy and charging control architecture (Arquitectura de criterios y control de cargo) (Entrega 8) (disponible en http://www.3gpp.org/ftp/Spects/2008-03/Rel-8/23_series/), aunque no se limitan a estas, integran el control de los criterios y del cargo.

El documento de la técnica anterior US 2005/0094646, proporcionado a modo de ejemplo, divulga un terminal de vídeo con una función para controlar la anchura de banda de transmisión / recepción de vídeo y la calidad de la imagen, y un método de control para ello.

Es deseable proporcionar métodos, servidores y programas informáticos para mejorar las arquitecturas e implementaciones de control de los criterios y del cargo, en particular para permitir una mayor flexibilidad sin aumentar la complejidad de la implementación y de la arquitectura.

[Compendio] Tales métodos, servidores y programas informáticos se definen en las reivindicaciones independientes. Realizaciones ventajosas se definen en las reivindicaciones dependientes.

En una realización, el método es un método de control de criterios y de cargo llevado a cabo por un nodo de red que incluye, o implementa, una función de aplicación (AF –“application function”), por un primer servidor que incluye, o implementa, una función de reglas de criterios y de cargo (PCRF –“policy and charging rules function”), por un segundo servidor que incluye, o implementa, una función de cumplimiento de criterios y de cargo (PCEF –“policy and charging enforcement function”), y por un equipo de usuario (UE –“user equipment”), configurado para interactuar con el nodo de red. El método incluye las etapas de crear, por medio de la PCRF, primeras reglas de control de criterios y de cargo (PCC –“policy and charging control”) basadas en información de sesión negociada entre el UE y la AF; instalar, en el establecimiento de una sesión en el plano del usuario, asociada con el UE, las primeras reglas de PCC en la PCEF; e iniciar un servicio asociado con el UE de acuerdo con las primeras reglas de PCC. El método incluye, de manera adicional, durante el tiempo de duración de la sesión en el plano del usuario, las etapas de: transmitir, por parte del UE, al nodo de red, una petición de cambio de calidad de servicio (QoS –“quality-of-service”) con la activación de una orden de interfaz de usuario existente en el UE; crear, por parte de la PCRF, segundas reglas de PCC basándose en la petición de cambio de QoS; instalar, en el PCEF, las segundas reglas de PCC mediante el reemplazo de las primeras reglas de PCC por las segundas reglas de PCC; y proseguir el servicio asociado con el UE de acuerdo con las segundas reglas de PCC.

El método proporciona medios para cambiar la QoS bajo demanda. En una realización, el cambio puede consistir en

un incremento de QoS. En otra realización, puede consistir en una reducción de QoS. En una realización, el cambio puede ser temporal. En el contexto de una arquitectura de PCC y basándose en ella, el método permite a un usuario

o usuaria suscribirse o abonarse a un servicio con un perfil de QoS dado y, entonces, en un cierto instante de tiempo, rebajar o incrementar su grado o categoría, o, más generalmente, cambiar, el perfil de QoS bajo su petición. La petición puede realizarse manualmente por el usuario o bien puede llevarse a cabo de acuerdo con ajustes almacenados en el UE, o terminal de usuario, en respuesta a que se satisfaga una condición concreta en el UE o seguidamente a la activación de una orden de interfaz de usuario en el UE. En el método de la invención, la PCRF se implementa de tal manera que sea capaz de manejar tal petición de rebajar o incrementar la categoría o grado de la QoS, o, más generalmente, tal petición de cambio de QoS, durante el tiempo de duración de la sesión.

Un método de control de criterios y de cargo es un método por medio del cual un operador de red gestiona las reglas que se han de aplicar a las sesiones de los usuarios, o sesiones de los abonados, con respecto a qué uso de las redes está permitido y a qué regla de cargo debe ser aplicada a una sesión particular en el plano del usuario.

Una PCRF es un elemento de decisión sobre criterios que, particularmente basándose en el perfil del usuario y en las condiciones de la red, decide qué regla se ha de hacer cumplir en el plano del usuario con respecto a la sesión concreta. En una red de, por ejemplo, el Servicio General de Radio en Paquetes (GPRS –“General Packet Radio Service”), la PCRF puede ser capaz de comunicarse con el Nodo de Soporte de GPRS de Pasarela (GGSN – “Gateway GPRS Support Node”) para transferir información de autorización, a fin de tener la capacidad de controlar recursos portadores del Protocolo de Internet (IP –“Internet Protocol”). El portador de IP permite el transporte en el plano del usuario de paquetes de IP y es capaz de transportar muchos flujos de IP.

Una PCEF se encarga de hacer cumplir las reglas de PCC decididas por la PCRF. La PCEF hace cumplir las reglas de PCC en el plano del usuario con respecto a una sesión particular.

Una AF permite a la PCRF obtener información de sesión en el nivel de la aplicación, tal como requisitos de servicio, aunque no está limitada por estos, como entrada para el procedimiento de decisión sobre criterios. La AF forma parte del plano de control.

La expresión “calidad de servicio” (QoS –“quality-of-service”) se refiere al afecto colectivo de un conjunto de requisitos o criterios implementados en una red por mecanismos de control con el fin de asegurarse de que se satisfacen los objetivos relativos a la fiabilidad, el rendimiento, la integridad y otros factores. La QoS puede utilizarse para determinar o expresar el grado de satisfacción de un usuario de un servicio, tal como un servicio consistente en transferir paquetes de datos por una red.

Se hará referencia, en lo que sigue, a los mecanismos de control establecidos para implementar una QoS en una red como mecanismos de QoS. Los mecanismos de QoS pueden ser implementados en una red y pueden ser aplicados a paquetes de datos y a su transferencia por la red con el propósito de garantizar una QoS pretendida o de objetivo. Los mecanismos de QoS pueden ser implementados en, o aplicados a, diferentes capas de protocolo, por ejemplo, en el Modelo de Referencia Básico de Interconexión de Sistemas Abiertos (modelo OSI –“Open Systems Interconnection”), o en el modelo de TCP / IP (Protocolo de Control de Transporte / Protocolo de Internet – “Transport Control Protocol / Internet Protocol”). Dependiendo de la capa de protocolo en la que se ha implementado un mecanismo de QoS, el mecanismo de QoS puede ser implementado o hacerse cumplir en algunos tipos de nodos de red o de entidades de red, mientras que en otros no. En la presente invención, la QoS se hace cumplir por parte de la PCEF, si bien esto no excluye que otros nodos de red puedan también estar a cargo de algunos mecanismos de QoS.

En algunos mecanismos de QoS, el tipo de paquetes de datos o algunas de sus características necesitan ser identificadas o reconocidas por un nodo de red para implementar de forma adecuada el mecanismo de QoS en la red. La identificación de cierta información contenida en el paquete de datos o de cierta información relacionada con el paquete de datos permite la aplicación de diferentes tratamientos o criterios a diferentes paquetes de datos. En otras palabras, el manejo de un paquete de datos o de un grupo de paquetes de datos puede hacerse dependiente del tipo o de las características del paquete de datos o del grupo de paquetes de datos.

Por ejemplo, los paquetes de datos que representan voz pueden formar una de las categorías de paquetes de datos de una red dada, y los paquetes de datos que representan mensajes de correo electrónico pueden formar otra categoría de paquetes de datos de la red. Así, pues, en este ejemplo, mediante la identificación del tipo de información que contienen, o representan, los paquetes de datos, es posible aplicar diferentes políticas o criterios a los paquetes de datos que representan voz, en comparación con paquetes de datos que representan mensajes de correo electrónico.

En otro ejemplo, los paquetes de datos que llegan de un abonado particular pueden formar una categoría de paquetes de datos en una red dada, y los paquetes de datos que llegan de otro abonado particular pueden formar otra categoría de paquetes de datos en la red. Así, pues, en este ejemplo, mediante la identificación del origen de los paquetes de datos, es posible aplicar diferentes políticas o criterios a los paquetes de datos que llegan del primer

abonado, en comparación con los paquetes de datos que llegan del segundo abonado.

En otras palabras, el tratamiento relacionado con la QoS que se aplica a los paquetes de datos por parte de los nodos de red puede ser diferente dependiendo del tipo de tráfico, del contenido de los paquetes de datos, de su origen, de su destino o de cualesquiera otras características.

Ejemplos de mecanismos de QoS incluyen:

-

�Protocolo de Reserva de Recursos (RSVP –“Resource ReSerVation Protocol”), descrito en la publicación de Braden, R. et al.: “Resource ReSerVation Protocol (RSVP) - - Versión 1 Functional Specification” (Protocolo de Reserva de Recursos (RSVP) - - Especificación funcional de la Versión 1), RFC [Petición de comentarios –“Request for Comments”] 2205, septiembre de 1997”. -�Diffserv, descrito en la publicación de Blake, S. et al.: “An Architecture for Differentiated Services” (Una arquitectura para servicios diferenciados), RFC 2475, diciembre de 1998, y en la de Nichols, K. et al.: “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers” (Definición del Campo de Servicios Diferenciados (Campo DS) en los encabezamientos de IPv4 e IPv6), RFC 2474, diciembre de 1998.

El RSVP y el Diffserv realizan su acción sobre paquetes de Protocolo de Internet (IP). Estos dos mecanismos de QoS son implementados por dispositivos de encaminamiento o cortafuegos.

Otro ejemplo de mecanismo de QoS es el que se ha proporcionado por las clases portadoras del Sistema Universal de Telecomunicaciones Móviles (UMTS –“Universal Mobile Telecommunications System”), descrito en la 3GPP TS

23.107: “Universal Mobile Telecommunications System (UMTS); Quality of Service (QoS) concept and architecture” (Sistema Universal de Telecomunicaciones Móviles (UMTS); concepto de Calidad de Servicio (QoS) y arquitectura), V6.4.0, marzo de 2006, donde 3GPP significa Proyecto de Sociedad de 3ª Generación (“3rd Generation Partnership Project”), y TS significa Especificación Técnica (“Technical Specification”). Se definen clases portadoras, cada una de las cuales tiene como objetivo un tipo específico de tráfico de paquetes de datos.

En una realización, la activación de la orden de interfaz de usuario en el UE consiste en una activación de un botón turbo. La activación no está, sin embargo, limitada a una orden de interfaz de usuario táctil, tal como la activación de un botón, un dial o un conmutador. Puede también utilizarse una orden de voz. Tras la activación de la orden de interfaz de usuario, la interfaz de usuario puede indicar que la petición de cambio de QoS ha sido, o no, aceptada.

En una realización, la petición de cambio de QoS es al menos una de entre una petición para un cambio en la categoría, el nivel, las llamadas o el grado de la QoS asociados con la sesión en el plano del usuario, una petición para un cambio en los recursos asociados con la sesión en el plano de usuario, tal como una petición para un cambio en la velocidad de bits garantizada asociada con la sesión en el plano del usuario, y tal como una petición para un cambio en la anchura de banda asociada con la sesión en el plano del usuario.

En una realización, el método incluye, de manera adicional, entre las etapas de transmitir la petición de cambio de QoS y crear las segundas reglas de PCC basándose en la petición de cambio de QoS, decidir sobre al menos uno de entre: si la petición de cambio de QoS puede ser aplicada a la sesión en el plano del usuario; y hasta qué grado o extensión puede ser aplicada la petición de cambio de QoS a la sesión en el plano del usuario. En esta realización, la implementación de la PCRF está provista de medios para determinar y decidir qué QoS, o qué QoS adicional, se ha de asignar en cada caso, basándose en el servicio y en el perfil del usuario, y si es posible entregar la QoS, o QoS adicional, basándose en las condiciones de la red.

En una realización, la etapa de decidir incluye decidir, basándose en al menos una de entre las condiciones de red de acceso, las condiciones de desplazamiento itinerante, el tipo de acceso de radio, el nivel de congestión, el tiempo y el perfil de usuario.

En una realización, la etapa de instalar, en la PCEF, las segundas reglas de PCC mediante el reemplazo de las primeras reglas de PCC por las segundas reglas de PCC, incluye asignar una nueva clave de cargo al servicio asociado con el UE. Esta realización hace posible aplicar características apropiadas de cargo modificadas, cuando una petición de cambio de QoS es disparada o desencadenada por la activación de una interfaz de usuario existente en el UE y cuando, de forma subsiguiente, se aplican las segundas reglas de PCC.

En una realización, el método incluye, de manera adicional, restituir las reglas de PCC aplicadas a la sesión en el plano del usuario, de vuelta a las primeras reglas de PCC cuando se produce al menos uno de los siguientes hechos: un lapso de tiempo termina o expira tras la etapa de instalar las segundas reglas de PCC en la PCEF; se transmite desde el UE una petición para restituir la QoS aplicada a la sesión en el plano del usuario; se llega a una hora o tiempo particular del día o de la semana; un perfil de usuario con datos de suscripción cambia; y un suceso en el plano del usuario invalida las segundas reglas de PCC modificadas. En este contexto, un suceso puede ser, por ejemplo, una condición que se satisface en el plano del usuario. En una realización, el suceso en el plano del

usuario que invalida las segundas reglas de PCC incluye el hecho de que el UE esté desplazándose de forma itinerante. El establecimiento de un tiempo de expiración para el cambio de QoS permite al operador de red restringir los posibles efectos negativos de los cambios individuales de QoS en la petición de carga de red global. Esto puede ser también un incentivo para que los usuarios soliciten el cambio de QoS solo cuando sea necesario.

En una realización, la PCEF se implementa en al menos uno de entre una pasarela, una unidad de PCEF, un nodo de soporte (GGSN) de servicio general de radio en paquetes (GPRS –“general packet radio service”) de pasarela, y una pasarela de datos en paquetes. Otras implementaciones para la PCEF se encuentran también dentro del ámbito de la invención.

En una realización, la petición de cambio de QoS es transmitida desde el UE hasta el nodo de red a través de una petición de protocolo de negociación de sesión que es una cualquiera de entre una petición de establecimiento de protocolo de flujo de información en tiempo real (RTSP –“real time streaming protocol”), y una petición de Protocolo de Inicio de Sesión (SIP –“Session Initiation Protocol”). Otros tipos de peticiones de cambio de QoS que utilizan los mismos o diferentes protocolos de comunicación se encuentran también dentro del alcance de la invención.

La invención también se refiere a un servidor configurado para implementar una función de reglas de criterios y de cargo según se define en la reivindicación 8. El servidor se ha configurado para tomar parte en los métodos anteriormente descritos y en sus realizaciones particulares.

La invención también se refiere a un programa informático que incluye instrucciones configuradas para, cuando se ejecutan en un servidor configurado para implementar una PCRF, hacer que el servidor lleve a cabo las etapas anteriormente descritas relativas a la PCRF, según se define en la reivindicación 11. Sin embargo, cualesquiera realizaciones y variantes explicadas con referencia a los métodos y al servidor de acuerdo con la invención y con sus realizaciones, son también aplicables al programa informático y se encuentran dentro del alcance de la invención.

La invención también se refiere a un UE configurado, dispuesto o adaptado para cooperar o interactuar con el servidor anteriormente descrito, a fin de llevar a cabo uno cualquiera de los métodos anteriormente descritos y de sus realizaciones, tal y como se define en la reivindicación 12.

[Breve descripción de los dibujos] Se describirán a continuación realizaciones de la presente invención, en combinación con los dibujos que se acompañan, en los cuales:

La Figura 1 ilustra un diagrama de flujo de un método de acuerdo con una realización de la invención; Las Figuras 2a y 2b ilustran diagramas de flujo de porciones de métodos de acuerdo con realizaciones de la invención, respectivamente con una etapa de activar un botón turbo (Figura 2a) y una etapa de decidir si puede aplicarse una petición de cambio de QoS (Figura 2b); La Figura 3a ilustra un diagrama de flujo de una porción de un método de acuerdo con una realización de la invención, con una etapa restituir reglas de PCC; La Figura 3b ilustra un diagrama de estado correspondiente a un método de acuerdo con una realización de la invención, que ilustra, en particular, una restitución de reglas de PCC; Las Figuras 4a y 4b ilustran esquemáticamente dos servidores de PCRF de acuerdo con realizaciones de la invención; Las Figuras 5a y 5b ilustran esquemáticamente dos servidores de PCEF de acuerdo con realizaciones de la invención; La Figura 6 ilustra esquemáticamente una arquitectura de PCC proporcionada a modo de ejemplo en una situación que no es de desplazamiento itinerante, con el fin de ayudar al lector a comprender un contexto proporcionado a modo de ejemplo en el que pueden aplicarse realizaciones de la invención; La Figura 7 ilustra un procedimiento proporcionado a modo de ejemplo que implica un acceso a un servidor de flujo de información, a fin de ayudar al lector a comprender un contexto proporcionado a modo de ejemplo en el que pueden aplicarse realizaciones de la invención; La Figura 8a ilustra esquemáticamente el aumento de la anchura de banda asignada a un servicio asociado con un UE en un método de acuerdo con una realización de la invención; La Figura 8b ilustra esquemáticamente un botón de interfaz de usuario y, más específicamente, un botón turbo, dispuesto en un UE, en una realización de la invención; La Figura 9 ilustra un método de acuerdo con una realización de la invención, que incluye la activación de una característica de botón turbo, el cual implica el reemplazo de las primeras reglas de PCC por segundas reglas de PCC; La Figura 10 ilustra un método de acuerdo con una realización de la invención, que incluye la desactivación de una característica del turbo bajo petición del usuario, y que implica la restitución de las reglas de PCC en las primeras reglas de PCC; La Figura 11 ilustra un método de acuerdo con una realización de la invención, que incluye la desactivación de una característica del turbo al expirar o vencer un límite de tiempo, y que implica restituir las reglas de

PCC en las primeras reglas de PCC; La Figura 12 ilustra un método de acuerdo con una realización de la invención, que incluye la desactivación de una característica del turbo debido al cambio de las condiciones de la red, y que implica restituir las reglas de PCC en las primeras reglas de PCC; La Figura 13 ilustra un método proporcionado a modo de ejemplo de acuerdo con una realización de la invención, que muestra una posible implementación para el establecimiento de sesión y la activación del turbo, el cual implica el remplazo de las primeras reglas de PCC por las segundas reglas de PCC; La Figura 14 ilustra una arquitectura e implementación de PCC de acuerdo con una realización de la invención; y La Figura 15 ilustra perfiles de QoS proporcionados a modo de ejemplo, asignados a diferentes servicios antes de que las segundas reglas de PCC sean activadas y cuando lo son (en correspondencia, por ejemplo, a la activación de la denominada característica del turbo), de acuerdo con una realización de la invención.

[Descripción detallada] La presente invención se describirá a continuación en combinación con realizaciones específicas. Puede apreciarse que estas realizaciones específicas sirven para proporcionar a la persona experta en la técnica una mejor comprensión, pero que no están destinadas a limitar en modo alguno el alcance de la invención, la cual está definida por las reivindicaciones que se acompañan.

La Figura 1 ilustra esquemáticamente un diagrama de flujo de un método de control de criterios y de cargo de una realización de la invención. El método de control de criterios y de cargo que se ilustra es llevado a cabo por un nodo de red que incluye, o implementa, una AF [función de aplicación –“application function”] 400 (no ilustrada en la Figura 1), por un primer servidor que incluye, o implementa, una PCRF [función de reglas de criterios y de cargo – “policy and charging rules function”] 100, por un segundo servidor que incluye, o implementa, una PCEF [función de cumplimiento de criterios y de cargo –“policy and charging enforcement function”] 200, y por un UE [equipo de usuario –“user equipment”] 300. El UE 300 está configurado para interactuar con el nodo de red.

Tras la negociación entre el UE 300 y la AF 400, que conduce al establecimiento de información de sesión negociada, la PCRF crea 12 primeras reglas de PCC basándose en la información de sesión. Entonces, en el establecimiento de una sesión en el plano del usuario, asociada con el UE 300, las primeras reglas de PCC son instaladas, según se indica por la referencia 14, en la PCEF 200. El servicio es entonces iniciado según se indica por la referencia 16, de acuerdo con las primeras reglas de PCC. En otras palabras, el servicio es iniciado según se indica por la referencia 16, de tal manera que la PCEF 200 hace cumplir las primeras reglas de PCC para el servicio iniciado.

De forma subsiguiente, en un instante de tiempo durante el tiempo de duración de la sesión en el plano del usuario (en la Figura 1, las etapas que se producen durante el tiempo de duración de la sesión en el plano del usuario están incluidas en el rectángulo en línea discontinua), se activa una orden de interfaz de usuario en el UE 300. Esto desencadena o dispara la transmisión 21, desde el UE 300 hasta el nodo de red, y, a continuación, desde este último hasta la PCRF, de una petición de cambio de QoS. En particular, la transmisión puede ser llevada a cabo desde la AF del nodo de red a la PCRF. Esto puede corresponder a una petición, que se origina desde el usuario 300, para obtener un incremento temporal en la anchura de banda asociada con un servicio particular.

Al recibirse la petición de cambio de QoS en la PCRF 100, la PCRF 100 crea, según se indica por la referencia 22, segundas reglas de PCC para manejar, en tanto en cuanto sea posible, la petición de cambio de QoS. Como se explicará más adelante, la creación de las segundas reglas de PCC puede estar sometida a la comprobación de si el UE 300, o el usuario del UE, está autorizado, en un momento particular, en una red concreta y con respecto a un servicio particular, a obtener el cambio de QoS solicitado, tal como el incremento de QoS solicitado. La creación de las segundas reglas de PCC puede también estar sometida a la comprobación con respecto a si las condiciones de red en curso en ese momento permiten el cambio de QoS. En otras palabras, puede ser necesario comprobar si la red puede permitirse, en un instante concreto de tiempo, incrementar la QoS con respecto al servicio particular asociado con el UE 300.

Una vez que la PCRF 100 ha creado las segundas reglas de PCC, sometidas a las comprobaciones opcionales anteriormente descritas, las segundas reglas de PCC son instaladas, según se indica por la referencia 24, en la PCEF 200 mediante el reemplazo de las primeras reglas de PCC por las segundas reglas de PCC.

Aquí, las referencias a las primeras y segundas reglas de PCC deben entenderse como sigue. Las primeras reglas de PCC creadas e instaladas en el establecimiento, es decir, en el inicio, de la sesión en el plano del usuario son reemplazadas más tarde, durante el tiempo de duración de la sesión en el plano del usuario, por las segundas reglas de PCC. Sin embargo, aún durante el tiempo de duración de la sesión en el plano del usuario, y a continuación de una segunda petición de cambio de QoS, las segundas reglas de PCC pueden ser, a su vez, reemplazadas por terceras reglas de PCC (no ilustradas), etc. La creación de reglas de PCC subsiguientes puede ser el resultado de peticiones de cambio de QoS subsiguientes en correspondencia con el deseo, por parte del usuario del UE, de obtener aún un cambio de QoS adicional, tal como aún un incremento adicional de QoS, en relación con un servicio

o sesión particular.

Tras la instalación, según se indica por la referencia 24, de las segundas reglas de PCC en la PCEF 200, se lleva a cabo el servicio asociado con el UE 300, es decir, se prosigue conforme se indica por la referencia 26, de acuerdo con estas segundas reglas de PCC. En este momento, la PCEF 200 hace cumplir las segundas reglas de PCC al menos durante un cierto periodo de tiempo. El cambio de QoS puede ser un cambio de anchura de banda o de velocidad de transmisión de bits asociada con una sesión.

La Figura 2a ilustra esquemáticamente las etapas que tienen lugar durante el tiempo de duración de la sesión en el plano del usuario, en el método de la Figura 1, pero con una etapa adicional de activar, según se indica por la referencia 20, un botón turbo, o, mas generalmente, de activar una orden de interfaz de usuario que indica el deseo de obtener un cambio de QoS, tal como un incremento de QoS. La etapa adicional 20 tiene lugar antes de transmitir, según se indica por la referencia 21, una petición de cambio de QoS desde el UE 300 al nodo de red. La etapa de activar, conforme a lo indicado por la referencia 20, un botón turbo constituye un caso específico del caso más general de activar una orden de interfaz de usuario en el equipo de usuario. Tanto los casos específicos como los más generales se encuentran dentro del alcance de la invención. En la Figura 8b se ha ilustrado un ejemplo de botón turbo.

La Figura 2b ilustra esquemáticamente las etapas que se producen durante el tiempo de duración de la sesión en el plano del usuario, en el método de la Figura 1, pero con una etapa adicional de decidir, según se indica por la referencia 21a, si la petición de cambio de QoS puede ser aplicada. La etapa de decidir, conforme a lo indicado por la referencia 21a, se produce entre la transmisión, indicada por 21, de la petición de cambio de QoS al nodo de red, y la creación, indicada por 22, de segundas reglas de PCC basándose en la petición de cambio de QoS.

En una realización, decidir, según se indica por la referencia 21a, si la petición de cambio de QoS puede ser aplicada conduce a dos resultados diferentes: (i) la petición de cambio de QoS puede ser aplicada, de tal manera que se crean las segundas reglas de PCC, según se indica por la referencia 22, basándose en la petición de cambio de QoS, o (ii) la petición de cambio de QoS no puede ser aplicada, de tal modo que las segundas reglas de PCC no son creadas, según se indica por la referencia 22. En este último caso (ii), la PCEF 200 continúa aplicando las primeras reglas de PCC y, opcionalmente, puede informarse al UE 300 de que la petición de cambio de QoS no puede ser aplicada. Opcionalmente, el UE 300 puede también ser informado de la razón por la que la petición de cambio de QoS no puede ser aplicada. Las razones pueden incluir al menos una de entre una falta de autorización por parte del usuario asociado con el UE 300 para obtener el cambio de QoS, y una falta de compatibilidad por parte del nodo de red (es decir, por el plano de usuario del nodo de red) para aplicar la petición de cambio de QoS, debida a las condiciones de la red vigentes en ese momento.

En otra realización, la decisión, según se indica por la referencia 21a, sobre si la petición de cambio de QoS puede ser aplicada, puede conducir a más de dos determinaciones diferentes: (i) la petición de cambio de QoS puede ser aplicada (como se ha explicado anteriormente), (ii) la petición de cambio de QoS no puede ser aplicada (como también se ha explicado en lo anterior), o (iii) la petición de cambio de QoS puede ser aplicada únicamente en una cierta extensión o grado. El tercer caso (iii) puede aplicarse debido a que el usuario carezca de la necesaria autorización para obtener el cambio de QoS solicitado en su totalidad, en tanto que el usuario esté, sin embargo, autorizado para obtener un cambio de QoS en una cierta extensión. En otras palabras, el cambio de QoS solicitado por el usuario puede ser parcialmente satisfecho. El tercer caso (iii) puede también aplicarse debido a que las condiciones de la red vigentes en ese momento tan solo permiten satisfacer parcialmente el deseo del UE o del usuario del UE.

La Figura 3a ilustra esquemáticamente las etapas que se producen durante el tiempo de duración de la sesión en el plano del usuario, en el método de la Figura 1, pero con una etapa adicional de restituir, según se indica por la referencia 28, las reglas de PCC en las primeras reglas de PCC. En otras palabras, en una realización, durante el tiempo de duración de la sesión en el plano del usuario, la aplicación de las segundas reglas de PCC en la PCEF 200 es una operación temporal.

En una realización, la restitución, según se indica por la referencia 28, de las reglas de PCC aplicadas a la sesión en el plano del usuario, de vuelta las primeras reglas de PCC se produce cuando termina o expira un cierto lapso de tiempo tras la instalación, según se indica por la referencia 24, de las segundas reglas de PCC.

En una realización, la restitución 28 se produce cuando una petición para restituir la QoS aplicada a la sesión en el plano del usuario, es transmitida desde el UE 300. Tal petición para restituir la QoS aplicada a la sesión en el plano del usuario puede ser transmitida desde el UE 300 al activarse una orden de interfaz de usuario. La activación de la orden de interfaz de usuario puede incluir, o consistir en, apretar de nuevo un botón turbo.

En una realización, la restitución, según se indica por la referencia 28, de las reglas de PCC tiene lugar cuando se llega a una hora o tiempo particular del día, de la semana, del mes o del año.

En una realización, la restitución 28 se produce cuando un perfil de usuario que tiene datos de suscripción para el usuario, cambia.

En una realización, la restitución 28 tiene lugar cuando un suceso en el plano del usuario invalida las segundas reglas de PCC. Esto puede ocurrir cuando se detecta que el UE 300 se está desplazando de forma itinerante. Esto puede producirse, adicional o alternativamente, cuando la cantidad que se ha de cargar a un usuario que ha solicitado el cambio de QoS, ha alcanzado un cierto umbral.

Las realizaciones y condiciones anteriores para restituir, según se indica por la referencia 28, reglas de PCC no constituyen una lista exhaustiva. Pueden utilizarse otras condiciones alternativas o adicionales.

La Figura 3b ilustra un diagrama de estado básico que destaca el cambio de las primeras reglas de PCC que se hacen cumplir por la PCEF 200, a las segundas reglas de PCC, al recibirse una petición de cambio de QoS, y el paso de vuelta de las segundas reglas de PCC a las primeras reglas cuando se satisface una cierta condición, tal como, según se ha explicado anteriormente, la ocurrencia de un suceso configurado para desencadenar una restitución.

Las realizaciones que se ilustran con referencia a las Figuras 2a, 2b, 3a y 3b pueden ser combinadas de acuerdo con cualquier combinación de las mismas.

La Figura 4a ilustra esquemáticamente un servidor configurado para implementar una PCRF. Se ha hecho referencia al servidor como un servidor de PCRF 100. El servidor de PCRF 100 incluye una unidad de creación 102, una unidad de disparo 104 y una unidad de recepción 106.

La unidad de creación 102 se ha configurado para crear las primeras reglas de PCC basándose en la información de sesión negociada por el UE 300 y una AF 400. La unidad de creación 102 está, por tanto, configurada para recibir una entrada procedente de una AF 400 o un UE 300. La unidad de creación 102 está también configurada para suministrar como salida las primeras reglas de PCC a la unidad de disparo 104. La unida de creación 102 está, además, configurada para crear, durante el tiempo de duración de la sesión en el plano del usuario, las segundas reglas de PCC basándose en una petición de cambio de QoS transmitida desde la unidad de recepción 106. La unidad de creación 102 está configurada, por tanto, para recibir una entrada procedente de la unidad de recepción

106. La unidad de creación 102 está también configurada para suministrar como salida las segundas reglas de PCC creadas, a la unidad de disparo 104.

La unidad de disparo 104 está configurada para desencadenar o disparar la instalación, en el establecimiento de una sesión en el plano del usuario asociada con el UE 300, de las primeras reglas de PCC en el servidor 200 de PCEF. Como resultado de ello, la PCEF 200 puede hacer cumplir las primeras reglas de PCC al iniciarse un servicio asociado con el UE 300 o con el usuario del UE. La unidad de disparo 104 está configurada, de manera adicional, para desencadenar la instalación, durante el tiempo de duración de la sesión en el plano del usuario, de las segundas reglas de PCC en el servidor de PCEF 200, mediante el reemplazo en él de las primeras reglas de PCC por las segundas reglas de PCC. El servidor 200 de PCEF puede, por lo tanto, continuar con el servicio asociado con el UE 300 o con el usuario del UE, de acuerdo con las segundas reglas de PCC, es decir, haciendo cumplir las segundas reglas de PCC en lugar de las primeras reglas de PCC.

La unidad de recepción 106 se ha configurado para recibir, durante el tiempo de duración de la sesión en el plano del usuario, una petición de cambio de QoS procedente de un UE 300, bien directamente o bien a través de una AF

400. La unidad de recepción 106 suministra como salida la petición de cambio de QoS a la unidad de creación 102.

La Figura 4b ilustra esquemáticamente un servidor de PCRF que comprende las unidades descritas con referencia a la Figura 4a, con una unidad de decisión adicional 108. La unidad de decisión 108 se ha configurado para decidir si la petición de cambio de QoS puede ser aplicada a la sesión en el plano del usuario, o en qué grado o extensión puede aplicarse la petición de cambio de QoS a la sesión en el plano del usuario. La unidad de decisión 108 está configurada, de manera adicional, para recibir, desde la unidad de recepción 106, como una entrada, la petición de cambio de QoS. La unidad de decisión 108 se ha configurado para suministrar como salida la petición de cambio de QoS a la unidad de creación 102, si se determina que la petición de cambio de QoS puede ser aplicada a la sesión en el plano del usuario. La unidad de decisión 108 se ha configurado también para suministrar como salida, cuando sea apropiado o necesario, información acerca de en qué grado o extensión puede aplicarse la petición de cambio de QoS a la sesión en el plano del usuario.

La Figura 5a ilustra esquemáticamente un servidor que implementa una PCEF, al que se hace aquí referencia como servidor 200 de PCEF. El servidor 200 de PCEF incluye una unidad de instalación 204 y una unidad de inicio 205.

La unidad de instalación 204 se ha configurado para instalar, en el establecimiento de una sesión en el plano del usuario, asociada con el UE 300 o con el usuario del UE, primeras reglas de PCC tras recibirlas del servidor 100 de PCRF. La unidad de instalación 204 está configurada, de manera adicional, durante el tiempo de instalación de la

sesión en el plano del usuario, para instalar segundas reglas de PCC mediante el reemplazo de las primeras reglas de PCC por las segundas reglas de PCC, una vez que ha recibido las segundas reglas de PCC desde el servidor 100 de PCRF. La unidad de instalación 200 está configurada, de manera adicional, para continuar, o hacer continuar, un servicio asociado con el UE 300, o con el usuario del UE, de acuerdo con las segundas reglas de PCC.

La unidad de inicio 205 está configurada para iniciar un servicio asociado con el UE 300 de acuerdo con las primeras reglas de PCC.

La Figura 5 ilustra esquemáticamente un servidor de PCEF 200, el cual comprende las unidades descritas con referencia a la Figura 5a, con una unidad de restitución adicional 206. La unidad de restitución 206 está configurada para restituir las reglas de PCC aplicadas a la sesión en el plano del usuario, de vuelta a las primeras reglas cuando se satisface una cierta condición, tal como se ha descrito anteriormente.

En una realización, el servidor 100 de PCRF (o primer servidor) y el servidor 200 de PCEF (o segundo servidor) forman un único servidor. En otra realización, el servidor 100 de PCRF (o primer servidor) y el servidor 200 de PCEF (o segundo servidor) constituyen dos servidores distintos. En una realización, el servidor 100 de PCRF (o primer servidor) y la AF 400 forman un servidor o nodo de red único. En otra realización, el servidor de PCRF 100 (o primer servidor) y la AF 400 constituyen servidores o nodos de red independientes.

En una realización, la AF 400, la PCRF 100 y la PCEF 200 están situadas en nodos de red (o servidores) independientes, de tal manera que la AF 400 se comunica con la PCRF 100, y esta última con la PCEF 200. Una PCRF 100 puede ser capaz de comunicarse con una pluralidad de AFs 400 y con una pluralidad de PCEFs 200 de una red, y una PCRF 100 puede dar servicio a, y manejar, la pluralidad de AFs 400 y de PCEFs 200.

La Figura 6 ilustra esquemáticamente una arquitectura o estructura de PCC proporcionada a modo de ejemplo, en una situación en la que no hay desplazamiento itinerante, a fin de ayudar al lector a comprender un contexto ejemplar en el que pueden aplicarse realizaciones de la invención. En particular, la arquitectura de PCC proporcionada a modo de ejemplo hace posible integrar el control tanto de los criterios como del cargo, con el objetivo de optimizar el flujo de información. Pueden encontrarse más detalles sobre la arquitectura en la TS 23.203

(V.8.8.1) (a la que se ha hecho referencia anteriormente), la cual especifica la capacidad funcional de PCC para el dominio conmutado en paquetes de 3GPP evolucionado, incluyendo tanto accesos de 3GPP (GERAN / UTRAN / E-UTRAN) como accesos que no son de 3GPP. El repositorio de perfil de suscripción (SPR –“subscription profile repository”), la AF y la PCRF se explican, en particular, en la presente memoria.

La AF 400 es un elemento que ofrece aplicaciones en las cuales el servicio es suministrado en una capa diferente (por ejemplo, la capa de transporte) de aquella desde la cual se ha solicitado el servicio (por ejemplo, la capa de señalización), con el control de los recursos tales como los recursos portadores de IP, aunque sin limitarse a estos, de acuerdo con lo que se ha negociado. Un ejemplo de nodo de red que incluye una AF 400 es la P-CSCF (función de control de sesión de llamada de representante –“proxy-call session control function”) del subsistema de red de núcleo (CN –“core network”) multimedia de IP (IM –“IP multimedia”) (3GPP). La AF 400 se comunica con la PCRF 100 para transferir información de sesión dinámica (es decir, la descripción de los medios de soporte que se ha de suministrar en la capa de transporte). Esta comunicación se lleva a cabo utilizando la interfaz Rx o el punto de referencia de Rx, que se encuentra entre la PCRF 100 y la AF 400 y se utiliza para intercambiar información en el nivel de la aplicación entre la PCRF 100 y la AF 400. La información contenida en la interfaz Rx es entregada desde la información de sesión contenida en la P-CSCF (por ejemplo, el SDP [Protocolo de Descripción de Sesión – “Session Description Protocol”] cuando se utiliza el SIP [Protocolo de Inicio de Sesión –“Session Initiation Protocol”] para la señalización), e incluye, fundamentalmente, lo que se denomina componentes de medios de soporte. Un componente de medios de soporte está compuesto por un conjunto de flujos de IP, cada uno de los cuales se describe a través de un quinteto, el tipo de medios de soporte y la anchura de banda requerida. Otro ejemplo de nodo de red que incluye una AF 400 es el servidor de flujo de información, que se explica adicionalmente a modo de ejemplo en esta memoria.

La PCRF 100 es la función que proporciona un control de criterios y de cargo para los componentes de medios de soporte negociados entre el UE 300 y la AF 400. Para hacerlo, la PCRF 100 crea reglas de PCC basándose en la información recibida desde la interfaz Rx. La PCRF 100, dependiendo del usuario y del servicio solicitado, incluye información de cargo y de criterios conjuntamente con un conjunto de información de filtro de IP: cada quinteto de IP está compuesto por una dirección y puertas de IP de fuente y de destino, y la id de protocolo por encima del IP (TCP [Protocolo de Control de Transporte –“Transport Control Protocol”], UDP [Protocolo de Datagrama de Usuario –“User Datagram Protocol”]). Los filtros incluidos en las reglas de PCC definen los denominados flujos de datos de servicio (SDF –“service data flows”), es decir, los flujos de datos que son tratados de la misma manera en relación con los criterios y el cargo. Estos SDF son instalados en la PCEF 200 a través de la interfaz Gx (como se ilustra en la Figura 6).

La PCEF 200 abarca la detección del flujo de datos de servicio (basándose en las definiciones de los filtros incluidas en las reglas de PCC), así como interacciones de cargo en línea, o en conexión, y fuera de conexión (que no se

describen aquí), y el cumplimiento de las políticas o criterios. La PCEF 200 hace cumplir la QoS para el portador, es decir, en el plano del usuario, de acuerdo con la información de QoS obtenida o recibida desde la PCRF 100. Esta entidad funcional está ubicada en la pasarela (por ejemplo, el GGSN, en el caso de GPRS, y el PDG en el caso deWLAN [Red de Área Local Inalámbrica –“Wireless Local Area Network”]).

El SPR contiene información acerca del abonado y de sus criterios. Si un usuario es un abonado “Oro” y tiene permanentemente la posibilidad de disponer de más anchura de banda que el usuario medio, esta información será insertada en el SPR.

En la arquitectura de PCC, el control de criterios incluye el control de QoS. La PCEF 200 hace cumplir la QoS autorizada para un portador de red de acceso con capacidad de conexión, o conectividad, por IP (IP-CAN –“IP connectivity access network”), de acuerdo con la información recibida a través de la interfaz Gz y dependiendo del modo de establecimiento del portador.

La obligación de cumplimiento de la QoS autorizada del portador de IP-CAN puede conducir a una rebaja o incremento del grado o categoría de la QoS de portador solicitada, por parte de la PCEF 200, como parte de un establecimiento o modificación de portador de IP-CAN iniciada por el UE. Alternativamente, la obligación del cumplimiento de la QoS autorizada puede, dependiendo de los criterios y las capacidades de red del operador, conducir a un establecimiento o modificación de portador de IP-CAN iniciado por red. Si la PCRF 100 proporciona QoS autorizada tanto para el portador de IP-CAN como para la(s) regla(s) de PCC, tiene lugar primeramente el cumplimiento de la QoS autorizada de las reglas de PCC individuales.

Para el control de criterios, la AF 400 interactúa con la PCRF 100 y la PCRF 100 interactúa con la PCEF 200, conforme se le dan instrucciones por parte de la AF 400. Para ciertos sucesos relacionados con el control de criterios, la AF 400 proporciona instrucciones a la PCRF 100 para que actúe por su cuenta, esto es, basándose en la información de servicio disponible en ese momento.

La Figura 7 ilustra un procedimiento proporcionado a modo de ejemplo y que implica un acceso a un servidor de flujo de información, a fin de ayudar al lector a comprender un contexto ejemplar en el que pueden ser aplicadas realizaciones de la invención.

El UE 300 se conecta a un servidor 400 de flujo de información y negocia la sesión (etapa “1. Negociación de sesión de AF-UE”). Durante la negociación de la sesión, se definen las puertas de IP que son utilizadas por los puntos de extremo, el tipo de medios de soporte (audio, vídeo, etc.) y los parámetros de QoS.

El servidor 400 de flujo de información proporciona la información de sesión que ha sido negociada a la PCRF 100 (etapa “2. AAR (Información de Servicio)”, donde el AAR es un código de orden contenido en el encabezamiento de Diámetro (“Diameter”).

La PCRF 100 comprueba si la información de sesión recibida cumple los criterios definidos por el operador, almacena la información de servicio y responde con una confirmación al servidor 400 de aplicación, es decir, el servidor de flujo de información en este ejemplo (etapa “3. AAA (Ack)”).

La PCRF 100 envía una petición RAR para solicitar que la GW, incluyendo la PCEF 200, o la GW (PCEF), instale, modifique o elimine reglas de PCC (etapa “4. RAR (reglas de PCC)”).

La GW, incluyendo la PCEF 200, envía una RAA para confirmar la RAR (etapa “5. RAA”).

La GW (BBERF), donde BBERF significa función portadora, de unión y de informe de suceso (“bearer, binding and event reporting function”), inicia el procedimiento para crear o actualizar el mensaje de petición de contexto (ctx) de Protocolo de Datos en Paquetes (PDP –“Packet Data Protocol”) (etapa “6. señalización de ctx de PDP”).

La GW (PCEF) 200 envía entonces las notificaciones requeridas a la PCRF 100 (etapa “7. Notificaciones de CCR”, donde CCR significa Petición de Control de Crédito (“Credit-Control-Request”) y es un código de orden contenido en el encabezamiento de Diámetro –véase el RFC 4006, Diameter-Credit-Control Application (Aplicación de control de crédito de Diámetro), agosto de 2005).

La PCRF 100 almacena la información recibida en la notificación y confirma la CCR con una CCA (etapa “8. CCA (Ack)”, donde CCA significa Respuesta de Control de Crédito (“Credit-Control-Answer”) y es un código de orden contenido en el encabezamiento de Diámetro –véase el RFC 4006).

En el sistema ilustrado en la Figura 6 y en el procedimiento proporcionado a modo de ejemplo y que se ilustra en la Figura 7, un usuario o usuaria puede tener ciertos límites de QoS preestablecidos en el contexto de su suscripción. Por ejemplo, un usuario puede tener una suscripción de 128 kb/s (kilobytes por segundo). También, el usuario o usuaria puede tener diferentes perfiles de QoS por cada servicio al que se ha abonado, por ejemplo, 1 Mb/s

(megabyte por segundo) para servicios de compartimiento de archivos de igual a igual, o entre pares, y 128 kb/s para los demás servicios. La PCRF 100 tiene en cuenta esta información de suscripción entre otra información recibida desde la AF 400 y la PCEF 200, a fin de determinar la información de autorización de QoS que se ha de aprovisionar de forma dinámica en la PCEF 200.

Esta solución (es decir, la solución ilustrada con referencia a las Figuras 6 y 7) no permite al usuario, por una parte, suscribirse a un grado o categoría de servicio (por ejemplo, la básica y más barata), y, después, por otra parte, cambiar (tal como aumentar) la QoS para un servicio específico, únicamente cuando el usuario desea hacerlo. Esto puede ocurrir, por ejemplo, cuando el abonado está viendo una película, o en cualquier otra aplicación que requiera más anchura de banda o una QoS más adaptada.

La anchura de banda bajo demanda significa que, en cualquier momento, el usuario o usuaria puede, desde su terminal o UE 300, indicar que necesita o desea temporalmente aumentar la calidad de su conexión, tal y como se ilustra en la Figura 8a. Esta característica puede recibir el nombre de característica de “botón turbo” o “turbo” de una realización de la invención: el abonado o abonada aprieta un botón para solicitar a la red que aumente temporalmente los recursos de red a él, o a ella, asignados, tal como se ilustra en la Figura 8b.

La palabra “turbo” y la expresión “botón turbo” no tienen la intención de limitar la invención y son meros nombres a modo de ejemplo para una característica que consiste en permitir a un usuario, o un abonado, solicitar un cambio en la QoS mediante la activación de una orden de interfaz de usuario en el UE 300.

Una diferencia entre esta característica de anchura de banda bajo demanda, perteneciente a una realización de la invención, y otras soluciones tales como la modificación del perfil del usuario mediante un sistema de aprovisionamiento, es que la característica de anchura de banda bajo demanda puede tener una naturaleza temporal. En la característica de anchura de banda bajo demanda, el cambio de la anchura de banda asignada a un usuario puede tener un límite de tiempo de validez.

El límite de tiempo puede ser configurable o puede depender de una indicación explícita, por parte del usuario, del final del periodo de asignación de la anchura de banda adicional o la QoS modificada.

Una realización de la invención puede ser considerada como una modificación de la arquitectura, la implementación y el procedimiento de PCC que se han ilustrado con referencia a las Figuras 6 y 7. La realización proporciona una solución de botón turbo con el fin de permitir al usuario o usuaria mejorar temporalmente la QoS de su conexión o la QoS asignada a un servicio específico.

Esta realización incluye el uso de la interfaz Rx tal y como está normalizada en la arquitectura de PCC (véase la Figura 6) para transportar la información destinada a indicar que un usuario o usuaria desea temporalmente cambiar,

o aumentar, la QoS asociada con su sesión. Esta realización incluye, en particular, la transferencia de información particular, mejorada, desde la AF 400 a la PCRF 100 a través de la interfaz Rx o el punto de referencia de Rx.

Esta realización implica, en particular, el UE 300 desde el que una indicación de la activación del botón turbo es susceptible de ser transferida al nodo de red y, a continuación, a la PCRF 100, de tal manera que el análisis de la información de sesión de servicio y de componente de medios de soporte (información de flujo de datos de servicio) necesita tener en cuenta la indicación del turbo. La realización puede también implicar la AF 400, en caso de utilizarse, que es necesaria para crear información de sesión de servicio e información de componente de medios de soporte (información de flujo de datos de servicio) mejoradas. Esta realización tiene un impacto en la interfaz Rx, de tal manera que la descripción de la sesión contiene información destinada a indicar la petición de cambio de QoS, o petición del turbo. Esta información puede también contener una indicación de los diferentes niveles de cambios de QoS, o de los diferentes niveles del turbo.

En una realización de la invención, la SPR contiene información que indica que un usuario está autorizado a solicitar más anchura de banda bajo demanda.

La PCRF 100, al recibir la petición de cambio de QoS, por ejemplo, una petición del turbo, evalúa si la petición puede ser ejecutada, es decir, hacerse cumplir en la PCEF 200, considerando información tal como:

(1)

Suscripción del usuario: El perfil del usuario indica si el usuario tiene la característica del turbo disponible. El perfil del usuario puede también tener una relación de correspondencia con el incremento de la anchura de banda que supone esta acción del turbo. Los incrementos de anchura de banda pueden ser diferentes para cada usuario y para cada servicio.

(2)

Información de tráfico: La información recibida desde la PCEF 200 a través de la interfaz Gx es considerada en la evaluación, por ejemplo, el tipo de acceso por radio (RAT –“radio access type”), una indicación de desplazamiento itinerante, etc., puesto que la ejecución del turbo puede tener algunas restricciones, dependiendo de las circunstancias de la red. Por ejemplo, el incremento puede ser de un cierto valor si el tipo de RAT es UTRAN [Red de Acceso por Radio Terrestre Universal –“Universal Terrestrial Radio

Access Network”] y de otro valor si el tipo de RAT es GERAN [Red de Acceso por Radio de GSM EDGE – “GSM EDGE Radio Access Network”], o bien puede no ser posible en el caso de desplazamiento itinerante. Estas restricciones son configurables y forman parte del procedimiento de evaluación de criterios que se ha de llevar a cabo en la PCRF 100.

(3) Criterios: La PCRF 100 tiene criterios para decidir si es posible la acción del turbo y para determinar qué acciones se han de emprender en cada caso, tales como que el incremento de la anchura de banda se ha de indicar a la PCEF 200 como parte de las segundas reglas de PCC. El incremento puede ser diferente dependiendo de la información referida en los puntos (1) y (2) anteriores.

Esta realización puede ser descrita en otras palabras, de la forma que sigue:

Un usuario establece, en primer lugar, una sesión de AF. La PCRF 100 recibe la petición de establecimiento de sesión e instala las reglas de PCC correspondientes en la PCEF 200. Cada regla de PCC incluye un SDF y datos de criterios y de cargo. Estos datos permiten a la PCEF 200 llevar a cabo la clasificación del tráfico y el cumplimiento de los criterios.

Durante el tiempo de duración de la sesión, el usuario solicita el cambio o mejora de la QoS de la sesión a través del uso de la característica del turbo. En este instante de tiempo, la PCRF 100 recibe una modificación de la sesión de AF con la indicación del turbo y, posiblemente, el nivel, grado o extensión de la petición de cambio de QoS. Esta analiza el consentimiento y la viabilidad de la petición, y crea las reglas de PCC correspondientes. Las nuevas reglas de PCC, es decir, las segundas reglas de PCC, tienen asignados valores de QoS mejorados, en comparación con las reglas de PCC instaladas en la creación de la sesión: mejor clase de QoS y/o velocidades de transmisión de bits más altas. Como parte de la definición de regla de PCC, se indica también la clave de cargo que se utiliza por parte del sistema de cargo en línea, o bajo conexión, (OCS –“online charging system”) y el sistema de cargo fuera de conexión (OFCS –“offline charging system”) para determinar la tarifa que se ha de aplicar al SDF. La PCRF 100 puede asignar una clave de cargo diferente en las nuevas reglas de PCC, de tal manera que puede aplicarse un cargo adaptado para tener en cuenta el cambio de QoS o la utilización del turbo.

Una persona experta encontrará información acerca de una posible estructura de PCC en la TS 23.203 (a la que se ha hecho referencia anteriormente) como información técnica antecedente para llevar a cabo la invención, si bien la invención no está limitada a la mejora de la arquitectura descrita en la TS 23.203.

La Figura 9 ilustra una realización del método de la invención, que incluye la activación del turbo, es decir, la activación de las segundas reglas de PCC. El UE 300 y la AF 400 negocian los parámetros de la sesión de servicio utilizando la señalización en el nivel de la aplicación; por lo común, el UE 300 negocia el tipo de medios de soporte y parámetros detallados tales como la codec [codificación-descodificación] o las velocidades de transmisión (etapa “1. Negociación de Sesión”). A continuación, la AF 400 informa a la PCRF 100 acerca de los componentes de medios de soporte negociados (etapa “2. Activación de sesión de AF (Petición-AA)”). La PCRF 100 crea las reglas de PCC de acuerdo con la información recibida desde la AF 400 y determina los datos de cargo y de criterios que se aplican a dichas reglas de PCC, basándose en esta información. La PCRF 100 descarga entonces las reglas de PCC que se han de aplicar al portador, es decir, al plano del usuario (etapas “3. Instalación de regla de PCC (RAR)”, “4. RAA”, “5. Notificación (Petición-CC)”, “6. Respuesta-CC”).

A continuación, el UE 300 indica la petición de cambio de QoS o petición del turbo utilizando señalización en el nivel de la aplicación, es decir, señalización en el plano de control (etapa “7. Petición del Turbo de UE”). La AF 400 informa a la PCRF 100 acerca de la petición de cambio de QoS o de la petición por parte del usuario del turbo (etapa “8. Petición-AA de modificación de sesión de AF”). El mensaje existente en la interfaz Rx incluye la indicación del turbo. El formato de interfaz Rx ha de indicar tal indicación, por ejemplo, mediante el uso de un campo con un valor o indicador.

La PCRF 100 lleva a cabo las evaluaciones correspondientes para comprobar si la petición de cambio de QoS o la petición del turbo puede ser aplicada. En ese caso, identifica las reglas de PCC afectadas y descarga las reglas de PCC modificadas (con la nueva QoS y valores de cargo) a la PCEF 200 (etapa “9. Instalación de reglas de PCC (RAR)”). Se transmite una confirmación desde la PCEF 200 a la PCRF 100 (etapa “10. RAR”).

Las Figuras 10, 11 y 12 ilustra realizaciones del método de la invención, incluyendo la desactivación del turbo, es decir, la desactivación de las segundas reglas de PCC y la restitución de las primeras reglas de PCC. Más específicamente, la Figura 10 ilustra la recepción de una petición de desconexión del turbo procedente del UE, la Figura 11 ilustra una expiración del límite temporal del turbo, y la Figura 12 ilustra una desactivación del turbo debida al cambio de las condiciones de la red.

En otras palabras, una vez que se ha solicitado el cambio de QoS por parte de un usuario, y después de que las segundas reglas de PCC correspondientes se han hecho cumplir en la red, esto es, por la PCEF 200, pueden tener lugar diferentes etapas (lista no exhaustiva):

(a)

El usuario requiere explícitamente la desactivación del estado del turbo. En otras palabras, se introduce una orden a través de la interfaz de usuario del UE 300 para indicar esta intención. En la Figura 10 se ha ilustrado una realización de estas etapas.

(b)

El tiempo máximo configurado para que el estado del turbo expire. Este límite de tiempo puede haberse configurado por usuario y por servicio. Una realización de estas etapas se ilustra en la Figura 11.

(c)

El estado de la red cambia: por ejemplo, desplazamiento itinerante, cambio en el tipo de acceso por radio, etc. En la Figura 12 se ilustra una realización de estas etapas.

En los tres casos (tal como se ilustra en las Figuras 10, 11 y 12), así como en los casos en que un cambio en el perfil del usuario con datos de suscripción requiere la desactivación del estado de turbo, la PCRF 100 reevalúa e identifica las reglas de PCC afectadas, y transfiere o descarga las reglas de PCC modificadas (con la nueva QoS y clave de cargo) a la PCEF 200. La PCRF 100 puede notificar el nuevo estado a la AF 400 con información de que las segundas reglas de PCC, o, en el presente caso, la característica del turbo, han sido desactivadas.

La Figura 13 ilustra un ejemplo de establecimiento de sesión y de activación del turbo con referencia a la Figura 13 y a la siguiente descripción, donde AVP significa Par de Valores de Atributos (“Attribute Value Pair”) (que puede, por ejemplo, corresponder a un elemento de información contenido en un mensaje Diámetro (“Diameter”), véase el RFC 3588).

Etapa 1. Una orden DESCRIBIR RTSP (“RTSP DESCRIBE”) es enviada al servidor 400 de flujo de información desde el cliente de flujo de información (el UE 300), a fin de transmitir una descripción del tipo de medios de soporte. Por ejemplo:

DESCRIBIR rtsp: / /movie.server.com/movie.test RTSP/1.0 CSeq: 1 Aceptar: aplicación/sdp Aceptar - Lenguaje: ingles británico (“en-gb”) Usuario - Agente: Ericsson-SC/1.1

Etapa 2. Se devuelve una orden CONFORMIDAD 200 RSTP (“RSTP 200 OK”) desde el servidor 400 de flujo de información al UE 300. Esta incluye una descripción del medio de soporte disponible, posiblemente, una combinación de audio y de vídeo. Se entrega la descripción de las velocidades de transmisión disponibles. Por ejemplo:

RSTP/1.0 200 OK CSeq: 1 Servidor: Ericsson-SS/1.6 Permitir: OPCIONES, DESCRIBIR, ESTABLECER, REPRODUCIR, PAUSA, DESTRUCCIÓN Tipo-contenido: aplicación / sdp Longitud-contenido: 203 v=0 o= - 950814089 950814089 IN IP4 192.168.186.8 s=Ejemplo de película i= Ejemplo de control agregado de audio y de vídeo a=intervalo:npt=0 - 59.3478 a=control : * t=0 0 m=audio 0 RTP/AVP 0 a=control : IDflujo_de_información=0 (“streamID=0”) b=AS : 13

Etapa 3. El cliente de ESTABLECER RTSP dispara el servidor 400 de flujo de información para establecer una sesión de IDflujo_de_información específica, por ejemplo, de audio, y también indica con qué puerta(s) de cliente se ha de comunicar. Por ejemplo:

ESTABLECER rtsp: / /movie.server.com/movie.test/streamID=0

RTSP/1.0

CSeq: 2

Transporte: RTP/AVP/UDP; difusión_única;puerta_cliente=3456-3457

(“RTP/AVP/UDP;unicast;client_port=3456-3457”)

Etapa 4. El Servidor de CONFORMIDAD 200 RTSP (“RTSP 200 OK”) proporciona la id [identidad] de sesión al cliente (el UE 300), y también dice con qué puerta(s) de servidor se ha de comunicar. Por ejemplo:

RTSP/1.0 200 OK

CSeq: 2

Transporte: RTP/AVP/UDP; difusión_única;puerta_cliente=3456-3457; puerta_servidor=5678-5679

(“RTP/AVP/UDP;unicast;client_port=3456-3457;server_port=5678-5679”)

Sesión: dfhyrio9011k Etapa 5. El servidor 400 de flujo de información envía la información de sesión a la PCRF 100 utilizando una petición-AA (AAR –“AA-request”). Por ejemplo:

ID de sesión:dfhyrio9011k

•

Número-Componente-Medios de soporte. 1 (“Media-Component-Number. 1”)

•

Sub-Componente-Medios de soporte (“Media-Sub-Component”)

•

Número-Flujo. 1 Descripción-Flujo Dirección: Afuera (“Out”) (Dirección de enlace descendente. Es decir, desde la red hasta el UE) Dirección de IP de fuente: 192.168.186.8 Dirección de IP de destino: 144.132.134.67 Protocolo: RTP Puertas de Fuente: 5678-5679 Puertas de Destino: 3456-3457 Estado de Flujo: Habilitar Utilización de Flujo: No información Anchura de banda-Solicitada-Max-UL. 0 (kbps). Anchura de banda-Solicitada-Max-DL. 13 (kbps).

•

Número-Flujo. 2 Descripción-Flujo Dirección: Afuera (Dirección de enlace descendente. Es decir, desde la red al UE) Dirección de IP de fuente: 192.168.186.8 Dirección de IP de destino: 144.132.134.67 Protocolo: RTCP Puertas de Fuente: 5680-5681 Puertas de Destino: 3458-3459 Estado de Flujo: Habilitar Descripción-Flujo Dirección: Adentro (Dirección de enlace ascendente. Es decir, desde el UE a la red) Dirección de IP de fuente: 144.132.134.67 Dirección de IP de destino: 192.168.186.8 Protocolo: RTPC Puertas de Fuente: 3457 Puertas de Destino: 5679 Estado de Flujo: Habilitar

•

Identificador-Aplicación-AF. ID-flujo de información

•

Tipo-Medios de soporte. AUDIO (0)

•

Anchura de banda-RS. 3,0 kbps

•

Anchura de banda-RR. 3,5 kbps

Etapa 6. La PCRF 100 confirma la petición, utilizando una respuesta-AA (AA).

Etapa 7. La PCRF 100 instala, en la PCEF 200, reglas de PCC e información de QoS. Por ejemplo:

RAR permitir salida 5678-5679 desde 192.168.186.8 a

144.132.134.67: 3456-3457 permitir entrada 3456-3457 desde 144.132.134.67 a

192.168.186.8: 5678-5679 Estado-Flujo = HABILITADO, Anchura de banda-Solicitada-Max-YY = 25400, QCI = 1

Etapa 8. Una respuesta de reautorización (RAA –“re-authorization answer”) es enviada a modo de confirmación desde la PCEF 200 a la PCRF 100.

Etapa 9. La señalización en el contexto de PDP puede implicar la modificación de un contexto de PDP existente o el establecimiento de uno nuevo. Por ejemplo, si se establece un nuevo contexto de PDP, la información correspondiente a este contexto de PDP puede ser: Crear en GTP petición de Contexto de PDP con valores de QoS para el contexto de PDP secundario (“GTP Create PDP Context request with QoS values for the secundary PDP context”). Por ejemplo:

Datos I de Identificador de Punto de Extremo de Túnel (“Tunnel Endpoint Identifier Data I”) Plano de Control de Identificador de Punto de Extremo de Túnel (“Tunnel Endpoint Identifier Control Plane”) NSAPI: 6 NSAPI enlazado: 5 Calidad del Perfil de Servicio: Clase de flujo de información; Clase de retardo 1; SDU entregado en orden; Máxima velocidad de bits 25400 en UL [enlace ascendente –“uplink”]; Máxima 25400 en DL [enlace descendente –“downlink”]; Velocidad de transmisión de bits garantizada 25400 en UL; Velocidad de transmisión de bits garantizada 25400 en DL TFT: IP4=192.168.186.8, puerta_fuente= { [5678 5679] }

Etapa 10. El Cliente de Reproducir RSTP solicita el contenido. La posible petición puede ser:

REPRODUCIR rtsp: / /movie.server.com/movie.test RTSP/1.0 CSeq: 4 Session: dfhyrio9011k

Etapa 11. CONFORMIDAD RTSP (“RTSP OK”)

RTSP/1.0 CONFORMIDAD 200 (“200 OK”) CSeq: 4 Sesión: dfhyrio9011k Intervalo: npt=0- Info-RTP: url= rtsp: / /movie.server.com/movie.test/streamID=0; seq=9900093; rtptime=4470048, url= rtsp: / /movie.server.com/movie.text/streamID=1; seq=1004096;rtptime=1070549

Etapa 12. La carga útil de los DATOS RTP (“RTP DATA”) es enviada al cliente (UE 300) con respecto al (a los) contenido(s) solicitado(s).

Etapa 13. La carga útil de los DATOS RTP (“RTP DATA”) es enviada al cliente (UE 300) con respecto al (a los) contenido(s) solicitado(s).

Etapa 14. La sesión de flujo de información comienza a presentar.

Etapa 15. El UE 300 actualiza la sesión de flujo de información y activa el turbo mediante el envío de una petición de ESTABLECIMIENTO RTSP; puede utilizarse un nuevo modificador de anchura de banda en el SDP para este propósito. Esta activación del turbo puede indicar también un nivel específico del turbo. El Cliente de ESTABLECIMIENTO RTSP modifica la sesión del IDflujo_de_información específico, por ejemplo, audio, para activar el turbo. Por ejemplo:

ESTABLECIMIENTO rtsp: / /movie.server.com/movie.test/streamID=0 RTSP/1.0 CSeq: 2 Transporte: RTP/AVP/UDP; difusión_única;puerta_cliente=3456-3457, b=TURBO=nivel-1

(“RTP/AVP/UDP;unicast;client_port=3456-3457, b=TURBO=level-1”)

Etapa 16. El Servidor de CONFORMIDAD 200 RTSP proporciona el id de sesión al cliente (UE 300) y también dice con qué puerta(s) del servidor se ha de comunicar. Por ejemplo:

RTSP/1.0 CONFORMIDAD 200 (“200 OK”) CSeq: 2 Transporte: RTP/AVP/UDP; difusión_única;puerta_cliente=3456-3457; puerta_servidor=5678-5679 (“RTP/AVP/UDP;unicast;client_port=3456-3457;server_port=5678-5679”) Sesión: dfhyrio9011k

Etapa 17. El servidor 400 de flujo de información envía la indicación del turbo a la PCRF 100, utilizando una petición-AA (AAR –“AA-request”). Por ejemplo:

ID de sesión: dfhyrio9011k

•

Número-Componente-Medios de soporte. 1

•

Turbo=Activo, nivel-1

•

Sub-Componente-Medios de soporte

•

Número-Flujo. 1

•

Número-Flujo. 2

•

Identificador-Aplicación-AF. ID-Flujo_de_información

Etapa 18. La PCRF 100 confirma la petición del turbo o la petición del cambio de QoS utilizando una respuesta-AA (AAA –“AA-answer”).

Etapa 19. La PCRF 100 lleva a cabo la evaluación correspondiente con el fin de comprobar si la petición del turbo es posible. En ese caso, identifica las reglas de PCC afectadas y descarga los nuevos valores de QoS y de cargo a la PCEF 200. Por ejemplo:

Información-QoS de RAR: Anchura de banda-Solicitada-Max=50000 (Nota: Este es el nuevo valor de anchura de banda calculado por la PCRF de acuerdo con la petición del turbo. Nótese que el valor de anchura de banda previo era 25400).

Etapa 20. La PCEF 200 responde con una respuesta de reautorización (RAA –“re-authorization answer”).

Etapa 21. La carga útil de DATOS RTP es enviada al cliente (UE 300) con respecto al (a los) contenido(s) solicitado(s), y la velocidad de transmisión de bytes mínima (MBR –“minimum byte rate”) se incrementa.

La Figura 14 ilustra una arquitectura y una implementación en las que una re de comunicación móvil (por ejemplo, 3GPP) con la nueva característica de QoS iniciada por red, es controlada por la PCRF 100 para proporcionar una cierta clase de QoS a un flujo dado. Los efectos sobre la PCRF 100 son como sigue. La PCRF es capaz de, o se ha configurado para, evaluar la petición de cambio de QoS o la petición del turbo, a fin de determinar si es posible atender esta petición, para identificar el servicio o servicios afectados, para recalcular las reglas de PCC con las nuevas claves de QoS y de cargo, y para instalar las segundas reglas de PCC en la PCEF 200.

La tabla de la Figura 15 muestra un ejemplo de los perfiles de QoS asignados para los diferentes servicios asignados al grupo de abonados “Oro”, antes de que se active el turbo (“Condiciones normales”) y cuando el turbo está activo o en funcionamiento (“Condiciones turbo”). MBR significa velocidad de transmisión de bytes mínima (“minimum byte rate”) y GBR quiere decir velocidad de transmisión de bits garantizada (“guaranteed bit rate”). WeShare hace referencia a la implementación del Subsistema Multimedia de IP (IMS –“IP Multimedia System”) de Ericsson, de servicios combinatorios (que combinan tanto la voz como otros medios de soporte). Un usuario con un terminal adaptado para WeShare puede compartir vídeo, imágenes y otros medios de soporte cuando lleva a cabo una llamada de voz.

Los efectos sobre la interfaz Rx pueden ser descritos como sigue. En particular, los efectos sobre la petición-AA pueden ser descritos de la siguiente manera:

La petición-AA (AAR) enviada por la AF 400 a la PCRF 100 incluye un AVP para indicar el estado de turbo o el estado de cambio de QoS. Los valores válidos para este AVP pueden ser “Activado” / “Desactivado” (“On” / “Off”), si bien puede ser extendido de manera que incluya nuevos valores, por ejemplo, a fin de indicar diferentes niveles de turbo o de QoS solicitada.

Este AVP puede estar incluido en el AVP de la Descripción-Componente-Medios de soporte, a fin de proporcionar una petición de turbo en el nivel de medios de soporte. Esto se refiere al caso en que el usuario desea aumentar la calidad asignada a unos medios de soporte específicos del servicio, por ejemplo, el vídeo.

La descripción en el nivel del componente-medios de soporte tiene una prioridad más alta que la que está en el nivel de la sesión del servicio.

Lo que sigue es un ejemplo de formato de mensaje que puede ser utilizado para la Petición-AA enviada desde la AF 400 a la PCRF 100:

<Petición-AA> : : = < Encabezamiento de Diámetro: 265, REQ, PXY >

< ID-sesión >

{ Id-Aplicación-Autor } (“{ Auth-Application-Id }”)

{ Anfitrión-Origen }

{ Dominio-Origen }

{ Dominio-Destino }

*[ Descripción-Componente-Medios de soporte ]

AVP modificado (véase más adelante)

[Turbo] Nuevo AVP

*[ Agrupamiento-Flujo ]

[ Identificador-Cargo-AF ]

[ Indicación-Bifurcación-SIP ]

*[ Acción-Específica ]

*[ ID-Suscripción ]

*[ Info-Representante ]

*[ Registro-Ruta ]

*[ AVP ]

Descripción-Componente-Medios de soporte : := < Encabezamiento AVP: 517 >

{ Número-Componente-Medios de soporte } ;

Número ordinal del componente de medios de soporte.

[Turbo] Nuevo AVP

* [ Sub-Componente-Medios de soporte ] ;

Conjunto de flujos para un identificador de flujo [ Identificador-Aplicación-AF ] [ Tipo-Medio de soporte ] [ Anchura de banda-Solicitada-Max-UL ] [Anchura de banda-Solicitada-Max-DL ] [ Estado-Flujo ] [ Anchura de banda-RS ] [ Anchura de banda-RR ]

Los efectos en los protocolos de negociación de la sesión pueden ser descritos como sigue. El protocolo de negociación de sesión entre los dos puntos de extremo deberá ser extendido.

En el caso de servicios de protocolo de descripción de sesión (SDP) para protocolo de inicio de sesión (SIP), este puede ser añadido mediante la definición de un nuevo modificador, según se describe en la RFC 3556 “Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth” (Modificadores de anchura de banda de protocolo de descripción de sesión (SDP) para anchura de banda de protocolo de control de RTP (RTCP)).

El protocolo de descripción de sesión (SDP) incluye un atributo de anchura de banda opcional con la siguiente sintaxis:

b=<modificador>:<valor-anchura de banda>

donde <modificador> es una única palabra alfanumérica que proporciona el significado de la cifra de anchura de banda. Esta puede ser extendida mediante la definición de nuevos modificadores para indicar la situación de turbo y/o el nivel de turbo requerido.

El dispositivo móvil o UE 300 que se muestra en la Figura 8b incorpora una aplicación para proporcionar un menú de presentación visual a través del cual el usuario pueda activar la característica del turbo. El dispositivo de presentación visual hace posible indicar el turbo para cada aplicación, o para cada sesión, y también el nivel de turbo, en caso necesario. Una vez que el usuario ha activado el turbo, la aplicación de terminal (o UE 300) genera la señalización correspondiente hacia el nodo de red, según se describe, por ejemplo, con referencia a la Figura 13.

Las entidades físicas de acuerdo con la invención, incluyendo los servidores, pueden comprender o almacenar programas informáticos que incluyen instrucciones tales que, cuando los programas informáticos son ejecutados en las entidades físicas, se llevan a cabo etapas y procedimientos de acuerdo con realizaciones de la invención. La invención también se refiere a programas informáticos tales, destinados a llevar a cabo métodos de acuerdo con la invención, así como a cualquier medio legible por computadora que almacena los programas informáticos para llevar a cabo métodos de acuerdo con la invención.

Cuando se utilizan, en la presente memoria, las expresiones “unidad de creación”, “unidad de disparo”, “unidad de decisión”, “unidad de recepción”, “unidad de instalación”, “unidad de inicio” y “unidad de restitución”, no se hace restricción alguna con respecto al modo como están distribuidos estos elementos ni en relación con cómo puedan estar reunidos o agrupados los elementos. Es decir, los elementos constituyentes de una unidad pueden estar distribuidos en diferentes componentes de software o de hardware, o en dispositivos para llevar a efecto la función deseada. Pueden reunirse también una pluralidad de elementos distintos con el fin de proporcionar las capacidades funcionales deseadas.

Cualquiera de las unidades anteriormente referidas de un servidor, o de un nodo de red, puede ser implementada en dispositivos físicos o hardware, en programación o software, en una matriz o conjunto geométricamente ordenado de puertas programables por campo (FPGA –“field-programmable gate array”), en un circuito integrado específico de la aplicación (ASICs –“application-specific integrated circuit”), firmware, o software instalado de forma permanente en hardware, o similares.

En realizaciones adicionales de la invención, cualquiera de entre la unidad de creación, unidad de disparo, unidad de decisión, unidad de recepción, unidad de instalación, unidad de inicio y unidad de restitución anteriormente mencionadas y/o reivindicadas es reemplazada por medios de creación, medios de disparo, medios de decisión, medios de recepción, medios de instalación, medios de inicio y medios de restitución, respectivamente, o por un creador, disparador, decisor, receptor, instalador, iniciador y restituidor, respectivamente, para llevar a cabo las

5 funciones de la unidad de creación, la unidad de disparo, la unidad de decisión, la unidad de recepción, la unidad de instalación, la unidad de inicio y la unidad de restitución.

En realizaciones adicionales de la invención, cualquiera de las etapas anteriormente descritas puede ser implementada utilizando instrucciones legibles por computadora, por ejemplo, en forma de procedimientos, métodos

10 o similares, comprensibles por una computadora, en cualquier tipo de lenguajes informáticos y/o en la forma de software o firmware embebido o incorporado, circuitos integrados o elementos similares.

Si bien la presente invención se ha descrito basándose en ejemplos detallados, los ejemplos detallados solo sirven para proporcionar a la persona experta una mejor comprensión, y no es la intención que limiten el alcance de la

15 invención. El alcance de la invención está definido, antes bien, por las reivindicaciones que se acompañan.

Claims (13)

1. REIVINDICACIONES

   1.-Un método para el control de políticas o criterios y de cargo, llevado a cabo por un nodo de red que incluye una función de aplicación, AF, por un primer servidor que incluye una función de reglas de criterios y de cargo, PCRF, por un segundo servidor que incluye una función de cumplimiento de criterios y de cargo, PCEF, y por un equipo de usuario, UE (300), configurado para interactuar con el nodo de red, de tal manera que el método incluye las etapas de crear (12), por parte de la PCRF, primeras reglas de control de criterios y de cargo, PCC, basándose en información de sesión negociada entre el UE (300) y la AF; instalar (14), en el establecimiento de una sesión en el plano del usuario asociada con el UE (300), las primeras reglas de PCC en la PCEF; e iniciar (16) un servicio asociado con el UE (300) de acuerdo con las primeras reglas de PCC, de tal manera que el servicio implica una pluralidad de medios de soporte; de tal manera que el método incluye, adicionalmente, las etapas de, durante el tiempo de duración de la sesión en el plano del usuario: transmitir (21), por parte del UE (300), al nodo de red, una petición de cambio de calidad de servicio, QoS, según un criterio por cada medio de soporte, al activarse una orden de interfaz de usuario en el UE (300), de tal modo que la petición de cambio de QoS es específica de un medio de soporte particular del servicio; crear (22), por parte de la PCRF, segundas reglas de PCC basándose en la petición de cambio de QoS, según un criterio por cada medio de soporte; instalar (24), en la PCEF, las segundas reglas de PCC, mediante el reemplazo de las primeras reglas de PCC por las segundas reglas de PCC; continuar (26) el servicio asociado con el UE (300) de acuerdo con las segundas reglas de PCC.
2. 2.-Un método de acuerdo con la reivindicación 1, en el cual la activación de la orden de interfaz de usuario en el UE (300) consiste en una activación (20) de un botón turbo (320).
3. 3.-Un método de acuerdo con la reivindicación 1 o la reivindicación 2, en el cual la petición de cambio de QoS es al menos una de entre una petición de un cambio en la categoría, nivel o grado asociado de QoS asociado con la sesión en el plano del usuario, una petición de un cambio en los recursos asociados con la sesión en el plano del usuario, una petición de un cambio en el rendimiento garantizado asociado con la sesión en el plano del usuario, y una petición de un cambio en la anchura de banda asociada con la sesión en el plano del usuario.
4. 4.-Un método de acuerdo con una cualquiera de las reivindicaciones precedentes, que incluye, de manera adicional, entre las etapas de transmitir (21) la petición de cambio de QoS y crear (22) las segundas reglas de PCC basándose en la petición de cambio de QoS, decidir (21a) al menos uno de:

   si la petición de cambio de QoS puede ser aplicada a la sesión en el plano del usuario; y en qué grado o extensión puede ser aplicada la petición de cambio de QoS a la sesión en el plano del usuario.
5. 5.-Un método de acuerdo con la reivindicación 4, en el cual la etapa de decidir (21a) incluye decidir basándose en al menos uno de entre las condiciones de red de acceso, las condiciones de desplazamiento itinerante, el tipo de acceso por radio, el nivel de congestión, el tiempo y el perfil del usuario.
6. 6.-Un método de acuerdo con una cualquiera de las reivindicaciones precedentes, en el cual la etapa de instalar (24), en la PCEF, las segundas reglas de PCC mediante el reemplazo de las primeras reglas de PCC por las segundas reglas de PCC, incluye asignar una nueva clave de cargo al servicio asociado con el UE (300).
7. 7.-Un método de acuerdo con una cualquiera de las reivindicaciones precedentes, que incluye adicionalmente restituir (28) las reglas de PCC aplicadas a la sesión en el plano del usuario, de vuelta a las primeras reglas de PCC cuando se produce al menos uno de los siguientes hechos: un lapso de tiempo termina o expira tras la etapa de instalar (24) las segundas reglas de PCC en la PCEF; se transmite una petición para restituir la QoS aplicada a la sesión en el plano del usuario, desde el UE (300); se llega a una hora concreta del día o tiempo de la semana; un perfil de usuario cambia; y un suceso en el plano del usuario invalida las segundas reglas de PCC modificadas.
8. 8.-Un servidor (100), configurado para implementar una función de reglas de políticas o criterios y de cargo, PCRF, de tal manera que el servidor (100) incluye:

   una unidad de creación (102), configurada para crear primeras reglas de control de criterios y de cargo, PCC, basándose en información de sesión negociada entre un equipo de usuario, UE (300), y una función de

   aplicación, AF; una unidad de desencadenamiento o disparo (104), destinada a desencadenar la instalación, en el establecimiento de una sesión en el plano del usuario asociada con el UE (300), de tal manera que las primeras reglas de PCC, situadas en el servidor (200), están configuradas para implementar una función de cumplimiento de criterios y de cargo, PCEF, y para iniciar un servicio asociado con el UE (300) de acuerdo con las primeras reglas de PCC, implicando el servicio una pluralidad de medios de soporte; y una unidad de recepción (106), configurada para recibir, durante el tiempo de duración de la sesión en el plano del usuario, una petición de cambio de calidad de servicio, QoS, según un criterio para medio de soporte, originada desde el UE (300), de tal manera que la petición de cambio de QoS es específica de un medio de soporte particular del servicio; estando configurada, adicionalmente, la unidad de creación (102) para crear, durante el tiempo de duración de la sesión en el plano del usuario, segundas reglas de PCC basándose en la petición de cambio de QoS, según un criterio para cada medio de soporte; estando configurada, adicionalmente, la unidad de disparo (104) para desencadenar o disparar la instalación, durante el tiempo de duración de la sesión en el plano del usuario, en el servidor (200) configurado para implementar la PCEF, de las segundas reglas de PCC mediante el reemplazo de las primeras reglas de PCC por las segundas reglas de PCC, de tal manera que el servidor (200) configurado para implementar la PCEF puede continuar el servicio asociado con el UE (300) de acuerdo con las segundas reglas de PCC.
9. 9.-Un servidor (100) de acuerdo con la reivindicación 8, que comprende, adicionalmente, una unidad de decisión (108), configurada para decidir al menos uno de entre:

   si la petición de cambio de QoS puede ser aplicada a la sesión en el plano del usuario; y hasta qué grado o extensión puede ser aplicada la petición de cambio de QoS a la sesión en el plano del usuario.
10. 10.-Un servidor (100) de acuerdo con la reivindicación 9, en el cual la unidad de decisión (108) está configurada para decidir basándose en al menos uno de entre las condiciones de red de acceso, las condiciones de desplazamiento itinerante, el tipo de acceso por radio, el nivel de congestión, el tiempo y el perfil de usuario.
11. 11.-Un programa informático que incluye instrucciones configuradas para, cuando se ejecutan en un servidor (100), implementar una función de reglas de políticas o criterios y de cargo, PCRF, hacer que el servidor (100) lleve a cabo las etapas de:

    crear (12) primeras reglas de control de criterios y de cargo, PCC, basándose en información de sesión negociada entre un equipo de usuario, UE (300), y una función de aplicación, AF; desencadenar o disparar la instalación (14), en el establecimiento de una sesión en el plano del usuario asociada con el UE (300), de las primeras reglas de PCC en el servidor (200) configurado para una implementación de una función de cumplimiento de criterios y de cargo, PCEF, y para el inicio de un servicio asociado con el UE (300) de acuerdo con las primeras reglas de PCC, de tal manera que el servicio implica una pluralidad de medios de soporte; y, de manera adicional, durante el tiempo de duración de la sesión en el plano del usuario, las etapas de: recibir (21), desde el UE (300), una petición de cambio de calidad de servicio, QoS, según un criterio por cada medio de soporte, de tal manera que la petición de cambio de QoS es específica de un medio de soporte particular del servicio; crear (22) segundas reglas de PCC basándose en la petición de cambio de QoS, según un criterio por cada medio de soporte; desencadenar o disparar la instalación (24), en el servidor (200) configurado para implementar la PCEF, las segundas reglas de PCC mediante el reemplazo de las primeras reglas de PCC por las segundas reglas de PCC, de tal manera que el servidor (200) configurado para implementar la PCEF puede continuar (26) el servicio asociado con el UE (300) de acuerdo con las segundas reglas de PCC.
12. 12.-Un terminal de usuario (300), dispuesto para transmitir una petición de cambio de calidad de servicio, QoS, según un criterio por cada medio de soporte para un servicio, al activarse una orden de interfaz de usuario en dicho terminal de usuario, de tal manera que dicho servicio implica una pluralidad de medios de soporte, y de modo que dicha petición de cambio de QoS es específica de un medio de soporte particular de dicho servicio.
13. 13.-Un terminal de usuario (300) de acuerdo con la reivindicación 12, en el cual la petición de cambio de QoS se da en la forma de una petición de establecimiento de protocolo de flujo de información en tiempo real, “RTSP”.