ES3031981T3

ES3031981T3 - Mp-dccp proxy to enable multipath transmission of dccp data packets between a sender and a receiver

Info

Publication number: ES3031981T3
Application number: ES22162020T
Authority: ES
Inventors: Markus Amend
Original assignee: Deutsche Telekom AG
Current assignee: Deutsche Telekom AG
Priority date: 2022-03-15
Filing date: 2022-03-15
Publication date: 2025-07-14
Anticipated expiration: 2042-03-15
Also published as: EP4246937A1; EP4246937B1; US20250047592A1; WO2023174865A1

Abstract

Un dispositivo de conversión de paquetes, en particular un proxy MP-DCCP, para permitir el transporte de tráfico de datos DCCP multitrayecto en una red de comunicación entre un emisor y un receptor, que comprende: - una primera interfaz de ruta única dispuesta para la transmisión de paquetes de datos por una ruta de comunicación o una primera interfaz multitrayecto dispuesta para la transmisión de paquetes de datos por al menos dos rutas de comunicación; en donde el tráfico de datos transmitido por la primera interfaz de ruta única o la primera interfaz multitrayecto es tráfico de datos no MP-DCCP; - una segunda interfaz multitrayecto dispuesta para la transmisión de paquetes de datos por al menos dos rutas de comunicación; en donde el tráfico de datos transmitido por la segunda interfaz multitrayecto es tráfico de datos MP-DCCP; - un módulo de conversión de paquetes dispuesto para convertir tráfico de datos no MP-DCCP en tráfico de datos MP-DCCP y/o para convertir tráfico de datos MP-DCCP en tráfico de datos no MP-DCCP para su posterior transmisión. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Proxy de MP-DCCP para permitir transmisión multitrayectoria de paquetes de datos de DCCP entre un remitente y un receptor

La invención se relaciona con un método, un dispositivo de conversión de paquetes, un remitente, un sistema de comunicación para permitir la transmisión multitrayectoria de paquetes de datos de DCCP entre un remitente y un receptor. La invención también se relaciona con un producto de programa de ordenador que contiene instrucciones de programa para hacer que un procesador realice las etapas del método para operar los dispositivos sugeridos.

Para garantizar que los protocolos de Internet se puedan usar de la forma más universal posible y sean fáciles de implementar, es preferible que se definan en comités de estandarización [1]. En este contexto, fue propuesto y definido el denominado MP-DCCP como una extensión multitrayectoria del DCCP [2]. Esta extensión ahora hace posible que el DCCP de protocolo de trayectoria única use múltiples trayectorias para transmitir carga útil entre un remitente y un receptor en una red. Tal solución multitrayectoria hace que la transmisión de datos sea más fiable y aumenta su ancho de banda. Para este propósito, se deben distribuir los diversos paquetes de datos a las diferentes trayectorias de comunicación usando una unidad lógica de distribución apropiada, en particular un programador multitrayectoria.

Tanto DCCP como MP-DCCP se han implementado con una funcionalidad de "control de congestión" y pueden ajustar la Ventana de Congestión CNWD en consecuencia para evitar situaciones de congestión de las respectivas trayectorias.

Otros dos protocolos de Internet que se presentarán como ejemplos en este contexto son TCP y UDP, debido a que DCCP con sus propiedades está en cierto sentido ubicado entre TCP y UDP y comparte algunas propiedades con cada uno de estos protocolos.

El Protocolo de Datagramas de Usuario (UDP) es un protocolo de red mínimo, sin conexión que pertenece a la capa de transporte de la familia de protocolos de Internet. UDP permite que las aplicaciones envíen datagramas en redes de ordenador basadas en IP. UDP es un protocolo que solamente es responsable de direccionar, sin asegurar la transmisión de datos, ya que esto llevaría a retrasos en una transmisión de voz, por ejemplo. UDP es un protocolo de transmisión sin conexión, no fiable y no seguro así como no protegido. Una aplicación que usa UDP por lo tanto debe ser insensible a los paquetes perdidos o sin clasificar o debe en sí proporcionar medidas correctivas apropiadas y, si es necesario, también medidas de seguridad. Dado que no se tiene que establecer una conexión antes de iniciar la transmisión, un socio de conexión o ambos socios pueden comenzar a intercambiar datos más rápidamente. Una negociación de tres vías como sucede con TCP (el Protocolo de Control de Transmisión) para establecer la conexión generaría una sobrecarga innecesaria en este caso.

El Protocolo de Control de Transmisión "TCP" es un protocolo de red que define cómo se deben intercambiar los datos entre los componentes de red. Casi todos los sistemas operativos actuales de los ordenadores modernos son capaces de TCP y lo usan para el intercambio de datos con otros ordenadores. El protocolo es un protocolo de transporte fiable, orientado a conexión, conmutado por paquetes en redes de ordenadores. Es parte de la familia de protocolos de Internet, la base del Internet. A diferencia del UDP (Protocolo de Datagramas de Usuario) sin conexión, TCP establece una conexión entre dos puntos finales de una conexión de red. En esta conexión se pueden transferir datos en ambas direcciones. TCP permite que se detecte y corrija automáticamente la pérdida de datos, es posible la transferencia de datos en ambas direcciones, se evita la congestión de red, y así sucesivamente. Sin embargo, todo esto crea una cierta "sobrecarga", que hace que TCP sea más "engorroso".

El Protocolo de Control de Congestión de Datagramas (DCCP) es un protocolo de red de la capa de transporte. Se usa, por ejemplo, para la transmisión de flujos de medios en redes de IP cuando se debe usar un mecanismo de control de congestión. Esto se debe a que el protocolo TCP, que de otro modo se usa frecuentemente para este propósito, conlleva desventajas en el suministro oportuno de "datos en tiempo real" - por ejemplo, debido a sus mensajes de reconocimiento forzado. DCCP fue desarrollado de tal forma que es fácil intercambiar una aplicación de UDP a DCCP. Para este propósito, la funcionalidad requerida se ha mantenido mínima y las funciones adicionales se han movido a capas superiores. Se puede usar con cualquier aplicación que requiera conexiones unidifusión no fiables con control de congestión. Así, DCCP tiene menos sobrecarga que TCP, pero más que UDP, y puede ser el mejor compromiso para algunas aplicaciones.

DCCP, y por lo tanto su extensión multitrayectoria MP-DCCP, son por lo tanto especialmente interesantes para servicios que son sensibles a la latencia o servicios que pueden gestionar un suministro menos fiable de paquetes de datos. En particular, esto puede aplicarse a la telefonía por vídeo.

Sin embargo, surgen los siguientes problemas al implementar las soluciones de MP-DCCP correspondientes: a) los servicios de DCCP ya implementados hoy en día usualmente no tienen soporte multitrayectoria, por lo que no se puede ejecutar MP-DCCP. En consecuencia, estos recurren a la solución de trayectoria única DCCP, con la que en el peor de los casos una trayectoria de comunicación está tan sobrecargada que no es posible ninguna conexión en absoluto. Ejemplo: hasta ahora el núcleo de Linux solo soporta DCCP. Un terminal con una funcionalidad de MP-DCCP implementada que intente comunicarse con tal núcleo de Linux a través de MP-DCCP se enfrentaría al hecho de que esto no es posible.

b) Como se describió anteriormente, DCCP fue diseñado para proporcionar características de transporte que no estén sujetas a las estrictas restricciones de suministro en orden de TCP. Sin embargo, en comparación con UDP, DCCP tiene mecanismos de control de congestión CC para adaptar la tasa de datos a las características de las trayectorias de comunicación. El transporte en tiempo real a través de DCCP es un ejemplo de cómo tales servicios en tiempo real pueden usar DCCP de manera efectiva. Sin embargo, dado que DCCP y en especial MP-DCCP aún no se usan ampliamente, muchas unidades centrales dentro de una red de comunicaciones a través de las cuales pasa o se reenvía tráfico, tales como cortafuegos o unidades NAT, se implementan usando solamente los protocolos UDP y TCP mencionados anteriormente. Como resultado, los servicios de DCCP rara vez se implementan y las aplicaciones deben usar ya sea el protocolo UDP o TCP, aunque DCCP sería una mejor opción para el tráfico en muchos casos.

En este contexto, el documento EP 3119057 A1 enseña un servidor proxy que está configurado para realizar una conversión de tráfico de datos de un protocolo a otro protocolo si los dispositivos finales no son capaces de soportar la comunicación multitrayectoria de tipos de protocolos comunes de tal manera que pueden comunicarse indirectamente a través de uno o dos servidores proxy.

En este contexto, el documento US 2013/0195004 A1 enseña un método y aparato para procesar flujos de paquetes de TCP asociados con conexiones de transporte basadas en flujos para permitir de esa manera la comunicación entre un anfitrión de origen y uno o más anfitriones de destino.

En este contexto, el documento US 2012/0093150 A1 enseña un enrutador de borde que ejecuta un proxy de Protocolo de Control de Transmisión Multitrayectoria (MPTCP) para permitir que un anfitrión que implementa TCP (Protocolo de Control de Transmisión) opere normalmente además de obtener los beneficios de una conexión de MPTCP. No es necesaria una actualización de un apilamiento de TCPIP en el anfitrión. El enrutador de borde demultiplexa los paquetes recibidos desde el anfitrión a través de una conexión de TCP a una conexión de MPTCP y multiplexa los paquetes enviados al anfitrión a través de una conexión de MPTCP a una conexión de TCP. Como resultado, se puede lograr un mayor rendimiento de comunicación de paquetes, por ejemplo, para un soporte de vídeo mejorado.

En este contexto, el documento US 2012/0014153 A1 enseña un sistema de transmisión multitrayectoria que incluye un primer dispositivo de red y un segundo dispositivo de red. El primer dispositivo de red está configurado para convertir un flujo de datos de entrada en un haz de subflujos para transmisión a través de un medio de transmisión multitrayectoria. El segundo dispositivo de red está configurado para reconvertir el haz de subflujos recibidos a través del medio de transmisión multitrayectoria en un flujo de datos de salida.

En este contexto, el documento EP 3 119 057 A1 enseña una implementación de dispositivo de conversión adaptado para un protocolo de agrupamiento multitrayectoria basado en paquetes transparentes para realizar un acceso híbrido de manera eficiente.

Por lo tanto, un objeto de la presente invención es proporcionar un método, un dispositivo de conversión de paquetes, un remitente y un producto de programa de ordenador, que superen los problemas antes mencionados y permitan la transmisión multitrayectoria de paquetes de datos de DCCP. También es un objeto de la presente invención proporcionar un medio legible por ordenador que contenga instrucciones de programa para hacer que un ordenador realice el método proporcionado para operar los dispositivos sugeridos.

Este objeto se resuelve mediante las características de las reivindicaciones independientes.

Las características de los diversos aspectos de la invención que se describen a continuación o de los diversos ejemplos de implementación pueden combinarse entre sí, a menos que esto esté explícitamente excluido o sea técnicamente imposible.

Nota preliminar: Si la especificación describe más de una trayectoria de comunicación, se entenderá que estas trayectorias de comunicación están al menos separadas lógicamente. En particular, las trayectorias de comunicación se basan en diferentes tecnologías como celular, Wi-Fi, DSL, etc.

De acuerdo con un primer aspecto, se proporciona un dispositivo de conversión de paquetes, en particular un Proxy de MP-DCCP, para permitir el transporte de tráfico de datos de DCCP multitrayectoria en una red de comunicación entre un remitente y un receptor, que comprende:

• una primera interfaz de trayectoria única que está dispuesta para la transmisión de paquetes de datos a través de una trayectoria de comunicación o una primera interfaz multitrayectoria que está dispuesta para la transmisión de paquetes de datos a través de al menos dos trayectorias de comunicación; en donde el tráfico de datos transmitido a través de la primera interfaz de trayectoria única o la primera interfaz multitrayectoria es tráfico de datos de no MP-DCCP;

° para explicar el término tráfico de datos de MP-DCCP: en el caso de una trayectoria de comunicación, el tráfico de datos de no MP-DCCP puede ser un tráfico de DCCP de trayectoria única o cualquier tráfico de datos que no sea de naturaleza de DCCP. Por tanto, en el caso de más de una trayectoria de comunicación, solo una trayectoria de comunicación puede ser DCCP de trayectoria única. Pero como se explicó anteriormente, esta trayectoria de comunicación también puede ser cualquier tráfico de datos que no sea de naturaleza de DCCP. Las otras trayectorias de comunicación no son de naturaleza de DCCP.

° un remitente - o más técnicamente: una entidad remitente - puede ser un equipo de usuario como un teléfono inteligente, un ordenador o un servidor que está asociado a una empresa. Es posible que el remitente esté configurado para soportar tráfico de datos de MP-DCCP o que el remitente no pueda soportar MP-DCCP. En caso de que el remitente no pueda soportar MP-DCCP se deduce que este remitente soporta tráfico de datos de no MP-DCCP. Para dar algunos ejemplos para el caso de tráfico de datos de no MP-DCCP, es posible que el remitente transmita tráfico de datos de UDP o TCP y que la primera interfaz de trayectoria única por tanto soporte tráfico de datos de UDP y/o TCP. También es posible que el remitente transmita tráfico de datos de UDP (MP-UDP) o TCP multitrayectoria "MP-TCP y que la primera interfaz de trayectoria multitrayectoria por tanto soporte tráfico de datos de UDP multitrayectoria (MP-UDP) o TCP multitrayectoria "MP-TCP". En cualquier caso, si se debe establecer un tráfico de datos de MP-DCCP entre el remitente y el receptor, se deduce que el tráfico del remitente necesita una conversión apropiada.

° Un receptor - o más técnicamente: una entidad receptora - puede ser un equipo de usuario como un teléfono inteligente, un ordenador o un servidor que está asociado a una empresa. Es posible que el receptor esté configurado para soportar tráfico de datos de MP-DCCP o que el receptor no pueda soportar MP-DCCP. En caso de que el receptor no pueda soportar MP-DCCP se deduce que este receptor soporta tráfico de datos de no MP-DCCP. Para dar algunos ejemplos para el caso de tráfico de datos de no MP-DCCP, es posible que el receptor reciba tráfico de datos de UDP y/o TCP y que la primera interfaz de trayectoria única por tanto soporte tráfico de datos de UDP y/o TCP. También es posible que el receptor reciba UDP (MP-UDP) o TCP multitrayectoria "MP-TCP" y que la primera interfaz de trayectoria multitrayectoria por tanto soporte UDP multitrayectoria (MP-UDP) o<t>C<p>multitrayectoria "MP-TCP". En cualquier caso, si se debe establecer un tráfico de datos de MP-DCCP entre el remitente y el receptor, el tráfico en dirección al receptor necesita una conversión apropiada.

° Preferiblemente, se deduce que la primera interfaz de trayectoria única o la primera interfaz multitrayectoria está configurada para estar orientada hacia la entidad que no soporta tráfico de MP-DCCP. Si ambas entidades no soportan el tráfico de MP-DCCP, se necesitan dos dispositivos de conversión de paquetes dispuestos adecuadamente para habilitar el tráfico de datos de MP-DCCP entre el remitente y el receptor.

° Está claro que en una transferencia típica de datos por paquetes que el remitente y el receptor pueden cambiar los roles de tal manera que el remitente se convierte en el receptor y viceversa dependiendo de la dirección del tráfico de datos.

• una segunda interfaz multitrayectoria que está dispuesta para la transmisión de paquetes de datos a través de al menos dos trayectorias de comunicación; en donde el tráfico de datos transmitido a través de la segunda interfaz multitrayectoria es tráfico de datos de MP-DCCP;

° Preferiblemente, se deduce que la segunda interfaz multitrayectoria está configurada para estar orientada hacia la entidad que sí soporta tráfico de MP-DCCP.

• un módulo de conversión de paquetes que está dispuesto para convertir tráfico de datos de no MP-DCCP en tráfico de datos de MP-DCCP y/o para convertir tráfico de datos de MP-DCCP en tráfico de datos de no MP-DCCP para transmisión adicional.

° La conversión de tráfico de datos de no MP-DCCP a tráfico de datos de MP-DCCP es necesaria si el remitente no soporta MP-DCCP con el fin de permitir la transmisión multitrayectoria del tráfico de datos de MP-DCCP a través de la red hasta el receptor. El módulo de conversión de paquetes puede comprender una base de datos con información sobre cómo convertir otros protocolos a tráfico de datos de MP-DCCP; en particular, cómo convertir UDP, MP-UDP, TCP, MP-TCP y/o tráfico de datos a tráfico de datos de MP-DCCP;

° La conversión del tráfico de datos de MP-DCCP a tráfico de datos de no MP-DCCP es necesaria si el receptor no soporta MP-DCCP con el fin de permitir que el receptor pueda procesar los datos. En particular, el módulo de conversión de paquetes tiene acceso a la información sobre qué protocolos se soportan por el receptor de tal manera que pueda convertir el tráfico de datos de MP-DCCP en tráfico de datos que el receptor sea capaz de procesar. Es posible que el receptor envíe la información sobre los protocolos de tráfico de datos que soporta al comienzo de un establecimiento de conexión. El módulo de conversión de paquetes puede comprender una base de datos con información sobre cómo convertir el tráfico de datos de MP-DCCP a otros protocolos; en particular, cómo convertir el tráfico de datos de MP-DCCP a UDP, MP-UDP, TCP, MP-TCP;

° el módulo de conversión de paquetes se puede implementar como un algoritmo en un procesador del dispositivo de conversión de paquetes.

El dispositivo de conversión de paquetes proporciona la ventaja de habilitar el tráfico de datos de MP-DCCP entre un remitente y un receptor si al menos uno de ellos no soporta el tráfico de datos de MP-DCCP. Ventajosamente, resuelve los problemas descritos en la introducción en a) y b). Se deduce que las aplicaciones que necesitan tráfico de datos sensible a latencia pueden emplear MP-DCCP de manera eficiente incluso si otros dispositivos o partes de la red de comunicación no soportan MP-DCCP. Por tanto, el proxy de MP-DCCP puede finalizar conexiones de DCCP o MP-DCCP y convertirlas al otro protocolo de red o viceversa. Si la descripción menciona una conversión de tráfico de datos, se debe entender que ésta está siendo realizada en el nivel de paquetes de datos individuales, debido a que el tráfico de datos en el contexto de la invención se compone de paquetes de datos individuales.

En una realización, el dispositivo de conversión de paquetes es un proxy que puede denominarse un proxy de MP-DCCP. Esto proporciona la ventaja de que los proxies típicamente están equipados con una configuración de hardware para facilitar estas tareas. Dado que los proxies ya se implementan con frecuencia dentro de la red de comunicación, es posible llevar a cabo la invención escribiendo un algoritmo de conversión de paquetes apropiado para realizar el módulo de conversión de paquetes como software.

En una realización, una conversión de paquetes se logra mediante el módulo de conversión de paquetes a medida que los paquetes de datos entrantes se transforman desde el protocolo de paquete de datos entrante hacia el protocolo de paquete de datos saliente para transmisión adicional. El dispositivo de conversión de paquetes recibe paquetes de datos, que se separan de acuerdo con un aspecto de la presente invención en carga útil y sobrecarga tal como información de enrutamiento. Una posibilidad es mantener el protocolo al cual debe convertirse un paquete de datos entrante como una plantilla sin completar. La plantilla comprende una porción de encabezado y una porción de carga útil. Por tanto, la carga útil del paquete de datos entrante se puede desplazar a la porción de carga útil del paquete de datos saliente y la porción de encabezado se puede llenar al menos con información de enrutamiento apropiada. Por tanto, los datos de carga útil pueden separarse de la información de enrutamiento de la interfaz entrante y combinarse con la información de enrutamiento de la interfaz saliente.

Preferiblemente, el módulo de conversión de paquetes está configurado para convertir al menos un paquete de datos recibido a través de la primera interfaz de trayectoria única en al menos un paquete de datos que va a ser transmitido a través de la segunda interfaz multitrayectoria reescribiendo y/o introduciendo información de encabezado del al menos un paquete de datos recibido a través de la primera interfaz de trayectoria única. Se entiende por la persona experta que la conversión de al menos un paquete de datos es bidireccional. En otras palabras, preferiblemente el módulo de conversión está configurado para convertir al menos un paquete de datos recibido a través de la interfaz multitrayectoria en al menos un paquete de datos que va a ser transmitido a través de la interfaz de trayectoria única reescribiendo y/o introduciendo información de encabezado del al menos un paquete de datos recibido a través de la interfaz multitrayectoria.

Preferiblemente, el módulo de conversión de paquetes está configurado para convertir al menos un paquete de datos recibido a través de la primera interfaz de trayectoria única en al menos un paquete de datos que va a ser transmitido a través de la interfaz multitrayectoria al no cambiar la carga útil. Como se mencionó anteriormente, es claro para la persona experta que la conversión del al menos un paquete de datos es bidireccional. Por lo tanto, preferiblemente el módulo de conversión de paquetes está configurado para convertir el al menos un dato recibido a través de la interfaz multitrayectoria en al menos unos paquetes de datos que van a ser transmitidos a través de la interfaz de trayectoria única al no cambiar la carga útil.

En una realización, el dispositivo de conversión de paquetes comprende un programador multitrayectoria, en donde el programador multitrayectoria distribuye el tráfico de datos de MP-DCCP recibido sobre la segunda interfaz multitrayectoria entre las al menos dos trayectorias de comunicación de la primera interfaz multitrayectoria y/o el programador multitrayectoria distribuye el tráfico de datos de no MP-DCCP recibido sobre la primera interfaz multitrayectoria entre las al menos dos trayectorias de comunicación de la segunda interfaz multitrayectoria.

Esto proporciona la ventaja de que se pueden usar múltiples trayectorias ya que es necesario distribuir el tráfico de datos entre las múltiples trayectorias. Para su decisión de cuántos paquetes de datos se distribuirán a una trayectoria distinta de entre las múltiples trayectorias, el programador multitrayectoria puede tener en cuenta las características de esa trayectoria. Las características de la trayectoria pueden ser el ancho de banda disponible, latencia, pérdida de paquetes, etc. En general, el programador multitrayectoria está programado para distribuir más paquetes de datos a la trayectoria que proporciona una mayor calidad de servicio al cliente o a la trayectoria que tiene los costes más bajos.

La conversión de paquetes está configurada para realizar un establecimiento de conexión coordinado entre el remitente y el receptor.

Típicamente, una conexión de DCCP, así como una conexión de MP-DCCP, comprende una negociación de tres vías para garantizar una cadena de flujos conectados. Si el dispositivo de conversión de paquetes se coloca entre el remitente y el receptor, en donde al menos uno del remitente o del receptor es un dispositivo de no MP-DCCP, entonces el dispositivo de conversión de paquetes realiza esta negociación de tres vías con cada uno del remitente y el receptor.

Hablar de un establecimiento de conexión descoordinado si el dispositivo de conversión de paquetes realiza una negociación de tres vías con el remitente y el receptor individualmente sin tener en cuenta las respuestas del otro dispositivo. Por ejemplo, puede suceder que el dispositivo de conversión de paquetes realice con éxito una negociación de tres vías con el remitente, aunque se realice sin éxito la negociación de tres vías con el receptor. Por supuesto, si el remitente comienza a transmitir paquetes de datos, estos paquetes de datos no serán recibidos por el receptor y la conexión de datos fallará. Sin embargo, si la negociación de tres vías con el receptor también es exitosa, el establecimiento de conexión descoordinado proporciona la ventaja de una latencia reducida y un establecimiento de conexión más rápido, debido a que el dispositivo de conversión de paquetes no espera a que el otro dispositivo responda.

Hablar de un establecimiento de conexión coordinado si el dispositivo de conversión de paquetes recibe una solicitud del remitente, luego envía una solicitud apropiada al receptor y espera la respuesta del receptor para responder al remitente. Una ventaja de esta alternativa es que los paquetes de datos enviados por el remitente pueden proporcionarse con un establecimiento de conexión exitoso.

En una realización, el dispositivo de conversión de paquetes está configurado para traspasar opciones y/o elementos de características del tráfico de datos, en particular opciones y/o elementos de características de DCCP, para transmisión adicional entre el remitente y el receptor.

En una realización, también es posible traspasar opciones de TCP y/o UDP y/o elementos de características.

Esas opciones y/o elementos de características de DCCP son parte del tráfico de datos original generado por el remitente. Dado que el dispositivo de conversión de paquetes finaliza el tráfico de datos del remitente, las opciones y/o elementos de características de DCCP del tráfico de datos original se pierden en el estado de la técnica. Un proxy del estado de la técnica solo intercambia carga útil. Esta realización de la invención propone ahora traspasar esta información al receptor.

En una posible versión de implementación, se configura un módulo de conversión de paquetes para extraer esas opciones y/o elementos de características de DCCP de la información de encabezado de los paquetes de datos originales y para escribir los elementos extraídos en la información de encabezado de los paquetes de datos que crea para transmisión adicional. Dado que las opciones y/o elementos de características de DCCP es información sobre la entidad y sus características, esto proporciona información al remitente y al receptor sobre cómo configurar su comunicación.

En una realización, el dispositivo de conversión de paquetes está configurado para traspasar una selección de opciones y/o elementos de características de DCCP.

En una realización, el dispositivo de conversión de paquetes está configurado para crear paquetes de datos para una transmisión adicional que solo contienen aquellas opciones y/o elementos de características de DCCP sin carga útil y para traspasar esta información al receptor antes de que comience la transmisión de carga útil real. Esto tiene la ventaja de que el remitente y el receptor pueden acordar ciertas características de transmisión antes de que comience la transmisión real. Esto aumentará la eficiencia de la comunicación entre el remitente y el receptor.

En una realización, las opciones y/o elementos de características de DCCP traspasados, en particular opciones y/o elementos de características de DCCP, comprenden:

• información de marca de tiempo,

° la información de marca de tiempo puede comprender además la marca de tiempo, la marca de tiempo y/o tiempo transcurrido. Se puede usar una pieza o una combinación de esta información para medir explícitamente el tiempo de ida y vuelta entre el remitente y el receptor, en lugar de medir el tiempo de ida y vuelta solo entre uno de los puntos finales y el proxy.

° También es posible realizar una evaluación de latencia usando una o una combinación de esta información.

° Si el tiempo de ida y vuelta o la latencia son demasiado altos para una cierta aplicación cuando se usa un primer dispositivo de conversión de paquetes entre el remitente y el receptor, la aplicación que se ejecuta en el remitente o el receptor se puede configurar para activar un cambio del dispositivo de conversión de paquetes. En otras palabras, el remitente y/o el receptor o la aplicación que se ejecuta en el remitente y/o el receptor está configurado para direccionar un dispositivo de conversión de paquetes adicional si la latencia o el tiempo de ida y vuelta del dispositivo de conversión de paquetes usado real es demasiado alto. El remitente y/o el receptor pueden configurarse para tener una base de datos que enumere las direcciones de múltiples dispositivos de conversión de paquetes. El remitente y o el receptor pueden configurarse para seleccionar un dispositivo de conversión de paquetes de la base de datos teniendo en cuenta su ubicación actual, en donde está siendo elegido el dispositivo de conversión de paquetes más cercano al remitente o al receptor.

° Incluso es posible configurar diferentes opciones de marca de tiempo, en donde la primera opción es la información de marca de tiempo entre el remitente y el receptor y la segunda opción es la información de marca de tiempo entre el proxy y el remitente. Al calcular la relación de los tiempos de ida y vuelta resultantes R = T(tiempo de ida y vuelta entre el remitente y el receptor)/T (tiempo de ida y vuelta entre el remitente o el receptor y el dispositivo de conversión de paquetes) es posible estimar el efecto en el tiempo de ida y vuelta que se introduce al direccionar el dispositivo de conversión de paquetes. Cuanto menor sea el valor de R, mayor será la posibilidad de reducir la latencia global usando otro dispositivo de conversión de paquetes.

• cambiar L/R, confirmar L/R,

° al intercambiar estas opciones de DCCP, el remitente y el receptor pueden acordar una base común de opciones y/o elementos de características de DCCP que pueden compartir y que ambos pueden usar para configurar un establecimiento de conexión eficiente. En particular, este acuerdo sobre un conjunto común de opciones y/o elementos de características de DCCP se puede realizar entre el remitente y el receptor cuando se realiza el establecimiento de conexión de negociación de tres vías de tal manera que puedan ajustar de manera ventajosa sus respectivas características de comunicación antes de que estén siendo transmitidos los datos de carga útil.

° Como ejemplo, el remitente y el receptor pueden acordar un mecanismo específico de control de congestión.

° Si el remitente o el receptor no son capaces de soportar una de las opciones y/o elementos de características de DCCP que necesita el otro dispositivo respectivo, pueden acordar recurrir al modo de trayectoria única.

• datos abandonados,

° si la cantidad de paquetes de datos abandonados es demasiado alta, el remitente y o el receptor pueden configurarse para recurrir al modo de trayectoria única o para activar el cambio a otro dispositivo de conversión de paquetes. También es posible que el remitente y el receptor acuerden usar otro mecanismo de control de congestión o simplemente disminuir el ancho de banda si la cantidad de paquetes de datos perdidos es demasiado alta.

• control de congestión, características específicas de CCID y/o,

° como ya se estableció antes, es beneficioso si el remitente y el receptor acuerdan el mismo mecanismo de control de congestión, lo cual hace que la transmisión de datos sea mucho más eficiente dado que no todos los mecanismos de control de congestión son compatibles entre sí. La negociación de extremo a extremo del CCID aplicado, en lugar de una negociación desacoplada entre puntos finales y proxy, garantiza una experiencia consistente si las aplicaciones que se ejecutan en el remitente o el receptor tienen una dependencia en mecanismos de control de congestión individuales.

• capacidad multitrayectoria.

° Una negociación del soporte multitrayectoria de extremo a extremo ayuda al remitente o al receptor a entender lo que el otro dispositivo respectivo está soportando. Por ejemplo, si obtienen la información de que el remitente y el receptor son ambos compatibles con MP-DCCP, pueden acordar instantáneamente evitar el dispositivo de conversión de paquetes o la próxima vez cuando realicen un establecimiento de conexión.

El intercambio de las opciones y características de DCCP de uno al otro flujo se implementará preferiblemente sobre una base selectiva.

A continuación, las tablas 1 y 2 copiadas sin modificaciones de [2], dan una visión general de las opciones y características que se definen hasta ahora en DCCP.

Tabla 1: Opciones de DCCP

Tabla 2: Números de características de DCCP

En una realización, el dispositivo de conversión de paquetes está configurado para traspasar las opciones y/o elementos de características de DCCP en un mensaje separado antes de que comience la transmisión de carga útil.

Esto proporciona la ventaja de que el remitente y el receptor pueden configurarse para acordar las mejores características de transporte teniendo en cuenta sus respectivas capacidades antes de enviar los datos de carga útil reales. Esto hace que la comunicación sea más eficiente.

En una realización, el módulo de conversión de paquetes está configurado para convertir tráfico de datos de UDP y/o TCP en tráfico de datos de MP-DCCP y/o para convertir tráfico de datos de MP-DCCP en tráfico de datos de tráfico de datos de UDP y/o TCP para transmisión adicional.

Esto proporciona la ventaja de que el remitente y/o el receptor que solo soporta tráfico de UDP o TCP pueden beneficiarse de un transporte de MP-DCCP.

Esto proporciona la ventaja de que la comunicación del remitente y/o del receptor que solo soporta tráfico de UDP o TCP se puede optimizar de manera eficiente como se describió anteriormente dentro del contexto de las opciones y/o elementos de características de DCCP traspasados.

A continuación, se enumeran las opciones y/o elementos de características de TCP de ejemplo: Fin de la Lista de Opciones; Sin Operación, Tamaño Máximo de Segmento, Escala de Ventana, SACK Permitido, SACK, Eco (obsoleto por la opción 8), Respuesta de Eco (obsoleto por la opción 8), Marcas de Tiempo, Conexión de Orden Parcial Permitida (obsoleto), Perfil de Servicio de Orden Parcial (obsoleto), CC (obsoleto), CC.NUEVO (obsoleto), CC.ECO (obsoleto), Solicitud de Suma de Verificación Alternativa de TCP (obsoleta), Datos de Suma de Verificación Alternativa de TCP (obsoletos), Skeeter, Bubba, Opción de Suma de Verificación de Tráiler, Opción de Firma MD5 (obsoleta por la opción 29), Capacidades de SCPS, Reconocimientos Negativos Selectivos, Límites de Registro, Corrupción experimentada, SNAP, Filtro de Compresión de TCP, Respuesta de Inicio Rápido, Opción de Tiempo de Espera de Usuario (también, otro uso no autorizado conocido), Opción de Autenticación de TCP (TCP-AO) o TCP Multitrayectoria (MPTCP). Especialmente, puede ser de interés la marca de tiempo.

A continuación, se enumeran las opciones y/o elementos de características de UDP de ejemplo: Sin operación (NOP), Suma de verificación de opción (OCS), Suma de verificación alternativa (ACS), Fragmentación (FRAG), Tamaño máximo de segmento (MSS), Tamaño máximo de segmento reensamblado (MRSS), (varía) Opciones no seguras para ignorar (UNSAFE), Marcas de tiempo (TIME), (varía) Autenticación (AUTH), Solicitud (REQ), Respuesta (RES), (varía) SIN ASIGNAR (asignable por IANA), RESERVADO o (varía) Experimentos estilo RFC 3692 (EXP). Especialmente, puede ser de interés la marca de tiempo.

En una realización, el módulo de conversión de paquetes está configurado para convertir el tráfico de datos de UDP y/o TCP en una primera etapa a un tráfico de datos de DCCP y para convertir el tráfico de datos de DCCP en una segunda etapa a MP-DCCp y viceversa.

Esto proporciona la ventaja de que se puede usar un algoritmo de conversión de DCCP a MP-DCCP ya que sus datos de entrada son los mismos. Esto proporciona un enfoque modular para programar las conversiones individuales, lo cual en general es más eficiente.

De acuerdo con un segundo aspecto, se proporciona un remitente que está configurado para comunicarse con un receptor usando un dispositivo de conversión de paquetes como se describió anteriormente, en donde el remitente está configurado para seleccionar un dispositivo de conversión de paquetes tomando en cuenta su posición local.

En particular, el remitente seleccionará el dispositivo de conversión de paquetes que esté más cerca de su posición local. Esto minimiza la longitud de transmisión de trayectoria única de tal manera que se pueda emplear eficientemente el tráfico de datos de MP-DCCP. El remitente puede comprender una base de datos con las posiciones locales de diversos dispositivos de conversión de paquetes o el remitente puede solicitar una lista de dispositivos de conversión de paquetes cerca de su propia posición local a un proveedor de red.

En una realización, el remitente está configurado para direccionar un dispositivo de conversión de paquetes adicional si la latencia o el tiempo de ida y vuelta del dispositivo de conversión de paquetes usado real excede un umbral predefinido.

El umbral predefinido puede ser establecido por una aplicación que usa el tráfico de datos que se ejecuta en el remitente y/o el umbral predefinido puede ser establecido dentro del sistema operativo del remitente. Esto proporciona la ventaja de que se proporciona un criterio que permite la decisión de direccionar el dispositivo de conversión de paquetes adicional.

De acuerdo con una realización, se proporciona un sistema de comunicación, en particular un sistema de telecomunicaciones, que comprende

• un remitente,

• un receptor,

• una red para facilitar un tráfico de datos entre el remitente y el receptor, y

° la red puede comprender múltiples trayectorias de comunicación, especialmente trayectorias de comunicación maleables que son técnicamente diferentes entre sí, como celular, Wi-Fi, DSL o similares;

• un dispositivo de conversión de paquetes como se describió anteriormente, en donde el dispositivo de conversión de paquetes está dispuesto para recibir tráfico de datos del remitente, luego está configurado para convertir el tráfico de datos recibido y para reenviar el tráfico de datos convertido al receptor.

Básicamente esto proporciona las mismas ventajas como se describió dentro del contexto del dispositivo de conversión de paquetes.

En una realización, el dispositivo de conversión de paquetes está siendo dispuesto dentro de la trayectoria de comunicación entre el remitente y el receptor o que el dispositivo de conversión de paquetes está siendo dispuesto fuera de la trayectoria de comunicación entre el remitente y el receptor.

Estar dispuesto dentro de la trayectoria de comunicación significa que el dispositivo de conversión de paquetes está ubicado dentro de la trayectoria de comunicación que conecta al remitente y al receptor directamente. Estar dispuesto fuera de la trayectoria de comunicación significa que esta no es la trayectoria de comunicación que el remitente y el receptor normalmente elegirían para comunicarse entre sí como una primera opción. En ese sentido la conexión de datos experimenta una especie de desvío.

Si los dispositivos de conversión de paquetes se disponen dentro de la trayectoria de comunicación entre el remitente y el receptor, esto proporciona la ventaja de que

• los servicios multitrayectoria se pueden usar de manera muy eficiente debido a que se evita el desvío; esto es en particular el caso si los dispositivos de conversión de paquetes están en estrecha proximidad del remitente y/o del receptor. Por ejemplo, este podría ser el caso si el dispositivo de conversión de paquetes está siendo implementado en una puerta de acceso residual en el entorno de red doméstica del usuario.

• Una ventaja adicional de esta opción es que no es necesario direccionar explícitamente el dispositivo de conversión de paquetes debido a que de todos modos está dentro de la trayectoria de comunicación. Ni el remitente ni el receptor necesitan conocer la dirección de IP del proxy.

Si los dispositivos de conversión de paquetes están siendo dispuestos fuera de la trayectoria de comunicación entre el remitente y el receptor, esto proporciona la ventaja de que

• los sistemas existentes se pueden proporcionar fácilmente con la funcionalidad de MP-DCCP implementando dispositivos de conversión de paquetes en ubicaciones preferidas dentro de la red de comunicación. Por ejemplo, el proxy podría emplearse dentro de una nube del proveedor de red, de tal manera que básicamente cada remitente y/o receptor tenga acceso a este proxy a través de la red de comunicación. Se deduce que el remitente y/o el receptor necesitan conocer la dirección de esos dispositivos de conversión de paquetes dentro de la red de comunicación. Es posible almacenar estas direcciones dentro de la base de datos del remitente y/o del receptor o que el sistema operativo del remitente y/o del receptor o una aplicación que se ejecuta en el remitente y/o el receptor solicite las direcciones de los dispositivos de conversión de paquetes dentro de la red. Por supuesto, es posible actualizar tal base de datos. Por tanto, esta opción proporciona una solución muy flexible y fácil de implementar.

En una realización, el dispositivo de conversión de paquetes se implementa en una puerta de acceso residencial.

Esto proporciona la ventaja de que el dispositivo de conversión de paquetes está muy cerca del remitente, en donde el remitente puede ser un equipo de usuario como un teléfono inteligente, una tableta, un ordenador, etc. Esto también proporciona la ventaja de que múltiples equipos de usuario pueden hacer uso de la puerta de acceso residencial actualizada.

De acuerdo con un Tercer aspecto de la invención, se proporciona un método para operar un dispositivo de conversión de paquetes, en particular un Proxy de MP-DCCP, para permitir el transporte de tráfico de datos de DCCP multitrayectoria en una red de comunicación entre un remitente y un receptor, que comprende:

• operar una primera interfaz de trayectoria única que está dispuesta para la transmisión de paquetes de datos a través de una trayectoria de comunicación o una primera interfaz multitrayectoria que está dispuesta para la transmisión de paquetes de datos a través de al menos dos trayectorias de comunicación; en donde el tráfico de datos transmitido a través de la primera interfaz de trayectoria única o la primera interfaz multitrayectoria es tráfico de datos de no MP-DCCP;

• operar una segunda interfaz multitrayectoria que está dispuesta para la transmisión de paquetes de datos a través de al menos dos trayectorias de comunicación; en donde el tráfico de datos transmitido a través de la segunda interfaz multitrayectoria es tráfico de datos de MP-DCCP;

• operar un módulo de conversión de paquetes que está dispuesto para convertir tráfico de datos de no MP-DCCP en tráfico de datos de MP-DCCP y/o para convertir tráfico de datos de MP-DCCP en tráfico de datos de no MP-DCCP para transmisión adicional.

El método proporciona básicamente las mismas ventajas como se describió anteriormente.

De acuerdo con un quinto aspecto de la invención, se proporciona un producto de programa de ordenador que contiene instrucciones de programa para hacer que un procesador, en particular un procesador de un proxy de MP-DCCP, realice el método descrito anteriormente.

El producto de programa de ordenador proporciona básicamente las mismas ventajas como se describió anteriormente.

A continuación, se explican ejemplos de implementación preferidos de la presente invención con referencia a la figura acompañante:

Figura 1a: muestra una configuración de proxy de MP-DCCP inventiva de acuerdo con la invención.

Figura 1b: muestra la configuración de la Figura 1a, en donde el proxy de MP-DCCP soporta una conversión de protocolo inicial adicional.

Figura 2a: muestra un establecimiento de conexión descoordinado entre un remitente y un receptor a través del proxy de MP-DCCP.

Figura 2b: muestra un establecimiento de conexión coordinado entre un remitente y un receptor a través del proxy de MP-DCCP.

Figura 3 muestra un sistema de comunicación de acuerdo con la invención.

Figura 4 muestra un diagrama de flujo del método de acuerdo con la invención.

A continuación, se explican en detalle numerosas características de la presente invención por medio de realizaciones preferidas.

La Figura 1 muestra una configuración de proxy de MP-DCCP inventiva de acuerdo con la invención. Un remitente es compatible con DCCP y está conectado a través de una trayectoria única 105 a un primer proxy 110. El primer proxy tiene una primera interfaz de trayectoria única 115 y una segunda interfaz multitrayectoria 120. El tráfico de datos de DCCP transmitido por el remitente 100 al primer proxy 110 traspasa las diferentes capas OSI 125 hasta llegar al módulo de conversión de paquetes 130 del primer proxy 110. El módulo de conversión de paquetes 130 convierte el tráfico de datos de DCCP en tráfico de datos de MP-DCCP y crea paquetes de datos apropiados. En particular, está siendo realizado un intercambio de mordida 135 de la carga útil. Los paquetes de datos de MP-DCCP creados traspasan las diferentes capas OSI 125 en la dirección opuesta y salen del primer proxy 110 por medio de la segunda interfaz multitrayectoria 120 y se transmiten a través de una multitrayectoria a un segundo proxy 150.

El segundo proxy 150 comprende una segunda interfaz multitrayectoria adicional 155 para recibir los paquetes de datos de MP-DCCP. Estos paquetes de datos traspasan las diferentes capas OSI 160 del segundo proxy 150 hasta llegar al módulo de conversión de paquetes 165 del segundo proxy 150. El módulo de conversión de paquetes 165 del segundo proxy está configurado para convertir el tráfico de datos de MP-DCCP en tráfico de datos de DCCP para transmisión adicional. En particular, está siendo realizado un intercambio de mordida 170 de la carga útil. Los paquetes de datos de DCCP salen del segundo proxy 150 por medio de una primera interfaz de trayectoria única adicional 175 y se comunican a un receptor 180 usando una conexión de trayectoria única adicional 185.

Se puede observar que incluso si el remitente 100 y el receptor 180 no son compatibles con MP-DCCP, el proxy 110 y el proxy 150 proporcionan una solución que al menos en algunas secciones es posible el uso de MP-DCCP.

Si el remitente 100 es compatible con MP-DCCP, entonces solo es necesario el segundo proxy 150 para proporcionar una solución que al menos en algunas secciones sea posible el uso de MP-DCCP. Por otro lado, si el receptor 180 es compatible con MP-DCCP, entonces solo el primer proxy 110 es necesario para proporcionar tráfico de MP-DCCP en al menos algunas secciones.

En esencia, el proxy de MP-DCCP finaliza las conexiones de DCCP o MP-DCCP y las convierte al otro protocolo de red respectivo. Para ello, la carga útil del paquete de DCCP o MP-DCCP se eXtrae del flujo de datos entrante y se coloca en un nuevo flujo de DCCP o MP-DCCP establecido.

La Figura 1b muestra la configuración de la Figura 1a, en donde el proxy de MP-DCCP soporta una conversión de protocolo inicial adicional.

En caso de que los terminales, es decir el remitente 100 y el receptor 180, no sean compatibles con DCCP, sino que en cambio usen el protocolo UDP y/o TCP para el tráfico de datos, los proxies de MP-DCCP 110, 150 pueden incluso ayudar a proporcionar transporte multitrayectoria para tales escenarios. El concepto en la Figura 1b por lo tanto propone intercambiar 135 la carga útil entre los flujos de UDP y DCCP de una forma similar a como se propone para los terminales de DCCP en la Figura 1a. Esto se puede implementar de la siguiente manera, el tráfico de datos de UDP llega a los proxies de MP-DCCP 110 - que también se pueden denominar como Proxy de UDP ya que ahora convierten el tráfico de datos de UDP. El módulo de conversión de paquetes 160 está configurado para extraer la carga útil del datagrama de UDP y proporcionarla a una conexión de MP-DCCP existente o recién creada. Es posible que la carga útil de UDP se intercambie directamente a un paquete de datos de MP-DCCP recién creado o que la carga útil de UDP se convierta en una primera etapa en un paquete de datos de DCCP, en donde se crea una conexión de MP-DCCP a partir de este paquete de datos de DCCP. Técnicamente, esto se hace de la misma forma cuando al menos uno del remitente 100 y/o el receptor 180 usan tráfico de datos de TCP. Incluso es posible que el remitente 100 use tráfico de datos de TCP, mientras que el receptor 180 este tráfico de datos de UDP o viceversa. En este caso se necesitaría un proxy de UDP-DCCP y un proxy de TCP-DCCP, en donde los respectivos proxies están dispuestos en consecuencia. Esto significa que, si el remitente usa tráfico de datos de TCP, envía los paquetes de datos a un proxy de TCP-DCCP, en donde el proxy de TCP-DCCP envía el tráfico de datos de MP-D<c>C<p>al proxy de UDP-DCCP, y en donde el proxy de UDP-DCCP envía el tráfico de datos de UDP al receptor 180.

Si uno del remitente 100 o el receptor 180 son compatibles con MP-DCCP, mientras que el otro solo soporta tráfico de datos de TCP y/o UDP, entonces solo se necesita un proxy de TCP-DCCP y/o un proxy de UDP-DCCP, respectivamente.

La Figura 1b proporciona la ventaja de que los terminales compatibles con UDP 100, 180 pueden beneficiarse de un transporte de MP-DCCP. Aunque un método implícito para obtener tráfico que pasa por el proxy de MP-DCCP no necesita mejoras adicionales, un método explícito sí. El método implícito y el explícito se describirán a continuación en el contexto de la Figura 3. En el caso del método explícito, la información de dirección de destino tiene que transmitirse fuera de banda o en banda, por ejemplo, usando las opciones de UDP [4] o el encabezado de TCP, especialmente usando el campo de opciones, o en la carga útil, especialmente como parte del proceso de negociación de TCP.

La información de dirección del proxy de MP-DCCP también se puede almacenar dentro del sistema operativo o la aplicación del remitente.

Esto tiene el beneficio de que incluso los flujos de UDP o TCP se pueden transmitir a través de un proxy de MP-DCCP, que no está residiendo en la trayectoria de comunicación directa. Para mapear el tráfico entre UDP y MP-DCCP se requiere una tabla de mapeo, preferiblemente ubicada en el mismo Proxy. Esta tabla de mapeo se actualiza de acuerdo con la información de dirección proporcionada dentro de la configuración "implícita" o "explícita".

La Figura 2a muestra un establecimiento de conexión descoordinado entre un remitente y un receptor a través del proxy de MP-DCCP. La Figura 2b muestra un establecimiento de conexión coordinado entre un remitente y un receptor a través del proxy de MP-DCCP.

En las Figuras 2a, 2b se muestra un proceso típico de establecimiento entre un remitente 100 y un receptor 180 mediante el enrutamiento del tráfico de datos a través de un proxy de MP DCCP 110 en el contexto de la invención. Las Figuras 2a y 2b suponen que el remitente de MP-DCCP 100 se comunica con el receptor compatible con DCCP 180 a través del proxy de MP-DCCP 110. Para realizar la negociación de tres vías típica, el remitente 100 primero establece una conexión de MP-DCCP con el proxy de MP-DCCP 110 realizando una solicitud 200 debido a que no puede comunicarse directamente con el receptor 180. Esta solicitud 200 activa una segunda solicitud 205 realizada por el proxy de MP-DCCP 110 al receptor 180. Como se puede ver, la primera conexión 201 es de naturaleza MP, mientras que la segunda conexión 202 es de naturaleza de trayectoria única.

Este procedimiento tiene el beneficio de que el intercambio de carga útil se puede aplicar entre dos flujos de (MP-)DCCP independientes, para proporcionar la conversión entre transporte multitrayectoria y de trayectoria única.

La diferencia entre los procesos de establecimiento de las Figuras 2a y 2b es que en el proceso de establecimiento coordinado en etapas individuales de la negociación de 3 vías, a saber, las respuestas 210, 215 y los ACK 220, 225 son coordinados por el proxy de MP-DCCP 110 de una forma que siempre espera la respuesta del dispositivo al que más recientemente le ha enviado una solicitud 205, una respuesta 215 para garantizar una cadena exitosa de flujos conectados. En el caso de la Figura 2a, puede suceder que el remitente 100 comience a enviar tráfico de datos de carga útil incluso si la segunda conexión 202 no se puede establecer con éxito o aún no se ha establecido con éxito.

Los bocetos de las Figuras 2a y 2b solo presentan una configuración mínima para conectar un terminal MP 100 con un terminal de DCCP 180, sin embargo, en una topología de Acceso Híbrido, la configuración mejora a terminal de DCCP <--> Proxy de MP-DCCP <-> Proxy de MP-DCCP <--> terminal de DCCP.

La Figura 3 muestra un sistema de comunicación 300 de acuerdo con la invención. El sistema de comunicación 300 comprende un primer dispositivo de conversión de paquetes 110 en la realización de una puerta de acceso residual compatible con multitrayectoria 110, en donde múltiples remitentes 100 tienen acceso a la red de comunicación 310 usando la puerta de acceso residual 110. Los remitentes pueden ser 100 un teléfono inteligente, un ordenador, una tableta, un altavoz inteligente, un servidor y/u otro equipo de usuario.

La red de comunicación 310 es una red multitrayectoria y comprende una trayectoria de red fija 315 y una trayectoria de red celular 320.

Uno o múltiples remitentes 100 pueden enviar tráfico de datos de DCCP a la puerta de acceso residencial 110, en donde el módulo de conversión de paquetes convierte el tráfico de datos de DCCP en tráfico de datos de MP-DCCP y envía este tráfico de datos a través de múltiples trayectorias, al menos a través de la red fija 315 y la red celular 320, al segundo dispositivo de conversión de paquetes 150, implementado como un HAG 150. El HAG 150 que convierte el tráfico de MP-DCCP recibido en tráfico de DCCP y enruta el tráfico de DCCP al receptor 180 que puede ser un servidor de vídeo 180. Por supuesto, esto también funciona si los múltiples remitentes envían tráfico de datos de UDP o TCP como se explicó anteriormente. Esto solo requiere un módulo de conversión de paquetes configurado apropiado. Este sistema de comunicación 300 proporciona la ventaja de que múltiples dispositivos de equipo de usuario pueden usar el tráfico de MP-DCCP si están conectados a la puerta de acceso residencial 110.

La Figura 4 muestra un diagrama de flujo 400 del método de acuerdo con la invención.

El método comprende las siguientes etapas:

410: operar una primera interfaz de trayectoria única que está dispuesta para la transmisión de paquetes de datos a través de una trayectoria de comunicación o una primera interfaz multitrayectoria que está dispuesta para la transmisión de paquetes de datos a través de al menos dos trayectorias de comunicación; en donde el tráfico de datos transmitido a través de la primera interfaz de trayectoria única o la primera interfaz multitrayectoria es tráfico de datos de no MP-DCCP;

420: operar una segunda interfaz multitrayectoria que está dispuesta para la transmisión de paquetes de datos a través de al menos dos trayectorias de comunicación; en donde el tráfico de datos transmitido a través de la segunda interfaz multitrayectoria es tráfico de datos de MP-DCCP;

430: operar un módulo de conversión de paquetes que está dispuesto para convertir tráfico de datos de no MP-DCCP en tráfico de datos de MP-DCCP y/o para convertir tráfico de datos de MP-DCCP en tráfico de datos de no MP-DCCP para transmisión adicional.

Claims

REIVINDICACIONES

1. Un dispositivo de conversión de paquetes, en particular un Proxy de MP-DCCP (110,150), para permitir el transporte de tráfico de datos de DCCP multitrayectoria en una red de comunicación entre un remitente y un receptor, que comprende:

• una primera interfaz de trayectoria única (115,175) que está dispuesta para la transmisión de paquetes de datos a través de una trayectoria de comunicación o una primera interfaz multitrayectoria que está dispuesta para la transmisión de paquetes de datos a través de al menos dos trayectorias de comunicación; en donde el tráfico de datos transmitido a través de la primera interfaz de trayectoria única o la primera interfaz multitrayectoria es tráfico de datos de no MP-DCCP;

• una segunda interfaz multitrayectoria (120,155) que está dispuesta para la transmisión de paquetes de datos a través de al menos dos trayectorias de comunicación; en donde el tráfico de datos transmitido a través de la segunda interfaz multitrayectoria es tráfico de datos de MP-DCCP;

un módulo de conversión de paquetes (130) que está dispuesto para convertir tráfico de datos de no MP-DCCP en tráfico de datos de MP-DCCP de acuerdo con una conversión de protocolo y/o para convertir tráfico de datos de MP-DCCP en tráfico de datos de no MP-DCCP de acuerdo con una conversión de protocolo adicional para transmisión adicional,

en donde el dispositivo de conversión de paquetes está configurado para realizar un establecimiento de conexión coordinado entre el remitente (100) y

el receptor (180), en donde el dispositivo de conversión de paquetes está configurado para realizar una negociación de tres vías con cada uno del remitente y el receptor.

2. El dispositivo de conversión de paquetes de la reivindicación 1, en donde el dispositivo de conversión de paquetes comprende un programador multitrayectoria, en donde el programador multitrayectoria distribuye el tráfico de datos de MP-DCCP recibido a través de la segunda interfaz multitrayectoria entre las al menos dos trayectorias de comunicación de la primera interfaz multitrayectoria y/o el programador multitrayectoria distribuye el tráfico de datos de no MP-DCCP recibido a través de la primera interfaz multitrayectoria entre las al menos dos trayectorias de comunicación de la segunda interfaz multitrayectoria.

3. El dispositivo de conversión de paquetes de cualquiera de las reivindicaciones, en donde el dispositivo de conversión de paquetes está configurado para traspasar opciones y/o elementos de características del tráfico de datos, en particular opciones y/o elementos de características de DCCP, para transmisión adicional entre el remitente y el receptor.

4. El dispositivo de conversión de paquetes de la reivindicación 3, en donde las opciones y/o elementos de características traspasados, en particular opciones y/o elementos de características de DCCP, comprenden: ° información de marca de tiempo,

° cambiar L/R, confirmar L/R,

° datos abandonados,

° control de congestión, características específicas de CCID y/o

° capacidad multitrayectoria.

5. El dispositivo de conversión de paquetes de las reivindicaciones 3 a 4, en donde el dispositivo de conversión de paquetes está configurado para traspasar las opciones y/o elementos de características de DCCP en un mensaje separado antes de que comience la transmisión de carga útil.

6. El dispositivo de conversión de paquetes de cualquiera de las reivindicaciones, en donde el módulo de conversión de paquetes está configurado para convertir tráfico de datos de UDP y/o TCP en tráfico de datos de MP-DCCP y/o para convertir tráfico de datos de MP-DCCP en tráfico de datos de tráfico de datos de UDP y/o TCP para transmisión adicional.

7. El dispositivo de conversión de paquetes de cualquiera de la reivindicación 6, en donde el módulo de conversión de paquetes está configurado para convertir el tráfico de datos de UDP y/o TCP en una primera etapa a un tráfico de datos de DCCP y para convertir el tráfico de datos de DCCP en una segunda etapa a MP-DCCP y viceversa.

8. Un remitente configurado para comunicarse con un receptor utilizando un dispositivo de conversión de paquetes de acuerdo con la reivindicación 1, caracterizado porque el remitente está configurado para seleccionar un dispositivo de conversión de paquetes teniendo en cuenta su posición local.

9. El remitente de la reivindicación 8, en donde el remitente está configurado para direccionar un dispositivo de conversión de paquetes adicional si la latencia o el tiempo de ida y vuelta del dispositivo de conversión de paquetes usado real excede un umbral predefinido.

10. Un sistema de Comunicación, que comprende

• un remitente,

• un receptor, y

• un dispositivo de conversión de paquetes de cualquiera de las reivindicaciones 1 - 7, en donde el dispositivo de conversión de paquetes está dispuesto para recibir tráfico de datos del remitente, luego está configurado para convertir el tráfico de datos recibido y para reenviar el tráfico de datos convertido al receptor.

11. El sistema de comunicación de la reivindicación 10, en donde el dispositivo de conversión de paquetes está siendo dispuesto dentro de la trayectoria de comunicación entre el remitente y el receptor o que el dispositivo de conversión de paquetes está siendo dispuesto fuera de la trayectoria de comunicación entre el remitente y el receptor.

12. El sistema de comunicación de cualquiera de las reivindicaciones 10-11, en donde el dispositivo de conversión de paquetes está implementado en una puerta de acceso residual.

13. Un método para operar un dispositivo de conversión de paquetes, en particular un Proxy de MP-DCCP (110,150), para permitir el transporte de tráfico de datos de DCCP multitrayectoria en una red de comunicación entre un remitente y un receptor, que comprende:

• operar una primera interfaz de trayectoria única (115,175) que está dispuesta para la transmisión de paquetes de datos a través de una trayectoria de comunicación o una primera interfaz multitrayectoria que está dispuesta para transmisión de paquetes de datos a través de al menos dos trayectorias de comunicación; en donde el tráfico de datos transmitido a través de la primera interfaz de trayectoria única o la primera interfaz multitrayectoria es tráfico de datos de no MP-DCCP;

• operar una segunda interfaz multitrayectoria (120,155) que está dispuesta para la transmisión de paquetes de datos a través de al menos dos trayectorias de comunicación; en donde el tráfico de datos transmitido a través de la segunda interfaz multitrayectoria es tráfico de datos de MP-DCCP;

operar un módulo de conversión de paquetes que está dispuesto para convertir tráfico de datos de no MP-DCCP en tráfico de datos de MP-DCCP de acuerdo con una conversión de protocolo y/o para convertir tráfico de datos de MP-DCCP en datos de no MP-DCCP de acuerdo con un tráfico de conversión de protocolo adicional para transmisión adicional,

en donde el dispositivo de conversión de paquetes realiza el establecimiento de conexión entre el remitente (100) y el receptor (180), en donde el dispositivo de conversión de paquetes realiza una negociación de tres vías con cada uno del remitente y el receptor.

14. Un producto de programa de ordenador que contiene instrucciones de programa para hacer que un procesador, en particular un procesador de un proxy de MP-DCCP, realice el método de la reivindicación 13.