ES2922416T3 - Transmisión de trayectoria múltiple de datos - Google Patents
Transmisión de trayectoria múltiple de datos Download PDFInfo
- Publication number
- ES2922416T3 ES2922416T3 ES16306173T ES16306173T ES2922416T3 ES 2922416 T3 ES2922416 T3 ES 2922416T3 ES 16306173 T ES16306173 T ES 16306173T ES 16306173 T ES16306173 T ES 16306173T ES 2922416 T3 ES2922416 T3 ES 2922416T3
- Authority
- ES
- Spain
- Prior art keywords
- user equipment
- data streams
- data stream
- multiple data
- transport protocol
- 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
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 15
- 238000006243 chemical reaction Methods 0.000 claims abstract description 71
- 238000004891 communication Methods 0.000 claims abstract description 46
- 238000000034 method Methods 0.000 claims abstract description 31
- 238000004590 computer program Methods 0.000 claims abstract description 3
- 238000012937 correction Methods 0.000 claims description 21
- 230000008901 benefit Effects 0.000 claims description 6
- 230000008859 change Effects 0.000 claims description 4
- 230000004044 response Effects 0.000 claims description 2
- 230000002776 aggregation Effects 0.000 description 10
- 238000004220 aggregation Methods 0.000 description 10
- 230000004048 modification Effects 0.000 description 9
- 238000012986 modification Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 4
- 230000001419 dependent effect Effects 0.000 description 3
- 230000015654 memory Effects 0.000 description 3
- 238000011084 recovery Methods 0.000 description 3
- 230000003044 adaptive effect Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 239000012050 conventional carrier Substances 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 230000006855 networking Effects 0.000 description 2
- 238000001228 spectrum Methods 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 230000004931 aggregating effect Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000008030 elimination Effects 0.000 description 1
- 238000003379 elimination reaction Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000011056 performance test Methods 0.000 description 1
- 238000011176 pooling Methods 0.000 description 1
- 239000002243 precursor Substances 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 230000005641 tunneling Effects 0.000 description 1
- 239000011800 void material Substances 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/24—Multipath
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/61—Network physical structure; Signal processing
- H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
- H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/61—Network physical structure; Signal processing
- H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
- H04N21/6131—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a mobile phone network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/631—Multimode Transmission, e.g. transmitting basic layers and enhancement layers of the content over different transmission paths or transmitting with different error corrections, different keys or with different transmission protocols
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Multimedia (AREA)
- Communication Control (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephone Function (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Se describen un equipo de usuario, un nodo proxy intermedio, un método y un programa informático. El equipo de usuario comprende un dominio de control de red y un dominio de usuario y puede funcionar para recibir y transmitir datos a través de múltiples rutas de comunicación. El equipo de usuario tiene una lógica de conversión dentro del dominio del usuario que puede funcionar para convertir entre un único flujo de datos y múltiples flujos de datos formados a partir del único flujo de datos, de modo que al menos dos de las múltiples rutas de comunicación pueden usarse para la transmisión de los múltiples flujos de datos formados. del único flujo de datos. (Traducción automática con Google Translate, sin valor legal)
Description
DESCRIPCIÓN
Transmisión de trayectoria múltiple de datos
Campo de la invención
La invención se refiere al campo de la comunicación de datos inalámbrica y, en particular, a la transmisión de datos a través de múltiples trayectorias.
Antecedentes
Hay una demanda cada vez mayor para datos móviles. Se espera un aumento de quince veces en el tráfico de datos en los mercados desarrollados para 2020, mientras que los mercados en desarrollo pueden experimentar posiblemente un aumento de 60 veces.
Una forma de satisfacer las mayores demandas de capacidad sin aumentar excesivamente los costes es proporcionar comunicaciones inalámbricas de múltiples trayectorias, en donde se usan simultáneamente diferentes trayectorias, en algunos casos usando diferentes tecnologías de acceso de radio (RAT), para suministrar un flujo de datos individual a través de estos múltiples enlaces inalámbricos paralelos (trayectorias).
Aunque están considerándose diferentes enfoques para las comunicaciones de múltiples trayectorias, estos se refieren en general a cambios en el lado de red. Las figuras 1 y 2 muestran diferentes enfoques para estas técnicas de múltiples trayectorias en el lado de red, mientras que la figura 3 muestra un equipo de usuario según la técnica anterior en donde una aplicación genera un flujo de datos dentro del dominio de usuario y se emite a través del dominio o núcleo de control de red a un puerto de salida para su transmisión usando una trayectoria de comunicación individual. Un inconveniente de las técnicas de múltiples trayectorias mostradas en las figuras 1 y 2 es que sólo los equipos de usuario compatibles pueden usar actualmente estas técnicas.
El documento US2015/0201046 describe un equipo de usuario con una entidad de estado de interfaz de red que monitoriza el estado de las interfaces de red disponibles para el usuario. Un módulo 506 de control de TCP gestiona conexiones de MPTCP usando un puerto de MPTCP en el núcleo de sistema operativo. El documento JP 2009 296084 A representa otro ejemplo de la técnica anterior.
Sería deseable que un equipo de usuario pudiera comunicarse usando múltiples enlaces o trayectorias de comunicación inalámbrica sin requerir una modificación extensa del equipo de usuario, particularmente no de la porción del equipo de usuario que generalmente no es accesible para el usuario y cuya alteración puede invalidar una garantía.
Resumen
La invención se define en las reivindicaciones independientes adjuntas, y las reivindicaciones dependientes describen realizaciones adicionales.
Un primer aspecto de la presente invención proporciona un equipo de usuario que comprende un dominio de control de red y un dominio de usuario, pudiendo hacerse funcionar dicho equipo de usuario para recibir y transmitir datos a través de múltiples trayectorias de comunicación, comprendiendo dicho equipo de usuario:
lógica de conversión dentro de dicho dominio de usuario que puede hacerse funcionar para convertir entre un flujo de datos individual y múltiples flujos de datos formados a partir de dicho flujo de datos individual, de modo que pueden usarse al menos dos de dichas múltiples trayectorias de comunicación para la transmisión de dichos múltiples flujos de datos formados a partir de dicho flujo de datos individual; en donde
dicho flujo de datos individual comprende información de cabecera que cumple con un primer protocolo de transporte; y dicha lógica de conversión puede hacerse funcionar para añadir información de cabecera que cumple con un protocolo de transporte adicional a dichos múltiples flujos de datos, conteniendo dicha información de cabecera añadida información para enrutar dichos múltiples flujos de datos a un nodo proxy intermedio.
Los inventores de la presente invención reconocieron las ventajas de las comunicaciones de múltiples trayectorias junto con las dificultades implicadas en la modificación de la pila de red de un equipo de usuario con el fin de permitirle desplegar comunicaciones de múltiples trayectorias. Con respecto a esto, aunque en teoría, los dispositivos móviles modernos, tales como los teléfonos inteligentes y ordenadores de tipo tableta, pueden soportar la conexión en red de múltiples bandas y múltiples tecnologías, ya que están habitualmente equipados con múltiples transceptores de LTE, HSPA, WiFi operativos en múltiples bandas de frecuencia con licencia y sin licencia, sin embargo, prácticamente cualquier equipo de usuario de legado (UE) requiere modificaciones de la pila de red para desplegar comunicaciones de múltiples trayectorias. Más específicamente, se requiere el desbloqueo del UE y/o el acceso de superusuario a su sistema operativo. Por ejemplo, las soluciones de capa de red tales como LWIP (integración de nivel de radio de WLAN de LTE con túnel de IPSec) y LWA (agregación de WLAN de LTE) como se
muestra en la figura 1 requieren la modificación de tablas de enrutamiento junto con la gestión de túneles de IPSec, mientras que las soluciones de capa de transporte basadas en MPTCP (protocolo de control de transmisión de múltiples trayectorias) requieren el reemplazo de toda la capa de transporte de la pila de conexión en red. Otros protocolos de múltiples trayectorias como SCTP (protocolo de transmisión de control de flujo) ni siquiera son compatibles con la interfaz de programación de aplicaciones actual lo que, por lo tanto, requerirá la adaptación de aplicaciones de usuario por sus autores.
Sin embargo, desplegar comunicaciones de múltiples trayectorias basadas en modificaciones de núcleo es una opción comercialmente inviable El desbloqueo del UE a menudo implica anular la garantía del UE, mientras que establecer acceso de superusuario tiene implicaciones de seguridad y privacidad. Los operadores de red que están dispuestos a abordar estos problemas todavía tendrán que desarrollar y mantener parches de software y versiones de núcleo para todas las versiones de teléfonos existentes y sus controladores patentados, dando como resultado costes significativos.
Estos problemas se han abordado proporcionando una lógica de conversión dentro del dominio de usuario que puede hacerse funcionar para convertir entre flujos de datos individuales y múltiples. De esta manera, en lugar de proporcionar esta funcionalidad dentro del dominio o núcleo de control de red del equipo de usuario que puede requerir acceso de superusuario y desbloqueo del UE, se proporciona en el dominio de usuario que es fácilmente accesible. Esto le permite actualizarse simplemente requiriendo sólo acceso de usuario, y no requiere ninguna modificación del sistema operativo del UE. De esta manera, tanto la red como el dominio de control de red de UE ven y enrutan múltiples flujos de datos de la manera que tratan con otros múltiples flujos de datos, realizándose la conversión entre flujos de datos múltiples e individuales en el dominio de usuario.
La lógica de conversión recibirá el flujo de datos individual que tiene información de cabecera que cumple con un primer protocolo de transporte. Este primer protocolo de transporte es uno que el dominio de control de red del equipo de usuario puede decodificar ya que se transmitirá a la lógica de conversión a través del conjunto de circuitos de enrutamiento dentro del equipo de usuario. De manera similar, los múltiples flujos de datos se modificarán para comprender información de cabecera que cumplirá con un protocolo de transporte adicional que la red puede decodificar ya que esto se usará para enrutar los múltiples flujos de datos a su destino posterior. Estos dos protocolos de transporte deben ser protocolos de transporte normalizados que el sistema operativo del equipo de usuario y la red entiendan. En algunos casos pueden ser el mismo protocolo. La información de cabecera de los múltiples flujos de datos contiene información de enrutamiento para enrutar los múltiples flujos de datos a través de un nodo proxy intermedio, estando este nodo presente para generar el flujo de datos individual original a partir de los múltiples flujos de datos antes de que se alcance el destino final. Por lo tanto, según la presente invención, la lógica de conversión puede hacerse funcionar para añadir información de cabecera a los múltiples flujos de datos según un protocolo de transporte adicional, información de cabecera que indica el enrutamiento a través de un nodo proxy intermedio.
En algunas realizaciones, dichos múltiples flujos de datos comprenden además información de cabecera según un segundo protocolo, proporcionando dicha información de cabecera una indicación de cómo los datos en dichos múltiples flujos de datos se refieren a paquetes de datos en dicho flujo de datos individual.
En algunos casos, además de tener el protocolo de transporte adicional que se usa para enrutar los múltiples flujos de datos, puede añadirse información de cabecera adicional, que cumple con un segundo protocolo e indicativa de cómo los datos de múltiples trayectorias se refieren a los datos de trayectoria individual, a los paquetes de datos de los múltiples flujos de datos. Proporcionar información de cabecera adicional usando un protocolo diferente permite definir este protocolo dentro de la lógica de conversión en el dominio de usuario proporcionando libertad para implementar protocolos tanto normalizados (de legado) como no normalizados (patentados optimizados) para comunicaciones de múltiples trayectorias. Con respecto a esto, este protocolo no se usa para enrutar los flujos de datos y, como tal, sólo necesita entenderse por la lógica de conversión de equipo de usuario y el nodo proxy intermedio correspondiente que realizará una conversión correspondiente de múltiples trayectorias a trayectoria individual.
Las cabeceras que cumplen con el segundo protocolo proporcionan una indicación de cómo los datos en los múltiples flujos de datos se refieren a los paquetes de datos en el flujo de datos individual y, por lo tanto, permiten recombinar los múltiples flujos de datos para reformar el flujo de datos individual en un punto posterior. Con respecto a esto, la información en la cabecera puede indicar el orden de paquete de datos del flujo de datos individual y/o puede indicar otras cosas tales como códigos de error.
En algunas realizaciones,
Dicha lógica de conversión puede hacerse funcionar para eliminar cabeceras que cumplen con dicho primer protocolo de transporte; y añadir cabeceras que cumplen con dicho protocolo de transporte adicional cuando se convierte entre dicho flujo de datos individual y dichos múltiples flujos de datos.
Cuando se convierte entre el flujo de datos individual y los múltiples flujos de datos, la lógica de conversión puede hacerse funcionar para cambiar la cabecera de manera que las cabeceras de primer protocolo de transporte que
están vinculadas al flujo de datos individual se cambian por cabeceras que cumplen con el protocolo de transporte adicional para los múltiples flujos de datos. Aunque en algunos casos los dos protocolos pueden ser el mismo protocolo, las cabeceras no lo serán ya que los múltiples flujos de datos se enrutarán a través de un nodo proxy intermedio.
Además, cuando se usa información de cabecera adicional según un segundo protocolo, esto también se proporciona por la lógica de conversión a los múltiples flujos de datos. De esta manera, los múltiples flujos de datos tendrán dos cabeceras, siendo una de ellas según el protocolo de transporte adicional que se usa por la red para enrutar el flujo de datos y proporcionando la otra información referente a los paquetes de datos en los múltiples flujos de datos y, en particular, sobre cómo se relacionan con el flujo de datos individual original permitiendo que la lógica de conversión aguas abajo vuelva a ensamblar el flujo de datos original. Cuando la lógica de conversión convierte de los múltiples flujos de datos a los flujos de datos individuales, entonces los datos de cabecera se cambian del protocolo de transporte adicional al primer protocolo de transporte, cuando estos protocolos son diferentes y cuando hay datos de cabecera adicionales que cumplen con el segundo protocolo, entonces esto se usa para reensamblar el flujo de datos individual y, en particular, cuando los paquetes de datos tienen un orden particular, se usa en el orden de los paquetes de datos.
En algunas realizaciones, dicho flujo de datos individual comprende información de cabecera según dicho primer protocolo de transporte, y dicha lógica de conversión puede hacerse funcionar para convertir dicho flujo de datos de salida en múltiples flujos de datos de salida mediante: eliminar dicha información de cabecera según dicho primer protocolo de transporte; añadir información de cabecera según dicho segundo protocolo a dichos múltiples flujos de datos; y añadir información de cabecera adicional a dichos múltiples flujos de datos según un protocolo de transporte adicional, enrutándose dichos múltiples flujos de datos según dicha información de cabecera de dicho protocolo de transporte adicional a través de un nodo proxy intermedio.
En algunas realizaciones, dicho equipo de usuario comprende además una interfaz virtual dentro de dicho dominio de control de red, estando dicha interfaz virtual configurada para enrutar flujos de datos entre una aplicación de usuario en dicho dominio de usuario y dicha lógica de conversión.
En algunas realizaciones, el equipo de usuario comprende una interfaz virtual dentro del dominio de control de red que puede hacerse funcionar para enrutar un flujo de datos entre una aplicación de usuario y la lógica de conversión.
Como se indicó anteriormente, permitir cualquier modificación del dominio o núcleo de control de red del equipo de usuario requiere acceso a este dominio lo cual en muchos casos puede anular la garantía del equipo de usuario. Sin embargo, muchos equipos de usuario tienen una interfaz virtual dentro del dominio de control de red como parte de una red privada virtual que está ahí para desviar un flujo de datos que se enruta a una salida a través de esta interfaz de vuelta al dominio de usuario. Esto se usa generalmente para enrutar datos que van a emitirse a un algoritmo de cifrado dentro del dominio de usuario que cifra los datos y luego los reenvía para su emisión. Los inventores de la presente invención reconocieron que esta interfaz virtual puede usarse para desviar un flujo de datos generado por una aplicación en el dominio de usuario a la lógica de conversión dentro del dominio de usuario que entonces puede usarse para modificar el flujo de datos antes de su emisión. De esta manera, la lógica de conversión puede proporcionarse en el dominio de usuario para convertir un flujo de datos individual para su emisión en múltiples flujos de datos. Esto permite que realizar procedimiento de conversión según una aplicación que puede descargarse por un usuario.
En algunas realizaciones,
Dicha lógica de conversión puede hacerse funcionar en respuesta a la recepción de dichos múltiples flujos de datos para generar dicho flujo de datos individual a partir de dichos múltiples flujos de datos.
Anteriormente se ha descrito que la lógica de conversión convierte los datos de enlace ascendente de un flujo individual generado por una aplicación a múltiples flujos para su transmisión. La lógica de conversión también puede hacerse funcionar para recibir y convertir datos de descarga que se reciben como múltiples flujos en un flujo de datos individual que luego puede transmitirse a través de la interfaz virtual a la aplicación relevante.
En algunas realizaciones, dicho primer protocolo de transporte es un protocolo de transporte más complejo que tiene datos de cabecera con más información que dicho protocolo de transporte adicional.
Como protocolo de transporte adicional se puede usar a menudo junto con información de cabecera adicional según un segundo protocolo, puede ser un protocolo de transporte muy simple que contiene muy poca información en la cabecera, indicando la información simplemente, por ejemplo, el puerto a través del cual tienen que emitirse los datos. Por ejemplo, pueden ser datos de puerto sin procesar sin protocolos o puede ser un protocolo de transporte simple tal como UDP/IP (protocolo de datagrama de usuario). El primer protocolo de transporte no tiene el beneficio de información de cabecera adicional y, por lo tanto, generalmente es un protocolo de transporte de legado más complejo tal como TCP (protocolo de control de transmisión).
En algunas realizaciones, al menos uno de dichos múltiples flujos de datos comprende códigos de corrección de errores para datos dentro de dicho flujo de datos individual.
Proporcionar múltiples flujos de datos permite enviar los datos en paralelo proporcionando una mayor capacidad de transporte o ancho de banda. Este aumento de capacidad también se puede usar para transmitir códigos de corrección de errores tales como códigos de corrección de errores directos que permiten detectar, y en algunos casos corregir, errores en los datos recibidos debido, por ejemplo, a paquetes descartados.
En algunas realizaciones, dicha lógica de conversión puede hacerse funcionar para generar dichos códigos de corrección de errores asociados con dichos datos de dicho flujo de datos individual y para transmitir dichos códigos de corrección de errores a lo largo de dicho al menos uno de dichos múltiples flujos de datos.
Aunque puede haber códigos de corrección de errores presentes en el flujo de datos individual, en algunas realizaciones se generan por la lógica de conversión y se envían en uno o más de los múltiples flujos de datos. Con respecto a esto, uno de los múltiples flujos de datos puede usarse para transmitir los códigos de corrección de errores; en realizaciones alternativas, se pueden transmitir con los datos a los que se refieren en los múltiples flujos de datos. En cualquier caso, habrá alguna indicación de a qué paquetes de datos se refieren.
Un segundo aspecto de la presente invención proporciona un método realizado en un equipo de usuario, comprendiendo dicho equipo de usuario un dominio de control de red y un dominio de usuario, pudiendo hacerse funcionar dicho equipo de usuario para recibir y transmitir datos a través de múltiples trayectorias de comunicación que tienen diferentes propiedades, comprendiendo dicho método: convertir dentro de dicho dominio de usuario entre un flujo de datos individual y múltiples flujos de datos de modo que pueden usarse al menos dos de dichas múltiples trayectorias de comunicación para la transmisión de dicho flujo de datos individual; en donde dicho flujo de datos individual comprende información de cabecera que cumple con un primer protocolo de transporte; y dichos múltiples flujos de datos comprenden información de cabecera que cumple con un protocolo de transporte adicional para enrutar dichos múltiples flujos de datos a un nodo proxy intermedio.
En algunas realizaciones, dicho método comprende además eliminar dichas cabeceras que cumplen con dicho primer protocolo de transporte y añadir cabeceras que cumplen con dicho protocolo de transporte adicional cuando se convierte entre dicho flujo de datos individual y múltiples flujos de datos.
En algunas realizaciones, dicho método comprende además añadir información de cabecera que cumple con un segundo protocolo a dichos múltiples flujos de datos, proporcionando dicha información de cabecera una indicación de cómo los datos en dichos múltiples flujos de datos se refieren a paquetes de datos en dicho flujo de datos individual.
En algunas realizaciones, dicho método comprende generar códigos de corrección de errores asociados con dichos datos de dicho flujo de datos individual y transmitir dichos códigos de corrección de errores a lo largo de dicho al menos uno de dichos múltiples flujos de datos.
Un tercer aspecto de la presente invención proporciona un sistema que comprende un equipo de usuario según un primer aspecto y un nodo proxy intermedio que puede hacerse funcionar para recibir y reenviar señales transmitidas entre dicho equipo de usuario y un servidor, comprendiendo dicho nodo proxy intermedio:
múltiples interfaces de equipo de usuario para comunicarse a través de múltiples trayectorias de comunicación con un equipo de usuario; y
una interfaz de servidor para comunicarse con un servidor a través de trayectoria ruta de comunicación individual;
comprendiendo dicho nodo proxy intermedio lógica de conversión que puede hacerse funcionar para convertir entre múltiples flujos de datos y un flujo de datos individual, de modo que un flujo de datos individual enviado a través de dicha trayectoria de comunicación entre dicho servidor y dicho nodo proxy intermedio se envía como múltiples flujos de datos a través de múltiples trayectorias de datos entre dicho equipo de usuario y dicho nodo proxy intermedio; en donde
dicho flujo de datos individual comprende información de cabecera que cumple con un primer protocolo de transporte; y dichos múltiples flujos de datos comprenden información de cabecera que cumple con un protocolo de transporte adicional, pudiendo hacerse funcionar dicha lógica de conversión para cambiar cabeceras en dichos flujos de datos cuando se convierte entre dicho flujo de datos individual y dichos múltiples flujos de datos.
El equipo de usuario de la presente invención funciona en una red junto con un nodo proxy intermedio que actúa para convertir entre flujos de datos múltiples e individuales de modo que la entidad con la que está comunicándose el equipo de usuario ve un flujo de datos individual, mientras que los datos se transmiten a través de gran parte de la red como múltiples flujos de datos. Este nodo proxy intermedio está ubicado entre el equipo de usuario y la otra entidad y puede estar ubicado como una entidad por sí mismo o dentro de otra entidad tal como dentro de un nodo de red, dentro de la nube o dentro de un servidor. El nodo proxy intermedio actúa para convertir el flujo de datos
individual emitido, por ejemplo, por un servidor en múltiples flujos de datos para la transmisión al equipo de usuario y para realizar la operación inversa de convertir múltiples flujos de datos recibidos desde el equipo de usuario en un flujo de datos individual para su transmisión al servidor. La lógica de conversión dentro del nodo intermedio corresponde a la lógica de conversión dentro del equipo de usuario y, por lo tanto, el segundo protocolo usado por la lógica de conversión en cada uno, para la funcionalidad de múltiples trayectorias, puede seleccionarse y actualizarse según se requiera actualizando simplemente la lógica de conversión tanto en el equipo de usuario como en el nodo proxy intermedio.
En algunas realizaciones, dicho nodo proxy intermedio comprende un dominio de control de red y un dominio de usuario, y dicha lógica de conversión está dentro del dominio de control de red.
Como el nodo proxy intermedio es un artículo personalizado, la modificación del núcleo o dominio de control de red para proporcionar una funcionalidad adicional o diferente no es un problema y, por lo tanto, en algunos casos puede ser ventajoso proporcionar la lógica o aplicación de conversión dentro de este dominio ya que esto puede mejorar el rendimiento.
En algunas realizaciones, dicha lógica de conversión puede hacerse funcionar para añadir información de cabecera que cumple con un segundo protocolo a dichos múltiples flujos de datos cuando se convierte dicho flujo de datos individual en dichos múltiples flujos de datos, proporcionando dicha información de cabecera una indicación de cómo los datos en dichos múltiples flujos de datos se refieren a paquetes de datos en dicho flujo de datos individual.
En algunas realizaciones, dicho primer protocolo de transporte es un protocolo de transporte más complejo que tiene datos de cabecera con más información que dicho protocolo de transporte adicional.
En algunas realizaciones, al menos uno de dichos múltiples flujos de datos comprende códigos de corrección de errores para datos dentro de dicho flujo de datos individual.
En algunas realizaciones, dicha lógica de conversión puede hacerse funcionar para generar dichos códigos de corrección de errores asociados con dichos datos de dicho flujo de datos individual y para transmitir dichos códigos de corrección de errores a lo largo de dicho al menos uno de dichos múltiples flujos de datos.
Aunque puede haber códigos de corrección de errores presentes en el flujo de datos individual, en algunas realizaciones se generan por la lógica de conversión y se envían en uno o más de los múltiples flujos de datos. Con respecto a esto, uno de los múltiples flujos de datos puede usarse para transmitir los códigos de corrección de errores; en realizaciones alternativas, se pueden transmitir con los datos a los que se refieren en los múltiples flujos de datos. En cualquier caso, habrá alguna indicación de a qué paquetes de datos se refieren.
Un cuarto aspecto de la presente invención proporciona un método realizado por un sistema que comprende un método realizado en un equipo de usuario según un segundo aspecto y un método realizado en un nodo proxy intermedio para recibir y reenviar señales transmitidas entre dicho equipo de usuario y un servidor, comprendiendo dicho nodo proxy intermedio:
una interfaz de equipo de usuario para comunicarse a través de múltiples trayectorias de comunicación de diferentes tipos con un equipo de usuario; y
una interfaz de servidor para comunicarse con un servidor a través de trayectoria ruta de comunicación individual;
dicho método comprende convertir entre múltiples flujos de datos y un flujo de datos individual eliminando cabeceras que cumplen con un primer protocolo de transporte y añadiendo cabeceras que cumplen con un protocolo de transporte adicional, de modo que un flujo de datos individual enviado a través de dicha trayectoria de comunicación entre dicho servidor y dicho nodo proxy intermedio se envía como múltiples flujos de datos a través de múltiples trayectorias de datos entre dicho equipo de usuario y dicho nodo proxy intermedio.
En algunas realizaciones, dicho método comprende además añadir información de cabecera que cumple con un segundo protocolo a dichos múltiples flujos de datos, proporcionando dicha información de cabecera una indicación de cómo los datos en dichos múltiples flujos de datos se refieren a paquetes de datos en dicho flujo de datos individual.
En algunas realizaciones, dicho método comprende generar códigos de corrección de errores asociados con dichos datos de dicho flujo de datos individual y transmitir dichos códigos de corrección de errores a lo largo de dicho al menos uno de dichos múltiples flujos de datos.
En algunas realizaciones, al menos uno de dichos múltiples flujos de datos comprende códigos de corrección de errores para datos dentro de dicho flujo de datos individual.
En algunas realizaciones, dicho método comprende además generar dichos códigos de corrección de errores asociados con dichos datos de dicho flujo de datos individual y transmitir dichos códigos de corrección de errores a lo largo de dicho al menos uno de dichos múltiples flujos de datos.
Un quinto aspecto de la presente invención proporciona un programa informático que, cuando se ejecuta por un procesador, puede hacerse funcionar para controlar dicho procesador para realizar un método según un primer o un tercer aspecto de la presente invención.
En las reivindicaciones dependientes e independientes adjuntas se exponen aspectos particulares y preferidos adicionales. Las características de las reivindicaciones dependientes pueden combinarse con características de las reivindicaciones independientes según sea apropiado, y en combinaciones distintas de las explícitamente expuestas en las reivindicaciones.
Cuando se describe que una característica de aparato puede hacerse funcionar para proporcionar una función, se apreciará que esto incluye una característica de aparato que proporciona esa función o que está adaptada o configurada para proporcionar esa función.
Breve descripción de las figuras
Ahora se describirán adicionalmente realizaciones de la presente invención, con referencia a los dibujos adjuntos, en los que:
la figura 1 representa esquemáticamente la integración LTE y WiFi de capa de red para comunicación de múltiples trayectorias según la técnica anterior;
la figura 2 muestra una visualización esquemática de la pila de protocolos de interconexión de sistema abierto para el protocolo de control de transporte de múltiples trayectorias como normalizado por la IETF;
la figura 3 muestra una comunicación de trayectoria individual de legado dentro de un equipo de usuario;
la figura 4 muestra esquemáticamente un equipo de usuario;
la figura 5 muestra esquemáticamente una visión general de arquitectura de un equipo de usuario, nodo proxy intermedio y servidor de contenido;
la figura 6 muestra esquemáticamente un ejemplo del equipo de usuario y el nodo intermedio según realizaciones que usan protocolos de múltiples trayectorias de legado;
la figura 7 muestra esquemáticamente un equipo de usuario y un nodo intermedio que usan un protocolo no normalizado;
las figuras 8 y 9 ilustran esquemáticamente la generación de códigos de corrección de errores y la recuperación de datos a partir de los mismos.
Descripción
Antes de comentar las realizaciones en más detalle, en primer lugar se proporcionará un resumen.
La presente descripción proporciona conectividad múltiple que permite la comunicación de múltiples flujos de datos entre un equipo de usuario y un nodo proxy intermedio que usan múltiples trayectorias que pueden ser múltiples trayectorias que usan las mismas técnicas de comunicación, tales como múltiples trayectorias de Wi-Fi o pueden ser múltiples trayectorias de comunicación de diferentes tipos, tales como una trayectoria de Wi-Fi, una trayectoria de LTE y una trayectoria de 5G. Dividir un flujo de datos en múltiples flujos y usar múltiples trayectorias aumenta el ancho de banda disponible para el transporte de ese flujo de datos y, por lo tanto, puede mejorar el rendimiento. Los ejemplos buscan hacer esto sin requerir modificaciones en el lado de servidor/red y sin requerir la modificación del dominio de control de red del equipo de usuario, estando este último protegido por contraseñas de raíz y requiriendo desbloquear el teléfono para acceder. Dichas etapas de desbloqueo son onerosas y pueden provocar la anulación de la garantía del teléfono.
Ejemplos abordan este problema proporcionando una lógica de conversión dentro del dominio de usuario del equipo de usuario y proporcionando un nodo proxy intermedio con la lógica de conversión correspondiente, estando el nodo proxy intermedio ubicado entre el equipo de usuario y la entidad con la que se comunica que puede ser un servidor. Esta lógica de conversión convierte entre un flujo de datos individual y múltiples flujos de datos y proporciona información que relaciona los flujos de datos individuales y múltiples entre sí en cabeceras que cumplen con un protocolo que pueden decodificar ambas lógicas de conversión. Los flujos de datos comprenden cabeceras adicionales compatibles con protocolos de transporte según normas particulares que
permiten que el lado de red y el dominio de control de red del equipo de usuario enruten los flujos de datos sin requerir ninguna modificación.
De esta manera, la lógica de conversión además de dividir el flujo de datos o recombinarlos, cambiará la información de cabecera asociada con los flujos de datos de modo que cuando se forma un flujo de datos individual para dar múltiples flujos, se añade una cabecera adicional relacionado los múltiples flujos al flujo individual. Esta cabecera adicional cumple con un protocolo que puede ser un protocolo de legado pero que también puede ser un protocolo patentado ya que debe interpretarse sólo por la lógica de conversión dentro del equipo de usuario y el nodo proxy intermedio. La información en esta cabecera permite recombinar los múltiples flujos de datos para formar un flujo de datos individual y también puede proporcionar algún tipo de funcionalidad de corrección de errores.
Cuando la lógica de conversión recombina los múltiples flujos de datos para formar un flujo de datos individual, entonces el cabecera según este protocolo se decodifica y se interpreta de tal manera que los múltiples flujos de datos se pueden reformar para formar un flujo de datos individual. Luego se añade una cabecera a este flujo de datos individual que debe cumplir con un protocolo de transporte normalizado y que, en realizaciones preferidas, es el protocolo que se usó originalmente con el flujo de datos individual original. De esta manera, cuando el flujo de datos llega a su destino no parece que se haya alterado de ninguna manera.
Además de agregar las cabeceras que relacionan los flujos múltiples e individual, se añade una cabecera de protocolo de transporte que es un protocolo de transporte normalizado y permite enrutar los múltiples flujos de datos entre el nodo proxy intermedio y el equipo de usuario. Este protocolo de transporte puede ser un protocolo de transporte muy simple que indica simplemente dónde deben ir los múltiples flujos de datos ya que cualquier funcionalidad adicional, tal como las instalaciones de corrección de errores, pueden incluirse en la cabecera que relaciona los flujos de datos individual y múltiples. En otros ejemplos, puede ser el mismo protocolo de transporte que el usado con el flujo de datos individual.
En la presente descripción, la conectividad de múltiples trayectorias se habilita aprovechando el marco de espacio de usuario convencional para redes privadas virtuales que se proporciona en muchos equipos de usuario. Esta red privada virtual proporciona una forma de desviar un flujo de datos emitido hacia un puerto particular de vuelta al dominio de usuario donde una aplicación, en este caso un algoritmo de conversión, puede modificar el flujo de datos que entonces puede emitirse hacia múltiples puertos.
Establecer conectividad de múltiples trayectorias en el modo de espacio de usuario resulta ventajoso porque puede hacerse simplemente descargando e instalando una aplicación especializada que puede crearse y publicarse por el operador de red. Por lo tanto, se elimina la necesidad de desbloquear el teléfono y/o el acceso de superusuario. Además, pueden implementarse protocolos tanto normalizados como no normalizados para comunicaciones de múltiples trayectorias usando el marco de red privada virtual convencional, incluso en equipos de usuario de legado.
El concepto de comunicaciones inalámbricas de múltiples trayectorias es atractivo por tres razones:
Rendimiento - la agregación de múltiples enlaces de entrega de datos independientes en una conexión lógica permite un aumento significativo del rendimiento global así como reducir la latencia gracias a la posibilidad de agrupación de recursos y multiplexación. A diferencia de la agregación de portadoras convencional, la agregación de ancho de banda entre RAT no está limitada por la disponibilidad de espectro por RAT.
Control de calidad de servicio - las comunicaciones e múltiples trayectorias son un precursor necesario para permitir el control de la calidad de servicio inalámbrica, un diferenciador clave de 5G, ya que las interrupciones temporales de ancho de banda pueden enmascararse usando multiplexación de enlace adaptativa. Al mismo tiempo, la latencia de extremo a extremo puede controlarse usando codificación de redundancia en forma de corrección de errores directa a nivel de paquetes. El control sobre el equilibrio entre ancho de banda-latencia es la base de proporcionar calidad de servicio de manera eficiente.
Rentabilidad - las comunicaciones de múltiples trayectorias permiten a los operadores reutilizar de manera eficiente su infraestructura de múltiples tecnologías y múltiples bandas existente y ofrecer conexiones de alta velocidad sin incurrir en los costes significativos asociados con el lanzamiento de una nueva red de alto rendimiento.
La figura 4 muestra esquemáticamente un equipo de usuario. Las flechas en esta figura muestran datos de enlace ascendente que viajan desde una aplicación en el teléfono hacia la red; en donde datos de enlace descendente tales como datos de vídeo se reciben en el equipo de usuario y se envían a una aplicación tal como una aplicación de visualización para esos datos de vídeo, entonces las flechas simplemente se invertirán.
Los datos de aplicación generados por una aplicación dentro del dominio de usuario se enrutan hacia/desde una aplicación de conversión que proporciona un protocolo de múltiples trayectorias dentro de una red privada virtual en el dominio de usuario a través de una interfaz virtual dentro del núcleo o dominio de control de red del equipo de usuario. La aplicación genera datos y los emite hacia un puerto de salida de una manera convencional a través del núcleo. El flujo de datos tiene cabeceras que cumplen con un protocolo de transporte de trayectoria individual de legado. El flujo
de datos se intercepta por la interfaz virtual y se desvía a la aplicación de conversión dentro de la red privada virtual. Por lo tanto, durante el enlace ascendente, el servicio de red privada virtual (VPN) divide el flujo de datos de trayectoria individual de entrada de la aplicación en múltiples subflujos de salida que luego se reenvían a través de múltiples interfaces físicas, por ejemplo LTE y WiFi, al servidor de contenido remoto, a través de un nodo proxy intermedio.
Durante el enlace ascendente, la lógica de conversión dentro de la VPN actúa eliminando las cabeceras que cumplen con el protocolo de transporte de trayectoria individual que divide el flujo en múltiples flujos y añadiendo cabeceras compatibles con un protocolo de múltiples trayectorias. Este protocolo puede ser un protocolo patentado ya que necesita interpretarse únicamente por el nodo proxy intermedio. A continuación se añaden cabeceras adicionales según un protocolo de transporte de trayectoria individual de legado y se usan por la red para enrutar los múltiples flujos. Estas cabeceras indican que los múltiples flujos de datos se deben enrutar a través de un nodo proxy intermedio.
Cuando se reciben datos de enlace descendente en el equipo de usuario, se reciben como múltiples subflujos de entrada formados a partir de un flujo de datos individual emitido por el servidor remoto que se ha desplazado a través de un nodo proxy intermedio y se ha dividido divide en los múltiples flujos de datos que se reciben en las diferentes interfaces. Cada flujo de datos tiene cabeceras de un protocolo de transporte de trayectoria individual y cabeceras adicionales según el protocolo de múltiples trayectorias posiblemente patentado y se enrutan por el núcleo a la red privada virtual con la lógica de conversión. Aquí, los múltiples flujos de datos se agregan por la lógica de conversión para dar un flujo de datos individual con cabeceras que cumplen con protocolo de trayectoria individual de legado como se requiere por la aplicación, después se enruta este flujo de datos individual a través de la interfaz virtual a la aplicación.
La figura 5 muestra una visión general de la arquitectura del sistema que comprende el equipo de usuario, el nodo proxy intermedio y el servidor de contenido. Un equipo de usuario de legado puede estar adaptado para el funcionamiento en donde un operador ha publicado una aplicación de conversión y el usuario la descarga y la activa. La aplicación de conversión activa la característica de red privada virtual que está disponible en muchos sistemas operativos de equipo de usuario y usa esto junto con la lógica de conversión para convertir entre flujos de datos individuales y múltiples.
Por lo tanto, como se muestra en la figura 5, la aplicación de usuario APP abre un puerto de red para intercambiar datos con un servidor de contenido remoto usando un protocolo de legado de una trayectoria individual 1 , a través del núcleo no modificado. Los datos de salida se enrutan a través de una interfaz virtual que forma parte de la red privada virtual activada y se desvían hacia/desde el servicio de VPN de espacio de usuario.
En el enlace ascendente, el servicio de VPN terminará la conexión basándose en el protocolo de legado 1 para extraer los datos de carga útil. Los datos se reenviarán a continuación a través de múltiples interfaces físicas designadas PHY/MAC en la figura 5 a un nodo proxy intermedio o de agregación desplegado por el operador usando un “protocolo 2” de múltiples trayectorias genérico. El “ protocolo 2” puede consistir en un protocolo de legado conocido tal como TCP o puede ser un protocolo nuevo/patentado/mejorado (TCP con optimización para baja latencia como se describe a continuación). Las cabeceras adicionales según el “protocolo de legado 3” del núcleo no modificado sirven como protocolo de transporte real para los múltiples flujos de datos. Por lo tanto, gran parte de la información referente a los múltiples flujos de datos se proporciona por el protocolo 2, mientras que el transporte/enrutamiento de los múltiples flujos de datos se controla según información en las cabeceras que cumplen con el protocolo de legado 3.
El proxy intermedio o de agregación está ubicado entre el UE y el servidor de contenido remoto y actúa como proxy conexión dividida, es decir, termina la conexión de múltiples trayectorias con el UE basándose en la información del protocolo 2 y reenvía los datos agregados como un flujo de datos individual usando el protocolo de legado 1 para comunicarse con el servidor, por ejemplo, a través de Ethernet. Dado que el proxy de agregación está bajo el control del operador de red o proveedor de servicios empresariales, el rendimiento de VPN puede mejorarse ejecutándose en el modo de núcleo como se indica en el ejemplo de la figura 5.
El funcionamiento de enlace descendente se realiza mediante las mismas etapas pero en el orden inverso. Por lo tanto, los datos generados por el servidor de contenido que tienen cabeceras que cumplen con el protocolo de legado 1 se transportan a través de Ethernet y se interceptan por el proxy de agregación en donde la lógica de conversión dentro del proxy de agregación dividirá el flujo de datos individual para dar múltiples flujos de datos y les proporcionará información de cabecera que cumple con un protocolo de legado o nuevo 2 que proporciona información de múltiples trayectorias y una cabecera adicional que cumple con el protocolo de legado 3 y que comprende información de transporte o enrutamiento. Después, se enrutan los múltiples flujos de datos a través de diferentes interfaces al equipo de usuario en donde la lógica de conversión combina los múltiples flujos de datos usando la información en las cabeceras de protocolo 2.
Un ejemplo de uso de TCP de múltiples trayectorias de legado como protocolo 2 se muestra en la figura 6 y se detalla a continuación. En este ejemplo, el operador de red activa la funcionalidad MPTCP de legado para comunicaciones de múltiples trayectorias en el equipo de usuario de legado.
Como se muestra en la figura 6, el conjunto de protocolos de TCP/IP se usa para implementar el “ protocolo de legado 1” para las cabeceras asociadas con el flujo de datos individual que se desvía en la interfaz virtual a la lógica de conversión dentro del modo de usuario (VPN). Aquí, se divide el flujo para dar múltiples flujos de datos y se añaden cabeceras según el “protocolo 2” que en esta realización consiste en la pila de doble capa para el MTCP normalizado del IETF a los múltiples flujos de datos. Por lo tanto, en este ejemplo, se usa un protocolo de múltiple trayectoria normalizado cuando se divide el flujo de datos individual para dar múltiples flujos de datos. Esto se indica en la figura usando TCP (MP) para indicar su dependencia de la subcapa de MPTCP, por ejemplo, en forma de opciones de MTCP para las cabeceras de TCP normalizadas.
En este ejemplo, se usa UDP/IP como capa de transporte, es decir la cabecera de transporte del “ protocolo de legado 3” , sin embargo, se podría usar TCP/IP en su lugar. Si está disponible acceso de superusuario, pueden aprovecharse puertos de RAW sin protocolo. Para garantizar la privacidad y la seguridad, el transporte a través de medios no confiables, tales como WiFi pública, puede mejorarse mediante túneles criptográficos, por ejemplo, IPSec (seguridad de protocolo de Internet). Los flujos de datos de múltiples trayectorias con estas cabeceras se enrutan al nodo proxy intermedio en donde la lógica de conversión en la VPN en modo de núcleo realiza la conversión de múltiples trayectorias a trayectoria individual y luego se transportan adicionalmente a través de Ethernet con cabeceras de protocolo de TCP de legado. Para los datos de descarga, se invierten las trayectorias.
La figura 7 muestra un ejemplo adicional que difiere del ejemplo de la figura 6 por usar un TCP de múltiples trayectorias patentado para comunicaciones de ancho de banda alto de baja latencia de 5G. Esto permite que el planificador de MPTCP envíe información de corrección de errores directa (FEC) a nivel de paquete a través de una conexión de UDP paralela. Debe observarse que, aunque en este ejemplo la información de corrección de errores se envía en su propia trayectoria paralela, en otro ejemplo, puede enviarse junto con datos en múltiples trayectorias paralelas diferentes.
Cada P paquetes de datos de carga útil van acompañados por F paquetes de datos de corrección de errores directa generados a partir de los P paquetes anteriores de datos de carga útil en la lógica de conversión. Los paquetes de FEC permiten una recuperación instantánea proactiva para hasta F paquetes perdidos de datos de carga sin recurrir a retransmisiones. El control de la razón de P/F proporciona el control de la calidad de servicio y la latencia de extremo a extremo.
Los datos de FEC pueden generarse en forma de combinaciones lineales aleatorias, combinando múltiples paquetes de datos para dar los denominados paquetes de combinación como se muestra en la figura 8. El paquete de combinación se genera como una combinación lineal aleatoria ponderada de varios paquetes de carga útil usando una operación XOR binaria. Los pesos multiplicativos se seleccionan aleatoriamente de una manera idéntica, independiente, uniforme. La recuperación de un paquete de carga útil se puede realizar en tiempo real usando los paquetes de origen/combinación recibidos y la eliminación gaussiana como se muestra en la figura 9.
Los datos de FEC se generan en la lógica de conversión en el equipo de usuario para transmisiones de enlace ascendente y en la lógica de conversión en el nodo proxy intermedio para transmisiones de enlace descendente.
En resumen, los ejemplos proporcionan una forma de desplegar comunicaciones de múltiples trayectorias y control de QoS en equipos de usuario (UE) móviles modernos tales como teléfonos inteligentes y tabletas sin la necesidad de modificar el sistema operativo del UE y, por lo tanto, cubriendo también equipos de usuario de legado.
La capacidad de los ejemplos para agregar múltiples enlaces de entrega de datos independientes para dar una conexión lógica puede aumentar significativamente el rendimiento global así como reducir la latencia de extremo a extremo gracias a la agrupación de recursos y la multiplexación. A diferencia de la agregación de portadoras convencional, el uso en realizaciones de agregación de ancho de banda entre RAT no está limitado por la disponibilidad de espectro por RAT.
Las comunicaciones de múltiples trayectorias también permiten enmascarar interrupciones temporales del ancho de banda mediante el uso de multiplexación de enlace adaptativa. Al mismo tiempo, el despliegue de protocolos patentados arbitrarios para proporcionar la información de múltiples trayectorias puede usarse, por ejemplo, para controlar la latencia de extremo a extremo usando la codificación de redundancia en forma de corrección de errores directa a nivel de paquete. Proporcionar control del equilibrio entre ancho de banda-latencia proporciona una base para proporcionar calidad de servicio de manera eficiente.
Una ventaja adicional es que permiten a los operadores de red reutilizar de manera eficiente su infraestructura de múltiples tecnologías y múltiples bandas existente y ofrecer conexiones de alta velocidad sin incurrir en los costes significativos asociados con el lanzamiento de una nueva red de alto rendimiento.
La presente descripción proporciona múltiples características innovadoras tales como:
(i) despliegue sin la necesidad de modificar el sistema operativo del UE y cubriendo también equipos de usuario de legado,
(ii) libertad para implementar protocolos tanto normalizados (de legado) como no normalizados (patentados optimizados) para comunicaciones de múltiples trayectorias, y
(iii) diseño sencillo y fiable basado en herramientas de sistema operativo convencionales que son fáciles de mantener y actualizar.
Las evaluaciones de rendimiento indican que incluso teléfonos inteligentes de recursos restringidos tales como Nexus 5 sólo presentaron un pequeño aumento inducido por VPN de la carga total de CPU, en este ejemplo desde el 15 % hasta el 21 % (es decir, una sobrecarga del 6 % con un margen de casi el 80 %) a velocidades de descarga de aproximadamente de 200 Mbps, es decir, velocidades 10 veces más altas que las que pueden alcanzarse normalmente en redes de actuales.
Un experto en la técnica reconocerá fácilmente que las etapas de diversos métodos descritos anteriormente pueden realizarse mediante ordenadores programados. En el presente documento, también se pretende que algunas realizaciones cubran dispositivos de almacenamiento de programas, por ejemplo, medios de almacenamiento de datos digitales, que son legibles por máquina o por ordenador y codifican programas de instrucciones ejecutables por máquina o ejecutables por ordenador, en donde dichas instrucciones realizan algunas o todas las etapas de dichos métodos descritos anteriormente. Los dispositivos de almacenamiento de programas pueden ser, por ejemplo, memorias digitales, medios de almacenamiento magnéticos tales como discos magnéticos y cintas magnéticas, discos duros o medios de almacenamiento de datos digitales ópticamente legibles. También se pretende que las realizaciones cubran ordenadores programados para realizar dichas etapas de los métodos descritos anteriormente.
Las funciones de los diversos elementos mostrados en las figuras, incluyendo cualquier bloque funcional etiquetado como “procesadores” o “ lógica” , pueden proporcionarse mediante el uso de hardware dedicado así como hardware que puede ejecutar software en asociación con software apropiado. Cuando se proporcionan por un procesador, las funciones pueden proporcionarse por un único procesador dedicado, por un único procesador compartido o por una pluralidad de procesadores individuales, algunos de los cuales pueden estar compartidos. Además, no debe interpretarse que el uso explícito del término “procesador” o “controlador” o “ lógica” se refiera exclusivamente a hardware que puede ejecutar software, y puede incluir implícitamente, sin limitación, hardware de procesador de señales digitales (DSP), procesador de red, circuito integrado específico de aplicación (ASIC), matriz de puertas programables en campo (FPGA), memoria de sólo lectura (ROM) para almacenar software, memoria de acceso aleatorio (RAM) y almacenamiento no volátil. También se puede incluir otro hardware, convencional y/o personalizado. De manera similar, cualquier conmutador mostrado en las figuras es únicamente conceptual. Su función puede llevarse a cabo mediante el funcionamiento de la lógica de programa, mediante lógica dedicada, mediante la interacción de control del programa y lógica dedicada, o incluso manualmente, pudiendo seleccionarse la técnica particular por el implementador tal como se entiende más específicamente a partir del contexto.
Los expertos en la técnica deberán apreciar que cualquier diagrama de bloques en el presente documento representa vistas conceptuales de conjuntos de circuitos ilustrativos que implementan los principios de la invención. De manera similar, se apreciará que cualquier gráfico de flujo, diagrama de flujo, diagrama de transición de estado, pseudocódigo y similares representa diversos procesos que pueden representarse sustancialmente en medio legible por ordenador y ejecutarse por un ordenador o procesador, tanto si dicho ordenador o procesador se muestra explícitamente como si no.
Claims (9)
- REIVINDICACIONESi. Un equipo de usuario que comprende un dominio de control de red y un dominio de usuario, pudiendo hacerse funcionar dicho equipo de usuario para recibir y transmitir datos a través de múltiples trayectorias de comunicación, comprendiendo dicho equipo de usuario:lógica de conversión dentro de dicho dominio de usuario que puede hacerse funcionar para convertir entre un flujo de datos individual y múltiples flujos de datos formados a partir de dicho flujo de datos individual, de modo que pueden usarse al menos dos de dichas múltiples trayectorias de comunicación para la transmisión de dichos múltiples flujos de datos formados a partir de dicho flujo de datos individual; en donde dicho flujo de datos individual comprende información de cabecera que cumple con un primer protocolo de transporte;caracterizado porquedicha lógica de conversión puede hacerse funcionar para añadir información de cabecera que cumple con un protocolo de transporte adicional a dichos múltiples flujos de datos, conteniendo dicha información de cabecera añadida información para enrutar dichos múltiples flujos de datos a un nodo proxy intermedio.
- 2. Un equipo de usuario según la reivindicación 1, en donde dicha lógica de conversión puede hacerse funcionar además para añadir información de cabecera que cumple con un segundo protocolo a dichos múltiples flujos de datos, proporcionando dicha información de cabecera añadida una indicación de cómo los datos en dichos múltiples flujos de datos se refieren a paquetes de datos en dicho flujo de datos individual.
- 3. Un equipo de usuario según la reivindicación 1 ó 2, en donde dicha lógica de conversión puede hacerse funcionar para eliminar cabeceras que cumplen con dicho primer protocolo de transporte; y añadir cabeceras que cumplen con dicho protocolo de transporte adicional cuando se convierte entre dicho flujo de datos individual y dichos múltiples flujos de datos.
- 4. Un equipo de usuario según cualquier reivindicación anterior, comprendiendo dicho equipo de usuario además:una interfaz virtual dentro de dicho dominio de control de red, estando dicha interfaz virtual configurada para enrutar flujos de datos entre una aplicación de usuario en dicho dominio de usuario y dicha lógica de conversión.
- 5. Un equipo de usuario según cualquier reivindicación anterior; en dondedicha lógica de conversión puede hacerse funcionar en respuesta a la recepción de dichos múltiples flujos de datos para generar dicho flujo de datos individual a partir de dichos múltiples flujos de datos.
- 6. Un equipo de usuario según cualquiera de las reivindicaciones 1 a 3, en donde dicho primer protocolo de transporte no tiene el beneficio de información de cabecera adicional y, por lo tanto, es un protocolo de transporte más complejo que dicho protocolo de transporte adicional.
- 7. Un equipo de usuario según cualquier reivindicación anterior, en donde al menos uno de dichos múltiples flujos de datos comprende códigos de corrección de errores para datos dentro de dicho flujo de datos individual.
- 8. Un equipo de usuario según la reivindicación 7, en donde dicha lógica de conversión puede hacerse funcionar para generar dichos códigos de corrección de errores asociados con dichos datos de dicho flujo de datos individual y para transmitir dichos códigos de corrección de errores a lo largo de dicho al menos uno de dichos múltiples flujos de datos.
- 9. Un método realizado en un equipo de usuario, comprendiendo dicho equipo de usuario un dominio de control de red y un dominio de usuario, pudiendo hacerse funcionar dicho equipo de usuario para recibir y transmitir datos a través de múltiples trayectorias de comunicación que tienen diferentes propiedades, comprendiendo dicho método:convertir dentro de dicho dominio de usuario entre un flujo de datos individual y múltiples flujos de datos de modo que pueden usarse al menos dos de dichas múltiples trayectorias de comunicación para la transmisión de dicho flujo de datos individual; en donde dicho flujo de datos individual comprende información de cabecera que cumple con un primer protocolo de transporte;caracterizado porquedichos múltiples flujos de datos comprenden información de cabecera que cumple con un protocolo de transporte adicional para enrutar dichos múltiples flujos de datos a un nodo proxy intermedio.Un sistema que comprende un equipo de usuario según una cualquiera de las reivindicaciones 1 a 8 y un nodo proxy intermedio que puede hacerse funcionar para recibir y reenviar señales transmitidas entre dicho equipo de usuario y un servidor, comprendiendo dicho nodo proxy intermedio:múltiples interfaces de equipo de usuario para comunicarse a través de múltiples trayectorias de comunicación con un equipo de usuario; yuna interfaz de servidor para comunicarse con un servidor a través de trayectoria ruta de comunicación individual;comprendiendo dicho nodo proxy intermedio lógica de conversión que puede hacerse funcionar para convertir entre múltiples flujos de datos y un flujo de datos individual, de modo que un flujo de datos individual enviado a través de dicha trayectoria de comunicación entre dicho servidor y dicho nodo proxy intermedio se envía como múltiples flujos de datos a través de múltiples trayectorias de datos entre dicho equipo de usuario y dicho nodo proxy intermedio; en donde dicho flujo de datos individual comprende información de cabecera que cumple con un primer protocolo de transporte; y dichos múltiples flujos de datos comprenden información de cabecera que cumple con un protocolo de transporte adicional, pudiendo hacerse funcionar dicha lógica de conversión para cambiar cabeceras en dichos flujos de datos cuando se convierte entre dicho flujo de datos individual y dichos múltiples flujos de datos.Un sistema según la reivindicación 10,en donde dicho primer protocolo de transporte no tiene el beneficio de información de cabecera adicional y, por lo tanto, es un protocolo de transporte más complejo que dicho protocolo de transporte adicional.Un método realizado por un sistema que comprende un método realizado en un equipo de usuario según la reivindicación 9 y un método realizado en un nodo proxy intermedio para recibir y reenviar señales transmitidas entre dicho equipo de usuario y un servidor, comprendiendo dicho nodo proxy intermedio:una interfaz de equipo de usuario para comunicarse a través de múltiples trayectorias de comunicación de diferentes tipos con el equipo de usuario; yuna interfaz de servidor para comunicarse con un servidor a través de trayectoria ruta de comunicación individual;dicho método comprende convertir entre múltiples flujos de datos y un flujo de datos individual eliminando cabeceras que cumplen con un primer protocolo de transporte y añadiendo cabeceras que cumplen con un protocolo de transporte adicional, de modo que un flujo de datos individual enviado a través de dicha trayectoria de comunicación entre dicho servidor y dicho nodo proxy intermedio se envía como múltiples flujos de datos a través de múltiples trayectorias de datos entre dicho equipo de usuario y dicho nodo proxy intermedio.Un programa informático que, cuando se ejecuta por un procesador, puede hacerse funcionar para controlar dicho procesador para realizar un método según la reivindicación 9 ó 12.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP16306173.2A EP3297322B1 (en) | 2016-09-15 | 2016-09-15 | Multiple path transmission of data |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2922416T3 true ES2922416T3 (es) | 2022-09-14 |
Family
ID=57003462
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES16306173T Active ES2922416T3 (es) | 2016-09-15 | 2016-09-15 | Transmisión de trayectoria múltiple de datos |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US11128559B2 (es) |
| EP (1) | EP3297322B1 (es) |
| JP (1) | JP6848053B2 (es) |
| CN (1) | CN109716818B (es) |
| ES (1) | ES2922416T3 (es) |
| WO (1) | WO2018050775A1 (es) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3586489B1 (en) | 2017-02-24 | 2023-09-06 | Alcatel Lucent | Methods and network elements for multi-connectivity control |
| CN110730248B (zh) * | 2019-10-24 | 2020-10-27 | 北京大学 | 一种多路径传输中继设备及方法 |
| CN110621040B (zh) * | 2019-10-24 | 2021-02-02 | 北京大学 | 一种实现多路并行传输通信的方法和系统 |
| CN112243253B (zh) * | 2019-10-24 | 2022-07-08 | 北京大学 | 一种通信设备 |
| US12381813B2 (en) | 2019-10-24 | 2025-08-05 | Peking University | Location-awareness-based network intermediate device |
| CN110635988B (zh) * | 2019-10-24 | 2020-10-27 | 北京大学 | 一种用于多路径传输的数据转发方法及设备 |
| ES2951036T3 (es) * | 2020-08-20 | 2023-10-17 | Deutsche Telekom Ag | Identificación de multiconectividad en cascada y mitigación de efectos de interferencia de multiconectividad en cascada |
| US12166825B2 (en) | 2022-08-25 | 2024-12-10 | Cisco Technology, Inc. | Telemetry over quic |
| CN120321213B (zh) * | 2025-06-05 | 2025-10-17 | 阿里云计算有限公司 | 数据处理方法、设备、存储介质和程序产品 |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5097620B2 (ja) * | 2008-06-03 | 2012-12-12 | 株式会社日立製作所 | マルチパス通信システム |
| US20120188949A1 (en) * | 2011-01-20 | 2012-07-26 | Motorola-Mobility, Inc. | Wireless communication device, wireless communication system, and method of routing data in a wireless communication system |
| US20130064198A1 (en) * | 2011-09-14 | 2013-03-14 | Qualcomm Incorporated | Multipath transport tunnel over multiple air interfaces connecting wireless stations |
| US9264353B2 (en) * | 2011-09-22 | 2016-02-16 | Qualcomm Incorporated | Dynamic subflow control for a multipath transport connection in a wireless communication network |
| US9888042B2 (en) * | 2013-05-21 | 2018-02-06 | Citrix Systems, Inc. | Systems and methods for multipath transmission control protocol connection management |
| US9456464B2 (en) * | 2013-06-06 | 2016-09-27 | Apple Inc. | Multipath TCP subflow establishment and control |
| KR102173084B1 (ko) * | 2013-08-23 | 2020-11-02 | 삼성전자주식회사 | 무선 통신 시스템에서 데이터 패킷 송수신 방법 및 장치 |
| US9762702B2 (en) * | 2014-01-14 | 2017-09-12 | Apple Inc. | Multipath TCP signaling with application specific tags |
| MX358438B (es) * | 2014-01-24 | 2018-08-21 | Ericsson Telefon Ab L M | Métodos, nodos de red, sistemas, y productos de programas de cómputo para controlar el uso de tcp de trayectoria múltiple. |
| JP2016082438A (ja) | 2014-10-17 | 2016-05-16 | 日本電気株式会社 | 通信制御装置、無線通信システム、通信制御方法及び無線基地局 |
| FR3027478B1 (fr) * | 2014-10-20 | 2016-12-09 | Sagemcom Broadband Sas | Procede de creation d'un sous flux de paquets de donnees. |
-
2016
- 2016-09-15 EP EP16306173.2A patent/EP3297322B1/en active Active
- 2016-09-15 ES ES16306173T patent/ES2922416T3/es active Active
-
2017
- 2017-09-14 US US16/329,500 patent/US11128559B2/en active Active
- 2017-09-14 CN CN201780056590.1A patent/CN109716818B/zh active Active
- 2017-09-14 WO PCT/EP2017/073192 patent/WO2018050775A1/en not_active Ceased
- 2017-09-14 JP JP2019514815A patent/JP6848053B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| EP3297322A1 (en) | 2018-03-21 |
| US11128559B2 (en) | 2021-09-21 |
| EP3297322B1 (en) | 2022-06-22 |
| US20190199619A1 (en) | 2019-06-27 |
| WO2018050775A1 (en) | 2018-03-22 |
| CN109716818B (zh) | 2022-04-22 |
| CN109716818A (zh) | 2019-05-03 |
| JP6848053B2 (ja) | 2021-03-24 |
| JP2019537293A (ja) | 2019-12-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2922416T3 (es) | Transmisión de trayectoria múltiple de datos | |
| US12184554B2 (en) | Multi-access management service packet classification and prioritization techniques | |
| EP3586489B1 (en) | Methods and network elements for multi-connectivity control | |
| ES2905499T3 (es) | Nodos SDN híbridos divididos horizontalmente configurados por Openflow | |
| ES2644311T3 (es) | Manipulación de mensajes de señalización en el plano de datos en una arquitectura definida por software | |
| US11637771B2 (en) | Technologies for managing network traffic through heterogeneous networks | |
| CN105814941B (zh) | 用于多连接通信的一体化子层 | |
| US11310078B2 (en) | Cipher stream based secure packet communications with key stream transmission over diverse paths | |
| US20080291846A1 (en) | Dual radio wireless mesh network access point | |
| US20220150059A1 (en) | Forwarding device, key management server device, communication system, forwarding method, and computer program product | |
| PT2335395E (pt) | Método de fornecimento de comunicação de dados a um veículo | |
| US20220278970A1 (en) | Anonymous communication over virtual, modular and distributed satellite communications network | |
| EP2706674A1 (en) | Outdoor wireless modem and signal processing method thereof | |
| CN113271176A (zh) | 网络编码方法和通信装置 | |
| WO2017031326A1 (en) | Scalable software-defined networking (sdn) bloom filter-based forwarding | |
| ES2804676T3 (es) | Método para implementar un túnel de GRE, un punto de acceso y una puerta de enlace | |
| CN104067526B (zh) | 用于在无线通信系统中传输回程数据的方法 | |
| WO2017147076A1 (en) | Methods, apparatuses and systems directed to common transport of backhaul and fronthaul traffic | |
| ES2844185T3 (es) | Procedimiento para optimizar la eficiencia espectral en un contexto de interconexión MPLS | |
| WO2022214627A1 (en) | Routing data in an integrated access and backhaul network | |
| US12438957B1 (en) | Method and system for IP header compression | |
| ES3031981T3 (en) | Mp-dccp proxy to enable multipath transmission of dccp data packets between a sender and a receiver | |
| ES2735416T3 (es) | Terminal móvil de comunicaciones y sistema con un terminal móvil de comunicaciones | |
| ES3003483T3 (en) | Method for using a user equipment with at least one telecommunications network, user equipment, system or telecommunications network, program and computer-readable medium | |
| WO2015108458A1 (en) | Method nodes and computer program for enabling of data traffic separation |