ES2349583T3 - Autorización dinámica de medios en redes móviles. - Google Patents

Abstract

Un aparato (222) para gestionar la calidad de servicio de una sesión, estando el aparato (222) configurado para determinar, si un flujo de medios que requiere la clase de tráfico más alta dentro de una pluralidad de flujos de medios se quita de la sesión, cuando se modifica la sesión establecida entre dos terminales móviles (110, 120) o un terminal móvil y un servidor, a través de un enlace de comunicación; que se caracteriza porque el aparato (222) está configurado además para mantener la clase de tráfico existente para los restantes flujos de medios para la sesión, si se quita de la sesión el flujo de medios que requiere la clase de tráfico más alta.

Description

ANTECEDENTES DE LA INVENCIÓN

CAMPO TÉCNICO

La presente invención se refiere a redes móviles que incluyen gestión de calidad de servicio (QoS) integral, y más particularmente, se refiere a la autorización y gestión dinámica de medios de clases de QoS de una sesión (conexión entre usuarios o terminales móviles, o entre un terminal móvil y un servidor) que comprende una pluralidad de tipos diferentes de flujos de medios dentro de redes móviles.

ANTECEDENTES DE LA INVENCIÓN

Las redes móviles de módem, tales como aquellas redes estandarizadas por las especificaciones del 3GPP (Proyecto de Asociación de Tercera Generación) que incluyen todos los GSM (Sistema Global para Comunicaciones Móviles) y terceras generaciones de redes GSM, son la integración sin fisuras de redes celulares digitales y sistemas de comunicaciones personales para proporcionar servicios de telecomunicación que incluyen, por ejemplo, servicios de redes de datos móviles y servicios multimedia IP.

Cada sistema 3GPP puede incluir una red de núcleo y una infraestructura de redes de acceso por radio que usa tecnologías de Servicio General de Radio por Paquetes (GPRS) y de Velocidades de Datos Mejoradas para la Evolución Global (EDGE) o que soportan Acceso por Radio Terrestre Universal (UTRA) operable tanto en Duplex por División de Frecuencia (FDD) como en Duplex por División de Tiempo (TDD). La red de núcleo CN puede estar lógicamente dividida en dominios conmutados por circuitos (CD) y conmutados por paquetes (PS) con entidades CN dispuestas para el tráfico de usuario y la señalizaciones relacionada, y un Subsistema Multimedia IP (IMS) con entidades de red de núcleo (CN) dispuestas para los servicios multimedia IP. Algunas entidades CN tales como el Servidor de Abonados Propios (HSS), el Registro de Posición de Clientes Propios (HLR), el Centro de Autenticación (AuC), el Registro de Posición de Visitantes (VLR) y el Registro de Identificación de Equipos (EIR) pueden ser comunes a los dominios PS y CS, mientras que otras entidades CN tales como el Centro de Conmutación Móvil (MSC) y el MSC de Puerta de Enlace son específicos del el dominio CS para gestionar los servicios conmutados por circuitos hacia / desde las estaciones móviles, y el Nodo de Soporte (GGSN) del GPRS (servicio general de radio por paquetes) de Puerta de Enlace y el GSN de Servicio (SGSN) son específicos para el dominio PS para gestionar la transmisión de paquetes hacia / desde las estaciones móviles.

Para servicios multimedia IP, las entidades IMS funcionales, tales como la Función de Control de la Sesión de Llamada (CSCF) pueden disponerse para manejar procedimientos relacionados con la CDCF, incluyendo el establecimiento del contexto de PDP (Protocolo de Datos por Paquetes, por ejemplo, IP) para la señalización relacionada con el IMS, el registro y otros procedimientos para las sesiones IMS. La CSCF puede actuar como CSCF Proxy (PCSCF) para servir como un primer punto de contacto para un equipo de usuario (UE) (por ejemplo, el dispositivo que permite que un usuario acceda a los servicios de red, tal como un terminal móvil dentro del subsistema multimedia IP (IMS), la CSCF de Servicio (S-CSCF) para gestionar estados de la sesión en la red o una CSCF interrogativa (I-CDCF) para servir como punto de contacto dentro de una red del operador para todas las conexiones IMS destinadas bien a un abonado de ese operador de red o bien a un abonado itinerante en un área de servicio dada. Consulte la Especificación Técnica (TS) 3GPP 23.002, V5.9.0 (diciembre de 2002) “Network Architecture”; la TS 3GPP 23.101, V4.0.0 (abril de 202) “General UMTS Architecture”; y la TS 3GPP 23.110, V4.0.0 (abril de 2001) “UMTS Access Stratum: Services and Functions”; y la Especificación Técnica (TS) 3GPP 23.228, V6.0.1 (enero de 2003) “IP Multimedia Subsystem (IMS)”. Todas las especificaciones 3GPP (GSM/3G) pueden encontrarse y descargarse del servidor 3GPP en ftp://ftp.3gpp.org/especs. Además, los mecanismos para crear, mantener y actualizar las especificaciones 3GPP (incluyendo diferentes versiones de una especificación 3GPP dada con una funcionalidad nueva o modificada) también puede encontrarse en la Especificación Técnica (TS) 3GPP 21.900 V5.0.1 (septiembre de 2002) “Technical Specification Group Working Methods.”

Se ha estandarizado una Función de Decisión de Política (PDF) para supervisar la gestión de las clases de calidad de servicio (QoS) de una sesión que comprenda una pluralidad de flujos de medios, para efectuar decisiones de estrategia basadas en la sesión y en la información relacionada con los medios, incluyendo la máxima clase autorizada de tráfico para un flujo de medios dado entre dos usuarios (terminales móviles) o entre un terminal móvil y un servidor, y para intercambiar entonces la información de la decisión con el GGSM a través de una interfaz Go, tal como se pone de manifiesto en la TS 3GPP 29.207 V.5.2.0 (siembre de 2002) “Policy Control over Go Interface”, Versión 5; en la 3GPP TS 23.207 V.5.6.0 (diciembre de 2002) “EndTo-End Quality of Service (QoS) Concept and Architecture”, Versión 5 y en la TS 3GPP 29.208

V.5.2.0 (diciembre de 2002) ) “End-To-End Quality of Service (QoS) signaling flows”, Versión 5. Dicha PDF puede integrarse dentro de la P-CSFC tal como se pone de manifiesto en la especificación 3GPP, Versión 5 (diciembre de 2002), o alternativamente, puede implementarse en un elemento de red separado que está separado de la P-CSCF tal como se pone de manifiesto en la TS 3GPP, Versión 6 (enero de 2003).

En general, cuando se establece una sesión (conexión) entre equipos de usuario (UE) (por ejemplo, terminales móviles), o entre un terminal móvil y un servidor, y se modifica la sesión (por ejemplo, de audio bidireccional y vídeo unidireccional a vídeo unidireccional solamente), la PDF cambia la clase de tráfico (de conversacional a flujo de datos en tiempo real). Esto es porque la sesión tal como se estableció entre los equipos de usuario (UE), por ejemplo terminales móviles, o entre un terminal móvil y un servidor, comprende un flujo de audio bidireccional y un flujo de vídeo unidireccional. El flujo de audio bidireccional se usa para una conversación en tiempo real, y consecuentemente, requiere una clase de tráfico en tiempo real de bajo retardo, por ejemplo, la clase de tráfico CONVERSATIONAL. El flujo de vídeo unidireccional se usa para transferir imágenes de vídeo en movimiento solamente en una dirección. Dicho flujo de vídeo unidireccional en tiempo real tolera retardos de transmisión más largos y variaciones de retardo (a.k.a., fluctuaciones) ya que el remitente no espera recibir respuesta. Como resultado, el flujo unidireccional en tiempo real utiliza típicamente una clase de tráfico STREAMING en la práctica. Si la sesión se modifica, es decir, si uno del flujo de audio bidireccional o del flujo de vídeo unidireccional finaliza y se quita de la sesión, consecuentemente es necesario que la PDF cambie la clase de tráfico para los recursos portadores. Por ejemplo, si se elimina de la sesión el flujo de audio bidireccional con la clase de tráfico CONVERSATIONAL, el flujo de vídeo unidireccional, con la clase de tráfico STREAMING como requisito por defecto, tiene ahora la “clase de tráfico más alta” de la sesión. Consecuentemente, la PDF cambia (por ejemplo, baja de clasificación) la clase de tráfico para el portador de la sesión de clase de tráfico CONVERSATIONAL a clase de tráfico STREAMING.

Sin embargo, algunos parámetros, tales como el tamaño del búfer en el terminal de recepción, son diferentes en estas clases de tráfico, el cambio de la clase de tráfico con el cambio inherente del retardo de la transmisión provocará el subdesbordamiento del búfer en el terminal

o servidor receptor, reduciendo así la calidad de la conexión percibida por el usuario final.

Puede ocurrir otro problema significativo, cuando se añade un flujo unidireccional (por ejemplo, vídeo) a una sesión existente que comprende un flujo bidireccional (por ejemplo, audio). La petición de clase de tráfico señalada del flujo de vídeo unidireccional es típicamente flujo de datos en tiempo real. La clase de tráfico de la sesión bidireccional es conversacional. Si los flujos de medios tienen una relación temporal (por ejemplo una explicación verbal del flujo de vídeo en el flujo de audio), la diferencia de las clases de tráfico provocará una diferencia en los retardos de transmisión (debido a las diferentes longitudes de los búferes en los receptores para compensar los diferentes retardos y fluctuaciones del retardo en la transmisión), reduciendo así la calidad de la conexión percibida por el usuario final.

Consecuentemente, existe la necesidad de soluciones que puedan ser aplicables a todos los sistemas en los cuales una sesión (conexión entre usuarios o terminales móviles o entre un terminal móvil o un servidor) pueda comprender una pluralidad de tipos de flujos de medios y que se vinculan con la autorización de los medios y una mejor gestión de las clases de calidad de servicio (QoS) de una sesión (conexión entre usuarios o terminales móviles o entre un terminal móvil o un servidor) que comprenda una pluralidad de tipos diferentes de flujos de medios dentro de redes móviles de forma que, cuando los flujos de medio se modifican (se inician nuevos y se eliminan existentes) durante la sesión, la clase de tráfico de una sesión se defina por los mayores requisitos de clase de tráfico de los flujos de los medios que pertenecen a la misma sesión para eliminar las diferencias de retardos de transmisión de los flujos de medios que pertenecen a la misma sesión y, por lo tanto mejorar la calidad de la conexión percibida por el usuario final.

La invención está definida en las reivindicaciones independientes. Ciertas realizaciones específicas se definen en las reivindicaciones dependientes.

Algunos aspectos de la invención pueden estar dirigidos a soluciones para una autorización dinámica de medios y una mejor gestión de las clases de calidad de servicio (QoS) de una sesión (conexión entre usuarios o terminales móviles o entre un terminal móvil o un servidor) que comprenda una pluralidad de tipos diferentes de flujos de medios dentro de redes móviles de forma que, cuando se modifican uno o más flujos de medios (se inician nuevos o se eliminan los existentes) durante la sesión, la clase de tráfico de una sesión esté definida por los requisitos más altos de clase de tráfico de los flujos de medios que pertenecen a la misma sesión para eliminar la diferencia en los retardos de transmisión de los flujos de los medios que pertenecen a la misma sesión, y por lo tanto mejorar la calidad de la conexión percibida por el usuario final.

De acuerdo con un aspecto de la invención, se suministra una Función de Decisión de Política

(PDF) en una red móvil para determinar una clase máxima de tráfico autorizado para un flujo de medios dado de una sesión entre dos terminales móviles o entre un terminal móvil y un servidor. Dicha PDF se configura para determinar si uno o varios flujos de medios, que requieren la clase de tráfico más alta dentro de una pluralidad de diferentes tipos de flujos de medios, se han quitado de la sesión, cuando se establece una sesión y está siendo modificada entre dos terminales móviles o entre un terminal móvil y un servidor, a través de un enlace de comunicación; y mantener la clase de tráfico usada para los restantes flujos de medios para la sesión, si uno o varios flujos de medios que requieren la clase de tráfico más alta se quitan de la sesión.

De acuerdo con otro aspecto de la invención, se configura una Función de Decisión de Política (PDF) para determinar si se añade un flujo unidireccional a la sesión que comprende un flujo bidireccional, cuando se establece o modifica una sesión entre dos terminales móviles o entre un terminal móvil y un servidor, a través de un enlace de comunicación; y para aplicar a todos los flujos de medios de la sesión la clase de tráfico más alta, asignada a cualquiera de los flujos de medios de la sesión, durante el tiempo de vida de la sesión, si se añade el flujo unidireccional a la sesión que comprende el flujo bidireccional en una red móvil para determinar una clase máxima autorizada de tráfico para un flujo de medios dado de una sesión entre dos terminales móviles o entre un terminal móvil y un servidor, a través de un enlace de comunicación.

De acuerdo con otro aspecto adicional de la invención, se suministra un medio legible por ordenador con instrucciones que, cuando son ejecutadas por una red móvil, realizan un procedimiento de determinación de una clase máxima de tráfico autorizado para un flujo de medios dado de una sesión entre dos terminales móviles o entre un terminal móvil y un servidor, que incluye: determinar si se añade un flujo unidireccional a una sesión que comprende un flujo bidireccional, cuando se establece o modifica la sesión entre dos terminales móviles o entre un terminal móvil y un servidor a través de un enlace de comunicación; y aplicar la clase de tráfico más alta, asignada a cualquiera de los flujos de medios de la sesión, a todos los flujos de medios de la sesión durante el tiempo de vida de la sesión si se añade el flujo unidireccional a la sesión que comprende el flujo bidireccional.

La presente invención se describe más específicamente, solamente a modo de ejemplo, en los siguientes párrafos mediante la referencia a los dibujos adjuntos.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

Una apreciación más completa de la presente invención y de muchas de sus ventajas será fácilmente evidente a medida que la misma se entiende mejor mediante la referencia a la siguiente descripción detallada cuando se considera en conjunción con los dibujos adjuntos en los cuales símbolos de referencia similares indican los mismos o similares componentes, en donde:

La figura 1 ilustra una arquitectura de un sistema de red de ejemplo para suministrar servicios de telecomunicación incluyendo servicios multimedia IP de acuerdo con la Especificación 3GPP, Versión 5.

La figura 2 ilustra una arquitectura de interfaz de ejemplo de entidades funcionales de IMS de acuerdo con la Especificación 3GPP, Versión 5.

La figura 3 ilustra una arquitectura de interfaz de ejemplo de entidades funcionales de IMS de acuerdo con una realización de la presente invención.

La figura 4 ilustra una sesión de trabajo de ejemplo entre dos equipos de usuario (terminales móviles), o entre un terminal móvil y un servidor, usando nuevas reglas de mapeo, cuando los flujos de medios son unidireccionales y tienen la misma dirección, de acuerdo con una realización de la presente invención.

La figura 5 ilustra una sesión de trabajo de ejemplo entre dos equipos de usuario (terminales móviles) o entre un terminal móvil y un servidor, usando nuevas reglas de mapeo, cuando los flujos de medios son unidireccionales y no tienen la misma dirección, de acuerdo con una realización de la presente invención.

La figura 6 ilustra una sesión de trabajo de ejemplo entre dos equipos de usuario (terminales móviles) o entre un terminal móvil y un servidor, usando nuevas reglas de mapeo, cuando un flujo de medios es bidireccional y el otro unidireccional, de acuerdo con una realización de la presente invención.

La figura 7 ilustra una sesión de trabajo de ejemplo entre dos equipos de usuario (terminales móviles) o entre un terminal móvil y un servidor, usando nuevas reglas de mapeo, cuando un flujo de medios es bidireccional (diferente de audio / vídeo) y el otro unidireccional (audio / vídeo), de acuerdo con una realización de la presente invención.

MEJOR MODO PARA LLEVAR A CABO LA INVENCIÓN

La presente invención es aplicable para su uso con todos los tipos de redes que soportan una pluralidad de tipos diferentes de flujos de medios, incluyendo, segunda y tercera generaciones de redes GSM (Sistema Global para Comunicaciones Móviles), redes de tránsito tales como Internet, Intranets, redes de área local (LAN) y redes de tránsito basadas en ATM y redes terminales tales como redes telefónicas públicas conmutadas (PSTN), ISDN, redes IP/LAN,

X.25 y Redes Móviles Terrestres (PLMN) y sistemas interconectados y protocolos relacionados usados para transferencias de voz, mensajes, datos e imágenes entre sistemas en dichas redes móviles. Sin embargo, para mayor simplicidad, el análisis se concentrará principalmente en una red multimedia simple que incluye entidades del Subsistema Multimedia IP (IMS) para suministrar servicios multimedia IP.

La atención se centra ahora en los dibujos y particularmente en la figura 1, se ilustra una arquitectura de sistema de red de ejemplo para suministrar sistemas de telecomunicación incluyendo servicios multimedia IP de acuerdo con la Especificación 3GPP, Versión 5, Según se muestra en la figura 1, la arquitectura 100 del sistema de red puede incluir ampliamente, un equipo (UE) 110 de usuario de origen, un equipo (UE) 120 de usuario final o viceversa y un enlace 130 de comunicación dispuesto para conectar los equipos (UE) 110/120 de usuario y puede expandirse sobre una única red o sobre diferentes redes, tal como, por ejemplo, una Red Móvil Terrestre Pública (PLMN) 132, una o más redes 134 de tránsito y una red 136 terminal. El equipo (UE) 110/120 de usuario puede ser un dispositivo o terminal de usuario para permitir al usuario acceder a los servicios de red, incluyendo, por ejemplo, un servidor remoto o un terminal móvil para GSM según se define en la TS 3GPP, V 5.0.0 (diciembre de 2001), Versión 5.

Cada UE 110/120 puede incluir, por ejemplo, una terminación móvil (MT) 112, un equipo terminal (TE) 114 y una función de adaptación de terminal (TAF) 116 dispuestos para realizar la transmisión de radio y las funciones relacionadas, y puede contener aplicaciones integrales para dar soporte a los servicios de telecomunicación.

La red 134 de tránsito puede incluir, aunque no en sentido limitativo, Internet, Intranet, una red de área local (LAN) o una red de tránsito basada en ATM. La red terminal 136 puede incluir, aunque no en sentido limitativo, una red telefónica pública conmutada (PSTN), un ISDN, una red IP/LAN, X.25 u otra Red Móvil Pública Terrestre (PLMN).

La figura 2 ilustra una arquitectura de interfaz de ejemplo de entidades funcionales del IMS en redes móviles de acuerdo con la Especificación 3GPP, Versión 5. Según se muestra en la figura 2, el Nodo de Soporte (GGSN) 210 del GPRS (servicio de radio general por paquetes) de Puerta de Enlace y la Función de Control de Sesión de Llamada de Proxy (P-CSCF) 220 representan entidades de red que son parte de la red de núcleo. Puede utilizarse el GGSN para gestionar la transmisión de paquetes hacia / desde el UE 110/120 (por ejemplo, estaciones móviles). La P-CSCF 220 puede usarse para servir como primer punto de contacto para un UE 110/120 dado y para suministrar servicios de gestión de sesión y procedimientos relacionados con la CSCF, incluyendo el establecimiento del contexto PDP (Protocolo de Datos por Paquetes, por ejemplo, IP) para la señalización relacionada con el subsistema multimedia IP (IMS), el registro y otros procedimientos para sesiones del IMS.

De acuerdo con la Especificación 3GPP, Versión 5 (diciembre de 2002), una Función de Decisión de Políticas (PDF) 222 se integra dentro de la P-CSCF 220 para supervisar una sesión IMS cuando el UE 110 envía o recibe un mensaje SIP (Protocolo de Iniciación de Sesión) que contiene señalización SDP (Protocolo de Descripción de Sesión) para negociar los parámetros para una sesión IMS y efectuar decisiones de política basándose en la sesión IMS y en la información relacionada con los medios obtenida de la P-CSCF 220, incluyendo las decisiones que se refieren a la clase máxima de tráfico autorizado para un flujo de medios dado entre dos usuarios (por ejemplo, terminales móviles) o entre un terminal móvil y un servidor e intercambiar entonces la información de las decisiones con el GGSN 210 por medio de una interfaz Go, tal como se pone de manifiesto en la TS 3GPP 29.207 V.5.2.0 (diciembre de 2002) “Policy Control over Go Interface”, Versión 5. Además solamente se permite una sesión simple IMS para cada contexto PDP (Protocolo de Datos por Paquetes, por ejemplo IP). Alternativamente, la PDF también puede implementarse en un elemento de red separado que esté separado de la P-CSCF 220, según se describe en la Especificación 3GPP, Versión 6 (enero de 2003).

Tal como se analizó y se puso de manifiesto previamente en la Especificación 3GPP, Versión 5, la PDF 222 puede usarse para generar un conjunto de información vinculante (especialmente, un testigo de autorización para vincular el nivel de IMS y el nivel de portador de GPRS de una sesión IMS, y enviar la información vinculante al GGSN 210 a través del equipo (UE) 110 de usuario. La información vinculante asocia un contexto PDP (Protocolo de Datos por Paquetes, por ejemplo IP) con uno o más componentes de medios (flujos IP) de una sesión IMS, y es usada por el GGSN 210 para solicitar la información de política local basada en el Servicio (SBLP) de PDF 222. Dicha información vinculante típicamente incluye:

(1)

un testigo de autorización enviado por la P-CSCF 220 al UE 110 durante la señalización SIP/SDP y

(2)

uno o más identificadores de flujo (que pueden ser añadidos por el UE 110 después de recibir la información vinculante de la P-CSCF/PDF) usados por el UE 110, el GGSN 210 y la PDS 222 para identificar de forma única el o los flujos de medios IP asociados con la sesión SIP.

Una vez recibida dicha información vinculante, el GGSN 210 se utiliza entonces para buscar la dirección de la PDF del conjunto de información vinculante (del testigo de autorización) recibida del UE 110, identificar la PDF correcta y verificar que las operaciones de contexto PDP solicitadas por el UE 110 obedecen la negociación precedente en el nivel IMS.

En el GGSN 210, el Punto de Refuerzo de Políticas (PEP) 212 es un entidad lógica que comunica con la PDF en lo que respecta al control de la política local basada en el Servicio (SBLP). Para mayor simplicidad, se asume que el GGSN 210 contiene implícitamente el PEP 212 a menos que se diga de otra manera. El GGSN 210 envía peticiones y recibe decisiones de la PDF 222. El GGSN 210 puede almacenar temporalmente los datos de las decisiones de política de las decisiones de la PDF que pueden utilizarse posteriormente para una decisión de política local que permita que el GGSN 210 efectúe una decisión de control de política relativa a la autorización de calidad de servicio (QoS) para modificaciones del contexto PDP sin requerir ninguna interacción adicional con la PDF 222. Las funcionalidades del PEP para el SBLP en el GGSN se describen en la TS 3GPP 29.207 V.5.2.0 (diciembre de 2002) “Policy Control over Go Interface”, Versión 5 y, por lo tanto, no es necesario repetirlas aquí.

Tanto el UE 110 como el GGSN 210 pueden incluir también mecanismos para gestionar funciones integrales de calidad de servicio (QoS) IP y los flujos de señalización relacionados según se describe en la TS 3GPP 23.207 V.5.6.0 (diciembre de 2002) “End-To-End Quality of Service (QoS) Concept and Architecture”, Versión 5 y en la TS 3GPP 29.208 V.5.2.0 (diciembre de 2002) “End-To-End Quality of Service (QoS) signaling flows”, Versión 5, que se incorporan aquí por referencia. Por ejemplo, el UE 110 puede incluir una aplicación de cliente (no mostrada), un gestor de portador de servicio (BS) IP (no mostrado), una función de traducción / mapeo (no mostrada) y, opcionalmente, un gestor de servicio portador (BS) UMTS (no mostrado). Asimismo, el GGSN 210 también puede incluir un gestor de BS IP (no mostrado), una función de traducción / mapeo (no mostrada) y, opcionalmente, un gestor de servicio portador (BS) UMTS (no mostrado). Los gestores de BS IP utilizan habitualmente mecanismos IP estándar para gestionar servicios portadores IP. Las funciones de traducción / mapeo suministran interoperación entre los mecanismos y parámetros utilizados dentro de los servicios portadores UMTS y aquellos usados dentro de los servicios portadores IP e interactúan con los gestores de BS IP. Los gestores de BS UMTS utilizan mecanismos UMTS estándar para gestionar servicios portadores UMTS (Sistema de Telecomunicaciones Móvil Universal) y funciones de gestión de QoS para servicios portadores UMTS.

En general, una sesión se establece (conexión) entre equipos de usuarios (UE) (por ejemplo, terminales móviles capaces de transmitir y recibir flujos multimedia IP) o entre un terminal móvil y un servidor. La sesión tal como se establece entre equipos de usuario (UE) (por ejemplo, terminales móviles) o entre un terminal móvil y un servidor, comprende, por ejemplo, un flujo de audio bidireccional y un flujo de vídeo unidireccional. El flujo de audio bidireccional se utiliza para una conversación en tiempo real y, consecuentemente, requiere una clase de tráfico en tiempo real de bajo retardo, por ejemplo, la clase de tráfico CONVERSATIONAL. El flujo de vídeo unidireccional se utiliza para transferir imágenes de vídeo en movimiento solamente en una dirección. Dicho flujo de vídeo unidireccional en tiempo real tolera mayores retardos de transmisión y variaciones de retardo (a.k.a., fluctuación) ya que el remitente no espera remitir ninguna respuesta. Como resultado, el flujo unidireccional en tiempo real utiliza típicamente una clase de tráfico STREAMING en la práctica. La clase de tráfico CONVERSATIONAL se caracteriza por un corto retardo máximo en la transmisión y una pequeña variación de retardo para minimizar el retardo experimentado por los comunicantes (por ejemplo, terminales móviles

o entre un terminal móvil y un servidor), mientras que la clase de tráfico STREAMING se caracteriza por un mayor retardo máximo de transmisión y una mayor variación del retardo ya que no es una comunicación bidireccional en tiempo real con respuestas en tiempo real. Como resultado, la clase de tráfico CONVERSATIONAL se conoce como una «clase de tráfico más alta» con relación a la clase de tráfico STREAMING, que se conoce como una «clase de tráfico más baja».

De acuerdo con la TS 3GPP 23.107, pueden requerirse otras clases de tráfico en la sesión de ejemplo, tal como la clase de tráfico INTERACTIVE y la clase de tráfico BACKGROUND. Por ejemplo, la clase de tráfico INTERACTIVE puede caracterizarse por tolerar retardos y fluctuaciones de la transmisión todavía más largos que la clase de tráfico STREAMING y, consecuentemente es una «clase de tráfico más baja» que la clase de tráfico STREAMING. La clase de tráfico BACKGROUND puede caracterizarse por tolerar retardos de transmisión y fluctuaciones todavía más largos y, como resultado, es una clase de tráfico aún más baja que la clase de tráfico INTERACTIVE. Sin embargo, los flujos de audio y de vídeo de la sesión de ejemplo pueden ser llevados por el mismo portador (por ejemplo, un contexto PDP en el sistema de red) o pueden tener una relación temporal entre sí, significando que los recursos portadores de la sesión completa tienen una clase de tráfico CONVERSATIONAL de acuerdo con la «clase de tráfico más alta» de la sesión.

Transcurrido un tiempo, puede modificarse la sesión, es decir, los usuarios de la comunicación (por ejemplo, terminales móviles o un terminal móvil y un servidor) pueden desear finalizar, por ejemplo, el flujo de flujo de audio bidireccional de la sesión, mientras mantienen el flujo de vídeo unidireccional de la sesión. Consecuentemente, es necesario que la PDF cambie la clase de tráfico para los recursos portadores de la sesión. Por ejemplo, si la sesión se modifica y el flujo de audio bidireccional con la clase de tráfico CONVERSATIONAL es eliminado de la sesión, el flujo de vídeo unidireccional con la clase de tráfico STREAMING como requisito por defecto, tiene ahora la «clase de tráfico más alta» de la sesión. Consecuentemente, la PDF cambia (por ejemplo, actualiza a la clasificación anterior) la clase de tráfico para el portador de la sesión, de la clase de tráfico CONVERSATIONAL a la clase de tráfico STREAMING.

Sin embargo, cuando se modifica la sesión (por ejemplo, de audio bidireccional y vídeo unidireccional a vídeo unidireccional solamente) y la PDF 222 cambia la clase de tráfico (por ejemplo, de CONVERSATIONAL a STREAMING), algunos parámetros, tal como el tamaño del buffer en el terminal receptor, son diferentes en estas clases de QoS, el cambio de la clase de tráfico con el cambio inherente del retardo de transmisión puede provocar subdesbordamientos en el terminal receptor, reduciendo así la calidad de la conexión percibida por el usuario final.

Por ejemplo, cuando se establece una sesión (conexión), los terminales móviles, o un terminal móvil y un servidor, inician la comunicación con un flujo de voz bidireccional. En este punto, la PDF 222 asigna al flujo de voz la clase máxima autorizada de tráfico que es igual a CONVERSATIONAL. Pasado algún tiempo, uno de los terminales móviles, o uno de entre un terminal móvil y un servidor, decide añadir un flujo de vídeo a la comunicación y el flujo de vídeo es unidireccional. En este punto la PDF 222 comprueba el conjunto actual de flujos multimedia IP que pertenecen a la sesión (conexión) y decide asignar al flujo de vídeo una clase máxima autorizada de tráfico igual a «CONVERSATIONAL». Esta clase es seleccionada ya que hay un flujo de medios bidireccional existente que está autorizado para la clase de tráfico «CONVERSATIONAL». Como resultado, el terminal móvil o el servidor que recibe los flujos tanto de voz como de vídeo es capaz de obtener sincronización de audio - vídeo. Después de algún tiempo, los dos terminales móviles, o el terminal móvil y el servidor, deciden dejar la comunicación de voz, pero continúan la transmisión de vídeo unidireccional. En este punto, la PDF 222 comprueba el conjunto actual de flujos multimedia IP que pertenecen a la sesión (solamente queda el flujo de vídeo unidireccional en la comunicación) y decide cambiar su clase máxima autorizada de tráfico a «STREAMING». Esto ocurre a causa de que el flujo de medios unidireccional consigue siempre una clase máxima autorizada de tráfico igual a «STREAMING».

Sin embargo, si la clase máxima autorizada de tráfico se cambia de «CONVERSATIONAL» a «STREAMING» este cambio daría problemas al terminal móvil o el servidor que recibe el flujo de vídeo. En particular, el cambio podría provocar una renegociación en el contexto PDP, en el que no solamente la clase de tráfico es diferente sino que también el retardo de transferencia es diferente. Como resultado, un mayor retardo de transferencia podría producir subdesbordamientos del buffer frecuentes y repetidos en el terminal móvil receptor y un medio no continuo, dando como resultado que el usuario final perciba una calidad inferior. Esto es porque el búfer del terminal móvil o del servidor está dimensionado de acuerdo con el retardo de transferencia de la clase de tráfico «CONVERSATIONAL», no de acuerdo con la clase de tráfico «STREAMING».

También podría producirse otro problema significativo cuando se añade un flujo unidireccional (por ejemplo, vídeo) a una sesión existente que comprenda un flujo bidireccional (por ejemplo, audio). La petición de la clase de tráfico señalada del flujo de vídeo unidireccional es típicamente streaming. La clase de tráfico de la sesión bidireccional es conversational. Si los flujos de medios tienen una relación temporal (por ejemplo, una explicación verbal del flujo de vídeo en el flujo de audio) la diferencia del las clases de tráfico provocará una diferencia en los retardos de transmisión (debido a las diferentes longitudes de los búferes en los receptores para compensar los diferentes retardos y fluctuaciones del retardo en la transmisión, reduciendo así la calidad de la conexión percibida por el usuario final.

Por ejemplo, una sesión (conexión) se inicia con un flujo unidireccional. En este punto, la PDF

222 asigna «STREAMING» como clase máxima autorizada de tráfico. Después de algún tiempo, se añade un flujo bidireccional de llamada de voz a la comunicación. En este punto, la PDF 222 asigna al flujo de voz una clase máxima autorizada de tráfico igual a «CONVERSATIONAL». La PDF 222 también vuelve a comprobar la clase máxima autorizada de tráfico del primer flujo existente y la actualiza a «CONVERSATIONAL». En algunos casos, la actualización puede provocar una negociación de contexto PDP para el flujo multimedia IP, particularmente, cuando los flujos multimedia IP están relacionados y requieren sincronización. Sin embargo, en la mayoría de los casos no se necesita actualización.

Volviendo ahora a la figura 3, se ilustra una arquitectura de interfaz de ejemplo de entidades funcionales IMS de acuerdo con una realización de la presente invención. La arquitectura de la interfaz, según se muestra en la figura 3, mantiene de forma ventajosa la clase de tráfico usada para la sesión, por ejemplo, para el resto de los flujos multimedia IP, cuando los flujos de medios que requieren la clase de tráfico más alta son eliminados de la sesión para evitar el problema producido cuando se cambia la clase de tráfico y para aplicar la clase de tráfico más alta (tiempo real, por ejemplo CONVERSATIONAL, STREAMING) asignada a cualquiera de los flujos de medios de la sesión, para todos los flujos de medios (tiempo real) de la sesión durante el tiempo de vida de la sesión para evitar el problema que se produce cuando se añade un flujo de medios a una sesión existente.

Según se muestra en la figura 3, puede implementarse un algoritmo 310 como parte de la PDF 222, siempre que la PDF 222 esté integrada dentro de la P-CSCF 220 o una entidad de red permanezca separada de la P-CSCF 220. En el algoritmo 310, la eliminación de uno o varios flujos multimedia durante el tiempo de vida de una sesión (conexión) puede definirse de manera que no se actualice a la clasificación anterior la clase máxima autorizada de tráfico previamente asignada y, asimismo, pueda definirse la adición de flujos de medios para asignar la clase máxima de tráfico de los flujos a todos los flujos (tiempo real) de la sesión (conexión). El uso de dicho algoritmo 310 puede aplicarse a todos los sistemas, incluyendo todas las redes multimedia futuras, en las cuales una sesión puede comprender una pluralidad de diferentes tipos de flujos de medios y puede cumplir, por ejemplo, con la TS 3GPP 23.207 V.5.6.0 (diciembre de 2002) “End-To-End Quality of Service (QoS) Concept and Architecture” Versión 5 y con la TS 3GPP 29.208 V.5.2.0 (diciembre de 2002) “End-To-End Quality of Service (QoS) signaling flows”, Versión 5.

La sincronización de flujos de medios en tiempo real puede mejorarse también eliminando la

diferencia de los retardos de transición de los flujos de medios que pertenecen a la misma sesión, mejorando así la calidad percibida por el usuario final. Puede haber un inconveniente en que las clases de QoS asignadas a todos los flujos de medios en la sesión puedan ser más altas que las requeridas, reduciendo así la capacidad total de la red y también provocando potencialmente mayores costes de conexión para el usuario final.

Por ejemplo el usuario / UE inicia una sesión o extiende una sesión con flujos de menor clase de tráfico, con uno o unos flujos de corrientes de datos unidireccionales. En este punto, la PDF 222 asigna «STREAMING» como clase máxima autorizada de tráfico a los flujos de medios pertinentes. Posteriormente durante el tiempo de vida de la sesión, el usuario / UE inicia un flujo bidireccional (por ejemplo, audio) dentro de la misma sesión. En este punto, la PDF 222 asigna al flujo de audio la clase máxima autorizada de tráfico igual a «CONVERSATIONAL». La PDF 222 también vuelve a comprobar la clase máxima autorizada de tráfico de los flujos ya existentes. La actualización de los flujos de medios existentes al valor de la clase de tráfico del nuevo flujo bidireccional puede ser innecesaria, ya que los flujos de corrientes de datos unidireccionales se han iniciado antes que el flujo conversacional bidireccional y consecuentemente puede que no tengan relación temporal con el flujo conversacional bidireccional. La actualización no es deseable ya que las clases de QoS asignadas a algunos flujos de medios en la sesión pueden ser mayores que las requeridas, reduciendo así la capacidad total de la red y también provocando potencialmente mayores costes de conexión para el usuario final.

Sin embargo, puede evitarse la actualización si los flujos unidireccionales se iniciaron primero, y se consideran independientes de un flujo o flujos bidireccionales posteriores, por ejemplo, no hay relación temporal. Entonces no se necesita sincronización, por ejemplo, la clase de tráfico permanecerá «STREAMING», cuando se añade un flujo de medios conversacional bidireccional. (En un sistema IMS, los flujos con diferentes clases de tráfico / QoS usarán entonces contextos PDP separados). Alternativamente, si se inició primero un flujo conversacional bidireccional y se añade un flujo de corriente de datos unidireccional posteriormente a la sesión, el flujo de la corriente de datos unidireccional se considera como dependiente del bidireccional, por ejemplo hay una relación temporal entre ellos. Por lo tanto se requiere sincronización, por ejemplo, la clase de tráfico del flujo de corriente de datos unidireccional se ajustará al mismo valor que la clase de tráfico del flujo bidireccional, es decir, «CONVERSATIONAL» (mediante la PDF 222). (En un sistema IMS, los flujos con diferentes clases de tráfico / QoS pueden utilizar entonces un contexto PDP común o contextos PDP separados.

La PDF 222, según se muestra en la figura 3, puede configurarse para determinar la clase máxima autorizada de tráfico para un flujo de medios dado de una conexión entre dos terminales móviles o entre un terminal móvil y un servidor. Un algoritmo 310 de ejemplo en la PDF 222 puede incluir lo siguiente:

si una clase máxima autorizada de tráfico ha sido asignada a un flujo X dado, entonces la adición o eliminación de uno o varios flujos de medios durante el tiempo de vida de una sesión (conexión) no produce ningún cambio para la clase máxima autorizada de tráfico previamente asignada para el flujo X.

También pueden requerirse reglas de mapeo de conformidad con la TS 3GPP 29.208 V.5.6.0 (diciembre de 2002) “End-To-End Quality of Service (QoS) signaling flows”, Versión 5, de manera que pueda asignarse una clase máxima autorizada de QoS adecuada a un servicio de corriente de datos. Dichas reglas de mapeo pueden ser utilizadas por la PDF 222, tal como se muestra en la figura 3, cuando se inicia o modifica una sesión para obtener la QoS máxima autorizada adecuada por componente de medios. Sin embargo, es necesario definir un mapeo adecuado de manera que se asegure que no estén restringidos futuros servicios y que puedan evitarse abusos, fraudes o ineficacia. En general, un servicio de corriente de datos puede caracterizarse por la dirección del flujo de datos -es o no unidireccional- y por el tipo de medio audio o vídeo. De esta forma pueden analizarse todos los componentes de medios que pertenecen a una sesión. Por ejemplo, si todos los componentes de audio y de vídeo son unidireccionales y tienen la misma dirección, la aplicación puede considerarse como corriente de datos y por lo tanto los límites de QoS para la corriente de datos pueden aplicarse como la QoS máxima autorizada.

Ahora con referencia a las figuras 4 - 7, se muestran ejemplos de las reglas de mapeo. Por ejemplo, la figura 4 ilustra una sesión de trabajo de ejemplo entre dos equipos de usuario (terminales móviles), cuando los flujos de medios son unidireccionales y tienen la misma dirección, de acuerdo con una realización de la presente invención. La figura 5 ilustra un ejemplo de una sesión de trabajo entre dos equipos de usuario (terminales móviles) cuando los flujos de medios son unidireccionales y no tienen la misma dirección, de acuerdo con una realización de la presente invención. La figura 6 ilustra una sesión de trabajo entre dos equipos de usuario (terminales móviles), cuando un flujo de medios es bidireccional y el otro unidireccional, de acuerdo con una realización de la presente invención. Por último, la figura 7 ilustra una sesión de trabajo de ejemplo entre dos equipos de usuario (terminales móviles), cuando un flujo de medios es bidireccional (diferente de audio / vídeo) y el otro unidireccional (audio / vídeo), de acuerdo con una realización de la presente invención.

Específicamente, en la figura 4, cuando los flujos de medios (audio y vídeo) son unidireccionales y tienen la misma dirección, la autorización del flujo de medios será «STREAMING». En la figura 5, cuando los flujos de medios son unidireccionales y no tienen la misma dirección, la autorización de flujo de medios será «CONVERSATIONAL». En la figura 6, cuando un flujo de medios es bidireccional y el otro unidireccional, la autorización de flujo de medios será «CONVERSATIONAL». En la figura 7, cuando un flujo de medios es bidireccional (diferente de audio / vídeo) y el otro unidireccional (audio / vídeo), la autorización de flujo de medios será «CONVERSATIONAL» para aplicación y «STREAMING» para vídeo.

Las reglas de mapeo pueden extenderse para asegurar la asignación adecuada de la clase máxima autorizada de QoS de acuerdo con el servicio solicitado. Las reglas que definen el mapeo de los parámetros SDP para las clases máximas autorizadas para QoS se extienden, por ejemplo, para permitir el mapeo para la clase streaming en el caso de componentes de medios unidireccionales de tipo «audio» o «vídeo» que tienen la misma dirección. A continuación se muestran ejemplos de las reglas de mapeo que pueden ser utilizadas por el UE 110 (por ejemplo, un terminal móvil o un servidor) y la PDF 222, según se muestra en la figura 2 y en la figura 3. En particular, la tabla 1 ilustra reglas de mapeo de ejemplo para la derivación de las velocidades máximas autorizadas de los datos y de la clase máxima autorizada de servicio (QoS) por componente de medios en la PDF 222. Dichas reglas de mapeo de ejemplo pueden empaquetarse en módulos de software almacenados o suministrados en un medio informáticamente legible o, alternativamente, pueden suministrarse a través de descarga de Internet o integrarse en la PDF 222 según se muestra en la figura 2 y en la figura 3. En correspondencia con la tabla 1, la tabla 2 ilustra reglas de mapeo de ejemplo para la derivación del ancho de banda máximo autorizado y de la clase máxima autorizada de tráfico por componente de medios en el UE 110 (por ejemplo, un terminal móvil o un servidor). Asimismo, dichas reglas de mapeo también pueden empaquetarse en un módulo de software almacenado

o dispuesto en un medio informáticamente legible o, alternativamente, pueden suministrarse a través de descarga de Internet o integrarse dentro del UE 110 (por ejemplo, un terminal móvil o un servidor), según se muestra en la figura 2 y en la figura 3.

TABLA 1: Reglas para la derivación de las Velocidades de Datos Máximas Autorizadas y de la Clase Máxima Autorizada de QoS por componente de medios en la PDF.

Parámetro

5

autorizado de QoS

Derivación a partir de los parámetro SDP

IP por componente

de medios

Velocidad máxima autorizada de los datos del DL (Max_DR_DL) y del UL (Max_DR_DL) por componente de medios (consulte la nota 1)

IF a=recvonly THEN IF <SDP direction> = mobile originated THEN Direction := downlink; ELSE /* móvil finalizado */ Direction := uplink; ENDIF; ELSE IF a=sendonly THEN IF <SDP direction> = mobile originaed THEN Direction := uplink; ELSE /* móvil finalizado */ Direction := downlink;

ENDIF;

ELSE

Direction := both

ENDIF;

ENDIF;

IF b = AS:<bandwith> is present THEN IF Direction = sownlink THEN

IF <transport> = “RTP/AVP” THEN Max_DR_DL := 0.025 * <bandwith>;

Max_DR_UL := 1.025 * <bandwith>;

ELSE

Max_DR_DL := 0;

Max_DR_UL := <bandwith>;

ENDIF;

ELSE

IF Direction = uplink THEN IF <transport> = “RTP/AVP” THEN Max_DR_UL := 1.025 * <bandwith>;

Max_DR_DL := 0.025 * <bandwith>;

ELSE

Max_DR_UL := <bandwith>;

Max_DR_DL := 0; ENDIF;

ELSE /* Dirección = ambas*/ Max_DR_UL := 1.025 * <bandwith>; Max_DR_DL := 1.025 * <bandwith>;

ENDIF, ENDIF;

ELSE BW := as set by the operator; IF Direction = downlink THEN Max_DR_UL := 0; Max_DR_DL := bw; ELSE IF Direction = uplink THEN Max_DR_UL := bw; Max_DR_DL := 0; ELSE /* Dirección = ambas*/ Max_DR_UL := bw; Max_DR_DL := bw;

ENDIF; ENDIF; ENDIF

Clase máxima autorizada de QoS [MaxClass] por componente de medios (Consulte la nota 2, x e y)

IF (all media components of media type “audio” or “video” for the session are unidirectional an have the same direction) THEN MaxClassDerivation := B; /*streaming*/ ELSE MaxClassDerivation := A; /*conversational*/ ENDIF; CASE <media> OF “audio”: MaxClass := MaxClassDerivation; “video”: MaxClass := MaxClassDerivation; “application”: MaxClass := A; “data”: MaxClass := B; /*Interactivo con prioridad 3*/ “control”: MaxClass := E; /*Interactivo con prioridad 1*/ /*Nuevo tipo*/ OTHERWISE: MaxClass := F; /*Entorno*/ END;

NOTA 1: Para un componente de medios RTP las Velocidades Máximas Autorizadas de los Datos del DL/UL son la suma de las Velocidades Máximas Autorizadas de los Datos del DL/UL para los flujos de medios RTP y los flujos asociados IP RTCP del DL/UL. NOTA 2: La Clase Máxima Autorizada de QoS para un flujo IP RTCP es la misma que para el correspondiente flujo de medios RTP. Nota x: Cuando se elimina un flujo de audio o de vídeo de una sesión, los flujos de medios restantes de la sesión mantendrán las clases máximas autorizadas de QoS originalmente asignadas. Nota y: Cuando se añade un flujo de audio o de vídeo a una sesión, la PDF derivará la clase máxima autorizada de QoS teniendo en cuenta los flujos de medios ya existentes dentro de la sesión

La PDF 222 almacenará, por cada sesión en curso, los parámetros Autorizados de QoS IP por componente de medios. Cuando el GGSN 210 solicita los parámetros autorizados de QoS UMTS para un Contexto PDP activado / modificado que lleva uno o más componentes de medios, la PDF 222 puede utilizar las reglas de mapeo, tal como las mostradas, por ejemplo, en la tabla 1 de manera que calcule los parámetros autorizados de la QoS IP.

TABLA 2: Reglas para la derivación del UL/DL de Ancho de Banda Máximo Autorizado y la Clase Máxima Autorizada de Tráfico por componente de medios en el UE.

Parámetro autorizado de QoS UMTS [MaxClass] por componente de medios

Derivación a partir los Parámetros SDP

Ancho de Banda Máximo Autorizado del DL (Max_BW_DL) y del UL (Max_BW_UL) por componente de medios

/*Comprobar si contexto IMS (el criterio para esta comprobación es asunto de los fabricantes del UE*/ IF IMS context THEN IF a = recvonly THEN IF <SDP direction> = mobile originated THEN Direction := downlink; ELSE /* móvil finalizado*/ Direction := upnlink; ENDIF; ELSE; IF a = sendonly THEN IF <SDP direction> = mobile originated THEN Direction := upnlink; ELSE /* móvil finalizado*/ Direction := downlink; ENDIF; ELSE /*sendrecv o sin atributo direction*/ Direction := both; ENDIF; ENDIF; IF b = AS:<bandwith> is present THEN IF Direction = downlink THEN IF <transport> = “RTP/AVP” THEN

Max_BW_UL := 0.025 * <bandwidth>; Max_BW_DL := 1.025 * <bandwidth>;

ELSE Max_BW_UL := 0; Max_BW_DL := <bandwidth>;

ENDIF; ELSE IF Direction = uplink THEN

IF <transport> = “RTP/AVP” THEN Max_BW_UL := 1.025 * <bandwidth>; Max_BW_DL := 0.025 * <bandwidth>;

ELSE Max_BW_UL := <bandwidth>; Max_BW_DL := 0;

ENDIF;

ELSE /*Dirección = ambas*/ Max_BW_UL := 1.025 * <bandwidth>; Max_BW_DL := 1.025 * <bandwidth>;

ENDIF; ENDIF;

ELSE bw := as set by the UE manufacturer; IF Direction = downlink THEN

Max_BW_UL := 0; Max_BW_DL := bw; ELSE

IF Direction = uplink THEN Max_BW_UL := bw; Max_BW_DL := 0;

ELSE /*Dirección = ambas*/ Max_BW_UL := bw; Max_BW_DL := bw;

ENDIF; ENDIF; ENDIF;

ELSE No authorization is done; ENDIF;

Clase Máxima Autorizada de Tráfico [MaxTrafficClass] por componente de medios (consulte NOTA x e y)

/* Comprobar si contexto IMS (el criterio para esta comprobación es asunto de los fabricantes del UE) */ IF IMS context THEN IF (all media components of media type “audio” or “ video” for the session are unidirectional and have the same direction) THEN MaxService := streaming; ELSE MaxService := conversational; ENDIF CASE <media> OF “audio” MaxTrafficClass := MaxService; “video” MaxTrafficClass := MaxService; “application” MaxTrafficClass := conversational; “data” MaxTrafficClass := interactive with priority 3; “control” MaxTrafficClass := interactive with priority 1; /* Tipo de medios nuevo*/ OTHERWISE: MaxTrafficClass := background; END ELSE No authorization is done; ENDIF

NOTA x: Cuando se saca un flujo de audio o de vídeo de una sesión, los flujos de medios restantes mantendrán la clase máxima autorizada de tráfico originalmente asignada. NOTA y: Cuando se añade un flujo de audio o de vídeo a una sesión, el UE derivará la clase máxima autorizada de tráfico tomando en cuenta los flujos de medios ya existentes dentro de la sesión.

El UE 110 almacenará, por cada sesión en curso, los parámetros autorizados de QoS UMTS por componente de medios. Antes de la activación o modificación del contexto PDP, el UE 110 puede comprobar que la velocidad de Bits Garantizada solicitada del UL/DL (si la Clase de Tráfico es Conversational o Streaming) o que la velocidad de bits máxima solicitada del UL/DL (si la Clase de Tráfico es Interactive o Background) no excede del ancho de banda máximo autorizado del UL/DL por contexto PDP (calculado de acuerdo con las reglas de mapeo). Además el UL 110 puede comprobar que la clase de tráfico de los parámetros de QoS UMTS solicitados no exceda la clase de tráfico máxima autorizada por contexto PDP (calculada de acuerdo con las reglas de mapeo).

Tal como se describió anteriormente, la arquitectura de la interfaz de red de acuerdo con una realización de la presente invención suministra soluciones para la autorización dinámica de medios y una mejor gestión de las clases de QoS de una sesión (conexión entre usuarios o terminales móviles, o entre un terminal móvil y un servidor) que comprende una pluralidad de tipos diferentes de flujos de medios dentro de redes móviles de manera que, cuando uno o varios flujos de medios dentro de una pluralidad de tipos diferentes de flujos de medios se modifican (se inician nuevos o se eliminan existentes) durante una sesión, la clase de tráfico de una sesión viene definida por la clase de tráfico más alta requerida por los flujos de medios que pertenecen a la misma sesión, para eliminar la diferencia de los retardos de transmisión de los flujos de medios que pertenecen a la misma sesión y, por lo tanto, mejorar la calidad de la conexión percibida por el usuario final. La sincronización de los flujos de medios en tiempo real también puede mejorarse eliminando la diferencia de los retardos de transmisión de los flujos de medios que pertenecen a la misma sesión, mejorando así la calidad percibida por el usuario final.

Aunque se ha ilustrado y descrito lo que se considera un ejemplo de las realizaciones de la presente invención, aquellos expertos en la materia entenderán que pueden hacerse diferentes cambios y modificaciones y que diferentes elementos pueden sustituirse por sus equivalentes sin apartarse del verdadero alcance de la presente invención. Además, pueden hacerse muchas modificaciones para adaptar una situación particular a las enseñanzas de la presente invención sin apartarse del ámbito central de la presente invención. Por lo tanto, se tiene la intención de que la presente invención no se limite a la realización particular presentada como el mejor modo contemplado para llevar a la práctica la presente invención, sino que la presente invención incluya todas las realizaciones que caen dentro del alcance de las reivindicaciones adjuntas.

Claims (15)

1. Reivindicaciones

   1. Un aparato (222) para gestionar la calidad de servicio de una sesión, estando el aparato

   (222) configurado para determinar, si un flujo de medios que requiere la clase de tráfico más alta dentro de una pluralidad de flujos de medios se quita de la sesión, cuando se modifica la sesión establecida entre dos terminales móviles (110, 120) o un terminal móvil y un servidor, a través de un enlace de comunicación; que se caracteriza porque el aparato (222) está configurado además para mantener la clase de tráfico existente para los restantes flujos de medios para la sesión, si se quita de la sesión el flujo de medios que requiere la clase de tráfico más alta.
2. 2. Un aparato (222) para gestionar la calidad de servicio de una sesión, estando el aparato

   (222) configurado para determinar, si se añade un flujo unidireccional a la sesión que comprende un flujo bidireccional, cuando se establece o se modifica la sesión entre dos terminales móviles (110, 120) o entre un terminal móvil y un servidor, a través de un enlace de comunicación; que se caracteriza porque el aparato (222) está configurado además para asignar la clase de tráfico más alta, asignada a cualquiera de los flujos de medios de la sesión, a todos los flujos de medios de la sesión durante el tiempo de vida de la sesión, si se añade a la sesión el flujo unidireccional que comprende el flujo bidireccional.

3. 3.

   El aparato (222) de acuerdo con la reivindicación 1 ó 2, en el que el aparato (222) está configurado para generar un conjunto de información vinculante para vincular un nivel del subsistema multimedia del protocolo de Internet y un nivel de portador de servicio de radio general por paquetes de una sesión de un subsistema multimedia de protocolo de Internet.

4. 4.

   El aparato (222) de acuerdo con cualquier reivindicación precedente, en el que el terminal móvil (110, 120) comprende al menos uno de entre un equipo terminal y una función de adaptación de terminal configurada para realizar una transmisión de radio y las funciones relacionadas, y que comprende aplicaciones integrales para soportar servicios de telecomunicaciones.

5. 5.

   El aparato (222) de acuerdo con cualquier reivindicación precedente, en el que el aparato (222) está configurado para supervisar la gestión de las clases de calidad de servicio de la sesión.

6. 6.

   El aparato (222) de acuerdo con cualquier reivindicación precedente, en el que aparato

   (222) está configurado para tomar decisiones de política basándose en la sesión y en la información relacionada con los medios.

7. 7.

   El aparato (222) de acuerdo con cualquier reivindicación precedente, en el que el aparato (222) está configurado para intercambiar información de decisión con una puerta (210) de enlace.

8. 8.

   El aparato (222) de acuerdo con la reivindicación 2 o cualquier reivindicación que dependa de la reivindicación 2, en el que el flujo unidireccional comprende un flujo de vídeo unidireccional.

9. 9.

   El aparato (222) de acuerdo con la reivindicación 2 o cualquier reivindicación que dependa de la reivindicación 2, en el que el flujo bidireccional comprende un flujo de audio bidireccional.

10. 10.

    Un procedimiento para gestionar la calidad de servicio de una sesión, que comprende:

    la determinación de, si se quita de la sesión un flujo de medios que requiere la clase de tráfico más alta dentro de una pluralidad de flujos de medios, cuando se modifica la sesión establecida entre dos terminales móviles o entre terminal móvil y un servidor, a través de un enlace de comunicación; que se caracteriza porque el procedimiento comprende:

    el mantenimiento de la clase de tráfico existente para los flujos de medios restantes para la sesión, si se quita de la sesión el flujo de medios que requiere la clase de tráfico más alta.
11. 11. Un procedimiento para gestionar la calidad de servicio de una sesión, que comprende:

    la determinación de, si se añade un flujo unidireccional a la sesión que comprende un flujo bidireccional, cuando la sesión se establece o se modifica entre dos terminales móviles o entre terminal móvil y un servidor, a través de un enlace de comunicación; que se caracteriza porque el procedimiento comprende:

    la aplicación de la clase de clase de tráfico más alta, asignada a cualquiera de las corrientes de medios de la sesión, a todas las corrientes de medios de la sesión durante el tiempo de vida de la sesión, si se añade el flujo unidireccional a la sesión que comprende el flujo bidireccional.
12. 12. El procedimiento de acuerdo con la reivindicación 10 ú 11, que comprende la generación de un conjunto de información vinculante para vincular un nivel de subsistema multimedia de protocolo de Internet y un nivel de portador de servicio de radio general por paquetes de una sesión de un subsistema multimedia de protocolo de Internet.

    5 13. El procedimiento de acuerdo con cualquiera de las reivindicaciones 10 a 12, que comprende la supervisión de la gestión de las clases de calidad de servicio de la sesión.
13. 14. El procedimiento de acuerdo con cualquiera de las reivindicaciones 10 a 13, que comprende la toma de al menos una decisión de política basándose en la sesión y en la información relacionada con los medios.

    10 15. El procedimiento de acuerdo con cualquiera de las reivindicaciones 10 a 14, que comprende el intercambio de la información de decisión con una puerta de enlace.
14. 16. El procedimiento de acuerdo con la reivindicación 11 o cualquier reivindicación que dependa de la reivindicación 11, en el que el flujo unidireccional comprende un flujo de vídeo unidireccional.

    15 17. El procedimiento de acuerdo con la reivindicación 11 o cualquier reivindicación que dependa de la reivindicación 11, en el que flujo bidireccional comprende un flujo de audio bidireccional.
15. 18. Un producto de programa de ordenador que comprende medios de código de programa almacenados en un medio legible por ordenador, los medios de código de programa

    20 están adaptados para realizar cualquiera de las reivindicaciones 10 a 17 cuando el programa se ejecuta en un procesador.