ES2390582T3 - Método y sistema para el servicio de control de velocidad en una red - Google Patents

Método y sistema para el servicio de control de velocidad en una red Download PDF

Info

Publication number
ES2390582T3
ES2390582T3 ES03816585T ES03816585T ES2390582T3 ES 2390582 T3 ES2390582 T3 ES 2390582T3 ES 03816585 T ES03816585 T ES 03816585T ES 03816585 T ES03816585 T ES 03816585T ES 2390582 T3 ES2390582 T3 ES 2390582T3
Authority
ES
Spain
Prior art keywords
rnc
message
radio
speed control
parameters
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES03816585T
Other languages
English (en)
Inventor
Justus Petersson
Magnus Westerlund
Alessio Terzani
Svetlana Chermiakina
Robert Skog
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2390582T3 publication Critical patent/ES2390582T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/263—Rate modification at the source after receiving feedback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0273—Traffic management, e.g. flow control or congestion control adapting protocols for flow control or congestion control to wireless environment, e.g. adapting transmission control protocol [TCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H04W28/22—Negotiating communication rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)
  • Selective Calling Equipment (AREA)
  • Circuits Of Receivers In General (AREA)

Abstract

El método para controlar la velocidad de flujo de transmisión de bits de datos en una sesión de transferencia de bits de datos desde una entidad de servicio (104, Ser de Transmisión en tiempo real) a un cliente (VE, 102), implicando la sesión la transferencia de bits sobre un enlace de comunicaciones inalámbrico, comprendiendo el método: ajustar la sesión proporcionando un nodo de control de radio (RNC – Radio Network Controller, en inglés) para establecer parámetros de velocidad de flujo relativos al enlace inalámbrico, en el que el ajuste incluye: resolver el direccionamiento entre el nodo de control de radio (RNC – Radio Network Controller, en inglés) y la entidad de servicio (104, Ser de Transmisión en tiempo real), enviando parámetros de configuración de control al nodo de control de radio (RNC - Radio Network Controller, en inglés), generando en el nodo de control de radio (RNC - Radio Network Controller, en inglés) un mensaje del control de velocidad (RC) inicial incluyendo parámetros de velocidad iniciales, enviando al menos (226) un mensaje del control de velocidad inicial para permitir que la entidad de servicio (104, Ser de Transmisión en tiempo real) ajuste las velocidades de transmisión iniciales para la sesión de acuerdo con al menos uno de los parámetros de velocidad de flujo iniciales; monitorizar el enlace de comunicación inalámbrico; basándose en la monitorización, enviar (236) nuevos parámetros de velocidad de flujo de manera que la entidad de servicio (104, Ser de Transmisión en tiempo real) pueda actualizar la velocidad de transmisión de la sesión de acuerdo con los nuevos parámetros de control de velocidad.

Description

Método y sistema para el servicio de control de velocidad en una red
CAMPO DE LA INVENCIÓN
La presente invención se refiere a sistemas y métodos de comunicaciones, y más particularmente a controlar la transmisión de bits de datos en una sesión de transferencia de bits.
ANTECEDENTES DE LA INVENCIÓN
Las redes de comunicación para la comunicación de información basada en paquetes en forma de bits de datos son bien conocidas para el experto en la materia. Ciertamente la Internet es la red de comunicación de datos más ampliamente conocida. Una gran variedad de protocolos de comunicación han sido desarrollados para manejar la comunicación de datos. Los protocolos de transporte UDP (User Datagram Protocol, en inglés – Protocolo de Datagrama) y TCP (Transmission Control Protocol, en inglés – Protocolo de Control de Transmisión) se utilizan en la Internet. El UDP es un protocolo sin conexión sin mecanismos de control de flujo, mientras que el TCP es un protocolo orientado a la conexión con mecanismos de control de flujo que proporciona una transferencia de datos fiable entre dos anfitriones.
La creciente importancia de la comunicación mediante telefonía móvil crea la demanda de transferir datos sobre conexiones inalámbricas. La transferencia de datos sobre enlaces inalámbricos puede dar lugar a muchos problemas y dificultades que no se tienen en cuenta cuando se transfieren datos sobre conexiones por cable fijas. El ancho de banda sobre la interfaz aérea es un recurso escaso y limitado. Por lo tanto, resulta de interés hacer un uso eficiente de los recursos de radio. El ancho de banda que está disponible para una conexión de radio en una red de comunicación mediante telefonía móvil puede variar rápidamente debido a cambios en las características de la interfaz aérea provocados, por ejemplo, por inclinaciones de desvanecimiento o sombreado, o debido a la redistribución de un ancho de banda asignado a los usuarios de una celda. El limitado ancho de banda sobre la interfaz aérea y el cambiante ancho de banda pueden hacer difícil proporcionar una calidad de servicio (QoS – Quality of Service, en inglés) aceptable para un usuario final que reside en un sistema de telefonía móvil. El limitado ancho de banda puede, por ejemplo, resultar en largas latencias que el usuario final experimenta como molestas.
Muchas de las soluciones de la técnica anterior se dirigen a resolver el problema de optimización de la QoS para el usuario final en una red de telefonía móvil, principalmente para servicios basados en UDP tales como servicios de Transmisión en tiempo real/Video. Por ejemplo en el documento EP1126716, se presenta una solución que está dirigida a servicios basados en UDP. No obstante, estos métodos no resuelven el problema de la optimización de aplicaciones basadas en protocolos de transporte con mecanismos de control del flujo, tales como el TCP.
En el documento WO 02/052800, se describe un método para ajustar un flujo de datos desde una red externa hasta un terminal de usuario. Un algoritmo de control del flujo de datos ejecutado por una unidad de control de paquetes trabaja con un nodo de red desde el cual la unidad de control de paquetes recibe paquetes de datos. La unidad de control de paquetes indica al nodo de red la velocidad de transmisión real de un flujo de datos especificado y la capacidad de almacenamiento temporal para el flujo de datos. De manera más específica, la velocidad de envío desde un SGSN a un BSC es controlada para evitar la sobrecarga y el desaprovechamiento de memorias temporales en el BSC. La tasa de bits real para controlar las memorias temporales en el BSC y el SGSN utiliza señalización de capa 2 a capa 2.
En el documento WO02/093866 se describe un método para comunicar información de multimedios sobre una red. Los problemas que resuelve se refieren a la velocidad de transmisión disponible del canal de enlace descendente. D2 proporciona un método para estimar la velocidad de transmisión disponible en un canal de enlace descendente calculando una relación del tiempo de ida y vuelta continuo de paquetes enviados al receptor y una ventana de congestión continua asociada con el canal de enlace descendente.
Además, muchas de las soluciones de la técnica anterior están centradas en el cliente, es decir, hacen uso de mensajes de respuesta desde el usuario final en el sistema de telefonía móvil para controlar la calidad de servicio para el usuario final. Un inconveniente con las soluciones centradas en el cliente es que pasa un tiempo bastante largo hasta que el cliente, con certeza, detecta un cambio en el ancho de banda disponible en la conexión sobre la interfaz aérea. Puesto que el entorno de radio es inestable al cliente se le solicita que lleve a cabo un filtrado o cálculos de media sobre periodos de tiempo largos antes de que pueda enviar mensajes de respuesta fiables. Además, los mensajes de respuesta desde el usuario final deben ser transmitidos sobre una conexión de radio al sistema de control que añade un retardo adicional a los datos introducidos al sistema de control.
COMPENDIO DE LA INVENCIÓN
Las realizaciones de la presente invención se refieren a tratar problemas y a “establecer” un servicio de control de velocidad. Específicamente, las realizaciones de la presente invención establecen un mecanismo de control del flujo
2
o de control de velocidad para una sesión de transferencia de bits entre un cliente de un sistema de telefonía móvil y un servidor de aplicación por medio de un transporte. El mecanismo de control de velocidad puede estar asociado con un número de parámetros de control de velocidad. Se describen varias realizaciones que “ajustan” o configuran la dirección para los mecanismos de control de velocidad dentro de una red. Las realizaciones de la invención hacen uso de información de respuesta desde una entidad de gestión de recursos de radio para establecer y actualizar parámetros del control de flujo durante la sesión. Una vez que el mecanismo de control de velocidad está configurado o “ajustado”, una entidad de gestión de recursos de radio puede comunicarse con una entidad de red para optimizar los parámetros del control de velocidad, lo que permite una QoS mejorada y un uso eficiente de los recursos de radio disponibles.
El objeto se logra mediante el asunto principal de las reivindicaciones independientes. Se definen realizaciones ventajosas en las reivindicaciones adjuntas. Además, se proporcionan ejemplos para facilitar la comprensión de la invención.
De acuerdo con un ejemplo, se proporciona un método para establecer el control de la transmisión de bits de datos en una sesión de transferencia de bits para transmitir información de datos desde un servidor de aplicación a un cliente, implicando la sesión de transferencia de bits la transferencia de bits sobre un enlace de comunicaciones inalámbrico por medio de un protocolo de transporte con un mecanismo de control del flujo o de la velocidad. El método incluye el ajuste de una entidad de red de manera que pueda recibir información desde una entidad de gestión de recursos de radio acerca del ancho de banda disponible para el enlace inalámbrico, actualizando entonces la entidad de red al menos un parámetro relativo al mecanismo del control de velocidad del protocolo de transporte en respuesta a la recepción de la información para que la velocidad de transmisión de la sesión pueda ser controlada de acuerdo con la información recibida.
Una ventaja de la presente invención es que “ajusta” servicios de control de velocidad para que las entidades de red puedan equilibrar de manera óptima el tráfico ofrecido sobre la interfaz aérea con el extremo trasero para servicios de persona a contenido y de persona a persona sobre un dominio de paquetes conmutados, lo que conduce a una mejor utilización de los recursos de radio escasos.
Otra ventaja de algunas de las realizaciones de la presente invención es que puesto que la información de respuesta que es utilizada para controlar los parámetros del control de velocidad puede ser proporcionada de manera continua durante la sesión desde la entidad de gestión de recursos de radio que está situada en la red de acceso de radio, los parámetros del control de flujo pueden ser actualizados basándose en la información actual. Esto permite mejores ajustes de parámetros en comparación con las soluciones de la técnica anterior, en las que los parámetros del control de flujo son ajustados sólo una vez al principio de la sesión basándose en datos históricos de sesiones previas. Puesto que la información de respuesta utilizada en la presente invención es comunicada desde la red de acceso por radio a la entidad de red que controla los parámetros del control del flujo la información de respuesta no estará sujeta a tanto retardo como en las soluciones centradas en el cliente explicadas anteriormente. La red de acceso por radio detecta cambios en el ancho de banda disponible de la sesión más rápidamente de lo que lo hace el cliente y no hay necesidad de comunicar la información de respuesta sobre la interfaz aérea.
La continua monitorización y actualización de los parámetros del control del flujo de acuerdo con algunos aspectos de la presente invención permite una buena QoS en toda la sesión y no sólo al principio de la sesión. En las soluciones de la técnica anterior en las que los ajustes de parámetros no son actualizados durante la sesión, existe un riesgo de que la QoS pueda deteriorarse durante la sesión si las condiciones de radio experimentadas por la sesión cambian. Las condiciones de radio pueden cambiar muy rápidamente y, así, es más importante actualizar los ajustes de los parámetros de las sesiones que implican una interfaz aérea que las de las sesiones que están completamente basadas en las conexiones por cable.
Otra ventaja de algunas realizaciones de la presente invención es que hace uso de la respuesta de la red para cada sesión separadamente, la cual se utiliza para actualizar los parámetros del control del flujo de cada sesión individualmente. Así, los ajustes de parámetros pueden ser específicamente adaptados para optimizar la QoS para cada sesión. De acuerdo con algunas soluciones de la técnica anterior el control del flujo es manejado para grupos de sesiones. Aunque las soluciones de la técnica anterior permiten pocas decisiones acerca del control del flujo en comparación con la invención, estas soluciones pueden llevar a una baja calidad de servicio para un cliente particular, el cual está experimentando localmente condiciones de radio que son mucho peores que las de otros clientes del mismo grupo.
Puesto que algunas realizaciones de la presente invención permiten una más rápida y más precisa adaptación del rendimiento para el ancho de banda disponible actual en la interfaz aérea, el riesgo de sobrecarga en la entidad de gestión de recursos de radio, tales como el RNC o el BSC se reduce. Así, una ventaja adicional de la presente invención es que los tamaños de los almacenes temporales en la entidad de gestión de recursos de radio pueden sr minimizados.
3
Otras ventajas y objetos de las realizaciones de la presente invención resultarán evidentes con la lectura de la siguiente descripción detallada junto con los dibujos. Por ejemplo, las realizaciones que pueden ser utilizadas en situaciones de Persona a Contenido (P2C – Person to Content, en inglés) son también igualmente aplicables en servicios de Persona a Persona (P2P – Person to Person, en inglés) y viceversa. Ejemplos que ilustran realizaciones de la presente invención se presentan primero en el contexto de situaciones de P2C, y a continuación se presentan ejemplos en el contexto de escenarios de P2P.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
La Fig. 1 es un diagrama de bloques esquemático que ilustra una sesión de comunicación entre un cliente y un servidor de aplicación de acuerdo con la técnica anterior.
La Fig. 2 es un diagrama de bloques esquemático que ilustra una sesión de comunicación entre un cliente y un servidor de aplicación que emplea aspectos de la presente invención.
La Fig. 3 es un diagrama esquemático que ilustra una comparación del rendimiento de las sesiones ilustradas en la Fig. 1 y la Fig. 2.
La Fig. 4a es un diagrama de bloques esquemático de nivel alto que ilustra un sistema UMTS que emplea aspectos de la presente invención para una comunicación de persona a contenido.
La Fig. 4b ilustra cómo puede el modelo de referencia de Interconexión de Sistema Abierto (OSI – Open System Interconnection, en inglés) ser aplicado al sistema ilustrado en la Fig. 4a.
La Fig. 5 es un diagrama de flujo que ilustra la adaptación de la velocidad de transmisión basándose en la respuesta de red de acuerdo con algunas realizaciones de la presente invención.
La Fig. 6 es un diagrama de señalización que ilustra un procedimiento general “de ajuste” que configura el RNC para enviar indicaciones de Control de Velocidad a un servidor de aplicación durante una sesión específica.
La Fig. 7 es un diagrama de señalización que ilustra un procedimiento de detección de problemas en la red que puede ser utilizado en varios aspectos de la presente invención.
La Fig. 8 es un diagrama de señalización que ilustra un procedimiento de detección de problemas en la red alternativo que puede ser utilizado en varios aspectos de la presente invención.
La Fig. 9 es un diagrama de señalización que ilustra un diagrama de señalización en el que una estación de telefonía móvil (UE) ajusta el RNC con los parámetros requeridos para el servicio de control de velocidad. El RNC puede o no tener una dirección de IP.
La Fig. 10 es un diagrama de señalización que ilustra un procedimiento de ajuste en el que un Proxy ajusta el RNC con los parámetros requeridos para un servicio de control de la velocidad. El RNC no tiene una dirección de IP.
La Fig. 11 es un diagrama de señalización que ilustra un procedimiento de ajuste en el que un Proxy ajusta el RNC con los parámetros requeridos para un servicio de control de velocidad. El RNC tiene una dirección de IP.
La Fig. 12 es un diagrama de bloques esquemático de nivel alto que ilustra un sistema UMTS que emplea aspectos de la presente invención para comunicaciones de persona a persona o, alternativamente, comunicaciones de persona a teléfono fijo.
La Fig. 13 es un diagrama de señalización que ilustra un procedimiento de ajuste en el que las unidades de telefonía móvil ajustan el RNC apropiado con los parámetros requeridos para un servicio de control de velocidad. Los RNCs no tienen una dirección de IP.
La Fig. 14 es un diagrama de señalización que ilustra un procedimiento de ajuste en el que las unidades de telefonía móvil ajustan el RNC apropiado con parámetros requeridos para un servicio de control de la velocidad. El RNC tiene dirección de IP.
La Fig. 15 es un diagrama de señalización que ilustra un procedimiento de ajuste en el que proxies de SIP ajustan el RNC apropiado con los parámetros requeridos para un servicio de control de la velocidad. Los RNC no tienen direcciones de IP.
La Fig. 16 es un diagrama de señalización que ilustra un procedimiento de ajuste en el que los proxies de SIP ajustan el RNC apropiado con parámetros requeridos para un servicio de control de la velocidad. Los RNCs tienen direcciones de IP.
4
La Fig. 17 es un diagrama de señalización que ilustra un procedimiento de ajuste en el que la unidad de telefonía móvil ajusta el RNC apropiado con los parámetros requeridos para un servicio de control de la velocidad. El RNC puede o no tener una dirección de IP.
La Fig. 18 es un diagrama de señalización que ilustra un procedimiento de ajuste en el que una puerta de enlace a 5 medios ajusta el RNC apropiado con los parámetros requeridos para un servicio de control de la velocidad. El RNC no tiene una dirección de IP.
La Fig. 19 es un diagrama de señalización que ilustra un procedimiento de ajuste en el que una puerta de enlace a medios ajusta el RNC apropiado con los parámetros requeridos para un servicio de control de la velocidad. El RNC tiene una dirección de IP.
10 DESCRIPCIÓN DETALLADA
La presente invención se describirá más completamente a continuación en esta memoria con referencia a los dibujos que se acompañan, en los cuales se muestran realizaciones preferidas de la invención. Esta invención puede, no obstante, ser empleada de muy diferentes formas y no debe ser considerada como limitada a las realizaciones explicadas en esta memoria; por el contrario, estas realizaciones son proporcionadas de manera que esta
15 descripción será profunda y completa, y transmitirá completamente el alcance de la invención para los expertos en la materia. En los dibujos, números iguales se refiere a elementos iguales.
Para los propósitos de la presente descripción, se utilizan varios acrónimos, y las definiciones de las cuales se listan a continuación:
3GPP Proyecto de Colaboración de Tercera Generación Third Generation Partnership Project, en inglés
BSC Controlador de Estación de Base Base Station Controller, en inglés
CDMA200 Acceso Múltiple por División de Código. Una tecnología de Code Division Multiple Access, en acceso que combina cada llamada telefónica con un código inglés que sólo un teléfono móvil extraes del aire.
DL Tasas de bits de DL
GGSN Nodo de Soporte de GPRS de Puerta de Enlace. Una puerta Gateway GPRS Support Node, en de enlace inalámbrica en una red de GPRS que permite a inglés los usuarios de teléfonos móviles acceder a la red de datos en paquetes. Proporciona una interfaz hacia las redes de paquetes de IP externas y traduce formatos de datos, protocolos de señalización e información de direcciones para permitir la comunicación entre diferentes redes.
GPRS Servicio de Radio en paquetes General. El servicio de datos General Packet Radio Service, en para redes de GSM. Proporciona un soporte tanto para inglés circuitos conmutados como para paquetes conmutados.
GTP Protocolo de túnel. Un protocolo de túnel de capa 3 utilizado GPRS Tunneling Protocol, en inglés entre el SGSN y el GGSN.
GTP-U Un túnel de usuario de GTP. Para cada estación de telefonía User-GTP, en inglés móvil, se establece un túnel de GTP-C para señalización y se establecen varios túneles de GTP-U, uno por cada contexto de PDP (es decir, sesión) para tráfico de usuario.
HTTP Protocolo de Transporte de Hipertexto Hypertext Transport Protocol, en inglés
IMSI Identidad de Abonado de Telefonía Móvil Internacional. International Mobile Subscriber Campo de 50 bits que identifica un país y portador local del Identity, en inglés abonado de telefonía móvil en una red de GSM y que está almacenado en el Módulo de Identidad de Abonado (SIM – Subscriber Identity Module, en inglés)
IP Protocolo de Internet Internet Protocol, en inglés
5
Iu UP Plano de Usuario, es decir, la interfaz entre el RNC y la Red User Plane, en inglés de Núcleo
Capa 2 (Nodo SGSN) Proporciona un medio para sincronizar el flujo de bits a y desde la capa física y para la detección de errores debidos a problemas de transmisión (por ejemplo, ruido e interferencias).
MSISDN ISDN de Estación de Telefonía Móvil. El número de teléfono Mobile Station ISDN, en inglés de una estación de telefonía móvil.
NAT Traducción de Dirección de Red Network Address Translation, en inglés
OSI Interconexión de Sistema Abierto Open System Interconnection, en inglés
P2C Persona a Contenido Person-to-Content, en inglés
P2P Persona a Persona Person-to-Person, en inglés
PDP Protocolo de Datos en paquetes. Término del GPRS para Packet Data Protocol, en inglés una gama de protocolos (por ejemplo, IP y PPP) que soportan la transferencia de datos en paquetes sobre una red de telefonía móvil inalámbrica de 3G.
PDP Un contexto de PDP es una asociación lógica entre una MS
context (Estación de Telefonía Móvil – Mobile Station, en inglés) y la PDN (Red da Datos Pública – Public Data Network, en inglés) que corren a través de una red de GPRS. El contexto de PDP es un conjunto de información (por ejemplo, un perfil de QoS) guardado en el teléfono móvil y los GSNs para una dirección de PDP. El contexto define aspectos tales como encaminamiento, calidad de servicio, seguridad, tarificación, etc.
QoE Calidad Experimentada por el Usuario Final Quality of End User Experience, en inglés
QoS Calidad de Servicio Quality of Service, en inglés
RAB Soporte de Acceso por Radio Radio Access Bearer, en inglés
RADIUS Un protocolo de AAA (autenticación, autorización y registro de operaciones de un usuario)
RAN Red de Acceso por Radio Radio Access Network, en inglés
RANAP Parte de Aplicación de Red de Acceso por Radio – un Radio Access Network Application protocolo de capa intermedia utilizado por el RNC y la CN. Part, en inglés
RC Control de Velocidad Rate Control, en inglés
RC ID Identificador de Controlador de Velocidad Rate Controller Identifier, en inglés
RNC Controlador de Red de Radio Radio Network controller, en inglés
RRC Control de Recurso de Radio. El RRC se utiliza para Radio Resource Control, en inglés configuración, reconfiguración, reasignación y liberación de entidades de PDCP individuales relativas a diferentes soportes de radio.
6
RTSP Protocolo de Transmisión en tiempo Real. Un protocolo a Real Time Streaming Protocol, en nivel de aplicación para el control sobre la transmisión de inglés datos con propiedades de tiempo real. El RTSP proporciona un marco extensible para permitir una transmisión controlada, bajo demanda, de datos en tiempo real, tal como audio y video, utilizando el Protocolo de Control de Transmisión (TCP – Transmission Control Protocol, en inglés) o el Protocolo de Datos de Usuario (UDP – User Data Protocol, en inglés).
SDP Protocolo de Descripción de Sesión Session Description Protocol, en inglés
SGSN Nodo de Soporte de GPRS de Servicio. Nodo de GPRS que Serving GPRS Support Node, en maneja datos a y desde la MS, guarda la información de inglés ubicación de la MS y se comunica entre la MS y el GGSN. Proporciona encaminamiento de paquetes para todos los abonados de GPRS situados en un área específica.
SIP Protocolo de Iniciación de Sesión. Un protocolo de IP de Session Initiation Protocol, en inglés IETF para el procesamiento de llamada de VoIP (voz en paquetes). Lleva a cabo el ajuste y la señalización de sesión para una variedad de características.
SM Gestión de Sesión Session Management, en inglés
TCP Protocolo de Control de Transmisión Transmission Control Protocol, en inglés
TEID Identificador de Final de Túnel Tunnel Endpoint Identifier, en inglés
TFT Plantilla de Flujo de Tráfico. Permitiendo al GGSN clasificar Traffic Flow Template, en inglés paquetes recibidos desde la red externa en el contexto de PDP adecuado. Utilizada para determinar la QoS que aplica a un paquete específico.
T-PDU PDU (Unidad de Datos de Protocolo, Protocol Data Unit, en Transport PDU, en inglés inglés) de Transporte
UDP Protocolo de Datos de Usuario User Data Protocol, en inglés
UE Equipo de Usuario User Equipment, en inglés
UMTS Sistema de Telecomunicaciones de Telefonía Móvil Universal Mobile Telecommunications Universal. Estándar inalámbrico de tercera generación para System, en inglés soportar velocidades de transferencia de datos de 144 kbs (en vehículos), 384 kbs (en peatones) o hasta 2 Mbits en edificios.
WCDMA Acceso Múltiple por División de Código de Banda ancha. Es Wideband Code Division Multiple una de las principales tecnologías para la implementación de Access, en inglés sistemas celulares de tercera generación (3G). Se basa en una técnica de acceso por radio propuesta por el grupo Alpha de ETSI y las especificaciones fueron terminadas en 1999.
WLAN Red de Área Local Inalámbrica Wireless Local Area Network, en inglés
La presente invención es aplicable a servicios de paquetes conmutados de persona a contenido (P2C) y de persona a persona (P2P), y particularmente a servicios tales que se basan en un protocolo de transporte con un mecanismo de control de flujo. Tales servicios comprenden comunicación de paquetes entre un equipo de usuario de un usuario final y de un servidor de aplicación. El sistema de telefonía móvil incluye una red de telefonía móvil tal como una red de WCDMA, de CDMA2000, de LAN Inalámbrica o de GPRS en la cual reside el equipo de usuario. Un ejemplo de un protocolo de transporte con un mecanismo de control de flujo es el TCP. El mecanismo de control de flujo del TCP comprende varios parámetros de control del flujo como es bien conocido para un experto en la materia. Ejemplos de parámetros de control del flujo de TCP son tamaño de ventana y tamaño de segmento. La transmisión
7
de bits de datos sobre una conexión de TCP puede ser controlada por medio de un cambio en los parámetros del control del flujo de TCP.
Cuando se establece una sesión de comunicación entre el equipo de usuario de telefonía móvil y el servidor de aplicación, el ancho de banda disponible sobre la interfaz aérea será normalmente un factor limitativo de la tasa de bits de la sesión. Las características de la interfaz aérea, por ejemplo, inclinaciones de desvanecimiento y de sombreado, pueden tener consecuencias negativas para el usuario final. Esto es especialmente cierto para aplicaciones que utilizan el protocolo TCP como soporte de transporte. Por ejemplo, una latencia grande sobre la interfaz aérea puede activar el mecanismo para evitar la congestión de TCP, lo que conduce a menos ancho de banda para la sesión y que resulta en un rendimiento muy malo para el usuario final. Por otro lado, si el usuario final ve aumentado temporalmente su ancho de banda sobre la interfaz aérea, esto puede muy probablemente no acelerar la conexión de TCP en la misma medida, lo que implica que recursos de radio escasos no serán utilizados. Dado que los recursos de radio en la interfaz aérea son recursos escasos que resulta de interés utilizar lo más eficientemente posible, un uso más eficiente de los recursos de radio disponibles muy probablemente mejorará la calidad de servicio de los usuarios finales.
La Fig. 1 ilustra esquemáticamente una sesión de comunicación entre un cliente en el equipo de usuario 102 y un servidor de aplicación 104 de acuerdo con la técnica anterior. Aquí el servidor de aplicación 104 es un Servidor de Red. La sesión es establecida por medio de un enlace de TCP 106 entre el cliente 102 y el servidor de aplicación
104. Cuando el cliente está visualizando o descargando información desde el servidor de aplicación 104, el cliente reconoce la recepción de datos, indicando con ello la calidad de la recepción. El servidor de aplicación 104 utiliza esta información de los reconocimientos para adaptar los parámetros de transmisión de TCP, tales como por ejemplo tamaño de ventana o tamaño de segmento, a las condiciones de transmisión sobre el enlace de TCP.
Un problema con el planteamiento en la Fig. 1 es que cuando el enlace de transmisión incluye una conexión de radio existe un riesgo de malas condiciones de conexión, incluyendo que muchas retransmisiones son malinterpretadas pro el servidor de aplicación 104 como congestión, activando por ello el mecanismo para evitar una congestión de TCP. También, las condiciones de radio pueden cambiar muy rápidamente, pero la respuesta en forma de reconocimientos llega relativamente tarde, lo que reduce también la capacidad de que el servidor reaccione adecuadamente a las nuevas condiciones de transmisión de radio. Estos son inconvenientes que ocurren puesto que el mecanismo de transmisión de TCP no fue diseñado para una transmisión por radio.
La Fig. 2 es un diagrama de bloques esquemático que ilustra los principios básicos de una sesión de comunicación en la que se utiliza un aspecto de la presente invención. Una sesión de comunicación es establecida entre el cliente 102 y el servidor de aplicación 104 a través de un proxy 112 por medio de las conexiones de TCP 106a y 106b. La conexión de TCP 106b implica la transmisión sobre un enlace de radio en una red de telefonía móvil 114. La red de telefonía móvil reporta datos de respuesta de red relativos a la calidad de servicio de la transmisión mediante enlace de radio al proxy. El proxy utiliza los datos de respuesta de red para cambiar ajustes de parámetros de TCP, tales como el tamaño de la ventana de TCP y el tamaño del segmento, de la conexión de TCP 106b. La respuesta de red puede ser también utilizada para decidir cómo reconocer la recepción al servidor de aplicación sobre la conexión de TCP 106a.
Los datos de respuesta de red que son reportados al proxy son información acerca del ancho de banda que la entidad de gestión del recurso de radio de la red de telefonía móvil ha decidido que la sesión puede utilizar sobre la interfaz aérea.
La Fig. 3 es un diagrama esquemático que ilustra una comparación de la velocidad de rendimiento utilizando disposiciones de acuerdo con la Fig. 1 y la Fig. 2 respectivamente. La curva rectangular 120 ilustra el ancho de banda que la entidad de gestión del recurso de radio de la red de telefonía móvil ha decidido que la sesión puede utilizar sobre la interfaz aérea. La curva 116 ilustra la curva de rendimiento de la disposición de la técnica anterior de la Fig. 1 y la curva en negrita 118 ilustra la curva de rendimiento de la disposición de acuerdo con la invención en la Fig. 2.
La curva 116 ilustra que la velocidad de transmisión aumenta primero exponencialmente, hasta que se ha alcanzado la máxima tasa de bits disponible sobre la interfaz aérea. Cuando esto ocurre, el cliente empieza a reportar “No recibido”, lo que es interpretado por el servidor de aplicación 104 en la Fig. 1 como congestión. Así, el servidor de aplicación aplica el mecanismo para evitar una congestión por lo que la velocidad de transmisión se reduce sustancialmente. A continuación, el servidor de aplicación empieza a aumentar muy lentamente la velocidad de transmisión de manera lineal. Este comportamiento del servidor de aplicación puede no estar en conformidad con la situación real sobre el enlace de radio.
En contraste, en la Fig. 2, el proxy 112 (o el servidor 104 en una realización en la que la respuesta de red es directamente proporcionada al servidor) puede tomar medidas más adecuadas y más rápidamente puesto que recibe anteriormente información del enlace de radio – lo que proporciona una descripción más precisa de las condiciones de la transmisión de radio. Esto se ilustra mediante la curva en negrita 118, que ilustra que el
8
rendimiento aumenta más rápidamente cuando se utiliza la respuesta de red de acuerdo con la presente invención y que el rendimiento global es mayor, lo que conduce a una mejor calidad de servicio para el usuario final. Un aumento en el ancho de banda disponible sobre la interfaz aérea resultará rápidamente en un mayor rendimiento cuando se utiliza la disposición de la Fig. 2.
Aunque la Fig. 2 ilustra la utilización de la invención para una sesión que es establecida a través de un proxy y de dos conexiones de TCP 106a y 106b, la utilización de un proxy no es esencial para la invención. Si la sesión es establecida directamente entre el servidor de aplicación y el cliente, sin un proxy intermedio, la invención puede ser implementada se tal manera que la respuesta de la red es proporcionada directamente al servidor de aplicación El servidor de aplicación puede entonces utilizar la respuesta de la red para adaptar los parámetros de TCP de la sesión. Además de las situaciones de Persona a Contenido (P2C – Person-to-Content, en inglés) descritas anteriormente, aspectos de la invención son también igualmente aplicables en servicios de Persona a Persona (P2P
- Person-to-Person, en inglés).
Servicios de Persona a Contenido:
La Fig. 4a ilustra una realización de la presente invención en un sistema UMTS 120 en un escenario de Persona a Contenido (P2C – Person-to-Content, en inglés). El sistema incluye una red de acceso por radio 122 que comprende un número de Estaciones de Base de Radio (RBS – Radio Base Station, en inglés) 124 y al menos un Controlador de Red de Radio (RNC – Radio Network Controller, en inglés) 126. El sistema incluye también un Nodo de Soporte de GPRS de Servicio (SGSN – Serving GPRS Support Node, en inglés) 128 y un Nodo de Soporte de GPRS de Puerta de Enlace (GGSN – Gateway GPRS Support Node, en inglés) 130, que son nodos de una Red de Núcleo (CN – Core Network, en inglés) 132 que proporciona una conexión entre la red de acceso por radio 122 y una Red de Servicio (SN – Service Network, en inglés) 134. La Red de Servicio 134 incluye el servidor de aplicación 104 y el proxy 112. El proxy puede estar en comunicación con una Base de Datos de Sesión de Red de Servicio (SNSD – Service Network Session Database, en inglés) 136 y una red de IP 138 externa.
Como se ha explicado anteriormente, la presente invención proporciona medios mejorados para controlar la velocidad de transmisión de la sesión, que permite la optimización de la calidad de servicio del usuario final. Información acerca del ancho de banda permitido sobre la interfaz aérea utilizada para la sesión puede ser enviada desde el RNC 126 al proxy 112. Por ejemplo, si el proxy 112 tiene acceso a la tasa de bits permitida sobre la interfaz aérea, el proxy tiene la capacidad de ajustar los parámetros de control del flujo de TCP tales como por ejemplo los tamaños de segmento/ventana para adaptarse de manera óptima a la situación del recurso de radio. Así, el Proxy 112 puede tener las capacidades de optimizar la calidad de servicio del usuario final sobre la base de la información del ancho de banda obtenida del RNC 126 y de sus propios algoritmos internos.
En un aspecto de la realización, el RNC 126 puede ser preconfigurado para gestionar el servicio de RC. El RNC 126 puede ser codificado de manera fija o configurado con datos que son necesarios para el servicio mediante una herramienta 140 de configuración. Adicionalmente, el RNC 126 puede ser parcialmente configurado con la ayuda del equipo de usuario (UE – User Equipment, en inglés), o el servidor de aplicación, o el Proxy del servidor de aplicación, o la Puerta de Enlace a Medios. Típicamente, el receptor de las indicaciones de Control de Velocidad es el Proxy 112.
Ejemplos de tal configuración son:
La dirección de IP y el Número de Puerto de Receptor (del Proxy).
La clase de tráfico para la cual el servicio de RC será aplicable (por ejemplo, Transmisión en tiempo real e Interactiva). Qué usuarios tendrán el servicio. (Esta lista puede estar basada en servicios de suscripción).
Además, una unidad de ajuste de parámetros, que actualiza los parámetros de sesión basándose en la respuesta de la red, puede ser adaptada para ser capaz de recibir e interpretar la respuesta de la red y para ser capaz de adaptar los parámetros basándose en la respuesta de la red recibida. Resultará evidente para el experto en la materia cómo puede ser implementada la presente invención utilizando medios de hardware y de software conocidos. El mecanismo de respuesta de la red de acuerdo con la presente invención puede ser implementado utilizando un protocolo de transporte separado creado para este propósito.
En un escenario de transmisión en tiempo real el servicio de Control de Velocidad puede ser establecido para cada flujo de medios en la descripción de SDP (por ejemplo, un ajuste del servicio de RC para el flujo de conversación y un ajuste del servicio de RC para el flujo de video), todos los flujos de medios en la descripción de SDP como conjunto, o una combinación de los mismos.
En varias realizaciones, el SNSD 136 puede ser conectado al Proxy 112 y comunica la información del ancho de banda del RNC 126 al Proxy 112. En algunas realizaciones, el SNSD 136 puede estar dispuesto para almacenar la información del ancho de banda del RNC 126. Cuando el UE 102 ha activado un contexto de protocolo de datos en paquetes (PDP – Packet Data Protocol, en inglés), este contexto de PDP incluye entre otra información un nombre
9
de punto de acceso (APN – Access Point Name, en inglés). El APN proporciona una conexión lógica entre el UE 102 y el Proxy 110. El Proxy 112 ó la SNSD 136 pueden, por ejemplo, almacenar la siguiente información acerca del UE
102:
dirección de IP del UE
tasa de bits
otra información, por ejemplo, la MSISDN del usuario, que pueda ser de interés para otros propósitos distintos de la presente invención.
En referencia de nuevo a las Figs. 2 y 4, una sesión de transferencia de bits puede ser establecida entre el servidor de aplicación 104 en la red del servicio 134 y un cliente en un Equipo de Usuario (UE – User Equipment, en inglés) 102 por medio de las conexiones 106a, 106b que pasan por el proxy 112, la CN 132 y la red de acceso por radio
122. Alternativamente la sesión puede ser establecida entre el UE 102 y un servidor de aplicación 104 en una red externa 138 con la cual se comunica el proxy. Las conexiones 106a, 106b pueden, por ejemplo, ser conexiones de TCP o conexiones basadas en otro tipo de protocolo de transporte con algún tipo de mecanismo de control del flujo.
Como es bien conocido en el sector, el modelo de referencia de la Interconexión de Sistema Abierto (OSI – Open System Interconnection, en inglés) divide la comunicación entre dispositivos de red en siete “capas” más pequeñas. Cada capa tiene un conjunto predeterminado de funciones que son llevadas a cabo para que la comunicación ocurra. La Fig. 4b ilustra el modelo de referencia de OSI estableciendo un enlace de comunicación desde un nodo, por ejemplo el UE 102 a través de nodos intermedios (tales como el RNC 126, el SGSN 128 y el GGSN 130) hasta el servidor de aplicación 104.
Una capa de aplicación 141 identifica y establece la disponibilidad de interlocutores de comunicación de objetivo, sincroniza aplicaciones que cooperan y establece un acuerdo en procedimientos para recuperación del error y el control de la integridad de datos. Una capa de presentación 142 está “debajo” de la capa de aplicación 141 y asegura que esa información enviada por la capa de aplicación de un sistema sea legible por la capa de aplicación de otro sistema. Una capa de sesión 143 se encuentra por debajo de la capa de presentación 142 y establece, gestiona y termina sesiones entre aplicaciones. Las sesiones consisten en diálogo entre dos o más entidades de presentación.
Bajo la capa de sesión 143 se encuentra una Capa de transporte 144. La capa de transporte 144 proporciona mecanismos para el establecimiento, mantenimiento y terminación ordenada de circuitos virtuales y control de flujo de información. Una capa de de red 145 está debajo de la capa de transporte. La capa de red 145 es una capa que proporciona conectividad y selección de ruta entre dos extremos de sistema que pueden estar situados en sub-redes geográficamente diferentes. Una capa de enlace 146 proporciona el tránsito de datos a través de un enlace físico. Haciendo esto, la capa de enlace 146 se ocupa del direccionamiento físico (en contraposición con el de red o lógico), la topología de la red, la disciplina de la línea (cómo utilizarán el enlace de red los extremos del sistema), la notificación de error, la entrega ordenada de tramas y el control del flujo. Bajo la capa de enlace 146, se encuentra una capa física 147 que define las especificaciones eléctricas, mecánicas, de procedimiento y funcionales para la activación, mantenimiento y desactivación del enlace físico entre sistemas de extremo.
La frontera entre la capa de sesión 143 y la capa de transporte 144 están generalmente considerados como la frontera entre protocolos de capa de aplicación y protocolos de capa inferior. Mientras que las capas de aplicación, presentación y sesión se ocupan de los problemas de la aplicación, las cuatro capas inferiores se ocupan típicamente de los problemas de transporte.
En algunas realizaciones, puede existir un flujo o transferencia de “datos de aplicación” 148, por ejemplo, tráfico de la red o de transmisión en tiempo real entre el UE 201 y el servidor de aplicación 112. Esto puede considerarse como una transferencia de datos de “Nivel Alto”. Como se describirá con más detalle a continuación, el RNC 126 puede detectar nuevas condiciones del sistema sobre el enlace UE-RNC, lo que ocurre en la capa física 147. El RNC 126 puede actualizar el proxy 112 acerca de cambios de estado sobre el enlace UE-RNC (por ejemplo, enlace inalámbrico). La información de cambio de estado puede entonces ser utilizada por el servidor de aplicación 104 para equilibrar el flujo de datos que se origina en él hacia el UE 102 para adaptarse a la capacidad disponible sobre el enlace UE-RNC.
(La información de estado desde el RNC al proxy 112 puede ser transparente, es decir, invisible, para el SGSN 128 y el GGSN 130). No obstante, para que este proceso funcione, el RNC necesita conocer la dirección del servidor de aplicación 112, para que el RNC pueda enviar la información de estado al servidor de aplicación 104.
La Fig. 5 ilustra un procedimiento de flujo de llamada general 150 utilizando adaptación de TCP en el que el enlace de TCP entre el UE y el servidor de aplicación ha sido dividido en dos partes: (1) entre el servidor de aplicación 104 y el proxy 112, y (2) entre el proxy 112 y el UE 102.
10
Las condiciones iniciales para el ejemplo ilustrado en la Fig. 5 son éstas: El servidor de aplicación envía carga útil a una cierta tasa de bits de acuerdo con el protocolo de red, tal como mecanismos de TCP. Debido a limitaciones con la interfaz aérea, el proxy 112 no está autorizado para transmitir la carga útil entrante a la misma velocidad que llega. Por lo tanto, el proxy 112 temporalmente almacena las cargas útiles entrantes en una memoria caché (no mostrada) y reconoce el Servidor de Aplicación enviando reconocimientos (ACKs- Acknowledgements, en inglés) como si las cargas útiles hubiesen sido recibidas por el cliente. Mediante esto se disminuye el riesgo de que pueda emplearse el mecanismo de control de congestión de TCP. Al mismo tiempo se minimiza el tiempo total de descarga para el objeto/fichero requerido. Cuando las condiciones con la interfaz aérea cambian, el RNC puede notificar al proxy, quien a continuación notifica al servidor de aplicación que puede emplearse una nueva velocidad de transferencia.
De acuerdo con la presente invención se llevan a cabo las siguientes etapas ilustrativas en el ejemplo de la Fig. 5:
Etapa 151: El servidor de aplicación está transmitiendo datos a una velocidad predeterminada al proxy.
Etapa 152: el proxy no puede transmitir los datos al UE 102 a la misma velocidad debido a limitaciones con la interfaz aérea, así que el proxy almacena temporalmente los datos.
Etapa 153: El proxy envía mensajes de reconocimiento al servidor de aplicación para evitar la activación de un mecanismo de control de congestión.
Etapa 154: Las condiciones de la interfaz aérea mejoran. La entidad de gestión del recurso de radio, por ejemplo, el RNC 126, ha descubierto que el sistema ahora tiene una capacidad de reserva e informa así al proxy 112 (o a la base de datos en comunicación con el proxy) de que una sesión específica puede disfrutar de una nueva y mayor tasa de bits por medio de un mensaje de respuesta del control de velocidad. Así, la entidad de gestión del recurso de radio envía un mensaje de capa inferior al proxy en forma de un Mensaje de Respuesta del Control de Velocidad.
Etapa 156: Los algoritmos de optimización inalámbricos internos del proxy se adaptan a la nueva situación determinando una velocidad óptima. Por ejemplo, en un sistema de TCP, el proxy determina un tamaño óptimo de segmento de TCP.
Etapa 158: El proxy 112 puede a continuación enviar al servidor de aplicación un mensaje de capa de aplicación especificando una nueva tasa de bits (o tamaño de segmento).
Etapa 160: El servidor de aplicación reconoce el mensaje enviando un reconocimiento de capa de aplicación y empieza el envío a una nueva velocidad, etapa 162.
Debe observarse que el procedimiento 150 es una “instantánea” del comportamiento para la adaptación de velocidad basada en la respuesta de la red de acuerdo con un aspecto de la presente invención. Durante toda una sesión el procedimiento 150 puede ser empleado muchas veces a medida que la tasa de bits permitida de la sesión sobre la interfaz aérea varía.
Cuando se implementa la presente invención en los sistemas de comunicación existentes, el software y/o el hardware existente pueden tener que ser modificados, como resultará evidente para un experto en la materia. En la mayoría de los casos las modificaciones serán principalmente modificaciones de software. Por ejemplo, el RNC 126 puede ser adaptado de manera que pueda comunicar la respuesta de la red de acuerdo con la presente invención a otra unidad, tal como el proxy 112 ó el servidor de aplicación 104. En la realización ilustrada en la Fig. 4a, el RNC 126 puede ser informado acerca de la dirección de IP del proxy 112 sobre i) configuración o ii) ajuste de sesión. Mediante esto, el RNC 126 puede enviar información acerca de la tasa de bits válida directamente al proxy 112 sin ninguna interrogación desde un nodo intermedio.
La Fig. 6 es un diagrama del flujo de llamada que ilustra un procedimiento 170 que es similar al procedimiento 150 descrito con referencia a la Fig. 5. No obstante, el procedimiento 170 ilustra cómo se resuelve el problema cuando el RNC es configurado para enviar indicadores de control de velocidad para una sesión específica. El procedimiento 170 configura el RNC para enviar indicadores de ancho de banda (es decir, control de velocidad) al proxy por medio del GGSN para una clase de tráfico específica. El servidor de aplicación 104 envía datos a una cierta tasa de bits de acuerdo con los mecanismos del protocolo de la red. En algún punto durante la transmisión, el RNC 126 determina que es posible una nueva tasa de bits y envía un mensaje de IP hacia el Proxy 112. No obstante, puesto que el Proxy 112 no sabe a qué sesión (es decir, a qué UE) se aplica el mensaje de Control de Velocidad, el procedimiento necesita resolver la dirección de IP y el número de Puerto del UE.
La resolución puede ser completada por medio de un Identificador de Punto Final de Túnel de GTP-U en un mensaje de T-PDU y de un mapeo de filtro de TFT. El GGSN puede emplear procedimientos para determinar la dirección de IP del UE (o alternativamente asociar la MSISDN o el IMSI al mensaje). En el último caso, la MSISDN/IMSI será resuelta y mapeada a la dirección de IP de un UE por la base de datos de la sesión de Red de Servicio, que tiene una interfaz al Proxy (no mostrada en la Fig. 6).
11
Las siguientes etapas pueden ser llevadas a cabo en el procedimiento 170 ilustrado en la Fig. 6:
Etapa 172: El servidor de aplicación 104 envía datos a una cierta tasa de bits de acuerdo con los mecanismos del protocolo de red.
Etapa 174: El RNC 126 envía un mensaje de respuesta de control de velocidad de capa intermedia hacia el Proxy (por ejemplo, el RNC pone en túnel un mensaje del Control de Velocidad al GGSN 130 sobre la capa de GTP-U.
Etapa 176: El GGSN 130 intercepta el mensaje y determina la dirección de IP y el número de puerto del UE 102 utilizando el Identificador de Punto Final de Túnel (TEID – Tunnel Endpoint Identifier, en inglés) de GTP-U en un mensaje de T-PDU y el mapeo del filtro de TFT tal como se ha explicado en el documento TS 24.008 del 3GPP.
Etapa 178: El GGSN 130 transmite la indicación del Control de Velocidad al Proxy por medio de un mensaje del nivel de la capa de red (por ejemplo, un mensaje de RADIUS/HTTP). Este mensaje incluye la dirección de IP y el número de Puerto del UE. Así, el mensaje del Control de Velocidad contiene el ancho de banda que se acaba de empezar a utilizar sobre la interfaz aérea y la dirección de IP y el número de Puerto de la fuente (del UE). Incluyendo la dirección de IP y el número de Puerto del UE, el Proxy puede identificar la sesión de aplicación específica para la cual es aplicable el mensaje.
Etapa 179: El Proxy determina una tasa de bits óptima basándose en la información en el mensaje de control de velocidad.
Etapa 180: El Proxy 112 puede entonces enviar al servidor de aplicación un mensaje de capa de aplicación, que especifica una nueva tasa de bits. En este ejemplo, el mensaje de la capa de aplicación es un mensaje de RTSP.
Etapa 182: El servidor de aplicación reconoce el mensaje de RTSP y empieza a enviar a una nueva velocidad, etapa 184.
En el procedimiento 170 explicado anteriormente, el RNC proporciona la dirección de IP y el número de puerto del UE en el mensaje de respuesta del control de conexión 174. Por lo tanto, el RNC determina primero la dirección de IP del UE (o alternativamente asocia el número de la MSISDN o de la IMSI al mensaje. En el último caso, la MSISDN/IMSI será resuelta y mapeada a la dirección de IP del UE por la base de datos de la sesión de la red de servicio). Dos métodos de determinar la dirección de IP del UE se explican en relación con las Fig. 7 y 8.
La Fig. 7 ilustra un procedimiento de “búsqueda” 190 en el ajuste del contexto de PDP de manera que el RNC pueda iniciar servicios de Control de Velocidad. “Búsqueda” tal como se utiliza en esta explicación significa que el RNC escucha al tráfico de datos del usuario desde el UE e intercepta mensajes que son marcados apropiadamente. Por ejemplo puede haber un campo de identificación del control de velocidad (RC ID – Rate Control IDentification, en inglés) en el protocolo de Iu UP o en el número de puerto de destino en la cabecera de IP que alerta al RNC de que tales mensajes pueden estar sujetos a un servicio de control de velocidad. Cuando el usuario final activa un contexto de PDP, el GGSN envía un Mensaje de Registro de Operaciones de Usuario de Radius al Proxy. El Mensaje de Registro de Operaciones de Usuario de RADIUS incluye una dirección de IP del UE, una MSISDN y opcionalmente el número de IMSI. En respuesta, el Proxy envía un mensaje de inicialización del control de velocidad hacia la dirección de IP del UE y un número de Puerto de RC específico sobre la capa de GTP-U. (Los datos en el mensaje de Iniz. de RC contienen, entre otras cosas: Las direcciones de IP y los números de puertos del UE y del Proxy). El RNC busca (por ejemplo examina) mensajes dirigidos hacia este número de Puerto de RC específico. Una vez que el RNC ha buscado en tal mensaje, asocia la dirección de IP con el correspondiente identificador de RAB utilizando el Identificador de Túnel de GTP. El RNC puede entonces enviar un mensaje de respuesta del control de velocidad sobre un canal que contiene los cambios de velocidad hacia la dirección de IP y el número de puerto que detectó en la activación del contexto de PDP.
Las siguientes etapas pueden ser llevadas a cabo en el procedimiento 190 ilustrado en la Fig. 7:
Etapa 192: El usuario final activa un contexto de PDP, que es enviado al GGSN.
Etapa 194: En respuesta, el GGSN envía un Mensaje de Registro de Operaciones de Usuario de Radius al Proxy. El Mensaje de Registro de Operaciones de Usuario de Radius incluye la dirección de IP del UE, la MSISDN y opcionalmente el número de IMSI.
Etapa 196: El Proxy envía un mensaje de Iniz. de Control de Velocidad hacia la dirección de IP del UE y un número de Puerto de RC específico en el nivel de GTP-U. (Los datos en el mensaje de Iniz. de RC contienen, entre otras cosas: las direcciones de IP y los números de puerto del UE y del Proxy. El RNC busca (por ejemplo examina) en mensajes dirigidos hacia este número de puerto de RC específico. Una vez que el RNC ha buscado en tal mensaje, asocia la dirección de IP con el correspondiente RAB-Id utilizando el Identificador de Túnel de GTP.
12
Etapa 198: El RNC envía un mensaje de respuesta del Control de Velocidad sobre el canal conteniendo cambios de velocidad hacia la dirección de IP y el número de puerto.
La Fig. 8 ilustra otro procedimiento de “búsqueda” 200 en el cual el RNC determina la dirección de IP del UE de una manera más flexible que en el procedimiento 190 (Fig. 7). En este escenario, el tráfico no va a través de un proxy específico. Inicialmente el UE envía una solicitud de http al proxy para iniciar una solicitud de transferencia. Una respuesta de TCP es devuelta hacia el UE. La respuesta de TCP puede ser realizada en uno o en varios paquetes de TCP. (La respuesta podría también ser transportada en un mensaje de UDP en el caso de “transmisión en tiempo real sobre UDP”). El RNC (o alternativamente, el BSC) busca en los paquetes y determina las direcciones de IP y los números de Puerto de la fuente y del destino de los paquetes. El RNC puede entonces devolver un mensaje de Respuesta del Control de Velocidad a la dirección de IP y al número de Puerto de la fuente, que fueron previamente descubiertos. La dirección de IP y el número de Puerto del UE pueden entonces servir como identidad y pueden por lo tanto ser incluidos en el mensaje.
Las siguientes etapas pueden ser llevadas a cabo en el procedimiento 200 ilustrado en la Fig. 8:
Etapa 202: El UE envía una solicitud de http al proxy.
Etapa 204: Se devuelve una respuesta de TCP.
Etapa 206: El RNC “busca” en los paquetes basándose en unos criterios predeterminados y determina las direcciones de IP y los números de Puerto de la fuente y del destino.
Etapa 208: El RNC puede ahora devolver un mensaje de Respuesta del Control de Velocidad a la dirección de IP y al número de Puerto del proxy de envío / servidor de aplicación.
La Fig. 9 ilustra un ejemplo en el que el UE configura el RNC con los parámetros necesarios para el servicio de control de velocidad en un establecimiento de contexto de PDP. En este ejemplo, el proxy añade los parámetros de control de velocidad específicos al protocolo RTSP/SDP. El RNS puede o no tener una dirección de IP de su propiedad. En este ejemplo se utilizará un Proxy y un Servidor de Aplicación para ilustrar los principios del procedimiento subyacente.
En el procedimiento 210 de la Fig. 9, se ha añadido una identidad (ID) específica para implementar el servicio de Control de Velocidad RC (es decir, el ID del RC). En este ejemplo, la dirección de IP del RC y el número de Puerto del RC corresponden a la dirección de IP y el número de Puerto del Proxy. Debe observarse que en presencia de NATs (Traductores de Dirección de Red – Network Address Translators, en inglés) se utiliza una identidad especial para el servicio de Control de Velocidad porque la dirección de IP y el número de Puerto del UE son específicos del operador (es decir, son conocidos sólo localmente) y no pueden ser utilizados por el Servidor como identificador del servicio de Control de Velocidad. En realizaciones alternativas, como en el caso del tráfico basado en TCP, los parámetros de ajuste pueden ser incluidos en la cabecera de HTTP por el Proxy o por el Servidor. Otra alternativa, que puede adaptarse mejor para el tráfico de TCP general, es preconfigurar el UE con la dirección de IP y el número de Puerto del RC.
De acuerdo con este ejemplo ilustrado en la Fig. 9, pueden llevarse a cabo las siguientes etapas:
Etapa 211: El UE envía un mensaje de describir de RTSP al proxy para iniciar el proceso de transmisión de datos. El proxy, a su vez, envía el mensaje al servidor de Aplicación.
Etapa 212: El servidor de Aplicación responde devolviendo un mensaje de OK de RTSP/SDP al UE a través del Proxy.
Etapa 213: El UE envía entonces un mensaje de Establecer de RTSP al servidor de aplicación a través del proxy.
Etapa 214: En respuesta, el servidor de aplicación devuelve un mensaje de OK de RTSP al UE. El mensaje de OK de RTSP contiene el ID del RC, la dirección de IP del RC, el número de puerto del RC y un indicador de que el control de velocidad está habilitado (debe observarse que la dirección de IP del RC y el número de puerto del RC corresponden a la dirección de IP y al número de puerto del proxy, respectivamente).
Etapa 216: El UE envía una solicitud de mensaje de gestión de sesión al SGSN para activar un contexto de PDP secundario. Este mensaje de SM contiene el método de control de Velocidad, el ID del RC, las direcciones de IP del RC y los números de puerto del RC.
Etapa 218: En respuesta, el SGSN envía un mensaje de RANAP de capa intermedia al RNC. En este ejemplo, el mensaje es un mensaje de solicitud de asignación de RAB que contiene el método de control de Velocidad, el ID del RC, las direcciones de IP del RC y los números de puerto del RC.
13
Etapa 220: El RNC envía un reconocimiento en forma de una Respuesta de Asignación de RAB de RANAP indicando que el método de control de velocidad se ha aceptado.
Etapa 222: El SGSN envía a continuación una solicitud de Crear contexto de PDP de GTP-C de capa 3 al SGSN para solicitar el contexto de PDP.
Etapa 224: En respuesta, el GGSN devuelve un mensaje de respuesta a Crear Contexto de PDP de GTP-C al SGSN.
Etapa 226: El RNC envía a continuación un mensaje de GTP sobre IP al proxy. El mensaje contiene el ID del RC y la tasa de bits inicial.
Etapa 227: En respuesta a la etapa 216, el SGSN envía al UE un mensaje de aceptación de SM de la solicitud de Activar Contexto de PDP Secundario.
Etapa 228: El Proxy puede entonces enviar al servidor de aplicación un mensaje de RTSP al nivel de la aplicación, que especifica la tasa de bits inicial para la transmisión de datos.
Etapa 229: El servidor de aplicación reconoce el mensaje de RTSP y establece la tasa de bits.
Etapa 230: El UE envía al servidor de aplicación una solicitud de empezar la transmisión en tiempo real (a través del proxy).
Etapa 232: El servidor de aplicación responde enviando el flujo a la velocidad determinada previamente (determinada en la etapa 226 citada anteriormente).
Etapa 234: En algún punto durante la transmisión, el RNC determina que es posible una nueva tasa de bits y envía un mensaje de GTP sobre IP de capa 3 (Respuesta del Control de Velocidad) al Proxy.
Etapa 236: El Proxy envía a continuación al servidor de aplicación un mensaje de RTSP al nivel de la aplicación, que especifica una nueva tasa de bits.
Etapa 238: El servidor de aplicación reconoce el mensaje de RTSP y empieza a enviar a una nueva velocidad, etapa 240.
Como en el ejemplo previo explicado en referencia a la Fig. 9, la Fig. 10 ilustra un procedimiento 250 en el que el proxy configura el RNC con los parámetros requeridos para el servicio de control de velocidad mediante el establecimiento de un contexto de PDP. En este ejemplo, se utilizarán un Proxy y un Servidor de Aplicación para ilustrar el procedimiento subyacente.
Las condiciones iniciales para el ejemplo ilustrado en la Fig. 10 son éstas: El RNC no está asociado con una dirección de IP y el UE no conoce el servicio de RC. Además, el RNC y el Proxy puede ser preconfigurados por medio de la herramienta de configuración 140 con el número de puerto del RC. Este número de puerto del RC no es utilizado por el Proxy como puerto de fuente para los mensajes del RC. El RNC utiliza el número de puerto del RC para “buscar” o señalar mensajes de RC, es decir, los mensajes que tienen el número de puerto igual al número de puerto del RC.
Después de que la solicitud ha sido iniciada (lo cual en este ejemplo tiene lugar en el nivel de aplicación con el protocolo RTSP), el UE establece los filtros de paquetes de TFT de contexto de PDP secundario de tal manera que incluye sólo el flujo de datos del usuario (porque el UE no sabe del servicio de RC [véase el documento TS 23.060]).
Para inicializar el RNC, el proxy envía un mensaje de inicialización cuya cabecera de IP/UDP contiene la dirección de IP del UE y el número de puerto del usuario como dirección y puerto de destino. El puesto de fuente es el número de puerto del RC (preconfigurado) y la dirección de IP de fuente es la dirección de IP del Proxy. Así, el mensaje de inicialización contiene los siguientes parámetros:
dirección de IP del RC (dirección de IP del Proxy)
número de puerto del RC (Puerto al cual el Proxy escuchará para mensajes de RC)
ID de RC.
En respuesta, el GGSN mapea el mensaje de inicialización entrante al contexto de PDP llevando el flujo de datos de usuario (es decir el contexto de PDP que lleva los datos que deben ser controlados) porque la dirección de IP y el número de puerto de destino del mensaje de RC iguala los valores en los datos de usuario.
Como se ha descrito anteriormente, el RNC “busca” en todo el tráfico entrante de ese usuario particular e intercepta los paquetes que tienen el puerto de RC listado como el puerto de fuente (es decir, los mensajes de control de
14
velocidad). El RNC es capaz de asociar el mensaje del RC con el correcto Soporte de Acceso de Radio (RAB – Radio Access Bearer, en inglés) porque el mensaje del RC ha llegado de ese particular RAB.
En el enlace ascendente, el RNC envía el mensaje de Respuesta del RC a la dirección de IP del RC y al número de puerto del RC (es decir, al Proxy). Este mensaje contiene la velocidad de bit inicial y el ID del RC. El Proxy utiliza el ID del RC para asociar el mensaje del control de velocidad a la sesión de RTSP.
De acuerdo con el procedimiento 250 ilustrado en la Fig. 10, se llevarán a cabo las siguientes etapas:
Etapa 252: El UE envía un mensaje de describir de RTSP al servidor de aplicación al proxy para empezar el proceso de transmisión en tiempo real. El proxy envía el mensaje al servidor de Aplicación.
Etapa 254: El servidor de Aplicación responde devolviendo un mensaje de OK de RTSP/SDP al UE a través del proxy.
Etapa 255: El UE envía un mensaje de Ajustar de RTSP al servidor de aplicación a través del proxy.
Etapa 256: En respuesta el servidor de aplicación devuelve un mensaje de OK de RTSP al UE. El proxy añade el ID del RC, la dirección de IP de RC, los números de puerto del RC y un indicador de que el control de velocidad está habilitado para el mensaje de OK de RTSP. La dirección de IP de RC y el número de puerto de RC corresponde a la dirección de IP y al número de puerto de IP del proxy.
Etapa 258: El UE envía una solicitud de mensaje de SM al SGSN para activar un contexto de PDP secundario. Este mensaje de SM contiene el método de control de Velocidad, el ID del RC, las direcciones de IP del RC y los números de puerto del RC.
Etapa 260: En respuesta, el SGSN envía un mensaje de RANAP al RNC. En este ejemplo el mensaje es un mensaje de solicitud de asignación de RAB que contiene el método de control de Velocidad, el ID de RC, las direcciones de IP del RC y los números de puerto del RC.
Etapa 262: El RNC envía un reconocimiento en forma de una Respuesta de Asignación de RAB de RANAP indicando que el método de control de velocidad es aceptado.
Etapa 264: El SGSN envía a continuación una solicitud de Crear contexto de PDP de GTP-C al SGSN.
Etapa 266: En respuesta, el GGSN devuelve un mensaje de respuesta de Crear Contexto de PDP de GTP-C al SGSN.
Etapa 268: En respuesta a la etapa 258, el SGSN envía al UE un mensaje de aceptación de SM para una solicitud de Activar Contexto de PDP Secundario.
Etapa 270: En respuesta, el UE envía un mensaje de reproducir de RTSP al servidor de aplicación a través del proxy. El mensaje de reproducir incluye la tasa de bits inicial.
Etapa 272: En respuesta, el servidor de aplicación envía al UE una solicitud de control de velocidad a través del proxy. Este mensaje es interceptado por el RNC. La solicitud de control de velocidad es transmitida al nivel de GTP-U (o al nivel de Iu UP) y contiene la velocidad, la dirección de IP del RC, el número de puerto del RC y el ID del RC). (Iu UP es un protocolo que especifica la transmisión entre el RNC y la CN (a través de su SGSN). El GTP-U típicamente es colocado en una capa en la parte superior del Iu UP.)
Etapa 274: En respuesta, el RNC devuelve un mensaje de respuesta de control de velocidad al servidor de aplicación a través del proxy para establecer una tasa de bits inicial. El mensaje de respuesta del control de velocidad incluye el ID del RC y la tasa de bits inicial. En este ejemplo, el servidor de aplicación recibe este mensaje como un mensaje de RTSP.
Etapa 276: El servidor de aplicación envía los datos a la tasa de bits inicial.
Etapa 278: En algún punto durante la transmisión, el RNC determina que es posible una nueva tasa de bits y envía un mensaje de GTP-U (Respuesta del Control de Velocidad) al proxy.
Etapa 280: El proxy envía a continuación al servidor de aplicación un mensaje de RTSP/RTCP de nivel de aplicación, que especifica una nueva tasa de bits.
Etapa 282: El servidor de aplicación reconoce el mensaje de RTSP y empieza a enviar a una nueva velocidad, etapa 284.
15
La Fig. 11 ilustra otro procedimiento 290 en el cual el proxy ajusta el RNC con parámetros para el servicio de control de la velocidad. En oposición al ejemplo explicado en referencia a la Fig. 10, en el ejemplo ilustrado en la Fig. 11, el RNC tiene una dirección de IP.
Las condiciones iniciales para el procedimiento 290 son éstas: El proxy puede obtener la dirección de IP del RNC/BSC del UE mediante la solicitud inicial en la fase de establecimiento de la Sesión de RTSP/HTTP. A continuación, el UE es actualizado de manera continua en lo que respecta a la Dirección de IP/Número de Puerto del RNC/BSC, para el cual ha establecido un contexto de PDP. Adicionalmente, en el caso de una transferencia inter-RNC/BSC, los procedimientos de gestión de movilidad aseguran que el “nuevo” RNC/BSC se actualiza de manera que el servicio de RC continúa sin ninguna interrupción. Tras el inicial intercambio de señalización y finalización del procedimiento de establecimiento del contexto de PDP, el Proxy señala protocolos de RC específicos (ID de RC, RTSP del RC (del proxy), número de puerto del RC, RTSP del UE y número de puerto de destino de datos del UE) al RNC. El RNC asocia el ID del RC con la RAB para la sesión para saber dónde enviar los mensajes del RC. Para lograr este procedimiento, el RNC “busca” para cada RAB el flujo de datos de usuario extrayendo por ello la RTSP del UE y el número de puerto de destino de datos del UE. Esta información puede ser utilizada para asociar el ID del RC con la RAB adecuada.
Así, de acuerdo con este ejemplo ilustrado en la Fig. 11, pueden llevarse a cabo las siguientes etapas:
Etapa 292: El UE envía un mensaje de describir de RTSP para iniciar la solicitud de transmisión. El proxy envía el mensaje al servidor de aplicación.
Etapa 294: El servidor de aplicación responde devolviendo un mensaje de OK de RTSP/SDP al UE a través del proxy.
Etapa 296: El UE envía a continuación un mensaje de Establecer RTSP al servidor de aplicación a través del proxy.
Etapa 298: En respuesta, el servidor de aplicación devuelve un mensaje de OK de RTSP al UE, donde el mensaje de RTSP OK contiene el ID del RC, la dirección de IP del RC, los números de puerto del RC y un indicador de que el control de velocidad está habilitado. Estos números son del servidor de aplicación o del proxy.
Etapa 300: Se establece un contexto de PDP.
Etapa 302: El UE envía un mensaje de ejecutar RTSP al servidor de aplicación a través del proxy.
Etapa 304: En respuesta, el proxy envía al RNC una solicitud de control de velocidad. La solicitud de control de velocidad es transmitida en el GTP sobre la capa de IP e incluye el método de control de velocidad, la dirección de IP del RC, el número de puerto del RC y el ID del RC).
Etapa 306: El RNC devuelve un mensaje de respuesta de control de velocidad al proxy sobre el GTP sobre la capa de IP. El mensaje de respuesta de control de velocidad incluye el método de control de velocidad, el ID del RC y la tasa de bits inicial.
Etapa 307: El proxy envía a continuación al servidor de aplicación un mensaje de RTSP, que especifica la tasa de bits inicial.
Etapa 308: El servidor de aplicación reconoce el mensaje de RTSP.
Etapa 309: El servidor de aplicación envía los datos a la tasa de bits inicial a través de un mensaje de RTSP.
Etapa 310: En algún punto durante la transmisión, el RNC determina que una nueva tasa de bits es posible y envía un GTP sobre un mensaje de IP (Respuesta de Control de Velocidad) al Proxy.
Etapa 312: El Proxy envía a continuación al servidor de aplicación un mensaje de RTSP, que especifica una nueva tasa de bits.
Etapa 314: El servidor de aplicación reconoce el mensaje de RTSP y empieza a enviar a una nueva velocidad, etapa 316.
Servicios de Persona a Persona:
La Fig. 12 ilustra un ejemplo de una adaptación de tasa de bits de persona a persona (P2P – Person-to-Person, en inglés) en un sistema UMTS de acuerdo con un aspecto de la presente invención. El sistema UMTS mostrado en la Fig. 12 comprende dos redes de núcleo, CN 350a y CN 350b. La red de núcleo CN 350a comprende un Nodo de Soporte de GPRS de Puerta de Enlace (GGSN – Gateway GPRS Support Node, en inglés) 352a conectado a un Nodo de Soporte de GPRS de Servicio (SGSN – Serving GPRS Support Node, en inglés) 354a. El GGSN 352a
16
puede estar conectado a una pluralidad de SGSNs. El GGSN 352a es una puerta de enlace hacia las redes externas tales como las PSTNs u otras redes de telefonía móvil y el SGSN 354a está conectado al menos a una Entidad de Control de Radio (RCE – Radio Controlling Entity, en inglés) (no mostrada en la Fig. 12). Cada RCE comprende un Controlador de Red de Radio (RNC – Radio Network Controller, en inglés) 356a y al menos una estación de base (no mostrada en la Fig. 12) conectada a un RNC respectivo 356a en la red de UMTS. Cada estación de base proporciona comunicación inalámbrica con un terminal de telefonía móvil UE 358a.
De manera similar, la CN 350b tiene componentes similares a la CN 350a). Así, la red de núcleo CN 350b comprende un Nodo de Soporte de GPRS de Puerta de Enlace (GGSN – Gateway GPRS Support Node, en inglés) 352b conectado al Nodo de Soporte de GPRS de Servicio (SGSN – Serving GPRS Support Node, en inglés) 354b. El GGSN 352b puede estar conectado a una pluralidad de SGSNs. El SGSN 354b está conectado al menos a una Entidad de Control de Radio (RCE – Radio Controlling Entity, en inglés) (no mostrada en la Fig. 12). Cada RCE comprende un Controlador de Red de Radio (RNC – Radio Network Controller, en inglés) 356b y al menos una estación de base (no mostrada en la Fig. 12) conectada al RNC en la red de UMTS. Cada estación de base proporciona comunicación inalámbrica con un terminal de telefonía móvil UE 358b.
En este ejemplo, al menos una de las RCEs comprende un medio de control de velocidad para controlar la tasa de bits de su enlace de radio Uu. El medio de control de velocidad es preferiblemente una parte de un sistema de Gestión de Recurso de Radio (RRM – Radio Resource Management, en inglés). En una realización, el medio de control de velocidad incluye un medio de negociación. El medio de negociación está dispuesto para llevar a cabo una negociación de las tasas de bits de capa de enlace entre dos medios de control de velocidad.
Así, para llevar a cabo una negociación, los mensajes del control de velocidad pueden ser también enviados entre dos UEs o entre dos RNCs a través de un nodo intermedio o proxy 360 en una red de servicio 366. De manera similar, los mensajes del control de velocidad puede ser enviados a un nodo “equivalente” en una red fija, tal como una Puerta de Enlace a Medios 362, que puede estar en comunicación con un teléfono fijo 364.
Cuando una tasa de bits de capa de aplicación de enlace ascendente y/o de enlace descendente sobre un enlace de radio 366a requiere una modificación debida a condiciones nuevas en el citado enlace de radio, un primer medio de control de velocidad del enlace de radio transmite información de modificación a un segundo medio de control de velocidad de un segundo enlace de radio 366b. Una modificación de tasa de bits de capa de aplicación propuesta es entonces negociada entre los medios de control de velocidad segundo y primero por el medio de negociación. El medio de negociación puede estar dispuesto para comunicar el resultado de la negociación al menos a uno de los medios de control de velocidad. A continuación, a los respectivos terminales de telefonía móvil UE 358a, UE 358b se les solicita desde el respectivo medio de control de velocidad que adapten sus tasas de bits de capa de aplicación de transmisión, y/o sus tasas de bits de capa de aplicación de recepción, de manera correspondiente. El medio de control de velocidad respectivo transmite un mensaje de radio a sus terminales conectados utilizando un protocolo de comunicación de radio, por ejemplo, el protocolo de Control de Recurso de Radio (RRC – Radio Resource Control, en inglés) para solicitar que los terminales de telefonía móvil se adapten a la nueva tasa de bits de la capa de aplicación. Así, el mensaje de radio es mapeado a la capa de aplicación con el fin de llevar a cabo el cambio negociado de la tasa de bits de la capa de aplicación.
El medio de control de velocidad puede residir en un número de entidades. Por ejemplo, el primer medio de control de velocidad puede residir en la primera RCE, mientras que el segundo medio de control de velocidad puede residir en la misma RCE. Alternativamente, cada RCE podría tener su propio medio de control de velocidad, o el medio de control de velocidad podría estar en otra red, tal como una red fija. Si los medios de control primero y segundo están situados dentro de la misma RCE, la comunicación y la negociación entre los medios de control de velocidad son rápidas y sencillas. Si los medios de control de velocidad primero y segundo se comunican a través de nodos y/o puertas de enlace intermedios, tales como nodos de soporte de GPRS, entonces el RNC envía mensajes de control de velocidad a otros nodos dentro del sistema.
Por ejemplo, de acuerdo con un aspecto de la presente invención, el primer RNC 356a podría utilizar una dirección de IP de un segundo terminal de telefonía móvil UE 358b para enviar un mensaje de control de velocidad al segundo RNC 356b. Esta dirección de IP puede ser utilizada por nodos intermedios, por ejemplo el GGSN 352a para encaminar el mensaje hacia el segundo RNC 356b, que interpretará y actuará sobre él.
No obstante, el RNC no conoce inicialmente la dirección de IP del segundo terminal de telefonía móvil. De este modo, el RNC puede estar configurado o “ajustado” para enviar mensajes del RC a otro RNC, al proxy o a otro nodo tal como la puerta de enlace a medios 362. La siguiente explicación proporciona ejemplos que ilustran procedimientos de ajuste para un RNC en varias situaciones.
La Fig. 13 ilustra un ejemplo en el que el UE configura al RNC con los parámetros necesarios para el servicio de control de velocidad. En este ejemplo, los RNCs no tienen direcciones de IP de su propiedad. El UE 358a empieza enviando un mensaje de INVITAR de SIP al UE 358b. Este mensaje contiene un fichero de SDP, que describe las características del UE 358a. Por ejemplo, el fichero incluye parámetros del RC (ID, dirección de IP y número de
17
Puerto) y un atributo que indica que el UE 358A soporta el servicio de RC. Este atributo puede ser utilizado por el UE 358B para indicar al RNC-B que el UE 358A está conectado a la RAN que soporta el servicio del control de velocidad. El UE 358B responde con un mensaje que contiene su descripción de sesión con la misma información.
Una vez que el UE 358A y el UE 358B conocen uno de otro sus características de sesión inician el procedimiento de activación del contexto de PDP. El mensaje de solicitud de de contexto de PDP del UE 358A contiene los parámetros del RC del UE 358B. Esta información es enviada al RNC 356A por el SGSN 354A por medio del mensaje de Solicitud de Asignación del RAB de RANAP. El UE define o “ajusta” los filtros de paquetes de TFT del contexto de PDP secundario de tal manera que incluye mensajes del RC (por ejemplo, los mensajes del RC entrantes serán mapeados sobre este contexto de PDP secundario). El TFT es utilizado por el GGSN para mapear los paquetes entrantes sobre el contexto de PDP correcto. El TFT consiste en uno o varios filtros de paquete, que contienen cada uno, entre otra información: dirección de fuente, intervalo de puertos de destino y un intervalo de puertos de fuente. El TFT es creado por el UE y proporcionado al GGSN en el mensaje de “Activar Solicitud de Contexto de PDP”.
Durante la señalización inicial, por ejemplo, de SIP, el UE recoge la información acerca del flujo de datos de sesión tal como direcciones de IP y números de puerto, y en particular entre otros parámetros del RC. Permite que el UE defina el TFT que será utilizado por el GGSN para mapear los datos entrantes y los paquetes de control de velocidad sobre este contexto de PDP particular. De este modo los mensajes del RC entrantes pueden ser mapeados sobre el contexto de PDP que lleva datos para controlar y el RNC será capaz de interceptar el mensaje y asociarlo con la RAB para ser controlado.
Cuando el RNC 356A recibe el mensaje de RANAP, que contiene los parámetros del RC, entiende que las tasas de bits de transferencia disponible deben ser comunicadas a una entidad remota. El RNC 356A utiliza la dirección de IP del RC (dirección de IP del UE 358B) para encaminar el mensaje de Inicialización del GTP-U o Iu UP hacia el UE 358B. El mensaje contiene las tasas de bits del DL disponibles sobre la interfaz A. El RNC-B utiliza una técnica de “búsqueda” para interceptar el mensaje dado que todo el tráfico hacia el UE 338B pasará a través del RNC-B. Como se ha explicado previamente, “buscar” significa que el RNC-B escucha al tráfico de datos del usuario desde el UE 358A al UE 358B e intercepta mensajes que están marcados, por ejemplo, un campo de ID del RC en el protocolo de GTP-U o un número de puerto de destino en la cabecera de IP, para facilitar el servicio de RC. Tales técnicas de búsqueda se han explicado anteriormente en referencia a las Figs. 7 y 8. El RNC-B es capaz de asociar el mensaje de RC con el RAB correcto debido a que el mensaje de RC ha llegado desde ese RAB particular.
Así, de acuerdo con estos ejemplos ilustrados en la Fig. 13, el siguiente procedimiento 370 puede ser llevado a cabo:
Etapa 372: El UE 358A envía un mensaje de invitar de SIP para iniciar un proceso de transferencia de datos entre el UE 358A y el UE 358B. El mensaje contiene un fichero de SDP, que incluye la velocidad, el ID de RC, la dirección de IP de RC y los números de puerto de RC.
Etapa 374: El UE 358B responde con un mensaje de OK de SIP. El mensaje de reconocimiento también contiene un fichero de SDP, que incluye la velocidad, el ID de RC, la dirección de IP de RC y los números de puerto de RC para el UE 358B.
Etapa 376: El UE 358A envía una Solicitud de Activar Contexto de PDP Secundario de SM a la CN 350A. De manera similar, el UE 358B envía una Solicitud de Activar contexto de PDP Secundario de SM a la CN-B.
Etapa 378: La CN 350A envía un mensaje de Solicitud de Asignación de RAB de RANAP al RNC 356A que contiene la Velocidad, el ID del RC, la dirección de IP del RC y el número de puerto del RC del UE 358B. De manera similar, la CN 350B envía un mensaje de Solicitud de Asignación de RAB de RANAP al RNC 356B que contiene la Velocidad, el ID del RC, la dirección de IP del RC y el ejemplo de puerto del RC al UE 358A.
Etapa 380: El RNC 356A envía un mensaje de Respuesta a Asignación de RAB de RANAP a la CN 350A. De manera similar, el RNC 356B envía un mensaje de Respuesta a Asignación de RAB de RANAP a la CN 350B,
Etapa 382: La CN 350A reconoce la solicitud de Activar Contexto de PDP Secundario de SM enviando un mensaje de Aceptación de Activar Contexto de PDP Secundario de SM al RNC 356A. De manera similar, la CN 350B reconoce la solicitud de Activar contexto de PDP Secundario de SM enviando un mensaje de Aceptación de Activación de contexto de PDP Secundario al RNC 356B.
Etapa 384: El RNC 356A envía un mensaje de Inicialización de Iu UP hacia el UE 358B. El mensaje de inicialización incluye las tasas de transferencia de bits disponibles para el UE 358A. El RNC 356A utiliza la dirección de IP del RC (dirección de IP del UE 358B) para encaminar hacia el UE 358B.
18
Etapa 386: El RNC 356B intercepta el mensaje de Inicialización de GTP-U y devuelve un mensaje de Inicialización de GTP-U hacia el UE 358A, que es interceptado por el RNC 356A. El mensaje de Inicialización incluye las tasas de transferencia de bits disponibles para el UE 358A.
Etapa 388: El RNC 356A determina la velocidad de transferencia de bits óptima comparando la velocidad de transferencia de bits por UE 358B con la velocidad de transferencia de bits para el UE 358B. De manera similar, el RNC 356B determina la velocidad de transferencia de bits óptima comparando la velocidad de transferencia de bits para el UE 358B con la velocidad de transferencia de bits para el UE 358A.
Etapa 390: El RNC 356A envía un mensaje de RRC al UE 358A especificando una tasa de bits inicial. De manera similar, el RNC 356B envía un mensaje de RRC al UE 358B especificando una tasa de bits inicial.
Etapa 392: El UE 358B envía un mensaje de reconocimiento de SIP al UE 358B, y la transferencia de datos tiene lugar a la velocidad negociada, Etapa 394.
La Fig. 14 ilustra un ejemplo en el que uno de los UEs configura el RNC apropiado con los parámetros necesarios para el servicio de control de velocidad. En este ejemplo, los RNCs tienen sus propios dirección de IP/números de puerto. Además, los UEs son actualizados de manera continua con respecto a la dirección de IP/número de puerto del RNC/BSC, para los cuales establecen un contexto de PDP.
El procedimiento 410 de la Fig. 14 es similar al procedimiento 370 de la Fig. 13, en que el ID del RC es utilizado para asociar la sesión de la aplicación con la RAB. En este ejemplo, no obstante, la dirección de IP del RC y el número de Puerto del RC corresponden a la dirección de IP y al número de Puerto del RNC respectivo.
Los RNCs son “ajustados” con el ID del RC, la dirección de IP y el número de Puerto de los RNCs correspondientes. A continuación, el RNC 356A puede indicar al RNC 356b que tiene recursos de radio de falta o de reserva enviando un mensaje de Control de Velocidad (RC – Rate Control, en inglés) al RNC 356B o viceversa. El mensaje contiene el ID del RC y un valor de tasa de bits. El RNC 356B asocia el mensaje de RC con una RAB adecuada basándose en el ID del RC.
El mismo mecanismo puede ser también utilizado en la dirección contraria (es decir, del RNC 356b al RNC 356a).
Si el UE 358A se traslada a otro RNC de control, los procedimientos de gestión de movilidad actualizan cualquier RNC nuevo y correspondiente con los datos necesarios (por ejemplo, direcciones de IP/Números de Puerto del RNC nuevos/actualizados para continuar el servicio de Control de Velocidad sin ninguna interrupción.
Así, de acuerdo con este ejemplo ilustrado en la Fig. 14, puede llevarse a cabo el siguiente procedimiento 410:
Etapa 412: El UE 358A envía un mensaje de invitar de SIP para iniciar la transferencia de datos. El mensaje contiene un fichero de SDP, que incluye la velocidad, el ID de RC, la dirección de IP del RNC 356A y el número de puerto del RNC 356A.
Etapa 414: El UE 358B responde con un mensaje de OK de SIP. Este diagrama también contiene un fichero de SDP, que incluye la velocidad, el ID del RC, la dirección de IP del RNC 356B y el número de puerto del 356B.
Etapa 416: El UE 356A envía una solicitud de Activar contexto de PDP Secundario de SM a la CN 350A. La solicitud contiene la velocidad. El ID del RC, la dirección de IP del RNC 356B y el número de puerto del RNC 356B. De manera similar, el UE 358B envía una Solicitud de Activar contexto de PDP Secundario de SM a la CN 350B conteniendo la velocidad, el ID del RC, la dirección de IP del RNC 356A y el número de puerto del RNC 356A.
Etapa 418: La CN 350A envía un mensaje de Solicitud de Asignación de RAB de RANAP al RNC 356A conteniendo la Velocidad, el ID del RC, la dirección de IP del RNC 356B y el número de puerto del RNC 356B. De manera similar, la CN 350B envía un mensaje de Solicitud de Asignación de RAB de RANAP al RNC 356B conteniendo la Velocidad, el ID del RC, la dirección de IP del RNC 356A y el número de puerto del RNC 356A.
Etapa 420: El RNC 356A envía un mensaje de Respuesta a Asignación de RAB de RANAP a la CN 350B.
Etapa 422: La CN 350A reconoce la solicitud de Activación de contexto de PDP Secundario enviando un mensaje de Activar Aceptación de contexto de PDP Secundario de SM a la CN 350A. La CN 350A reconoce el mensaje de solicitud de Activación de contexto de PDP Secundario de SM enviando un mensaje de Aceptación de Activación de Contexto de PDP Secundario de SM a la CN 350A.
Etapa 424: El RNC 356A envía un mensaje de Inicialización de GTP-U al RNC 356B incluyendo las tasas disponibles para el UE 358A.
19
Etapa 426: En respuesta, el RNC 356B envía un mensaje de Inicialización de GTP-U al RNC 356A, incluyendo el mensaje de Inicialización las velocidades de transferencia de bits disponibles para el UE 358A.
Etapa 428: El RNC 356A determina la velocidad de transferencia de bits óptima comparando la velocidad de transferencia de bits para el UE 358B con la velocidad de transferencia de bits para el UE 358B. De manera similar, el RNC 356B determina la velocidad de transferencia de bits óptima comparando la velocidad de transferencia de bits para el UE 358B con la velocidad de transferencia de bits para el UE 358A.
Etapa 430: El RNC 356A envía un mensaje de RRC al UE 358A especificando una tasa de bits inicial. De manera similar, el RNC 356B envía un mensaje de RRC al UE 358B especificando una tasa de bits inicial.
Etapa 432: El UE 358B envía un mensaje de reconocimiento de SIP al UE 358B, y la velocidad de transferencia de datos tiene lugar a la velocidad negociada, etapa 434.
La Fig. 15 ilustra un ejemplo en el que el proxy ajusta el RNC o el BSC. En este ejemplo, el RNC no está asociado con ninguna dirección de IP y el UE no sabe del servicio de RC. Además, el RNC y el proxy son reconfigurados por medio de la herramienta de configuración con el número de puerto del RC. Este número de puerto es utilizado por el proxy como número de puerto de fuente para los mensajes del RC. El RNC utiliza el número de puerto del RC para señalar mensajes de RC, en otras palabras, los mensajes que tienen el número de puerto de fuente igual al número de puerto del RC. En este escenario el proxy inicializa los RNCs.
El UE 358A inicia la sesión de aplicación enviando un mensaje de INVITAR al UE 358B, a través del Proxy de SIP. El mensaje incluye un fichero de SDP, que especifica las velocidades que son aplicables para la sesión.
Tras la señalización de SIP inicial, los UEs establecen los filtros de paquetes de TFT de contextos de PDP secundarios de tal manera que incluyen el flujo de datos de usuario, dado que los UEs no saben del servicio de RC [véase el documento TS 23.060 del 3GPP].
Debido a que el proxy es un proxy de SIP, intercepta los mensajes de SIP y puede por ello leer y almacenar toda la información acerca de los UEs y de la sesión. Después, el proxy inicializa los RNCs. Para llevar a cabo la inicialización, el Proxy 360 envía un mensaje de inicialización a las direcciones de IP del UE 358A y el UE 358B y los números de puerto de datos de usuario como puerto de destino; el puerto de fuente es el número de puerto del RC (pre-configurado) y la dirección de IP de fuente es la dirección de IP del Proxy. El mensaje contiene los siguientes parámetros:
dirección de IP del RC (dirección de IP del UE correspondiente)
número de puerto de fuente del RC (el Proxy podría elegir el puerto del cual escuchará los mensajes del RC el RNC correspondiente)
ID del RC.
El GGSN mapea el mensaje de inicialización entrante al contexto de PDP que lleva el flujo de datos de usuario (es decir el contexto de PDP que lleva los datos que deben ser controlados) puesto que la dirección de IP y el número de puerto de destino del mensaje del RC es igual a los de los datos de usuario.
Los RNCs “buscan” en todo el tráfico entrante de ese usuario particular e interceptan los paquetes que tienen el puerto del RC como puerto de fuente, es decir, los mensajes del RC. Los RNCs son capaces de asociar el mensaje del RC con la RAB correcta debido a que el mensaje del RC ha llegado de esa RAB particular.
En la capa de UL, el RNC 356A envía el mensaje de inicialización del RC a la dirección de IP del RC y al número de puerto del RC (es decir al UE 358B). El mensaje contiene la tasa de bits inicial y el ID del RC.
El GGSN-B mapea el mensaje de inicialización entrante al contexto de PDP correcto puesto que la dirección de IP y el puerto de destino del mensaje de RC es igual al flujo de datos del usuario.
El RNC 356B, mediante la “búsqueda” en todo el tráfico entrante de ese usuario particular, intercepta los paquetes que tienen el puerto de RC como puerto de fuente, es decir, los mensajes del RC. El RNC es capaz de asociar el mensaje del RC con el RAB correcto debido a que el mensaje de RC ha llegado de ese RAB particular.
El RNC 356B contesta a continuación al mensaje de RC de Inicialización de una manera similar a ejemplos previos explicados anteriormente.
Así, de acuerdo con este ejemplo ilustrado en la Fig. 15, puede llevarse a cabo el siguiente procedimiento 440:
20
Etapa 422: El UE 358A envía un mensaje de invitar de SIP al proxy 360 que contiene un fichero de SDP, que incluye las velocidades de transferencia aplicables para la sesión. El proxy 360 envía el mensaje de SIP sobre el UE 358B.
Etapa 444: En respuesta, el UE 358B envía un mensaje de OK de SIP al proxy 360. El mensaje de reconocimiento también contiene un fichero de SDP, que incluye la velocidad de transferencia aplicable para el UE 358B.
Etapa 446: El UE 358A envía una Solicitud de Activar contexto de PDP Secundario a la CN 350A. La solicitud contiene la velocidad de transferencia. De manera similar, el UE 358B envía una Solicitud de Activar contexto de PDP Secundario de SM a la CN 350B que contiene también la velocidad de transferencia de usuario.
Etapa 448: La CN 350A envía un mensaje de Solicitud de Asignación del RAB de RANAP al RNC 356A que contiene la Velocidad, el ID del RC, la dirección de IP del 356B del RNC, y el número de puerto del 356B del RNC. De manera similar, la CN 350B envía un mensaje de Solicitud de Asignación de RAB de RANAP al RNC 356B que contiene la Velocidad, el ID del RC, la dirección de IP del 356A del RNC y el número de puerto del 356A del RNC.
Etapa 450: El RNC 356A envía un mensaje de Respuesta a Asignación de RAB de RANAP a la CN 350A. De manera similar, el RNC 356B envía un mensaje de Respuesta de Asignación del RAB de RANAP a la CN 350B.
Etapa 452: La CN 350A reconoce la solicitud de Activación de contexto de PDP Secundario de SM enviando un mensaje de Aceptación de Activación de contexto de PDP Secundario de SM a la CN 350A. La CN 350B reconoce la solicitud de Activación de contexto de PDP Secundario de SM enviando un mensaje de Aceptación de Activación de contexto de PDP Secundario de SM al UE 358B.
Etapa 454: El proxy 360 envía una Solicitud de GTP-U hacia el UE 358B. La Solicitud de RC incluye el ID del RC, la dirección de IP del RC y el número de Puerto del RC. El RNC 356B intercepta este mensaje.
Etapa 456: El proxy 360 envía una Solicitud de RC de GTP-U hacia el UE 358A. La Solicitud del RC incluye el ID del RC, la dirección de IP del RC y el número de Puerto del RC. El RNC 356A intercepta este mensaje.
Etapa 458: El RNC 356B devuelve una respuesta de GTP-U a la Solicitud del RC.
Etapa 460: El RNC 356A devuelve una respuesta de GTP-U a la Solicitud del RC.
Etapa 462: Ahora que el RNC 356A conoce la dirección de IP del UE 358B, el RNC 356A envía un mensaje de inicialización de GTP-U hacia el UE 358B. El mensaje es interceptado por el RNC 356B. El mensaje contiene el ID del RC y las velocidad de transferencia disponibles para el UE 358A.
Etapa 464. En respuesta, el RNC 356B envía un mensaje de inicialización de GTP-U hacia el UE 358A, el cual es interceptado por el RNC 356A, el mensaje de inicialización incluye las velocidad de transferencia de bits disponibles para el UE 358B.
Etapa 466: Ahora que el RNC 356A tiene la velocidad de transferencia de bits disponible para el UE 358B, puede determinar la velocidad de transferencia de bits óptima comparando la velocidad de transferencia de bits disponible para el UE 358B con la velocidad de transferencia de bits disponible para el UE 358B. De manera similar, el RNC 356B determina la velocidad de transferencia de bits óptima comparando la velocidad de transferencia de bits disponible para el UE 358B con la velocidad de transferencia de bits disponible para el UE 358A.
Etapa 468: El RNC 356A envía un mensaje de RRC al UE 358A especificando una tasa de bits inicial. De manera similar, el RNC 356B envía un mensaje de RRC al UE 358B especificando una tasa de bits inicial.
Etapa 470: El UE 358B envía un mensaje de reconocimiento de SIP al UE 358B y la transferencia de datos tiene lugar a la velocidad negociada, etapa 472.
La Fig. 16 ilustra un procedimiento 480 en el que un Proxy ajusta el RNC o el BSC. El procedimiento 480 es similar al procedimiento 440 explicado en referencia a la Fig. 15. En este ejemplo, los RNCs tienen direcciones de IP y el proxy de SIP local tiene conocimiento de las direcciones. Así, el proxy se actualiza de manera continua con respecto a la dirección de IP/Número de Puerto del RNC/BSC, para los cuales el UE ha establecido un contexto de PDP. La dirección del RNC podría alternativamente ser recibido del UE.
El UE 358A inicia la sesión de aplicación enviando un mensaje de INVITAR al UE 358B, a través de los Proxies de SIP (uno o varios de tales proxies). El primer Proxy de SIP añade la dirección de IP del RNC y el número de Puerto al mensaje de SIP. El fichero de SDP especifica las velocidades que son aplicables para la sesión. Alternativamente,
21
si es el UE el que sabe de la dirección de IP del RNC, entonces el UE puede añadir esta información al mensaje de SIP.
Una vez que el UE 358A y el UE 358B conocen las características de la sesión de aplicación uno de otro, inician el procedimiento de activación del contexto de PDP. A continuación, el UE 358A envía un reconocimiento de SIP al UE 358B, a través de los Proxies de SIP. Los Proxies de SIP interceptan este mensaje y lanzan el servicio de Control de Velocidad enviando mensajes de Solicitud de RC a su RNC local. Estos mensajes contienen parámetros de RC específicos (ID del RC, dirección de IP del RC, número de puerto del RC, dirección de IP del UE y número de puerto de destino de datos del UE). El RNC apropiado asocia el ID del RC con el RAB de manera que la sesión conocerá dónde enviar los mensajes de Control de Velocidad. Con el fin de llevar a cabo este procedimiento, el RNC “busca” para cada RAB en el flujo de datos del usuario extrayendo por ello la dirección de IP del UE y el número de puerto de destino de los datos del UE. Esta información es utilizada para asociar el ID del RC con el RAB apropiado.
Así, de acuerdo con este ejemplo ilustrado en la Fig. 16, puede llevarse a cabo el siguiente procedimiento 480:
Etapa 482: El UE 358A envía un mensaje de invitar de SIP al proxy 360A conteniendo un fichero de SDP, el cual incluye las velocidad de transferencia aplicables para la sesión. El Proxy de SIP añade al fichero de SDP la dirección de IP del RNC y el número de Puerto al cual el UE 358A. El proxy 360A envía el mensaje de SIP a otros proxies de SIP hasta que el mensaje llega al UE 358B.
Etapa 484: El UE 358B responde enviando un mensaje de OK de SIP al proxy 360B. El mensaje de reconocimiento también contiene un fichero de SDP, que incluye la velocidad de transferencia aplicable para el UE 358B.
Etapa 486: El UE 358A envía una Solicitud de Activación de contexto de PDP Secundario de SM a la CN 350A. La solicitud contiene el flujo de datos del usuario. De manera similar, el UE 358B envía una Solicitud de Activación de contexto de PDP Secundario de SM a la CN 350B, conteniendo también el flujo de datos de usuario.
Etapa 488: La CN 350A envía un mensaje de Solicitud de Asignación de RAB de RANAP al RNC 356A conteniendo la Velocidad, el ID del RC, la dirección de IP del RNC 356B y el número de puerto del RNC 356B. De manera similar, la CN 350B envía un mensaje de Solicitud de Asignación de RAB de RANAP al RNC 356B conteniendo la Velocidad, el ID del RC, la dirección de IP del RNC 356A y el número de puerto del RNC 356A.
Etapa 490: El RNC 356A envía un mensaje de Respuesta a Asignación de RAB de RANAP a la CN 350A. De manera similar, el RNC 356B envía un mensaje de Respuesta a Asignación de RAB de RANAP a la CN 350B.
Etapa 492: La CN 350A reconoce la solicitud de Activación de contexto de PDP Secundario de SM enviando un mensaje de Aceptación de Activación de contexto de PDP Secundario de SM a la CN 350A. La CN 350B reconoce la solicitud de Activación de contexto de PDP Secundario de SM enviando un mensaje de Aceptación de Activación de contexto de PDP Secundario de SM a la CN 350B.
Etapa 494: El UE 358A devuelve un mensaje de reconocimiento de SIP al UE 358B.
Etapa 496: El proxy envía una Solicitud de GTP-U de RC al RNC 356B. La solicitud de RC incluye el ID del RC, la dirección de IP del RC y el número de Puerto del RC. De manera similar, el Proxy envía una Solicitud de RC de GTP-U al RNC 356A. La Solicitud de RC incluye el ID del RC, la dirección de IP del RC y el Número de Puerto del RC.
Etapa 498: El RNC 356B devuelve una respuesta de GTP-U a la Solicitud de RC y el RNC 356A devuelve una respuesta de GTP-U a la Solicitud de RC.
Etapa 500: EL RNC 356A envía un mensaje de inicialización de GTP-U al RNC 356B. El mensaje contiene el ID del RC y las velocidades de transferencia disponibles para el UE 358A.
Etapa 502: En respuesta, el RNC 356B envía un mensaje de Inicialización de GTP-U al RNC 356A, incluyendo el mensaje de inicialización las velocidades de transferencia de bits disponibles para el UE 358B.
Etapa 504: El RNC 356A determina la velocidad de transferencia de bits óptima comparando la velocidad de transferencia de bits para el UE 358B con la velocidad de transferencia de bits del UE 358B y seleccionando la velocidad de transferencia de bits más baja. De manera similar, el RNC 356B determina la velocidad de transferencia de bits óptima comparando la velocidad de transferencia de bits para el UE 358B con la velocidad de transferencia de bits para el UE 358A.
Etapa 506: El RNC 356A envía un mensaje de RRC al UE 358A especificando una velocidad de bis inicial. De manera similar, el RNC 356B envía un mensaje de RRC al UE 358B especificando una tasa de bits inicial.
22
Etapa 508: La velocidad de transferencia tiene lugar a la velocidad de negociación.
Como se ha indicado en la Fig. 12, algunas realizaciones de la presente invención pueden comunicarse con una puerta de enlace a medios. La puerta de enlace a medios puede ajustar el RNC/BSC para el servicio de RC, que puede ser utilizado, por ejemplo, en la comunicación telefónica de móvil a fijo. Esta situación de P2P puede ser similar al caso de P2C en el que el Proxy es reemplazado por la Puerta de Enlace a Medios (MGW – Media GateWay). La MGW lleva a cabo la funcionalidad de transcodificación entre la PLMN y la PSTN. Así, el servicio de RC puede ser utilizado para ajustar convenientemente la tasa de bits del transcodificador.
La Fig. 17 es un ejemplo tal que en él el UL ajusta el RNC (o alternativamente el BSC) con los parámetros necesarios para el servicio de Control de Velocidad mediante el establecimiento del contexto de PDP. En este ejemplo, la MGW añade los parámetros de de RC específicos al protocolo de SIP/SDP. El RNC puede tener una dirección de IP de su propiedad, o no.
En este ejemplo 550, tiene que añadirse una identidad específica (IC) para implementar el servicio de Control de Velocidad RC, (es decir, el ID del RC). Además, la dirección de IP del RC y el número de Puerto del RC corresponden a la dirección de IP y al número de Puerto de la MGW. Así, el ajuste del RC en este ejemplo es conceptualmente similar al procedimiento 210 descrito en referencia a la Fig. 9. En este ejemplo, no obstante, se utiliza el protocolo de SIP para establecer la sesión en lugar del RTSP. Los parámetros del RC, por lo tanto, son enviados al UE en el mensaje de OK de SIP.
De acuerdo con este ejemplo ilustrado en la Fig. 17, pueden llevarse a cabo las siguientes etapas:
Etapa 552: El UE envía un mensaje de INVITAR de SIP a la MGW.
Etapa 554: La MGW responde devolviendo un mensaje de 200 OK/SDP de SIP al UE. El mensaje contiene también un fichero de SDP, que incluye el ID del RC, la dirección de IP del RC y los números de puerto del RC.
Etapa 556: El UE envía una solicitud de mensaje de SM a un SGSN para activar un contexto de PDP secundario. Este mensaje de SM contiene el ID del RC, las direcciones de IP del RC y los números de Puerto del RC.
Etapa 558: En respuesta, el SGSN envía un mensaje de RANAP al RNC. En este ejemplo, el mensaje es un mensaje de solicitud de asignación de RAB conteniendo el ID del RC, las direcciones de IP del RC y los números de puerto del RC.
Etapa 560: El RNC envía un reconocimiento en forma de una Respuesta de Asignación de RAB de RANAP indicando que el método de control de velocidad es aceptado.
Etapa 562: El SGSN envía a continuación una solicitud de Crear contexto de PDP de GTP-C al GGSN para iniciar el contexto de PDP.
Etapa 564: En respuesta, el GGSN devuelve un mensaje de respuesta a Crear contexto de PDP de GTP-C al SGSN.
Etapa 566: El RNC envía a continuación un GTP-U a la MGW. El mensaje incluye el ID del RC y la tasa de bits inicial.
Etapa 568: La MGW ajusta la velocidad del transcodificador a la tasa de bits inicial.
Etapa 570: En respuesta a la Etapa 556, el SGSN envía al UE un mensaje de aceptación de SM para la solicitud de Activar Contexto de PDP Secundario.
Etapa 572: Se envían datos a la velocidad del transcodificador entre el UE y el teléfono fijo.
Etapa 574: En algún punto durante la transmisión, el RNC determina que es posible una nueva tasa de bits y envía un mensaje de GTP-U (Respuesta de Control de Velocidad) a la MGW.
Etapa 576: La MGW ajusta la velocidad del transcodificador a la nueva velocidad.
Etapa 578: Se envían datos a la nueva velocidad del transcodificador.
La Fig. 18 es un ejemplo en el que la MGW ajusta el RNC o el BSC con los parámetros requeridos para el servicio de control de velocidad mediante el establecimiento del contexto de PDP. En este ejemplo, el RNC no está asociado con una dirección de IP y el UE no sabe del servicio de RC. Además, el RNC y la MGW puede ser preconfigurado por medio de una herramienta de configuración con el número de puerto del RC. El número de puerto del RC es utilizado por la MGW como número de puerto de fuente para todos los mensajes del RC. El RNC utiliza el número de
23
puerto del RC para señalar mensajes del RC, es decir, los mensajes que tienen el número de puerto de fuente igual al número de puerto del RC.
Tras la señalización inicial de SIP, el UE establece el contexto de PDP secundario donde el paquete de TFT filtra de tal manera que incluye sólo el flujo de datos del usuario, dado que el UE no sabe nada del servicio de RC [véase el documento TS 23.060 del 3GPP]. Debido a que el UE no sabe nada del servicio de RC, sólo puede definir filtros de paquete de TFT del contexto de PDP secundario para paquetes de datos de usuario (en otras palabras, no puede incluir mensajes del RC). Así que los mensajes del RC son mapeados sobre el mismo contexto de PDP que los datos de usuario. Por lo tanto, desde la perspectiva del GGSN, los mensajes del RC parecen ser los datos de usuario. El mapeo puede lograrse asignando a los mensajes del RC los mismos parámetros de IP que el paquete de datos, pero el número de puerto de fuente es el puerto del RC. De esta manera el mensaje del RC entrante será mapeado por el GGSN sobre el contexto de PDP de datos. Los mensajes del RC pueden ser entonces interceptados por el RNC que utiliza el número de puerto de fuente del RC como identificador. Como se ha explicado previamente, el RNC es preconfigurado por medio de una herramienta de configuración, así que reconocerá este tipo de mensaje.
Para preconfigurar o “inicializar” el RNC, la MGW envía un mensaje de inicialización cuya cabecera de IP/UDP contiene: dirección de IP del UE y número de puerto de datos de usuario como dirección y puerto de destino, el puerto de fuente es el número de puerto del RC (preconfigurado para ser el puerto en el cual escuchará la MGW los mensajes del RC) y la dirección de IP de fuente es la dirección de IP de la MGW (es decir, la dirección de IP del RC). El mensaje puede también contener el ID del RC.
En respuesta, el GGSN aplicable mapea el mensaje de inicialización entrante al contexto de PDP que lleva el flujo de datos del usuario (es decir, el contexto de PDP que lleva los datos que deben ser controlados) puesto que la dirección de IP y el número de puerto de destino del mensaje del RC son iguales a los de los datos de usuario.
Como se ha descrito anteriormente, el RNC “busca” en todo el tráfico entrante a ese usuario particular e intercepta los paquetes que tienen el puerto del RC como puerto de fuente, es decir, mensajes del RC. El RNC es capaz de asociar el mensaje del RC con el Soporte de Acceso por Radio (RAB – Radio Access Bearer, en inglés) porque el mensaje del RC ha llegado de ese RAB particular. En el enlace ascendente, el RNC envía el mensaje de Respuesta del RC a la dirección de IP del RC y al número de puerto del RC (es decir, a la MGW). El mensaje contiene la tasa de bits inicial y el ID del RC.
De acuerdo con este ejemplo ilustrado en la Fig. 18, puede llevarse a cabo el siguiente procedimiento 590:
Etapa 592: El UE envía un mensaje de INVITAR de SIP a la MGW.
Etapa 594: La MGW responde devolviendo un mensaje de 200 OK/SDP de SIP al UE.
Etapa 596: El UE envía una solicitud de mensaje de SM al SGSN para activar un contexto de PDP secundario.
Etapa 598: En respuesta, el SGSN envía un mensaje de RANAP al RNC.
Etapa 600: El RNC envía un reconocimiento en forma de una Respuesta de Asignación de RAB de RANAP indicando que el método del control de velocidad se ha aceptado.
Etapa 602: El SGSN envía a continuación una solicitud de Crear contexto de PDP de GTP-C al GGSN para iniciar el contexto de PDP.
Etapa 604: En respuesta, el GGSN devuelve un mensaje de respuesta a Crear contexto de PDP de GTP-C al SGSN.
Etapa 606: La MGW envía un mensaje de Solicitud de Control de Velocidad de GTP-U hacia el UE. En este ejemplo, el mensaje de solicitud incluye el ID del RC, la dirección de IP del RC (es decir, la dirección de IP de la MGW) y el número de puerto del RC.
Etapa 608: El RNC intercepta esta solicitud de control de velocidad y, en respuesta envía una solicitud de inicialización a la MGW, donde la solicitud de inicialización contiene el ID del RC y la tasa de bits inicial.
Etapa 610: La MGW ajusta la velocidad del transcodificador a la tasa de bits inicial.
Etapa 612: El SGSN responde al UE con un mensaje de Aceptación de Activar Contexto de PDP Secundario.
Etapa 614: Se envían datos a la velocidad del transcodificador entre el UE y el teléfono fijo.
Etapa 616: En algún punto durante la transmisión, el RNC determina que es posible una nueva tasa de bits y envía un mensaje de GTP-U (Respuesta de Control de Velocidad) a la MGW.
24
Etapa 618: La MGW ajusta la velocidad del transcodificador a la nueva velocidad.
Etapa 620: Se envían datos a la nueva velocidad del transcodificador.
La Fig. 19 es un ejemplo en el que la MGW ajusta el RNC/BSC con los parámetros requeridos para el servicio de control de velocidad sobre el establecimiento del contexto de PDP. En este ejemplo, no obstante, el RNC tiene una dirección de IP y esta dirección es conocida para la MGW. La MGW puede, por ejemplo, obtener la dirección de IP del RNC/BSC del UE mediante la fase de establecimiento de la sesión de RTSP/HTTP, o alternativamente, mediante una fase de establecimiento de SIP. (El UE es actualizado de manera continua con respecto a la dirección de IP del RNC / número de Puerto, para la o el cual ha establecido un contexto de PDP).
De acuerdo con el procedimiento de ejemplo 630 ilustrado en la Fig. 19, pueden llevarse a cabo las siguientes etapas:
Etapa 632: El UE envía un mensaje de INVITAR de SIP a la MGW.
Etapa 634: La MGW responde devolviendo un mensaje de 200 OK/SDP de SIP al UE.
Etapa 636: El UE envía una solicitud de mensaje de SM al SGSN para activar un contexto de PDP secundario.
Etapa 638: En respuesta, el SGSN envía un mensaje de RANAP al RNC.
Etapa 640: El RNC envía un reconocimiento en forma de una Respuesta de Asignación de RAB de RANAP indicando que el método del control de velocidad se ha aceptado.
Etapa 642: El SGSN envía a continuación una solicitud de Crear contexto de PDP de GTP-C al GGSN para iniciar el contexto de PDP.
Etapa 644: En respuesta, el GGSN devuelve un mensaje de respuesta a Crear Contexto de PDP de GTP-C al SGSN.
Etapa 646: La MGW envía a continuación un mensaje de Solicitud de Control de Velocidad de GTP-U al RNC. En este ejemplo, el mensaje de solicitud incluye el ID del RC, la dirección de IP del RC y el número de puerto del RC.
Etapa 648: En respuesta, el RNC envía una solicitud de inicialización a la MGW, donde la solicitud de inicialización contiene el ID del RC y la tasa de bits inicial.
Etapa 650: La MGW ajusta la velocidad del transcodificador a la tasa de bits inicial.
Etapa 652: En respuesta a la etapa 636, el SGSN envía al UE un mensaje de aceptación de SM para la solicitud de Activar Contexto de PDP Secundario.
Etapa 654: Se envían datos a la velocidad del transcodificador entre el UE y el teléfono fijo.
Etapa 656: En algún punto durante la transmisión, el RNC determina que es posible una nueva tasa de bits y envía un mensaje de GTP-U (Respuesta de Control de Velocidad) a la MGW.
Etapa 658: LA MGW ajusta la velocidad del transcodificador a la nueva velocidad.
Etapa 660: Se envían datos a la nueva velocidad del transcodificador.
En los dibujos y memoria, se han explicado realizaciones preferidas típicas de la invención y, aunque se emplean términos específicos, se utilizan sólo en un sentido genérico y descriptivo y no con el propósito de limitación, siendo el alcance de la invención expuesto en las siguientes reivindicaciones. Para un experto en la materia resultarán evidentes otras realizaciones, las cuales también se incorporarían a la invención, por ejemplo: Las realizaciones de la invención podrían también incorporar un sistema que incorpora un método para controlar la velocidad de flujo de transmisión de bits de datos en una sesión de transferencia de bits de datos desde una entidad de servicio hasta un cliente, implicando la sesión la transferencia de bits sobre un enlace de comunicaciones inalámbrico, comprendiendo el sistema: un medio para ajustar la sesión proporcionando un nodo de control de radio para establecer parámetros de velocidad de flujo relativos al enlace inalámbrico, en el que el ajuste incluye: un medio para resolver el direccionamiento entre el nodo de control de radio y la entidad de servicio, un medio para enviar parámetros de configuración de control de velocidad al nodo de control de radio, un medio para generar en el nodo de control de radio un mensaje de control de velocidad (RC – Rate Control, en inglés) inicial incluyendo parámetros de velocidad de flujo inicial, un medio para enviar al menos un mensaje de control de velocidad iniciales para permitir que la entidad de servicio ajuste las velocidades de transmisión iniciales para la sesión de acuerdo con al menos uno de los parámetros de velocidad de flujo inicial; un medio para monitorizar el enlace de comunicación inalámbrica; un medio para, basándose en la monitorización, enviar nuevos parámetros de velocidad de flujo de manera que la entidad de
25
servicio pueda actualizar la velocidad de transmisión de la sesión de acuerdo con los nuevos parámetros de control de velocidad.
Tal sistema puede comprender también un medio para examinar, el nodo de control de radio, cada cabecera de mensaje en el flujo entre el cliente y la entidad de servicio para obtener parámetros de configuración de control de velocidad dentro de los mensajes examinados.
El sistema puede comprender también un medio para activar un conjunto de información de capa intermedia entre el cliente y un nodo de puerta de enlace; un medio para enviar, el nodo de puerta de enlace, un mensaje de capa de aplicación a la entidad de servicio, incluyendo la dirección de IP del cliente; un medio para recibir, el nodo de control de radio, un mensaje de iniciación de control de radio desde la entidad de servicio, incluyendo la dirección de IP de la entidad de servicio para permitir que el nodo de control de radio envíe mensajes a la entidad de servicio; y un medio para enviar, el nodo de control de radio, un mensaje de control de velocidad a la entidad de servicio, en el que el mensaje de control de velocidad contiene parámetros de velocidad de flujo.
El sistema puede comprender también un medio para iniciar una sesión, el cliente, enviando una orden de capa de aplicación a la entidad de servicio, un medio para enviar, la entidad de servicio, una orden de capa de transporte al cliente, un medio para examinar, el nodo de control de radio, cabeceras de órdenes de capa de transporte desde la entidad de servicio para obtener parámetros de configuración de control de velocidad dentro de la orden de capa de transporte, un medio para enviar, el nodo de control de radio, una respuesta del control de velocidad en respuesta a encontrar parámetros de configuración del control de velocidad en la orden de capa de transporte.
Adicionalmente, el medio para el ajuste puede también comprender: un medio para iniciar la sesión de acuerdo con un protocolo de nivel de aplicación, un medio para recibir, el nodo de control de radio, los parámetros de configuración de control de velocidad de acuerdo con un primer protocolo de capa intermedia; un medio para ligar los primeros parámetros de configuración de control de capa intermedia a parámetros de acuerdo con un segundo protocolo de capa intermedia; un medio para generar los parámetros ligados; y un medio para incluir los parámetros ligados en el mensaje del control de velocidad inicial.
El medio para el ajuste puede comprender también: un medio para iniciar la sesión de acuerdo con un protocolo de nivel de aplicación, un medio para recibir, el nodo de control de radio, los parámetros de configuración del control de velocidad de acuerdo con un protocolo de capa intermedia; un medio para enviar la velocidad inicial a la dirección de IP del control de velocidad especificada en los parámetros de configuración.
El sistema puede comprender también un medio para activar una información de capa intermedia ajustada entre el cliente y un nodo de soporte de servicio en la red. La entidad de servicio del sistema puede ser un servidor de aplicación, un servidor de transmisión en tiempo real o un proxy en comunicación con un servidor de aplicación. El cliente puede ser una estación de telefonía móvil.
En otras realizaciones, los parámetros de configuración del control de velocidad pueden ser seleccionados de un grupo que consiste en un indicador del método de control de velocidad, un identificador del control de velocidad, una dirección de IP del control de velocidad y números de puerto del control de velocidad. Los parámetros de la velocidad de flujo son seleccionados del grupo que consiste en un identificador del control de velocidad y una tasa de bits. El protocolo de capa de aplicación puede ser el Protocolo de Transmisión en Tiempo Real (RTSP – Real Time Streaming Protocol, en inglés), el primer protocolo intermedio es una Parte de Aplicación de Red de Acceso de Radio (RANAP – Radio Access Network Application Part, en inglés) y el segundo protocolo intermedio es Iu UP o GTP sobre IP. Además, la sesión puede ocurrir dentro de una red que es un Sistema de Telefonía Móvil Universal (UMTS – Universal Mobile Telephony System, en inglés), un sistema de Servicio de Radio en paquetes General (GPRS – General Packet Radio Service, en inglés) o una red WLAN.
En otras realizaciones, puede haber un sistema que tiene instrucciones para negociar la velocidad del flujo de transmisión de bits de datos en una sesión de transferencia de bits de datos de una primera entidad de telefonía móvil a una segunda entidad de telefonía móvil, implicando la sesión la transmisión de bits sobre al menos un enlace de comunicaciones inalámbrico, pudiendo las instrucciones comprender: proporcionar un primer nodo de control de radio en comunicación con la primera entidad de telefonía móvil para controlar las velocidades de transmisión de bits de un primer enlace de radio a la primera entidad de telefonía móvil, proporcionar un segundo nodo de control de radio en comunicación con la segunda entidad de telefonía móvil, para controlar las velocidades de transmisión de bits de un segundo enlace de radio a la segunda entidad de telefonía móvil, resolver el direccionamiento entre el primer nodo de control de radio y el segundo nodo de control de radio para permitir la comunicación entre el primer nodo de control de radio y el segundo nodo de control de radio, enviar los parámetros de control de velocidad para el primer enlace al segundo nodo de control de radio, enviar los parámetros de control de velocidad para el segundo enlace al primer nodo de control de radio, igualar los parámetros de control de velocidad para obtener una velocidad de transmisión de bits real, enviar un indicador de la velocidad de transmisión de bits real a la primera entidad de telefonía móvil y a la segunda entidad de telefonía móvil de manera que la transmisión de bits puede ocurrir a la velocidad de transmisión de bits.
26
En algunas realizaciones, la resolución puede también incluir: iniciar una sesión enviando órdenes de ajuste de acuerdo con un protocolo de capa de aplicación entre la primera entidad de telefonía móvil y la segunda entidad de telefonía móvil, establecer un conjunto de información de capa intermedia entre la primera entidad de telefonía móvil y un nodo de servicio, recibir, el primer nodo de control de radio, parámetros de configuración del control de velocidad para la segunda entidad de telefonía móvil de acuerdo con un primer protocolo de capa intermedia; y recibir, el segundo nodo de control de radio, parámetros de configuración del control de velocidad para la primera entidad de telefonía móvil de acuerdo con un primer protocolo de capa intermedia.
En otras realizaciones, el sistema puede contener instrucciones para examinar, el primer nodo de control de radio, las cabeceras de mensajes dirigidas a la primera entidad de telefonía móvil para obtener las velocidades de transmisión disponibles para el segundo enlace de radio, y examinar, el segundo nodo de control de radio, las cabeceras de mensajes dirigidos a la segunda entidad de telefonía móvil para obtener las velocidades de transmisión disponibles para el primer enlace de radio.
En algunas realizaciones, el sistema puede contener instrucciones para proporcionar un proxy, por lo que todos los mensajes previstos para ser recibidos por la primera entidad de telefonía móvil desde la segunda entidad de telefonía móvil, y todos los mensajes recibidos por la segunda entidad de telefonía móvil desde la primera entidad de telefonía móvil, son enviados a través de y transmitidos por el proxy, o examinar, el primer nodo de control de radio, las cabeceras de mensajes dirigidos a la primera entidad de telefonía móvil para obtener parámetros de configuración del control de velocidad relativos a la segunda entidad de telefonía móvil, y examinar, el segundo nodo de control de radio, las cabeceras de mensajes dirigidos a la segunda entidad de telefonía móvil para obtener parámetros de configuración del control de velocidad relativos a la primera entidad de telefonía móvil.
En algunas realizaciones, el sistema puede contener instrucciones para proporcionar un primer proxy, por lo que todos los mensajes enviados por la primera entidad de telefonía móvil a la segunda entidad de telefonía móvil, todos los mensajes enviados por el primer nodo de control de radio al segundo nodo de control de radio, son enviados y transmitidos por el primer proxy. Adicionalmente, algunas realizaciones pueden comprender instrucciones para proporcionar un segundo proxy, por lo que todos los mensajes enviados por la segunda entidad de telefonía móvil a la primera entidad de telefonía móvil, y todos los mensajes enviados por el segundo nodo de control de radio al primer nodo de control de radio son enviados a y transmitidos por el segundo proxy.
En algunas de estas realizaciones, el protocolo de capa de aplicación utilizado por el sistema es un Protocolo de Iniciación de Sesión, el protocolo de primera capa intermedia es una Parte de Aplicación de Red de Acceso por Radio (RANAP – Radio Access Network Application Part, en inglés), y el segundo protocolo de capa intermedia es Iu UP.
En otras realizaciones, puede haber un sistema para controlar la velocidad de transcodificación de una puerta de enlace a medios durante una sesión de transferencia de bits de datos de una puerta de enlace a medios a un cliente, implicando la sesión de transferencia de bits la transferencia de bits sobre un enlace de comunicaciones inalámbrico, comprendiendo el sistema: un medio para ajustar la sesión proporcionando un nodo de control de radio para establecer parámetros de velocidad de transcodificación relativos al enlace inalámbrico, en el que el ajuste incluye: un medio para resolver el direccionamiento entre el nodo de control de radio y la puerta de enlace a medios, un medio para enviar parámetros de comunicación del control de velocidad al nodo de control de radio, un medio para generar en el nodo de control de radio un mensaje de control de velocidad inicial que incluye parámetros de velocidad de transcodificación iniciales, un medio para enviar al menos un mensaje de control de velocidad inicial de manera que la puerta de enlace a medios pueda ajustar las velocidades de transcodificación iniciales para la sesión de acuerdo con al menos uno de los parámetros de velocidad de transcodificación; un medio para monitorizar el enlace de comunicación inalámbrica; un medio para, basándose en la monitorización, enviar nuevos parámetros de velocidad de transcodificación de manera que la puerta de enlace a medios pueda actualizar la velocidad de transmisión de la sesión de acuerdo con los nuevos parámetros de velocidad de transcodificación.
Otras realizaciones pueden contener un medio para examinar, el nodo del control de radio, cada cabecera de mensaje en el flujo entre el cliente y la puerta de enlace a medios para obtener parámetros de configuración de control de velocidad dentro de los mensajes examinados. Otras realizaciones pueden incluir un medio para activar un conjunto de información de capa intermedia entre el cliente y un nodo de puerta de enlace en la red; un medio para enviar, el nodo de puerta de enlace, un mensaje de capa de aplicación a la puerta de enlace a medios, incluyendo la dirección de IP del cliente; y un medio para recibir, el nodo de control de radio, un mensaje de iniciación del control de velocidad, incluyendo la dirección de IP de la puerta de enlace a medios para permitir que el nodo de control de radio envíe mensajes a la puerta de enlace a medios.
Otras realizaciones pueden incluir un medio para iniciar una sesión, el cliente, enviando una orden de capa de aplicación a la puerta de enlace a medios, un medio para enviar, la puerta de enlace a medios, una orden de capa de transporte al cliente en la que la orden de la capa de transporte incluye parámetros de configuración del control de velocidad; y un medio para examinar, el nodo de control de radio, las cabeceras de las órdenes de capa de
27
transporte para obtener parámetros de configuración de control de velocidad dentro de las órdenes de la capa de transporte.
En algunas realizaciones, el medio para ajustar incluye también un medio para iniciar la sesión de acuerdo con un protocolo de nivel de aplicación, un medio para recibir, el nodo de control de radio, los parámetros de configuración del control de velocidad de acuerdo con un primer protocolo de capa intermedia; un medio para ligar los primeros parámetros de configuración del control de capa intermedia a parámetros de acuerdo con un segundo protocolo de capa intermedia; un medio para generar los parámetros ligados; y un medio para incluir los parámetros ligados en el mensaje del control de velocidad uncial.
En algunas comunicaciones, el medio para el ajuste incluye también un medio para iniciar la sesión de acuerdo con un protocolo de nivel de aplicación, un medio para recibir, el nodo de control de radio, los parámetros de configuración del control de velocidad de acuerdo con un protocolo de capa intermedia; un medio para enviar la velocidad inicial a la dirección de IP del control de velocidad especificada en los parámetros de configuración.
Tales realizaciones pueden también comprender un medio para activar un conjunto de información de capa intermedia entre el cliente y un nodo de soporte de servicio en la red, en el que el cliente puede ser una estación de telefonía móvil. Además, los parámetros de configuración del control de velocidad pueden ser seleccionados del grupo que consiste en un indicador del sistema del control de velocidad, un identificador del control de velocidad, una dirección de IP del control de velocidad y números de puerto del control de velocidad, y los parámetros de velocidad de transcodificación pueden ser seleccionados del grupo que consiste en un identificador del control de velocidad y una tasa de bits.
En tales realizaciones, el protocolo de capa de aplicación puede ser el SIP [Protocolo de Iniciación de Sesión – Session Initiation Protocol, en inglés) el primer protocolo intermedio puede ser la Parte de Aplicación de Red de Acceso por Radio (RANAP – Radio Access Network Application Parten inglés), y el segundo protocolo intermedio puede ser el Iu UP. Adicionalmente, la sesión puede ocurrir dentro de una red que es un Sistema de Telefonía de Telefonía Móvil Universal (UMTS – Universal Mobile Telephony System, en inglés), un sistema de Servicio de Radio en paquetes General (GPRS – General Packet Radio Service, en inglés), o una red WLAN.
28

Claims (26)

  1. REIVINDICACIONES
    1. El método para controlar la velocidad de flujo de transmisión de bits de datos en una sesión de transferencia de bits de datos desde una entidad de servicio (104, Ser de Transmisión en tiempo real) a un cliente (VE, 102), implicando la sesión la transferencia de bits sobre un enlace de comunicaciones inalámbrico, comprendiendo el método: ajustar la sesión proporcionando un nodo de control de radio (RNC – Radio Network Controller, en inglés) para establecer parámetros de velocidad de flujo relativos al enlace inalámbrico, en el que el ajuste incluye:
    resolver el direccionamiento entre el nodo de control de radio (RNC – Radio Network Controller, en inglés) y la entidad de servicio (104, Ser de Transmisión en tiempo real), enviando parámetros de configuración de control al nodo de control de radio (RNC - Radio Network Controller, en inglés), generando en el nodo de control de radio (RNC - Radio Network Controller, en inglés) un mensaje del control de velocidad (RC) inicial incluyendo parámetros de velocidad iniciales, enviando al menos (226) un mensaje del control de velocidad inicial para permitir que la entidad de servicio (104, Ser de Transmisión en tiempo real) ajuste las velocidades de transmisión iniciales para la sesión de acuerdo con al menos uno de los parámetros de velocidad de flujo iniciales; monitorizar el enlace de comunicación inalámbrico;
    basándose en la monitorización, enviar (236) nuevos parámetros de velocidad de flujo de manera que la entidad de servicio (104, Ser de Transmisión en tiempo real) pueda actualizar la velocidad de transmisión de la sesión de acuerdo con los nuevos parámetros de control de velocidad.
  2. 2.
    El método de la reivindicación 1, que comprende también examinar, el nodo de control de radio (RNC – Radio Network Controller, en inglés), cada cabecera de mensaje en el flujo entre el cliente y la entidad de servicio (104, Ser de Transmisión en tiempo real) para obtener parámetros de configuración del control de velocidad dentro de los mensajes examinados.
  3. 3.
    El método de la reivindicación 2, que comprende también activar un conjunto de información de capa intermedia entre el cliente y un nodo de puerta de enlace; enviar, el nodo de puerta de enlace, un mensaje de capa de aplicación a la entidad de servicio (104, Ser de Transmisión en tiempo real), incluyendo la dirección de IP del cliente;
    recibir, el nodo de control de radio (RNC - Radio Network Controller, en inglés), un mensaje de iniciación del control de radio desde la entidad de servicio (104, Ser de Transmisión en tiempo real), incluyendo la dirección de IP de la entidad de servicio (104, Ser de Transmisión en tiempo real) para permitir que el nodo de control de radio (RNC -Radio Network Controller, en inglés) envíe mensajes a la entidad de servicio (104, Ser de Transmisión en tiempo real); y
    enviar, el nodo de control de radio (RNC - Radio Network Controller, en inglés) un mensaje de control de velocidad a la entidad de servicio (104, Ser de Transmisión en tiempo real), en el que el mensaje de control de tasa contiene parámetros de velocidad de flujo.
  4. 4. El método de la reivindicación 1, que comprende también:
    iniciar una sesión, el cliente, enviando una orden de capa de aplicación a la entidad de servicio (104, Ser de Transmisión en tiempo real),
    enviar, la entidad de servicio (104, Ser de Transmisión en tiempo real), una orden de capa de transporte al cliente,
    examinar, el nodo de control de radio (RNC - Radio Network Controller, en inglés), las cabeceras de las órdenes de capa de transporte desde la entidad de servicio (104, Ser de Transmisión en tiempo real) para obtener parámetros de configuración del control de velocidad dentro de la orden de la capa de transporte,
    enviar, el nodo de control de radio (RNC - Radio Network Controller, en inglés), una respuesta del control de velocidad en respuesta a encontrar parámetros de configuración del control de velocidad en la orden de la capa de transporte.
  5. 5. El método de la reivindicación 1, en el que el ajuste comprende también:
    iniciar la sesión de acuerdo con un protocolo de nivel de aplicación,
    recibir, el nodo de control de radio (RNC - Radio Network Controller, en inglés), los parámetros de configuración del control de velocidad de acuerdo con un primer protocolo de capa intermedia;
    ligar los primeros parámetros de configuración del control de capa intermedia a los parámetros de acuerdo con un segundo protocolo de capa intermedia;
    29
    generar los parámetros ligados; e
    incluir los parámetros ligados en el mensaje del control de velocidad inicial.
  6. 6. El método de la reivindicación 1, en el que el ajuste comprende también:
    iniciar la sesión de acuerdo con un protocolo de nivel de aplicación,
    recibir, el nodo de control de radio (RNC - Radio Network Controller, en inglés), los parámetros de configuración del control de velocidad de acuerdo con un protocolo de capa intermedia;
    enviar la velocidad inicial a la dirección de IP del control de velocidad especificada en los parámetros de configuración.
  7. 7.
    El método de las reivindicaciones 5 ó 6, que comprende también activar un conjunto de información de capa intermedia entre el cliente y un nodo de soporte de servicio en la red.
  8. 8.
    El método de la reivindicación 1, en el que la entidad de de servicio (104, Ser de Transmisión en tiempo real) es un servidor de aplicación o un servidor de transmisión en tiempo real.
  9. 9.
    El método de la reivindicación 1, en el que la entidad de servicio (104, Ser de Transmisión en tiempo real) es un proxy en comunicación con el servidor de aplicación.
  10. 10.
    El método de la reivindicación 1, en el que le cliente es una estación de telefonía móvil.
  11. 11.
    El método de la reivindicación 1, en el que los parámetros de configuración del control de velocidad son seleccionados de un grupo que consiste en un indicador de método del control de velocidad, un identificador del control de velocidad, una dirección de IP del control de velocidad y números de puerto del control de velocidad.
  12. 12.
    El método de la reivindicación 1, en el que los parámetros de la velocidad de flujo son seleccionados de un grupo que consiste en un identificador del control de velocidad y una tasa de bits.
  13. 13.
    El método de la reivindicación 5, en el que el protocolo de capa de aplicación es el Protocolo de Transmisión en Tiempo Real (RTSP – Real Time Streaming Protocol, en inglés), el primer protocolo intermedio es una Parte de Aplicación de Red de Acceso por Radio (RANAP – Radio Access Network Application Part, en inglés), y el segundo protocolo intermedio es el Iu UP o GTP sobre IP.
  14. 14.
    El método de la reivindicación 1, en el que la sección ocurre dentro de una red que es un Sistema de Telefonía Móvil Universal (UMTS – Universal Mobile Telephony System, en inglés), un sistema de Servicio de Radio en paquetes General – General Packet Radio Service, en inglés), o una red WLAN.
  15. 15.
    Un método para controlar la velocidad de transcodificación de una puerta de enlace a medios durante una sesión de transferencia de bits de datos desde la puerta de enlace a medios a un cliente (VE, 102), implicando la sesión de transferencia de bits la transferencia de bits sobre un enlace de comunicaciones inalámbrico, comprendiendo el método:
    ajustar la sesión proporcionando un nodo de control de radio (RNC – Radio Network Controller, en inglés) para establecer parámetros de velocidad de transcodificación relativos al enlace inalámbrico, en el que el establecimiento incluye:
    resolver el direccionamiento entre el nodo de control de radio (RNC – Radio Network Controller, en inglés) y la puerta de enlace a medios, enviando los parámetros de configuración del control de velocidad al nodo de control de radio (RNC – Radio Network Controller, en inglés),
    generar en el nodo de control de radio (RNC – Radio Network Controller, en inglés) un mensaje del control de velocidad inicial incluyendo parámetros de velocidad de transcodificación inicial,
    enviar (226) al menos un mensaje del control de velocidad inicial de manera que la puerta de enlace a medios pueda enviar velocidades de transcodificación iniciales para la sesión de acuerdo con al menos uno de los parámetros de velocidad de transcodificación iniciales;
    monitorizar el enlace de comunicación inalámbrico;
    basándose en la monitorización, enviar nuevos parámetros de velocidad de transcodificación de manera que la puerta de enlace a medios pueda actualizar la velocidad de transmisión de la sesión de acuerdo con los nuevos parámetros de velocidad de transcodificación.
    30
  16. 16.
    El método de la reivindicación 15, que comprende también examinar, el nodo de control de radio (RNC – Radio Network Controller, en inglés), cada cabecera de mensaje en el flujo entre el cliente y la puerta de enlace a medios para obtener los parámetros de configuración del control de velocidad dentro de los mensajes examinados.
  17. 17.
    El método de la reivindicación 16, que comprende también:
    activar un conjunto de información de capa intermedia entre el cliente y un nodo de puerta de enlace en la red;
    enviar, el nodo de puerta de enlace, un mensaje de capa de aplicación a la puerta de enlace a medios, incluyendo la dirección de IP del cliente; y
    recibir, el nodo de control de radio (RNC – Radio Network Controller, en inglés), un mensaje de iniciación del control de velocidad, incluyendo la dirección de IP de la puerta de enlace a medios para permitir que el nodo de control de radio (RNC – Radio Network Controller, en inglés) envíe mensajes a la puerta de enlace a medios.
  18. 18. El método de la reivindicación 15, que comprende también:
    iniciar una sesión, el cliente, enviando una orden de capa de aplicación a la puerta de enlace a medios,
    enviar, la puerta de enlace a medios, una orden de capa de transporte al cliente en la que la orden de capa de transporte incluye parámetros de configuración de control de velocidad; y
    examinar, el nodo de control de radio (RNC – Radio Network Controller, en inglés), las cabeceras de las órdenes de capa de transporte para obtener parámetros de configuración de control de velocidad dentro de las órdenes de la capa de transporte.
  19. 19. El método de la reivindicación 15, en el que el ajuste comprende también: iniciar la sesión de acuerdo con un protocolo de nivel de aplicación, recibir, el nodo de control de radio (RNC – Radio Network Controller, en inglés), los parámetros de configuración
    de control de velocidad de acuerdo con un primer protocolo de capa intermedia;
    ligar los primeros parámetros de configuración de control de capa intermedia a los parámetros de acuerdo con un segundo protocolo de capa intermedia; generar los parámetros ligados; e incluir los parámetros ligados en el mensaje de control de velocidad inicial.
  20. 20.
    El método de la reivindicación 15, en el que el establecimiento comprende también: iniciar la sesión de acuerdo con un protocolo de nivel de aplicación, recibir, el nodo de control de radio (RNC – Radio Network Controller, en inglés), los parámetros de configuración
    de control de velocidad de acuerdo con un protocolo de capa intermedia; enviar la velocidad inicial a la dirección de IP de control de velocidad especificada en los parámetros de configuración.
  21. 21.
    El método de las reivindicaciones 19 ó 20, que comprende también activar un conjunto de información de capa intermedia entre el cliente y un nodo de soporte de servicio en la red.
  22. 22.
    El método de la reivindicación 15, en el que el cliente es una estación de telefonía móvil.
  23. 23.
    El método de la reivindicación 15, en el que los parámetros de configuración del control de velocidad son seleccionados del grupo que consiste en un indicador del método del control de velocidad, un identificador del control de velocidad, una dirección de IP del control de velocidad y números de puerto del control de velocidad.
  24. 24.
    El método de la reivindicación 15, en el que los parámetros de velocidad de transcodificación son seleccionados del grupo que consiste en un identificador de control de velocidad y una velocidad de bits.
  25. 25.
    El método de la reivindicación 19, en el que el protocolo de capa de aplicación es el SI [Protocolo de Iniciación de Sesión – Session Initiated Protocol, en inglés], el primer protocolo intermedio es la Parte de Aplicación de Red de Acceso de Radio (RANAP – Radio Access Network Application Parten inglés) y el segundo protocolo intermedio es el Iu UP.
  26. 26.
    El método de la reivindicación 15, en el que la sesión ocurre dentro de una red que es un Sistema de Telefonía Móvil Universal (UMTS – Universal Mobile Telephony System, en inglés), un sistema de Servicio de Radio en paquetes General (GPRS – General Packet Radio Service, en inglés) o una red WLAN.
    31
    32
ES03816585T 2003-04-07 2003-11-18 Método y sistema para el servicio de control de velocidad en una red Expired - Lifetime ES2390582T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
SE0301053 2003-04-07
SE0301053A SE0301053D0 (sv) 2003-04-07 2003-04-07 Method and system in a communications network
PCT/IB2003/005231 WO2004091151A1 (en) 2003-04-07 2003-11-18 Method and system for rate control service in a network

Publications (1)

Publication Number Publication Date
ES2390582T3 true ES2390582T3 (es) 2012-11-14

Family

ID=20290981

Family Applications (1)

Application Number Title Priority Date Filing Date
ES03816585T Expired - Lifetime ES2390582T3 (es) 2003-04-07 2003-11-18 Método y sistema para el servicio de control de velocidad en una red

Country Status (9)

Country Link
US (1) US20070025301A1 (es)
EP (2) EP1614258B1 (es)
CN (2) CN101516110B (es)
AT (1) ATE484134T1 (es)
AU (1) AU2003276592A1 (es)
DE (1) DE60334508D1 (es)
ES (1) ES2390582T3 (es)
SE (1) SE0301053D0 (es)
WO (1) WO2004091151A1 (es)

Families Citing this family (173)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE356499T1 (de) * 2004-01-06 2007-03-15 Cit Alcatel Session-ressource-broker für physikalische schicht
US20050243746A1 (en) * 2004-04-29 2005-11-03 Nokia Corporation Session inspection scheme
US7984149B1 (en) * 2004-08-04 2011-07-19 Cisco Technology, Inc. Method and apparatus for identifying a policy server
US7672272B2 (en) * 2004-08-31 2010-03-02 Telefonaktiebolaget L M Ericsson (Publ) Frame size adaptation in real-time transport protocol
US20060114855A1 (en) * 2004-11-30 2006-06-01 Haihong Zheng Quality of service (QOS) signaling for a wireless network
KR100666956B1 (ko) * 2005-03-08 2007-01-10 삼성전자주식회사 네트워크에서의 미디어 전송 장치 및 방법
US7818001B2 (en) * 2005-03-25 2010-10-19 Alcatel-Lucent Usa Inc. Fine grain downlink active set control
US9065595B2 (en) * 2005-04-07 2015-06-23 Opanga Networks, Inc. System and method for peak flow detection in a communication network
US11258531B2 (en) 2005-04-07 2022-02-22 Opanga Networks, Inc. System and method for peak flow detection in a communication network
US8589508B2 (en) * 2005-04-07 2013-11-19 Opanga Networks, Inc. System and method for flow control in an adaptive file delivery system
US7500010B2 (en) * 2005-04-07 2009-03-03 Jeffrey Paul Harrang Adaptive file delivery system and method
US8909807B2 (en) * 2005-04-07 2014-12-09 Opanga Networks, Inc. System and method for progressive download using surplus network capacity
US8719399B2 (en) 2005-04-07 2014-05-06 Opanga Networks, Inc. Adaptive file delivery with link profiling system and method
FI20050412A0 (fi) * 2005-04-21 2005-04-21 Nokia Corp Menetelmä yhteyksien muodostamiseksi tietoliikennejärjestelmässä
US7656835B2 (en) * 2005-05-18 2010-02-02 Nokia Corporation Method for informing changed communications capabilities
US20060285534A1 (en) * 2005-06-20 2006-12-21 Lucent Technologies Inc. Methods and systems for improved charging information accuracy in a wireless communication system
EP1929687B1 (en) 2005-09-30 2011-05-25 Research In Motion Limited Methods and apparatus for dynamically adjusting a data packet window size for data packet transmission in a wireless communication network
US9219686B2 (en) * 2006-03-31 2015-12-22 Alcatel Lucent Network load balancing and overload control
KR100966047B1 (ko) * 2006-08-25 2010-06-28 삼성전자주식회사 통신시스템에서 미디어 송신 방법 및 장치
US20080069101A1 (en) * 2006-09-15 2008-03-20 Nokia Corporation System and method of routing packets
CN101155260A (zh) * 2006-09-30 2008-04-02 华为技术有限公司 电子设备的控制方法、鉴权方法和服务器
US8477608B2 (en) 2006-10-26 2013-07-02 Unwired Planet, Llc Method and receiver for controlling the conformance of a data flow in a communication system to a traffic definition
US7907523B2 (en) * 2006-12-05 2011-03-15 Electronics And Telecommunications Research Institute Method and apparatus for controlling variable bit-rate voice codec
US8929360B2 (en) 2006-12-07 2015-01-06 Cisco Technology, Inc. Systems, methods, media, and means for hiding network topology
EP2103052B1 (en) * 2006-12-28 2012-08-22 Research In Motion Limited Methods and apparatus for increasing data throughput by grouping data packets into maximum transmissible units
US20080165679A1 (en) * 2007-01-10 2008-07-10 Ipwireless, Inc. Method to mitigate fraudulent usage of QoS from mobile terminals using uplink packet marking
JP2010517375A (ja) * 2007-01-16 2010-05-20 メディアキャスト エルエルシー ワイヤレスデータ配信管理システムおよび方法
US8081609B2 (en) * 2007-02-14 2011-12-20 Alcatel Lucent Proxy-based signaling architecture for streaming media services in a wireless communication system
US7706266B2 (en) * 2007-03-12 2010-04-27 Citrix Systems, Inc. Systems and methods of providing proxy-based quality of service
KR20100029258A (ko) * 2007-06-22 2010-03-16 인터디지탈 테크날러지 코포레이션 핸드오버 동작에서 자원 관리를 위한 방법 및 장치
CN101364883B (zh) * 2007-08-06 2011-12-28 华为技术有限公司 一种多终端会话方法及通讯系统以及相关设备
US8190750B2 (en) 2007-08-24 2012-05-29 Alcatel Lucent Content rate selection for media servers with proxy-feedback-controlled frame transmission
CN101431394B (zh) 2007-11-05 2012-01-11 中兴通讯股份有限公司 下行隧道混合自动重传请求方法
EP2218241A1 (en) * 2007-11-06 2010-08-18 Alcatel Lucent A method for the delivery of media streaming services in a mobile communication system
WO2009063434A1 (en) * 2007-11-16 2009-05-22 Nokia Siemens Networks Oy Mapping quality of service for intersystem handover
EP2091203A1 (en) * 2008-02-12 2009-08-19 Koninklijke KPN N.V. Method and system for transmitting a multimedia stream
WO2009090983A1 (ja) * 2008-01-16 2009-07-23 Nec Corporation ゲートウェイ装置およびシステム、並びに、通信方法
WO2009106127A1 (en) * 2008-02-25 2009-09-03 Telefonaktiebolaget Lm Ericsson (Publ) Delivery of multicast data
EP2266291B1 (en) * 2008-03-20 2018-09-05 Nokia Solutions and Networks Oy Different ip interfaces in a communication network system
US8949719B2 (en) * 2008-05-23 2015-02-03 Viasat, Inc. Methods and systems for user interface event snooping and prefetching
US8340634B2 (en) 2009-01-28 2012-12-25 Headwater Partners I, Llc Enhanced roaming services and converged carrier networks with device assisted services and a proxy
US8832777B2 (en) 2009-03-02 2014-09-09 Headwater Partners I Llc Adapting network policies based on device service processor configuration
US8964788B2 (en) * 2008-06-05 2015-02-24 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8402111B2 (en) 2009-01-28 2013-03-19 Headwater Partners I, Llc Device assisted services install
US8391834B2 (en) 2009-01-28 2013-03-05 Headwater Partners I Llc Security techniques for device assisted services
US8635335B2 (en) 2009-01-28 2014-01-21 Headwater Partners I Llc System and method for wireless network offloading
US8825480B2 (en) * 2008-06-05 2014-09-02 Qualcomm Incorporated Apparatus and method of obtaining non-speech data embedded in vocoder packet
US8589541B2 (en) 2009-01-28 2013-11-19 Headwater Partners I Llc Device-assisted services for protecting network capacity
US8406748B2 (en) 2009-01-28 2013-03-26 Headwater Partners I Llc Adaptive ambient services
US8958441B2 (en) * 2008-06-05 2015-02-17 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8548428B2 (en) 2009-01-28 2013-10-01 Headwater Partners I Llc Device group partitions and settlement platform
US8250207B2 (en) 2009-01-28 2012-08-21 Headwater Partners I, Llc Network based ambient services
US8725123B2 (en) 2008-06-05 2014-05-13 Headwater Partners I Llc Communications device with secure data path processing agents
US8898293B2 (en) 2009-01-28 2014-11-25 Headwater Partners I Llc Service offer set publishing to device agent with on-device service selection
US8626115B2 (en) 2009-01-28 2014-01-07 Headwater Partners I Llc Wireless network service interfaces
US8346225B2 (en) 2009-01-28 2013-01-01 Headwater Partners I, Llc Quality of service for device assisted services
US8503517B2 (en) * 2008-06-05 2013-08-06 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8275830B2 (en) 2009-01-28 2012-09-25 Headwater Partners I Llc Device assisted CDR creation, aggregation, mediation and billing
US9083521B2 (en) * 2008-06-05 2015-07-14 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8924543B2 (en) 2009-01-28 2014-12-30 Headwater Partners I Llc Service design center for device assisted services
US8924469B2 (en) 2008-12-18 2014-12-30 Headwater Partners I Llc Enterprise access control and accounting allocation for access networks
US8725502B2 (en) * 2008-06-05 2014-05-13 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8516121B1 (en) * 2008-06-30 2013-08-20 Symantec Corporation Method and apparatus for optimizing computer network usage to prevent congestion
WO2010017205A2 (en) * 2008-08-04 2010-02-11 Jeffrey Harrang Systems and methods for video bookmarking
CN101646205B (zh) * 2008-08-05 2014-07-09 华为技术有限公司 移动网络高速接入公网的节点、方法及系统
WO2010017308A1 (en) * 2008-08-06 2010-02-11 Movik Networks Content caching in the radio access network (ran)
US8055286B1 (en) * 2008-08-27 2011-11-08 Sprint Spectrum L.P. Modification of en-route message to add destination port number selected based at least in part on message originator
US8059559B2 (en) 2008-09-09 2011-11-15 Embarq Holdings Company, Llc System and method for monitoring bandwidth utilization by a user
WO2010033750A2 (en) * 2008-09-18 2010-03-25 Jeffrey Harrang Systems and methods for automatic detection and coordinated delivery of burdensome media content
US8488596B2 (en) 2008-11-03 2013-07-16 At&T Intellectual Property I, L.P. Method and apparatus for sharing a single data channel for multiple signaling flows destined to multiple core networks
KR20110082192A (ko) * 2008-11-07 2011-07-18 오팡가 네트웍스, 인크. 호스트 디바이스들을 이용하여 데이터 전송들을 개시하는 휴대용 데이터 스토리지 디바이스들
WO2010068497A2 (en) * 2008-11-25 2010-06-17 Jeffrey Harrang Viral distribution of digital media content over social networks
WO2010075426A1 (en) * 2008-12-23 2010-07-01 Movik Networks Transparent interaction with multi-layer protocols via selective bridging and proxying
US11973804B2 (en) 2009-01-28 2024-04-30 Headwater Research Llc Network service plan design
US9578182B2 (en) 2009-01-28 2017-02-21 Headwater Partners I Llc Mobile device and service management
US10200541B2 (en) 2009-01-28 2019-02-05 Headwater Research Llc Wireless end-user device with divided user space/kernel space traffic policy system
US10264138B2 (en) 2009-01-28 2019-04-16 Headwater Research Llc Mobile device and service management
US10492102B2 (en) 2009-01-28 2019-11-26 Headwater Research Llc Intermediate networking devices
US9565707B2 (en) 2009-01-28 2017-02-07 Headwater Partners I Llc Wireless end-user device with wireless data attribution to multiple personas
US9955332B2 (en) 2009-01-28 2018-04-24 Headwater Research Llc Method for child wireless device activation to subscriber account of a master wireless device
US12543031B2 (en) 2009-01-28 2026-02-03 Headwater Research Llc Adapting network policies based on device service processor configuration
US10057775B2 (en) 2009-01-28 2018-08-21 Headwater Research Llc Virtualized policy and charging system
US8745191B2 (en) 2009-01-28 2014-06-03 Headwater Partners I Llc System and method for providing user notifications
US9954975B2 (en) 2009-01-28 2018-04-24 Headwater Research Llc Enhanced curfew and protection associated with a device group
US12389218B2 (en) 2009-01-28 2025-08-12 Headwater Research Llc Service selection set publishing to device agent with on-device service selection
US10779177B2 (en) 2009-01-28 2020-09-15 Headwater Research Llc Device group partitions and settlement platform
US9572019B2 (en) 2009-01-28 2017-02-14 Headwater Partners LLC Service selection set published to device agent with on-device service selection
US12432130B2 (en) 2009-01-28 2025-09-30 Headwater Research Llc Flow tagging for service policy implementation
US10798252B2 (en) 2009-01-28 2020-10-06 Headwater Research Llc System and method for providing user notifications
US12452377B2 (en) 2009-01-28 2025-10-21 Headwater Research Llc Service design center for device assisted services
US10484858B2 (en) 2009-01-28 2019-11-19 Headwater Research Llc Enhanced roaming services and converged carrier networks with device assisted services and a proxy
US9647918B2 (en) 2009-01-28 2017-05-09 Headwater Research Llc Mobile device and method attributing media services network usage to requesting application
US9557889B2 (en) 2009-01-28 2017-01-31 Headwater Partners I Llc Service plan design, user interfaces, application programming interfaces, and device management
US10841839B2 (en) 2009-01-28 2020-11-17 Headwater Research Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US10783581B2 (en) 2009-01-28 2020-09-22 Headwater Research Llc Wireless end-user device providing ambient or sponsored services
US9253663B2 (en) 2009-01-28 2016-02-02 Headwater Partners I Llc Controlling mobile device communications on a roaming network based on device state
US8793758B2 (en) 2009-01-28 2014-07-29 Headwater Partners I Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US11985155B2 (en) 2009-01-28 2024-05-14 Headwater Research Llc Communications device with secure data path processing agents
US12388810B2 (en) 2009-01-28 2025-08-12 Headwater Research Llc End user device that secures an association of application to service policy with an application certificate check
US8893009B2 (en) 2009-01-28 2014-11-18 Headwater Partners I Llc End user device that secures an association of application to service policy with an application certificate check
US10064055B2 (en) 2009-01-28 2018-08-28 Headwater Research Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US9392462B2 (en) 2009-01-28 2016-07-12 Headwater Partners I Llc Mobile end-user device with agent limiting wireless data communication for specified background applications based on a stored policy
US10326800B2 (en) 2009-01-28 2019-06-18 Headwater Research Llc Wireless network service interfaces
US9270559B2 (en) 2009-01-28 2016-02-23 Headwater Partners I Llc Service policy implementation for an end-user device having a control application or a proxy agent for routing an application traffic flow
US10715342B2 (en) 2009-01-28 2020-07-14 Headwater Research Llc Managing service user discovery and service launch object placement on a device
US10237757B2 (en) 2009-01-28 2019-03-19 Headwater Research Llc System and method for wireless network offloading
US11218854B2 (en) 2009-01-28 2022-01-04 Headwater Research Llc Service plan design, user interfaces, application programming interfaces, and device management
US9755842B2 (en) 2009-01-28 2017-09-05 Headwater Research Llc Managing service user discovery and service launch object placement on a device
US9706061B2 (en) 2009-01-28 2017-07-11 Headwater Partners I Llc Service design center for device assisted services
US10248996B2 (en) 2009-01-28 2019-04-02 Headwater Research Llc Method for operating a wireless end-user device mobile payment agent
US12166596B2 (en) 2009-01-28 2024-12-10 Disney Enterprises, Inc. Device-assisted services for protecting network capacity
US9980146B2 (en) 2009-01-28 2018-05-22 Headwater Research Llc Communications device with secure data path processing agents
US9351193B2 (en) 2009-01-28 2016-05-24 Headwater Partners I Llc Intermediate networking devices
US9858559B2 (en) 2009-01-28 2018-01-02 Headwater Research Llc Network service plan design
EP2391953A4 (en) * 2009-01-30 2012-08-08 Movik Networks APPLICATION, USE AND WIRELESS CONNECTING TRANSPORT NETWORK PLANNER
JP2010178867A (ja) * 2009-02-05 2010-08-19 Fujifilm Corp 放射線撮影用ネットワークシステム及び放射線画像撮影システム制御方法
US8537699B2 (en) 2009-06-16 2013-09-17 Qualcomm Incorporated Managing video adaptation algorithms
US8743864B2 (en) * 2009-06-16 2014-06-03 Qualcomm Incorporated System and method for supporting higher-layer protocol messaging in an in-band modem
US8705361B2 (en) * 2009-06-16 2014-04-22 Tellabs Operations, Inc. Method and apparatus for traffic management in a wireless network
US8855100B2 (en) * 2009-06-16 2014-10-07 Qualcomm Incorporated System and method for supporting higher-layer protocol messaging in an in-band modem
EP2457401B1 (en) * 2009-07-21 2014-09-10 T-Mobile Austria GmbH Method, system and base station for enhanced communication efficiency
EP2468067A4 (en) 2009-08-19 2015-09-09 Opanga Networks Inc OPTIMIZING MEDIA CONTENT BASED ON RESOURCE METHODS DEFINED BY A USER DEVICE
US8886790B2 (en) * 2009-08-19 2014-11-11 Opanga Networks, Inc. Systems and methods for optimizing channel resources by coordinating data transfers based on data type and traffic
EP2468019A4 (en) * 2009-08-20 2013-10-23 Opanga Networks Inc BROADCASTING CONTENTS OF CONVERTIBLE NETWORK CAPACITIES
WO2011044287A1 (en) * 2009-10-06 2011-04-14 Openwave Systems Inc. Managing network traffic by editing a manifest file and/or using intermediate flow control
CN102598642A (zh) * 2009-11-04 2012-07-18 日本电气株式会社 网关装置、便携终端、便携通信方法以及程序
US8755405B2 (en) 2009-11-09 2014-06-17 Movik Networks, Inc. Burst packet scheduler for improved ran efficiency in UMTS/HSPA networks
US8351948B2 (en) * 2010-03-01 2013-01-08 Nec Laboratories America, Inc. Method and system for customizable flow management in a cellular basestation
CN102196513B (zh) * 2010-03-11 2014-02-26 阿尔卡特朗讯 用于确定业务网关接入的业务速率的方法和设备
WO2011115965A1 (en) * 2010-03-15 2011-09-22 Movik Networks Adaptive chunked and content-aware pacing of multi-media delivery over http transport and network controlled bit rate selection
US8495196B2 (en) 2010-03-22 2013-07-23 Opanga Networks, Inc. Systems and methods for aligning media content delivery sessions with historical network usage
US9445215B2 (en) 2010-04-21 2016-09-13 Telefonaktiebolaget Lm Ericsson (Publ) MTC device bandwidth reduction
EP2408152B1 (en) * 2010-07-16 2013-11-27 BlackBerry Limited Methods and apparatus for use in communicating data packets within a data packet window having a size that is set based on quality of service (qos) parameters
US8477618B2 (en) 2010-07-16 2013-07-02 Research In Motion Limited Methods and apparatus for use in communicating data packets within a data packet window having a size that is set based on quality of service (QoS) parameters
US8799480B2 (en) 2010-07-19 2014-08-05 Movik Networks Content pre-fetching and CDN assist methods in a wireless mobile network
WO2012040608A2 (en) * 2010-09-24 2012-03-29 Movik Networks Destination learning and mobility detection in transit network device in lte & umts radio access networks
KR101539155B1 (ko) * 2010-10-27 2015-07-23 인터디지탈 패튼 홀딩스, 인크 진보형 애플리케이션 인터페이스의 조정가능한 정책 제어형 패킷 검사 시스템 및 방법
ES2411082T3 (es) * 2010-11-02 2013-07-04 Telefónica O2 Germany GmbH & Co. OHG Un aparato para controlar el tráfico de datos y un método para medir QoE
US9451049B2 (en) * 2010-12-13 2016-09-20 Google Technology Holdings LLC Sharing media among remote access clients in a universal plug and play environment
EP2679073A4 (en) * 2011-02-25 2016-10-19 Ericsson Telefon Ab L M IP COMMUNICATION AUTHORIZATION WITH A MACHINE MACHINE DEVICE
US9154826B2 (en) 2011-04-06 2015-10-06 Headwater Partners Ii Llc Distributing content and service launch objects to mobile devices
US20130051253A1 (en) * 2011-08-23 2013-02-28 James M. Lin Method and apparatus for improving user experience via payload adaptation
US8630307B2 (en) 2011-09-13 2014-01-14 Qualcomm Incorporated Methods and apparatus for traffic contention resource allocation
US10292066B2 (en) * 2011-11-04 2019-05-14 Cisco Technology, Inc. System and method of modifying congestion control based on mobile system information
CN103248451B (zh) * 2012-02-09 2016-12-07 华为技术有限公司 业务速率控制方法和系统以及设备
US8972568B2 (en) * 2012-02-21 2015-03-03 Telefonaktiebolaget L M Ericsson (Publ) Quantifying user quality of experience by passive monitoring
WO2013125994A1 (en) * 2012-02-22 2013-08-29 Telefonaktiebolaget L M Ericsson (Publ) Measurement based qos adaptation
CN103582029B (zh) * 2012-07-24 2018-05-18 华为技术有限公司 策略控制方法及设备
US9276967B2 (en) * 2012-07-27 2016-03-01 Centurylink Intellectual Property Llc System and method for determining optimal bandwidth for streaming to a client device in an adjustable bit rate video system
US9591513B2 (en) * 2012-08-06 2017-03-07 Vid Scale, Inc. Rate adaptation using network signaling
CN103702364B (zh) * 2012-09-27 2017-08-25 华为技术有限公司 一种业务数据传输的方法、设备及系统
US20140281018A1 (en) * 2013-03-13 2014-09-18 Futurewei Technologies, Inc. Dynamic Optimization of TCP Connections
WO2014159862A1 (en) 2013-03-14 2014-10-02 Headwater Partners I Llc Automated credential porting for mobile devices
KR102077740B1 (ko) * 2013-03-18 2020-02-14 삼성전자주식회사 기지국과의 통신을 위한 자원을 할당하는 방법 및 단말
US20150112767A1 (en) * 2013-10-17 2015-04-23 Cisco Technology, Inc. System and method for using network mobility events to build advertising demographics
US9237467B2 (en) 2013-11-27 2016-01-12 At&T Intellectual Property I, L.P. Adaptive pacing of media content delivery over a wireless network
US20160380898A1 (en) 2013-11-27 2016-12-29 Telefonaktiebolaget Lm Ericsson (Publ) Controlling a transmission control protocol window size
US11695847B2 (en) 2014-08-14 2023-07-04 Nokia Solutions And Networks Oy Throughput guidance based on user plane insight
US10367738B2 (en) * 2014-08-14 2019-07-30 Nokia Solutions And Networks Oy Throughput guidance based on user plane insight
EP3198823A1 (en) * 2014-09-22 2017-08-02 Nokia Solutions and Networks Oy Mute call detection in a communication network system
CN104618967B (zh) * 2015-01-30 2018-06-05 上海华为技术有限公司 一种通信方法、相关装置和系统
JP6717008B2 (ja) * 2016-03-31 2020-07-01 富士通株式会社 情報生成プログラム、情報生成方法及び情報生成装置
WO2018077426A1 (en) * 2016-10-28 2018-05-03 Telefonaktiebolaget Lm Ericsson (Publ) Handling of data packet transfer via a proxy
US10986000B2 (en) * 2017-05-07 2021-04-20 Qualcomm Incorporated Enabling new radio cellular quality of service for non-internet protocol data sessions
EP3656166B1 (en) * 2017-08-10 2024-07-17 Sony Group Corporation Wireless communications system, communications device and wireless network infrastructure
WO2019095295A1 (zh) * 2017-11-17 2019-05-23 Oppo广东移动通信有限公司 用于传输数据的方法、终端设备和会话管理功能smf设备
US11632810B2 (en) * 2018-02-28 2023-04-18 Nokia Technologies Oy Transparent integration of 3GPP network into TSN based industrial network
US11350268B2 (en) * 2018-05-18 2022-05-31 Qualcomm Incorporated End-to-end rate adaptation using RAN assisted rate adaptation
CN116033596B (zh) * 2018-07-18 2025-06-03 北京小米松果电子有限公司 点对点通信方法、装置、存储介质及电子设备
US11395242B2 (en) 2019-02-01 2022-07-19 Cisco Technology, Inc. Link establishment between a radio equipment controller (REC) and radio equipment (RE) in a fronthaul network
CN112152934A (zh) * 2019-07-25 2020-12-29 北京天德科技有限公司 显式反馈数据流控制
US11089078B2 (en) * 2019-09-13 2021-08-10 Microsoft Technology Licensing, Llc Model-based parameter selection for media sessions
CN110996298A (zh) * 2019-12-25 2020-04-10 北京汽车集团越野车有限公司 一种通信速率调整系统及汽车

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5115429A (en) * 1990-08-02 1992-05-19 Codex Corporation Dynamic encoding rate control minimizes traffic congestion in a packet network
ZA946674B (en) * 1993-09-08 1995-05-02 Qualcomm Inc Method and apparatus for determining the transmission data rate in a multi-user communication system
US6252851B1 (en) * 1997-03-27 2001-06-26 Massachusetts Institute Of Technology Method for regulating TCP flow over heterogeneous networks
EP0948168A1 (en) * 1998-03-31 1999-10-06 TELEFONAKTIEBOLAGET L M ERICSSON (publ) Method and device for data flow control
FI107220B (fi) * 1998-11-06 2001-06-15 Nokia Networks Oy Menetelmä kantajien ominaisuuksien hallitsemiseksi
FI108767B (fi) * 1999-02-24 2002-03-15 Ericsson Telefon Ab L M Puhelunmuodostus tietoliikennejärjestelmässä
US6687226B1 (en) * 1999-04-01 2004-02-03 Telefonaktiebolaget Lm Ericsson (Publ) Base station subsystem and method for handling an increase in traffic volume that overloads a terrestrial link in an internet protocol network
US6473442B1 (en) * 1999-04-12 2002-10-29 Telefonaktiebolaget Lm Ericsson (Publ) Communications system and method for matching and balancing the bit rates of transport channels to the bit rate of a physical channel
CN101489319B (zh) * 2000-02-22 2012-02-22 北方电讯网络有限公司 控制无线分组交换语音呼叫的系统及方法
FI20002848A7 (fi) * 2000-12-22 2002-06-23 Nokia Corp Vuon valvonta tietoliikenneverkossa
US7142508B2 (en) * 2000-12-22 2006-11-28 Radiance Technologies, Inc. System and method for controlling data transfer rates on a network
US7444418B2 (en) * 2001-05-11 2008-10-28 Bytemobile, Inc. Transcoding multimedia information within a network communication system
US20030095510A1 (en) * 2001-11-16 2003-05-22 Motorola, Inc. Use and management of groups defined according to a call initiation protocol
FI116498B (fi) * 2002-09-23 2005-11-30 Nokia Corp Kaistanleveyden mukauttaminen
SE0203056D0 (sv) * 2002-10-11 2002-10-11 Ericsson Telefon Ab L M Method and apparatus in a telecommunication system
US7047310B2 (en) * 2003-02-25 2006-05-16 Motorola, Inc. Flow control in a packet data communication system

Also Published As

Publication number Publication date
ATE484134T1 (de) 2010-10-15
AU2003276592A1 (en) 2004-11-01
EP2099179B1 (en) 2010-10-06
CN101516110A (zh) 2009-08-26
EP1614258B1 (en) 2012-08-01
WO2004091151A1 (en) 2004-10-21
US20070025301A1 (en) 2007-02-01
DE60334508D1 (de) 2010-11-18
EP1614258A1 (en) 2006-01-11
CN1774890B (zh) 2010-05-26
CN1774890A (zh) 2006-05-17
CN101516110B (zh) 2011-01-26
SE0301053D0 (sv) 2003-04-07
EP2099179A1 (en) 2009-09-09

Similar Documents

Publication Publication Date Title
EP1614258B1 (en) Method and system for rate control service in a network
US11595300B2 (en) Traffic shaping and end-to-end prioritization
US9930123B2 (en) Method and apparatus for initiating and maintaining sessions between endpoints
EP3100517B1 (en) Systems, devices and computer-readable medium for application specific routing in dual connectivity
ES2442892T3 (es) Traspaso de conmutación de paquetes en un sistema de comunicación móvil, durante el que un nodo móvil recibe paquetes desde un nodo de origen y un nodo de destino
ES2230340T3 (es) Asignacion de recursos de transmision de datos en una transmision de datos conmutada por paquetes.
US10075987B2 (en) Multipath TCP subflow establishing on single IP connection
US20040246962A1 (en) Dynamically assignable resource class system to directly map 3GPP subscriber communications to a MPLS-based protocol
US20100299446A1 (en) Method and apparatus for controlling service data flows transmitted in a tunnel
US7221657B2 (en) Processing different size packet headers for a packet-based conversational service in a mobile communications system
WO2018167254A1 (en) Unique qos marking ranges for smfs in a 5g communications network
KR20050026056A (ko) 시그널링 및 데이터 트래픽 채널을 통한 패킷 데이터유닛의 통신
CN107810647B (zh) 在服务客户端和ran之间建立交互会话
KR102219625B1 (ko) 인터넷 프로토콜(ｉｐ) 흐름 이동성을 위한 장치 및 방법
US10897451B2 (en) System and method for transmitting over multiple simultaneous communication networks by using point-to-point protocol over ethernet
EP3314974B1 (en) Setting up a dedicated bearer in a radio communication network
US20050073953A1 (en) Quality of service in communication systems
US10939330B2 (en) Establishing an interaction session on a bearer in a radio communication network
Yang et al. A multi-link mechanism for heterogeneous radio networks
WO2025151903A1 (en) Differentiated handling for uplink encrypted xrm traffic
KR20080102367A (ko) 보편적 이동성 및 무선 인식 전송용 종단간 아키텍쳐
CN121441848A (zh) 一种流量控制方法、装置和系统