ES2921983T3

ES2921983T3 - Método y aparato para procesar datos de mensaje

Info

Publication number: ES2921983T3
Application number: ES18305301T
Authority: ES
Inventors: Ana Minaburo; Alexander Pelov
Original assignee: Acklio SAS
Current assignee: Acklio SAS
Priority date: 2018-03-16
Filing date: 2018-03-16
Publication date: 2022-09-05
Anticipated expiration: 2038-03-16
Also published as: US20210051218A1; US11622030B2; US20220201102A1; CN112385193A; CN112385193B; US11303738B2; EP3541040A1; EP3541040B1; EP4030738A1; WO2019175275A1

Abstract

Los mensajes de datos, como los paquetes de datos en formato IPv4 o lPv6, se procesan con vistas a la compresión/descompresión, utilizando información obtenida de fuentes distintas del propio paquete de datos o del flujo al que pertenece. Esto puede implicar un procesamiento dinámico adicional definido en las especificaciones identificadas por un marcador compartido u obtenido de una fuente de datos adicional, como un archivo estático, una aplicación de base de datos o similar. Las realizaciones descritas en este documento mejoran este enfoque con una determinación dinámica de los componentes de datos. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Método y aparato para procesar datos de mensaje

Campo de la invención

[0001] La presente invención se refiere, en general, al procesamiento de mensajes de datos y, en concreto, a la compresión de dichos datos.

Antecedentes de la invención

[0002] La figura 1 muestra esquemáticamente aspectos de un mecanismo de compresión de encabezado de red conocido en el estado de la técnica.

[0003] Específicamente, la figura 1 muestra elementos de un mecanismo de compresión de encabezado para redes IPv6, sustancialmente como se propone en LPWAN Static Context Header Compression (SCHC) for IPv6 and UDP draft-ietflpwan-ipv6-static-context-hc-10.

[0004] Como se muestra, los datos deben ser transmitidos desde un dispositivo transmisor A a un dispositivo receptor B a través de una red LPWAN 150 basada en IPv6. Debido a limitaciones tales como la potencia o la disponibilidad de ancho de banda en el dispositivo transmisor, puede ser deseable reducir la cantidad total de datos que se han de transmitir. De acuerdo con el mecanismo de la figura 1 , un paquete de datos que comprende un número de campos definidos para la transmisión se expone a un conjunto de reglas 110, 120, 130, 140, que en conjunto constituyen un contexto 100a. Cada regla comprende una pluralidad de líneas de instrucción de campo. Por ejemplo, la regla 140 comprende las líneas de instrucción de campo 141, 142, 143, 144, 145, etc. Las líneas de descripción de campo tienen una estructura común que comprende cuatro entradas. Específicamente, cada línea de descripción de campo comprende un ID de campo que especifica uno de los campos definidos del paquete de datos, un valor de destino, un operador de coincidencia y una acción de compresión/descompresión. Por lo tanto, como se muestra, los campos de la regla 141 pueden verse estructurados en cuatro columnas 140a, 140b, 140c, 140d. Por consiguiente, la línea de descripción de campo 141 presenta un ID de campo 141a, un valor de destino 141b, un operador de coincidencia 141c y una acción de compresión/descompresión 141d. De manera similar, la línea de descripción de campo 142 presenta un ID de campo 142a, un valor de destino 142b, un operador de coincidencia 142c y una acción de compresión/descompresión 142d.

[0005] En funcionamiento, un paquete de datos procesado en el lado del transmisor se compara sucesivamente con cada regla, y con cada regla sucesivamente con cada línea de descripción de campo de esa regla utilizando un operador de coincidencia.

[0006] Para cada línea de descripción de campo se determina si la entrada de valor de destino del campo al que se hace referencia en la entrada de ID de campo se corresponde de una manera prescrita según lo definido en la entrada de operador de coincidencia de esa línea de descripción de campo. En caso de que el campo referenciado corresponda al valor de destino de la manera prescrita para todos los campos de una regla respectiva, se aplica la acción de compresión/descompresión de cada campo en la regla correspondiente.

[0007] Los operadores de coincidencia posibles incluyen los operadores “ignorar” o “iguales” MSB(longitud) y correspondencia de mapas a partir de una lista.

[0008] A modo de ejemplo, la regla 140 podría comprender los tres campos que se muestran a continuación.

[0009] Sobre esta base, el primer campo del paquete de datos se expondría primero a la línea de instrucción de campo 141, ya que el método de comparación prescrito en la entrada del operador de coincidencia para este campo es "ignorar", esta comparación se satisface automáticamente. A continuación, el método procede a la línea de instrucción de campo 142, para la cual la forma de comparación prescrita en la entrada del operador de coincidencia es "igual". En consecuencia, el campo F2 del paquete de datos debe comprender el valor de destino "0x1230", tal como se define en el campo de valor de destino. A continuación, el método procede a la línea de instrucción de campo 143, para la cual la forma de comparación prescrita en la entrada del operador de coincidencia es “igual”. En consecuencia, el campo F3 del paquete de datos debe comprender el valor de destino "0xABC0", tal como se define en el campo de valor de destino.

[0010] Suponiendo que los tres campos de la regla 140 se satisfacen sobre esta base, se selecciona la regla 140 para su aplicación. Sobre esta base, la instrucción de compresión de cada campo de la regla 140 se aplica al paquete de datos.

[0011] Como se ha mostrado anteriormente, la función de compresión de las tres líneas de instrucción de campo de la regla 141 es "no enviado", lo que indica que cada uno de los tres campos en cuestión F1, F2 y F3 se elimina del paquete que se ha de transmitir.

[0012] Como se muestra en la figura 1, el paquete comprimido se transmite entonces a través de la red 150 al lado receptor b, junto con un identificador de la regla 140 que se ha aplicado, ID4.

[0013] Como se muestra, un conjunto de reglas 160, 170, 180, 190, correspondientes a las reglas 110, 120, 130 140, como se ha descrito anteriormente, respectivamente, constituyen un contexto 100b. El contexto 100b se corresponde en estructura y contenido con el contexto 100a, de manera que cada regla comprende una pluralidad de líneas de instrucción de campo. Por ejemplo, la regla 190 comprende las líneas de instrucción de campo 191, 192, 193, 194, 195, etc. Las líneas de instrucción de campo tienen una estructura común que comprende cuatro entradas. En concreto, cada línea de instrucción de campo comprende una referencia de campo que especifica uno de los campos definidos del paquete de datos, un valor de destino, un operador de coincidencia y una acción de compresión/descompresión. Por lo tanto, como se muestra, las líneas de instrucción de campo de la regla 191 pueden verse estructuradas en cuatro columnas 190a, 190b, 190c, 190d. En consecuencia, la línea de instrucción de campo 191 tiene una referencia de campo 191a, un valor de destino 191b, un parámetro de coincidencia 191c y una función de compresión 191d. De manera similar, la línea de instrucción de campo 192 presenta una referencia de campo 192a, un valor de destino 192b, un parámetro de coincidencia 192c y una función de compresión 192d.

[0014] En funcionamiento, el paquete de datos recibido se procesa de acuerdo con la regla especificada por la transmisión recibida, es decir, la regla ID4, correspondiente a la regla 190. La línea de instrucción de campo en la regla especificada se aplica al campo respectivo de la manera prescrita.

[0015] Con referencia a una regla 190 que es idéntica a la regla 140 presentada anteriormente, como se indica por medio del ID único de la regla, ID4, la regla 190 podría comprender los tres campos que se muestran a continuación.

[0016] Sobre esta base, el primer campo F1 del paquete de datos se llenaría con el valor 0x00, el segundo campo F2 del paquete de datos se llenaría con el valor 0x1230 y el tercer campo F3 del paquete de datos se llenaría con el valor 0xABC0.

[0017] Se puede observar, sobre esta base, que el paquete resultante 13 es idéntico al paquete original 11, aparte del valor del campo F1, donde el valor original 0xA1 ha sido sustituido por el valor 0x00, por la operación del operador de coincidencia "ignorar" en el campo 141c. Se observará que, en ciertos casos, puede determinarse que el valor de un campo concreto puede establecerse de forma segura como un valor predeterminado de este modo sin interferir con el funcionamiento general del sistema. Las funciones de compresión/descompresión definidas en el estándar mencionado anteriormente incluyen las siguientes.

[0018] Se describen características adicionales en el borrador posterior LPWAN Static Context Header Compression (SCHC) for IPv6 and UDP draft-ietf-lpwan-ipv6-static-context-hc-10.

[0019] DAE IN CHOI ET AL: "Improve IPv6 global connectivity for 6LoWPAN" Advanced Communication Technology (ICACT) 2011 13TH International Conference on, IEEE, 13 de febrero de 2011, pp. 1007-1010. Propone uso de una dirección de forma corta en lugar de una dirección IP completa en un mecanismo de compresión de encabezado.

[0020] WO2016/206742 se refiere a un método para gestionar el tráfico de datos en una red informática, donde el tráfico de datos se transmite en la red informática a través de flujos de paquetes, y donde el uno o más paquetes son procesados por una o más funciones de red, donde a) se determina la información de procesamiento para procesar dicho uno o más paquetes de dicho flujo identificado, b) se elimina la información de encabezado de dicho uno o más paquetes c) se añade información de etiqueta a dicho uno o más paquetes, d) un mapeo entre dicha información de etiqueta y dicha información de encabezado se almacena en una memoria caché y e) dichos paquetes son procesados por dicha una o más funciones de red de acuerdo con dicha información de procesamiento identificada, donde dicha una o más funciones de red consultan dicha memoria caché utilizando dicha información de etiqueta para recuperar información asociada a la información de etiqueta de dicha memoria caché si se requiere para procesar dicho uno o más paquetes.

[0021] Mecanismos como el descrito con referencia a la figura 1 proporcionan una base para la reducción del flujo de datos en redes. Sin embargo, a medida que crece el número de dispositivos que utilizan dichos sistemas de comunicación, y las capacidades de los dispositivos finales están sujetas a limitaciones cada vez más estrictas en términos de consumo de energía, potencia de procesamiento y ancho de banda de comunicaciones, es deseable proporcionar mecanismos para optimizar aún más dichas comunicaciones.

Sumario de la invención

[0022] La presente invención se define en las reivindicaciones independientes. Las realizaciones preferidas se definen en las reivindicaciones dependientes.

Breve descripción de los dibujos

[0023] Las anteriores y otras ventajas de la presente invención se describirán ahora con referencia a los dibujos que se adjuntan, con fines meramente ilustrativos, en los que:

La figura 1 muestra esquemáticamente aspectos de un mecanismo de compresión de encabezado de red; La figura 2 muestra un método según una primera realización;

La figura 3 muestra un método según una segunda realización;

La figura 4 presenta esquemáticamente las funciones combinadas de los métodos de la figura 2 y 3 de acuerdo con ciertas realizaciones;

La figura 5 muestra una variante del procesamiento del lado de transmisión como se presenta con respecto a la figura 4;

La figura 6 muestra un algoritmo de aprendizaje de especificación de acuerdo con una realización.

La figura 7 presenta un ejemplo de aprendizaje de especificación mediante comunicaciones de estado de acuerdo con una realización;

La figura 8 muestra un sistema informático genérico adecuado para la implementación de realizaciones de la invención; y

La figura 9 muestra un dispositivo de sensor independiente adaptable para constituir una realización.

Descripción detallada

[0024] La figura 2 muestra un método según una primera realización.

[0025] Como se muestra en la figura 2, se proporciona un método de procesamiento de un mensaje de datos para transmisión. El mensaje puede ser un paquete, por ejemplo, definido de acuerdo con un protocolo de transmisión de paquetes conocido como IPv6 o IPv4. El mensaje puede constituir igualmente un mensaje de tipo ráfaga, por ejemplo, en una comunicación punto a punto. A modo de ejemplo, el mensaje puede comprender una comunicación con comunicaciones de información de estación meteorológica, comunicaciones de señalización de telefonía celular como PDU 3G, gestión de movilidad y similares, Bluetooth, Zigbee, comunicaciones de aeronave ADS-B, sensores industriales remotos como el control de flujo y la supervisión de estado de las tuberías, la detección de intrusiones en instalaciones remotas, gestión de dispositivos (como Om A-DM, LWM2M), OneM2M, OCF, Thread, ZigBee Cluster Library, etc.

[0026] En algunas realizaciones, el componente de datos puede obtenerse con referencia a una característica del mensaje de datos o a un flujo de datos al que puede pertenecer el mensaje de datos. También se observará que algunos o todos los aspectos de la característica se pueden obtener dinámicamente, por ejemplo, en la iniciación del sistema o cuando se procesa la especificación. Por ejemplo, cuando un aspecto del mensaje es la dirección IP de origen, esta se puede obtener en el lado de transmisión al iniciar el sistema.

[0027] Esta característica puede ser cualquier característica de un flujo de datos al que pertenece el mensaje o está asociada de otro modo que se pueda suponer que sigue siendo verdadera a medida que el flujo pasa a través de la red. Entre los ejemplos posibles de la característica se pueden incluir el protocolo de acuerdo con el que el mensaje está codificado, por ejemplo, IPv4 o IPv6. A partir de esta característica se pueden hacer deducciones sobre la forma y el contenido del flujo, que pueden subyacer a algunas de las funciones de procesamiento descritas con más detalle a continuación. Se observará que las realizaciones pueden utilizarse en una gama muy amplia de redes de comunicaciones, incluyendo a modo de ejemplo no limitativo, IPv4 o IPv6, CoAP (Constrained Application Protocol), UDP (User Datagram Protocol), TCP (Transmission Control Protocol), ICMP (Internet Control Message Protocol), ICMPv6, C^bOR (Concise Binary Object Representation), CoMI (CoAP Management Interface), LWM2M (Light Weight Machine to Machine), OneM2M, OCF (Open Connectivity Foundation), MQTT (Message Queuing Telemetry Transport), RoHC (Robust Header Compression), VJ (Van Jacobson Header Compression), GHC (Generic Header Compression), DTLS (Datagram Transport Layer Security) u otros rasgos característicos de cualquiera de los contextos de comunicaciones mencionados anteriormente, mensajes de datos no formateados en los que los campos de datos individuales se atribuyen a posiciones fijas de bits o palabras dentro de un mensaje que puede tener un formato propio, o de otro tipo.

[0028] El método, como se muestra, comienza en el paso 200 antes de proceder al paso 210 en el que un campo del mensaje de datos se analiza para un componente de datos de un primer tipo, donde los datos sustitutivos correspondientes al componente de datos del primer tipo son derivables de una fuente de datos distinta a un flujo de datos asociado al mensaje de datos junto con el conocimiento de la característica.

[0029] Sobre la base de la técnica de compresión descrita con referencia a la figura 1, el componente de datos puede ser un campo del mensaje de datos, por ejemplo, como se especifica en la entrada de ID de campo de una línea de instrucción de campo. Sobre esta base, el análisis del componente de datos puede comprender el paso de determinar si el campo especificado corresponde al valor de destino de la manera definida mediante el operador de coincidencia de la línea de instrucción de campo. El experto en la materia observará que, en diferentes contextos, el análisis del mensaje de datos puede llevarse a cabo mediante cualquier mecanismo adecuado. La determinación de si el campo especificado se corresponde con el valor de destino de la manera definida por el operador de coincidencia de la línea de instrucción de campo no constituye necesariamente la determinación de si el campo es igual al valor de destino. El operador de coincidencia puede utilizarse para evaluar si el valor de campo coincide con el valor de destino. Esto puede expresarse como: MO(Valor_de_campo, Valor_de_destino) - donde m O devuelve TRUE o FALSE (coincide o no coincide). Esta representación se denomina notación polaca. Cuando el componente de datos del primer tipo se identifica así, tal y como se determina en el paso 215, el método avanza al paso 220, en el que se añade un marcador asociado con una especificación de una operación de procesamiento que define la derivación de los datos sustitutivos al mensaje de datos antes de concluir en el paso 230. De lo contrario, cuando no se identifica el componente de datos del primer tipo, tal y como se determina en el paso 215, el método concluye en el paso 230.

[0030] En las realizaciones, por ejemplo, que se explican a continuación, la modificación del mensaje de datos con un marcador puede realizarse con el fin de comprimir o enriquecer el mensaje de datos. La definición, selección o inclusión del marcador se puede llevar a cabo de acuerdo con una instrucción proporcionada en la línea de instrucción de campo, en concreto, en el campo de operación de procesamiento, o de lo contrario, como se explica con más detalle a continuación. El marcador puede comprender un ID de regla, por ejemplo, como se describe con respecto a la figura 1, o en lo sucesivo, en cuyo caso la especificación de una operación de procesamiento que define la derivación de los datos sustitutivos puede corresponder a una regla, o a una línea de instrucción de una regla. Este proceso no implica una restricción acerca de la naturaleza del marcador, podría ser un conjunto opaco de bits (por ejemplo, una etiqueta) o información estructurada (por ejemplo, datos con formato CBOR, XML o de otro tipo).

[0031] Cabe señalar que mientras las funciones de compresión/descompresión del estado de la técnica se apoyan solo en las características del propio mensaje de datos o del flujo de datos al que pertenece y, como tal, son inherentemente estáticas, las realizaciones descritas en la presente memoria refuerzan este enfoque con una determinación dinámica de los componentes de datos.

[0032] Sobre esta base, en un modo de compresión el paso de modificación del mensaje de datos con el marcador puede comprender la sustitución del componente de datos por el marcador. A modo de ejemplo, el marcador puede comprender un ID de regla como se ha comentado con referencia a la figura 1 , en la que los datos sustitutivos correspondientes al componente de datos son derivables de una fuente de datos distinta de un flujo de datos asociado al mensaje de datos. Del mismo modo, en un modo de enriquecimiento, el paso de modificación del mensaje de datos con el marcador puede comprender la sustitución del componente de datos por el marcador. A modo de ejemplo, el marcador puede comprender un ID de regla como se ha comentado con referencia a la figura 1 , en la que los datos sustitutivos correspondientes al componente de datos son derivables de una fuente de datos distinta de un flujo de datos asociado al mensaje de datos.

[0033] La figura 3 muestra un método según una segunda realización.

[0034] Como se muestra en la figura 3, se proporciona un método de procesamiento de un mensaje de datos recibido.

[0035] Como tal, el método de la figura 3 puede considerarse como una implementación del proceso coincidente al descrito con referencia a la figura 2, con el método de la figura 2 implementado en el emisor o el transmisor, y el método de la figura 3 implementado en el receptor, que recibe, por ejemplo, mensajes procesados de acuerdo con el método de la figura 2.

[0036] Tal y como se muestra en la figura 3, el método comienza en el paso 300 antes de avanzar al paso 310 en el que se extrae un marcador asociado con un primer tipo de componente de datos del mensaje de datos. El método entonces avanza al paso 320 en el que un componente de datos adicional se deriva por medio de una operación de procesamiento al respecto de una fuente de datos distinta de un flujo de datos asociado con el mensaje de datos, donde la operación de procesamiento se define en una especificación asociada con el marcador. A continuación, el método concluye en el paso 330.

[0037] La figura 4 presenta esquemáticamente las funciones combinadas de los métodos de la figura 2 y 3 de acuerdo con ciertas realizaciones.

[0038] Tal y como se muestra en la figura 4, un mensaje de datos 410 se procesa para su transmisión en un procesador de transmisión 420. De acuerdo con el método de la figura 2, un campo 411 del mensaje de datos 410 se analiza para un componente de datos de un primer tipo 412, donde el componente de datos del primer tipo 412 se determina para ser derivable de una fuente de datos distinta de un flujo de datos asociado al mensaje de datos 410. A continuación, el procesador de transmisión sustituye el componente de datos 412 por un marcador 433, 443 asociado al primer tipo de componente de datos. Como se muestra, el marcador 433 puede sustituir simplemente el componente de datos en cuestión, o alternativamente un único marcador 443 puede sustituir componentes de datos pertenecientes a un número de campos en el mensaje de datos, por ejemplo, como lo permite el enfoque descrito anteriormente con respecto a la figura 1. Se observará que el término "sustituir" no debe entenderse como un requisito de que el marcador se sitúe en la misma posición en el mensaje de datos que el componente de datos, o que deba tener la misma longitud. De hecho, el marcador será normalmente mucho más corto que el componente de datos al que sustituye para conseguir un efecto de compresión. En efecto, en los casos en que el marcador adopta la forma de un ID de regla según el enfoque descrito con referencia a la figura 1, puede ser normalmente del orden de 1 byte, y puede ser tan pequeño como un bit. Se observará que pueden utilizarse uno o más marcadores para sustituir componentes de datos que pertenecen al mismo campo o que pertenecen a diferentes campos respectivos, o que se extienden a través de una pluralidad de campos respectivos. Se observará que, en ciertos casos, el campo o los campos que contienen componentes de datos que deben ser sustituidos por uno o más marcadores pueden contener contenido adicional que no es sustituido por un marcador; en cuyo caso este contenido adicional se incluye en el mensaje de datos 430, 440 como una carga útil residual respectiva 432, 442.

[0039] El mensaje de datos 430 o 440 resultante se transmite entonces a través de la red 450 desde el emisor a hasta el receptor b. En ciertas implementaciones, las comunicaciones de acuerdo con las realizaciones pueden tener lugar entre un dispositivo final y un servidor, u otro punto centralizado. En cualquier caso, mientras las comunicaciones tengan lugar entre dos dispositivos, de acuerdo con las realizaciones, cada uno puede operar como un emisor y un receptor. En otros casos, un dispositivo concreto puede operar únicamente como un emisor, o únicamente como un receptor.

[0040] Cuando el receptor b recibe el mensaje de datos 430 o 440, se procesa mediante un procesador de recepción 460 y el marcador 433, 443 se extrae mediante la unidad funcional 461 de una fuente de datos interna 462, o una fuente de datos externa 463, a un componente de datos adicional.

[0041] La fuente de datos puede ser una base de datos, en memoria o en almacenamiento, una cadena de bloques o registros públicos, como los que alberga IANA, un archivo, por ejemplo, en XML, JSON o formato binario o cualquier otro. Se proporcionan ejemplos adicionales a continuación.

[0042] En la disposición de la figura 1, se presume que las especificaciones son idénticas en el receptor y en el transmisor, y del mismo modo, que son idénticas independientemente de las características de dónde se implementen, por ejemplo, en un dispositivo final por un lado o en un servidor por otro. Por ejemplo, para la compresión, la dirección IP puede ser comprimida con respecto a los valores aprendidos a través de DHCP (global) o SLAAC (local de vínculo), de modo que el marcador indicará si es una dirección global o local de vínculo. En el lado del receptor, sin embargo, puede ser suficiente descomprimir la dirección con un valor genérico que conozca la naturaleza de la dirección en el lugar del valor real de la dirección. De acuerdo con determinadas realizaciones, pueden preverse alternativas, por ejemplo, como las siguientes:

• Pueden definirse especificaciones que definen una operación de procesamiento en la que ciertos elementos presentan alternativas, para su aplicación en función de la situación, por ejemplo, diferentes valores de destino, operadores de coincidencia o instrucciones de procesamiento para los mensajes recibidos en contraposición a los mensajes transmitidos, etc.

• El procesador de transmisión o el procesador de recepción puede adaptarse para procesar las especificaciones que definen una operación de procesamiento de una manera que corresponde a la situación del dispositivo en el que funciona. Por ejemplo, en los casos en que una especificación requiera una operación DHCP, en el caso de una transmisión desde el propio dispositivo, el procesador de transmisión puede programarse para omitir este paso y simplemente insertar un valor predefinido para la dirección IP de los dispositivos.

[0043] De acuerdo con ciertas variantes opcionales, el componente de datos adicional puede almacenarse en un dispositivo de almacenamiento 464, por ejemplo, para reducir la necesidad de acciones de interrogación adicionales.

[0044] Sobre esta base, las realizaciones pueden contemplarse como una asociación de un estado con un determinado dispositivo, flujo de datos, mensaje o, en general, el compresor/descompresor. Un ejemplo específico sería la noción de que un dispositivo puede tener la misma dirección IPv6 durante su asociación con una red particular, la aplicación de gestión en este dispositivo tendrá el mismo puerto UDP durante toda la vida útil del dispositivo, una sesión de gestión específica (que reconfiguraría el período de suspensión del dispositivo) puede tener un ID de token CoAP válido para la duración de la sesión de gestión, el compresor/descompresor puede tener una función de instrucción de procesamiento específica implementada o ausente, etc. Sobre esta base, por ejemplo, si la entrada del valor de destino implementa una operación de aprendizaje como se describe con más detalle a continuación, el aprendizaje debe almacenarse en algún lugar. Esto puede ser en un servicio externo (por ejemplo, enviándolo a través de HTTPS o almacenándolo en una base de datos), o de otro modo, pero en cualquier caso constituye esencialmente el mantenimiento de un estado. Lo mismo ocurre con cualquier función que pueda ser modificada, descubierta, aprendida o utilizada internamente. Puede haber una función que mantenga el número de mensajes que han pasado por el compresor. O, puede ser la función FEC que podría estar almacenando mensajes específicos para su recuperación. O bien, las claves de cifrado, o de establecimiento de túnel, o de firma. Una vez que se considera que las comunicaciones tienen un aspecto imponente, cobra sentido un mecanismo de señalización que permite a los dos dispositivos en comunicación intercambiar datos relativos a su funcionamiento o a un estado concreto. A continuación, esto podría utilizarse para transmitir los valores de las funciones, que podrían tener que configurarse cuando se ejecutan las funciones. Dicho estado puede conservarse por compresor/descompresor, por flujo de datos, por dispositivo, por especificación, por contexto, por función, o crearse dinámicamente. El estado puede guardarse localmente, remotamente (por ejemplo, a través de SSH, DNS, DHCP, HTTPS, MQTT, ODBC), o ambos. El contexto puede verse entonces como una descripción estática, que tiene indicaciones sobre cómo interactuar con el estado. Las realizaciones se refieren a un marcador asociado con una especificación de una operación de procesamiento que define la derivación de un componente de datos de una fuente de datos distinta de un flujo de datos asociado al mensaje de datos. La operación de procesamiento puede comprender una instrucción para recuperar el componente de datos, o algún precursor del mismo, desde un repositorio como un archivo estático o una base de datos. La operación de procesamiento puede comprender, alternativa o adicionalmente, una instrucción para recuperar el componente de datos, o algún precursor del mismo, desde un proceso, que puede ser una aplicación externa, o una operación de software definida en la propia especificación, y ejecutada en una plataforma adecuada, en cuyo caso el software ejecutado puede constituir la fuente de datos. En cualquier caso, la fuente de datos no es el flujo de datos asociado al mensaje de datos, por ejemplo, un flujo de datos al que pertenece el mensaje de datos, o el propio mensaje de datos. La fuente de datos puede excluir opcionalmente la especificación, y/o un contexto al que pertenece la especificación. La operación de procesamiento puede contribuir a la definición de la respectiva región especificada, el valor de destino, la manera prescrita en que el valor de destino y el valor en la región específica pueden ser requeridos para corresponder, o la instrucción de procesamiento que se realizará en el caso de que la línea de instrucción de campo se aplique, o cualquier combinación o algunos o todos estos.

[0045] Como tal, se divulga un procesador de transmisión para procesar un mensaje de datos, estando el procesador de transmisión adaptado para analizar un campo del mensaje de datos para un componente de datos de un primer tipo, donde el componente de datos del primer tipo es derivable de una fuente de datos distinta de un flujo de datos asociado con el mensaje de datos, y para añadir un marcador al mensaje de datos, estando el marcador asociado a una especificación de una operación de procesamiento que define la derivación.

[0046] Igualmente, se divulga un procesador de recepción para procesar un mensaje de datos recibido, estando el procesador de recepción adaptado para extraer un marcador asociado con un primer tipo de componente de datos del mensaje de datos y para derivar un componente de datos adicional por medio de una operación de procesamiento con respecto a una fuente de datos distinta del flujo de datos asociado al mensaje de datos, donde la operación de procesamiento se define en una especificación asociada al marcador.

[0047] El marcador está asociado a una especificación de una operación de procesamiento que define la derivación del componente de datos. El marcador puede designar una especificación por referencia o de cualquier modo adecuado. Un ejemplo de una especificación es una regla como se describe anteriormente, en cuyo contexto un marcador puede ser un ID de regla. En cierta realización, el marcador puede comprender información adicional, por ejemplo, un residuo de compresión, aprendizaje de información, o información de señal/control, como se explica a continuación.

[0048] En determinadas realizaciones, un marcador puede transmitir información de estado para el compresor/descompresor en banda. Por ejemplo, un campo con una función puede tener un marcador de longitud variable estructurado (SVLM, por sus siglas en inglés). Este SVLM puede tener una estructura, por ejemplo, expresada en CBOR, como un TLV u otro. Esto puede dividir el marcador en dos partes - "marcador" e "información adicional". La "información adicional" puede contener información como el "nuevo valor de destino" para el valor de destino. En el ejemplo del servidor DHCP() que se muestra a continuación, la red puede realizar un DHCP para determinar la dirección ⁱP, y luego enviar el valor obtenido en un SLVM al dispositivo.

[0049] Esto también podría utilizarse para inicializar la configuración de un dispositivo a través de una única especificación que define una operación de procesamiento asignada para este uso, por ejemplo, una especificación que define una operación de procesamiento que contiene todas las funciones que necesitan un valor. Las especificaciones que definen una operación de procesamiento por sí misma no generarán ningún paquete ni operaciones en el dispositivo, salvo la configuración del estado asociado a estas funciones.

[0050] Un ejemplo de esto podría ser pedirle al usuario que defina algunos valores, por ejemplo, la IP de origen, la IP de destino y el destino de UDP en el dispositivo final. Esto podría expresarse, por ejemplo, con la definición de una función: UserDefined()

[0051] El dispositivo puede, entonces, tener una ESPECIFICACIÓN DE CONFIG. con ID_DE_REGLA == 100, que puede ser, por ejemplo:

[0052] Aquí, las variables "FirstIPv6Add", "SecondIPv6Add" y "FirstUDPDest" hacen referencia a parte del estado local en el punto final. A esto se le podría entonces hacer referencia mediante funciones en otras especificaciones que definen una operación de procesamiento, por ejemplo, para servir de valor de destino. La denominación está definida por el usuario, y puede tener una lógica como "AII.IPv6.source" o "RuleID.5.IPv6.source", por ejemplo.

[0053] Esta especificación que define una operación de procesamiento solo coincidirá cuando sea necesario enviar una configuración, y puede utilizar el SVLM. (alternativamente, podría haber un protocolo de gestión que podría realizar esta configuración sobre CoAP u otros medios no entendidos directamente por el procesador de transmisión/procesador de recepción. El SLVM proporciona una manera de sincronizar los estados de los dos extremos comunicantes en banda.

[0054] La "información adicional" puede incluir también la indicación de que el emisor no tiene el campo en su estado. Esto indica al receptor que debe enviarlo siempre que sea posible. Por ejemplo, un dispositivo puede ver la función DHCP() en el contexto, pero puede NO ser capaz de ejecutar directamente el DHCP(). Tras la compresión, se indicaría en la parte "información adicional" del SVLM "estado local ausente".

[0055] De acuerdo con diversas variantes opcionales, el componente de datos adicional puede someterse a procesamiento adicional en el procesador de recepción o el procesador de transmisión.

[0056] De acuerdo con diversas variantes opcionales, el componente de datos adicional 471 puede ocupar el lugar del componente de datos original 412 en un mensaje de datos reconstituido o descomprimido 470, por ejemplo, a través de una unidad funcional de sustitución 465. De acuerdo con diversas variantes opcionales, el componente de datos adicional 491 puede ser añadido, por ejemplo, por una unidad funcional de "adición" 466 al mensaje de datos como un campo adicional que no pertenece al original o como un mensaje de datos reconstituido 480.

[0057] El método de la figura 2 o 3 se puede implementar en un supuesto como el de la figura 1, en el que se definen una o más reglas, comprendiendo cada regla una o más líneas de instrucción de campo, comprendiendo cada línea de instrucción de campo un valor de destino y una instrucción de procesamiento. Como tal, las “reglas” de este tipo son ejemplares de las especificaciones que definen una operación de procesamiento. En tal caso, el método puede comprender los pasos adicionales de determinar para una regla si una región especificada respectiva del mensaje de datos corresponde al valor de destino respectivo de una manera prescrita respectiva, y en caso de que la región especificada respectiva corresponda al valor de destino de la manera prescrita respectiva para cada campo en una regla respectiva, para aplicar la instrucción de procesamiento de cada campo en la regla correspondiente con respecto a la región especificada respectiva. La estructura general descrita con respecto a la figura 1 es un ejemplo de este supuesto operacional, aunque el experto en la materia observará que se puede prever cualquier número de variantes de este supuesto. A pesar de que ciertos ejemplos de la presente memoria se describen con referencia a supuestos de este tipo, se apreciará que las realizaciones son aplicables a muchos supuestos de procesamiento de mensaje y de compresión de encabezado. Por ejemplo, el mensaje puede ser un paquete, por ejemplo, definido de acuerdo con un protocolo de transmisión de paquetes conocido como IPv6 o IPv4 y finalmente un protocolo de capas superiores. El mensaje puede constituir igualmente un mensaje de tipo ráfaga, por ejemplo, en una comunicación punto a punto. A modo de ejemplo, el mensaje puede comprender una comunicación con comunicaciones de información de estación meteorológica, comunicaciones de señalización de telefonía celular como PDU 3G, gestión de movilidad y similares, Bluetooth, Zigbee, comunicaciones de aeronave ADS-B, sensores industriales remotos como el control de flujo y la supervisión de estado de las tuberías, la detección de intrusiones en instalaciones remotas, etc., como se menciona anteriormente.

[0058] Un enfoque básico como el de la figura 1 puede extenderse en una serie de formas para aumentar su potencia y sofisticación.

[0059] El enfoque general de probar cada regla y luego aplicar cada línea de instrucción de campo en la regla significa que las operaciones pueden ser incluidas en la regla escrita de tal manera que no tienen ningún efecto en la prueba (siempre son verdaderas) por ejemplo, mediante la configuración del operador de coincidencia que se ha de ignorar, pero luego incluir operaciones particulares para el procesamiento adicional del mensaje de datos. Una serie de ejemplos presentados a continuación utilizan este enfoque.

[0060] En algunos casos, se puede suponer que las líneas de instrucción de campo de la regla seleccionada se aplican en el orden en que aparecen en la regla, y que el mensaje de datos de salida se construye de extremo a extremo en la misma secuencia que el orden de las líneas de instrucción de campo en la regla que se aplica. De este modo, el mensaje de datos de salida puede estructurarse definiendo adecuadamente la secuencia de líneas de instrucción de campo, y el número de ID de campo puede utilizarse, en algunos casos, para otros fines. Una serie de ejemplos presentados a continuación utilizan este enfoque.

[0061] De acuerdo con determinadas realizaciones, las líneas de instrucción de campo se pueden ejecutar en una secuencia arbitraria como sugiere alguna consideración adicional. Por ejemplo, las líneas de instrucción de campo se pueden asociar a un número de secuencia, o se pueden procesar ciertas líneas de ID de campo que no se corresponden con campos reales del paquete de datos en un orden de precedencia predefinido, o cualquier otro. Se observará que ciertas líneas de instrucción de campo podrían continuar ejecutándose en el orden de su posición en el encabezado, mientras que otras se tratan en alguna otra secuencia.

[0062] La instrucción de procesamiento puede comprender una acción de compresión y/o descompresión como se comenta con respecto a la figura 1. Además de realizar una variedad de operaciones adicionales con la instrucción de procesamiento, también podemos definir funciones que proporcionan una salida de longitud cero (por ejemplo, que no emitan nada) y que solo se centren en la acción. El componente de datos adicional recuperado de acuerdo con el método de la figura 3 puede utilizarse entonces de diversas maneras.

[0063] En algunos casos, el componente de datos adicional puede utilizarse para rellenar un mensaje de datos descomprimido llenando secciones vacías del mensaje de datos con la información recuperada. Sobre esta base, la operación de los métodos de la figura 2 y 3 tomados conjuntamente constituye una operación de compresión/descompresión de extremo a extremo. Por definición, el método puede comprender el paso adicional de sustituir el componente de datos por el componente de datos adicional.

[0064] En algunos casos, el componente de datos adicional se puede utilizar para enriquecer un mensaje de datos mediante la adicción de la información recuperada como datos complementarios en el mensaje de datos, además del mensaje de datos original. Sobre esta base, la operación de los métodos de la figura 2 y 3 tomados conjuntamente constituye una operación de enriquecimiento con carga final. Como tal, el método puede comprender el paso adicional de añadir el componente de datos adicional al flujo de datos.

[0065] En algunos casos, el método puede comprender los pasos adicionales de almacenar el componente de datos adicional, y en una iteración adicional del paso de analizar una región de un mensaje de datos adicional para un marcador asociado a un primer tipo de componente de datos, recuperar los datos sustitutivos almacenados en lugar de repetir dicho paso de interrogar una fuente de datos asociada al marcador.

[0066] Cabe observar que los diversos casos de uso mencionados anteriormente pueden combinarse. Por ejemplo, los datos adicionales pueden añadirse al flujo de datos y almacenarse para futuras iteraciones, pueden utilizarse para descomprimir el mensaje de datos y almacenarse para futuras iteraciones o cualquier otra combinación.

[0067] Cabe observar que, en un contexto como este, la recuperación y, en su caso, el uso del componente de datos adicional puede realizarse en diversos puntos diferentes del proceso. Por ejemplo, la fuente de datos puede ser interrogada en el contexto de la especificación del campo, la definición o resolución de la instrucción de procesamiento, la definición de la manera en la que se requiere que un valor de destino particular corresponda al valor de destino, la definición del valor, etc. En las siguientes secciones, algunas de estas posibilidades se exploran con mayor detalle.

[0068] En determinadas realizaciones, derivar un componente de datos adicional por medio de una operación de procesamiento puede implementarse por medio de unos comandos de operación de procesamiento especiales incorporados en la especificación, que el procesador de transmisión o de recepción está adaptado para interpretar y ejecutar directamente a fin de generar el componente de datos adicional o un elemento del mismo. Se puede proporcionar una pluralidad de estos comandos de operación de procesamiento especiales, cada uno correspondiente a una función concreta, o uno o más comandos de operación de procesamiento especiales generales, cuya función se interpreta en función de otros elementos en la misma línea de instrucción de campo. Por medio de ejemplo, los siguientes ejemplos de funciones de "generar" o “computar” siguen este último enfoque, aunque el experto en la materia observará que se podrían implementar individualmente de igual manera.

[0069] Los tres ejemplos siguientes muestran el uso de una instrucción de procesamiento “generar” de acuerdo con las realizaciones. Esta instrucción de procesamiento “generar” se puede utilizar para rellenar un campo que no está enviado a través de la red, que significa que en algunos casos el campo en cuestión simplemente se puede omitir en los datos transmitidos. La instrucción de procesamiento “generar” se puede asociar con el uso de almacenamiento como el elemento 464, tal y como se ha descrito anteriormente, para permitir que las operaciones se repartan entre una pluralidad de mensajes posteriores.

[0070] Para el id de campo de etiqueta de flujo IPv6 en el encabezado IPv6

[0071] Cuando el mensaje de datos que contiene un componente de datos correspondiente a la dirección del dispositivo llega al procesador de transmisión, el procesador de transmisión determina la especificación que ha de ser aplicable, ya que en cualquier caso, el operador de coincidencia es “ignorar”, de manera que la línea siempre será verdadera y, en función de esta, ejecuta la operación “generar”, por lo que se genera el mismo valor de identificador para todos los mensajes que tienen la misma dirección de origen, así como puerto de origen y puerto de destino. La operación de generación puede estar definida para almacenar la etiqueta, y descartarla después de cierto periodo de tiempo, según la característica del tráfico.

[0072] Mientras que el ejemplo presentado anteriormente mantiene la estructura de cuatro columnas del enfoque de la figura 1 , cabe observar que se pueden definir columnas adicionales, que soporten funcionalidades paralelas adicionales, y/o comportamientos de extensión o de modificación de acuerdo con realizaciones de la invención. Por ejemplo, además de especificar un campo como se define en el protocolo subyacente del mensaje de datos, una subparte de un campo puede definirse en términos de, por ejemplo, una posición inicial dentro del campo especificado y una longitud de subcampo, o de otro modo. Mientras que el enfoque de la figura 1 asume que las especificaciones son igualmente aplicables de manera ascendente y descendente, también pueden definirse especificaciones que sean aplicables en una dirección o en la otra, o que sean aplicables de una manera en una dirección, y de otra en la dirección opuesta, o de otro modo. También se pueden añadir campos adicionales a la tabla de contexto que pueden ser opcionales para el mantenimiento del sistema, como una fecha de caducidad de la especificación (para la extinción de un formato de datos o para la caducidad de suscripción, por ejemplo). Esto es equivalente a añadir un operador de fecha en el operador de coincidencia, que puede ser conceptualmente más fácil de gestionar como un campo adicional en la implementación de la base de datos de contexto. Otros ejemplos pueden incluir la ventana de validez de la especificación (2 campos), el ID de inicio de sesión (quizá para el análisis del rendimiento, 1 campo), etc.

[0073] Por motivos de claridad, las referencias de ID de campo, que corresponden a un campo real especificado en el mensaje de datos, están definidos en la tabla de especificación anterior, y las de otros ejemplos adicionales debajo de acuerdo con la convención [Protocol].[Field reference]. Las referencias de ID de campo que no cumplen con esta convención, y en concreto, presentan un primer componente no correspondiente con un protocolo de red puede entenderse como un uso alternativo del ID de campo, a fin de implementar características especiales como las descritas en la presente memoria.

[0074] Para el campo del identificador del id de fragmentación IPv4 del encabezado IPv4.

[0075] Cuando el mensaje de datos que contiene un componente de datos correspondiente a la dirección del dispositivo llega al procesador de transmisión, el procesador de transmisión determina la especificación que ha de ser aplicable, ya que en cualquier caso, el operador de coincidencia es “ignorar”, de manera que la línea siempre será verdadera y, en función de esta, ejecuta la operación “generar”, por lo que la siguiente línea de instrucción de campo puede generar un valor diferente cada vez que se llame la instrucción de procesamiento. El valor puede ser distinto para todos los mensajes o para cada tupla compuesta por la misma dirección de origen, el mismo puerto de origen y el mismo puerto de destino, por ejemplo.

[0076] Para un campo de ID de mensaje CoAP del encabezado CoAP.

[0077] Cuando el mensaje de datos que contiene un componente de datos correspondiente a la dirección del dispositivo llega al procesador de transmisión, el procesador de transmisión determina la especificación que ha de ser aplicable, ya que en cualquier caso, el operador de coincidencia es “ignorar”, de manera que la línea siempre será verdadera y, en función de esta, ejecuta la operación “generar”, por lo que para un ID de mensaje CoAP puede ser el mismo que para la fragmentación IPv4, una instrucción de procesamiento "generar" como se muestra a modo de ejemplo en la siguiente línea de instrucción de campo puede generar un valor diferente cada vez que se requiere la instrucción de procesamiento. El valor puede ser distinto para todos los mensajes o para cada tupla compuesta por la misma dirección de origen, el mismo puerto de origen y el mismo puerto de destino, por ejemplo. Se puede utilizar para la compresión de mensajes NON.

[0078] En concreto, el componente de datos puede ser un ID de fragmentación, y la fuente puede ser una calculadora de suma de verificación adaptada para devolver un ID correspondiente.

[0079] Por ejemplo, en IPv4, el identificador para la fragmentación puede ser generado por el descompresor y debe ser diferente para cada paquete, en IPv6, la etiqueta de flujo puede ser generada por el descompresor, pero debe mantenerse igual para un flujo. Para el ID de mensaje CoAP tenemos el mismo comportamiento que para el id de fragmentación IPv4.

Uso del componente de datos adicional en el contexto de un valor de destino.

[0080] Si se asume que un emisor, como un dispositivo de usuario final, ha implementado el método de la figura 2 de manera que transmita un marcador correspondiente a un ID de regla que especifique la especificación de abajo, Protocol.fieldID es un nombre general para denominar el campo específico que debe aprenderse.

[0081] El valor de destino está configurado por medio de una función, que opcionalmente puede tener algunos parámetros. Esta función devuelve un valor utilizado como un valor de destino, por ejemplo, en un proceso, como se describe con referencia a la figura 1 , o de otro modo.

[0082] Si la función está presente en un número de diferentes líneas de instrucción de campo, entonces el resultado puede ser almacenado en caché la primera vez que se llame a los servicios, en cuyo caso se pueden llamar periódicamente para actualizar el valor, o simplemente se pueden llamar para cada línea de instrucción de campo.

[0083] Sobre esta base, cuando se determina si una región especificada del mensaje de datos corresponde al valor de destino respectivo de una manera prescrita respectiva, el valor de destino en cuestión puede ser recuperado sobre la marcha de un servicio designado en la especificación.

[0084] En algunos casos, también puede ser conveniente informar al dispositivo final del valor obtenido. Esto se puede llevar a cabo utilizando, por ejemplo, un protocolo de administración (como Lightweight M2M, CoMI o similares), a través de un protocolo de señalización (como comandos MAC-layer), ID de regla especialmente asignados, etc.

[0085] Tal y como un ejemplo del uso del enfoque general descrito anteriormente para definir el valor de destino, el valor de destino puede comprender un marcador definido de manera que recupere una dirección de dispositivo.

[0086] Las siguientes entradas ilustran como una dirección IPv6 puede ser obtenida dinámicamente mediante un dispositivo de acuerdo con una realización que utiliza DHCP.

[0087] Cuando el mensaje de datos que contiene un componente de datos que corresponde a la dirección del dispositivo llega al procesador de transmisión, el procesador de transmisión determina la especificación ha de ser aplicable, por ejemplo, mediante el ingreso de datos en el valor de destino por medio de una llamada DHCP como se especifica en la especificación, comparando esta con el campo de dirección del emisor como se especifica en el campo de referencia, y suponiendo que esto coincida con que la especificación sea aplicable, y en vista de que la operación “no enviado” omita la dirección._. Cuando el mensaje de datos llega al procesador de recepción, el marcador se extrae, y en respuesta, la especificación expuesta anteriormente se aplica al mensaje de datos y la nueva operación DHCP se lleva a cabo para obtener la dirección IP del emisor y se incorpora en el un mensaje de datos reconstituido.

[0088] Esta funcionalidad proporciona un ejemplo de un caso donde puede resultar conveniente almacenar de manera adicional el resultado de la operación, la primera vez se envía un mensaje desde este dispositivo, el procesador puede enviar una solicitud DHCP, solicitando la asignación de una dirección IP para este dispositivo tal y como se describe anteriormente. A continuación, la respuesta se almacenará en el estado asociado con este dispositivo. De aquí en adelante, cualquier mensaje de enlace ascendente o de enlace descendente (al/del dispositivo) puede utilizar esta dirección IP.

[0089] Esta funcionalidad proporciona un ejemplo de un caso donde puede resultar conveniente modificar de manera adicional la propia especificación: el procesador puede cambiar la especificación permanentemente mediante el reemplazo del texto DHCP(« nodo1 ») por un valor constante, p. ej., « 2001 ::1 » o « 10.0.0.1 ».

[0090] Aún más, este ejemplo puede ser adecuado para las realizaciones que implementan aspectos de comunicaciones de un estado, y plantea consideraciones sobre si las operaciones se pueden llevar a cabo de manera diferente en función del papel del dispositivo que lleva a cabo la operación, por ejemplo, en el caso de los dispositivos finales, por un lado, y de los componentes de red por otro. En presencia de un protocolo de configuración (señalización/control o en banda), si el lado de la red es el emisor, puede determinar que necesita llevar a cabo el DHCP() a fin de obtener la información necesaria. Entonces envía un mensaje al dispositivo para configurar el estado, de manera que también contiene el valor obtenido a través del DHCP() (p. ej., dirección IPv6 de destino). En este momento, tanto la red como el dispositivo presentan un estado que indica el valor que se debe emplear para la función de DHCP("nodo1"). En ese momento, tiene lugar el proceso de compresión/descompresión estándar.

[0091] En ausencia de un protocolo de comunicaciones de señalización/control o en banda, así como para optimización, esto también se puede lograr a través de contextos asimétricos. En este caso, la red puede ser capaz de realizar DHCP, pero no el dispositivo, sin la necesidad de intercambiar ninguna información. El DISPOSITIVO puede utilizar siempre una dirección IPv6 Link-Local (p. ej., FE80::ABCD) como dirección IP de origen, omitiéndola, y la red, en la recepción, puede utilizar el DHCP() para obtener una dirección global para ponerla en los paquetes (p. ej., 2001::1234). Los mensajes de enlace descendente también reciben la dirección global omitida y remplazada en la recepción mediante la dirección Link-Local. De este modo, esto transforma la compresión/descompresión de manera efectiva en una NAT.

[0092] Por último, en el caso de que el dispositivo no lleve cabo la descompresión del paquete completo, esto podría servir de beneficio para el sistema completo. El dispositivo envía un marcador que indica a la red que necesita llevar a cabo el DHCP() (o cualquier otro mecanismo) para determinar la dirección de origen para poner en el paquete de salida. Si hay algún enlace descendente, la dirección de origen simplemente será omitida, que a su vez volvería al dispositivo, que solo miraría el marcador y sabría cómo procesarlo, sin preocuparse de qué dirección IP posee exactamente.

[0093] Esto proporciona un ejemplo donde diferentes comportamientos pueden ser adecuados para el comportamiento de transmisión y de recepción en la misma especificación, por ejemplo, puede no ser necesario para el dispositivo transmisor llevar a cabo una llamada DHCP para recuperar su propia dirección IP, que puede recuperar de la memoria en determinadas realizaciones.

[0094] Aún más, en el caso de implementaciones que emplean comunicaciones de estado, si el dispositivo es el emisor, puede estar configurado para interpretar la operación DHCP() como una instrucción de que la RED realizará la consulta DHCP() y enviará de nuevo la información necesaria a través del mecanismo de señalización. Esto también podría significar que el emisor debería realizar la llamada DHCP, y luego enviar el valor al receptor a través del mecanismo de señalización. Podría significar que el dispositivo puede simplemente omitir la dirección IP del emisor, y esta dirección será rellenada por el DHCP() en el lado del receptor.

[0095] Las primeras dos líneas de instrucción de campo utilizan DHCP para obtener un prefijo. El nombre del nodo o su dirección MAC se pueden proporcionar como parámetro. El segundo par de líneas de instrucción de campo describe el comportamiento con el descubrimiento de vecinos (SLAAC). En ese caso, se puede proporcionar la dirección MAC.

[0096] Como tal, esta especificación llama para la interrogación de una pluralidad de fuentes de datos. Dado que la especificación divide la dirección IPv6 en dos partes, se puede realizar una sola interrogación cada vez, y el componente de datos recuperado de la primera interrogación almacenado, por ejemplo, en el almacenamiento 464 para ser utilizado para cumplir con el segundo par de líneas de instrucción de campo y obtener la dirección completa.

[0097] Las siguientes entradas ilustran como una dirección IPv6 puede ser obtenida dinámicamente mediante un dispositivo de acuerdo con una realización que utiliza SLAAC

[0098] Este enfoque se puede aplicar a otros campos como TTL (IPv4) o Hop limit (IPv6) con valores por defecto devueltos por el DHCP o SLAAC.

[0099] Tal y como un ejemplo adicional del uso del enfoque general descrito anteriormente para definir el valor de destino, el valor de destino puede comprender un marcador definido de manera que recupere una dirección de solicitud.

[0100] Cuando el mensaje de datos que contiene un componente de datos que corresponde a la dirección del dispositivo llega al procesador de transmisión, el procesador de transmisión determina la especificación que debe aplicarse, por ejemplo, mediante el ingreso de datos en el valor de destino por medio de una llamada DNS como se especifica en la especificación, comparando esta con el campo de dirección de identificador de la solicitud como se especifica en el campo de referencia (IIDLA = dirección local del identificador de interfaz), y suponiendo que esto coincida con que la especificación sea aplicable, y en vista de que la operación “no enviado” omita la dirección. Cuando el mensaje de datos llega al procesador de recepción, el marcador se extrae, y en respuesta, se aplica la especificación expuesta anteriormente se aplica al mensaje de datos y la nueva operación DNS se lleva a cabo para obtener la dirección IP del emisor y se incorpora en el un mensaje de datos reconstituido.

[0101] En consecuencia, la fuente de datos, y el componente de datos adicional respectivo pueden tomar una variedad infinita de formas. Por ejemplo, la fuente de datos puede ser un servidor DNS y el marcador puede indicar el servidor DNS y una URL. Sobre esta base, el componente de datos adicional puede ser entonces una dirección IP.

[0102] Por ejemplo, la fuente de datos puede ser un servidor DHCP y el marcador puede indicar un servidor DHCP y una dirección MAC. Sobre esta base, el componente de datos adicional puede ser entonces una dirección IP.

[0103] Por ejemplo, la fuente de datos puede ser un servidor de clave de cifrado adaptado para devolver la clave pública de una entidad especificada. Sobre esta base, el marcador indica el servidor de clave de cifrado y la entidad especificada.

Uso del marcador para hacer referencia al código de software

[0104] El operador de coincidencia, el valor de destino o la instrucción de procesamiento pueden contener un código escrito en un lenguaje de software, como JavaScript, lua o cualquier otro lenguaje de programación.

[0105] El ID de campo del operador de coincidencia o el campo de la instrucción de procesamiento pueden utilizarse para especificar el lenguaje.

[0106] Un papel del operador de coincidencia puede ser probar la validez del valor del campo, tal y como se ha explicado anteriormente. Se pueden definir parámetros como el valor de campo (valor original en compresión, residuo para descompresión) y el valor de destino. En determinadas realizaciones, donde la especificación incluye una llamada a elementos similares al lenguaje de programación, la instrucción de procesamiento puede estar definida en términos de 3 parámetros: la función de comprimir el campo, la función de descomprimir el campo y el tamaño en bits que se debería devolver, a pesar de que en algunos casos se puede especificar un tamaño de retorno variable. La siguiente especificación proporciona un ejemplo de operaciones definidas en términos de elementos de lenguaje de programación que, como se muestra, están específicamente en formato JavaScript, a pesar de que cabe observar que se puede utilizar cualquier lenguaje de programación.

[0107] Los datos son un ID de campo especial que no corresponde a ningún campo del paquete de encabezado, pero que en cambio especifica los datos después del encabezado analizado. La longitud y la posición pueden utilizarse para aislar una secuencia en los datos. Las entradas de posición adicional en la regla pueden indicar el desplazamiento y la longitud de la parte de la carga útil a la que se debe acceder.

[0108] La instrucción de procesamiento llamará al proceso de JavaScript con argumentos N JS(a,b,c, ...), donde uno de los argumentos contiene un código de JavaScript que se debe ejecutar. Este código de JavaScript puede ser un fragmento de código (p. ej., una sola expresión de JavaScript) o un programa que consiste en múltiples funciones de JavaScript, que al final dan lugar al resultado esperado. El resultado esperado para un operador de coincidencia puede ser un valor booleano verdadero/falso (p. ej., el campo coincide en "verdadero" y no coincide en "falso"). Los argumentos distintos del código de JavaScript pueden proporcionar toda la información necesaria para la ejecución del código de JavaScript, que incluye, entre otros: el valor de campo (FV, por sus siglas en inglés), el valor de destino (TV, por sus siglas en inglés), el valor de campo comprimido (CFV, por sus siglas en inglés), el estado asociado a este mensaje de datos, el estado asociado a este flujo de datos, el estado asociado a este C/D, etc.

[0109] Cuando este mensaje de datos que contiene un componente de datos con el valor 0b1110000 llega al procesador de transmisión, el procesador de transmisión llama a la función de JavaScript ExecuteJavaScript(FieldValue, TargetValue, "FV&TV==TV") como se especifica en el operador de coincidencia. El texto entre comillas define un código de JavaScript válido, que en este caso define una expresión que debe evaluarse, que utiliza dos parámetros, FV (que corresponde al valor de campo) y TV (que corresponde al valor de destino). Una vez se ha evaluado, el código de JavaScript produce un valor booleano (tomando verdadero o falso), el comportamiento esperado para un operador de coincidencia. Para su ejecución, la expresión compara el contenido especificado en el valor de campo por medio de una operación AND bit a bit (sobre la base del código de JavaScript utilizado en el presente ejemplo y representado por “&”), con el valor 0b1110000 en el valor de destino, y si el resultado de esta operación AND bit a bit es igual al valor de destino (representado por ==), el resultado de la ejecución lo evalúa como “verdadero”, quedando la especificación determinada como aplicable. La compresión y descompresión también están definidas con expresiones de JavaScript, donde la compresión está definida como JS(FV, "[FV, 6]"}, y la descompresión está definida como JS(CFV, TV, "[CFV<<2|TV,8]"). Cabe observar que esto podría dividirse igualmente en dos funciones compresión=JS() y descompresión=JS().

[0110] La compresión se determina mediante la ejecución de la función ExecuteJavaScript(FieldValue, "[FV, 6]"), mientras que la descompresión se obtiene al ejecutar la función ExecuteJavaScript(CompressedFieldValue, TargetValue, "[CFV <<2|TV,8]").

[0111] El código de compresión "[FV, 6]" devuelve la variable FV que en este ejemplo contiene el valor de campo y el valor "6" que indica en este caso el número de bits que deben retenerse para enviar, y el código de descompresión "[CFV<<2|TV,8]" proporciona la salida binaria del descompresor y el tamaño de la salida, donde CFV es la variable que contiene el valor de campo comprimido <<2 indica el desplazamiento binario a la izquierda con 2 bits, | denota la operación OR bit a bit, TV denota el valor de destino, y 8 indica el tamaño en bits de la salida.

[0112] Sobre esta base, el compresor reemplaza el componente de datos con el marcador que especifica la especificación indicada anteriormente, y un nuevo valor de datos que corresponde a un desplazamiento binario a la izquierda de los datos especificados en la referencia de campo. Cuando el mensaje de datos llega al procesador de recepción, el marcador es extraído, y en respuesta, la especificación indicada anteriormente se aplica al mensaje de datos. La operación de JavaScript en el campo de operador de coincidencia es llamada y evaluada del mismo modo que en el lado de transmisión, y la operación de JavaScript es llamada en la instrucción de procesamiento, y en este caso, el valor 0b1110000 del valor de destino se incorpora en un mensaje de datos reconstituido.

[0113] Las operaciones triviales de JavaScript se han descrito anteriormente por medio de ejemplo en aras de sencillez, no obstante, cabe apreciar entonces que cualquier operación o secuencia de operaciones puede estar definida de esta manera.

[0114] Como se menciona anteriormente, en algunos casos, el marcador puede constituir información más allá de la contenida en el mensaje de datos. Como se ha explicado con referencia a los elementos 470 y 490 de la figura 4, esta información puede ser añadida al mensaje de datos por medio del procesador de recepción. En otras realizaciones, la información se puede añadir al mensaje de datos en el lado de transmisión.

[0115] Así como los lenguajes de programación estándar tal y como se ha discutido anteriormente, los procesadores de transmisión o de recepción puede estar configurados para soportar directamente una serie de operaciones de procesamiento. Por ejemplo:

• Delta(x) cuando se puede añadir o sustraer un valor,

• Funciones lógicas como AND, OR, XOR, NOT. Por ejemplo: se puede suponer que el operador de coincidencia para la versión IP NOT 6 devuelve 4.

• f(x)=learning(x) donde el primer mensaje llenará el valor correcto.

• Aprender los valores posibles de la aplicación LPWAN que pueden estar en un rango conocido, por ejemplo, la temperatura en una habitación puede iterar entre 19 y 22 grados, por lo que se sabe que el valor de destino es este rango, el operador de coincidencia es "incluir" y la instrucción de procesamiento puede no enviarse, o enviarse delta(x)

[0116] Cabe apreciar que estas operaciones se pueden implementar en las entradas de valor de destino o de operador de coincidencia, en cuyo caso se puede esperar una salida booleana, mientras que se implementa para la entrada de la instrucción de procesamiento, se puede esperar que devuelvan un valor.

[0117] La figura 6 muestra una variante del procesamiento del lado de transmisión como se presenta con respecto a la figura 4;

[0118] La figura 6 reproduce los elementos del lado de transmisión 400, 410, 411,412, 420, y 450 sustancialmente como se describen con referencia a la figura 4. En el caso de la figura 6, sin embargo, en el paso de reemplazo del componente de datos 412 por un marcador asociado con el primer tipo de componente de datos, el marcador es 633 es añadido al mensaje de datos fuera de la estructura del paquete de datos 630.

Uso de un marcador para hacer referencia a un repositorio centralizado

[0119] Tal y como se describe anteriormente, un marcador asociado con una especificación de una operación de procesamiento se puede utilizar para definir la derivación de un componente de datos de una fuente de datos. Cabe observar que una fuente de datos común puede ser empleada por varios dispositivos sobre esta base. Por ejemplo, como un mensaje de datos pasa desde el dispositivo transmisor, a través de una serie de nodos de red al dispositivo receptor, cada dispositivo y cada nodo podrían analizar el mensaje de datos y acceder a una sola fuente de datos para recuperar el componente de datos. De manera similar, los mensajes podrían ser enviados a varios dispositivos receptores, haciendo cada mensaje referencia a la misma fuente de datos como la fuente de un componente de datos común a esos mensajes.

[0120] Las solicitudes posibles de este enfoque pueden incluir la incorporación de información adicional relacionada con la gestión de dispositivos o seguridad. Los ejemplos incluyen identificar el procesador de transmisión, añadiendo una cookie para introducir un estado en el procesador, autenticar el procesador de transmisión, o añadir un número de secuencia.

[0121] Esto puede verse como la definición de un contexto externo a la especificación que garantiza un comportamiento global para el sistema. Esto se puede utilizar para generar un valor o llamar a otra función (compresión/procesamiento).

[0122] En concreto, el componente de datos puede ser una suma de verificación de fragmentación, y la fuente puede ser una calculadora de suma de verificación adaptada para devolver una suma de verificación correspondiente.

[0123] Por ejemplo, en IPv4, el identificador para la fragmentación puede ser generado por el descompresor y debe ser diferente para cada paquete, en IPv6, la etiqueta de flujo puede ser generada por el descompresor, pero debe mantenerse igual para un flujo. Para un ID de mensaje CoAP tenemos el mismo comportamiento que para el id de fragmentación IPv4.

Firma de carga útil

[0124] Esta instrucción de procesamiento puede utilizarse para añadir una firma que cubre todo el mensaje junto con el ID de regla. La instrucción de procesamiento se puede aplicar además de la operación de reemplazo en el transmisor o en el receptor, por ejemplo, después de que se haga la compresión/descompresión, y puede constituirse antes de enviar el mensaje SCHc . Esta referencia de campo se añade para computar la firma y no es parte del mensaje.

[0125] La línea de instrucción de campo es siempre verdadera en la etapa de prueba para determinar si la especificación es aplicable o no en vistas del operador de coincidencia “ignorar”. Suponiendo que se aplica esta especificación, la instrucción de procesamiento añade una función de firma criptográfica, como un hash, al residuo del encabezado comprimido, que admite la autenticación del compresor. Cuando el mensaje de datos llega al procesador de recepción, el marcador es extraído, y en respuesta, la especificación indicada anteriormente se aplica al mensaje de datos. El receptor hace lo contrario y verifica el hash. Si el hash no es correcto, se descarta la trama. La función de firma criptográfica puede derivar una firma de cualesquiera datos de entrada, incluida la totalidad del mensaje de datos, o alguna parte de este. Por ejemplo, la función de firma criptográfica puede derivar una firma de campos específicos, o la salida de las líneas de instrucción precedentes de la misma especificación.

[0126] Como tal, de acuerdo con el método de las figuras 2 o 3, el marcador puede además comprender una versión cifrada del componente de datos. Sobre esta base, el método de la figura 3 puede comprender el paso adicional de emplear la clave de cifrado para descifrar la versión cifrada del componente de datos.

Ping de gestión local

[0127]

[0128] La regla describe los encabezados IPv6 y el encabezado ICMPv6 de la forma habitual y se añade un campo comp.ping al final de la descripción. Cuando llega un paquete, se comparan cada uno de los campos con la descripción de campo y si todos campos coinciden, luego se selecciona la regla. Cabe señalar que el Compute.ping es un ejemplo de un caso donde la entrada de ID de campo no resuelve en un campo del mensaje de datos, y como tal puede no ser útil en la comparación convencional de un campo. A modo de ejemplo, aquí mostramos una solicitud de eco (ICMPv6 tipo 128, código 0) que necesita una respuesta, por lo que el Comp.Ping responderá a este ping.

[0129] Cuando el procesador de recepción recibe un mensaje que proviene de Internet, si la coincidencia es correcta, la especificación se selecciona de la forma habitual. Esto conlleva la ejecución de la instrucción de procesamiento de la respuesta-ping. Esta instrucción de procesamiento genera una respuesta ping y la envía al solicitante. La instrucción de procesamiento para todos los campos (excepto el comp.ping) se establece como no enviada, para que no se generen datos residuales. La instrucción de procesamiento para comp.ping se establece como una acción (respuesta ping). Esta acción recibirá como argumento el paquete original que desencadena la selección de la regla. Esta acción constituye una respuesta ping con los parámetros adecuados (es decir, invierte la posición de las direcciones de origen y destino y cambia el código icmpv6 para responder). Esta respuesta se devuelve al solicitante del ping y se informa al compresor primario de que el marcador no debe ser enviado.

[0130] Las funciones DEViid y APPiid tal y como se discuten, por ejemplo, en LPWAN Static Context Header Compression (SCHC) for IPv6 and UDP (drafí-ietf-Ipwan-ipv6-static-context-hc-04) se utilizan para procesar respectivamente los identificadores de la interfaz del dev y de la app (Deviid y Appiid) de las direcciones IPv6. El valor de IID se puede computar a partir del ID de dispositivo presente en el encabezamiento de capa 2. El cómputo es específico para cada tecnología LPWAN y depende del tamaño del ID de dispositivo. En la dirección descendente, se pueden emplear para determinar las direcciones L2 utilizadas por la LPWAN.

Uso de marcadores para indicar protocolos encapsulados

[0131] Una primera regla describe campos IPv6 y UDP. Entonces se añade un campo comp.SCHC.

[0132] Cuando llega un paquete, se compara cada uno de los campos con la descripción de campo y si todos campos coinciden, se selecciona la regla a continuación. Cabe señalar que el Compute.ping es un ejemplo de un caso donde la entrada de ID de campo no resuelve en un campo del mensaje de datos, y como tal puede no ser útil en la comparación convencional de un campo. La instrucción de procesamiento para todos los campos (excepto comp.SCHC) se establece en la acción apropiada que puede producir algún valor residual. Entonces, el SCHC es llamado repetidamente con los campos de encabezado restantes, digamos que solo CoAP. Se realiza la coincidencia y se puede encontrar una regla que comprime CoAP. En ese caso, se proporciona un marcador, así como residuos. La concatenación del marcador y el residuo se envían mediante la compresión de primer nivel, y dado que este campo se describe como variable, precedido por la longitud. El receptor recibe el mensaje comprimido. Aplica la regla para recuperar los campos IPv6 y UDP y llamar de nuevo al descompresor SCHC en el valor opaco para descomprimir los campos restantes.

[0133] En el ID de campo podemos añadir carga útil, por ejemplo, mediante un proceso de aprendizaje. En la aplicación LPWAN, donde la mayor parte del uso es para sensores, podemos aportar rápidamente algunos modos de aprendizaje o compresión de la carga útil. Si se desea poner una carga útil más global de la aplicación, la carga útil puede ser procesada como un protocolo, a fin de aprender los valores posibles de la aplicación LPWAN que pueden estar en un rango, por ejemplo, de temperatura conocido, en una habitación, que puede iterar entre 19 y 22 grados, de manera que el valor de destino se puede establecer como equivalente a este rango, el operador de coincidencia es incluir y la instrucción de procesamiento puede estar no enviada, o enviada delta(x).

[0134] El descompresor llama a la instrucción de procesamiento en el valor transmitido para procesar la información. Esto puede llevar a rechazar la trama o a memorizar la información o a cualquier otro tratamiento.

[0135] En algunos casos, los enfoques generales, como el de la figura 1 pueden fallar porque el procesador de transmisión y/o de recepción no es capaz de interpretar un mensaje de datos, e identificar campos en este, por ejemplo, porque está codificado de acuerdo con un protocolo que no está admitido por el mecanismo primario de compresión/descompresión del procesador de transmisión y/o de recepción, p. ej., como se describe anteriormente. Dado que los enfoques como el de la figura 1 a se basan en la posibilidad de definir campos para procesamiento, ningún mecanismo está disponible para tratar estos mensajes anómalos. Mientras que, como se ha explicado con respecto a la figura 1, se supone que la referencia de campo de cada línea de instrucción de campo corresponde generalmente a un campo del mensaje de datos, tal y como se designa en la referencia de campo, en ciertas realizaciones la referencia de campo puede utilizarse para otros fines. En concreto, cuando se proporciona una entrada de referencia de campo que no designa de forma válida un campo del mensaje de datos, se puede suponer que lleva a cabo alguna otra función. Por ejemplo, cuando se determina que un mensaje de datos cumple con un protocolo distinto al protocolo admitido directamente por el mecanismo primario de compresión/descompresión del procesador de transmisión y/o del procesador de recepción, puede proporcionarse una indicación de la identidad del protocolo no admitido en una entrada de campo de una línea de instrucción de campo, que cuando se aplica en el lado del receptor puede utilizarse para dirigir el contenido en cuestión a un decodificador externo adecuado. Ejemplos de este enfoque general del uso de la línea de instrucción de campo, tal como se presenta aquí, incluyen el id del protocolo, la firma de la carga útil, el proceso de ping y el tratamiento de protocolos alternativos (GHC, RoHC, VJ)

[0136] Por ejemplo, se puede considerar una especificación según las siguientes líneas.

[0137] En este ejemplo, el IPv6 y UDP se comprimen de acuerdo con un mecanismo de compresión/descompresión primario, tal y como se describe anteriormente, mientras que partes del resto de los encabezados de los protocolos se comprimen con un mecanismo secundario, p. ej., en el caso del RTP, podría hacerse mediante el uso del formalismo RoHC.

[0138] La regla describe los encabezados IPv6 y el encabezado UDP de la forma habitual (p. ej., línea por línea, evaluando el operador de coincidencia, y después de la coincidencia, ejecutando la instrucción de procesamiento), con la instrucción de procesamiento comp.RoHC cubriendo parte del mensaje, en este ejemplo, los encabezados finales del protocolo.

[0139] Cuando llega un paquete, se comparan cada uno de los campos con la descripción de campo y si todos campos coinciden, luego se selecciona la regla. Cabe señalar que el Compute.ping es un ejemplo de un caso donde la entrada de ID de campo no resuelve en un campo del mensaje de datos, y como tal puede no ser útil en la comparación convencional de un campo.

[0140] La instrucción de procesamiento para todos los campos (excepto comp.rohc) se establece en la acción apropiada que puede producir algún valor residual. La instrucción de procesamiento para comp.rohc se establece en una acción (compresión rohc). Esta acción recibirá como argumento el paquete original que desencadena la selección de la regla. La acción consiste en aplicar la compresión secundaria, siguiendo el algoritmo RoHC. Cabe apreciar que esta acción puede crear un estado específico (esto es, información almacenada) que será reutilizado por la acción de compresión RoHC para procesar mensajes futuros. El resultado se devuelve al mecanismo de compresión/descompresión primario, que lo enviará como un valor opaco, es decir, un valor que no tiene significado/interpretación/semántica para el mecanismo de procesamiento primario, sino que solo podrá ser interpretado por algún otro mecanismo. Por ejemplo, el valor MSLKQSLDKQ puede ser opaco para el mecanismo de procesamiento primario, pero puede representar una codificación que tiene todo el sentido para el RoHC. Nótese que la descripción de campo comp.RoHC puede establecerse como variable para indicar la longitud del valor opaco.

[0141] El receptor recibe un encabezado comprimido con un marcador. El marcador contribuye a encontrar la regla y los campos son procesados respecto a la regla. Los campos del IPv6 y UDP son recuperados al utilizar el mecanismo de compresión/descompresión primario. Después, el valor opaco se da a la acción de compresión RoHC. Se utiliza el algoritmo de descompresión RoHC se utiliza y se recuperan los valores de un campo. Se añaden a la descripción de campo sin comprimir que se utilizará para reconstruir el mensaje original.

[0142] La línea de instrucción de campo es siempre verdadera en la etapa de probar para determinar si la especificación es aplicable o no en vistas del operador de coincidencia “ ignorar”. Suponiendo que entonces se aplica esta especificación, la instrucción de procesamiento remite el residuo no procesado tal y como es definido por el valor de destino incluir(x) a un compresor RoHC correspondiente a la referencia de campo 142 que aparece en la referencia de campo. (Comp.RoHC es la referencia de RoHC). Cada protocolo IETF posee un ID de referencia, que identifica el protocolo utilizado, véase https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml, estos números podrían ser utilizados para incluir diferentes protocolos para ser procesados en el Comp.Protocol. El número IANA identifica protocolos del IETF, estos números son conocidos y se pueden utilizar en la invención para identificar los diferentes protocolos que han de ser computados a fin de comprimir una pila de encabezado completo. En general, la primera columna de la tabla se puede utilizar para identificar los campos de encabezado del mensaje, pero también el proceso de carga útil, los datos y protocolos que no pertenecen al encabezado original, pero que contribuirán a reducir su tamaño. En el caso del protocolo uno puede tener: Comp. RoHC, Comp.VJ, Comp.RoHCv2, Comp.SogComp;, Comp.DTLS, Comp.IPSec, etc.

[0143] Cuando el mensaje de datos llega al procesador de recepción, el marcador es extraído, y en respuesta, la especificación indicada anteriormente se aplica al mensaje de datos. El receptor repite la operación remitiendo el descompresor RoHC no procesable correspondiente a la referencia de campo comp.RoHC que aparece en la referencia de campo, y llamando de nuevo al resultado a través del campo de valor de destino para su incorporación en el mensaje de datos de salida.

[0144] Otro ejemplo consiste en utilizar una función de compresión genérica, como DEFLATE (como se utiliza en ZIP). En este caso, se puede proporcionar también un diccionario inicial para la función de compresión/descompresión. Cabe señalar que esto también es pertinente para la carga útil de la aplicación. Por ejemplo, uno puede llevar a cabo la compresión sin pérdida, así como la compresión con pérdida, como JPEG en la carga útil.

[0145] Por ejemplo, se puede considerar una especificación según las siguientes líneas:

[0146] La regla describe los encabezados IPv6 y el encabezado UDP de la forma habitual (p. ej., línea por línea, evaluando el operador de coincidencia, y después de la coincidencia, ejecutando la instrucción de procesamiento), con la instrucción de procesamiento comp.DEFLATE cubriendo parte del mensaje, en este ejemplo, los encabezados finales del protocolo.

[0147] Esto también se puede utilizar para instancias encapsuladas de compresión de acuerdo con realizaciones tal y como se describen en la presente memoria, de manera que se pueden contemplar múltiples aplicaciones recursivas de las realizaciones, por ejemplo, cuando algunas partes están cifradas, para reducir el número de especificaciones mediante la división de la especificación en varias partes. También puede ser útil para OSCORE, donde se definen dos encabezados COAP.

Aprendizaje de especificación

[0148] En determinadas realizaciones, las especificaciones pueden indicar al procesador de transmisión o de recepción que algunos de los valores se pueden obtener, refinar o reemplazar, determinar de otro modo a través de un proceso de aprendizaje.

[0149] Este proceso de aprendizaje puede estar basado en muestreo estadístico, redes bayesianas, redes neuronales, algoritmos genéticos, aprendizaje automático, minería de datos, o cualquier otra forma de proceso que tenga en cuenta las características concretas de un flujo de datos determinado, un dispositivo, un supuesto de implementación, unas capacidades del transmisor o receptor y así sucesivamente.

[0150] Como ejemplo, se puede emplear un dispositivo genérico (p. ej., un termómetro) en un edificio de oficinas, donde la temperatura es siempre de aproximadamente 22 grados Celsius. El procesador de transmisión o de recepción puede utilizar cualquiera de los algoritmos anteriormente mencionados para determinar, después de varios días de trabajo, si el valor “22” requiere compresión mejorada y asignar una nueva especificación específicamente para él. El mismo dispositivo, empleado en una fábrica, puede enviar temperaturas en el rango de 30-35 grados, en cuyo caso, la compresión de la carga útil se optimizaría para este rango.

[0151] El algoritmo de aprendizaje puede ser simétrico, p. ej., tanto el emisor como el receptor pueden llevar a cabo el proceso de aprendizaje en su lado. En el ejemplo anterior, el termómetro genérico puede hacer que el algoritmo de aprendizaje indique que después de 5 mensajes consecutivos con una temperatura concreta (p. ej., 22 °C), se establecerá una nueva especificación con un marcador igual a 10 en este valor. Esto también ocurre en el receptor que, al observar los 5 valores pasados, aprende que el valor para el marcador =10 debe establecerse en 22 °C.

[0152] El proceso también puede ser asimétrico, que es por lo que puede existir la necesidad de tener un protocolo de señalización, por ejemplo, como se ha señalado anteriormente, que sincronizaría las dos instancias de procesador de transmisión o de recepción. Por ejemplo, la red puede comprender el elemento que proporciona el algoritmo de aprendizaje, que entonces actualiza los valores correspondientes en el dispositivo final.

[0153] Este podría ser el caso para el uso con Comp.DEFLATE, donde la RED puede determinar un diccionario DEFLATE mejor y actualizar el del dispositivo final.

[0154] El proceso de aprendizaje puede modificar el estado, que podría tener múltiples implicaciones sobre el proceso de compresión/descompresión, como:

- Activar o desactivar una regla concreta.

° Esto se podría lograr, por ejemplo, disponiendo de un operador de coincidencia que consulte una variable en el estado local. Esta variable puede indicar que el operador de coincidencia es siempre falso (p. ej., la regla nunca coincide) hasta que el proceso de aprendizaje haya alcanzado algún objetivo.

° Esto también podría alcanzarse directamente a través del valor de destino.

- Modificar uno o más de los valores de destino de una o más reglas. Un ejemplo sería tener el ID de regla == 100 desactivado hasta que una dirección IPv6 de destino concreta haya coincidido 5 veces, después de lo que, el valor de destino del ID de regla se volvería igual para esta dirección IPv6 concreta, que activaría la regla con el ID de regla ==100.

[0155] Un modo posible de llevar esto a cabo es que el operador de coincidencia realice la fase de aprendizaje y que, cuando se de alguna condición interna, actualice el valor de destino. Esto se podría lograr a través del uso del par de operador de aprendizaje por coincidencia (LMO, por sus siglas en inglés)-valor de destino aprendido (LTV, por sus siglas en inglés), donde el l Mo está actualizando el estado del LTV en la misma línea de la misma regla, o podría ser que un LMO actualice el estado de uno o más LTV de cualquiera de las líneas en cualquiera de las reglas. Además, podría darse el caso de que un LMO pueda llevar a cabo el aprendizaje, lo que puede afectar al estado de cualquiera de las funciones de este C/D. Nótese que el aprendizaje se puede llevar a cabo en cualquier función, p. ej., en las acciones de compresión/descompresión también.

[0156] La figura 6 muestra un algoritmo de aprendizaje de especificación de acuerdo con una realización.

[0157] Como se muestra en la figura 6, el método comienza en el paso 600, antes de proceder al paso 605, en el que se espera el siguiente mensaje de datos.

[0158] Por medio de ejemplo, el método de la figura 6 se describe en un supuesto donde se definen una o más reglas, correspondientes a especificaciones como se describen anteriormente, comprendiendo cada regla una o más líneas de instrucción de campo, comprendiendo cada línea de instrucción de campo un valor de destino y una instrucción de procesamiento.

[0159] Si en el paso 610 se determina que se ha recibido un nuevo mensaje, el método procede al paso 615, en el que se selecciona una primera regla para evaluación. El método entonces avanza al paso 620, en el que la primera línea de instrucción de la regla actualmente seleccionada se considera para evaluación. Si la región especificada del mensaje de datos corresponde al valor de destino de una manera prescrita respectiva, p. ej., si el valor de campo coincide con el valor de destino, el método avanza al paso 640, en el que se determina si la línea de instrucción actualmente considerada es la última. En caso de que se haya determinado en el paso 640 que se la línea de instrucción actualmente considerada es la última, el método avanza al paso 645, en el que se determina si la regla actualmente considerada es la última. En caso de que se haya determinado en el paso 645 que la regla actualmente considerada es la última, el método procesa el paquete de datos de acuerdo con la regla coincidente del modo habitual, como se trata con referencia a la figura 1 , antes de volver al paso 605. En caso de que se haya determinado en el paso 640 que la línea de instrucción actualmente considerada no es la última, el método avanza al paso 650, en el que se selecciona la siguiente línea de instrucción, antes de volver al paso 625. En caso de que se haya determinado en el paso 645 que la regla actualmente considerada no es la última, el método avanza al paso 655, en el que se selecciona la siguiente regla, antes de volver al paso 615. De este modo, el método itera a través de todos los campos de todas las reglas a fin de encontrar la regla coincidente como se trata con referencia a la figura 1. En caso de que la región especificada del mensaje de datos no corresponda al valor de destino de una primera manera prescrita respectiva en el paso 625, p. ej., si el valor de campo coincide con el valor de destino, el método avanza al paso 630, en el que se determina si la región especificada del mensaje de datos corresponde al valor de destino de una segunda manera prescrita respectiva, p. ej., según determina el operador de aprendizaje por coincidencia como se presenta anteriormente. Por ejemplo, el mensaje de datos puede desviarse del valor de destino dentro de un rango concreto. Cuando este sea el caso, el método avanza al paso 635 en el que un valor de aprendizaje que indica el número de veces que la región especificada del mensaje de datos ha correspondido al valor de destino de la segunda manera prescrita respectiva. El método, a continuación, procede al paso 636, en el que se determina si el valor de aprendizaje supera un umbral, y en caso de que se supere el umbral, la primera manera prescrita de la línea de instrucción considerada es actualizarse, por ejemplo, para que coincida con la segunda manera prescrita antes de volver al paso 640. Si se da que el valor de aprendizaje no supera el umbral en el 635, el método vuelve directamente al paso 640.

[0160] Como tal, se proporciona un método de procesamiento de una pluralidad de mensajes de datos, donde se definen una o más reglas, comprendiendo cada regla una o más líneas de instrucción de campo, comprendiendo cada una de dichas líneas de instrucción de campo un valor de destino y una instrucción de procesamiento;

comprendiendo el método los pasos adicionales de determinar para una regla si una región especificada respectiva de cada mensaje de datos corresponde al valor de destino de una manera prescrita respectiva, y en el caso de que la región especificada respectiva no corresponda al valor de destino de la manera prescrita respectiva para cada línea de instrucción de campo en una regla respectiva para un número predeterminado de los mensajes de datos, modificando el valor de destino de una manera predeterminada.

[0161] El ejemplo ilustrado en la tabla de anterior muestra cómo podrían funcionar juntos un LTV y un LMO. El experto en la materia observará que esta es una estructura simplificada, y que se pueden añadir columnas adicionales además de los campos de valor de destino, operador de coincidencia e instrucción de procesamiento. Para Field1, el “Learn” del LMO señala una función de aprendizaje, que toma un parámetro, el nombre de los criterios de evaluación ("max5"). Esta función es un operador de coincidencia, que devuelve “verdadero” cuando el proceso de aprendizaje ha logrado rendimiento suficiente (p. ej., cuando se dan los criterios de evaluación) y “falso” en caso contrario. Los criterios de evaluación en este caso podrían indicar que los últimos 5 mensajes contenían el mismo valor. En este supuesto, este valor podría aceptarse como el valor para el valor de destino. Cuando se da el criterio de evaluación, la regla coincidirá con el mensaje de datos, y se invocará la acción de compresión/descompresión para comprimir el mensaje de datos, con el LearnedValue() como entrada. El LearnedValue() devuelve el resultado de la función de aprendizaje, que entonces es procesado por el CDA not-sent-or-sync().

[0162] En este ejemplo, not-sent-or-sync() es una función que tiene en cuenta el estado del EMISOR y del RECEPTOR y hace uso de la existencia de un mecanismo de SEÑALIZACIÓN/CONTROL. Si el estado del EMISOR y RECEPTOR difiere o es desconocido con respecto al valor que debe transmitirse, lo indica en el valor de salida, e invoca potencialmente el protocolo de SEÑALIZACIÓN/CONTROL. Actúa como no enviado siempre que se sepa que el estado tanto del EMISOR como el RECEPTOR respecto al valor que debe enviarse es el mismo (p. ej., a través de intercambios previos). Por ejemplo, esto se podría implementar como que tiene una longitud variable de salida, que siempre que la longitud es 0 indica que no es necesaria la sincronización de los estados, y si es mayor que 0, contiene un marcador de longitud variable estructurado (SVLM, por sus siglas en inglés), que proporciona la actualización del estado necesaria.

[0163] Otro ejemplo es el uso de los diccionarios predefinidos para un algoritmo de compresión genérica, como DEFLATE. Por ejemplo, la RED puede llevar a cabo la actualización del diccionario con el uso intensivo del procesador, y después de alcanzar un criterio determinado (p. ej., 10 % de mejor relación de compresión con el nuevo diccionario en comparación con el actual/genérico), puede enviar el nuevo diccionario para que sea utilizado para la función DEFLATE por el DISPOSITIVO.

[0164] La figura 7 presenta un ejemplo de aprendizaje de especificación mediante comunicaciones de estado de acuerdo con una realización. El supuesto de la figura 7 proporciona una situación que puede ser implementada mediante un método como se describe con referencia a la figura 6. Como se muestra, se produce una serie de comunicaciones 711, 712, 713, 714, 715 entre un primer dispositivo A 700 y un segundo dispositivo B 701. Al principio, la frase de aprendizaje aún no se ha llevado a cabo.

[0165] A es un nodo con una identidad (aa-bb-vvvvv-yyyyy), esta identidad no es conocida en la creación de la regla y se puede definir de manera dinámica. A posee dos reglas definidas, una que porta la identidad y otra sin ella. Imaginemos un protocolo muy simple que envía la identidad y el valor. Las reglas pueden definirse como sigue:

Regla A1

Regla A2

B es un descompresor que necesita aprender la identidad del dispositivo A. B posee dos reglas definidas (B1 y B2) que tienen el mismo contenido, pero B1 se utiliza cuando se desconoce la identidad de A y B2 se utiliza cuando se conoce la identidad de A.

Regla B1

Regla B2

[0166] El dispositivo A 700 recibe mensajes 711, 712 del dispositivo B 701 comprimidos con la especificación B1 y luego descomprimidos de acuerdo con una la especificación A 1. Desde que la especificación B1 solicita una confirmación, el dispositivo A 700 responde con un mensaje 713, también comprimido con la especificación A1 y luego descomprimido de acuerdo con la especificación B1. Este mensaje 713 contiene los campos de ID y valor tal y como se transmiten de acuerdo con la especificación A1. Cuando el procesador de recepción del dispositivo B recibe esto, puede conocer el ID del dispositivo B. Sobre esta base, el dispositivo B puede enviar su siguiente comunicación 714 que utiliza la especificación B2, que no solicita una confirmación. Sobre esta base, el dispositivo A puede seleccionar la especificación A2 para sus siguientes comunicaciones 715, que no incluye información de ID que, por lo tanto, aumenta el grado de comprensión de las comunicaciones en curso.

[0167] Si el dispositivo B 701 se reinicia, puede volver a la especificación inicial y entonces el dispositivo A 700 tendrá que reenviar la información de aprendizaje. Si el dispositivo A 700 cambia su información de aprendizaje, también puede volver a la regla 1.

[0168] Como se ha tratado anteriormente, los mensajes de datos, como los paquetes de datos en un formato IPv4 o IPv6, se procesan en vistas a la compresión/descompresión, utilizando información obtenida de fuentes distintas al propio paquete de datos, o al flujo al que pertenece. Esto puede implicar procesamiento dinámico adicional, definido en las especificaciones identificadas por un marcador compartido, u obtenidas de una fuente de datos adicional, como un archivo estático, una aplicación de base de datos o similares. Las realizaciones descritas en la presente memoria mejoran este enfoque con una determinación dinámica de los componentes de datos.

[0169] Las realizaciones de software incluyen, pero no se limitan a, aplicaciones, firmware, software residente, microcódigo, etc. La invención puede adoptar la forma de un producto de programa de ordenador accesible desde un medio utilizable por ordenador o legible por ordenador que proporciona un código de programa para su uso por o en conexión con un ordenador o un sistema de ejecución de instrucciones. Las realizaciones de software incluyen software adaptado para implementar los pasos analizados anteriormente con referencia a las figuras 1 a 4. Un medio utilizable por ordenador o legible por ordenador puede ser cualquier aparato que pueda contener, almacenar, comunicar, propagar o transportar el programa para su uso por o en conexión con el sistema, aparato o dispositivo de ejecución de instrucciones. El medio puede ser un sistema (o aparato o dispositivo) electrónico, magnético, óptico, electromagnético, infrarrojo o semiconductor, o un medio de propagación.

[0170] En algunas realizaciones, los métodos y procesos descritos en la presente memoria pueden ser implementados en su totalidad o en parte por un dispositivo de usuario. Estos métodos y procesos pueden ser implementados por programas o servicios de aplicación informática, una interfaz de programación de aplicaciones (API), una biblioteca y/u otro producto de programa de ordenador, o cualquier combinación de dichas entidades.

[0171] El dispositivo de usuario puede ser un dispositivo móvil, como un teléfono inteligente o una tableta, un dron, un ordenador o cualquier otro dispositivo con capacidad de procesamiento, como un robot u otro dispositivo conectado, incluidos los dispositivos IoT (Internet de las cosas).

[0172] La figura 8 muestra un sistema informático genérico adecuado para la implementación de realizaciones de la invención.

[0173] Como se muestra en la figura 8, un sistema incluye un dispositivo lógico 801 y un dispositivo de almacenamiento 802. El sistema puede, opcionalmente, incluir una interfaz de visualización 804 y una pantalla 811, un subsistema de entrada/salida 803, un subsistema de comunicación 820 y/u otros componentes no mostrados.

[0174] El dispositivo lógico 801 incluye uno o más dispositivos físicos configurados para ejecutar instrucciones. Por ejemplo, el dispositivo lógico 801 puede estar configurado para ejecutar instrucciones que forman parte de una o más aplicaciones, servicios, programas, rutinas, bibliotecas, objetos, componentes, estructuras de datos u otras construcciones lógicas. Tales instrucciones pueden ser implementadas para realizar una tarea, implementar un tipo de datos, transformar el estado de uno o más componentes, lograr un efecto técnico, o llegar a un resultado deseado de otro modo.

[0175] El dispositivo lógico 801 puede incluir uno o más procesadores configurados para ejecutar instrucciones de software. Adicional o alternativamente, el dispositivo lógico puede incluir uno o más dispositivos lógicos de hardware o firmware configurados para ejecutar instrucciones de hardware o firmware. Los procesadores del dispositivo lógico pueden ser de un solo núcleo o de varios núcleos, y las instrucciones ejecutadas en ellos pueden estar configuradas para un procesamiento secuencial, paralelo y/o distribuido. Los componentes individuales del dispositivo lógico 801 pueden ser distribuidos opcionalmente entre dos o más dispositivos separados, que pueden estar localizados remotamente y/o configurados para un procesamiento coordinado. Aspectos del dispositivo lógico 1001 pueden ser virtualizados y ejecutados por dispositivos informáticos en red accesibles remotamente y configurados en una configuración de computación en la nube.

[0176] El dispositivo de almacenamiento 802 incluye uno o más dispositivos físicos configurados para contener instrucciones ejecutables por el dispositivo lógico para implementar los métodos y procesos descritos en la presente memoria. Cuando se implementan dichos métodos y procesos, el estado del dispositivo de almacenamiento 802 puede transformarse, por ejemplo, para contener datos diferentes.

[0177] El dispositivo de almacenamiento 802 puede incluir dispositivos extraíbles y/o integrados. El dispositivo de almacenamiento puede estar almacenado local o remotamente (en una nube, por ejemplo). El dispositivo de almacenamiento 802 puede comprender uno o más tipos de dispositivo de almacenamiento, incluyendo memoria óptica (p. ej., CD, DVD, h D-DVD, Blu-Ray Disc, etc.), memoria de semiconductor (por ejemplo, FLASH, RAM, EPROM, EEPROM, etc.), y/o memoria magnética (por ejemplo, unidad de disco duro, unidad de disquete, unidad de cinta, MRAM, etc.), entre otros. El dispositivo de almacenamiento puede incluir dispositivos volátiles, no volátiles, dinámicos, estáticos, de lectura/escritura, de solo lectura, de acceso aleatorio, de acceso secuencial, direccionables por ubicación, direccionables por archivo y/o direccionables por contenido. En determinadas disposiciones, el sistema puede comprender una interfaz 803 adaptada para admitir comunicaciones entre el dispositivo lógico 801 y otros componentes del sistema. Por ejemplo, los componentes del sistema adicionales pueden comprender dispositivos de almacenamiento extendido extraíbles y/o integrados. Los dispositivos de almacenamiento extendido pueden comprender uno o más tipos de dispositivo de almacenamiento, incluyendo una memoria óptica 832 (por ejemplo, CD, DVD, HD-DVD, Blu-Ray Disc, etc.), una memoria de semiconductor 833 (por ejemplo, RAM, EPROM, EEPROM, FLASH, etc.), y/o una memoria magnética 831 (por ejemplo, unidad de disco duro, unidad de disquete, unidad de cinta, MRAM, etc.), entre otros. Dicho dispositivo de almacenamiento extendido puede incluir dispositivos volátiles, no volátiles, dinámicos, estáticos, de lectura/escritura, de solo lectura, de acceso aleatorio, de acceso secuencial, direccionables por ubicación, direccionables por archivo y/o direccionables por contenido.

[0178] Cabe observar que el dispositivo de almacenamiento incluye uno o más dispositivos físicos, y excluye la propagación de señales per se. Sin embargo, algunos aspectos de las instrucciones descritas en la presente memoria pueden ser propagados alternativamente por un medio de comunicación (por ejemplo, una señal electromagnética, una señal óptica, etc.), en lugar de ser almacenados en un dispositivo de almacenamiento.

[0179] Algunos aspectos del dispositivo lógico 801 y del dispositivo de almacenamiento 802 pueden integrarse juntos en uno o más componentes de hardware lógico. Dichos componentes de hardware lógico pueden incluir matrices de puertas programables en campo (FPGA), circuitos integrados específicos de programa y aplicación (PASIC/ASIC), productos estándar específicos de programa y aplicación (PSSP/ASSP), sistema en un chip (SOC), y dispositivos lógicos programables complejos (CPLD), por ejemplo.

[0180] El término "programa" puede utilizarse para describir un aspecto de sistema informático implementado para realizar una función concreta. En algunos casos, un programa puede ser instanciado a través de un dispositivo lógico que ejecuta instrucciones legibles por máquina contenidas en el dispositivo de almacenamiento 802. Se entenderá que diferentes módulos pueden ser instanciados desde la misma aplicación, servicio, bloque de código, objeto, biblioteca, rutina, API, función, etc. Del mismo modo, el mismo programa puede ser instanciado por diferentes aplicaciones, servicios, bloques de código, objetos, rutinas, API, funciones, etc. El término "programa" puede abarcar archivos individuales o grupos de archivos ejecutables, archivos de datos, bibliotecas, controladores, scripts, registros de bases de datos, etc.

[0181] En particular, el sistema de la figura 8 puede utilizarse para implementar realizaciones de la invención.

[0182] Por ejemplo, un programa que implementa los pasos descritos con respecto a las figuras 2 a 5, o los algoritmos presentados anteriormente, puede ser almacenado en el dispositivo de almacenamiento 802 y ejecutado por el dispositivo lógico 801. El mensaje de datos y/o el componente de datos pueden ser recibidos y/o transmitidos a través de la interfaz de comunicaciones 820, y en concreto, a través de la red de radio 874 o de Internet 875. El contexto o las especificaciones individuales pueden recibirse y/o transmitirse a través de la interfaz de comunicaciones 820 y, en particular, a través de la red de radio 874 o de Internet 875. El mensaje de datos, y/o el componente de datos puede ser almacenado en un buffer o de otra manera en el dispositivo de almacenamiento 802, 831, 832, 833. El contexto o las especificaciones individuales pueden almacenarse en el dispositivo de almacenamiento 802, 831, 832, 833. El mensaje de datos y/o el componente de datos puede ser usuario Las funciones de cualquiera o de todas las unidades 420, 470, o de cualquiera o de todas sus respectivas subunidades, pueden ser implementadas de forma similar por un programa que realiza las funciones requeridas, en comunicación con unidades de hardware dedicado adicionales, según sea necesario. Por lo tanto, la invención puede ser incorporada en la forma de un programa de ordenador.

[0183] Cabe observar que un "servicio", tal y como se utiliza aquí, es un programa de aplicación ejecutable a través de múltiples sesiones de usuario. Un servicio puede estar disponible para uno o más componentes del sistema, programas y/u otros servicios. En algunas implementaciones, un servicio puede ejecutarse en uno o más dispositivos informáticos de servidor.

[0184] Cuando se incluye, el subsistema de visualización 811 puede utilizarse para presentar una representación visual de los datos contenidos en un dispositivo de almacenamiento. Esta representación visual puede adoptar la forma de una interfaz gráfica de usuario (GUI). A medida que los métodos y procesos descritos en la presente memoria cambian los datos contenidos en el dispositivo de almacenamiento 802 y, por lo tanto, transforman el estado del dispositivo de almacenamiento 802, el estado del subsistema de visualización 811 puede transformarse igualmente para representar visualmente cambios en los datos subyacentes. El subsistema de visualización 811 puede incluir uno o más dispositivos de visualización que utilizan virtualmente cualquier tipo de tecnología, por ejemplo, como se analizó anteriormente. Dichos dispositivos de visualización pueden combinarse con un dispositivo lógico y/o un dispositivo de almacenamiento en un contenedor compartido, o dichos dispositivos de visualización pueden ser dispositivos de visualización periféricos. También puede proporcionarse una salida de audio, como un altavoz 814.

[0185] Cuando se incluye, el subsistema de entrada puede comprender o interactuar con uno o más dispositivos de entrada de usuario, como un teclado 812, un ratón 813, una pantalla táctil 811 o un controlador de juegos (no mostrado). En algunas realizaciones, el subsistema de entrada puede comprender o interactuar con componentes seleccionados de entrada natural de usuario (NUI). Dichos componentes pueden ser integrados o periféricos, y la transducción y/o el procesamiento de las acciones de entrada pueden ser manejados a bordo o no. Algunos ejemplos de componentes de NUI pueden incluir un micrófono 815 para el reconocimiento del habla y/o de la voz; una cámara de infrarrojos, de color, estereoscópica y/o de profundidad 816 para la visión artificial y/o el reconocimiento de gestos; un rastreador de cabeza, un rastreador de ojos, un acelerómetro y/o un giroscopio para la detección del movimiento y/o el reconocimiento de la intención; así como componentes de detección de campo eléctrico para evaluar la actividad cerebral. La interfaz de entrada/salida 803 puede interactuar igualmente con un altavoz 814, un motor vibratorio o cualquier otro dispositivo transductor que se le ocurra al experto en la materia. Por ejemplo, el sistema puede interactuar con una impresora 817.

[0186] Cuando se incluye, el subsistema de comunicación 820 puede estar configurado para acoplar de manera comunicativa el sistema informático con uno o más dispositivos informáticos. Por ejemplo, el módulo de comunicación de acoplar de manera comunicativa el dispositivo informático a un servicio remoto alojado, por ejemplo, en un servidor remoto 876 a través de una red de cualquier tamaño, incluyendo, por ejemplo, una red de área personal, una red de área local, una red de área amplia, o Internet. El subsistema de comunicación puede incluir dispositivos de comunicación por cable y/o inalámbricos compatibles con uno o varios protocolos de comunicación diferentes. Como ejemplos no limitativos, el subsistema de comunicación puede estar configurado para la comunicación a través de una red telefónica inalámbrica 874, o una red de área local o de área amplia por cable o inalámbrica. En algunas realizaciones, el subsistema de comunicación puede permitir que el sistema informático envíe y/o reciba mensajes hacia y/o desde otros dispositivos a través de una red como Internet 875. El subsistema de comunicaciones puede admitir además comunicaciones inductivas de corto alcance con dispositivos pasivos o activos (NFC, RFID, UHF, etc.). En determinadas variantes de las realizaciones descritas anteriormente, los datos de tráfico pueden recibirse a través de la red de radio 874 o de Internet 875.

[0187] El sistema de la figura 8 pretende reflejar una amplia gama de diferentes tipos de sistemas de gestión de información. Cabe observar que muchos de los subsistemas y características descritos con respecto a la figura 8 no son necesarios para la implementación de la invención, pero se incluyen para reflejar posibles sistemas de acuerdo con la presente invención. Cabe observar que las arquitecturas de sistema varían ampliamente, y la relación entre los diferentes subsistemas de la figura 8 es meramente esquemática, y es probable que varíe en términos de disposición y distribución de funciones en los sistemas. Cabe observar que, en la práctica, es probable que los sistemas incorporen diferentes subconjuntos de las diversas características y subsistemas descritos con respecto a la figura 8.

[0188] Entre los ejemplos de dispositivos que comprenden al menos algunos elementos del sistema descrito con referencia a la figura 8 y que son adecuados para implementar realizaciones de la invención se incluyen los teléfonos móviles, incluidos los teléfonos inteligentes, y los sistemas de navegación de vehículos, los sensores distribuidos, los electrodomésticos inteligentes, los equipos de infraestructura industrial conectados, las implementaciones o los componentes de ciudades inteligentes, las implementaciones o los componentes de consumo de energía inteligente, la búsqueda de artículos o personas, los servicios médicos y de emergencia, la agricultura, los sensores vestibles para humanos y otras especies, etc.

[0189] La figura 8 muestra un dispositivo de sensor independiente adaptable para constituir una realización. El dispositivo de sensor independiente 800 de la figura 8 puede representar un componente típico del "Internet de las cosas". Dichos dispositivos suelen estar sometidos a limitaciones significativas en términos de ancho de banda de comunicaciones, consumo de energía, capacidad de procesamiento y de memoria y, de este modo, pueden beneficiarse de muchos de los mecanismos presentados en el análisis anterior. Como se muestra en la figura 8, el dispositivo de sensor independiente incorpora unos elementos 801, 802, 803, 820 y un dispositivo de sensor 860. Está en comunicación con la red de radio 874 y un servidor 876 a través de la red 875. También pueden utilizarse mecanismos de comunicación alternativos, tal como una red dedicada o wifi.

[0190] Tal y como se muestra, el dispositivo de sensor es un sensor de temperatura. No obstante, cabe observar que podría igualmente incorporar cualquier otro tipo de sensor u otro transductor, o una pluralidad de transductores adecuados para la función del dispositivo.

[0191] 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.

Claims

REIVINDICACIONES

1. Método de procesamiento de un mensaje de datos (430) recibido en un procesador de recepción (460), comprendiendo dicho método los pasos de extraer un marcador (433) asociado con un primer tipo de componente de datos a partir de dicho mensaje de datos (430), que determina una operación de procesamiento definida para dicho marcador (433) en una especificación designada por dicho marcador (433), y en respuesta a dicha determinación, derivar un componente de datos adicional (471) por medio de dicha operación de procesamiento con respecto a una fuente de datos (463) externa a dicho procesador de recepción (460) distinto de un flujo de datos asociado a dicho mensaje de datos, donde se definen una o más reglas, comprendiendo cada una de dichas reglas una o más líneas de instrucción de campo, comprendiendo cada línea de instrucción de campo un valor de destino y una instrucción de procesamiento;

comprendiendo dicho método los pasos adicionales de determinar para una de dichas reglas si una región especificada respectiva de dicho mensaje de datos corresponde a dicho valor de destino de una manera prescrita respectiva, y en el caso de que dicha región especificada respectiva corresponda a dicho valor de destino de dicha manera prescrita respectiva para cada línea de instrucción de campo en una dicha regla respectiva, aplicando la instrucción de procesamiento de cada línea instrucción de campo en dicha regla correspondiente con respecto a la región especificada respectiva, donde dicho componente de datos adicional se procesa como define dicha instrucción de procesamiento;

y donde dicho marcador especifica dicha regla.

2. Método de la reivindicación 1 que comprende el paso adicional de reconstituir un componente de datos (412) con dicho componente de datos adicional (471).

3. Método de la reivindicación 1 o 2 que comprende el paso adicional de añadir dicho componente de datos adicional (471) a dicho mensaje de datos (470).

4. El método de la reivindicación 1, 2 o 3 que comprende el paso adicional de almacenar dicho componente de datos adicional (471), y en una iteración adicional del paso de extracción de un marcador asociado con un primer tipo de componente de datos, que recupera dicho componente de datos adicional almacenado en lugar de repetir una interrogación de la fuente de datos (463) asociada con dicho marcador.

5. Método de cualquier reivindicación precedente donde dicha fuente de datos (463) es un servidor DNS y donde dicho marcador indica dicha fuente de datos (463) y una URL, y donde dicho componente de datos adicional es una dirección IP.

6. Método de cualquiera de las reivindicaciones 1 a 5 donde dicha fuente de datos (463) es un servidor DHCP y donde dicha especificación indica dicha fuente de datos (463) y una dirección MAC y donde dicho componente de datos adicional es una dirección IP.

7. Método de cualquiera de las reivindicaciones 1 a 5 donde dicha fuente de datos (463) es un servidor de clave de cifrado adaptado para devolver una clave de cifrado de una entidad especificada, y donde dicha especificación indica dicha fuente de datos (463) y dicha entidad especificada.

8. Método de la reivindicación 7 donde dicho marcador además comprende una versión cifrada de dicho componente de datos, comprendiendo dicho método el paso adicional de utilizar dicha clave de cifrado recuperada para descifrar dicha versión cifrada de dicho componente de datos.

9. Método de cualquiera de las reivindicaciones 1 a 5 donde dicho componente de datos es una suma de verificación de fragmentación y donde dicha fuente es una calculadora de suma de verificación adaptada para devolver una suma de verificación correspondiente.

10. Programa de ordenador que comprende instrucciones adaptadas para implementar los pasos de cualquiera de las reivindicaciones 1 a 9.

11. Un procesador de recepción (460) para procesar un mensaje de datos recibido (430), estando dicho procesador de recepción (460) adaptado para extraer un marcador (433) asociado a un primer tipo de componente de datos a partir de dicho mensaje de datos (430), para determinar una operación de procesamiento definida para dicho marcador (433) en una especificación designada por dicho marcador (433), y en respuesta a dicha determinación para derivar un componente de datos adicional (417) por medio de dicha operación de procesamiento con respecto a una fuente de datos (463) externa a dicho procesador de recepción (460) distinto de una fuente de datos asociada a dichos datos, donde se definen una o más reglas, comprendiendo cada una de dichas reglas una o más líneas de instrucción de campo, comprendiendo cada una de dichas líneas de instrucción de campo un valor de destino y una instrucción de procesamiento;

comprendiendo dicho método los pasos adicionales de determinar para una de dichas reglas si una región especificada respectiva de dicho mensaje de datos corresponde a dicho valor de destino de una manera prescrita respectiva, y en el caso de que dicha región especificada respectiva corresponda a dicho valor de destino de dicha manera prescrita respectiva para cada línea de instrucción de campo en una de dichas reglas respectivas, que aplica la instrucción de procesamiento de cada línea de instrucción de campo en dicha regla correspondiente con respecto a la región especificada respectiva, donde dicho componente de datos adicional se procesa como define dicha instrucción de procesamiento;

y donde dicho marcador especifica dicha regla.