ES2675198T3 - Método y sistema para detección de congestión cooperativa en redes celulares - Google Patents

Método y sistema para detección de congestión cooperativa en redes celulares Download PDF

Info

Publication number
ES2675198T3
ES2675198T3 ES13848380.5T ES13848380T ES2675198T3 ES 2675198 T3 ES2675198 T3 ES 2675198T3 ES 13848380 T ES13848380 T ES 13848380T ES 2675198 T3 ES2675198 T3 ES 2675198T3
Authority
ES
Spain
Prior art keywords
mobile terminal
network
congestion
congestion information
link
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.)
Active
Application number
ES13848380.5T
Other languages
English (en)
Inventor
Jeffrey P. Harrang
David Gibbons
John M. Burnette
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.)
Opanga Networks LLC
Original Assignee
Opanga Networks LLC
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 Opanga Networks LLC filed Critical Opanga Networks LLC
Application granted granted Critical
Publication of ES2675198T3 publication Critical patent/ES2675198T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • 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/0284—Traffic management, e.g. flow control or congestion control detecting congestion or overload during communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • 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/11—Identifying congestion

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un sistema en red, que comprende: un sistema de envío que tiene un procesador y una memoria, primer y segundo terminales móviles, teniendo cada terminal móvil un procesador y una memoria; y una red de comunicación que tiene una pluralidad de recursos de red que acopla el sistema de envío y el primer y segundo terminales móviles, compartiendo el primer y segundo terminales móviles un enlace en la red de comunicación; y en el que el sistema de envío está configurado para enviar un primer segmento de fichero al primer terminal móvil, siendo el primer segmento de fichero una porción de un primer fichero de datos que se transmite al primer terminal móvil, en el que el primer terminal móvil está configurado para determinar primera información de congestión de la red de comunicación basándose en una transferencia del primer segmento de fichero, para determinar una primera política de transferencia basándose en la primera información de congestión, y para comunicar la primera información de congestión al segundo terminal móvil, en el que el segundo terminal móvil está configurado para ajustar una solicitud de ancho de banda al sistema de envío basándose en la primera información de congestión, en el que la primera información de congestión proporciona mediciones de entrega de datos de caudal a través de uno o más segmentos de red o mediciones de rendimiento de caudal de enlace de extremo a extremo para segmentos de red combinados, o ambas, y en el que la primera política de transferencia proporciona una tasa de entrega promedio permitida máxima para el primer terminal móvil basándose en la primera información de congestión determinada por el primer terminal móvil.

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Método y sistema para detección de congestión cooperativa en redes celulares Antecedentes
Las realizaciones se refieren al campo de redes informáticas y comunicaciones a través de redes informáticas, incluyendo comunicaciones a través de las redes inalámbricas.
Muchas redes informáticas en existencia hoy en día se comunican a través de la transferencia de datos. Algunos ejemplos incluyen redes que pueden funcionar independientemente (por ejemplo, como Redes de Área Local o LAN) o de manera colectiva como parte de un grupo de redes interconectadas (por ejemplo, Redes de Área Extensa o WAN), tal como la Red Informática Mundial. Algunas de estas redes incluyen tecnologías que facilitan transmisiones de alta transferencia de datos relativamente rápidas (por ejemplo, redes alámbricas, de fibra óptica, cable y de Línea Digital de Abonado). Otras facilitan transmisiones de tasas de datos más lentas (por ejemplo, redes celulares 3G).
Los servicios de banda amplia móviles se están haciendo muy habituales en la sociedad moderna. Estos servicios pueden proporcionar una manera para que los individuos que tienen dispositivos de comunicaciones inalámbricas (por ejemplo, un teléfono celular o tableta) permanezcan conectados a la Internet mientras operan en y realizan itinerancia entre diversas áreas de cobertura inalámbrica. Una tendencia concurrente es el enorme aumento en aplicaciones y servicios de distribución de contenido de medios que facilitan la entrega de grandes ficheros de contenido de medios pesados a o desde equipo de usuario. Las transferencias de fichero de contenido de medios grandes tienen la característica distintiva de consumir cantidades significativas de recursos de red (por ejemplo, ancho de banda de canal) a través de periodos de tiempo extendidos. Los métodos para posibilitar y hacer esta entrega de tipo de datos particular más eficaz son importantes para tanto los usuarios finales como los proveedores de servicio. Los procesos que facilitan entrega de contenido de medios más eficaz son particularmente relevantes para redes inalámbricas que tienen recursos de ancho de banda limitados.
La mayoría de las redes inalámbricas operan usando canales de comunicaciones compartidas donde las solicitudes contrapuestas concurrentes para acceso de canal son comunes. En estas redes, las transferencias de datos pueden reducirse o degradarse durante periodos de congestión de canal de red. La congestión puede tener lugar si la demanda de recursos de ancho de banda para un canal compartido se acerca o supera la capacidad del canal. Bajo estas circunstancias, los usuarios activos del canal compartido pueden entrar en conflicto a medida que cada usuario intenta completar caudales de datos individuales. Para resolver este problema, los usuarios pueden revisar sus solicitudes de modo que el canal de red compartido pueda entregar satisfactoriamente todas las solicitudes de una manera oportuna. Por ejemplo, en una estrategia bien conocida, los usuarios reducen su tráfico individual usando una política de compartición equitativa. Existen muchos otros esquemas de priorización, pero en métodos existentes los usuarios del recurso de red compartido congestionado deben tener conocimiento primero de que la congestión está presente antes de que los usuarios puedan tomar la acción correctiva para mitigar la congestión.
El tener conocimiento de la congestión por un usuario de un canal compartido o enlace puede conseguirse en una diversidad de maneras. En un ejemplo, los terminales de usuario final podrían operar individualmente protocolos de datos de paquetes con un mecanismo de detección de congestión y desarrollar métricas de congestión. Por ejemplo, un protocolo de datos de paquetes de capa de transporte es el protocolo de control de transporte (TCP). TCP también se conoce por nombres de sus muchas variantes de implementación tales como TCP-Reno, TCP-Vegas y CUBIC. Existen otros protocolos de datos de paquetes con capacidad de detección de congestión tales como SCTP. Al usar TCP u otros protocolos similares, los terminales de envío y recepción interconectados por una red típicamente realizan mediciones periódicas de la red transportando datos a través de la red y midiendo rendimiento de entrega de los datos. Por lo tanto, las mediciones periódicas tomadas de acuerdo con estos protocolos también presentan una carga de tráfico a una red. Por consiguiente, si muchos terminales de usuario final intentan detectar la congestión de esta manera, la carga agregada al tráfico de red agrava cualquier congestión que pueda ya estar presente. Los pares de terminales de envío y recepción no comparten información de estado de congestión con otros terminales del canal compartido o enlace, o incluso con sesiones de datos de capa de transporte separadas que operan usando los mismos terminales de envío y recepción.
Adicionalmente, a menudo se asigna detección de congestión y control a capas de protocolo inferiores tales como TCP, mientras que las capas de protocolo de aplicación superior e interfaces de programación de aplicación típicamente no tienen acceso al estado de congestión de la red. Sin acceso a información de congestión, las capas de aplicación superiores y de programación de aplicación tienen difícilmente reaccionar ante o mitigar la congestión. A partir del documento US 2008/0102853 A1 es conocido un método de control de congestión en una red de comunicación móvil. El método incluye las etapas de reconocimiento de un estado de congestión por una unidad de control de estación base, y enviar un aviso acerca de información del estado de congestión a la unidad de control de estación base o una estación base o un terminal móvil que está en el estado de congestión, basándose en control realizado por la unidad de control de estación base, de modo que un usuario del terminal móvil puede reconocer el estado de congestión.
El documento US 2010/0274871 A1 muestra técnicas para medir congestión. En particular, se muestra un sistema y
5
10
15
20
25
30
35
40
45
50
55
60
65
método de entrega de fichero adaptativo que transmite un fichero de datos a través de una red en segmentos en los que cada segmento se transmite durante un periodo de tiempo diferente. Cada periodo de tiempo tiene una porción de transmisión y una porción de espera. Durante la duración de la porción de transmisión de cada periodo de tiempo se alcanza una condición de caudal de estado estable que permite que se determine el estado de carga de tráfico de la red a partir de mediciones de tasa de transmisiones de segmento de fichero.
A partir del documento EP 1 947 826 A1 es conocido un sistema y método de entrega de información de congestión de tráfico. En particular, el método describe que un teléfono celular mide el grado de congestión de las cercanías, lo transmite a su servidor principal como información de congestión, el servidor principal agrega la información de congestión y la proporciona a una localización específica solicitada por el solicitante.
Breve sumario de la invención
Las realizaciones se refieren al campo de redes informáticas y comunicaciones a través de redes informáticas, incluyendo comunicaciones a través de redes inalámbricas. En una realización, se determina información de congestión basándose en un segmento de fichero transferido a uno de los terminales de usuario. La información de congestión está disponible para un servidor o controlador comunicativamente enlazado con una pluralidad de terminales de usuario. La información de congestión se comparte con otros terminales de usuario que comparten un enlace de cuello de botella.
La presente invención se define en las reivindicaciones independientes adjuntas a las que debería hacerse referencia. Se exponen características ventajosas en las reivindicaciones dependientes adjuntas.
Breve descripción de los dibujos
La Figura 1 ilustra un sistema informático en red que incluye diversos dispositivos informáticos alámbricos e inalámbricos de acuerdo con algunas realizaciones.
La Figura 2 muestra una vista de diagrama de bloques de un dispositivo de proveedor de servicio de acuerdo con algunas realizaciones.
La Figura 3 muestra una vista de diagrama de bloques de un equipo de usuario de acuerdo con algunas realizaciones.
La Figura 4 es un diagrama esquemático de la pila de protocolo de comunicaciones de red de Interconexión de Sistemas Abiertos (OSI).
La Figura 5 ilustra una vista de alto nivel de un proceso de actualización de congestión en un entorno de red inalámbrica de acuerdo con una realización.
La Figura 6 ilustra un sistema informático en red de acuerdo con una realización.
La Figura 7 ilustra una realización que presenta un servidor y dos terminales.
La Figura 8 ilustra un sistema informático en red de acuerdo con una realización.
Descripción detallada de la invención
La Figura 1 ilustra un sistema informático en red 100 que incluye diversos dispositivos informáticos alámbricos e inalámbricos que pueden utilizarse para implementar cualquiera de los procesos de tráfico de red y monitorización de calidad de comunicaciones de radio u optimización de transferencia de contenido de datos asociados con diversas de las realizaciones de la presente invención. La configuración de red específica mostrada en la Figura 1 se pretende para proporcionar un ejemplo de un sistema informático de alto nivel que puede facilitar diversos procesos de comunicaciones de red de las realizaciones desveladas en el presente documento.
En una realización, el sistema informático en red 100 incluye un grupo de dispositivos de proveedor de servicio; una red de comunicaciones de datos 102; una diversidad de equipo de usuario remoto; uno o más dispositivos para facilitar comunicaciones de datos; y uno o más equipos de usuario locales. Además de los componentes anteriormente descritos, el sistema informático en red 100 puede incluir otros tipos de componentes de red de acuerdo con diversas implementaciones.
Un grupo de dispositivos de proveedor de servicio 110, 112, 114 y 116 (SPD) puede incluir ordenadores de servidor (por ejemplo, dispositivos de controlador de red) o cualquier otro dispositivo de red común, tal como encaminadores, pasarelas, o dispositivos de conmutación, que pueden soportar asignación de recursos de red y/o servicios de comunicaciones de datos digitales a diverso equipo de usuario (por ejemplo, cualquiera de los dispositivos terminal 108a-108c, 124, 126a-126c, 128, 130 y 132) en el sistema informático en red 100. Una red de comunicaciones de datos 102 incluye Red de Área Extensa (WAN), Redes de Área Local (LAN), y porciones de las mismas.
Una diversidad de equipo de usuario remoto puede incluir teléfono celular (o dispositivos móviles) 108a-108c junto con cualquier otra diversidad de dispositivos informáticos inalámbricos portátiles bien conocidos en la técnica (por ejemplo, teléfonos celulares, teléfonos inteligentes, tabletas, ordenadores, ordenadores portátiles, dispositivos de libro electrónico, unidades de juegos portátiles, reproductores de música personal, grabadores de vídeo, dispositivos WI-FI™, etc.). El equipo de usuario remoto puede conectarse a la red de comunicaciones de datos 102 utilizando una o más estaciones base inalámbricas 106a-106b, o cualquier otra tecnología de comunicaciones de red
5
10
15
20
25
30
35
40
45
50
55
60
65
inalámbrica o alámbrica común.
Una o más pasarelas de red, encaminadores, o dispositivos de conmutación 116 facilitan procesos de comunicaciones de datos, en las LAN, y entre las LAN y la WAN de la red de comunicaciones de datos 102.
Una o más pasarelas de red, encaminadores, o dispositivos de conmutación 116 facilitan procesos de comunicaciones de datos, en las LAN, y entre las LAN y la WAN de la red de comunicaciones de datos 102.
Uno o más equipos de usuario 108a-108c, 124, 126a-126c, 128, 130 y 132 pueden conectarse inalámbricamente a una o más estaciones base de red locales o remotas 106a-106b, 118, 120 y 122, u opcionalmente conectarse directa o indirectamente a una porción de enlace de retroceso de la red (por ejemplo, a la red de comunicaciones de datos 102) mediante cualquier tecnología de comunicaciones alámbricas o inalámbricas común. El equipo de usuario incluye ordenadores portátiles 124 y 128, dispositivos móviles inalámbricos (o teléfonos) 108a-108c, 126a- 126c, dispositivos de libro electrónico 130, unidades de juegos portátiles 132, reproductores de música personal, grabadores de vídeo, dispositivos Wi-Fi, o similares.
En una realización, cualquiera de los SPD 110, 112 y 114 (incluyendo cualquiera de las estaciones base de red 106a, 106b, 118, 120, y 122), el encaminador, pasarela, o dispositivo o dispositivos de conmutación 116, o cualquiera del equipo de usuario remoto o local 108a-108c, 124, 126a-126c, 128, 130 y 132, puede estar configurado para ejecutar cualquier sistema operativo conocido, incluyendo pero sin limitación, MICROSOFT®, WINDOWS ®, MAC OS®, LINUX®, UNIX®, GOOGLE® CHROME®, o cualquier sistema operativo móvil común, incluyendo APPLE IOS®, WINDOWS® MOBILE®, MOBILE LINUX®, GOOGLE® ANDROID®, etc.
En una realización, cualquiera de los SPD 106a, 106b, 110, 112, 114, 116, 118, 120 y 122 puede emplear cualquier número de dispositivos informáticos de servidor, sobremesa, portátil y personal comunes. En una realización, el equipo de usuario 108a-108c, 124, 126a-126c, 128, 130, y 132 puede incluir cualquier combinación de dispositivos informáticos móviles comunes (por ejemplo, ordenadores portátiles, ordenadores portables, teléfonos celulares, PDA, unidades de juegos portátiles, dispositivos de libro electrónico, reproductores de música personal, grabadores de vídeo, etc.), que tienen capacidades de comunicaciones inalámbricas que emplean cualquier tecnología de datos inalámbrica común, incluyendo, pero sin limitación: WI-FI™, WIMAX™, GSM™, UMTS™, LTE™, LTE Avanzada™, etc.
En una realización, las LAN o las porciones de WAN de la red de comunicaciones de datos 102 pueden emplear cualquiera de las siguientes tecnologías de comunicaciones comunes: fibra óptica, cable coaxial, cable de par trenzado, cable de Ethernet, y cable por línea eléctrica, junto con cualquier tecnología de comunicación inalámbrica conocida en la técnica. En una realización, cualquiera de los SPD 110, 112, y 114, incluyendo cualquiera de las estaciones base de red 106a, 106b, 118, 120, y 122, el encaminador, pasarela, dispositivo o dispositivos de conmutación 116, o cualquiera del equipo de usuario remoto o local 108a-108c, 124, 126a-126c, 128, 130, y 132, puede incluir cualquier software y hardware informático convencional necesario para procesar, almacenar y comunicar datos entre sí en el sistema informático en red 100. El hardware informático realizado en cualquiera de los dispositivos informáticos 106a, 106b, 108a-108c, 110, 112, 114, 116, 118, 120, 122, 124, 126a-126c, 128, 130 y 132 del sistema informático en red de datos 100 puede incluir uno o más procesadores, memorias volátiles y no volátiles, interfaces de usuario, transcodificadores, y transceptores de comunicaciones alámbricas y/o inalámbricas, etc.
En una realización, cualquiera de los SPD 110, 112, y 114 (incluyendo cualquiera de las estaciones base de red 106a, 106b, 118, 120, y 122), el encaminador, pasarela, dispositivo o dispositivos de conmutación 116, o cualquiera del equipo de usuario remoto o local 108a-108c, 124, 126a-126c, 128, 130 y 132, puede estar configurado para incluir uno o más medios legibles por ordenador (por ejemplo, cualquier tipo de memoria volátil o no volátil común) codificados con un conjunto de instrucciones legibles por ordenador, que cuando se ejecutan, realizan una porción de uno o más de los procesos de tráfico de red y monitorización de calidad de comunicaciones de radio o de optimización de transferencia de contenido de datos asociados con diversas realizaciones descritas en el presente documento.
La Figura 2 muestra una vista de diagrama de bloques de un SPD 200 que puede ser representativa de cualquiera de los dispositivos de proveedor de servicio SPD remotos 110, 112 y 114 (incluyendo las estaciones base de red 106a, 106b, 118, 120 y 122), y el encaminador, pasarela, dispositivo o dispositivos de conmutación 116 de la Figura 1, o cualquier otro proveedor de servicio de red común conocido en la técnica. El SPD 200 puede incluir, pero sin limitación, uno o más dispositivos de procesador incluyendo una unidad de procesamiento central (CPU) 204. En una realización, la CPU 204 puede incluir una unidad de lógica aritmética (ALU, no mostrada) que realiza operaciones aritméticas y lógicas y una o más unidades de control (CU, no mostradas) que extraen instrucciones y contenido almacenado de memoria y a continuación las ejecuta y/o procesa, solicitando a la ALU cuando sea necesario durante la ejecución de programa. La CPU 204 ejecuta programas informáticos almacenados en las memorias de sistema volátiles (RAM) y no volátiles (ROM), 202 y 208 del SPD.
El SPD 200 puede incluir también una interfaz de usuario 206 opcional que permite que un administrador de proveedor de servicio interactúe con los recursos de software y hardware del dispositivo; un repositorio de
5
10
15
20
25
30
35
40
45
50
55
60
65
software/base de datos 208; un transceptor 220 para transmitir y recibir comunicaciones de datos de red entre diverso equipo de usuario de red (por ejemplo, cualquiera de los dispositivos 108a-108c, 124, 126a-126c, 128, 130, y 132) y el SPD (por ejemplo, cualquiera de los SPD 106a, 106b, 110, 112, 114, 118, 120, 122 y 116) utilizando la red de comunicación de datos 102 del sistema informático en red 100; un transcodificador 218 para transmitir comunicaciones de datos antes de la transferencia; y un bus de sistema 222 que facilita comunicaciones de datos entre todos los recursos de hardware del SPD 200.
El repositorio de software/base de datos 208 del SPD 200 puede incluir un agente de transferencia de datos 210 (también denominado en el presente documento como un agente de regulación adaptativa o ATA) que puede facilitar el ajuste en tiempo real de tasas de transferencia de datos basándose en comparaciones de caudal de enlace máximo a caudal de enlace real recibido desde uno o más equipos de usuario (como una realimentación) o desde un monitor de capacidad de enlace local o externo. El repositorio de software/base de datos 208 de SPD 200 puede incluir también un generador de perfiles de enlace 214 que puede determinar una capacidad de caudal actual para una serie de enlaces de red entre un emisor y un receptor, y una base de datos de perfiles de dispositivo de abonado 216 que puede almacenar información de perfil de equipo de usuario y de recursos agotables residentes (información que pertenece a alimentación de batería, uso de procesador, memoria disponible, etc.). Adicionalmente, el repositorio de software/base de datos 208 de SPD 200 puede incluir un monitor de enlace de red 212 opcional que puede monitorizar el caudal de enlace real para enlaces de red de interés particulares (también denominado en el presente documento como un agente de detección de capacidad de enlace o LCSA).
De acuerdo con una realización de la presente invención, el agente de transferencia de datos 210 del SPD 200 puede enlazarse lógicamente al generador de perfiles de enlace 214 y al monitor de enlace de red 212 opcional (o como alternativa a un componente de monitor de enlace de red externo 312 del equipo de usuario 300), de manera que las transferencias de datos entre un dispositivo emisor y receptor (por ejemplo, entre un SPD 200 o un proveedor de contenido de medios, y un equipo de usuario 300) pueden gestionarse de manera óptima (por ejemplo, regulando una tasa de transferencia de datos o seleccionando periodos preferidos para entrega de contenido de datos) basándose en evaluaciones de tiempo reales de tráfico de red para enlaces de comunicaciones que son parte de la ruta de comunicaciones entre (e incluyendo opcionalmente) los dispositivos de envío y recepción.
La Figura 3 muestra una vista de diagrama de bloques de un equipo de usuario 300 que puede ser representativa de cualquiera de los terminales de equipo de usuario 108a-108c, 124, 126a-126c, 128, 130 y 132 en la Figura 1. El equipo de usuario 300 puede incluir, pero sin limitación, uno o más dispositivos de procesador incluyendo una unidad de procesamiento central (CPU) 304. En una realización, la CPU 304 puede incluir también una unidad de lógica aritmética (ALU, no mostrada) que realiza operaciones aritméticas y lógicas y una o más unidades de control (CU, no mostradas) que extraen instrucciones y contenido almacenado de la memoria y a continuación las ejecutan y/o procesan, solicitando la ALU cuando sea necesario durante ejecución de programa. La CPU 304 es responsable de ejecutar todos los programas informáticos almacenados en las memorias de sistema volátil (RAM) y no volátil (ROM), 302 y 308 del equipo de usuario 300.
El equipo de usuario 300 puede incluir también, pero sin limitación, una interfaz de usuario 306 que permite que un usuario interactúe con sus recursos de software y hardware; un repositorio de software/base de datos 308; un transcodificador 318 para formatear comunicaciones de datos antes de la transferencia; un transceptor 320 para transmitir y recibir comunicaciones de red entre otro equipo de usuario de red (por ejemplo, cualquiera de los equipos de usuario 108a-108c, 124, 126a-126c, 128, 130 y 132), proveedores de contenido de medios, y SPD (por ejemplo, cualquiera de los SPD 106a, 106b, 110, 112, 114, 116, 118, 120 y 122) utilizando la red de comunicación de datos 102 del sistema informático en red 100; y un bus de sistema 322 que facilita comunicaciones de datos entre todos los recursos de hardware del equipo de usuario 300.
El repositorio de software/base de datos 308 puede incluir un gestor de transferencia de datos 310 que facilita las comunicaciones entre el equipo de usuario 300, diversos SPD (por ejemplo, cualquiera de los SPD 106a, 106b, 110, 112, 114, 116, 118, 120y 122), proveedores de servicio de red (por ejemplo, proveedores de contenidos de medios), así como otro equipo de usuario (por ejemplo, cualquiera del equipo de usuario 108a-108c, 124, 126a-126c, 128, 130 y 132) utilizando la red de comunicación de datos 102 del sistema informático en red 100; un monitor de enlace de red 312 que puede monitorizar el caudal de enlace real para enlaces de red de interés particulares (también denominado en el presente documento como un agente de detección de capacidad de enlace o LCSA); un monitor de recursos de dispositivo 314 que puede monitorizar recursos de dispositivo residentes (por ejemplo, tal como recursos de fuente de alimentación, procesamiento, memoria, y comunicaciones); y un repositorio de aplicaciones local para almacenar diversas aplicaciones de usuario final que pueden permitir que el equipo de usuario 300 realice diversos procesos preferidos del usuario utilizando recursos de hardware y software residentes.
De acuerdo con una realización de la presente invención, el gestor de transferencia de datos 310 puede estar lógicamente enlazado al monitor de enlace de red 312 (o como alternativa a un monitor de enlace de red externo), y al monitor de recursos de dispositivo 314, de manera que el equipo de usuario 300 puede monitorizar capacidades de enlace de red externo así como sus recursos agotables residentes para afectar a las transferencias de datos entre sí mismo y un dispositivo informático externo (por ejemplo, un SPD 200, un proveedor de contenido de medios, u otro equipo de usuario). En una realización, en respuesta a analizar datos obtenidos desde el monitor de enlace de
5
10
15
20
25
30
35
40
45
50
55
60
65
red 312 y/o el monitor de recursos de dispositivo 314 del equipo de usuario 300, una entrega de datos al equipo de usuario 300 puede gestionarse de manera óptima (por ejemplo, regulando una tasa de transferencia de datos o seleccionando periodos preferidos para entrega de contenido de datos). Esta gestión puede estar basada en evaluaciones en tiempo real de tráfico de red para enlaces de comunicaciones que son parte de la ruta de comunicaciones entre (e incluyendo opcionalmente) dispositivos de envío y recepción (por ejemplo, el equipo de usuario 300). Ejemplos de gestión y evaluaciones de tráfico de red pueden hallarse en la Patente de Estados Unidos N.° 7.500.010, ADAPTIVE FILE DELIVERY SYSTEM AND METHOD, Harrang et al., expedida el 3 de marzo de 2009; Patente de Estados Unidos N.° 8.019.886, SYSTEMS AND METHODS FOR ENHANCED DATA DELIVERY BASED ON REAL TIME ANALYSIS OF NETWORK COMMUNICATIONS QUALITY AND TRAFFIC, Harrang et al., expedida el 13 de septiembre de 2011; y Solicitud de Patente de Estados Unidos N.° 12/395.485 ADAPTIVE FILE DELIVERY SYSTEM AND METHOD Harrang et al., expedida el 27 de febrero de 2009.
La Figura 4 es un diagrama esquemático de la pila de protocolo de comunicaciones de red de la Interconexión de Sistemas Abiertos (OSI). Las capas de aplicación, presentación y sesión pueden denominarse en general como las capas de aplicación superiores y corresponden a la capa de aplicación del Protocolo de Control de Transmisión y Protocolo de Internet (TCP/IP). La capa de transporte de la pila OSI corresponde a la capa de transporte de la pila de protocolo de TCP/IP. Las capas de transporte, y las capas por debajo de las capas de transporte, pueden denominarse en general las capas de protocolo inferiores.
En una realización, el equipo de usuario 300 puede solicitar una entrega desde un proveedor de contenido de medios (un dispositivo emisor) para un fichero de contenido de medios grande (por ejemplo, un contenido de medios relacionado con música, una película, un programa de TV, una aplicación de software, un libro electrónico, un podcast, etc.) a su dispositivo inalámbrico 300 usando un protocolo de comunicaciones inalámbricas específico que usa capas de protocolo inferiores. Uno o más dispositivos de red (por ejemplo, el equipo de usuario 300 o el SPD 200) que emplean el protocolo de comunicaciones pueden detectar un estado de congestión de canal de red (por ejemplo, usando un monitor de enlace de red 212, 312). El estado de congestión puede determinarse, por ejemplo, monitorizando el rendimiento del contenido de entrega de fichero de medios a través de uno o más segmentos específicos de red (por ejemplo, midiendo/analizando una o más métricas de comunicaciones de red) en el enlace de extremo a extremo, midiendo un pico, o rendimiento de caudal de enlace de extremo a extremo conseguible para los segmentos de red combinados (por ejemplo, con un dispositivo receptor, tal como el equipo de usuario 300), y a continuación comparando el caudal de segmento individual con el caudal de enlace de extremo a extremo pico. De esta manera, puede detectarse la congestión de red (mediante la comparación), y también puede identificarse el segmento o segmentos de red que pueden ser la fuente de un cuello de botella de congestión. Aunque en esta divulgación, se describen muchas realizaciones usando una red inalámbrica en un sistema informático en red, las realizaciones no necesitan estar limitadas a redes inalámbricas. Las realizaciones pueden ponerse en práctica también en sistemas informáticos en red usando unas redes alámbricas, o una combinación de redes alámbricas e inalámbricas, y en otros tipos de redes y enlaces entre puntos de extremo (por ejemplo, enlace de retroceso alámbrico o de fibra y cable coaxial).
La Figura 5 ilustra una vista de alto nivel de un proceso de actualización de congestión en un entorno de red inalámbrica de acuerdo con una realización. En 510, un primer equipo de usuario (por ejemplo, el equipo de usuario 300) puede determinar una capacidad de enlace pico asociada con una métrica de comunicaciones de red entre un equipo de usuario 300 y un SPD 200. Ejemplos de métricas de comunicaciones de red incluyen un esquema de modulación y codificación (MCS) empleado; una relación de señal a interferencia más ruido (SINR); una capacidad de enlace restante; o un caudal pico medido o uno designado para al menos un abonado de servicio. En general, una capacidad de enlace pico está asociada con rendimiento de red de extremo a extremo no congestionado o restringido en recursos de otra manera. En algunas realizaciones, la etapa 510 es opcional.
En 520, el primer equipo de usuario intercambia tráfico con un SPD 200 y obtiene información de congestión de red desde protocolos de comunicaciones de capa inferior. La información de congestión puede incluir el estado de congestión y métricas de congestión. El estado de congestión puede incluir, por ejemplo, mediciones de entrega de datos de caudal a través de uno o más segmentos de red específicos y mediciones de rendimiento de caudal de enlace de extremo a extremo para segmentos de red combinados. En algunas realizaciones el estado de congestión puede incluir contabilidad de rendimiento de entrega de datos de extremo a extremo para reenvíos de datos faltantes o perdidos (es decir, caudal útil). En otras realizaciones, el estado de congestión puede incluir latencia de entrega de datos de extremo a extremo. La información de estado de congestión puede usarse para calcular métricas de congestión. Las métricas de congestión pueden incluir, por ejemplo, tasas de caudal para múltiples segmentos de fichero entregados que pueden ponderarse de acuerdo con el tiempo de medición, y tasas de entrega de fichero de caudal escaladas de acuerdo con capacidades de enlace pico de extremo a extremo. En algunas realizaciones las métricas de congestión pueden incluir adicionalmente la tasa de entrega promedio permitida máxima basándose en estado de congestión informado y combinaciones de métricas de congestión derivadas. En algunas realizaciones, los segmentos de fichero consisten en múltiples paquetes de datos enviados de extremo a extremo y que abarcan suficiente volumen de tiempo y datos para obtener una estimación del rendimiento sostenido de la red de extremo a extremo. En algunas redes, un ejemplo de un tamaño de segmento de fichero es de aproximadamente 16 kiloBytes (kBytes).
5
10
15
20
25
30
35
40
45
50
55
60
65
En 530, el primer equipo de usuario pasa información de congestión que puede pasarse a las capas de aplicación superiores de otro equipo de usuario o servidores. El primer equipo de usuario también proporciona la información de congestión a un servidor en la red. Como una alternativa, la capacidad de enlace pico y la información de congestión de red pueden determinarse por un servidor en el sistema informático en red basándose en métricas de congestión pasadas al mismo por el equipo de usuario. En 540, el servidor reenvía la información de congestión de red a las capas de aplicación superiores de dispositivos conectados mediante la red, y compartiendo un enlace de cuello de botella con el primer equipo de usuario. Los dispositivos pueden incluir uno o más equipos de dispositivos de usuario, los servidores en red a estos dispositivos, y dispositivos de proveedor de servicio adicionales. En 550, los dispositivos que reciben la información de congestión de red usan la información para gestionar sus transferencias de datos. Por ejemplo, los dispositivos pueden regular una tasa de transferencia de datos o seleccionar periodos preferidos para entrega de contenido de datos. En una realización, descrita en la Patente de Estados Unidos N.° 7.500.010, ADAPTIVE FILE DELIVERY SYSTEM AND METHOD, Harrang et al., expedida el 3 de marzo de 2009, el agente de transferencia de datos 210 es un agente de regulación adaptativa que puede determinar la tasa de caudal promedio máxima del flujo de datos de emisor a receptor, Rmax, que puede aplicarse por cualquiera de un emisor o receptor para marcar el ritmo de la tasa de solicitudes desde un receptor para porciones posteriores del fichero de datos que se están transfiriendo.
La Figura 6 ilustra un sistema informático en red 600 de acuerdo con una realización. El sistema informático 600 incluye un sistema de envío 602 y dos sistemas de recepción 604 y 606, todos los cuales están enlazados comunicativamente a una red 608. El sistema de envío 602 podría ser un sistema informático o una pluralidad de sistemas informáticos co-localizados o distribuidos, tal como unos servidores, bases de datos, unidades de almacenamiento, encaminadores, conmutadores, cortafuegos, u otros dispositivos de este tipo, conectados mediante medios de fibra, alámbricos, inalámbricos a la red 608. En algunas realizaciones, el sistema de envío 602 es un SPD 200 como se describe en el presente documento.
Cada uno de los sistemas de recepción 604 y 606 podrían estar co-localizados con un DVR, PC, unidad de almacenamiento de red, estación de trabajo de cliente, decodificador de salón de televisión, módem, pasarela u otros dispositivos de este tipo tales como una tableta, reproductor de audio-vídeo portátil, dispositivo de comunicación móvil tal como un teléfono celular o en una unidad de hardware especializado. Los sistemas de recepción 604 y 606 podrían estar conectados mediante medios de fibra, alámbricos, inalámbricos a la red 608. En algunas realizaciones, cada uno de los sistemas de recepción 604 y 606 puede ser el equipo de usuario 300 como se describe en el presente documento.
La red 608 podría incluir uno o más componentes de red de la Internet u otras redes, tales como las WAN, incluyendo, pero sin limitación, redes de tipo alámbrico (DSL, cable, por línea eléctrica), fibra, inalámbricas, satélite y celulares. La red 608 podría incluir otros componentes de este tipo de red tal como, pero sin limitación, módems, encaminadores, puentes, pasarelas, interfaces de red, transmisiones cableadas, transmisiones inalámbricas, redes de área local (LAN), redes de acceso, redes de proveedor y disposiciones entre iguales.
El sistema de envío 602 incluye una interfaz 614 para acceder a la red 608, un procesador 616 y almacenamiento 618 que contiene un fichero 620 a transmitirse a través de la red al sistema de recepción 604. El sistema de envío 602 puede incluir uno o más módulos con instrucciones para implementar métodos de entrega de fichero adaptativa.
El sistema de recepción 604 incluye una interfaz 622 para acceder a la red 608, un procesador 624, y almacenamiento 626 para almacenar copias de porciones del fichero 620 recibidas desde el sistema de envío 602 y para almacenar uno o más módulos para implementar instrucciones con respecto a métodos de entrega de fichero adaptativa. Se entiende que el sistema de recepción 604 podría localizarse en una localización del usuario final o localizarse en alguna localización de red intermedia por ejemplo para servir como un nodo de almacenamiento en caché para distribuir contenido geográficamente más cerca de una pluralidad de usuarios finales.
El sistema de recepción 606 incluye una interfaz 628 para acceder a la red 608, un procesador 630 y almacenamiento 632 para almacenar la actualización 612 recibida desde el sistema de envío 602. Se entiende que el sistema de recepción 606 podrían localizarse en una localización del usuario final o localizarse en alguna localización de red intermedia por ejemplo para servir como un nodo de almacenamiento en caché para distribuir contenido geográficamente más cerca de una pluralidad de usuarios finales.
El sistema de envío 602 y los sistemas de recepción 604 y 606 pueden incluir datos almacenados en un medio legible por ordenador no transitorio en una memoria en o separados del almacenamiento 618, 626 y 632, respectivamente. Los datos pueden incluir instrucciones ejecutables por ordenador que, cuando se ejecutan por los procesadores 616, 624 y 630, respectivamente, realizan uno o más procesos asociados con las realizaciones de la presente invención. Por lo tanto, el sistema de envío 602 y los sistemas de recepción 604 y 606 puede realizar las mediciones y cálculos desvelados en el presente documento. Los sistemas de recepción 604 y 606 comparten al menos un enlace de cuello de botella 609 en la red 608. En una realización, el enlace de cuello de botella 609 es una estación base 106a, 106b, 118, 120, 122. En otra realización, el cuello de botella 609 es un segmento de enlace de red, o un conmutador, o un encaminador, o un nodo en la Internet.
5
10
15
20
25
30
35
40
45
50
55
60
65
Un enlace de cuello de botella es esa porción de un canal de comunicaciones compartido que limita la capacidad de caudal del canal. Independientemente del tipo de red empleada, un enlace de cuello de botella puede existir (ya sea inalámbrico, alámbrico o de fibra en su naturaleza) entre el servidor y uno o más terminales de usuario. El enlace de cuello de botella se comparte en términos de la capacidad de tráfico del enlace. Por ejemplo, en redes de acceso de consumidor, la última milla del canal de comunicación es típicamente un recurso compartido (por ejemplo, célula inalámbrica, enlace de retroceso de estación base o red de cable coaxial), y en muchos casos por razones de coste la última milla es el recurso de capacidad limitante o el enlace de cuello de botella.
Haciendo referencia a la Figura 6, los métodos para determinar qué sistemas de recepción comparten un enlace de cuello de botella 609 en la profundidad de red a un sistema de envío común 602 dependen del tipo de red que conecta los puntos de extremo. En algunas realizaciones, la red 608 incluye una red inalámbrica, y el enlace de cuello de botella 609 es el enlace inalámbrico de la última milla. En este ejemplo, pueden asociarse receptores examinando el identificador de equipo de célula servidora informada a un servidor por los terminales (por ejemplo, los sistemas de recepción 604, 606 y/o el sistema de envío 602). En ciertas realizaciones, la red 608 incluye un cable coaxial como el acceso de la última milla, y el enlace de cuello de botella 609 es la planta de cable compartido que conecta el sistema de terminación de módem de cable (CMTS) a un grupo de terminales (por ejemplo, los sistemas de recepción 604, 606 y/o el sistema de envío 602). En estos casos, los receptores pueden asociarse por el identificador de CMTS de los terminales (por ejemplo, los sistemas de recepción 604, 606 y/o el sistema de envío 602). En otra realización, el enlace de cuello de botella 609 en la red 608 puede identificarse usando técnicas conocidas para determinar el identificador de dirección del enlace de cuello de botella 609, y los terminales (por ejemplo, los sistemas de recepción 604, 606 y/o el sistema de envío 602) que comparten el enlace de cuello de botella 609 se agrupan por el servidor. En otra realización más, los terminales (por ejemplo, los sistemas de recepción 604, 606 y/o el sistema de envío 602) que comparten el enlace de cuello de botella 609 pueden determinarse por construcción de red y configurarse manualmente en el servidor.
En una realización, el sistema de envío 602 en la Figura 6 envía uno o más segmentos de fichero 610 a través de la red 608 al sistema de recepción 604. El sistema de recepción 604 mide el rendimiento de entrega de segmentos de fichero 610 y recopila mediciones de estado de congestión. El sistema de recepción 604 puede calcular métricas y proporcionar información de congestión al sistema de envío 602, por ejemplo en un mensaje de control, que no se muestra en la Figura 6. El sistema de envío 602 envía el mensaje actualizado 612 al sistema de recepción 606. El sistema de recepción 606 recibe la información de congestión de red actualizada.
En otra realización, el sistema de envío 602 en la Figura 6 envía uno o más segmentos de fichero 610 a través de la red 608 al sistema de recepción 604. El sistema de envío 602 mide la entrega de segmentos de fichero 610 y recopila mediciones de estado de congestión. El sistema de envío 602 puede calcular métricas y proporcionar información de congestión en el mensaje actualizado 612 al sistema de recepción 606. El sistema de recepción 606 recibe la información de congestión de red actualizada. El sistema de envío 602 puede enviar también una actualización 612 al sistema de recepción 604, o proporcionar información a través de un mensaje de control, que no se muestra en la Figura 6. Puede entenderse que, en algunas realizaciones, más de un sistema de envío puede enviar segmentos de fichero a una pluralidad de sistemas de recepción.
En una realización, el segmento de fichero 608 es una copia de una porción del fichero 620. El fichero 620 puede dividirse en múltiples segmentos de fichero 608 para transmisión de datos, con cada segmento de fichero enviado a un tiempo diferente. En algunas realizaciones que emplean una red inalámbrica, el tamaño del segmento de fichero puede designarse para conectar con la red inalámbrica y para enganchar el canal inalámbrico a una velocidad superior en casos donde los protocolos de comunicación de capa inferior segregan el acceso a canales de velocidad diferenciados por tamaño de transferencia de fichero. En tales casos, la porción inicial de una ráfaga de datos mayor puede encontrar la transferencia de paquetes más pequeños en un canal de acceso múltiple compartido más lento, seguido por un aumento abrupto en la tasa a medida que la ráfaga de datos se transfiere a un canal especializado de velocidad superior. Esto puede afectar a las mediciones de estado de congestión y reducir la precisión de los cálculos de tasa de caudal. Un tamaño de segmento de fichero mayor puede mejorar cálculos de tasa de caudal moviéndose rápidamente a través de este efecto de arranque. Por lo tanto, en ciertas realizaciones, el tamaño de segmento de fichero es dieciséis kBytes. En algunas realizaciones, el tamaño de segmento de fichero es mayor o menor que dieciséis kBytes.
En algunas realizaciones, y como se ha proporcionado en general anteriormente, el estado de congestión de red puede incluir mediciones de la cantidad de datos transferidos entre un emisor (es decir, sistema de envío) y un receptor (es decir, un sistema de recepción), junto con el tiempo para entrega de esos datos. A continuación, pueden calcularse las métricas de congestión, tal como por ejemplo la tasa de transferencia de datos o descarga de datos. En un ejemplo, el emisor puede ser el equipo de usuario final y el receptor un servidor conectado al equipo de usuario final a través de una red. En otro ejemplo, el receptor puede ser un equipo de usuario final y el emisor un servidor conectado al equipo de usuario final a través de una red. Por lo tanto, los papeles del emisor y receptor pueden asignarse de acuerdo con la dirección de transferencia de datos a través de la red, midiendo el emisor o receptor el estado de congestión y calculando métricas de congestión. Cada dirección de transferencia de datos a través de la red puede tener su propia información de congestión de red separada. Las realizaciones de la divulgación pueden aplicarse por lo tanto en una manera bidireccional.
5
10
15
20
25
30
35
40
45
50
55
60
65
La Figura 7 ilustra una realización que presenta un servidor y dos terminales. En una realización, un primer terminal 720 y un segundo terminal 740 están conectados a través de una red al servidor 730. Los terminales 720 y 740 comparten un enlace de cuello de botella. En una realización, en la etapa 712, un segmento de fichero 711 se transmite entre el terminal 720 y el servidor 730. En algunos casos, el segmento de fichero se transmite desde el terminal al servidor. En otros casos, el segmento de fichero se transmite desde el servidor al terminal. Por lo tanto, en la práctica un servidor y un terminal pueden desempeñar el papel de un sistema de envío o sistema de recepción.
El segmento de fichero 711 puede usarse para medir el estado de congestión de la red que tiene un enlace de cuello de botella. El segmento de fichero puede entregarse bajo condiciones derivadas de información de congestión previamente obtenidas, o entregadas bajo condiciones derivadas de ajustes de condición de red por defecto (por ejemplo, tasa de transferencia por defecto). En algunos casos, puede transmitirse más de un segmento de fichero de modo que el estado de congestión de la red puede promediarse a través de múltiples mediciones. En ciertos casos, el segmento de fichero puede ser de suficiente tamaño bajo las condiciones de red de manera que puede determinarse el caudal de datos de extremo a extremo sostenido a través del enlace de cuello de botella. En algunos casos, el segmento de fichero 711 es dieciséis kBytes en tamaño. Los métodos de determinación del estado de congestión de la red sostenido se desvelan en la Patente de Estados Unidos N.° 7.500.010, ADAPTIVE FILE DELIVERY SYSTEM AND METHOD, Harrang et al., expedida el 3 de marzo de 2009; Patente de Estados Unidos N.° 8.019.886, SYSTEMS AND METHODS FOR ENHANCED DATA DELIVERY BASED ON REAL TIME ANALYSIS OF NETWORK COMMUNICATIONS QUALITY AND TRAFFIC, Harrang et al., expedida el 13 de septiembre de 2011; y la Solicitud de Patente de Estados Unidos N. ° 12/395.485, ADAPTIVE FILE DELIVERY SYSTEM AND METhOd Harrang et al., presentada el 27 de febrero de 2009.
En algunas realizaciones, el terminal 720 recibe el segmento de fichero 711 y mide el estado de congestión de red en la etapa 721. El estado de congestión de red 713 se comunica a continuación al servidor 730 en la etapa 714. En una alternativa, el servidor 730 determina el estado de congestión de red en la etapa 731 basándose en el acuse de recibo de entrega desde terminal 720 donde el acuse de recibo de entrega también incluye rendimiento de entrega de segmento de fichero suficiente para determinar el estado de congestión actual. El servidor 730 puede enviar el estado de congestión de red 713 al terminal 720 en la etapa 714. En otra alternativa, tanto el terminal 720 como el servidor 730 determinan el estado de congestión de red en las etapas 721 y 731, respectivamente.
En ciertas otras realizaciones, el terminal 720 envía el segmento de fichero 711 y determina el estado de congestión de red en la etapa 721 basándose en un acuse de recibo de entrega desde el servidor 730. El estado de congestión de red 713 se comunica a continuación al servidor 730 en la etapa 714. En una alternativa, el servidor 730 mide el estado de congestión de red en la etapa 731. El servidor 730 puede enviar el estado de congestión de red 713 al terminal 720 en la etapa 714. En otra alternativa, tanto terminal 720 como el servidor 730 determinan el estado de congestión de red en las etapas 721 y 731, respectivamente.
En ciertas realizaciones, en la etapa 732, el servidor 730 determina los receptores (es decir, terminales o usuarios finales) para recibir el estado de congestión de red 713. Ejemplos de factores que pueden ser relevantes en esta determinación incluyen qué terminales que comparten un enlace de cuello de botella con el terminal 720 están actualmente activos usando la red; qué aplicación puede estar operando el terminal o terminales; qué configuración o mecanismos de calidad de servicio se están empleando actualmente en la red; y qué protocolos o procedimientos que direccionan congestión de red están actualmente vigentes. En algunos casos, la determinación puede ser basándose en una política almacenada en el servidor que puede configurarse para tener en cuenta uno o más de los factores anteriores. En ciertos casos, se seleccionan todos los receptores (es decir, terminales o usuarios finales) que comparten el enlace de cuello de botella para actualizar uno a uno con mensajes de unidifusión, y en otros casos con un mensaje de multidifusión o difusión. Aunque la Figura 7 ilustra un único segundo terminal, algunas realizaciones contemplan que una pluralidad de receptores pueden recibir la actualización de estado de congestión. Puede apreciarse también que en casos donde se seleccionan cero segundos terminales para actualizar, ese servidor 730 no realiza actualizaciones.
En algunas realizaciones, el terminal 720 o el servidor 730 pueden calcular métricas de congestión 715 basándose en el estado de congestión 713 en las etapas 722 y 733, respectivamente. En algunas realizaciones, el terminal 740 puede calcular métricas de congestión en la etapa 741 basándose en el estado de congestión 715 recibido desde el servidor como se describe adicionalmente a continuación. El estado de congestión puede incluir, por ejemplo, mediciones de entrega de datos de caudal a través de uno o más segmentos de red específicos y mediciones de rendimiento de caudal de enlace de extremo a extremo para segmentos de red combinados. La información de estado de congestión puede usarse para calcular métricas de congestión. Las métricas de congestión pueden incluir, por ejemplo, tasas de caudal para múltiples segmentos de fichero entregados que pueden ponderarse de acuerdo con el tiempo de medición, y tasas de entrega de fichero de caudal escaladas de acuerdo con capacidades de enlace pico de extremo a extremo. En algunos casos, se ponderan valores de estado de congestión de acuerdo con su antigüedad, que esta está basada a su vez en el tiempo de la medición de segmentos de entrega de fichero. En otros ejemplos, pueden emplearse estrategias de promediado para ponderar los valores de estado de congestión más recientes, o para reducir la variación de medición de estado de congestión rápida.
En una realización, un cálculo de ponderación ejemplar supone un conjunto de N estimaciones de congestión
5
10
15
20
25
30
35
40
45
50
55
60
65
disponibles de tasa (R) que representa una tasa de caudal de datos medida de un segmento de fichero entregado 711. Cada estimación se pondera como sigue:
Wi = m * ti + 1
donde m = - 1/tc. tc es un tiempo de corte establecido, donde ti > tc, y ti es el tiempo que corresponde al tiempo de muestra de R;, i = [1,N] entero.
Los pesos se determinan y normalizan a través de [0,1] usando
Wi' = Wi*(1/SUM(Wi)),
donde la SUMA recorre i = [1,N] entero.
En muchas realizaciones, algunos o todos los receptores pueden tener diferentes capacidades de entrega de fichero. Por lo tanto, en estos casos, las métricas de congestión para los receptores se escalan en consecuencia para tener en cuenta las capacidades:
(R/RP)c = SUM(Wi' * (Ri/RP)),
donde la SUM recorre i = [1,N] entero, y RP es la medición de caudal pico o máxima para el receptor a través del enlace determinado por medición de generación de perfiles de canal, o se establece por mediciones históricas o por configuración.
La relación promedio en conjunto, (R/RP)e puede usarse para determinar la restricción de caudal para entrega de segmento de fichero bajo las condiciones de red medidas:
Rmax = g( (R/RP)e )
donde g( ) es una función de retardo de envío para la que esta definición está relacionada a la política para control de flujo de congestión. En algunas realizaciones, la métrica de congestión Rmax es la tasa de caudal promedio máxima del flujo de datos de emisor a receptor, que puede aplicarse por protocolos de control de capa superior para marcar el ritmo de la tasa de solicitudes desde un receptor para porciones posteriores del fichero de datos que se está transfiriendo.
En las realizaciones, después de que se calculan las métricas de congestión 715, las métricas pueden comunicarse al servidor 730 por el terminal 720, o comunicarse al terminal 720 desde el servidor 730. En casos en los que el servidor 730 determina en la etapa 732 que una pluralidad de receptores (es decir, terminales o usuarios finales) deberían recibir una actualización de congestión de red, el servidor 730 puede comunicar el estado de congestión 713 o las métricas de congestión 715 a los receptores tales como el terminal 740 en la etapa 751. En estos casos en los que el terminal 740 recibe el estado de congestión 713, el terminal 740 puede calcular sus métricas de congestión en la etapa 741.
En algunas realizaciones, el terminal 740 está activo en la red y puede proporcionar el estado de congestión al servidor. En una realización, en la etapa 752, el segmento de fichero 753 se transmite entre el terminal 740 y el servidor 730. En algunos casos, el segmento de fichero se transmite desde el terminal al servidor. En otros casos, el segmento de fichero se transmite desde el servidor al terminal. Por lo tanto, en la práctica, un servidor y un terminal pueden desempeñar el papel de un sistema de envío o sistema de recepción.
El segmento de fichero 752 puede usarse para determinar el estado de congestión de la red que tiene un enlace de cuello de botella. En algunas realizaciones, el terminal 740 recibe el segmento de fichero 752 y mide el estado de congestión de red en la etapa 742. El estado de congestión de red 754 se comunica a continuación al servidor 730 en la etapa 755. En una alternativa, el servidor 730 determina el estado de congestión de red en la etapa 734 basándose en el acuse de recibo de entrega desde el terminal 740 donde el acuse de recibo de entrega también incluye suficiente rendimiento de entrega de segmento de fichero para determinar el estado de congestión actual. El servidor 730 puede enviar el estado de congestión de red 754 al terminal 740 en la etapa 755. En otra alternativa, tanto terminal 740 como el servidor 730 determinan el estado de congestión de red en las etapas 742 y 734, respectivamente.
En ciertas otras realizaciones, el terminal 740 envía el segmento de fichero 752 y determina el estado de congestión de red en la etapa 742 basándose en un acuse de recibo de entrega desde el servidor 730. El estado de congestión de red 754 se comunica a continuación al servidor 730 en la etapa 755. En una alternativa, el servidor 730 mide el estado de congestión de red en la etapa 734 basándose en mediciones de entrega de segmento de fichero. El servidor 730 puede enviar el estado de congestión de red 754 al terminal 740 en la etapa 755. En otra alternativa, tanto terminal 740 como el servidor 730 determinan el estado de congestión de red en las etapas 742 y 734, respectivamente.
5
10
15
20
25
30
35
40
45
50
55
60
65
En ciertas realizaciones, en la etapa 735, el servidor 730 determina los receptores (es decir, los terminales o usuarios finales) para recibir el estado de congestión de red 754. Ejemplos de factores que pueden ser relevantes en esta determinación incluyen qué terminales comparten un enlace de cuello de botella con el terminal 740 están actualmente activos usando la red; qué aplicación puede estar operando el terminal o terminales; qué configuración o mecanismos de calidad de servicio se están empleando actualmente en la red; y qué protocolos o procedimientos que direccionan congestión de red están actualmente vigentes. En algunos casos, la determinación puede estar basada en una política almacenada en el servidor que puede configurarse para tener en cuenta uno o más de los factores anteriores. En ciertos casos, se seleccionan todos los receptores (es decir, los terminales o usuarios finales) que comparten el enlace de cuello de botella para actualizar uno a uno con mensajes de unidifusión, y en otros casos con un mensaje de multidifusión o unidifusión. Aunque la Figura 7 ilustra un único segundo terminal, algunas realizaciones contemplan que una pluralidad de receptores pueden recibir la actualización de estado de congestión. Puede apreciarse también que en casos donde se seleccionan cero segundos terminales para actualizar, ese servidor 730 no realiza actualizaciones.
En algunas realizaciones, el terminal 740 o el servidor 730 pueden calcular métricas de congestión 757 basándose en el estado de congestión 754 en las etapas 743 y 736, respectivamente. Se han analizado previamente en el presente documento cálculos ejemplares para métricas de congestión, tal como por ejemplo Rmax.
En las realizaciones, después de que se calculan las métricas de congestión 756, las métricas pueden comunicarse al servidor 730 por el terminal 740, o comunicarse al terminal 740 desde el servidor 730. En casos en los que el servidor 730 determina en la etapa 735 que una pluralidad de receptores (es decir, los terminales o usuarios finales) deberían recibir una actualización de congestión de red, el servidor 730 puede comunicar el estado de congestión 754 o las métricas de congestión 756 a receptores tales como el terminal 720 en la etapa 717. En estos casos en los que el terminal 720 recibe el estado de congestión 754, el terminal 720 puede calcular sus métricas de congestión en la etapa 723.
Haciendo referencia a la Figura 1, en una realización, el servidor 730 es una estación base 106a, 106b, 118, 120, 122 y los terminales 720 y 740 son dispositivos móviles o teléfonos 108a-108c que están en un área de cobertura de la estación base y se unen a la estación base. La estación base puede ser una macro estación base, pico estación base, femto estación base, o similares. En una implementación, si la estación base o un controlador de estación base recibe un estado de congestión desde uno de los dispositivos móviles 108, la estación base o controlador determina otros dispositivos móviles que se unen a la estación base accediendo a registros de estado almacenados de los identificadores únicos de dispositivos móviles actualmente anexados (unidos) (por ejemplo estado de anexión conocido mediante intercambios de protocolo de movilidad entre dispositivos móviles y estación base servidora), y difunde información de congestión a estos otros dispositivos móviles. Estos otros dispositivos móviles a continuación reducen sus solicitudes de ancho de banda a la estación base. En otra implementación, tras recibir un estado de congestión desde uno de los dispositivos móviles que se une a la estación base, la estación base envía información de congestión a dispositivos móviles seleccionados basándose en el ancho de banda actual que se está usando o en uso de ancho de banda esperado de estos otros dispositivos móviles. Los dispositivos móviles seleccionados ajustan sus solicitudes de ancho de banda a la estación base tras recibir la información de congestión desde la estación base. Estos dispositivos móviles seleccionados son parte de los dispositivos móviles que están en el área de cobertura y se unen a la estación base.
La Figura 7 ilustra una realización que emplea un único servidor común entre dos o más terminales que comparten un enlace de cuello de botella. En algunas realizaciones, la pluralidad de terminales que comparten un enlace de cuello de botella puede cada uno usar diferentes servidores. En tales casos, la información (por ejemplo, estado de congestión o métricas de congestión) comunicada a un servidor por un terminal puede replicarse entre o a través de los servidores conectados a los terminales que comparten el enlace de cuello de botella. Por lo tanto, cada servidor se proporciona con información común que informa el estado de congestión de la red, y los servidores pueden enviar actualizaciones a otros terminales de usuario agrupados lógicamente.
La Figura 8 ilustra un sistema informático en red 800 de acuerdo con una realización adicional. El sistema informático 800 incluye un sistema de envío 802 y dos sistemas de recepción 804 y 806, y un gestor de congestión 808, todos los cuales están comunicativamente enlazados a una red 810. El sistema de envío 702 podría ser un sistema informático o una pluralidad de sistemas informáticos co-localizados o distribuidos tal como unos servidores, bases de datos, unidades de almacenamiento, encaminadores, conmutadores, cortafuegos, u otros dispositivos de este tipo, conectados mediante medios de fibra, alámbricos, inalámbricos a la red 810. Puede entenderse que, en algunas realizaciones, más de un sistema de envío puede enviar segmentos de fichero a una pluralidad de sistemas de recepción.
Cada uno de los sistemas de recepción 804 y 806 podría co-localizarse con un DVR, PC, unidad de almacenamiento en red, estación de trabajo de cliente, decodificador de salón de televisión, módem, pasarela u otros dispositivos de este tipo tales como una tableta, reproductor de audio-vídeo portátil, dispositivo de comunicación celular tal como un teléfono celular o en una unidad de hardware especializada. Los sistemas de recepción 804 y 806 podrían conectarse mediante medios de fibra, alámbricos, inalámbricos a la red 808.
5
10
15
20
25
30
35
40
45
50
55
60
65
La red 810 podría incluir uno o más componentes de red desde la Internet u otras redes, tales como las WAN, incluyendo, pero sin limitación, redes de tipo alámbrico (DSL, cable, por línea eléctrica), de fibra, inalámbricas, satélite y celular. La red 808 podría incluir otros componentes de red de este tipo tal como, pero sin limitación, módems, encaminadores, puentes, pasarelas, interfaces de red, transmisiones cableadas, transmisiones inalámbricas, redes de área local (LAN), redes de acceso, redes de proveedor y disposiciones entre pares.
El sistema de envío 802 incluye una interfaz 816 para acceder a la red 810, un procesador 818, y almacenamiento 820 que contiene un fichero 822 a transmitirse a través de la red al sistema de recepción 804. El gestor de congestión 808 incluye una interfaz 836 para acceder a la red 810, un procesador 838, y almacenamiento 840. El gestor de congestión 808 puede incluir uno o más módulos con instrucciones para implementar métodos de entrega de fichero adaptativa a transmitirse a través de la red a los sistemas de recepción 804 y 806.
El sistema de recepción 804 incluye una interfaz 824 para acceder a la red 810, un procesador 826, y almacenamiento 828 para almacenar copias de porciones del fichero 822 recibidas desde el sistema de envío 802 y para almacenar uno o más módulos para implementar instrucciones con respecto a métodos de entrega de fichero adaptativa. Se entiende que el sistema de recepción 804 podría localizarse en una localización del usuario final o localizarse en alguna localización de red intermedia por ejemplo para servir como un nodo de almacenamiento en caché para distribuir contenido geográficamente más cerca de una pluralidad de usuarios finales.
El sistema de recepción 806 incluye una interfaz 830 para acceder a la red 810, un procesador 832, y almacenamiento 834 para almacenar la actualización 814 recibida desde el gestor de congestión 808. Se entiende que el sistema de recepción 806 podría localizarse en una localización del usuario final o localizarse en alguna localización de red intermedia por ejemplo para servir como un nodo de almacenamiento en caché para distribuir contenido geográficamente más cerca de una pluralidad de usuarios finales.
El sistema de envío 802, los sistemas de recepción 804 y 806, y el gestor de congestión 808 pueden incluir datos almacenados en un medio legible por ordenador no transitorio en una memoria en o separados del almacenamiento 820, 828, 834 y 840, respectivamente. Los datos pueden incluir instrucciones ejecutables por ordenador que, cuando se ejecutan por los procesadores 816, 824 y 830, respectivamente, realizan uno o más procesos asociados con las realizaciones de la presente invención. Por lo tanto, el sistema de envío 802, los sistemas de recepción 804 y 806, y el gestor de congestión 808 pueden realizar las mediciones y cálculos desvelados en el presente documento. Los sistemas de recepción 804 y 806 comparten al menos un enlace de cuello de botella 811 en la red 810.
Un enlace de cuello de botella es esa porción de un canal de comunicaciones compartido que limita la capacidad de caudal del canal. Independientemente del tipo de red empleada, puede existir un enlace de cuello de botella (ya sea inalámbrica, cableada o de fibra en su naturaleza) entre el servidor y uno o más terminales de usuario. El enlace de cuello de botella se comparte en términos de la capacidad de tráfico del enlace. Por ejemplo, en redes de acceso de consumidor, la última milla del canal de comunicación es típicamente un recurso compartido (por ejemplo, célula inalámbrica, enlace de retroceso de estación base, o red de cable coaxial), y en muchos casos por razones de coste la última milla es el recurso de capacidad limitante, o el enlace de cuello de botella.
Haciendo referencia a la Figura 8, los métodos para determinar qué sistemas de recepción comparten un enlace de cuello de botella 811 en la ruta red a un sistema de envío común 802 dependen del tipo de red que conecta los puntos de extremo. En algunas realizaciones, la red 810 está conectada mediante una red inalámbrica, y el enlace de cuello de botella 811 es el enlace inalámbrico de la última milla. En este ejemplo, los receptores pueden estar asociados examinando el identificador de equipo de la célula servidora informado a un gestor de congestión 808 por los terminales (por ejemplo, los sistemas de recepción 804, 806 y/o el sistema de envío 802). En ciertas realizaciones, la red 810 incluye un cable coaxial como el acceso de la última milla, y el enlace de cuello de botella 811 es la planta de cable compartido que conecta el sistema de terminación de módem de cable (CMTS) a un grupo de terminales (por ejemplo, los sistemas de recepción 804, 806 y/o el sistema de envío 802). En estos casos, los receptores pueden estar asociados por el identificador de CMTS de los terminales (por ejemplo, los sistemas de recepción 804, 806 y/o el sistema de envío 802). En otra realización, el enlace de cuello de botella 811 en la red 810 puede identificarse usando técnicas conocidas para determinar el identificador de dirección del enlace de cuello de botella 811, y los terminales (por ejemplo, los sistemas de recepción 804, 806 y/o el sistema de envío 802) que comparten el enlace de cuello de botella 811 se agrupan por el gestor de congestión 808. En otra realización más, los terminales (por ejemplo, los sistemas de recepción 804, 806 y/o el sistema de envío 802) que comparte el enlace de cuello de botella 811 pueden determinarse por construcción de red y configurarse manualmente al gestor de congestión 808.
En una realización, el sistema de envío 802 en la Figura 8 envía uno o más segmentos de fichero 812 a través de la red 810 al sistema de recepción 804. El sistema de recepción 804 mide el rendimiento de entrega de segmentos de fichero 812 y recopila mediciones de estado de congestión. El sistema de recepción 804 puede calcular métricas y proporcionar información de congestión al gestor de congestión 808, por ejemplo en un mensaje de control, que no se muestra en la Figura 8. En algunas realizaciones, el sistema de envío 802 puede entregar contenido sin participar en el proceso de gestión de congestión. En tales casos, pueden usarse otros métodos por el sistema de recepción 804 para detectar la congestión, incluyendo sin limitación, monitorizar las tasas de caudal de entrega de extremo a
5
10
15
20
25
30
35
40
45
50
55
60
65
extremo promedio; las tasas de caudal de entrega de extremo a extremo de segmento de fichero; monitorizar tasas de paquetes de datos descartados; monitorizar latencia de paquete de datos; y monitorizar mareaje de congestión de encabezamiento de paquete de datos. El gestor de congestión 808 envía el mensaje actualizado 814 al sistema de recepción 806. El sistema de recepción 806 recibe la información de congestión de red actualizada.
En otra realización, el sistema de envío 802 en la Figura 8 envía uno o más segmentos de fichero 812 a través de la red 810 al sistema de recepción 804. El gestor de congestión 808 determina el tiempo para entrega de segmentos de fichero 812 y recopila mediciones de estado de congestión. El gestor de congestión 808 puede calcular en algunas realizaciones métricas de congestión. El gestor de congestión 808 envía el mensaje actualizado 814 al sistema de recepción 806. El sistema de recepción 806 recibe el estado de congestión de red actualizado. El gestor de congestión 808 puede enviar también una actualización 814 al sistema de recepción 804, o proporcionar información a través de un mensaje de control, que no se muestra en la Figura 8.
El gestor de congestión 808 puede localizarse en cualquier parte en la red. Como un ejemplo, en una localización central con conectividad de red a los terminales de usuario. En otro ejemplo, el gestor de congestión 808 puede localizarse en el punto de agregación para el tráfico de terminal de usuario, tal como en una estación base inalámbrica o controlador de estación base. El gestor de congestión 808 puede usar cualquier método para detectar congestión, incluyendo sin limitación, medir las tasas de entrega para segmentos de fichero transferidos a través de uno o más segmentos específicos de red tales como el enlace de cuello de botella, medir un rendimiento de caudal de enlace de extremo a extremo para los segmentos de red combinados y comparar el caudal de segmento individual con el pico, o caudal de enlace de extremo a extremo mejor conseguible, monitorizar las tasas de caudal promedio; monitorizar tasas de paquete de datos descartados; monitorizar latencia de paquete de datos; y monitorizar marcaje de congestión de encabezamiento de paquete de datos.
En una realización, el segmento de fichero 812 es una copia de una porción del fichero 822. El fichero 822 puede dividirse en múltiples segmentos de fichero 812 para transmisión de datos, con cada segmento de fichero enviado a un tiempo diferente. En algunas realizaciones que emplean una red inalámbrica, el tamaño del segmento de fichero puede designarse para conectar con la red inalámbrica y para enganchar el canal inalámbrico a una velocidad superior en casos donde los protocolos de comunicación de capa inferior segregan el acceso a canales de velocidad diferenciados por tamaño de transferencia de fichero. En tales casos, la porción inicial de una ráfaga de datos mayor puede encontrar la transferencia de paquetes más pequeños en un canal de acceso múltiple compartido más lento, seguido por un aumento abrupto en la tasa a medida que la ráfaga de datos se transfiere a un canal especializado de velocidad superior. Esto puede afectar las mediciones de estado de congestión y reducir la precisión de los cálculos de tasa de caudal. Un tamaño de segmento de fichero mayor puede mejorar los cálculos de tasa de caudal moviéndose rápidamente a través de este efecto de arranque. Por lo tanto, en ciertas realizaciones, el tamaño de segmento de fichero es dieciséis kBytes. En algunas realizaciones, el tamaño de segmento de fichero es mayor o menor que dieciséis kBytes.
En algunas realizaciones, y como se ha proporcionado en general anteriormente, el estado de congestión de red puede incluir mediciones de la cantidad de datos transferidos entre un emisor (es decir, sistema de envío) y un receptor (es decir, un sistema de recepción), junto con el tiempo para la entrega de esos datos. Las métricas de congestión, tal como por ejemplo la tasa de transferencia de datos o descarga de datos, pueden calcularse a continuación. En un ejemplo, el emisor puede ser el equipo de usuario final y el receptor un servidor conectado al equipo de usuario final a través de una red. En otro ejemplo, el receptor puede ser el equipo de usuario final y el emisor un servidor conectado al equipo de usuario final a través de una red. Por lo tanto, los papeles del emisor y receptor pueden asignarse de acuerdo con la dirección de transferencia de datos a través de la red, midiendo cualquiera del emisor o receptor el estado de congestión y calculando métricas de congestión. Cada dirección de transferencia de datos a través de la red puede tener su propia información de congestión de red separada. Las realizaciones de la divulgación pueden aplicarse por lo tanto en una manera bidireccional.
La Figura 9 ilustra una realización que presenta un gestor de congestión y dos terminales. En una realización, un primer terminal 920 y un segundo terminal 940 que están conectados al gestor de congestión 930. Los terminales 920 y 940 comparten un enlace de cuello de botella. En una realización, en la etapa 902, el segmento de fichero 901 se entrega al terminal 920 desde un sistema de entrega de contenido no mostrado en la Figura 9.
El segmento de fichero 901 puede usarse para medir el estado de congestión de la red que tiene un enlace de cuello de botella. El segmento de fichero puede entregarse bajo condiciones derivadas desde información de congestión previamente obtenida, o entregarse bajo condiciones derivadas desde ajustes de condición de red por defecto (por ejemplo, tasa de transferencia por defecto). En algunos casos, puede transmitirse más de un segmento de fichero de modo que el estado de congestión de la red puede promediarse a través de múltiples mediciones. En ciertos casos, el segmento de fichero puede ser de suficiente tamaño bajo condiciones de red de manera que puede determinarse el caudal de datos de extremo a extremo sostenido a través del enlace de cuello de botella. En algunos casos, el segmento de fichero 901 es dieciséis kiloBytes en tamaño.
En algunas realizaciones, el terminal 920 recibe el segmento de fichero 901 y mide el estado de congestión de red en la etapa 921. El estado de congestión de red 913 se comunica a continuación al gestor de congestión 930 en la
5
10
15
20
25
30
35
40
45
50
55
60
65
etapa 914.
En ciertas realizaciones, en la etapa 932, el gestor de congestión 930 determina los receptores (es decir, los terminales o usuarios finales) para recibir el estado de congestión de red 913. Ejemplos de factores que pueden ser relevantes en esta determinación incluyen qué terminales que comparten un enlace de cuello de botella con el terminal 920 están actualmente activos usando la red; qué aplicación puede estar operando el terminal o terminales; qué configuración de calidad de servicio o mecanismos se están empleando actualmente en la red; y qué protocolos o procedimientos que direccionan congestión de red están actualmente vigentes. En algunos casos, la determinación puede estar basada en una política almacenada en el gestor de congestión 930 que puede configurarse para tener en cuenta uno o más de los factores anteriores. En ciertos casos, se seleccionan todos los receptores (es decir, los terminales o usuarios finales) que comparten el enlace de cuello de botella para actualizar uno a uno con mensajes de unidifusión, y en otros casos con un mensaje de multidifusión o unidifusión. Aunque la Figura 9 ilustra un único segundo terminal, algunas realizaciones contemplan una pluralidad de receptores que pueden recibir la actualización de estado de congestión. Puede apreciarse también que en casos donde se seleccionan cero segundos terminales para actualizar, ese servidor 730 no realiza actualizaciones.
En algunas realizaciones, el terminal 920 o el gestor de congestión 930 pueden calcular métricas de congestión 915 basándose en el estado de congestión 913 en las etapas 922 y 932, respectivamente. En algunos casos, se ponderan valores de estado de congestión de acuerdo con su antigüedad, que esta a su vez está basada en el tiempo de la medición. En otros ejemplos, pueden emplearse estrategias de promediado para ponderar los valores de estado de congestión más recientes, o para reducir el ruido de medición de estado de congestión. Se han analizado previamente en el presente documento cálculos ejemplares para métricas de congestión, tal como por ejemplo Rmax.
En las realizaciones, después de que se calculan las métricas de congestión 915, las métricas pueden comunicarse al gestor de congestión 930 por el terminal 920, o comunicarse al terminal 920 desde el gestor de congestión 930. En casos en los que el gestor de congestión 930 determina en la etapa 932 que una pluralidad de receptores (es decir, los terminales o usuarios finales) deberían recibir una actualización de congestión de red, el gestor de congestión 930 puede comunicar el estado de congestión 913 o las métricas de congestión 915 a los receptores tal como el terminal 940 en la etapa 951. En aquellos casos en los que terminal 940 recibe el estado de congestión 913, el terminal 940 puede calcular sus métricas de congestión en la etapa 941.
En algunas realizaciones, el terminal 940 puede proporcionar actualizaciones de estado de congestión o métricas de congestión al gestor de congestión 930. En un ejemplo, en la etapa 962, el segmento de fichero 961 se entrega al terminal 940. El segmento de fichero 961 puede usarse para medir el estado de congestión de la red que tiene un enlace de cuello de botella. En algunas realizaciones, el terminal 940 recibe el segmento de fichero 961 y determina el estado de congestión de red en la etapa 942. El estado de congestión de red 954 se comunica a continuación al gestor de congestión 930 en la etapa 955. En la etapa 935, el gestor de congestión 930 determina los receptores (es decir, los terminales o usuarios finales) para recibir el estado de congestión de red 954 como se ha desvelado anteriormente.
En algunas realizaciones, el terminal 940 o el gestor de congestión 930 pueden calcular métricas de congestión 956 basándose en el estado de congestión 954 en las etapas 943 y 936, respectivamente. En algunos casos, los valores de estado de congestión se ponderan de acuerdo con su antigüedad, que esta está basada a su vez en el tiempo de la medición. En otros ejemplos, pueden emplearse estrategias de promediado para ponderar los valores de estado de congestión más recientes, o para reducir el ruido de medición de estado de congestión. Un ejemplo de un cálculo de ponderación y cálculos ejemplares para métricas de congestión, tal como, por ejemplo, Rmax se ha desvelado previamente en el presente documento.
En las realizaciones, después de que se calculan las métricas de congestión 956, las métricas pueden comunicarse al gestor de congestión 930 por el terminal 940, o comunicarse al terminal 940 desde el gestor de congestión 930. En casos en los que el gestor de congestión 930 determina en la etapa 935 que una pluralidad de receptores (es decir, los terminales o usuarios finales) deberían recibir una actualización de congestión de red, el gestor de congestión 930 puede comunicar el estado de congestión 954 o las métricas de congestión 956 a los receptores tal como el terminal 920 en la etapa 917. En estos casos en los que el terminal 920 recibe el estado de congestión 954, el terminal 920 puede calcular sus métricas de congestión en la etapa 923.
Haciendo referencia a la Figura 1, en una realización, el gestor de congestión 930 es una estación base 106a, 106b, 118, 120, 122 y los terminales 920 y 940 son dispositivos móviles o teléfonos 108a-108c que están en un área de cobertura de la estación base y se unen a la estación base. La estación base puede ser una macro estación base, pico estación base, femto estación base, o similares. En una implementación, si la estación base o un controlador de estación base recibe un estado de congestión desde uno de los dispositivos móviles 108, la estación base determina otros dispositivos móviles que se unen a la estación base accediendo a registros de estado almacenados de los identificadores únicos de dispositivos móviles (por ejemplo estado de anexión conocido mediante intercambios del protocolo de movilidad entre dispositivos móviles y la estación base servidora) actualmente anexados (unidos), y difunde la información de congestión a estos otros dispositivos móviles. Estos otros dispositivos móviles a
continuación reducen sus solicitudes de ancho de banda a la estación base. En otra implementación, tras recibir un estado de congestión desde uno de los dispositivos móviles que se ha unido a la estación base, la estación base envía información de congestión a dispositivos móviles seleccionados basándose en el ancho de banda actual que se está usando o en uso de ancho de banda esperado de estos otros dispositivos móviles. Los dispositivos móviles 5 seleccionados ajustan sus solicitudes de ancho de banda a la estación base después de la información de congestión desde la estación base. Estos dispositivos móviles seleccionados son parte de los dispositivos móviles que están en el área de cobertura y se unen a la estación base.

Claims (15)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    REIVINDICACIONES
    1. Un sistema en red, que comprende:
    un sistema de envío que tiene un procesador y una memoria,
    primer y segundo terminales móviles, teniendo cada terminal móvil un procesador y una memoria; y una red de comunicación que tiene una pluralidad de recursos de red que acopla el sistema de envío y el primer y segundo terminales móviles, compartiendo el primer y segundo terminales móviles un enlace en la red de comunicación; y
    en el que el sistema de envío está configurado para enviar un primer segmento de fichero al primer terminal móvil, siendo el primer segmento de fichero una porción de un primer fichero de datos que se transmite al primer terminal móvil,
    en el que el primer terminal móvil está configurado para determinar primera información de congestión de la red de comunicación basándose en una transferencia del primer segmento de fichero, para determinar una primera política de transferencia basándose en la primera información de congestión, y para comunicar la primera información de congestión al segundo terminal móvil,
    en el que el segundo terminal móvil está configurado para ajustar una solicitud de ancho de banda al sistema de envío basándose en la primera información de congestión,
    en el que la primera información de congestión proporciona mediciones de entrega de datos de caudal a través de uno o más segmentos de red o mediciones de rendimiento de caudal de enlace de extremo a extremo para segmentos de red combinados, o ambas, y
    en el que la primera política de transferencia proporciona una tasa de entrega promedio permitida máxima para el primer terminal móvil basándose en la primera información de congestión determinada por el primer terminal móvil.
  2. 2. El sistema de interconexión en red de la reivindicación 1, en el que el segundo terminal móvil está configurado para determinar una segunda política de transferencia basándose en segunda información de congestión, basándose la segunda información de congestión en la primera información de congestión determinada por el primer terminal móvil, proporcionando la segunda política de transferencia una tasa de entrega promedio permitida máxima para el segundo terminal móvil basándose en la segunda información de congestión, y
    en el que el segundo terminal móvil está configurado para recibir el segundo segmento de fichero desde el sistema de envío de acuerdo con la segunda política de transferencia.
  3. 3. El sistema de interconexión en red de la reivindicación 2, en el que la primera información de congestión se mide por un recurso que está asociado con una capa de protocolo inferior,
    en el que la segunda información de congestión se proporciona al segundo terminal móvil mediante la red de comunicación, y
    en el que la capa de protocolo inferior es una cualquiera de una capa de transporte de una pila del protocolo de Interconexión de Sistemas Abiertos (OSI), y una capa por debajo de la capa de transporte.
  4. 4. El sistema de interconexión en red de la reivindicación 3, en el que el primer terminal móvil está configurado para comunicar la segunda información de congestión al segundo terminal móvil en una capa de aplicación de un paquete transmitido al segundo terminal móvil.
  5. 5. El sistema de interconexión en red de la reivindicación 1, en el que la primera información de congestión incluye el estado de congestión.
  6. 6. El sistema de interconexión en red de la reivindicación 5, en el que el primer terminal móvil está configurado para medir la información de estado de congestión.
  7. 7. El sistema de interconexión en red de la reivindicación 6, en el que el primer terminal móvil está configurado para comunicar la segunda información de congestión al segundo terminal móvil en una capa de aplicación de un paquete transmitido al segundo terminal móvil.
  8. 8. El sistema de interconexión en red de la reivindicación 1, en el que el sistema de envío está configurado para determinar
    un enlace de cuello de botella en la red de comunicación basándose en la primera información de congestión, estando asociado el enlace de cuello de botella con uno de los recursos de red en los enlaces de red de comunicación de extremo a extremo entre el terminal de envío y el primero móvil;
    para identificar un terminal móvil que comparte el enlace de cuello de botella, siendo el terminal móvil identificado el segundo terminal móvil; y
    para comunicar la segunda información de congestión al segundo terminal móvil.
  9. 9. El sistema de interconexión en red de la reivindicación 8, en el que el sistema de envío está configurado para identificar el terminal móvil que comparte el enlace de cuello de botella y para comunicar la segunda información de congestión al segundo terminal móvil.
    5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
  10. 10. El sistema de interconexión en red de la reivindicación 1, en el que el primer terminal móvil está configurado para comunicar la primera información de congestión a un sistema de gestión de congestión del sistema de red, y
    en el que el sistema de gestión de congestión está configurado para comunicar la segunda información de congestión al segundo terminal móvil.
  11. 11. Un método de detección de congestión en un sistema en red que tiene un sistema de envío y primer y segundo terminales móviles, comprendiendo el método:
    determinar primera información de congestión de una red de comunicación mediante un primer terminal móvil basándose en una transferencia de un primer segmento de fichero, siendo el primer segmento de fichero una porción de un primer fichero de datos que se transmite al primer terminal móvil por el sistema de envío; determinar una primera política de transferencia por el primer terminal móvil basándose en la primera información de congestión, proporcionando la primera política de transferencia una tasa de entrega promedio permitida máxima para el primer terminal móvil;
    comunicar, por un emisor, la primera información de congestión al segundo terminal móvil, compartiendo el primer y segundo terminales móviles un enlace en la red de comunicación; y
    recibir, por un receptor, un segundo segmento de fichero del primer fichero de datos por el primer terminal móvil de acuerdo con la primera política de transferencia,
    en el que el segundo terminal móvil ajusta una solicitud de ancho de banda al sistema de envío basándose en la primera información de congestión.
  12. 12. El método de la reivindicación 11, en el que la primera información de congestión proporciona mediciones de entrega de datos de caudal a través de uno o más segmentos de red o mediciones de rendimiento de caudal de enlace de extremo a extremo para segmentos de red combinados, o ambas,
    en el que la primera información de congestión se mide por un recurso que está asociado con una capa de protocolo inferior,
    en el que segunda información de congestión se comunica al segundo terminal móvil proporcionando información en una capa de aplicación de un paquete transmitido al segundo terminal móvil, y
    en el que la capa de protocolo inferior es una cualquiera de una capa de transporte de una pila del protocolo de Interconexión de Sistemas Abiertos (OSI), y una capa por debajo de la capa de transporte.
  13. 13. El método de la reivindicación 11, en el que la primera información de congestión incluye el estado de congestión,
    en el que el estado de congestión se mide por el primer terminal móvil.
  14. 14. El método de la reivindicación 11, en el que el método comprende adicionalmente:
    determinar un enlace de cuello de botella en los enlaces de sistema de red de extremo a extremo entre el terminal de envío y uno o más móviles basándose en la primera información de congestión; identificar un terminal móvil que comparte el enlace de cuello de botella, siendo el terminal móvil identificado el segundo terminal móvil;
    comunicar segunda información de congestión al segundo terminal móvil.
  15. 15. Un método de detección de congestión en un sistema en red que tiene un sistema de envío y un primer terminal móvil, comprendiendo el método:
    enviar, por un emisor, un primer segmento de fichero al primer terminal móvil por el sistema de envío, siendo el primer segmento de fichero una porción de un primer fichero de datos transmitido al primer terminal móvil por el sistema de envío;
    recibir, por un receptor, primera información de congestión de una red de comunicación desde el primer terminal móvil, basándose la primera información de congestión en una transferencia del primer segmento de fichero según se recibe por el primer terminal móvil;
    enviar, por el emisor, la primera información de congestión a un segundo terminal móvil, compartiendo el primer y segundo terminales móviles un enlace en la red de comunicación;
    recibir, por el receptor, una solicitud de ancho de banda que se ha ajustado por el segundo terminal móvil basándose en la primera información de congestión;
    recibir, por el receptor, una comunicación que indica una primera política de transferencia desde el primer terminal móvil, proporcionando la primera política de transferencia una tasa de entrega promedio permitida máxima para el primer terminal móvil; y
    enviar, por el emisor, un segundo segmento de fichero al primer terminal móvil por el sistema de envío de acuerdo con una primera política de transferencia determinada por el primer terminal móvil, en el que la primera política de transferencia se determina por el primer terminal móvil basándose en la primera información de congestión.
ES13848380.5T 2012-10-25 2013-10-18 Método y sistema para detección de congestión cooperativa en redes celulares Active ES2675198T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201261718526P 2012-10-25 2012-10-25
US201261718526P 2012-10-25
PCT/US2013/065781 WO2014066189A1 (en) 2012-10-25 2013-10-18 Method and system for cooperative congestion detection in cellular networks

Publications (1)

Publication Number Publication Date
ES2675198T3 true ES2675198T3 (es) 2018-07-09

Family

ID=50545135

Family Applications (1)

Application Number Title Priority Date Filing Date
ES13848380.5T Active ES2675198T3 (es) 2012-10-25 2013-10-18 Método y sistema para detección de congestión cooperativa en redes celulares

Country Status (4)

Country Link
US (1) US9172643B2 (es)
EP (1) EP2912878B1 (es)
ES (1) ES2675198T3 (es)
WO (1) WO2014066189A1 (es)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2889761T3 (es) * 2013-07-31 2022-01-13 Assia Spe Llc Método y aparato para monitorización continua de red de acceso y estimación de pérdida de paquetes
US9872210B2 (en) 2013-10-16 2018-01-16 At&T Mobility Ii Llc Adaptive rate of congestion indicator to enhance intelligent traffic steering
WO2015077504A1 (en) * 2013-11-20 2015-05-28 Opanga Networks, Inc. Fractional pre-delivery of content to user devices
US10043137B1 (en) 2014-01-06 2018-08-07 Nuu:Bit, Inc. Dynamically optimized transport system
KR102102254B1 (ko) * 2014-01-15 2020-04-20 삼성전자주식회사 통신 시스템에서 무선 네트워크의 혼잡 검출 장치 및 방법
ES2715419T3 (es) * 2014-03-23 2019-06-04 Opanga Networks Inc Control de la predistribución de contenido a un dispositivo móvil
EP3192299B1 (en) * 2014-09-10 2020-01-15 Telefonaktiebolaget LM Ericsson (publ) Explicit congestion notification marking of user traffic
US20160344791A1 (en) * 2015-05-20 2016-11-24 Microsoft Technology Limited, Llc Network node bandwidth management
WO2016195788A1 (en) 2015-05-29 2016-12-08 Kvh Industries, Inc. Methods and apparatus for transporting data on a network
US9807010B2 (en) 2015-06-05 2017-10-31 Akamai Technologies, Inc. Congestion detection in mobile networks and delivery of content in non-congested conditions
US9813299B2 (en) * 2016-02-24 2017-11-07 Ciena Corporation Systems and methods for bandwidth management in software defined networking controlled multi-layer networks
KR102318284B1 (ko) 2017-03-14 2021-10-28 삼성전자주식회사 데이터 전송 경로의 혼잡 탐지 방법 및 장치
US20190253968A1 (en) * 2018-02-14 2019-08-15 Qualcomm Incorporated Managing target wake time scheduling using congestion metrics
CN110557297B (zh) * 2018-06-04 2021-06-08 华为技术有限公司 链路检测方法及相关装置
US10667172B2 (en) 2018-06-18 2020-05-26 Akamai Technologies, Inc. Download management with congestion mitigation for over the air content delivery to vehicles
US11012362B2 (en) 2018-06-18 2021-05-18 Akamai Technologies, Inc. Download management with congestion mitigation for over the air content delivery to vehicles
US20220014478A1 (en) * 2020-12-26 2022-01-13 Intel Corporation Resource consumption control

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002015215A (ja) 2000-06-30 2002-01-18 Hitachi Ltd マルチメデア情報配信システムおよび携帯情報端末装置
US7760646B2 (en) 2005-02-09 2010-07-20 Nokia Corporation Congestion notification in 3G radio access
US7500010B2 (en) 2005-04-07 2009-03-03 Jeffrey Paul Harrang Adaptive file delivery system and method
KR100797389B1 (ko) 2006-04-21 2008-01-28 한국전자통신연구원 다중 디스크립션 코딩을 이용한 클러스터 기반의 스트리밍시스템 및 그 방법
JP4688776B2 (ja) * 2006-10-31 2011-05-25 富士通株式会社 移動体通信ネットワークにおける輻輳制御方法および装置
JP2008177684A (ja) 2007-01-16 2008-07-31 Nec Corp 混雑情報提供システム、移動体端末、サーバー、混雑情報提供方法およびプログラム
US20110222406A1 (en) * 2008-11-11 2011-09-15 Fredrik Persson Method And Device For Enabling Indication Of Congestion In A Telecommunications Network
US8493860B2 (en) * 2010-03-24 2013-07-23 Telefonaktiebolaget Lm Ericsson (Publ) Fair congestion detection for transport network layer WCDMA communications
US20110267948A1 (en) * 2010-05-03 2011-11-03 Koc Ali T Techniques for communicating and managing congestion in a wireless network
GB2495712B (en) * 2011-10-17 2014-01-08 Skype Controlling transmission of data
US20130194937A1 (en) * 2012-01-31 2013-08-01 Alcatel-Lucent Usa Inc. Method and apparatus for providing intelligent codec rate adaptation for wireless users

Also Published As

Publication number Publication date
WO2014066189A1 (en) 2014-05-01
US20140119184A1 (en) 2014-05-01
EP2912878A4 (en) 2016-05-18
EP2912878A1 (en) 2015-09-02
US9172643B2 (en) 2015-10-27
EP2912878B1 (en) 2018-04-25

Similar Documents

Publication Publication Date Title
ES2675198T3 (es) Método y sistema para detección de congestión cooperativa en redes celulares
US11546268B2 (en) Systems and methods for pacing data flows
US11399293B2 (en) System and method of network policy optimization
BR112021005950A2 (pt) método e aparelho de processamento de informações de fatia
US20170317894A1 (en) Method and apparatus for communication network quality of service capability exposure
US9344908B2 (en) Systems and methods for quality of experience measurement and wireless network recommendation
ES2728732T3 (es) Técnicas de adaptación de tasa sensibles a la calidad para la difusión en flujo de tipo DASH
ES2856326T3 (es) Dispositivo, sistema y método de optimización de entrega de multimedia
US10348796B2 (en) Adaptive video streaming over preference-aware multipath
ES2855161T3 (es) Funciones de red auto-organizativa en redes de telecomunicaciones
ES2761225T3 (es) Provisión de tratamiento de QoS basándose en múltiples peticiones
US11303560B2 (en) HCPE-based intelligent path selection over a multipath network
KR102457792B1 (ko) 동적 채널 본딩을 위한 시스템 및 방법
US9130848B2 (en) Method and apparatus for enhancing QoS during home network remote access
US12010025B2 (en) System and method for accelerating or decelerating a data transport network protocol based on real time transport network congestion conditions
US8773990B1 (en) Detecting unauthorized tethering
Ben Mustafa et al. FlexStream: Towards flexible adaptive video streaming on end devices using extreme SDN
한빙 A Testbed for Mobile Named-Data Network integrated with 4G networking devices