ES2881255T3 - Protocolo de comunicación simple para la transmisión de datos a través de redes limitadas - Google Patents

Protocolo de comunicación simple para la transmisión de datos a través de redes limitadas Download PDF

Info

Publication number
ES2881255T3
ES2881255T3 ES18306387T ES18306387T ES2881255T3 ES 2881255 T3 ES2881255 T3 ES 2881255T3 ES 18306387 T ES18306387 T ES 18306387T ES 18306387 T ES18306387 T ES 18306387T ES 2881255 T3 ES2881255 T3 ES 2881255T3
Authority
ES
Spain
Prior art keywords
proxy
destination
tcp
packet
source
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
ES18306387T
Other languages
English (en)
Inventor
Arunprabhu Kandasamy
Ana Minaburo
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.)
Acklio SAS
Original Assignee
Acklio SAS
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 Acklio SAS filed Critical Acklio SAS
Application granted granted Critical
Publication of ES2881255T3 publication Critical patent/ES2881255T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/03—Protocol definition or specification 
    • 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/169—Special adaptations of TCP, UDP or IP for interworking of IP based networks with other networks 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H04W28/065—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information using assembly or disassembly of packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H04L67/5651—Reducing the amount or size of exchanged application data
    • 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/04—Protocols for data compression, e.g. ROHC
    • 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/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]
    • 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/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • 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/166—IP fragmentation; TCP segmentation
    • 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/18—Multiprotocol handlers, e.g. single devices capable of handling multiple 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/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H04W88/182—Network node acting on behalf of an other network entity, e.g. proxy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless

Landscapes

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

Abstract

Sistema que comprende un proxy de origen y un proxy de destino, dicho proxy de origen (303) para transmitir uno o más paquetes TCP enviados desde un dispositivo de origen (301) a un dispositivo de destino (307) a través de un enlace inalámbrico (304), comprendiendo cada paquete TCP una sección de datos TCP y una cabecera de paquete TCP, donde el proxy de origen (303) se ubica en dicho enlace inalámbrico (304) y está configurado para: - recibir dicho uno o más paquetes TCP; - determinar un paquete de modo de compresión simple a partir de dicho uno o más paquetes TCP mediante la eliminación de la cabecera de paquete TCP comprendida en cada paquete TCP, comprendiendo dicho paquete de modo de compresión simple las secciones de datos TCP comprendidas en dicho uno o más paquetes TCP y una cabecera que comprende un identificador de conexión; y - enviar dicho paquete de modo de compresión simple a un proxy de destino (305) ubicado en dicho enlace inalámbrico (304), estando el proxy de destino (305) configurado para: - recibir dicho paquete de modo de compresión simple y confirmar la recepción al proxy de origen (303); - determinar uno o más paquetes TCP reconstruidos mediante la extracción de las secciones de datos de cada paquete TCP a partir de dicho paquete de modo de compresión simple; y - enviar dicho uno o más paquetes TCP reconstruidos al dispositivo de destino (307) donde dicho identificador de conexión identifica una conexión entre dicho proxy de origen (303) y dicho proxy de destino (305), comprendiendo la cabecera de dicho paquete de modo de compresión simple, además: - un primer campo siguiente que representa un número del paquete de modo de compresión simple enviado por el proxy de origen (303) e incrementándose en uno cada vez que el proxy de origen envía un paquete de modo de compresión simple (303); - un segundo campo siguiente que representa un número del paquete de modo de compresión simple recibido por el proxy de origen (303) desde el proxy de destino (305) e incrementándose en uno cada vez que un paquete de modo de compresión simple es enviado desde el proxy de destino (305) al proxy de origen (303); - un tercer campo siguiente que indica si un fin de conexión es entregado por el origen (301) o el destino (307).

Description

DESCRIPCIÓN
Protocolo de comunicación simple para la transmisión de datos a través de redes limitadas
CAMPO TÉCNICO
[0001] La presente invención se refiere, en general, a la transmisión de datos a través de redes TCP/IP y, más específicamente, a la transmisión de datos TCP a través de redes inalámbricas.
ANTECEDENTES
[0002] Las tecnologías Machine-To-Machine (M2M), Web-of-Things (WoT) e Internet of Things (IoT) han permitido el desarrollo de redes de dispositivos físicos, máquinas, vehículos, electrodomésticos y muchos otros objetos conectados entre sí y dotados de una conectividad a Internet y de la capacidad de recopilar e intercambiar datos sin necesidad de interacciones entre humanos o entre humanos y ordenadores.
[0003] Varios protocolos y tecnologías de comunicación por cable e inalámbricos ofrecen conectividad a entidades loT/M2M (por ejemplo, dispositivos y pasarelas loT/M2M) que comprenden:
- redes por cable (por ejemplo, Ethernet, Multimedia over Coax Alliance (MoCA), Power-line communication); - redes inalámbricas de corto alcance (por ejemplo, redes de malla Bluetooth, Light-Fidelity, wifi y comunicaciones de campo próximo)
- redes inalámbricas de medio alcance (por ejemplo, HaLow, LTE-advanced), y
- redes inalámbricas de bajo alcance (por ejemplo, redes de área amplia de baja potencia (LPWAN), terminales de muy pequeña apertura y conectividad wifi de largo alcance).
[0004] Las LPWAN son redes inalámbricas diseñadas para permitir comunicaciones de largo alcance a una baja velocidad de datos, de modo que se reduce la energía y el coste de la transmisión. Las LPWAN son redes limitadas que presentan limitaciones complejas para ofrecer conectividad a dispositivos limitados, como los dispositivos loT, que requieren poco ancho de banda, un consumo de energía bajo y velocidades de datos bajas. Las tecnologías LPWAN ilustrativas comprenden LoRaWAN (Long Range Radio Wide Area Network [red de área amplia de radio de largo alcance]), Sigfox, LTE-NB1 (Long Term Evolution-Machine to Machine, Narrow Band [evolución a largo plazo-máquina a máquina, banda estrecha]), NB-loT (NarrowBand loT [IoT de banda estrecha]) y Weightless. Los detalles sobre estas tecnologías se dan a conocer, por ejemplo, en "RFCB376"
[0005] Las entidades de IoT utilizan Internet para conectarse entre sí y pueden interactuar en múltiples capas de protocolo de comunicación, como la capa de red y la capa de protocolo de aplicación, de acuerdo con diversas normas y convenciones de protocolo. La pila de protocolos de IoT admite el Protocolo de Internet (IP), el Protocolo de Datagramas de Usuario (UDP) y el Protocolo de Aplicación Restringida (CoAP). Inicialmente, se utilizaba el protocolo de Internet IPv4 para asignar una dirección IP única a cada entidad/objeto de IoT como identificador único. Debido al espacio de direcciones limitado de IPv4 y al gran espacio de direcciones necesario para cubrir el creciente número de objetos de loT, se ha adoptado el IPv6.
[0006] La adopción de los protocolos IPv6, UDP y CoAP para la conexión de objetos a través de redes limitadas de muy bajo ancho de banda, como las LPWAN, puede ofrecer una conectividad y una recogida y transferencia de datos rentables para muchas aplicaciones de IoT. El reto de admitir los protocolos IPv6/UDP/CoAP en dichas redes limitadas es el tamaño de trama limitado de estas redes en comparación con la gran sobrecarga de cabecera de los protocolos IPv6, UDP y CoAP (por ejemplo, 40 octetos para la cabecera IPv6, 8 octetos para la cabecera UDP y más de 4 octetos para la cabecera CoAP frente a sólo uno o dos octetos de tamaño de trama que pueden estar disponibles para transmitir todas las cabeceras de los protocolos IPv6/UDP/CoAP). La adaptación del IPv6/UDP/CoAP sobre las LPWAN para hacer frente a este reto ha sido abordada por el grupo de trabajo LPWAN del IETF (Internet Engineering Task Force [Grupo de Trabajo de Ingeniería de Internet]) desde 2016.
[0007] Los trabajos iniciales del grupo del IETF se centran en la compresión de cabeceras de protocolo y en la fragmentación/reensamblaje como solución para economizar el consumo de ancho de banda de la red y para adaptar el tamaño de las cabeceras de protocolo IPv6, IPv6/UDP o IPv6/UDP/CoAP al tamaño de trama limitado de la capa 2 de las LPWAN. La compresión de cabeceras permite eliminar la información redundante y los campos no utilizados. Los trabajos divulgados en "draft-ietf-lpwan-ipv6-static-context-hc-00" y "draft-ietf-lpwan-coap-staticcontext-hc-00", propuestos por el grupo de trabajo del IETF, definen un nuevo esquema de compresión de cabecera de contexto estático (SCHC, por sus siglas en inglés) aplicable a la compresión de la cabecera del protocolo IPv6, la cabecera del protocolo UDP y la cabecera del protocolo CoAP, independientemente de la tecnología LPWAN utilizada.
[0008] SCHC se basa en la construcción de un contexto estático compartido entre los componentes de red para comprimir/descomprimir las cabeceras de los protocolos. Un contexto es un conjunto de reglas utilizadas para comprimir/descomprimir cabeceras. Una regla es un conjunto de valores de campo de cabecera identificados por un identificador de regla (ID de regla). El contexto es estático, lo que significa que el contenido del contexto, es decir, los valores de los campos de cabecera no cambian con el tiempo. Dicha propiedad permite evitar una sincronización compleja, que constituye la operación que consume más recursos durante la compresión de cabecera. Un contexto compartido se almacena, en consecuencia, en los dispositivos dentro de la LPWAN que almacenan el mismo ID de regla para comprimir/descomprimir un tráfico específico. En el documento W o 2011/114183 A1 (MOBILE DEVICES INGENIERIE [FR]; ZARKA JULIEN [FR]; DE PHILY VINCENT [I) 22 de septiembre de 2011 (22-09-2011) se da a conocer un sistema de comunicación de datos, adaptado para manejar la comunicación de datos entre al menos un servidor remoto conectado a Internet y un dispositivo móvil conectado a una red inalámbrica.
[0009] La figura 1 representa la arquitectura de una LPWAN ilustrativa que comprende dos dispositivos, el dispositivo 1 y el dispositivo 2, cada uno de los cuales ejecuta aplicaciones que producen/aceptan flujos de IPv6/UDP/CoAP enviados/recibidos a/desde un servidor de aplicaciones a través de la LPWAN. Se muestran las comunicaciones bidireccionales entre los dos dispositivos y el servidor de aplicaciones. Los datos son transferidos a través de la pasarela de radio 103 y la pasarela de red 105. Los flujos producidos/recibidos se comprimen/descomprimen mientras se transfieren a través de la LPWAN. En consecuencia, cada uno del dispositivo 1 y el dispositivo 2 está dotado de una unidad de compresión/descompresión 101 referida SCHC C/D y una red SCHC C/D está integrada en la LPWAN, estando configuradas cada una de la unidad de compresión/descompresión 101 y la red SCHC C/D 107 para llevar a cabo acciones de compresión/descompresión en función del flujo dirigido. Por ejemplo, para comunicaciones de enlace ascendente que corresponden a la transferencia de datos desde el dispositivo 1 o el dispositivo 2 al servidor de aplicaciones, cada unidad de compresión/descompresión 101 se configura para comprimir al menos una de las cabeceras de los paquetes IPv6/UDP/CoAP para reducir el tamaño de las cabeceras. La trama obtenida se envía en una trama de capa 2 a la pasarela de radio 103 de la LPWAN. A continuación, los datos se transfieren desde la pasarela de radio 103 a la pasarela de red 105. La pasarela de red 105 envía entonces los datos a la red SCHC C/D 107 para su descompresión. La pasarela de red 105 comparte las mismas reglas con el dispositivo 1 y el dispositivo 2. A continuación, el paquete descomprimido se envía al servidor de aplicaciones a través de la red de Internet (por ejemplo, utilizando un enlace Ethernet IP). La red SCHC C/D 107 puede formar parte de la pasarela de red 105 o puede estar situada fuera de la pasarela de red 105 si se establece un túnel entre la pasarela de red 105 y la red SCHC C/D 107. Para las comunicaciones de enlace descendente, el principio es el mismo, salvo que la red SCHC C/D 107 realiza la compresión de cabecera y la respectiva unidad de compresión/descompresión 101 implementada en el dispositivo 1 y el dispositivo 2 realiza las operaciones de descompresión.
[0010] La figura 2 muestra el contexto estático según la compresión/descompresión SCHC. El contexto comprende un conjunto de N reglas indicadas por Regla 1, Regla 2,..., Regla N. Una regla se utiliza para la compresión de una o más cabeceras de protocolo; por ejemplo, una regla puede utilizarse para la cabecera del protocolo IPv6, las cabeceras de los protocolos IPv6/UDP/CoAP o las cabeceras IPv6/ICMP. Cada regla comprende un conjunto de N campos de cabecera y se define mediante un ID de regla. Un campo de cabecera (también denominado "campo") corresponde a un segmento de la cabecera que debe comprimirse/descomprimirse y describe la acción realizada para comprimir/descomprimir este campo. Un campo comprendido en una regla determinada contiene:
- un identificador de campo (ID de campo): un valor único que define el campo;
- un valor objetivo (VO): un valor comparado con el valor de campo de cabecera de paquete;
- un operador de concordancia (OC): un operador utilizado para realizar la comparación entre el valor objetivo y el valor de campo de cabecera de paquete, y
- una función de compresión/descompresión (C/D) (FCD): utilizada para describir el proceso de compresión/descompresión del campo.
[0011] El esquema de compresión/descompresión SCHC se basa en el envío del ID de regla en lugar de valores de campo conocidos entre las diferentes entidades de compresión/descompresión de la LPWAN. El proceso de compresión/descompresión SCHC consiste en varios pasos. En primer lugar, se selecciona una regla de compresión. Para conseguir la selección de la regla, se compara un valor de campo de cabecera con el valor objetivo almacenado en la regla para ese campo mediante el operador de concordancia. Si todos los campos de la cabecera de paquete coinciden con una de las reglas del contexto, es decir, satisfacen todos los operadores de coincidencia de una regla, se selecciona esta regla y el compresor utiliza las funciones C/D de la regla seleccionada para comprimir la(s) cabecera(s) de paquete y envía el ID de regla al descompresor. Al recibir el paquete comprimido, una unidad de descompresión identifica la regla utilizada mediante el ID de regla recibido y realiza operaciones de descompresión en el paquete recibido para reconstruir el paquete original mediante la aplicación de la función C/D correspondiente.
[0012] El borrador SCHC "draft-ietf-lpwan-ipv6-static-context-hc-01" define otros mecanismos de fragmentación aplicados después de la compresión/descompresión para fragmentar el paquete obtenido en múltiples fragmentos con el fin de adaptar el tamaño del paquete comprimido al tamaño de la unidad de datos de capa 2 de la LPWAN si, después de aplicar la compresión de cabecera, el tamaño del paquete es mayor que la carga útil máxima de la unidad de datos de capa 2 de la LPWAN o si no se ha realizado la compresión de cabecera.
[0013] La compresión y fragmentación de cabecera se realiza en una capa de adaptación entre la capa de enlace y la capa de red de la pila de protocolos TCP/IP, modificada en consecuencia para adaptar IPv6 a las redes loT limitadas. Los mecanismos de compresión y fragmentación SCHC desarrollados para las LPWAN no se ocupan de la compresión de los campos dinámicos y no son aplicables a los protocolos con cabeceras que comprenden campos dinámicos, como las cabeceras del TCP (Transmission Control Protocol [Protocolo de control de transmisión]).
[0014] En la capa de transporte, se elige UDP como protocolo de capa de transporte. Aunque la capa de protocolo de transporte dominante en Internet es el TCP, es posible que las redes limitadas, como las redes loT, no admitan el TCP y no permitan el tráfico TCP debido, principalmente, a las limitaciones de energía y ancho de banda de los dispositivos/redes loT y a la alta latencia introducida por el TCP (por ejemplo, al realizar el establecimiento de comunicación de TCP, la entrega por orden o los mecanismos de retransmisión) que no se admite en aplicaciones con requisitos de baja latencia.
[0015] Por lo tanto, es necesario desarrollar esquemas y protocolos de comunicación que permitan admitir el tráfico TCP en redes limitadas como las redes loT/M2M.
RESUMEN
[0016] De acuerdo con la presente invención, se proporciona un sistema conforme a la reivindicación 1.
[0017] Según algunas realizaciones, el proxy de origen puede estar configurado para enviar, al proxy de destino, un paquete de modo de compresión simple para confirmar los datos recibidos a través de un dato TCP vacío y un tercer campo siguiente igual a un valor de bit de fin predefinido si el dispositivo de origen entrega un fin de conexión, estando el proxy de destino configurado para enviar, al proxy de origen, un paquete de modo de compresión simple que comprende datos TCP vacíos y un tercer campo siguiente igual a un valor de bit de fin predefinido si el dispositivo de destino entrega un fin de conexión.
[0018] Según algunas realizaciones, el dispositivo de origen puede estar configurado para intercambiar paquetes TCP con el proxy de origen a través de una conexión TCP de origen según la pila de protocolos TCP/IP y el dispositivo de destino puede estar configurado para intercambiar paquetes TCP con el proxy de destino a través de una conexión TCP de destino según la pila de protocolos TCP/IP.
[0019] Según algunas realizaciones, el proxy de origen puede estar configurado además para encapsular cada paquete de modo de compresión simple en un datagrama IP y para encapsular el datagrama IP en una trama de modo de compresión simple, estando el proxy de origen y el proxy de destino configurados para intercambiar tramas de modo de compresión simple a través del enlace inalámbrico y para confirmar la recepción de cada trama de modo de compresión simple.
[0020] Según algunas realizaciones, el proxy de origen y el proxy de destino pueden estar configurados para fragmentar una trama de modo de compresión simple en dos o más fragmentos en función de un tamaño de trama predefinido en relación con las especificaciones del enlace inalámbrico.
[0021] Según algunas realizaciones, el proxy de origen puede estar configurado para realizar la compresión de cabecera al datagrama IP, la compresión de cabecera aplicada a un datagrama IP proporcionando residuo de cabecera IP y estando asociada a un identificador de regla, una trama de modo de compresión simple encapsulando el datagrama IP comprendiendo además el residuo de compresión de cabecera IP y el identificador de regla, estando el proxy de destino configurado para realizar la descompresión de cabecera al datagrama IP encapsulado en cada trama de modo de compresión simple enviada por el proxy de origen de acuerdo con dicho identificador de regla y residuo de compresión de cabecera IP.
[0022] Según algunas realizaciones, el dispositivo de origen y el dispositivo de destino pueden estar configurados, además, para utilizar un protocolo de aplicación limitado, que produce mensajes de protocolo de aplicación limitado comprendidos en cada paquete TCP, estando el proxy de origen configurado, además, para realizar la compresión de cabecera a la cabecera de cada mensaje de protocolo limitado, proporcionando la compresión de cabecera residuo de compresión de cabecera y estando asociado a un identificador de regla, la trama de modo de compresión simple determinada a partir de uno o más paquetes TCP que comprenden datos de protocolo de aplicación limitado que comprenden, además, el identificador de regla y el residuo de compresión de cabecera, estando el proxy de destino configurado, además, para realizar la descompresión de cabecera en cada paquete TCP reconstruido de acuerdo con el residuo de compresión de cabecera y el identificador de regla.
[0023] Según algunas realizaciones, la compresión de cabecera y la descompresión de cabecera pueden realizarse mediante la utilización de un protocolo de compresión de cabecera de contexto estático.
[0024] Según algunas realizaciones, cada identificador de regla puede estar relacionado con un identificador de conexión, estando el proxy de origen y el proxy de destino configurados, además, para almacenar una tabla de asignación en la que cada identificador de regla es asignado a un identificador de conexión.
[0025] Según algunas realizaciones, el enlace inalámbrico puede ser una red de área amplia de baja potencia o una red inalámbrica de corto alcance de baja potencia, estando el proxy de origen y el proxy de destino ubicados en nodos de pasarela en la red de área amplia de baja potencia o en la red inalámbrica de corto alcance de baja potencia.
[0026] Según algunas realizaciones, la red de área amplia de baja potencia puede utilizar una tecnología elegida en un grupo que comprende el LoRaWan, el Sigfox, el NB-IoT, el IEEE.802.15.4 y el Weightless.
[0027] También se proporciona un método según la reivindicación 13.
[0028] También se proporciona un programa según la reivindicación 14.
[0029] Ventajosamente, las realizaciones de la invención proporcionan protocolos de transmisión simplificados que permiten un soporte de tráficos TCP a través de redes inalámbricas.
[0030] Ventajosamente, las realizaciones de la invención permiten el intercambio de datos TCP entre nodos/entidades conectadas a través de redes limitadas restringidas en términos de potencia/velocidades de datos/ancho de banda.
[0031] Ventajosamente, las realizaciones de la invención proporcionan protocolos de comunicación simples que combinan un protocolo de modo de compresión simple realizado en los datos TCP y un mecanismo de compresión/descompresión de cabecera aplicado a datagramas IP que permite una reducción de la cantidad de datos transmitidos a través de redes inalámbricas.
[0032] Otras ventajas de la presente invención serán evidentes para los expertos en la materia tras el análisis de los dibujos y de la descripción detallada.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
[0033] Los dibujos adjuntos, que se incorporan a esta memoria y forman parte de ella, se facilitan únicamente con fines ilustrativos e ilustran diversas realizaciones de la invención junto con la descripción general de la invención proporcionada anteriormente y la descripción detallada de las realizaciones proporcionada a continuación.
La figura 1 representa la arquitectura de red de una red de área amplia de baja potencia que implementa la compresión/descompresión de cabecera de contexto estático de la técnica anterior;
La figura 2 es un diagrama de bloques que ilustra la estructura de un contexto utilizado en mecanismos de compresión/descompresión de cabecera estáticos de la técnica anterior;
La figura 3A es un diagrama esquemático que ilustra un sistema de comunicación ilustrativo y las pilas de protocolo de un origen, un proxy de origen, un proxy de destino y un proxy de destino, según algunas realizaciones de la invención;
La figura 3B es un diagrama esquemático que ilustra las unidades de datos de protocolo construidas en un proxy de origen o un proxy de destino, según algunas realizaciones;
La figura 3C es un diagrama esquemático que ilustra un sistema de comunicación ilustrativo y las pilas de protocolo de un origen, un proxy de origen, un proxy de destino y un proxy de destino, según algunas realizaciones de la invención en las que se realiza la compresión/descompresión de cabecera a las cabeceras de datagramas IP;
La figura 4 es un diagrama esquemático que ilustra un sistema de comunicación ilustrativo y las pilas de protocolo de un origen, un proxy de origen, un proxy de destino y un proxy de destino, según algunas realizaciones de la invención en las que se realiza la compresión/descompresión de cabecera a las cabeceras de datagramas IP y las cabeceras de mensaje CoAP.
La figura 5 es un flujo de conexión de una comunicación ilustrativa entre un origen y un destino, según algunas realizaciones;
La figura 6 es un diagrama de estado que ilustra los estados y cambios de estado del modo de compresión simple según algunas realizaciones;
La figura 7 es un diagrama de flujo que representa un método de transmisión de datos TCP desde un origen a un destino, según algunas realizaciones; y
La figura 8 es un diagrama de bloques que ilustra la estructura de un dispositivo que opera en un sistema, según algunas realizaciones de la invención.
DESRIPCIÓN DETALLADA
[0034] Las realizaciones de la invención proporcionan sistemas y métodos que permiten el intercambio de tráfico TCP entre un nodo de origen (al que también se hace referencia como "un origen" o "un dispositivo de origen") y un nodo de destino (al que también se hace referencia como "un destino" o "un dispositivo de destino") conectados a través de una red inalámbrica, preferiblemente una red limitada como la red inalámbrica loT/M2M que representa restricciones de bajo consumo de energía/larga duración de batería/baja latencia/poco hardware y coste de funcionamiento/alta densidad de conexión, como las redes de área amplia de baja potencia y las redes loT de corto alcance de baja potencia.
[0035] El origen se refiere a un iniciador de sesión TCP que produce datos que comprende paquetes TCP y el destino se refiere al receptor de sesión TCP al que se dirigen los datos producidos por el origen. Tanto el origen como el destino pueden utilizar una pila de protocolos que permite la conexión a redes basadas en IP (por ejemplo, la pila de protocolos TCP/IP) y que tiene una dirección IP válida.
[0036] Las realizaciones de la invención pueden implementarse en cualquier red de transmisión o comunicación basada en internet que utilice el protocolo de internet para intercambiar datos. El origen y el destino pueden ser cualquier dispositivo/terminal que implemente la pila de protocolos TCP/IP para conectarse a través de Internet. La red restringida puede ser cualquier red inalámbrica de dispositivos restringidos que requieren poco ancho de banda, poco consumo de energía o velocidades de datos bajas (por ejemplo, redes de área amplia de baja potencia y redes inalámbricas de corto alcance de baja potencia). Algunos ejemplos de redes limitadas comprenden las redes loT y M2M.
[0037] Con referencia a la figura 3A, se muestra un sistema ilustrativo 300 en el que pueden implementarse las realizaciones de la invención. El sistema 300 puede ser cualquier sistema de transmisión/comunicación/recopilación/procesamiento de datos en el que un origen 301 está configurado para intercambiar datos que comprenden flujos TCP/IP con un destino 307 a través de un enlace inalámbrico 304.
[0038] En realizaciones preferidas, el sistema 300 puede ser cualquier red loT o cualquier red M2M utilizada en aplicaciones de consumo, comerciales, industriales y de infraestructura. Algunas aplicaciones de consumo ilustrativas comprenden vehículos conectados (Internet de Vehículos, IoV), la domótica/hogar inteligente, las ciudades inteligentes, la tecnología ponible y la salud conectada. Algunas aplicaciones comerciales ilustrativas comprenden la medicina, la asistencia médica y el transporte. En medicina, puede utilizarse un sistema de asistencia sanitaria digitalizado que conecta los recursos médicos y los servicios de asistencia sanitaria, en el que se utilizan monitores y sensores especiales para permitir el seguimiento sanitario a distancia y la notificación de emergencias. En los sistemas de transporte, el loT que utiliza, por ejemplo, sensores inalámbricos, puede facilitar la interacción entre los vehículos y la infraestructura, así como las comunicaciones inter e intravehiculares, el control inteligente del tráfico, el aparcamiento inteligente y la seguridad y la asistencia en carretera. Algunas aplicaciones industriales ilustrativas comprenden aplicaciones en la agricultura, por ejemplo, en la agricultura mediante la utilización de sensores para recoger datos sobre la temperatura, la precipitación, la humedad, la velocidad del viento y el contenido del suelo. Algunas aplicaciones de infraestructura ilustrativas comprenden el uso de dispositivos loT para realizar operaciones de supervisión y control de infraestructuras urbanas y rurales, como puentes y vías férreas.
[0039] El origen 301 y/o el destino 307 pueden ser cualquier dispositivo/objeto físico con conexión a Internet que cuente con las tecnologías de hardware y/o software necesarias para permitir la comunicación a través de internet. El origen 301 y/o el destino 307 pueden ser cualquier dispositivo estándar conectado a Internet, como ordenadores de sobremesa, servidores, máquinas virtuales, ordenadores portátiles, teléfonos inteligentes y tabletas. En las realizaciones preferidas, el origen 301 y/o el destino 307 pueden ser cualquier dispositivo loT/M2M o cosa conectada que opera en una red loT/M2M, como los dispositivos médicos, los monitores de temperatura y clima, las tarjetas conectadas, los contadores inteligentes, las consolas de juegos, los asistentes digitales personales, los monitores de salud y estado físico, las luces, los termostatos, los electrodomésticos, las puertas de garaje, los dispositivos de seguridad, los drones, la ropa inteligente, los dispositivos de salud electrónica, los robots y los enchufes inteligentes. Un dispositivo loT/M2M puede ser cualquier dispositivo físico, vehículo, electrodoméstico o cualquier objeto/cosa con electrónica, software, sensores, actuadores y conectividad que permita la conexión remota para la recogida e intercambio de datos con una plataforma loT/M2M, por ejemplo. Un sensor puede ser cualquier órgano/objeto/dispositivo sensorial (por ejemplo, un transductor) que pueda medir todo tipo de características, como la temperatura, la humedad, la acústica/sonido/vibración, la química/gas, la fuerza/carga/deformación/presión, la eléctrica/magnética, la visión artificial/óptica/luz ambiental, o la posición/presencia/proximidad.
[0040] El origen 301 y/o el destino 307 pueden ser fijos o móviles y/o pueden ser supervisados y/o controlados a distancia. El origen 301 y/o el destino 307 pueden estar equipados con fuentes de energía que proporcionan energía a los diferentes componentes que aseguran el funcionamiento de estos dispositivos (por ejemplo, baterías de pilas secas, células solares y células de combustible).
[0041] El enlace inalámbrico 304 puede representar cualquier red inalámbrica que permite el loT en un espectro con o sin licencia. Los enlaces inalámbricos 304 ilustrativos comprenden las redes de corto alcance de baja potencia y las LPWAN. Algunas tecnologías LPWAN ilustrativas comprenden LoRaWAN, Sigfox, LTE-NB1, n B-IoT, IEEE.802.15.4 y Weightless.
[0042] En el sistema 300, el origen 301 y el destino 307 están configurados para intercambiar datos que comprenden tráfico TCP/IP incluyendo uno o más paquetes TCP a través del enlace inalámbrico 304. En la figura 3, se muestran comunicaciones bidireccionales entre el origen 301 y el destino 307. El origen 301 puede corresponder a un cliente TCP o a un servidor TCP, en función de la dirección de los flujos de datos en enlace ascendente o enlace descendente. Por ejemplo, el origen 301 puede ser un cliente TCP que intenta comunicarse con un servidor que está disponible en Internet.
[0043] Las realizaciones de la invención proporcionan protocolos de comunicación que permiten el soporte de datos que comprenden tráfico TCP/IP a través de redes inalámbricas 304 utilizando un proxy de origen 303 y un proxy de destino 305. En consecuencia, una conexión TCP entre el origen 301 y el destino 307 que son datos de intercambio que comprenden tráfico TCP/IP a través del enlace inalámbrico 304 puede comprender tres conexiones intermedias que implican un proxy de origen 303 y un proxy de destino 305. Los datos de tráfico TCP/IP intercambiados pueden comprender uno o más paquetes t Cp . El proxy de origen 303 y el proxy de destino 305 pueden estar ubicados en la periferia del enlace inalámbrico 304, por ejemplo, en las pasarelas de red inalámbrica. Más específicamente, el proxy de origen 303 puede estar ubicado en el lado del origen 301 y el proxy de destino 305 puede estar ubicado en el lado del destino 307. El proxy de origen 303 y el proxy de destino 305 pueden ser un router, un conmutador o cualquier dispositivo que opera en la pasarela de red del enlace inalámbrico 304.
[0044] El origen 301 y el destino 307 pueden no saber que se comunican a través de un enlace inalámbrico 304. El proxy de origen 301 y el proxy de destino 307 se comunican a través del enlace inalámbrico 304. El proxy de origen 303 y el proxy de destino 305 pueden implementarse de modo que el origen 301 pueda acceder solamente al proxy de origen 303 y el destino 307 pueda acceder solamente al proxy de destino 305.
[0045] Las realizaciones de la invención proporcionan un protocolo de modo de compresión simple utilizado en redes inalámbricas, por ejemplo, en redes limitadas, que se basan en dos puntos de conexión, el origen 301 y el destino 307. La conexión TCP se realiza fuera de la red inalámbrica y el protocolo de modo de compresión simple simulará la conexión mediante la utilización de uno o más proxies, el proxy de origen 301 y/o el proxy de destino 305.
[0046] Según algunas realizaciones, el proxy de origen 303 y el proxy de destino 305 pueden implementarse en las pasarelas de red del enlace inalámbrico 304 de manera independiente del origen 301 y del destino 307, respectivamente. Esto significa que el proxy de origen 303 y el proxy de destino 305 pueden ser dos dispositivos físicamente (desde una perspectiva de hardware) independientes del origen 301 y del destino 307. En tales realizaciones, es decir, cuando se utilizan dos proxies, el enlace inalámbrico 304 se encuentra en medio de la conexión TCP entre el origen 301 y el destino 307.
[0047] Según otras realizaciones, el proxy de origen 303 (o, respectivamente, el proxy de destino 305) puede implementarse en el dispositivo de origen 301 (o, respectivamente, en el dispositivo de destino 307). En tales realizaciones, el proxy de origen 303 (o, respectivamente, el proxy de destino 305) puede implementarse en el dispositivo de origen 301 como una parte de hardware, estando el dispositivo de origen 301 (respectivamente, el dispositivo de destino 307) configurado para implementar las funcionalidades realizadas por el proxy de origen 303 (respectivamente, el proxy de destino 307). En tales realizaciones, es decir, cuando sólo se utiliza un proxy (el proxy de origen 301 o el proxy de destino 305), en función de qué dispositivo entre el origen 301 o el destino 307 implementa las funcionalidades del proxy, este dispositivo puede estar configurado para utilizar el protocolo de modo de compresión simple y puede no tener que convertir las tramas de modo de compresión simple en tramas TCP.
[0048] El enlace de comunicación entre el origen 301 y el destino 307 puede comprender tres segmentos/enlaces: un enlace de origen 302 entre el origen 301 y el proxy de origen 303, el enlace inalámbrico 304 entre el proxy de origen 303 y el proxy de destino 305, y un enlace de destino 306 entre el proxy de destino 305 y el destino 307. El enlace de origen 302 y el enlace de destino 306 pueden ser cualquier enlace por cable o inalámbrico basado en IP (por ejemplo, Ethernet por cable, Ethernet inalámbrico, Ethernet móvil). El enlace de origen 302 y/o el enlace de destino 306 pueden comprender una red de tamaño arbitrario (p. ej., una red de área local).
[0049] En algunas realizaciones, la red en el enlace de origen 302 y/o el enlace de destino 306 puede comprender múltiples redes de acceso que proporcionan servicios a múltiples usuarios.
[0050] Las pilas de protocolos se representan por debajo del origen 301, el proxy de origen 303, el proxy de destino 305 y el destino 307. En consecuencia, una conexión TCP entre el origen 301 y el destino 307 se divide "virtualmente" en tres conexiones: una conexión TCP de origen 312 entre el origen 301 y el proxy de origen 303, una conexión inalámbrica denominada "conexión de modo de compresión simple" 314 entre el proxy de origen 303 y el proxy de destino 305, y una conexión TCP de destino 316 entre el proxy de destino 305 y el destino 307. Los paquetes TCP se transfieren a través de la conexión TCP de origen 312 y la conexión TCP de destino 316 de acuerdo con la pila de protocolos TCP/IP. El proxy de origen 301 y el proxy de destino 305 garantizan la transición entre las conexiones TCP (conexiones TCP de origen y de destino) y la conexión de modo de compresión simple a través del enlace inalámbrico 304 estableciendo una conexión específica que permite soportar datos TCP/iP a través del enlace inalámbrico 304. Los datos TCP son enviados a través del enlace inalámbrico 304 en un nuevo formato de cabecera utilizando el protocolo de modo de compresión simple.
[0051] En la conexión TCP de origen 312 y para los datos enviados desde el origen 301, el origen 301 actúa como cliente TCP/IP y el proxy de origen 303 actúa como servidor TCP. Del mismo modo, en la conexión TCP de destino 316 y para los datos enviados desde el destino 317 al proxy de destino 305, el destino 317 actúa como cliente TCP y el proxy de destino 305 actúa como servidor TCP. Los papeles del origen 301 y del proxy de origen 303 (respectivamente, el destino 307 y el proxy de destino 305) se intercambian cuando los datos se dirigen desde el proxy de origen 303 al origen 301 (respectivamente, desde el proxy de destino 305 al destino 307) donde el origen 301 actúa como servidor TCP y el proxy de origen 303 actúa como cliente TCP (respectivamente, el destino 307 actúa como servidor TCP y el proxy de destino 305 actúa como cliente TCP). Se ahorra ancho de banda porque el proxy o los proxies sólo envían las tramas de datos TCP a través del enlace inalámbrico; el resto de las tramas TCP se generan y se mantienen en el propio proxy para responder con la trama correcta a través de la conexión TCP.
[0052] El origen 301 y el destino 307 pueden estar configurados para operar mediante la utilización de la pila de protocolos TCP/IP estándar sin modificar. Por consiguiente, la capa de aplicación de origen 3011 del origen 3011 y la capa de aplicación de destino 3071 del destino 307 pueden utilizar aplicaciones TCP que producen/reciben datos TCP/IP como Web (HTTP), SSH, Protocolo de Transferencia de Archivos FTP, telnet, E-mail (Protocolo Simple de Transferencia de Correo), IMAP/POP, Secure Shell (SSH) y DNS. La capa de transporte 3012 del origen 301 y la capa de transporte 3072 del destino 307 utilizan el TCP que proporciona servicios orientados a la conexión para transportar servicios de capa de aplicación entre el origen 301 y el proxy de origen 303 y entre el destino 307 y el proxy del destino 305. Los datos de aplicación entregados por la capa de aplicación de origen 3011 y la capa de aplicación de destino 3071 se dividen en paquetes TCP en las capas de transporte 3012 y 3072. Un paquete TCP comprende una sección de datos TCP que comprende los datos de aplicación y una cabecera TCP. Los paquetes TCP se reenvían a las capas de red 3013 y 3073, respectivamente, del origen 301 y del destino 307 para ser enrutados a través del enlace de origen 302 y del enlace de destino 306. Las capas de red 3013 y 3073 pueden utilizar el Protocolo de Internet versión 4 (IPv4) o el Protocolo de Internet versión 6 (IPv6). Las capas de red 3013 y 3073 pueden utilizar otros protocolos como el ICMP (Internet Control Message Protocol), el IGMP (Internet Group Management Protocol), el Ml D (Multicast Listener Protocol), el ARP (Address Resolution Protocol), el ICMPv6 (Internet Control Message Protocol for IPv6) y el RARP (Reverse Address Resolution Protocol). Los paquetes TCP reenviados a las capas de red 3013 y 3073 pueden ser encapsulados en datagramas IP, un datagrama IP que encapsula un paquete TCP comprendiendo una cabecera IP y una sección de datos IP. Los datagramas IP se mueven entonces entre las capas de enlace (a las que se hace referencia también como "capas físicas"); por ejemplo, la capa de enlace 3014 del origen 301 y la capa de enlace 3074 del destino 307. Los datos se envían a través de las capas de enlace en forma de trama de un tamaño de trama determinado.
[0053] Según algunas realizaciones, el protocolo TLS puede utilizarse en las capas de transporte del proxy de origen 303 y el proxy de destino 305 para proporcionar una conexión segura de modo de conexión simple entre el proxy de origen 303 y el proxy de destino 305, lo que permite la prevención contra escuchas, manipulaciones o falsificación de mensajes.
[0054] En las realizaciones en las que el proxy de origen 303 o el proxy de destino 305 se implementan, respectivamente, en el origen 301 o el destino 307, el origen 301 o el destino 307 pueden estar configurados para implementar una pila de protocolos TCP/IP modificada en la que TCP se sustituye por el protocolo de modo de compresión simple (SCM) en la capa de transporte.
[0055] El proxy de origen 303 y el proxy de destino 307 según las realizaciones de la invención pueden operar mediante la utilización de una pila de protocolos modificada para adaptar el tráfico TCP/IP a las limitaciones del enlace inalámbrico 304. Más específicamente, el proxy de origen 303 y el proxy de destino 305 pueden estar configurados para operar e intercambiar datos de acuerdo con un protocolo SCM que implica una modificación de las pilas de protocolo 313 y 315 del proxy de origen 303 y del proxy de destino 305, respectivamente. El proxy de origen 303 y el proxy de destino 305 convierten los paquetes entrantes/paquetes salientes recibidos/destinados desde/hacia el origen 301 o desde/hacia el destino 307 de manera que los paquetes entrantes parecen haberse originado en el destino 307 y los paquetes salientes parecen haberse originado en el origen 301. El protocolo de modo de compresión simple proporciona un enlace eficiente orientado a la conexión entre el proxy de origen 303 y el proxy de destino 305 y un soporte de paquetes TCP/IP intercambiados entre el origen 301 y el destino 307.
[0056] Cuando el dispositivo de origen 301 envía uno o más paquetes TCP, el proxy de origen 303 puede configurarse, de acuerdo con el protocolo de modo de compresión simple, para:
- recibir el uno o más paquetes TCP enviados por el origen 301 a través de la conexión TCP de origen; - determinar un paquete de modo de compresión simple a partir del uno o más paquetes TCP enviados por el origen 301 mediante la eliminación de la cabecera de paquete TCP comprendida en cada paquete t Cp . El paquete de modo de compresión simple comprende las secciones de datos TCP comprendidas en el uno o más paquetes TCP enviados por el origen 301 y una cabecera que comprende un identificador de conexión indicado como CID. El CID se utiliza para identificar una conexión entre el proxy de origen 303 y el proxy de destino 305, pero no se necesita cuando solo hay una única conexión que utiliza el identificador.
[0057] Tras construir el paquete de modo de compresión simple, el proxy de origen 303 puede configurarse para establecer una conexión de modo de compresión simple con el proxy de destino 305 y enviar el paquete de modo de compresión simple al proxy de destino 305. El proxy de destino 305 puede configurarse para:
- recibir el paquete de modo de compresión simple y confirmar la recepción al proxy de origen 303;
- determinar uno o más paquetes TCP reconstruidos mediante la extracción de las secciones de datos de cada paquete TCP a partir del paquete de modo de compresión simple; y
- enviar el uno o más paquetes TCP reconstruidos al dispositivo de destino 307.
[0058] Como se ilustra en la figura 3A, el protocolo de modo de compresión simple introduce una modificación en las capas de transporte de las pilas de protocolos 313 y 315 del proxy de origen 303 y del proxy de destino 305, respectivamente.
[0059] En las capas de transporte 3032 y 3052, el protocolo TCP se sustituye por el protocolo de modo de compresión simple, que convierte los paquetes TCP entrantes/salientes en paquetes a los que se hace referencia como "paquetes de modo de compresión simple". Los paquetes TCP entrantes/salientes se refieren a los paquetes TCP recibidos/dirigidos desde/hacia el origen 301 o el destino 307. En consecuencia, el TCP no se ejecuta en la conexión de modo de compresión simple 314.
[0060] Según algunas realizaciones, el proxy de origen 303 y/o el proxy de destino 305 pueden configurarse para utilizar el tamaño de búfer de ventana de recepción TCP para limitar la cantidad de datos que se han de enviar a través del enlace inalámbrico 304.
[0061] Según algunas realizaciones, las cabeceras TCP pueden eliminarse de los paquetes TCP procesados de acuerdo con el protocolo de modo de compresión simple para convertir un paquete TCP en un paquete de modo de compresión simple.
[0062] Con referencia a la figura 3B, se ilustra la encapsulación de los datos de aplicación que descienden por las capas del proxy de origen 303 y las estructuras de las unidades de datos de protocolo de acuerdo con la pila de protocolos modificada del proxy de origen 303. Las mismas unidades de datos de protocolo se aplican en el proxy de destino 305 en una dirección ascendente desde la capa física hasta la capa de aplicación para procesar una trama de modo de compresión simple recibida desde el proxy de origen 303. El proxy de destino 305 puede estar configurado para realizar operaciones simétricas de acuerdo con las operaciones realizadas por el proxy de origen 303. La sección denominada "Datos" se refiere a los datos de aplicación producidos/recibidos en las capas de aplicación 3031. En la capa de transporte 3032 que implementa el protocolo de modo de compresión simple, el proxy de origen 303 puede configurarse para encapsular datos de aplicación en un paquete de modo de compresión simple. El paquete de modo de compresión simple comprende una sección de datos de modo de compresión simple que comprende las secciones de datos de uno o más paquetes TCP previamente recibidos del origen 301 y una cabecera de paquete de modo de compresión simple (por ejemplo, una cabecera de trama de capa 2 LPWAN). El proxy de origen 303 puede estar configurado además para encapsular cada paquete de modo de compresión simple en un datagrama IP en la capa de red 3033. Un datagrama IP que encapsula un paquete SCM comprende una sección de datos IP que contiene el paquete SCM y una cabecera IP. El proxy de origen 303 puede configurarse para encapsular además el datagrama IP en una trama de modo de compresión simple en la capa física 3034. El proxy de origen 303 y el proxy de destino 305 pueden configurarse para intercambiar tramas de modo de compresión simple a través del enlace inalámbrico 304 y para confirmar la recepción de cada trama de modo de compresión simple.
[0063] Como se ilustra en la figura 3B, un paquete de modo conectado simple puede comprender datos de paquete SCM y una cabecera (a la que también se hace referencia como "cabecera basada"). Los datos de paquete SCM pueden comprender valores de opciones TCP cuando estén disponibles, datos que comprenden n valores de datos indicados mediante DATOS1,...,DATOSn. La longitud de unos datos DATOSi para i=1,...,n se indica mediante longitudo A T O S i. Los datos se enviarán con el formato LV que indica (Longitud, Valor). La sección indicada mediante Síl para i=1,...,n comprende la longitud de DATOSi y la sección indicada mediante Sv comprende el valor de DATOSi. El paquete SCM puede comprender además una sección de relleno que puede utilizarse cuando sea necesario. No se pueden utilizar más de 7 bits de relleno. El relleno puede añadirse después de la concatenación de los datos a la cabecera SCM para que sea fácil recuperar el relleno.
[0064] Según algunas realizaciones con referencia a la figura 3B, además del identificador de conexión, la cabecera de un paquete de modo de compresión simple puede comprender, además:
- un primer campo siguiente indicado mediante Ns (al que se hace referencia como "número de secuencia de envío" o "número de secuencia del origen") que representa un número del paquete de modo de compresión simple enviado por el proxy de origen 303 al proxy de destino 305 y que se incrementa en uno cada vez que se envía un paquete SCM. Este campo es de longitud variable;
- un segundo campo siguiente indicado mediante Nr (al que se hace referencia como "número de secuencia de recepción" o "número de secuencia del destino") que representa un número del paquete de modo de compresión simple que se espera que reciba el proxy de origen 303 del proxy de destino 305, y que se incrementa en uno cada vez que se envía un paquete en la otra dirección. Este campo es de longitud variable;
- un tercer campo siguiente indicado mediante E (conexión de fin), que indica si el origen 301 o el destino 307 entregan un fin de conexión TCP. Este campo tiene una longitud de 1 bit y se establece cuando la conexión entre el origen 301 y el destino 307 debe cerrarse. En caso contrario, se envía E=0;
- un cuarto campo siguiente indicado mediante S (trama simple), que indica si el paquete SCM contiene una o múltiples tramas de datos TCP no concatenadas sino juntas en el mismo paquete SCM. Este campo tiene una longitud de 1 bit. Cuando está establecido, significa que el paquete SCM lleva múltiples paquetes TCP. Cuando hay un solo paquete TCP, el bit no está establecido ni se envía. Los datos del paquete SCM se envían después de un campo de opciones o después de los campos de cabecera basados cuando el campo de opciones no se envía;
- un quinto campo siguiente indicado mediante O (opciones), que indica si hay algunas opciones TCP para ser enviadas, las opciones TCP representan un campo comprendido en la cabecera de un paquete TCP. Este campo tiene un campo de longitud variable que da la longitud de las opciones TCP que se colocarán justo después del final de la cabecera basada. Cuando este campo no está establecido, no se envía.
[0065] La longitud de cada campo depende de la conexión y se define mientras se utiliza la transmisión.
[0066] El protocolo SCM se utiliza para transportar paquetes TCP a través del enlace inalámbrico 304. En consecuencia, la cabecera TCP de cada paquete Tc P se comprime en algunos bits de señalización. El establecimiento de la conexión TCP y la solicitud de retransmisiones pueden no ser enviados a través del enlace inalámbrico 304. Sólo los paquetes de datos TCP y la conexión de fin son enviados bajo el enlace inalámbrico 304 por el proxy de origen 303 y el proxy de destino 305.
[0067] Según algunas realizaciones, el proxy de origen 303 puede configurarse para enviar, al proxy de destino 305, un paquete de modo de compresión simple que comprende datos TCP vacíos (es decir, sección de datos de paquete SCM vacía) y un tercer campo siguiente igual a un valor de bit de fin predefinido si el dispositivo de origen 301 entrega un fin de conexión. El proxy de destino 305 puede configurarse para enviar, al proxy de origen 303 un paquete de modo de compresión simple que comprende sección de datos de paquete SCM vacía y un tercer campo siguiente igual a un valor de bit de fin predefinido si el dispositivo de destino 307 entrega un fin de conexión.
[0068] No se envía ninguna conexión de apertura a través del SCM por parte del proxy de origen 303 ni del proxy de destino 305 para reducir el retraso.
[0069] Según algunas realizaciones, el proxy de origen 303 y el proxy de destino 305 pueden configurarse para llevar a cabo la fragmentación de trama de modo que se fragmente cada trama de modo de compresión simple en dos o más fragmentos en función de un tamaño de trama predefinido en relación con las especificaciones de la capa de enlace del enlace inalámbrico 304. La fragmentación de trama puede utilizarse ventajosamente para reducir la cantidad de datos transmitidos a través del enlace inalámbrico 304 y para adaptar el tamaño de trama al tamaño de trama de la capa de enlace. El reensamblaje de trama puede realizarse en el proxy de origen 303 o en el proxy de destino 305 cuando se reciben tramas fragmentadas a través del enlace inalámbrico 304.
[0070] Según algunas realizaciones, el protocolo de modo de compresión simple puede utilizarse en combinación con protocolos de compresión/descompresión de cabecera aplicados en diferentes capas de las pilas de protocolo del proxy de origen 303 y del proxy de destino 305 para reducir el tamaño de las cabeceras de las correspondientes unidades de datos de protocolo. El protocolo SCM sólo afecta a las capas de transporte del proxy de origen 303 y del proxy de destino 305 y puede utilizarse con cualquier protocolo de compresión/descompresión de cabecera como RoHC, SCHC o VJ. En dichas realizaciones, el proxy de origen 303 y el proxy de destino 305 pueden implementar una unidad de compresión/descompresión configurada para realizar la compresión/descompresión de cabecera al menos a una cabecera de protocolo antes de enviar las tramas de modo de compresión simple a través del enlace inalámbrico 304. En dichas realizaciones, las longitudes de cabecera deben ser conocidas por el proxy de origen 303 y el proxy de destino 305.
[0071] Con referencia a la figura 3C, se ilustra una implementación ilustrativa del protocolo SCM en las capas de transporte 3032 y 3052 de las pilas de protocolos del proxy de origen 303 y del proxy de destino 305 junto con la aplicación de compresión/descompresión de cabecera IP en las capas de red 3133 y 3153 del proxy de origen 303 y del proxy de destino 305, respectivamente. Cada uno del proxy de origen 303 y el proxy de destino 305 puede implementar una unidad de compresión/descompresión de cabecera (C/D) configurada para realizar la compresión de cabecera para eliminar los campos no utilizados (por ejemplo, la etiqueta de flujo y la clase de tráfico) y la información redundante (por ejemplo, el identificador de interfaz en la dirección IPv6). La realización de la compresión o descompresión de cabecera por parte del proxy de origen 303 o del proxy de destino 305 depende de la dirección del paquete de modo de compresión simple. Por ejemplo, cuando un modo de compresión simple se dirige desde el proxy de origen 303 al proxy de destino 305, el proxy de origen 303 realiza la compresión de cabecera IP y el proxy de destino 305 realiza la descompresión de cabecera IP.
[0072] Por ejemplo, para los datos dirigidos desde el proxy de origen 303 al proxy de destino 305, el proxy de origen 303 puede configurarse para realizar la compresión de cabecera a cada datagrama IP incluyendo números de puerto TCP que encapsulan un paquete de modo de compresión simple. La compresión de cabecera aplicada para comprimir un datagrama IP proporciona un residuo de cabecera IP y se asocia con un identificador de regla. El proxy de origen 303 puede estar configurado además para encapsular el datagrama IP obtenido en una trama de modo de compresión simple. La trama de modo de compresión simple comprende, además del paquete SCM (que comprende la sección de datos de paquete TCP) encapsulado en el datagrama IP, el residuo de compresión de cabecera IP y el identificador de regla correspondiente a la compresión de cabecera aplicada al datagrama IP. Al recibir la trama de modo de compresión simple, el proxy de destino 305 puede configurarse para realizar la descompresión de cabecera al datagrama IP encapsulado en cada trama de modo de compresión simple recibida de acuerdo con el identificador de regla y el residuo de compresión de cabecera IP.
[0073] Con referencia a la figura 4, se ilustra una implementación ilustrativa del protocolo SCM en realizaciones en las que las pilas de protocolos CoAP/TCP/IP se utilizan en el origen 301 y el destino 307 en las capas 4012 y 4072, respectivamente. El origen 301 y el destino 307 utilizan, en consecuencia, un protocolo de aplicación limitado que produce/recibe mensajes de aplicación limitados comprendidos en cada paquete TCP. En dichas realizaciones, y para los datos enviados desde el proxy de origen 303 al proxy de destino 305, además de la compresión/descompresión de cabecera realizada a las cabeceras IP, el origen 303 puede configurarse para realizar la compresión/descompresión de cabecera a la cabecera de cada mensaje de protocolo limitado en la capa 4032, proporcionando la compresión de cabecera un residuo de compresión de cabecera y estando asociada a un identificador de regla. En dichas realizaciones, la trama de modo de compresión simple determinada en la capa 4035 a partir de uno o varios paquetes TCP que comprenden datos de protocolo de aplicación limitado puede comprender también, además del paquete SCM y el identificador de regla y el residuo de compresión IP correspondiente a la compresión de cabecera IP, el identificador de regla y el residuo de compresión de cabecera correspondiente a la compresión de la cabecera de mensaje CoAP. El proxy de destino 305 puede configurarse para realizar, además de la descompresión de cabecera IP aplicada al datagrama IP encapsulado en la trama de modo de compresión simple recibida, la descompresión de cabecera a la cabecera de cada mensaje de protocolo limitado comprendido en cada paquete TCP reconstruido de acuerdo con el residuo de compresión de cabecera y el identificador de regla correspondiente a la compresión de la cabecera de mensaje CoAP.
[0074] Según algunas realizaciones, el proxy de origen 303 y el proxy de destino 305 pueden configurarse para realizar la compresión/descompresión de cabecera para comprimir las cabeceras IP y, cuando proceda, las cabeceras de mensaje CoAP, mediante la aplicación del protocolo de compresión de cabecera de contexto estático.
[0075] En dichas realizaciones, cada uno del proxy de origen 303 y el proxy de destino 305 pueden configurarse para almacenar los contextos de compresión/descompresión de cabecera compartidos, por ejemplo, en una memoria no volátil. Los contextos almacenados definen cómo se comprimen/descomprimen las cabeceras de protocolo en el proxy de origen 303 y el proxy de destino 305. Las reglas de compresión admiten comunicaciones bidireccionales tanto en el proxy de origen 303 como en el proxy de destino 305. Los contextos de compresión de cabecera pueden proporcionarse previamente al proxy de origen 303 y/o al proxy de destino 305 en la utilización del sistema 300.
[0076] Según algunas realizaciones, el proxy de origen 303 y/o el proxy de destino 305 pueden configurarse para actualizar uno o más de los contextos de compresión de cabecera.
[0077] Según algunas realizaciones, cada identificador de regla asociado a la compresión/descompresión de la cabecera de un datagrama IP que encapsula un paquete de modo de compresión simple y la cabecera de una cabecera de mensaje CoAP pueden relacionarse con el identificador de conexión utilizado para identificar la conexión entre el proxy de origen 303 y el proxy de destino 305. En dichas realizaciones, el proxy de origen 303 y el proxy de destino 305 pueden configurarse para almacenar una tabla de asignación en la que cada identificador de regla es asignado a un identificador de conexión. La regla de compresión puede definir los campos del paquete SCM y el CID puede tomar el valor del ID de regla correspondiente a la regla de compresión.
[0078] Con el fin de ilustrar las operaciones realizadas en cada componente del sistema 300, un ejemplo de una sesión TCP para transmitir uno o más paquetes TCP desde el origen 301 al destino 307 se ilustra posteriormente con referencia a la figura 3C. El origen 301 indica un iniciador de sesión TCP (un cliente TCP en comunicaciones de enlace ascendente o un servidor TCP en comunicaciones de enlace descendente) configurado para producir uno o más paquetes TCP que deben ser entregados al destino 307, indicando aquí un recibidor de sesión TCP (un servidor t Cp en comunicaciones de enlace ascendente o un cliente TCP en comunicaciones de enlace descendente). Los paquetes TCP descienden por la pila de protocolos 311.
[0079] El origen 301 puede configurarse para iniciar una conexión TCP. De acuerdo con el protocolo SCM, los paquetes TCP enviados desde el origen 301 se procesan en el proxy de origen 303 y se envían a través del enlace inalámbrico en forma de paquetes SCM. Los paquetes TCP enviados desde el origen 301 llegan al proxy de origen 303 a través de la conexión TCP de origen de acuerdo con la pila de protocolos TCP/IP. Esto significa que el origen 301 divide los datos de aplicación producidos por la capa de aplicación de origen 3011 en paquetes TCP en la capa de transporte 3012 y encapsula, a continuación, en la capa de red 3014, cada paquete TCP entregado por la capa de transporte 3012 en un datagrama IP y encapsula, en la capa física 3014, el datagrama IP en una trama y transfiere la trama obtenida a través de la conexión TCP de origen 312 al proxy de origen 303. Al recibir los paquetes TCP enviados a través de la conexión TCP de origen, el proxy de origen 303 actúa como un servidor TCP para recuperar, en la capa de red 3033, los datagramas IP que encapsulan los paquetes TCP enviados por el origen 301, y en la capa de transporte 3032, los paquetes TCP enviados por el origen 301. Con el fin de comunicar los paquetes TCP al destino 307, el proxy de origen 303 convierte los paquetes TCP en la capa de transporte 3032 en un paquete de modo de compresión simple encapsulado en un datagrama IP en la capa de red 3133 y, a continuación, comunica la trama de modo de compresión simple que encapsula el datagrama IP obtenido al proxy de destino 307 a través de la conexión inalámbrica 314. En consecuencia, el proxy de origen 303 convierte cada paquete TCP en la capa de transporte modificada 3032 en un paquete de modo de compresión simple que comprende la sección de datos comprendida en el paquete TCP procesado, la conversión del paquete TCP comprende la eliminación de la cabecera del paquete TCP de manera que el paquete SCM correspondiente comprende la sección de datos y una cabecera que comprende un identificador de conexión utilizado para identificar la conexión SCM 314. El proxy de origen 303 encapsula, a continuación, cada SCM en un datagrama IP en la capa de red modificada 3133 y aplica compresión de cabecera a la cabecera IP del datagrama IP, la compresión de cabecera proporciona un residuo de compresión de cabecera y un identificador de regla relacionado con el identificador de conexión comprendido en la cabecera del paquete SCM. El datagrama IP convertido desciende por la pila de protocolos. En la capa física 3034, el proxy 303 encapsula cada datagrama IP en una trama de modo de compresión simple. Una trama conectada simple determinada a partir de un datagrama IP que encapsula un paquete SCM comprende el paquete SCM, el residuo de compresión de cabecera y el identificador de regla proporcionado por la compresión de cabecera IP realizada para obtener el datagrama IP convertido.
[0080] El proxy de origen 303 puede configurarse entonces para establecer una conexión de modo simple con el proxy de destino 305 a través del cual el proxy de origen 303 envía la trama conectada de modo simple que comprende los paquetes conectados de modo simple.
[0081] El proxy de destino 305 puede configurarse para recibir la trama de modo de compresión simple en la capa de enlace 3054 y para confirmar la recepción de la trama de modo de compresión simple al proxy de origen 303 mediante el envío de un mensaje de confirmación de modo de compresión simple. La trama de modo de compresión simple recibida sube por la pila de protocolos. En la capa de red modificada 3153, el proxy de destino 305 puede configurarse para determinar un datagrama IP reconstruido realizando la descompresión de cabecera IP al datagrama IP contenido en la trama SCM recibida y para determinar un paquete SCM reconstruido mediante la desencapsulación del datagrama IP. La descompresión de cabecera se realiza de acuerdo con el residuo de compresión de cabecera y el identificador de regla comprendidos en la trama SCM. En la capa de transporte modificada 3052, el proxy de destino 305 puede configurarse para determinar paquetes TCP reconstruidos a partir de los paquetes SCM reconstruidos. El proxy de destino 305 puede entonces configurarse para enviar los paquetes TCP reconstruidos al destino 307 a través de la conexión TCP de destino según la pila de protocolos TCP/IP en la que el proxy de destino 305 actúa como cliente TCP y el destino 307 actúa como servidor TCP.
[0082] La conexión de modo de compresión simple establecida entre el proxy de origen 303 y el proxy de destino 305 es transparente para el origen 301 y el destino 307 y tiene por objeto permitir el transporte de paquetes TCP entre el origen 301 y el destino 307 a través del enlace inalámbrico 304.
[0083] La figura 5 es un flujo de conexión que ilustra una conexión ilustrativa de extremo a extremo entre el origen 301 y el destino 305 que tiene por objeto el envío de tres paquetes TCP, denominados D1, D2 y D3, desde el origen 301 al destino 305, según algunas realizaciones de la invención.
[0084] El origen 301 se refiere en lo sucesivo al iniciador de sesión TCP que entrega paquetes TCP y el destino 307 se refiere al receptor de sesión TCP al que están destinados los paquetes TCP producidos por el origen 301. Los paquetes TCP se transmiten desde el origen 301 al destino 305 y se procesan en el proxy de origen 303 y en el proxy de destino 305, donde se convierten en paquetes SCM para su transmisión a través del enlace inalámbrico.
[0085] El origen inicia una conexión TCP en el paso 501 al enviar un paquete SYN TCP al destino 307. El paquete SYN llega al proxy de origen a través de la conexión TCP de origen 312. El proxy de origen 303 recibe el paquete SYN y reconoce que el origen 301 está intentando realizar una conexión TCP con el destino 307 y que el paquete SYN recibido está destinado al destino 307. El proxy de origen 303 confirma el paquete SYN del origen en el paso 502 mediante el envío de un paquete SYN ACK. Este paquete SYN ACK se modifica para que el origen 301 piense que proviene del destino 307. El origen 301 confirma el paquete SYN del proxy de origen en el paso 503 y se establece una conexión TCP de origen.
[0086] El origen 301 envía un paquete TCP D1 a través de la conexión TCP de origen en el paso 504. El paquete TCP D1 enviado desde el origen 301 llega al proxy de origen 303 a través de la conexión TCP de origen. El proxy de origen 303 intercepta el paquete TCP D1 y lo convierte en un paquete de modo de compresión simple indicado mediante 'CID=00,Ns=0,Nr=0,E=0,D1' de acuerdo con el protocolo de modo de compresión simple. El paquete de modo de compresión simple corresponde al primer paquete de datos único que comprende la sección de datos comprendida en el paquete TCP D1 y enviado desde el proxy de origen 303 al proxy de destino 305. Cada vez que el proxy 303 ve un número CID nuevo, indica que debe abrirse una nueva conexión entre 303 y 301.
[0087] Antes de cada comunicación entre el origen 301 y el destino 307 de acuerdo con la presente realización, se establece una sesión de modo de compresión simple entre el proxy de origen 303 y el proxy de destino 305.
[0088] En el paso 505, el proxy de origen 303 envía el paquete de modo de compresión simple 'CID=00,Ns=0,Nr=0,E=0,D1' al proxy de destino 305 a través de la conexión inalámbrica 314 en la que se establece una conexión de modo de compresión simple. El proxy de destino 305 recibe así la información del proxy de origen 303 de que el origen 301 está intentando iniciar una conexión TCP con el destino 307. El proxy de destino 305 establece una conexión TCP de destino con el destino 307 en los pasos 506 y, una vez que la conexión TCP de destino se ha establecido con éxito, el proxy de destino 305 convierte de nuevo el paquete de modo de compresión simple 'CID=00,Ns=0,Nr=0,E=0,D1' a un paquete TCP D1 y envía el paquete TCP reconstruido D1 en el paso 507 al destino 307. El origen 301 se comunica con el destino 307 a través del proxy de origen 303 y el proxy de destino 307. Los paquetes TCP se envían de un lado a otro hasta que el origen 301 o el destino 307 finalizan la conexión. El protocolo SCM funciona mediante el envío de paquetes SCM entre el proxy de origen 303 y el proxy de destino y mediante la recepción de confirmaciones en forma de paquetes de confirmación SCM. Del mismo modo, el origen 301 y el destino 307 envían respectivamente al proxy de origen 303 y al proxy de destino 305 confirmaciones de recepción de paquetes TCP en forma de paquetes de confirmación TCP. Los paquetes de confirmación pueden además transmitir datos superpuestos.
[0089] Los pasos 508 y 509 corresponden respectivamente a la transmisión del paquete TCP D2 y D3 desde el origen 301. El proxy de origen 301 espera a recibir el paquete de confirmación SCM correspondiente al paquete SCM 'CID=00,Ns=0,Nr=0,E=0,D1' enviado en el paso 505 antes de volver a empaquetar y enviar los paquetes TCP D2 y D3. En el paso 510, el destino 507 confirma la recepción del paquete D1 al proxy de destino 305 mediante el envío del paquete TCP d1. Al recibir esta confirmación, el proxy de destino 305 confirma al proxy de origen 303 que el paquete TCP ha sido entregado con éxito al destino 307 mediante el envío de un paquete de confirmación SCM CID=00,Ns=0,Nr=1,E=0,d1' que comprende el paquete TCP d1. Al recibir el paquete de confirmación SCM 'CID=00,Ns=0,Nr=1,E=0,d1', el proxy de origen 303 puede procesar los paquetes TCP D2 y D3 y transmitir los paquetes SCM convertidos al proxy de destino 305. Más concretamente, el proxy de origen 303 puede configurarse para agrupar los paquetes TCP d 2 y D3 y convertirlos en un único paquete SCM 'CID=00,Ns=1,Nr=1,S=1,E=0,LD2 D2, Ld3 D3'. Este paquete SCM corresponde al segundo paquete de datos enviado desde el proxy de origen 303 al proxy de destino 305, contiene dos paquetes TCP. Las secciones de datos correspondientes en la sección de datos de paquete SCM son D2 de longitud Ld2 y D3 de longitud Ld3. El proxy de origen 303 envía el paquete de confirmación TCP ACK D2+D3 al origen 301 en el paso 513 para confirmar la recepción de los paquetes TCP D2 y D3. La reconstrucción y transmisión de los paquetes TCP D2 y D3 al destino 307 no se ilustran en la figura 5, pero se realizan de forma similar a la transmisión del paquete TCP D1 desde el proxy de destino 305 al destino 307.
[0090] En algunas realizaciones, los paquetes TCP pueden llegar al proxy de destino 305 en un orden diferente. En dichas realizaciones, el proxy de destino 305 puede configurarse para reordenar los paquetes TCP reconstruidos de acuerdo con su orden original.
[0091] En el paso 514, el proxy de destino 305 envía un paquete SCM de confirmación vacío 'CID=00,Ns=0,Nr=0,E=0 vacío (sin datos)' al proxy de origen 303 con datos vacíos indicando que no hay datos que enviar.
[0092] En el paso 515, el destino 307 envía un paquete TCP FIN al proxy de destino 305 indicando que el destino 307 desea terminar la conexión TCP. Al recibir el paquete TCP FIN, el proxy de destino 305 confirma la recepción en el paso 517 de este paquete al destino y envía, en el paso 516 un paquete SCM 'CID=00,Ns=0,Nr=0,E=1 vacío (sin datos)' al proxy de origen 303, el paquete SCM comprende una carga útil vacía y un bit de fin. Al recibir el paquete SCM fin, el proxy de origen 303 pide al origen 301 que finalice la conexión TCP enviando un paquete TCP FIN en el paso 518. El origen 301 confirma la recepción del paquete TCP FIN mediante el envío, en el paso 519, de un paquete TCP FIN de confirmación. El CID puede ser reutilizado para indicar la apertura de una nueva conexión.
[0093] El paso 520 indica que el paquete SCM de fin enviado por el proxy de destino 305 en el paso 516 se perdió. A continuación, el destino envía, en el paso 521, un paquete TCP FIN al destino 307 para solicitar de nuevo la finalización de la conexión TCP. El destino confirma la recepción del paquete TCP FIN en el paso 522. El proxy de origen 303 envía un paquete TCP FIN al origen 301 para finalizar la conexión TCP y el origen 301 confirma la recepción del paquete TCP FIN. La pérdida del paquete SCM que indica el fin de la conexión en el paso 520 desencadenaría la retransmisión del paquete SCM 'CID=00,Ns=0,Nr=0,E=1 vacío (sin datos)' por parte del proxy de destino 305 en el paso 525 indicando una solicitud de fin de conexión del destino 307 al origen 301 y una confirmación por parte del proxy de origen 303 en el paso 626 mediante el envío de un paquete SCM de fin 'CID=00, Ns=0,Nr=1,E=1 vacío (sin datos)' que transmite un bit de fin y una carga útil vacía que indica el fin de conexión desde el proxy de origen 303 al proxy de destino 305.
[0094] La figura 6 es un diagrama de estado que ilustra los diferentes estados y transiciones que se producen en el proxy de origen 303 o en el proxy de destino 305 utilizando el protocolo de modo de compresión simple según algunas realizaciones de la invención. La descripción de los estados y transiciones mostrados en la figura 6 se harán con referencia al proxy de origen 303 con fines ilustrativos únicamente. No obstante, los diagramas de estado se aplican de forma intercambiable al proxy de destino 305.
[0095] Tras el establecimiento de la conexión TCP de origen, el proxy de origen 303 inicializa el valor del ID de conexión, Ns (número de secuencia de envío), Nr (número de secuencia de recepción) y alcanza el estado inicial, que es el estado EsperaDatos 61.
En este estado, el proxy de origen 303 puede configurarse:
i) para recibir datos TCP del origen 301; o
ii) para recibir el evento de cierre de conexión desde el origen 301; o .
iii) para recibir datos del proxy de destino 303; o
iv) para recibir la terminación de conexión desde el proxy de destino 303.
[0096] Si se produce el evento i), el proxy de origen 301 puede configurarse para enviar los datos TCP recibidos en una trama SCM al proxy de destino 303, lo que corresponde a la transición 601 al siguiente estado EsperaACK 63.
[0097] Si se produce el evento ii), el proxy de origen 301 puede configurarse para enviar una trama SCM con bit E al proxy de destino 303 para que el proxy de destino 303 pueda iniciar una terminación de la conexión TCP de destino con el destino 307, lo que corresponde a la transición 601 al estado EsperaACK 63.
[0098] Si se produce el evento iii), el proxy de origen 301 puede configurarse para comprobar si el Nr local y el Ns comprendido en los datos recibidos enviados por el proxy de destino 305 coinciden. En tal caso, el proxy de origen 303 puede estar configurado para incrementar el Nr local, y enviar los datos recibidos del proxy de destino 305 al origen 301, lo que corresponde a las transiciones 606 al estado EsperaDatosACK 65.
[0099] Si se produce el evento iv), el estado del proxy de origen 301 puede cambiar al estado FinACK 67 a través de la transición 608.
[0100] El estado EsperaACK 63 se alcanza siempre que el proxy de origen 301 envía una trama SCM (con datos o bit E) al proxy de destino 303 y espera el ACK del proxy de destino 303. Al comienzo de este estado, puede iniciarse un temporizador, denominado temporizador de inactividad. El temporizador puede restablecerse siempre que:
i) se reciban datos del proxy de destino 303.
ii) el temporizador expire cuando se produzca la retransmisión de la última trama enviada, correspondiente a la transición 602.
[0101] La trama SCM enviada por el proxy de destino 303 puede contener:
i) carga útil con datos TCP y Nr esperado que sirve de ACK, o
ii) carga útil vacía con Nr esperado que sirve de ACK, o
iii) bit E de fin de bit.
[0102] En el caso de i), el proxy de origen 303 puede configurarse para enviar los datos al origen 301, para incrementar el Nr local y cambia al estado EsperaDatosACK 65 a través de la transición 603.
[0103] En el caso de ii), el proxy de origen 301 puede configurarse para incrementar el Ns local y cambiar al estado EsperaDatos 61 a través de la transición 605.
[0104] En el caso iii), el proxy de origen 301 puede configurarse para pasar al estado Fin 69 a través de la transición 611.
[0105] El estado EsperaDatosACK 65 inicia un temporizador corto (en comparación con el temporizador de inactividad) y espera cualquier dato TCP del origen 301 antes de enviar ACK para los datos recibidos del proxy de destino 305. Tras la expiración del temporizador, el proxy de origen 303 envía ACK y puede producirse la transición 607 a EsperaDatos 61.
Mientras espera los datos TCP del origen 301, el proxy de origen 303 puede
i) recibir datos TCP del origen 301, o
ii) recibir un evento de cierre de conexión del origen.
[0106] Si se produce el evento i), el proxy de origen 303 puede configurarse para enviar los datos TCP recibidos del origen 301 en una trama SCM al proxy de destino 305 y se realiza la transición 604 al siguiente estado EsperaACK 63.
[0107] Si se produce el evento ii), el proxy de origen 303 puede configurarse para enviar una trama SCM con bit E al proxy de destino 303 para que el proxy de destino 303 inicie la terminación de conexión TCP de destino con el destino 307 y la transición 604 a EsperaACK 63.
[0108] En el estado FinACK 67, el proxy de origen 303 puede configurarse para esperar la confirmación SCM (ACK) del proxy de destino 305 para la trama SCM de bit E que había enviado. Si el proxy de origen 303 no recibe la trama SCM ACK durante un determinado periodo de inactividad, vuelve a transmitir la trama SCM de bit E y permanece en el mismo estado, correspondiente a la transición 609. Si el proxy de origen 303 recibe el ACK, se produce la transición 610 al estado FIN 69.
[0109] En el estado Fin 69, todos los recursos ocupados por el proxy de origen 303 pueden ser liberados y devueltos sin errores.
[0110] Con referencia a la figura 7, también se proporciona un método para transmitir, mediante un proxy de origen 303, uno o más paquetes TCP enviados desde un dispositivo de origen 301 a un dispositivo de destino 307 a través de un enlace inalámbrico 304. Cada paquete TCP comprende una sección de datos TCP y una cabecera de paquete TCP.
[0111] En el paso 701, uno o más paquetes TCP enviados por el origen 301 pueden ser recibidos por un proxy de origen 303 ubicado en el enlace inalámbrico 304.
[0112] En el paso 703, el proxy de origen 303 puede determinar un paquete de modo de compresión simple a partir del uno o más paquetes TCP recibidos. Un paquete de modo de compresión simple puede determinarse mediante la eliminación de la cabecera de paquete TCP comprendida en cada paquete TCP. El paquete de modo de compresión simple obtenido comprende las secciones de datos TCP comprendidas en el uno o más paquetes TCP recibidos y una cabecera que comprende un identificador de conexión.
[0113] En el paso 705, el paquete de modo de compresión simple determinado en el paso 703 puede ser enviado, por el proxy de origen 303 a un proxy de destino 305 ubicado en el enlace inalámbrico 304.
[0114] En el paso 707, el paquete de modo de compresión simple enviado por el proxy de origen 303 puede ser recibido por el proxy de destino 305. La confirmación de recepción del paquete de modo de compresión simple puede ser enviada en el paso 707 por el proxy de destino 305 al proxy de origen 303.
[0115] En el paso 709, uno o más paquetes TCP reconstruidos pueden ser determinados por el proxy de destino 305 extrayendo las secciones de datos de cada paquete TCP del paquete de modo de compresión simple recibido.
[0116] En el paso 711, el uno o más paquetes TCP reconstruidos pueden ser enviados, por el proxy de destino 305 al dispositivo de destino 307.
[0117] También se proporciona un programa almacenado en un medio no transitorio legible por ordenador para transmitir, mediante un proxy de origen 303, uno o más paquetes TCP enviados desde un dispositivo de origen 301 a un dispositivo de destino 307 a través de un enlace inalámbrico 304, comprendiendo cada paquete TCP una sección de datos TCP y una cabecera de paquete TCP. El programa comprende instrucciones almacenadas en el medio de almacenamiento legible por ordenador que, cuando son ejecutadas por un procesador, hacen que el procesador:
- reciba el uno o más paquetes TCP mediante un proxy de origen 303 ubicado en dicho enlace inalámbrico 304;
- determine, mediante el proxy de origen 303, un paquete de modo de compresión simple a partir del uno o más paquetes TCP mediante la eliminación de la cabecera de paquete TCP comprendida en cada paquete TCP, comprendiendo el paquete de modo de compresión simple las secciones de datos TCP comprendidas en el uno o más paquetes TCP y una cabecera que comprende un identificador de conexión;
- envíe, mediante el proxy de origen 303, el paquete de modo de compresión simple a un proxy de destino 305 ubicado en el enlace inalámbrico 304;
- reciba, mediante dicho proxy de destino 305, el paquete de modo de compresión simple y confirme la recepción del paquete de modo de compresión simple al proxy de origen 303;
- determine, mediante el proxy de destino 305, uno o más paquetes TCP reconstruidos mediante la extracción de las secciones de datos de cada paquete TCP a partir del paquete de modo de compresión simple; y
- envíe, mediante el proxy de destino 305, el uno o más paquetes TCP reconstruidos al dispositivo de destino 307.
[0118] Los métodos y dispositivos descritos en la presente memoria pueden implementarse mediante diversos medios. Por ejemplo, estas técnicas pueden implementarse en hardware, software o una combinación de los mismos. Para una implementación de hardware, los elementos de procesamiento de los diferentes dispositivos que operan en el sistema 300 pueden implementarse, por ejemplo, de acuerdo con una configuración de sólo hardware (por ejemplo, en uno o más FPGA, ASIC o circuitos integrados VLSI con la memoria correspondiente) o de acuerdo con una configuración que utiliza tanto VLSI como procesador de señales digitales (DSP).
[0119] La figura 8 es un diagrama de bloques que representa una arquitectura ilustrativa de hardware/software de un dispositivo 80 que opera en el sistema 300, como el origen 301, el destino 307, el proxy de origen 303, o el proxy de destino 305 según algunas realizaciones de la invención. Tal y como se ilustra, la arquitectura puede incluir varias unidades de computación, procesamiento, almacenamiento, comunicación, detección y visualización, que comprenden:
- circuitos de comunicación que comprenden un transceptor 802 y un elemento de transmisión/recepción 801 (por ejemplo, una o más antenas) configurados para conectar el dispositivo a enlaces correspondientes del sistema 300, y para garantizar la transmisión/recepción de señales por cable o inalámbricas. Los circuitos de comunicación pueden admitir diversas redes e interfaces aéreas, tales como redes por cable e inalámbricas (por ejemplo, redes de área local inalámbricas y redes celulares); - una unidad de procesamiento 802 configurada para ejecutar las instrucciones ejecutables por ordenador para ejecutar los métodos y algoritmos de acuerdo con las diversas realizaciones de la invención para realizar las diversas funciones requeridas del dispositivo, tales como operaciones de compresión/descompresión de cabecera, construcción de paquetes/tramas SCM, procesamiento de datos (por ejemplo, procesamiento de entrada/salida) y cualquier funcionalidad requerida para permitir que el dispositivo opere en el sistema 300 de acuerdo con las realizaciones de la invención. La unidad de procesamiento 802 puede ser un procesador de propósito general, un procesador de propósito específico, un DSP, una pluralidad de microprocesadores, un controlador, un microcontrolador, un ASIC, un circuito FPGA, cualquier tipo de circuito integrado, y similares;
- una fuente de energía 803 que puede ser cualquier dispositivo adecuado que proporcione energía al dispositivo 80, como baterías de pilas secas, células solares y células de combustible;
- una unidad de localización 804, como un conjunto de chips GPS implementado en aplicaciones que requieren información que indica la ubicación del dispositivo 80;
- un almacenamiento 811 que posiblemente comprende una memoria de acceso aleatorio (RAM) o una memoria de sólo lectura utilizada para almacenar datos procesados (por ejemplo, paquetes TCP, contextos, residuos de compresión) y cualquier dato necesario para realizar las funcionalidades del dispositivo 80 según las realizaciones de la invención;
- Periféricos de entrada 808;
- Periféricos de salida 809 que comprenden medios de comunicación como pantallas que permiten, por ejemplo, la interacción hombre-máquina entre el dispositivo 80 y el administrador del sistema 300, por ejemplo, con fines de configuración y/o mantenimiento.
[0120] La arquitectura del dispositivo 80 puede comprender además una o más unidades de software y/o hardware configuradas para proporcionar características adicionales, funcionalidades y/o conectividad de red. Dichas unidades comprenden, por ejemplo, sensores, cámaras digitales, dispositivos de vibración, un módulo Bluetooth, un reproductor multimedia, un navegador de Internet, etc.
[0121] Además, el método descrito en el presente documento puede implementarse mediante instrucciones de programa informático suministradas al procesador de cualquier tipo de ordenador para producir una máquina con un procesador que ejecuta las instrucciones para implementar las funciones/actos especificados en el presente documento. Estas instrucciones de programa informático también pueden almacenarse en un medio legible por ordenador que puede dirigir un ordenador para que funcione de una manera particular. A tal fin, las instrucciones de programa informático pueden cargarse en un ordenador para provocar la realización de una serie de pasos operativos y producir así un proceso implementado por ordenador de manera que las instrucciones ejecutadas proporcionan procesos para implementar las funciones especificadas en el presente documento.
[0122] Se entenderá que las configuraciones y/o enfoques descritos en el presente documento son de naturaleza ilustrativa, y que estas realizaciones o ejemplos específicos no deben considerarse en un sentido limitativo, ya que son posibles numerosas variaciones. Las rutinas o métodos específicos descritos en la presente memoria pueden representar una o más de cualquier número de estrategias de procesamiento. Como tal, varios actos ilustrados y/o descritos pueden ser realizados en la secuencia ilustrada y/o descrita, en otras secuencias, en paralelo, u omitidos. Asimismo, puede cambiarse el orden de los procesos descritos anteriormente.
[0123] El objeto de la presente exposición está limitado por las reivindicaciones adjuntas.

Claims (14)

REIVINDICACIONES
1. Sistema que comprende un proxy de origen y un proxy de destino, dicho proxy de origen (303) para transmitir uno o más paquetes TCP enviados desde un dispositivo de origen (301) a un dispositivo de destino (307) a través de un enlace inalámbrico (304), comprendiendo cada paquete TCP una sección de datos TCP y una cabecera de paquete TCP, donde el proxy de origen (303) se ubica en dicho enlace inalámbrico (304) y está configurado para:
- recibir dicho uno o más paquetes TCP;
- determinar un paquete de modo de compresión simple a partir de dicho uno o más paquetes TCP mediante la eliminación de la cabecera de paquete TCP comprendida en cada paquete TCP, comprendiendo dicho paquete de modo de compresión simple las secciones de datos TCP comprendidas en dicho uno o más paquetes TCP y una cabecera que comprende un identificador de conexión; y
- enviar dicho paquete de modo de compresión simple a un proxy de destino (305) ubicado en dicho enlace inalámbrico (304), estando el proxy de destino (305) configurado para:
- recibir dicho paquete de modo de compresión simple y confirmar la recepción al proxy de origen (303); - determinar uno o más paquetes TCP reconstruidos mediante la extracción de las secciones de datos de cada paquete TCP a partir de dicho paquete de modo de compresión simple; y
- enviar dicho uno o más paquetes TCP reconstruidos al dispositivo de destino (307) donde dicho identificador de conexión identifica una conexión entre dicho proxy de origen (303) y dicho proxy de destino (305), comprendiendo la cabecera de dicho paquete de modo de compresión simple, además:
- un primer campo siguiente que representa un número del paquete de modo de compresión simple enviado por el proxy de origen (303) e incrementándose en uno cada vez que el proxy de origen envía un paquete de modo de compresión simple (303);
- un segundo campo siguiente que representa un número del paquete de modo de compresión simple recibido por el proxy de origen (303) desde el proxy de destino (305) e incrementándose en uno cada vez que un paquete de modo de compresión simple es enviado desde el proxy de destino (305) al proxy de origen (303);
- un tercer campo siguiente que indica si un fin de conexión es entregado por el origen (301) o el destino (307).
2. Sistema de acuerdo con la reivindicación 1, donde dicho identificador de conexión identifica una conexión entre dicho proxy de origen (303) y dicho proxy de destino (305), una cabecera de paquete TCP que comprende un campo de opciones, comprendiendo la cabecera de dicho paquete de modo de compresión simple, además:
- un cuarto campo siguiente que indica si dicho paquete de modo de compresión simple comprende uno o múltiples paquetes TCP; y
- un quinto campo siguiente que indica si dicho campo de opciones debe estar comprendido en el paquete de modo de compresión simple.
3. Sistema de acuerdo con la reivindicación 2, donde el proxy de origen (303) está configurado para enviar, al proxy de destino (305), un paquete de modo de compresión simple que comprende datos TCP vacíos y un tercer campo siguiente igual a un valor de bit de fin predefinido si el dispositivo de origen (301) entrega un fin de conexión, estando el proxy de destino (305) configurado para enviar, al proxy de origen (303), un paquete de modo de compresión simple que comprende datos TCP vacíos y un tercer campo siguiente igual a un valor de bit de fin predefinido si el dispositivo de destino (307) entrega un fin de conexión.
4. Sistema de acuerdo con cualquier reivindicación anterior, donde el dispositivo de origen (301) está configurado para intercambiar paquetes TCP con el proxy de origen (303) a través de una conexión TCP de origen según la pila de protocolos TCP/IP y el dispositivo de destino (307) está configurado para intercambiar paquetes TCP con el proxy de destino (305) a través de una conexión TCP de destino según la pila de protocolos TCP/IP.
5. Sistema de acuerdo con cualquier reivindicación anterior, donde el proxy de origen (303) está configurado además para encapsular cada paquete de modo de compresión simple en un datagrama IP y para encapsular dicho datagrama IP en una trama de modo de compresión simple, estando el proxy de origen (303) y el proxy de destino (305) configurados para intercambiar tramas de modo de compresión simple a través de dicho enlace inalámbrico (304) y para confirmar la recepción de cada trama de modo de compresión simple.
6. Sistema de acuerdo con la reivindicación 5, donde el proxy de origen (303) y el proxy de destino (305) están configurados para fragmentar una trama de modo de compresión simple en dos o más fragmentos en función de un tamaño de trama predefinido en relación con las especificaciones del enlace inalámbrico (304).
7. Sistema de acuerdo con cualquiera de las reivindicaciones anteriores 4 a 6, donde el proxy de origen (303) está configurado para realizar la compresión de cabecera a dicho datagrama IP, la compresión de cabecera aplicada a dicho datagrama IP proporcionando residuo de cabecera IP y estando asociada a un identificador de regla, una trama de modo de compresión simple encapsulando dicho datagrama IP comprendiendo además dicho residuo de compresión de cabecera IP y el identificador de regla, estando el proxy de destino (305) configurado para realizar la descompresión de cabecera al datagrama IP encapsulado en cada trama de modo de compresión simple recibida enviada por el proxy de origen (303) de acuerdo con dicho identificador de regla y residuo de compresión de cabecera IP.
8. Sistema de acuerdo con cualquiera de las reivindicaciones anteriores 4 a 7, donde el dispositivo de origen (301) y el dispositivo de destino (307) están configurados, además, para utilizar un protocolo de aplicación limitado que produce mensajes de protocolo de aplicación limitado comprendidos en cada paquete TCP, estando el proxy de origen (303) configurado, además, para realizar la compresión de cabecera a la cabecera de cada mensaje de protocolo limitado, proporcionando la compresión de cabecera residuo de compresión de cabecera y estando asociado a un identificador de regla, la trama de modo de compresión simple determinada a partir de uno o más paquetes TCP que comprenden datos de protocolo de aplicación limitado que comprenden, además, dicho identificador de regla y residuo de compresión de cabecera, estando el proxy de destino (305) configurado, además, para realizar la descompresión de cabecera a la cabecera de cada mensaje de protocolo limitado comprendido en cada paquete TCP reconstruido de acuerdo con dicho residuo de compresión de cabecera e identificador de regla.
9. Sistema de acuerdo con cualquiera de las reivindicaciones anteriores 7 y/u 8, donde la compresión de cabecera y la descompresión de cabecera se realizan mediante la utilización de un protocolo de compresión de cabecera de contexto estático.
10. Sistema de acuerdo con cualquiera de las reivindicaciones anteriores 7 a 9, donde cada identificador de regla está relacionado con un identificador de conexión, estando el proxy de origen (303) y el proxy de destino (305) configurados, además, para almacenar una tabla de asignación en la que cada identificador de regla es asignado a un identificador de conexión.
11. Sistema de acuerdo con cualquier reivindicación anterior, donde un enlace inalámbrico (304) es una red de área amplia de baja potencia o una red inalámbrica de corto alcance de baja potencia, estando el proxy de origen (303) y el proxy de destino (305) ubicados en nodos de pasarela en dicha red de área amplia de baja potencia o en dicha red inalámbrica de corto alcance de baja potencia.
12. Sistema de acuerdo con la reivindicación 11, donde dicha red de área amplia de baja potencia utiliza una tecnología elegida en un grupo que comprende el LoRaWan, el Sigfox, el NB-IoT, el IEEE.802.15.4 y el Weightless.
13. Método para transmitir, mediante un proxy de origen (303), uno o más paquetes TCP enviados desde un dispositivo de origen (301) a un dispositivo de destino (307) a través de un enlace inalámbrico (304), comprendiendo cada paquete TCP una sección de datos TCP y una cabecera de paquete TCP, donde el método comprende:
- recibir dicho uno o más paquetes TCP mediante un proxy de origen (303) ubicado en dicho enlace inalámbrico (304);
- determinar, mediante dicho proxy de origen (303), un paquete de modo de compresión simple a partir de dicho uno o más paquetes t Cp mediante la eliminación de la cabecera de paquete TCP comprendida en cada paquete TCP, comprendiendo dicho paquete de modo de compresión simple las secciones de datos TCP comprendidas en dicho uno o más paquetes TCP y una cabecera que comprende un identificador de conexión;
- enviar, mediante dicho proxy de origen (303), el paquete de modo de compresión simple a un proxy de destino (305) ubicado en dicho enlace inalámbrico (304);
- recibir, mediante dicho proxy de destino (305), dicho paquete de modo de compresión simple y confirmar la recepción de dicho paquete de modo de compresión simple al proxy de origen (303);
- determinar, mediante el proxy de destino (305), uno o más paquetes TCP reconstruidos mediante la extracción de las secciones de datos de cada paquete TCP a partir de dicho paquete de modo de compresión simple; y
- enviar, mediante el proxy de destino (305), dicho uno o más paquetes TCP reconstruidos al dispositivo de destino (307); donde dicho identificador de conexión identifica una conexión entre dicho proxy de origen (303) y dicho proxy de destino (305), comprendiendo la cabecera de dicho paquete de modo de compresión simple, además:
- un primer campo siguiente que representa un número del paquete de modo de compresión simple enviado por el proxy de origen (303) e incrementándose en uno cada vez que el proxy de origen envía un paquete de modo de compresión simple (303);
- un segundo campo siguiente que representa un número del paquete de modo de compresión simple recibido por el proxy de origen (303) desde el proxy de destino (305) e incrementándose en uno cada vez que un paquete de modo de compresión simple es enviado desde el proxy de destino (305) al proxy de origen (303);
- un tercer campo siguiente que indica si un fin de conexión es entregado por el origen (301) o el destino (307).
14. Programa almacenado en un medio no transitorio legible por ordenador para transmitir, mediante un proxy de origen (303), uno o más paquetes TCP enviados desde un dispositivo de origen (301) a un dispositivo de destino (307) a través de un enlace inalámbrico (304), comprendiendo cada paquete TCP una sección de datos TCP y una cabecera de paquete TCP, comprendiendo el programa instrucciones almacenadas en el medio de almacenamiento legible por ordenador que, cuando son ejecutadas por un procesador, hacen que el procesador:
- reciba dicho uno o más paquetes TCP mediante un proxy de origen (303) ubicado en dicho enlace inalámbrico (304);
- determine, mediante el proxy de origen (303), un paquete de modo de compresión simple a partir de dicho uno o más paquetes TCP mediante la eliminación de la cabecera de paquete TCP comprendida en cada paquete TCP, comprendiendo dicho paquete de modo de compresión simple las secciones de datos TCP comprendidas en dicho uno o más paquetes TCP y una cabecera que comprende un identificador de conexión;
- envíe, mediante dicho proxy de origen (303), el paquete de modo de compresión simple a un proxy de destino (305) ubicado en dicho enlace inalámbrico (304);
- reciba, mediante dicho proxy de destino (305), dicho paquete de modo de compresión simple y confirme la recepción de dicho paquete de modo de compresión simple al proxy de origen (303);
- determine, mediante el proxy de destino (305), uno o más paquetes TCP reconstruidos mediante la extracción de las secciones de datos de cada paquete TCP a partir de dicho paquete de modo de compresión simple; y
- envíe, mediante el proxy de destino (305), dicho uno o más paquetes TCP reconstruidos al dispositivo de destino (307)
paquetes al dispositivo de destino (307);
donde dicho identificador de conexión identifica una conexión entre dicho proxy de origen (303) y dicho proxy de destino (305), comprendiendo la cabecera de dicho paquete de modo de compresión simple, además:
- un primer campo siguiente que representa un número del paquete de modo de compresión simple enviado por el proxy de origen (303) e incrementándose en uno cada vez que el proxy de origen envía un paquete de modo de compresión simple (303);
- un segundo campo siguiente que representa un número del paquete de modo de compresión simple recibido por el proxy de origen (303) desde el proxy de destino (305) e incrementándose en uno cada vez que un paquete de modo de compresión simple es enviado desde el proxy de destino (305) al proxy de origen (303);
- un tercer campo siguiente que indica si un fin de conexión es entregado por el origen (301) o el destino (307).
ES18306387T 2018-10-24 2018-10-24 Protocolo de comunicación simple para la transmisión de datos a través de redes limitadas Active ES2881255T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP18306387.4A EP3644573B1 (en) 2018-10-24 2018-10-24 Simple communication protocol for data transmission over constrained networks

Publications (1)

Publication Number Publication Date
ES2881255T3 true ES2881255T3 (es) 2021-11-29

Family

ID=64270767

Family Applications (1)

Application Number Title Priority Date Filing Date
ES18306387T Active ES2881255T3 (es) 2018-10-24 2018-10-24 Protocolo de comunicación simple para la transmisión de datos a través de redes limitadas

Country Status (4)

Country Link
US (1) US11102679B2 (es)
EP (1) EP3644573B1 (es)
CN (1) CN111092854B (es)
ES (1) ES2881255T3 (es)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2921983T3 (es) * 2018-03-16 2022-09-05 Acklio Método y aparato para procesar datos de mensaje
US11425228B2 (en) * 2020-03-18 2022-08-23 Cisco Technology, Inc. Protocol independent signal slotting and scheduling
US11831717B2 (en) * 2020-10-21 2023-11-28 Charter Communications Operating, Llc IP support in non-cellular low-power wide area networks
CN113645256B (zh) * 2021-10-13 2021-12-28 成都数默科技有限公司 一种不降低tcp会话数据价值密度的聚合方法

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6791982B2 (en) * 1999-09-29 2004-09-14 Telefonaktiebolaget Lm Ericsson Segmentation protocol that supports compressed segmentation headers
US20020010765A1 (en) * 2000-07-21 2002-01-24 John Border Method and system for prioritizing traffic in a network
US7031342B2 (en) * 2001-05-15 2006-04-18 Webex Communications, Inc. Aligning data packets/frames for transmission over a network channel
JP4317403B2 (ja) * 2002-08-09 2009-08-19 パナソニック株式会社 ヘッダ圧縮装置及びヘッダ圧縮方法
KR100745782B1 (ko) * 2006-09-29 2007-08-03 한국전자통신연구원 동적 헤더 압축 장치 및 방법
US8416788B2 (en) * 2007-04-26 2013-04-09 Microsoft Corporation Compression of data packets while maintaining endpoint-to-endpoint authentication
EP2548352B1 (en) * 2010-03-19 2019-03-06 Mobile Devices Ingenierie Data communication system and method
US8396954B2 (en) * 2010-06-24 2013-03-12 Aryaka Networks, Inc. Routing and service performance management in an application acceleration environment
WO2013088323A2 (en) * 2011-12-16 2013-06-20 Koninklijke Philips Electronics N.V. Operation of wireless resource-constrained devices in ip networks
KR101432719B1 (ko) * 2012-05-16 2014-08-25 주식회사 아라기술 핸드오버를 지원하는 컨텐츠 전송 방법, 시스템 및 컴퓨터 판독 가능한 기록 매체
US9455950B1 (en) * 2013-03-15 2016-09-27 Blue Coat Systems, Inc. System and method for implementing traffic optimization for overlay networks
US11032739B2 (en) * 2017-03-10 2021-06-08 Convida Wireless, Llc Dynamic header compression for constrained networks
CN111149384B (zh) * 2017-09-29 2022-05-27 苹果公司 针对mptcp的rohc标头压缩
US10652220B1 (en) * 2018-05-09 2020-05-12 Architecture Technology Corporation Systems and methods for secure data transport

Also Published As

Publication number Publication date
US20200137628A1 (en) 2020-04-30
US11102679B2 (en) 2021-08-24
EP3644573A1 (en) 2020-04-29
CN111092854B (zh) 2024-01-19
EP3644573B1 (en) 2021-04-21
CN111092854A (zh) 2020-05-01

Similar Documents

Publication Publication Date Title
ES2881255T3 (es) Protocolo de comunicación simple para la transmisión de datos a través de redes limitadas
Gomez et al. TCP in the Internet of Things: from ostracism to prominence
US20090161581A1 (en) ADDRESS AUTOCONFIGURATION METHOD AND SYSTEM FOR IPv6-BASED LOW-POWER WIRELESS PERSONAL AREA NETWORK
CN107006045A (zh) 网络地址中依赖于传输设备的上下文
Wang et al. Transmitting IPv6 packets over Bluetooth low energy based on BlueZ
CN110944323B (zh) 用于管理切换漫游的方法
US20120099579A1 (en) Zigbee gateway and ip service server interworking with zigbee gateway through ip network
TW202038584A (zh) 封包發送方法、封包接收方法以及相關設備
CN101827031A (zh) 一种用户数据包协议udp隧道中传输报文的方法及装置
Harvan Connecting wireless sensor networks to the internet-a 6lowpan implementation for tinyos 2.0
Garg et al. A study on need of adaptation layer in 6LoWPAN protocol stack
CN103379182A (zh) 数据传输方法和客户端
Schrickte et al. Integration of wireless sensor networks to the internet of things using a 6LoWPAN gateway
JP5569452B2 (ja) 無線通信装置、方法及びプログラム
Suryady et al. Performance evaluation of 6LoWPAN-based precision agriculture
CN104168273A (zh) 一种瘦ap模式下实现tcp代理的方法及系统
Nuhu Kontagora et al. Experimental performance evaluation and feasibility study of 6lowpan based internet of things
Awwad et al. Second and subsequent fragments headers compression scheme for IPv6 header in 6LoWPAN network
Suryady et al. A gateway solution for IPv6 wireless sensor networks
CN113056008A (zh) 数据传输方法及装置
Krishnendu et al. Development of 6lowpan Mote for IOT
WO2023273486A1 (zh) 一种数据传输的方法和装置
Fuchs IP-based communication in wireless sensor network
Schmidt 6LoWPAN: An Open IoT Networking Protocol
US20230155734A1 (en) First node, second node, third node, and methods performed thereby for handling retransmissions of messages