ES2746067T3 - Planificación de MPTCP - Google Patents

Planificación de MPTCP Download PDF

Info

Publication number
ES2746067T3
ES2746067T3 ES13766726T ES13766726T ES2746067T3 ES 2746067 T3 ES2746067 T3 ES 2746067T3 ES 13766726 T ES13766726 T ES 13766726T ES 13766726 T ES13766726 T ES 13766726T ES 2746067 T3 ES2746067 T3 ES 2746067T3
Authority
ES
Spain
Prior art keywords
mptcp
subflows
tcp
scheduler
subflow
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
ES13766726T
Other languages
English (en)
Inventor
Paul Schliwa-Bertling
Michael Eriksson
Rashmi Purushothama
Dinand Roeland
Jari Vikberg
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2746067T3 publication Critical patent/ES2746067T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/12—Wireless traffic scheduling
    • H04W72/1215—Wireless traffic scheduling for collaboration of different radio technologies
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H04L45/245—Link aggregation, e.g. trunking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1078—Resource delivery mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/12—Communication route or path selection, e.g. power-based or shortest path routing based on transmission quality or channel quality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/34—Modification of an existing route
    • H04W40/36—Modification of an existing route due to handover
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/30—Resource management for broadcast services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/18—Management of setup rejection or failure

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un método realizado en un planificador (61) Protocolo de Control de Transmisión de Múltiples Caminos, MPTCP, que planifica un flujo TCP entre un primer par (7) y un segundo par (2) capaz de MPTCP, el método comprende: establecer (91) el flujo TCP que comprende al menos dos subflujos (8) que conectan el segundo par (2) capaz de MPTCP, cada subflujo que está asociado con una dirección para el segundo par capaz de MPTCP; recibir (92) información externa relativa a al menos uno de los dos subflujos (8); y planificar (93) datos en el flujo TCP en base a la información externa recibida (92), donde la planificación (93) comprende elegir en qué subflujo o subflujos de los al menos dos subflujos (8) planificar los datos a través, en base a la información externa recibida (92) caracterizado por la recepción (92) de información externa comprende recibir información de que uno de los al menos dos subflujos (8) ha sido o será terminado debido a un traspaso para habilitar al planificador (61) a enviar datos a través de otro subflujo, sin tener que esperar un acuse de recibo TCP para los datos enviados que han sido perdidos debido al subflujo que ha sido terminado, y donde la planificación (93), en base a la información recibida (92) de la terminación del subflujo, comprende cualquiera de: el planificador (61) MPTCP inicia emisión múltiple de forma que un paquete TCP o paquetes TCP del flujo TCP son enviados temporalmente a una pluralidad de subflujos (8); el planificador (61) MPTCP reduce el uso de uno de los al menos dos subflujos (8); el planificador (61) MPTCP deja de usar uno de los al menos dos subflujos (8); o el planificador (61) MPTCP reenvía el paquete TCP o paquetes TCP ya enviados a través de uno de los al menos dos subflujos (8) a través de otro de los al menos dos subflujos (8) sin esperar un tiempo de acuse de recibo para el paquete TCP o los paquetes TCP ya enviados.

Description

DESCRIPCIÓN
Planificación de MPTCP
Campo técnico
La presente descripción se refiere a un método y dispositivos para planificación del Protocolo de Control de Transmisión de Múltiples Caminos (MPTCP) entre pares.
Antecedentes
Muchos servidores hoy son locales de manera múltiple. Por lo tanto, tienen múltiples caminos para la conectividad a través de una o más tecnologías de acceso. Las comunicaciones del Protocolo de Control de Transmisión (TCP)/Protocolo de Internet (IP) normales restringen estos servidores locales múltiples a usar solo una de las interfaces/caminos disponibles por sesión, donde el camino se define como un par de direcciones IP (origen, destino). La Fuerza de Trabajo de Ingeniería de Internet (IETF) está actualmente investigando un mecanismo que usa múltiples caminos entre los pares que se comunican de manera simultanea durante una sesión de comunicación. La Solicitud de Comentarios (RFC) de la IETF número 6824 propone un conjunto de extensiones de las operaciones de múltiples caminos del TCP tradicional cuando hay múltiples direcciones disponibles. Esto es referido como TCP de múltiples caminos (MPTCP).
Las ventajas de usar múltiples caminos de manera concurrente son:
1. Mejora el uso de los recursos de red (por ejemplo, aumenta el ancho de banda debido a la puesta en común de recursos)
2. Mejora la experiencia de usuario a través de mayor rendimiento.
3. Permite la tolerancia frente a fallos de una interfaz a otra (por ejemplo, cliente móvil).
4. Permite que una única conexión de datos use varias interfaces de manera simultánea.
Un escenario de uso para MPTCP es ilustrado en la figura 1 donde dos servidores A y B que se comunican son múltiplemente locales y múltiplemente direccionados. Cada servidor proporciona dos conexiones separadas a Internet que ofrece cuatro caminos diferentes entre ellos (A1-B1, A1-B2, A2-B1 y A2-B2).
Una conexión TCP tradicional entre los servidores A y B hará uso de solo uno de los caminos disponibles mientras que la conexión MPTCP hace uso de los cuatro caminos disponibles entre los servidores A y B. Una conexión MPTCP es similar a una conexión TCP normal y se define en la RFC 6824 como un conjunto de uno o más subflujos, sobre el cual una aplicación se puede comunicar entre dos servidores. Un “subflujo” es definido en la RFC 6824 como un flujo de segmentos de TCP que operan sobre un camino individual, que forma parte de una conexión MPTCP más grande. Un subflujo es iniciado y terminado de manera similar a una conexión TCP normal.
El MPTCP es un protocolo extremo a extremo que requiere que ambos servidores soporten MPTCP para beneficiarse de MPTCP. Por tanto, MPTCP está todavía en un estado inicial de despliegue, las probabilidades de que todos los servidores en Internet soporten MPTCP son muy bajas. Para superar este problema y beneficiarse de MPTCP incluso aunque ambos servidores en comunicación no soporten MPTCP, un proxy MPTCP puede ser usado para convertir flujos de MPTCP a TCP y viceversa.
Un caso de uso es ilustrado en la figura 2. Un Equipo de Usuario (UE) capaz de MPTCP (cf. Servidor A en la figura 1) es controlado por el operador y establece varios subflujos MPTCP al proxy MPTCP emplazado en la red del operador. Este proxy a su vez establece un único flujo TCP a un servidor en Internet (cf. Servidor B en la figura 1 que es en cambio capaz de MPTCP y no necesita un proxy MPTCP) que no es capaz de MPTCP. En el escenario descrito, el UE que soporta MPTCP puede todavía obtener los beneficios de MPTCP aunque el servidor en el otro extremo no sea consciente del MPTCP.
Así un principio principal del TCP de múltiples caminos (MPTCP) es agregar un conjunto de conexiones TCP por ejemplo sobre diferentes interfaces inalámbricas tal como un Proyecto de Asociación de 3a Generación (3GPP) Red de Acceso por Radio (RAN) y RAN de Red de Área Local Inalámbrica (WLAN) (por ejemplo Wi-Fi) (o incluso diferentes accesos del 3GPP celular simultáneos). El MPTCP tiene múltiples subflujos y es capaz de distribuir la carga en todos los subflujos. Dado que la multiplexación de las diferentes conexiones es a nivel TCP, permite separar el control de congestión para cada subflujo.
Las figuras 3a y 3b muestran las diferencias entre el TCP estándar y la pila de protocolos del MPTCP. La interfaz de la aplicación, esto es la API de la quíntupla, no cambia y los cambios principales son entre esta API y la capa de IP. Las capas de TCP e IP en la pila de protocolos son divididas entre los diferentes subflujos.
MPTCP proporciona la posibilidad de usar de manera completa y maximizada los diferentes subflujos TCP. Por ejemplo, en el caso de un subflujo TCP en un acceso del 3GPP y otro en un acceso Wi-Fi, el rendimiento total podría ser la suma de esos subflujos. La figura 4 muestra un ejemplo de arquitectura del protocolo del plano de usuario para el caso cuando MPTCP podría usar Evolución a Largo Plazo (LTE) del 3GPP y WLAN/Wi-Fi de manera simultánea.
En un caso ejemplar de MPTCP, el UE está conectado de manera simultanea tanto a LTE como a Wi-Fi/WLAN. La aplicación en el UE ha abierto una quíntupla TCP y envía un flujo de bits en la API interna. La capa MPTCP (también llamada planificador MPTCP) ha establecido dos subflujos TCP diferentes, el subflujo 1 a través de WLAN/Wi-Fi y el subflujo 2 a través de LTE. Ambos subflujos son hacia un Proxy MPTCP que además se comunica con otro servidor que usa solo TCP. El planificador MPTCP es la función que decide cómo los diferentes paquetes se hacen corresponder con los dos subflujos. Puede haber un planificador MPTCP en el UE para la planificación del enlace ascendente y uno en el proxy MPTCP para la planificación del enlace descendente. El planificador MPTCP aplica por ejemplo la planificación “round-robin” esto es el primer segmento TCP es enviado en el subflujo 2, el segundo en el subflujo 1, el tercero otra vez en el subflujo 2 etc. Otro ejemplo es que el planificador MPTCP usa el subflujo con el tiempo de ida y vuelta (RTT) más corto. Tal enfoque se usa normalmente en implementaciones de prototipo de núcleo de MPt Cp de hoy.
El documento WO 2012/095704 A1 se refiere a un método para proporcionar un planificador de múltiples caminos que incluye causar la generación de una tabla de búsqueda de reglas de acción que definen las acciones correspondientes a los diferentes estados respectivos en los cuales cada uno de los estados es una descripción ponderada de las medidas de rendimiento asociadas con una interfaz de datos, y que permite el uso de la tabla de búsqueda en una periodicidad predefinida durante la comunicación en un entorno de comunicación de múltiples caminos para identificar una interfaz de datos seleccionada entre una pluralidad de interfaces de datos disponibles en base a unas medidas de rendimiento actuales asociadas con la pluralidad de interfaces de datos disponibles.
El documento de Estados Unidos US 2013/0114481 describe un enfoque de codificación para un protocolo de comunicación de red robusto y flexible. Mediante el uso de la codificación, es posible eliminar la necesidad de seguir identidades de paquetes, y por lo tanto, es posible reducir la sobrecarga de coordinación asociada con muchos protocolos convenciones. El método y sistema descritos en este documento aprovechan múltiples caminos, interfaces, medios, servidores, y ubicaciones de almacenamiento disponibles en la red. El protocolo propuesto permite una respuesta rápida a la congestión mediante el balanceo de carga sobre diferentes recursos de red. El método también permite traspasos verticales suaves entre redes heterogéneas. En una realización, un archivo multimedia es dividido en trozos y transmitido mediante el uso de un protocolo de transporte a medida para cumplir los requisitos de retraso de las aplicaciones de flujos multimedia. También descritas hay diferentes estrategias de codificación para la entrega de trozos en base a un nivel de urgencia de cada trozo.
Compendio
La invención se define por un método para planificar un flujo TCP en MPTCP, un planificador MPTCP correspondiente y un programa informático, como se define por las reivindicaciones independientes 1, 9, 12. Más realizaciones son definidas en sus reivindicaciones dependientes respectivas. Las realizaciones que no caen dentro del alcance del conjunto anexo de reivindicaciones deben interpretarse como información de antecedentes útil solo para comprender la invención.
El actual comportamiento del MPTCP es que el planificador MPTCP proporciona su algoritmo interno cuando decide en qué subflujo un segmento TCP (en este documento también más generalmente llamado un paquete TCP) debería ser enviado inicialmente. Si no hay acuse de recibo (ACK) en un segmento TCP a través de ese subflujo, entonces el planificador MPTCP puede intentar reenviar ese segmento TCP en otro subflujo.
Esto lleva a retrasos desafortunados debido a la espera de un ACK antes de reenviar. Una implementación de planificación de proxy MPTCP típica refleja solo el conocimiento local. La función de planificación de paquetes rompe el flujo de bytes recibidos desde la aplicación en segmentos y los transmite en uno de los subflujos disponibles. Dependiendo de cuántos datos están en cola para ser enviados, el planificador bien selecciona un subflujo, por ejemplo el que tiene el RTT más corto (si no hay datos suficientes) o usa todos los subflujos disponibles (cuando hay aun más datos para ser enviados). En el último caso, el subflujo con más ancho de banda disponible será usado más a menudo por el planificador en caso de transferencia masiva de datos. Además, el comportamiento actual del MPTCP en relación con traspasos (HO) a nivel de radio en por ejemplo 3GPP o traspasos de Punto de Acceso (AP) a AP en WLAN puede resultar en retransmisiones innecesarias. Si por ejemplo un traspaso a nivel de radio intra LTE tuviera lugar y no está libre de pérdida de paquetes, entonces una retransmisión en cualquiera de los subflujos necesitaría tener lugar. Otro ejemplo es si el UE está a punto de perder la conectividad Wi-Fi. Si la capa del MPTCP no es consciente de esto, continuaría enviando datos sobre el subflujo Wi-Fi. No recibiría un acuse de recibo y concluiría que el subflujo Wi-Fi no debería usarse más. Este proceso toma al menos un RTT. Sería por tanto beneficioso para la capa del MPTCP conocer por adelantado cuándo la Wi-Fi se perderá. Un problema con un diseño de planificación actual que solo tiene conocimiento local, por servidor, en cuenta cuando toma decisiones, es que esto optimiza el rendimiento para un par en particular, pero puede no optimizar el rendimiento para la red de comunicación en su conjunto, que incluye un conjunto de pares servidos por el proxy MPTCP.
Es un objetivo de la presente descripción proporcionar una comunicación MPTCP mejorada en vista de los problemas mencionados anteriormente en la técnica.
Según un aspecto de la presente descripción, se proporciona un método realizado en un planificador MPTCP que planifica un flujo TCP entre un primer par y un segundo par capaz de MPTCP. El método comprende establecer el flujo TCP que comprende al menos dos subflujos que conectan el segundo par capaz de MPTCP, cada subflujo que está asociado con una dirección para el segundo par capaz de MPTCP. El método también comprende recibir información externa en relación a al menos uno de los al menos dos subflujos. El método también comprende planificar datos en el flujo TCP en base a la información externa recibida, donde la planificación comprende elegir en qué subflujo o subflujos de los al menos dos subflujos planificar los datos a través, en base a la información externa recibida.
Según otro aspecto de la presente descripción, se proporciona un producto de programa informático que comprende componentes ejecutables por ordenador para causar que un planificador MPTCP realice una realización del método de la presente descripción cuando los componentes ejecutables por ordenador son ejecutados en los circuitos del procesador comprendidos en el planificador MPTCP.
Según otro aspecto de la presente descripción, se proporciona un planificador MPTCP configurado para planificar un flujo TCP entre un primer par y un segundo par capaz de MPTCP. El planificador comprende circuitos del procesador, y una unidad de almacenamiento que almacena instrucciones que, cuando son ejecutadas por los circuitos del procesador, causan que el planificador establezca el flujo TCP que comprende al menos dos subflujos que conectan el segundo par capaz de MPTCP, cada subflujo que está asociado con una dirección para el segundo par capaz de MPTCP. Las instrucciones también causan que el planificador reciba información externa relativa a al menos uno de los al menos dos subflujos. Las instrucciones también causan que el planificador planifique datos en el flujo TCP en base a la información externa recibida, donde el planificador comprende elegir en qué subflujo o subflujos de los al menos dos subflujos planificar los datos a través, en base a la información externa recibida.
Según otro aspecto de la presente descripción, se proporciona un proxy MPTCP que comprende una realización del planificador MPTCP de la presente descripción.
Según otro aspecto de la presente descripción, se proporciona una red de comunicación que comprende un proxy MPTCP que comprende una realización del planificador MPTCP de la presente descripción, y una RAN configurada para proporcionar un subflujo en un flujo TCP a través del proxy MPTCP para cada una de una pluralidad de pares conectados a la RAN.
Según otro aspecto de la presente descripción, se proporciona un segundo par capaz de MPTCP que comprende una realización del planificador MPTCP de la presente descripción.
Según otro aspecto de la presente descripción, se proporciona un programa informático para planificar un flujo TCP. El programa informático comprende código de programa informático que es capaz de, cuando se ejecuta en circuitos de un procesador de un planificador MPTCP, causar que el planificador MPTCP establezca un flujo TCP que comprende al menos dos subflujos a un segundo par capaz de MPTCP, cada subflujo que está asociado con una dirección del segundo par capaz de MPTCP. El código también es capaz de causar que el planificador reciba información externa relativa a al menso uno de los al menos dos subflujos. El código es también capaz de causar que el planificador planifique datos en el flujo TCP en base a la información externa recibida, donde el planificador comprende elegir en qué subflujo o subflujos de los al menos dos subflujos planificar los datos a través, en base a la información externa recibida.
Según otro aspecto de la presente descripción, se proporciona un producto de programa informático que comprende una realización de un programa informático de la presente descripción y medios legibles por un ordenador en los cuales el programa informático es almacenado.
Según la presente descripción, el segundo par capaz de MPTCP es así conectado a través de una pluralidad de subflujos (también llamados caminos), independientemente del número de subflujos que conectan al primer par. Las direcciones pueden ser por ejemplo una dirección IP o una dirección IP en combinación con un puerto TCP. El primer par puede por ejemplo ser un servidor conectable a través de Internet. El flujo TCP puede de manera alternativa ser llamado una sesión TCP. El flujo TCP puede en algunas realizaciones establecerse a través de un proxy MPTCP, como se discute a continuación, mientras que en otras realizaciones tanto el primero como el segundo par son capaces de MPTCP y no se necesita un proxy MPTCP.
Es ventajoso que, según la presente descripción, la planificación MPTCP puede hacerse en vista de la información externa recibida sobre los subflujos en vez de solo operar según un conjunto preprogramado de reglas internas como es actualmente el caso. Por medio de la información externa, el planificador puede por ejemplo optimizar mejor el rendimiento general y/o coste en la red de comunicación. La información externa puede por ejemplo incluir información sobre capacidades de la RAN y propiedades del par capaz de MPTCP y/o preferencias del operador de red.
Generalmente, todos los términos en las reivindicaciones han de interpretarse según su significado ordinario en el campo técnico, a menos que se defina explícitamente de otro modo en este documento. Todas las referencias a “un/uno/el elemento, aparato, componente, medios, paso, etc.” han de interpretarse abiertamente como una referencia a al menos una instancia del elemento, aparato, componente, medios, paso, etc., a menos que se exprese explícitamente de otro modo. Los pasos de cualquier método descrito en este documento no tienen que realizarse en el orden exacto descrito, a menos que se exprese explícitamente. El uso de “primero”, “segundo”, etc. para diferentes características/componentes de la presente descripción solo pretenden distinguir las características/componentes de otras características/componentes similares y no impartir ningún orden de jerarquía a las características/componentes.
Breve descripción de los dibujos
Las realizaciones serán descritas, a modo de ejemplo, con referencia a los dibujos que acompañan, en los cuales: La figura 1 es un diagrama de bloques esquemático que ilustra una realización de una comunicación entre dos pares servidores sobre Internet.
La figura 2 es un diagrama de bloques esquemático que ilustra otra realización de una comunicación entre dos pares servidores sobre Internet a través de un proxy MPTCP.
La figura 3a ilustra de manera esquemática una pila de protocolos de un par para comunicación TCP.
La figura 3b ilustra de manera esquemática una pila de protocolos de un par para comunicación MPTCP.
La figura 4 ilustra de manera esquemática una pila de protocolos de un par para comunicación MPTCP entre dos subflujos paralelos.
La figura 5 es un diagrama de bloques esquemático de una realización de una red de comunicación de la presente descripción.
La figura 6 es un diagrama de bloques esquemático de una realización de un planificador MPTCP de la presente descripción.
La figura 7 es un diagrama de bloques esquemático de una realización de un par capaz de MPTCP de la presente descripción.
La figura 8 es un diagrama de bloques esquemático de una realización de un proxy MPTCP de la presente descripción.
La figura 9 es un diagrama de flujo esquemático de una realización de un método de la presente descripción.
La figura 10 es un diagrama de bloques esquemático de una realización ejemplar de una red de comunicación de la presente descripción.
La figura 11 es un diagrama de bloques esquemático de otra realización ejemplar de una red de comunicación de la presente descripción.
La figura 12 es un diagrama de bloques esquemático de otra realización ejemplar de una red de comunicación de la presente descripción.
La figura 13 es un diagrama de señalización para un traspaso intra LTE según un ejemplo de la presente descripción.
La figura 14 es un diagrama de bloques esquemático de las pilas de protocolos respectivas en los nodos implicados en un traspaso intra LTE según un ejemplo de la presente descripción.
La figura. 15 es un diagrama de bloques esquemático de una realización ejemplar de una red de comunicación de la presente descripción, que ilustra una emisión dual de MPTCP.
La figura 16 es una ilustración esquemática de una realización de un producto de programa informático de la presente descripción.
Descripción detallada
Las realizaciones serán descritas más en detalle a continuación con referencia a los dibujos que acompañan, en los cuales se muestran ciertas realizaciones. Sin embargo, otras realizaciones en muchas formas diferentes son posibles dentro del alcance de la presente descripción. Más bien, las siguientes realizaciones son proporcionadas a modo de ejemplo de forma que esta descripción sea exhaustiva y completa, y transmita completamente el alcance de la descripción a los expertos en la técnica. Números iguales se refieren a elementos iguales a lo largo de la descripción.
La figura 5 ilustra de manera esquemática una realización de una red 1 de comunicación de la presente descripción. Una pluralidad de pares 2 conectados a Internet 6 a través de un proxy 5 MPTCP. Cada uno de los pares 2 puede por ejemplo ser un dispositivo de radio o UE, móvil o estacionario, habilitado para comunicarse sobre un canal de radio en una red 1 de comunicaciones, por ejemplo pero no limitado a por ejemplo teléfono móvil, teléfono inteligente, modem, sensores, medidores, vehículos, electrodomésticos, aparatos médicos, reproductores multimedia, cámaras, o cualquier tipo de electrónica de consumo, por ejemplo pero no limitado a televisión, radio, disposiciones de iluminación, ordenadores tableta, ordenadores portátiles, u ordenadores personales (PC). Algunos o todos los pares 2 pueden ser capaces de MPTCP y son en este documento llamados par o pares 2 para distinguirlos del primer par 7 con el cual se pueden comunicar a través del proxy 5 MPTCP y la red 6 IP. En la realización de la figura 5, hay dos RAN diferentes disponibles, una RAN 33GPP (en la figura representada por un Nodo B evolucionado LTE, eNB), y una RAN 4 WLAN representada por un punto de acceso (AP) WLAN. En la figura 5, el par 2c solo está conectado a internet 6 a través del AP 4, mientras que el par 2b está solo conectado con internet 6 a través del eNB 3. En contraste, el par 2a está conectado a internet 6 a través de tanto el eNB 3 como el AP 4, esto es a través de dos RAN diferentes.
Así, el par 2a capaz de MPTCP está conectado a través de dos caminos diferentes y puede soportar dos subflujos 8 diferentes, aquí llamados 8a a través del eNB 3 y 8b a través del AP 4, en un flujo/sesión MPTCP en comunicación con el primer par 7 a través del proxy 5 MPTCP. Además el camino o caminos/subflujo o subflujos son también posibles para el par 2a, por ejemplo a través de una RAN de Acceso Múltiple por División de Código de Banda Ancha (WCDMA). El primer par, sin embargo, está conectado solo a través de un camino/subflujo 9 TCP con el proxy 5 MPTCP, posiblemente porque el 1er par 7 no es capaz de MPTCP.
La figura 6 muestra de manera esquemática una realización de un planificador 61 MPTCP. El planificador 61 MPTCP comprende circuitos 62 del procesador por ejemplo una unidad de procesamiento central (CPU). Los circuitos 62 del procesador pueden comprender una o una pluralidad de unidades de procesamiento en la forma de microprocesador o microprocesadores. Sin embargo, otros dispositivos adecuados con capacidades de computación podrían ser incluidos en el procesador 62, por ejemplo un circuito integrado de aplicación específico (ASIC), una matriz de puertas programables de campo (FPGA) o un dispositivo lógico programable complejo (CPLD). El procesador 62 es configurado para ejecutar uno o más programas informáticos o software almacenado en una unidad 63 de almacenamiento por ejemplo una memoria. La unidad de almacenamiento es considerada como medios legibles por un ordenador y puede por ejemplo ser en la forma de una Memoria de Acceso Aleatorio (RAM), una memoria Flash u otra memoria de estado sólido, o un disco duro, o una combinación de ellos. Los circuitos 62 del procesador están también configurados para almacenar datos en la unidad 63 de almacenamiento, según sea necesario. El planificador 61 MPTCP también comprende una interfaz 64 de comunicación, configurada para por ejemplo recibir información externa según la presente descripción y transmitir comandos de planificación.
La figura 7 muestra de manera esquemática una realización de un par 2 capaz de MPTCP. El par 2 capaz de MPTCP comprende circuitos 71 del procesador por ejemplo una unidad de procesamiento central (CPU). Los circuitos 71 del procesador pueden comprender una o una pluralidad de unidades de procesamiento en la forma de microprocesador o microprocesadores. Sin embargo, otros dispositivos adecuados con capacidades de computación podrían ser incluidos en el procesador 71, por ejemplo un circuito integrado de aplicación específico (ASIC), una matriz de puertas programables de campo (FPGA) o un dispositivo lógico programable complejo (CPLD). El procesador 71 es configurado para ejecutar uno o más programas informáticos o software almacenado en una unidad 72 de almacenamiento por ejemplo una memoria. La unidad de almacenamiento es considerada como medios legibles por un ordenador y puede por ejemplo ser en la forma de una Memoria de Acceso Aleatorio (RAM), una memoria Flash u otra memoria de estado sólido, o un disco duro, o una combinación de ellos. Los circuitos 71 del procesador están también configurados para almacenar datos en la unidad 72 de almacenamiento, según sea necesario. El par 2 capaz de MPTCP también comprende un transmisor 73, un receptor 74 y una antena 75, que pueden ser combinados para formar un transceptor o para estar presentes como unidades distintas dentro del par 2 capaz de MPTCP. El transmisor 73 es configurado para cooperar con los circuitos del procesador para transformar bits de datos a ser transmitidos sobre una interfaz de radio a una señal de radio adecuada según la tecnología de acceso por radio (RAT) usada por la RAN 3 y/o 4 a través de la cual los bits de datos han de ser transmitidos. El receptor 74 es configurado para cooperar con los circuitos 71 del procesador para transformar una señal de radio recibida a bits de datos. La antena 75 puede comprender una única antena o una pluralidad de antenas, por ejemplo para diferentes frecuencias y/o para comunicación MIMO (Múltiple Entrada Múltiple Salida). La antena 75 es usada por el transmisor 73 y el receptor 74 para transmitir y recibir, respectivamente, señales de radio. Si el aparato 61 planificador es integrado o de otra forma asociado con el par 2 capaz de MPTCP, el procesador 71 del par 2 capaz de MPTCP puede también funcionar como o comprender el procesador 62 del planificador 61, la unidad 72 de almacenamiento del par 2 capaz de MPTCP puede también funcionar como o comprender la unidad 63 de almacenamiento del planificador 61 y/o el transmisor 73 y el receptor 74 del par 2 capaz de MPTCP puede ser parte de o asociado con la interfaz 64 de comunicación del planificador 61.
La figura 8 muestra de manera esquemática una realización de un proxy 5 MPTCP. El proxy 5 MPTCP comprende circuitos 81 del procesador por ejemplo una unidad de procesamiento central (CPU). Los circuitos 81 del procesador pueden comprender una o una pluralidad de unidades de procesamiento en la forma de microprocesador o microprocesadores. Sin embargo, otros dispositivos adecuados con capacidades de computación podrían ser incluidos en el procesador 81, por ejemplo un circuito integrado de aplicación específico (ASIC), una matriz de puertas programables de campo (FPGA) o un dispositivo lógico programable complejo (CPLD). El procesador 81 es configurado para ejecutar uno o más programas informáticos o software almacenado en una unidad 82 de almacenamiento por ejemplo una memoria. La unidad de almacenamiento es considerada como medios legibles por un ordenador y puede por ejemplo ser en la forma de una Memoria de Acceso Aleatorio (RAM), una memoria Flash u otra memoria de estado sólido, o un disco duro, o una combinación de ellos. Los circuitos 81 del procesador están también configurados para almacenar datos en la unidad 82 de almacenamiento, según sea necesario. El proxy 5 MPTCP también comprende una interfaz 83 de comunicación, configurada por ejemplo para recibir mensajes desde el par 2 capaz de MPTCP y transmitir mensajes hacia el primer par 7, y viceversa. Si el aparto 61 planificador es integrado o de otro modo asociado con el proxy 5 MPTCP, el procesador 81 del proxy 5 MPTCP puede también funcionar como o comprender el procesador 62 del planificador 61, la unidad 82 de almacenamiento del proxy 5 MPTCP puede funcionar como o comprender la unidad 63 de almacenamiento del planificador 61 y/o la interfaz 83 de comunicación del proxy 5 MPTCP puede funcionar como o comprender la interfaz 64 de comunicación del planificador 61.
La figura 9 es un diagrama de flujo esquemático de una realización de un método de la presente descripción. El método es realizado en/por un planificador 61 MPTCP, por ejemplo integrado en un par 2 capaz de MPTCP o un proxy 5 MPTCP, como se discutió en este documento. El planificador está configurado para planificar un flujo TCP entre un primer par 7 y un segundo par 2 capaz de MPTCP. Un flujo TCP es establecido 91, que comprende al menos dos subflujos 8 que conectan el segundo par 2 capaz de MPTCP, cada subflujo está asociado con una dirección para el segundo par capaz de MPTCP. El flujo TCP puede ser establecido 91 de una manera convencional para establecer un camino de comunicación entre el primer par 7 y el segundo par 2 capaz de MPTCP. Dado que el segundo par 2 es capaz de MPTCP, una pluralidad de subflujos (8) puede ser establecida. Si el primer par 7 no es capaz de MPTCP, el flujo TCP puede ser establecido 91 con solo un camino/subflujo (8) al primer par 7. El planificador 61 MPTCP recibe 92 información externa relativa a al menos uno de los al menos dos subflujos 8. La información externa puede ser recibida 92 antes, durante o después de establecer 91 el flujo TCP. La información externa es recibida del exterior del planificador 61, por ejemplo del par 2 capaz de MPTCP o desde un operador de red de la red 1 de comunicación a través de la cual el flujo TCP es establecido 91. Entonces, los datos en el flujo TCP son planificados 93 en base a la información externa recibida 92. La planificación 93 comprende elegir en qué subflujo o subflujos de los al menos dos subflujos 8 planificar los datos a través, en base a la información externa recibida 92. En caso de dos subflujos 8 diferentes en la figura 5, correspondientes a dos diferentes direcciones para el par 2 capaz de MPTCP, el planificador 61 puede así, en base a la información externa recibida 92, optar por planificar 93 los datos a ser transmitidos en el flujo TCP a través bien del subflujo 8a sobre la RAN 3 LTE, a través del subflujo 8b sobre la RAN 4 WLAN, o a través de ambos subflujos 8a y 8b por ejemplo para maximizar el ancho de banda del flujo TCP.
En algunas realizaciones, recibir 92 información externa comprende recibir información de que uno de los al menos dos subflujos 8 es costoso, y la planificación 93 comprende evitar planificar los datos a través del subflujo costoso. Si por ejemplo el segundo par 2 capaz de MPTCP está cerca de un borde de celda en una RAN 3 celular, mucha potencia de transmisión (esto es mayor coste) puede ser necesaria para comunicarse con él sobre la RAN 3 celular, porque puede ser preferible planificar primero el segundo par 2 a través de otro subflujo 8, por ejemplo sobre la RAN 4 WLAN, y liberar recursos en la RAN celular para otro segundo par 2 que requiera una potencia de transmisión más baja y/o que no sea capaz de comunicarse a través de la RAN 4 WLAN. El coste total de la red 1 de comunicación puede ser así reducido. Esta información externa puede por ejemplo enviarse al planificador 61 desde el segundo par 2 o la RAN 3 celular.
En algunas realizaciones, recibir 92 información externa comprende recibir información de que un tipo de subflujo específico es preferido, y la planificación 93 comprende, si al menos uno de los al menos dos subflujos 8 es del tipo de subflujo especificado, planificar los datos a través de un subflujo de los al menos dos subflujos que es del tipo de camino especificado. Por ejemplo, el tipo puede ser tipo RAN, por ejemplo celular o WLAN, o tipo de RAN celular por ejemplo lTe o WCDMA. Esta información externa puede por ejemplo ser proporcionada desde un operador de red o un proveedor de servicios en la red 1 de comunicación. Por ejemplo, el operador de red puede instruir al planificador 61 a usar primero WLAN si está disponible, para reducir coste y para reducir la carga en la RAN celular.
En algunas realizaciones, recibir (92) información externa comprende recibir información de que un tipo de subflujo específico es preferido para un tipo de datos específico, y la planificación (93) comprende, si al menos uno de los al menos dos subflujos (8) es del tipo de subflujo especificado y al menos algunos de los datos a ser planificados son del tipo de datos especificado, planificar los datos del tipo de datos especificados a través de un subflujo de los al menos dos subflujos que es del tipo de subflujo especificado. Esta información externa puede por ejemplo ser proporcionada por un operador de red. Así, el operador de red puede por ejemplo instruir al planificador 61 sobre qué tipo de datos (por ejemplo datos desde ciertos servicios, o datos multimedia o datos en tiempo real, o tales) debería preferiblemente ser enviado a través por ejemplo de la RAN 3 o WLAN 4 celular. Datos en tiempo real pueden por ejemplo preferiblemente ser planificados 93 a través de un subflujo 8 con un RTT más bajo, mientras que la carga de tal subflujo de RTT bajo puede ser reducida mediante la planificación 93 de datos menos sensibles al tiempo a través de otro subflujo que tiene un RTT más largo.
En algunas realizaciones, recibir 92 información externa comprende recibir información de que uno de los al menos dos subflujos 8 ha sido o será terminado, por ejemplo debido a un traspaso o fallo del enlace. Mediante la recepción 92 de este tipo de información externa, el planificador 61 puede ser capaz de enviar datos (comprendidos en los paquetes TCP por ejemplo segmentos TCP) a través de otro subflujo, sin tener que esperar un acuse de recibo TCP (ACK TCP) para enviar datos que han sido perdidos debido al subflujo que ha sido terminado. En algunas realizaciones, la planificación 93, en base a la información recibida 92 de la terminación del subflujo, comprende que el planificador 61 MPTCP inicia múltiples emisiones de forma que el o los paquetes TCP del flujo TCP son enviados temporalmente a través de una pluralidad de los subflujos 8. Por ejemplo, si hay dos subflujos 8, el planificador 61 puede planificar una emisión dual sobre ambos subflujos para encontrar cual funciona o funciona mejor, sin perder tiempo intentando un subflujo después de otro. En otro ejemplo, cuando hay tres subflujos 8 y un traspaso está teniendo lugar en un primer subflujo, entonces la emisión múltiple puede tener lugar por ejemplo solo en el primer y segundo subflujos, o si uno de los tres subflujos se ha perdido debido a un fallo del enlace entonces la emisión múltiple puede tener lugar en los dos subflujos restantes para determinar el más adecuado. En algunas realizaciones, la planificación 93, en base a la información recibida 92 de la terminación del subflujo, comprende que el planificador 61 MPTCP reduce o minimiza el uso de uno de los al menos dos subflujos 8. Así, la pérdida y reenvío de datos puede ser reducida cuando el subflujo es terminado dado que se han planificado menos datos en ese subflujo. En algunas realizaciones, la planificación 93, en base a la información recibida 92 de la terminación del subflujo, comprende que el planificador 61 MPTCP deja de usar el uno de los al menos dos subflujos 8. Así, el planificador puede anticipar la terminación y deja de usar el subflujo sin tener que esperar un ACK que no se recibirá. En algunas realizaciones, la planificación 93, en base a la información recibida 92 de la terminación del subflujo, comprende que el planificador 61 MPTCP reenvía paquete o paquetes TCP ya enviados a través de al menos uno de los dos subflujos 8 a través de otro de los al menos dos subflujos 8 sin esperar un tiempo de acuse de recibo del paquete o paquetes TCP ya enviados.
En algunas realizaciones, el planificador 61 MPTCP es parte de un proxy 5 MPTCP, y la planificación 93 comprende planificar datos en el enlace descendente (DL) al segundo par 2 capaz de MPTCP en el flujo TCP. Para planificar el DL, el planificador puede convenientemente estar integrado en el proxy 5. En algunas realizaciones, el establecimiento 91 del flujo TCP comprende establecer dicho flujo TCP con solo un subflujo 9 entre el proxy 5 MPTCP y el primer par 7. Esto es adecuado por ejemplo si el primer par 7 no es capaz de MPTCP. Por medio del proxy 5, una pluralidad de subflujos MPTCP puede todavía establecerse 91 al segundo par 2 capaz de MPTCP. En algunas realizaciones, el proxy 5 MPTCP de manera adicional maneja una pluralidad de flujos TCP adicionales a una pluralidad de pares adicionales, por ejemplo otros pares 2 capaces de MPTCP y/o primeros pares 7. El mismo proxy 5 puede así ser usado para una pluralidad de flujos TCP mediante el uso de MPTCP.
En algunas realizaciones, el planificador 61 MPTCP es parte del segundo par 2 capaz de MPTCP, y la planificación 93 comprende planificar datos en el enlace ascendente (UL) desde el segundo par 2 capaz de MPTCP en el flujo TCP. Para planificar los datos del UL, el planificador puede convenientemente estar integrado en el segundo par 2 capaz de MPTCP.
En algunas realizaciones, como también se ha discutido anteriormente, al menos uno de los al menos dos subflujos 8 comprende una RAN 4 WLAN (cf. subflujo 8b en la figura 5).
En algunas realizaciones, como también se ha discutido anteriormente, al menos uno de los al menos dos subflujos 8 comprende una RAN 4 celular (cf. subflujo 8a en la figura 5).
Ejemplos
Más que optimizar el rendimiento por par, el planificador 61 puede lograr un mejor rendimiento a nivel de sistema cuando tiene en cuenta entradas externas. En este documento se describen diferentes modos de hacer tal planificación en un proxy 5 MPTCP mantenido por un operador mediante los ejemplos que se describen.
El planificador en un proxy MPTCP puede obtener entradas de información externa diferentes para tomar decisiones de planificación optimizadas a nivel de sistema. Entradas ejemplares son:
1. Entrada desde la RAN (por ejemplo RAN 3GPP y Wi-Fi)
2. Entrada sobre caminos 8 disponibles al par 2 capaz de MPTCP
3. Entrada sobre políticas de enrutamiento
Puede haber otra información externa que sea relevante para tomar decisiones de planificación optimizadas a nivel de sistema.
Ejemplo 1 - Información externa desde RAT (RAN 3GPP y Wi-Fi)
La RAT puede proporcionar entradas/realimentación al proxy 5 MPTCP y el planificador 61 en el proxy MPTCP puede usar esa información para tomar decisiones de planificación optimizadas a nivel de sistema como se ilustra en la figura 10. En la figura, un par 2 capaz de MPTCP está conectado con un proxy 5 MPTCP a través de dos subflujos 8, uno 8a sobre una RAN 3 celular, y otro 8b sobre Wi-Fi 4. Un único flujo/subflujo 9 conecta el proxy 5 con internet 6 y el primer par 7 (figura 5). Los caminos para la entrada de información externa desde la RAN 3 y 4 respectivas son dados como líneas punteadas en la figura. La figura también muestra una función 101 de política de cobro y reglas (PCRF) y su interfaz Gx con el proxy 5 MPTCP.
El proxy 5 MPTCP es un ejemplo ubicado en la puerta de enlace (P-GW) de la red de datos de paquetes (PDN) en la red 3GPP. Los pares 2 que están en el borde de una celda RAT (bien una celda RAT 3GPP como LTE o una celda Wi-Fi) pueden experimentar muy mal rendimiento debido a la pobre intensidad de señal. Para proporcionar un ancho de banda decente a tales pares, se requiere potencia extra que puede ser muy costosa a los operadores. La información sobre tales pares 2 que están en el borde de una celda RAT puede ser dirigida y recibida 92 por el planificador 61 MPTCP. El planificador MPTCP puede entonces tomar una decisión y establecer preferencias para tales pares para usar un subflujo 8 alternativo si está disponible.
Por ejemplo si un eNodoB envía información sobre los pares 2 que están en el borde de la celda y que usan más recursos, el planificador 61 MPTCP puede entonces establecer Wi-Fi como un subflujo 8 preferido a esos pares. De manera similar, un AP Wi-Fi puede enviar información sobre los pares 2 al borde de celda Wi-Fi que no tiene una buena cobertura y el planificador 61 MPTCP puede entonces preferir usar la RAN 33GPP sobre la Wi-Fi 4 para esos pares 2.
Ejemplo 2 - Información externa sobre caminos disponibles a los pares está presente en la P-GW
Si el proxy 5 MPTCP puede obtener información sobre los caminos/subflujos 8 disponibles a los pares 2 capaces de MPTCP, el planificador 61 puede usar esta información para distribuir pares 2 de manera uniforme dependiendo del número de subflujos 8 que tiene cada usuario.
Considere un escenario donde todos los pares 2 en una celda LTE particular obtienen muy bajo ancho de banda (digamos iMbps) y algunos de esos pares 2 tiene acceso/subflujo 8 tanto LTE como Wi-Fi. La P-Gw en la red 3GPP es consciente de los pares 2 que tienen más de un acceso. Así, el planificador 61 en el proxy 5 MPTCP que está en la P-GW puede usar esa información y establecer Wi-Fi como un subflujo 8 preferido para tales pares 2 que tienen capacidades tanto LTE como Wi-Fi. También, si algunos pares 2 tienen mucho ancho de banda sobre Wi-Fi, el planificador podría parar el uso de LTE para tales pares 2, de forma que otros pares 2 que solo tienen subflujo LTE puedan obtener mejor ancho de banda. Esta manera de compartir recursos mejorará el rendimiento del sistema general más que para un par 2 particular.
Ejemplo 3 - Entrada sobre políticas de enrutamiento
Un planificado 61 proxy MPTCP podría mejorar el rendimiento del sistema general mediante la aplicación de políticas de enrutamiento controladas por el operador. Tales políticas pueden ser preconfiguradas en el planificador, o las entradas de la función 111 de descubrimiento y selección de red de acceso (ANDSF) pueden ser alimentadas al planificador MPTCP. Las reglas ANDSF para la planificación del MPTCP podrían ser muy similares a las reglas de política de enrutamiento entre sistemas (ISRP) existentes.
Esto requeriría una nueva interfaz entre el proxy 5 MPTCP y ANDSF 111. Esto podría básicamente ser una copia de la interfaz S14 3GPP existente entre ANDSF 111 y el par 2 capaz de MPTCP (llamado UE en las figuras 10-12). Esto es ilustrado en la figura 11, donde ésta nueva interfaz es llamada S14' (S14 prima).
De manera alternativa, no se definen nuevas interfaces. En cambio, la información relevante es enviada al PCRF 101 desde el ANDSF 111 a través de una interfaz Z2 propietaria en un modo específico del vendedor y enviada desde el PCRF 101 a la P-GW a través de extensiones (específicas del vendedor) a Gx. Esta alternativa podría en particular aplicar si el proxy 5 está co-ubicado en la P-GW. Este enfoque es ilustrado en la figura 12. De manera alternativa, la información relevante puede originarse desde el PCRF 101, y así no es primer enviada desde el ANDSF 111.
El planificador 61 proxy MPTCP puede entonces aplicar políticas controladas por el operador almacenadas en la ANDSF 111. Para un par 2 particular, por ejemplo el tráfico de YouTube se enviará solo sobre Wi-Fi, la voz se enviará sobre LTE.
Ejemplo 4 - Traspasos a nivel radio
La figura 13 muestra un ejemplo de un traspaso a nivel de radio. Un par 2 capaz de MPTCP en la forma de un UE va a ser traspasado desde un eNB 3a origen a un eNB 3b destino de una RAN 3 LTE. Mostradas están también una Entidad 131 de Gestión de Movilidad (MME) de la red central (CN) de LTE, y la puerta de enlace 132 servidora. Este flujo de secuencias es del 3GPP TS 36.300 (sección 10.1.2.1 “Handover”) y los detalles son explicados más en detalle en esa sección.
Los principios principales de los traspasos a nivel de radio son que la movilidad está controlada por la red, y el UE es asistido, y se basa en los siguientes principios principales:
1. La red puede configurar el UE 2 para proporcionar reportes de mediciones en la celda actual y otras y tecnologías de acceso por radio.
2. El UE 2 proporciona las mediciones una vez que las condiciones proporcionadas como parte de la configuración de medición se cumplen.
3. La red (llamada nodo 3a origen) toma la decisión de traspaso a una celda destino manejada por un nodo 3b destino.
4. Normalmente hay señalización lateral de red entre el nodo 3a origen y el nodo 3b destino llamada señalización de preparación de traspaso.
5. Como parte de la señalación de preparación del traspaso, el nodo 3b destino proporciona un mensaje “comando de traspaso” que es transmitido de manera transparente al UE 2 a través del nodo 3a origen, y usado por el UE para acceder a la celda destino manejada por el nodo destino (llamado también ejecución del traspaso).
6. Señalización adicional puede tener lugar tanto hacia el nodo origen (para liberar recursos) como hacia la red central (para informar sobre el traspaso) después del traspaso (llamado también terminación del traspaso).
Además del enfoque del traspaso trazado anteriormente, un UE 2 puede reseleccionar a otra celda o tecnología de acceso por radio tanto tirando la conexión de radio de celda servidora como indicándolo explícitamente a la red primero. En el primer caso, la red servidora puede detectar que el UE tiró el enlace a través de una funcionalidad de monitorización del enlace de radio mientras que en el último caso el UE 2 hace a la red obviamente consciente. Es también posible que un UE 2 realice un traspaso intra WLAN. En especificaciones actuales, la decisión de traspasar a otro punto de acceso (AP) de WLAN se deja al UE. Una configuración típica es que múltiples AP son controlados por un controlador de acceso (AC) de WLAN. El Instituto de Ingeniería Eléctrica y Electrónica (IEEE) ha definido optimizaciones para traspasos rápidos de AP a AP dentro del domino de un AC (por ejemplo IEEE 802.11r-2008). En tal configuración, la red será consciente de que un traspaso AP a AP está en curso.
Realizaciones de la presente descripción pueden ser usadas de manera ventajosa para transmisión de datos mejorada durante un traspaso.
Por medio de la presente descripción, las propiedades conocidas actualmente del MPTCP pueden ser optimizadas mediante la provisión de información relacionada con recursos de radio sobre por ejemplo traspasos a nivel de radio al planificador 61 MPTCP para diferentes acciones.
El planificador 61 MPTCP es proporcionado con información relacionada con recursos radio externos desde los protocolos de nivel de radio. Ejemplos típicos son:
1. Traspaso pronto en subflujo X es probable,
2. Traspaso ocurrirá en subflujo X,
3. Traspaso ha ocurrido en subflujo X,
4. “Perderá el subflujo X”,
5. “pérdida del subflujo X es probable”,
6. “perdió el subflujo X”
El planificador 61 MPTCP entonces toma diferentes acciones en base a la información a nivel de radio, por ejemplo: 1. El planificador MPTCP inicia emisión dual o emisión múltiple de forma que todos los paquetes/segmentos TCP son enviados de manera temporal en todos los subflujos.
2. El planificador MPTCP minimiza el uso de un subflujo TCP específico.
3. El planificador MPTCP deja de usar un subflujo TCP específico.
4. El planificador MPTCP no espera un tiempo de acuse de recibo de tráfico ya enviado sobre el acceso perdido, sino que inmediatamente reenvía mediante el uso de otro subflujo TCP.
La figura 14 muestra diferentes ejemplos de cómo la información relacionada con recursos de radio puede ser proporcionada al planificador 61 MPTCP. Inicialmente las capas del protocolo del plano de control LTE diferentes (cualquiera de las mostradas) pueden recibir una indicación desde la red 1 o pueden detectar algo de manera local.
La figura 14 muestra como ejemplo una “Indicación de traspaso” recibida desde la red. Indicaciones similares son también posibles en el lado de la Wi-Fi/WLAN.
La figura 15 muestra un ejemplo del caso cuando el planificador 61 MPTCP inicia emisión dual en ambos subflujos 8 TCP (8a y 8b) después de recibir por ejemplo la “Indicación de traspaso” mostrada en la figura 14. La figura 15 cubre el planificador 61 MPTCP en el UE 2, esto es para el tráfico del enlace ascendente. Los mismos principios pueden aplicar para el planificador 61 MPTCP en el proxy 5, esto es para el tráfico del enlace descendente. La entidad que es consciente del próximo traspaso o condición de radio cambiada informaría entonces al proxy 5. Esto podría por ejemplo ser el eNB 3, MME 131, AP 4 o AC 102. La información a nivel de sistema que es enviada al proxy 5 puede por ejemplo ser información de traspaso/pérdida mencionada anteriormente. Observe que tal información a nivel de sistema podría enviarse bien desde la RAN 33GPP o desde la RAN 4 WLAN o ambas.
Se comprenderá que los ejemplos de LTE y WLAN dados aquí son solo ejemplos - la misma idea aplica a otro tipo de RAN/RAT. También, MPTCP no está restringido a solo usar dos subflujos 8, puede usar un único subflujo 8 o más de dos subflujos 8.
Ejemplo 5 - Producto de programa informático
La figura 16 ilustra un producto 160 de programa informático. El producto 160 de programa informático comprende medios 162 legibles por un ordenador que comprende un programa 161 informático en la forma de componentes 161 ejecutables por un ordenador. El programa informático/componentes 161 ejecutables por un ordenador pueden configurarse para causar que un planificador 61, por ejemplo como se discutió anteriormente para planificar un flujo TCP entre un primer par 7 y un segundo par 2 capaz de MPTCP, realice una realización del método de la presente descripción. El programa informático/componentes ejecutables por un ordenador puede ser ejecutado en los circuitos 62 del procesador del planificador 61 para causar que el planificador realice el método. El producto 160 de programa informático puede por ejemplo estar comprendido en una unidad de almacenamiento o memoria 63 comprendida en el planificador 61 y asociada con los circuitos 62 del procesador. De manera alternativa, el producto 160 de programa informático puede ser, o ser parte de, medios de almacenamiento separados, por ejemplo móvil, tal como un disco legible por un ordenador, por ejemplo CD o DVD o disco/unidad duro, o un medio de almacenamiento de estado sólido, por ejemplo una RAM o memoria Flash.
A continuación continúa otro aspecto de la presente descripción.
Según un aspecto de la presente descripción, se proporciona un planificador 61 MPTCP configurado para planificar un flujo TCP entre un primer par 7 y un segundo par 2 capaz de MPTCP. El planificador comprende medios 62 y 64 para establecer 91 el flujo t Cp que comprende al menos dos subflujos 8 que conectan el segundo par 2 capaz de MPTCP, cada subflujo está asociado con una dirección para el segundo par capaz de MPTCP. El planificador también comprende medios 62 y 64 para recibir 92 información externa relacionada con al menos uno de los al menos dos subflujos 8. El planificador también comprende medios 62 para planificar 93 datos en el flujo TCP en base a la información externa recibida 92, donde la planificación 93 comprende elegir en qué subflujo o subflujos de los al menos dos subflujos 8 planificar los datos a través, en base a la información externa recibida 92.
La presente descripción ha sido descrita principalmente con referencia a unas pocas realizaciones. Sin embargo, como será rápidamente apreciado por un experto en la técnica, otras realizaciones que las descritas anteriormente son igualmente posibles dentro del alcance de la presente descripción. Sin embargo, realizaciones ejemplares de la descripción anterior que no entran dentro del alcance de las reivindicaciones han de interpretarse solo como información, útil para comprender la invención, y no considerarse como parte de la invención reivindicada.

Claims (13)

REIVINDICACIONES
1. Un método realizado en un planificador (61) Protocolo de Control de Transmisión de Múltiples Caminos, MPTCP, que planifica un flujo TCP entre un primer par (7) y un segundo par (2) capaz de MPTCP, el método comprende: establecer (91) el flujo TCP que comprende al menos dos subflujos (8) que conectan el segundo par (2) capaz de MPTCP, cada subflujo que está asociado con una dirección para el segundo par capaz de MPTCP;
recibir (92) información externa relativa a al menos uno de los dos subflujos (8); y
planificar (93) datos en el flujo TCP en base a la información externa recibida (92), donde la planificación (93) comprende elegir en qué subflujo o subflujos de los al menos dos subflujos (8) planificar los datos a través, en base a la información externa recibida (92)
caracterizado por
la recepción (92) de información externa comprende recibir información de que uno de los al menos dos subflujos (8) ha sido o será terminado debido a un traspaso para habilitar al planificador (61) a enviar datos a través de otro subflujo, sin tener que esperar un acuse de recibo TCP para los datos enviados que han sido perdidos debido al subflujo que ha sido terminado, y donde la planificación (93), en base a la información recibida (92) de la terminación del subflujo, comprende cualquiera de:
el planificador (61) MPTCP inicia emisión múltiple de forma que un paquete TCP o paquetes TCP del flujo TCP son enviados temporalmente a una pluralidad de subflujos (8);
el planificador (61) MPTCP reduce el uso de uno de los al menos dos subflujos (8);
el planificador (61) MPTCP deja de usar uno de los al menos dos subflujos (8); o
el planificador (61) MPTCP reenvía el paquete TCP o paquetes TCP ya enviados a través de uno de los al menos dos subflujos (8) a través de otro de los al menos dos subflujos (8) sin esperar un tiempo de acuse de recibo para el paquete TCP o los paquetes TCP ya enviados.
2. El método de la reivindicación 1, donde la recepción (92) de información externa comprende recibir información de que un tipo de subflujo específico es preferido, y la planificación (93) comprende planificar los datos a través de un subflujo de los al menos dos subflujos que es del tipo de camino especificado.
3. El método de cualquiera de las reivindicaciones precedentes, donde la recepción (92) de información externa comprende recibir información de que un tipo de subflujo específico es preferido para un tipo de datos especifico, y la planificación (93) comprende planificar los datos del tipo de datos especificado a través de un subflujo de los al menos dos subflujos que es del tipo de subflujo especificado.
4. El método de cualquiera de las reivindicaciones precedentes, donde el planificador (61) MPTCP es parte de un proxy (5) MPTCP, y la planificación (93) comprende planificar el enlace descendente, DL, datos al segundo par (2) capaz de MPTCP en el flujo TCP.
5. El método de la reivindicación 4, donde el establecimiento (91) del flujo TCP comprende establecer dicho flujo TCP con solo un subflujo (9) entre el proxy (5) MPTCP y el primer par (7).
6. El método de cualquiera de las reivindicaciones 1-3, donde el planificador (61) MPTCP es parte del segundo par (2) capaz de MPTCP, y la planificación (93) comprende planificar el enlace ascendente, UL, datos desde el segundo par (2) capaz de MPt Cp en el flujo TCP.
7. El método de cualquiera de las reivindicaciones precedentes, donde al menos uno de los al menos dos subflujos (8) comprende una Red de Área Local Inalámbrica, WLAN, Red de Acceso por Radio, RAN.
8. El método de cualquiera de las reivindicaciones anteriores, donde al menos uno de los al menos dos subflujos (8) comprende una Red de Acceso por Radio celular, RAN.
9. Un Protocolo de Control de Transmisión Múltiples caminos, MPTCP, planificador (61) configurado para planificar un flujo TCP entre un primer par (7) y un segundo par (2) capaz de MPTCP, el planificador comprende: circuitos (62) del procesador; y
una unidad (63) de almacenamiento que almacena instrucciones que, cuando son ejecutados por los circuitos (62) del procesador, causan que el planificador (61):
establezca el flujo TCP que comprende al menos dos subflujos (8) que conectan el segundo par (2) capaz de MPTCP, cada subflujo que está asociado con una dirección para el segundo par capaz de MPTCP;
reciba información externa relativa a al menos uno de los dos subflujos (8); y
planifique datos en el flujo TCP en base a la información externa recibida, donde la planificación (93) comprende elegir en qué subflujo o subflujos de los al menos dos subflujos (8) planificar los datos, en base a la información externa recibida (92)
caracterizado por
la información externa comprende información de que uno de los al menos dos subflujos (8) ha sido o será terminado debido a un traspaso para habilitar al planificador (61) a enviar datos a través de otro subflujo, sin tener que esperar un acuse de recibo TCP para los datos enviados que han sido perdidos debido al subflujo que ha sido terminado, y donde
la planificación (93), en base a la información recibida (92) de la terminación del subflujo, comprende cualquiera de: el planificador (61) MPTCP inicia emisión múltiple de forma que un paquete TCP o paquetes TCP del flujo TCP son enviados temporalmente a una pluralidad de subflujos (8);
el planificador (61) MPTCP reduce el uso de uno de los al menos dos subflujos (8);
el planificador (61) MPTCP deja de usar uno de los al menos dos subflujos (8); o
el planificador (61) MPTCP reenvía el paquete TCP o paquetes TCP ya enviados a través de uno de los al menos dos subflujos (8) a través de otro de los al menos dos subflujos (8) sin esperar un tiempo de acuse de recibo para el paquete TCP o los paquetes TCP ya enviados.
10. Un proxy (5) MPTCP que comprende un planificador (61) MPTCP según la reivindicación 9.
11. Una red (1) de comunicación que comprende:
un proxy (5) MPTCP que comprende un planificador (61) MPTCP según la reivindicación 9; y
una Red de Acceso Radio, RAN, (3;4) configurada para proporcionar un subflujo (8) en un flujo TCP a través el proxy (5) MPTCP a cada uno de una pluralidad de pares (2) conectados a la RAN.
12. Un programa (161) informático para planificar un flujo de Protocolo de Control de Transmisión, TCP, el programa informático que comprende código de programa informático que es capaz de, cuando es ejecutado en circuitos (62) del procesador de un planificador (61) de Protocolo de Control de Transmisión de Múltiples Caminos, MPTCP, causar que el planificador MPTCP:
establezca (91) el flujo TCP que comprende al menos dos subflujos (8) que conectan el segundo par (2) capaz de MPTCP, cada subflujo que está asociado con una dirección para el segundo par capaz de MPTCP;
reciba (92) información externa relativa a al menos uno de los dos subflujos (8); y
planifique (93) datos en el flujo TCP en base a la información externa recibida (92), donde la planificación (93) comprende elegir en qué subflujo o subflujos de los al menos dos subflujos (8) planificar los datos, en base a la información externa recibida (92)
caracterizado por
la información externa comprende información de que uno de los al menos dos subflujos (8) ha sido o será terminado debido a un traspaso para habilitar al planificador (61) a enviar datos a través de otro subflujo, sin tener que esperar un acuse de recibo TCP para los datos enviados que han sido perdidos debido al subflujo que ha sido terminado, y donde
la planificación (93), en base a la información recibida (92) de la terminación del subflujo, comprende cualquiera de: el planificador (61) MPTCP inicia emisión múltiple de forma que un paquete TCP o paquetes TCP del flujo TCP son enviados temporalmente a una pluralidad de subflujos (8);
el planificador (61) MPTCP reduce el uso de uno de los al menos dos subflujos (8);
el planificador (61) MPTCP deja de usar uno de los al menos dos subflujos (8); o
el planificador (61) MPTCP reenvía el paquete TCP o paquetes TCP ya enviados a través de uno de los al menos dos subflujos (8) a través de otro de los al menos dos subflujos (8) sin esperar un tiempo de acuse de recibo para el paquete TCP o los paquetes TCP ya enviados.
13. Un producto (160) de programa informático que comprende un programa (161) informático según la reivindicación 12 y medios (162) legibles por un ordenador en los cuales el programa informático es almacenado.
ES13766726T 2013-08-29 2013-08-29 Planificación de MPTCP Active ES2746067T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SE2013/051013 WO2015030641A1 (en) 2013-08-29 2013-08-29 Mptcp scheduling

Publications (1)

Publication Number Publication Date
ES2746067T3 true ES2746067T3 (es) 2020-03-04

Family

ID=49237580

Family Applications (1)

Application Number Title Priority Date Filing Date
ES13766726T Active ES2746067T3 (es) 2013-08-29 2013-08-29 Planificación de MPTCP

Country Status (6)

Country Link
US (1) US10143001B2 (es)
EP (1) EP3039837B1 (es)
CN (1) CN105474598B (es)
BR (1) BR112016004142B1 (es)
ES (1) ES2746067T3 (es)
WO (1) WO2015030641A1 (es)

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104754003B (zh) * 2013-12-30 2019-01-08 腾讯科技（深圳）有限公司 传输数据的方法及系统
KR101937004B1 (ko) * 2014-01-24 2019-01-09 텔레호낙티에볼라게트 엘엠 에릭슨(피유비엘) 다중-경로 ｔｃｐ의 사용을 제어하기 위한 방법, 네트워크 노드, 시스템 및 컴퓨터 프로그램 제품
KR102184767B1 (ko) * 2014-04-01 2020-12-01 삼성전자주식회사 복수의 디바이스를 포함하는 네트워크의 통신 방법 및 장치
JP6555853B2 (ja) * 2014-05-07 2019-08-07 キヤノン株式会社 送信装置、送信制御方法及びプログラム
FR3023105A1 (fr) * 2014-06-30 2016-01-01 Orange Procede de communication tcp via des chemins multiples entre deux terminaux
KR101975684B1 (ko) 2014-07-21 2019-05-07 후아웨이 테크놀러지 컴퍼니 리미티드 링크 제어 노드, 링크 제어 방법 및 통신 시스템
EP3178220B1 (en) * 2014-08-06 2019-11-13 Nokia Solutions and Networks Oy Ipv6 interface id filter using a single pdn connection
US10721789B2 (en) * 2014-10-30 2020-07-21 Telefonaktiebolaget Lm Ericsson (Publ) Handling of backup path in a wireless communication system
US9681481B2 (en) * 2014-12-19 2017-06-13 At&T Intellectual Property I, L.P. Mobility management of wireless networks based on multipath transfer control protocol
US9871723B2 (en) * 2015-02-09 2018-01-16 Telefonaktiebolaget Lm Ericsson (Publ) Method and device for handling multi path connections
GB201502257D0 (en) * 2015-02-11 2015-04-01 Nat Univ Ireland A method of transmitting data between a source node and destination node
WO2016144224A1 (en) * 2015-03-12 2016-09-15 Telefonaktiebolaget Lm Ericsson (Publ) Methods and arrangements for multipath traffic aggregation
WO2016099371A1 (en) * 2015-06-26 2016-06-23 Telefonaktiebolaget Lm Ericsson (Publ) First network node and methods therein, for determining whether a second multi path transmission control protocol connection is to be initiated
EP3125472A1 (en) * 2015-07-30 2017-02-01 Alcatel Lucent Telecommunication system, method and computer readable medium to control how a transmission of packets of a data flow is realized
US11063785B2 (en) 2015-09-28 2021-07-13 Intel Corporation Multipath traffic management
KR102411188B1 (ko) 2015-11-30 2022-06-21 삼성전자주식회사 무선 통신 시스템에서의 혼잡 관리 장치 및 방법
US9992786B2 (en) 2016-03-31 2018-06-05 At&T Intellectual Property I, L.P. Facilitation of multipath scheduling
US10193781B2 (en) 2016-04-14 2019-01-29 At&T Intellectual Property I, L.P. Facilitation of multipath transmission control protocols
EP3255845A1 (en) * 2016-06-10 2017-12-13 Tessares SA Multipath tcp in hybrid access networks
EP3482547B1 (en) * 2016-07-08 2023-11-08 Alcatel Lucent Flow aggregation and routing for multi-connectivity client devices
KR102568436B1 (ko) 2016-07-28 2023-08-21 삼성전자 주식회사 무선 통신 시스템에서 데이터의 전송 방법 및 장치
WO2018032517A1 (zh) * 2016-08-19 2018-02-22 华为技术有限公司 业务流路由方法和设备
CN106533937B (zh) * 2016-11-01 2019-08-30 佛山科学技术学院 一种多路径分布式的报文转发方法、及基站
CN106454959B (zh) * 2016-11-01 2019-12-06 佛山科学技术学院 一种分布式网络的服务质量控制方法、及服务器
CN106572030B (zh) * 2016-11-01 2019-12-06 佛山科学技术学院 一种分布式网络中多路径发送控制方法、及系统
US10348796B2 (en) 2016-12-09 2019-07-09 At&T Intellectual Property I, L.P. Adaptive video streaming over preference-aware multipath
US11303572B2 (en) * 2017-06-02 2022-04-12 Samsung Electronics Co., Ltd. Methods and systems for accounting for data usage in MPTCP
CN107277861A (zh) * 2017-06-27 2017-10-20 广州坚和网络科技有限公司 一种移动全网络分布式接入方法
EP3669568B1 (en) * 2017-08-18 2023-10-25 Nokia Technologies Oy Traffic distribution control for wireless hybrid access networks
CN109510690B (zh) * 2017-09-14 2020-07-28 华为技术有限公司 传输报文的方法、网络组件和计算机可读存储介质
CN109729007B (zh) 2017-10-28 2022-07-22 华为技术有限公司 一种传输数据的方法、装置和设备
WO2019125483A1 (en) * 2017-12-22 2019-06-27 Nokia Technologies Oy Designs of an mptcp-aware load balancer and load balancer using the designs
WO2019166697A1 (en) * 2018-03-01 2019-09-06 Nokia Technologies Oy Conversion between transmission control protocols
ES2903241T3 (es) 2018-06-07 2022-03-31 Deutsche Telekom Ag Un sistema de comunicación para transmitir un segmento de protocolo de control de transmisión a través de una red de comunicación mediante el uso de un protocolo de control de transmisión de múltiples rutas, procedimiento y programa informático correspondientes
US11412437B2 (en) 2018-07-23 2022-08-09 Huawei Technologies Co., Ltd. Data transmission method and electronic device
US11191121B2 (en) * 2018-07-23 2021-11-30 Parallel Wireless, Inc. Multipath TCP with mesh access
CN110798868B (zh) 2018-08-02 2022-07-29 华为技术有限公司 网络切换方法、电子设备以及芯片子系统
WO2020080843A1 (en) * 2018-10-17 2020-04-23 Samsung Electronics Co., Ltd. Method and apparatus for controlling packet flow
CN111372329B (zh) 2018-12-25 2022-08-19 华为技术有限公司 一种连接建立方法及终端设备
CN111614923A (zh) * 2019-02-25 2020-09-01 疯壳(深圳)科技有限公司 一种网络实时通讯方法及其系统
US11558733B2 (en) * 2019-07-10 2023-01-17 Samsung Electronics Co., Ltd. Managing sub-flow communications in user equipment
CN113271252B (zh) * 2020-02-14 2023-06-06 中国电信股份有限公司 通信建立方法、系统和计算机可读存储介质
TWI793399B (zh) * 2020-02-14 2023-02-21 緯創資通股份有限公司 使用者裝置及資料流量傳遞之排程方法
CN113965516B (zh) * 2020-07-03 2023-10-13 华为技术有限公司 传输数据的方法和装置
US11979457B2 (en) 2020-11-06 2024-05-07 F5, Inc. Managing network services using multipath protocols
US12368665B2 (en) * 2022-02-17 2025-07-22 Cisco Technology, Inc. Differentiated multihomed route advertisement for multipath TCP
CN115883451B (zh) * 2022-09-22 2024-10-29 中国华能集团清洁能源技术研究院有限公司 基于多路径评估算法的电力二次系统网络传输方法和装置
US20240388959A1 (en) * 2023-05-19 2024-11-21 Qualcomm Incorporated Throughput enhancements for multi-link operations

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011153415A1 (en) * 2010-06-04 2011-12-08 Interdigital Patent Holdings, Inc. Mptcp and mobil ip interworking
PL2664214T3 (pl) * 2011-01-14 2021-05-04 Nokia Technologies Oy Metoda wielokierunkowego planowania na podstawie tabeli wyszukiwania
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
WO2012106032A1 (en) * 2011-02-03 2012-08-09 Interdigital Patent Holdings, Inc. Method and apparatus for establishing an end-to-end multipath connection using a multi-connection transport protocol
EP2698032A1 (en) * 2011-04-11 2014-02-19 Interdigital Patent Holdings, Inc. Session manager and source internet protocol (ip) address election
CN102185771B (zh) 2011-05-05 2013-09-04 清华大学 Mptcp中发送方数据包调度方法及系统
US20120331160A1 (en) 2011-06-22 2012-12-27 Telefonaktiebolaget L M Ericsson (Publ) Multi-path transmission control protocol proxy service
US20130064198A1 (en) * 2011-09-14 2013-03-14 Qualcomm Incorporated Multipath transport tunnel over multiple air interfaces connecting wireless stations
US8780693B2 (en) * 2011-11-08 2014-07-15 Massachusetts Institute Of Technology Coding approach for a robust and flexible communication protocol

Also Published As

Publication number Publication date
BR112016004142A2 (es) 2017-08-01
EP3039837B1 (en) 2019-07-24
US10143001B2 (en) 2018-11-27
CN105474598A (zh) 2016-04-06
WO2015030641A1 (en) 2015-03-05
EP3039837A1 (en) 2016-07-06
CN105474598B (zh) 2019-09-24
US20160212759A1 (en) 2016-07-21
BR112016004142B1 (pt) 2022-05-17

Similar Documents

Publication Publication Date Title
ES2746067T3 (es) Planificación de MPTCP
EP3586489B1 (en) Methods and network elements for multi-connectivity control
EP3085192B1 (en) Multipath tcp subflow establishing on single ip connection
EP3097670B1 (en) Methods, network node, systems, and computer program products for controlling usage of multi path tcp
US10973071B2 (en) Improving communication reliability
US20250323983A1 (en) Enabling xr service proxies
US20150237525A1 (en) Traffic Shaping and Steering for a Multipath Transmission Control Protocol Connection
EP3643116A1 (en) User plane relocation
CN103782622A (zh) 用于基于载波聚合的wlan卸载的控制和数据平面解决方案
CN111262772A (zh) 针对符合条件的包通过隧道传输和接收数据的方法和系统
KR102442083B1 (ko) Tcp 터널들 및 고유 tcp 정보를 기초로 하는 번들링 시나리오에서 패킷들의 스케줄링을 위한 방법 및 시스템
EP3252978A1 (en) Apparatuses, methods and computer programs for transmitting or receiving payload data and payload recovery data
US11246060B2 (en) Network node communication
WO2025175181A1 (en) Extending mpquic protocol support in atsss
WO2026090398A1 (en) Methods, architectures, apparatuses and systems for computing aware traffic steering sensor mobility
WO2025184461A1 (en) Methods, apparatuses and systems for service mobility-enabled computing aware traffic steering
WO2025035097A1 (en) Guaranteed bit rate quality of service flows for access traffic steering, switching, and splitting
Zhu et al. INTAREA S. Kanugovi Internet-Draft Nokia Intended status: Informational F. Baboescu Expires: December 2, 2019 Broadcom
Zhu et al. INTAREA S. Kanugovi Internet-Draft Nokia Intended status: Informational F. Baboescu Expires: September 1, 2019 Broadcom
Zhu et al. INTAREA S. Kanugovi Internet-Draft Nokia Intended status: Informational F. Baboescu Expires: March 8, 2019 Broadcom
Zhu et al. INTAREA S. Kanugovi Internet-Draft Nokia Intended status: Informational F. Baboescu Expires: July 2, 2018 Broadcom
Zhu et al. INTAREA S. Kanugovi Internet-Draft Nokia Intended status: Informational F. Baboescu Expires: October 13, 2018 Broadcom