ES2388637T3

ES2388637T3 - Procedimiento para transmitir mensajes de señalización en una red conmutada por paquetes y red conmutada por paquetes

Info

Publication number: ES2388637T3
Application number: ES08015222T
Authority: ES
Inventors: Muddassir Gohar Khan; Christian Dr. Schwingenschlögl; Andreas Ziller
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2007-09-26
Filing date: 2008-08-28
Publication date: 2012-10-17
Anticipated expiration: 2028-08-28
Also published as: PL2051560T3; WO2009043699A1; EP2051560A1; EP2051560B1

Abstract

Procedimiento para transmitir mensajes de señalización en una red (1) conmutada por paquetes, con lasetapas de:a) proporcionar una red (1) conmutada por paquetes con al menos tres nodos (10-30), teniendo un nodo(30) de retransmisión respectivo al menos una capa (31) de seguridad fiable y una capa (32) de codificaciónde red y teniendo un nodo (10, 20) de envío/recepción respectivo adicionalmente una capa (13, 23) detransporte fiable;b) empaquetar al menos un mensaje de señalización en un paquete (G) de capa de transporte sin codificarrespectivo sin datos de usuario de capa de transporte en un nodo (10) de envío/recepción;c) enviar con prioridad el paquete (G) de capa de transporte sin codificar respectivo a un nodo (30) deretransmisión predeterminado a través del nodo (10) de envío/recepción; yd) retransmitir con prioridad el paquete (G) de capa de transporte sin codificar respectivo a través del nodo(30) de retransmisión.

Description

Procedimiento para transmitir mensajes de señalización en una red conmutada por paquetes y red conmutada por paquetes

La invención se refiere a un procedimiento para transmitir mensajes de señalización en una red conmutada por paquetes y a una red conmutada por paquetes de este tipo.

El campo técnico de la invención se refiere a redes conmutadas por paquetes, como las redes WLAN, que soportan codificación de red.

La codificación de red se conoce por ejemplo por la publicación “Network Information Flow”, Rudolf Ahlswede et al., IE-EE Transactions on Information Theory, vol. 46, n.º 4, julio de 2000. Mediante la utilización de codificación de red se reduce el número de transmisiones necesarias en la red respectiva.

Además se conoce la posibilidad de utilizar codificación de red en una red WLAN por la publicación “XORs in the Air, Practical Wireless Network Coding”, Sachin Katti et al., SIG-COMM 2006, 11 – 15 de septiembre de 2006, Pisa, Italia. Mediante esta solución, denominada a continuación COPE, es posible aplicar codificación de red directamente en una red WLAN. A este respecto se usan habitualmente confirmaciones en diferentes capas o layers. Por ejemplo además de las confirmaciones de capa MAC, que se usan por ejemplo en la norma 802.11, se utilizan confirmaciones de la propia capa de codificación de red.

Además, la capa TCP situada por encima también usa confirmaciones TCP para confirmar que el paquete de datos respectivo ha llegado al nodo de destino, como se da a conocer por ejemplo en el documento US 6757738. A este respecto las confirmaciones TCP representan una posibilidad para optimizar el rendimiento del sistema. Habitualmente el nodo de destino o el nodo de recepción envía una confirmación TCP o un paquete de confirmación TCP al nodo de origen, para confirmar la transmisión satisfactoria. En caso de que el nodo de origen o el nodo de envío en un periodo de tiempo predeterminado no reciba tal confirmación TCP, el paquete correspondiente debe volver a transmitirse de manera desventajosa al nodo de destino. Además el protocolo TCP puede reaccionar en caso de una pérdida de paquete con una disminución de la tasa de transmisión de datos.

Para ilustrar el uso de diferentes confirmaciones de diferentes capas en la transmisión de un segmento D de datos TCP, las figuras 1 y 2 muestran un diagrama de bloques esquemático de una red 1 con dos nodos 1 y 2 de envío/recepción y un nodo 3 de retransmisión que acopla los dos nodos 1 y 2 de envío/recepción.

El nodo 3 de retransmisión tiene al menos una capa 31 de seguridad fiable y una capa 32 de codificación de red.

Por el contrario, el primer nodo 10 de recepción y el segundo nodo 20 de recepción tienen en cada caso al menos una capa 11, 21 de seguridad fiable, una capa 12, 22 de codificación de red y adicionalmente una capa 13, 23 de transporte fiable.

En particular las figuras 1 y 2 muestran las transmisiones necesarias incluyendo las confirmaciones necesarias para el envío de un segmento D de datos TCP desde el primer nodo 10 de envío/recepción a través del nodo 30 de retransmisión al segundo nodo 20 de envío/recepción.

Los paquetes transmitidos entre los nodos 10, 20 y 30 se designan en cada caso con una letra y un número. Los números de los paquetes indican su orden cronológico.

Con respecto a las letras “D” designa un segmento de datos TCP, “M” una confirmación MAC, “C” una confirmación COPE y “T” una confirmación TCP. Por ejemplo la flecha designada con “2” y “M” representa el paquete de datos transmitido como segundo en el orden según las figuras 1 y 2. Este segundo paquete de datos M transmitido es una confirmación M MAC, que se transmite desde el nodo 30 de retransmisión como confirmación para el segmento D de datos de capa de transporte recibido por la capa 31 MAC del nodo 30 de retransmisión a la capa 11 MAC del primer nodo 10 de envío/recepción.

En total según las figuras 1 y 2 para la transmisión del segmento D de datos TCP, designado con “D” y “1” entre el primer nodo 10 de envío y el nodo 30 de retransmisión y con “D” y “5” entre el nodo 30 de retransmisión y el segundo nodo 20 de envío/recepción, se requieren dieciséis transmisiones, hasta que se confirma la recepción satisfactoria del segmento D de datos TCP al emisor original del segmento D de datos TCP, el primer nodo 10 de envío/recepción.

En total, los dieciséis paquetes transmitidos contienen según las figuras 1 y 2 sólo dos paquetes de datos, concretamente el segmento de datos TCP designado con “D” y “1” y el segmento de datos TCP designado con “D” y “5”. Los catorce paquetes restantes contienen mensajes de señalización, en particular confirmaciones.

Por tanto, el objetivo de la presente invención es reducir o minimizar el número de mensajes de señalización

necesarios en una red conmutada por paquetes.

Según la invención, este objetivo planteado se soluciona mediante un procedimiento con las características de la reivindicación 1 para transmitir mensajes de señalización en una red conmutada por paquetes y/o mediante una red conmutada por paquetes con las características de la reivindicación 21.

Según esto, se propone un procedimiento para transmitir mensajes de señalización en una red 1 conmutada por paquetes, que tiene las siguientes etapas:

a) proporcionar una red conmutada por paquetes con al menos tres nodos, teniendo un nodo de retransmisión respectivo al menos una capa de seguridad fiable y una capa de codificación de red y teniendo un nodo de envío/recepción respectivo adicionalmente una capa de transporte fiable;

b) empaquetar al menos un mensaje de señalización en un paquete de capa de transporte sin codificar respectivo sin datos de usuario de capa de transporte en un nodo de envío/recepción;

c) enviar con prioridad el paquete de capa de transporte sin codificar respectivo a un nodo de retransmisión predeterminado a través del nodo de envío/recepción; y

d) retransmitir con prioridad el paquete de capa de transporte sin codificar respectivo a través del nodo de retransmisión.

Además se propone una red conmutada por paquetes para transmitir mensajes de señalización, que presenta al menos tres nodos, teniendo un nodo de retransmisión respectivo al menos una capa de seguridad fiable y una capa de codificación de red y teniendo un nodo de envío/recepción respectivo adicionalmente una capa de transporte fiable, estando configurado el nodo de envío/recepción respectivo para empaquetar al menos un mensaje de señalización en un paquete de capa de transporte sin codificar respectivo sin datos de usuario de capa de transporte y enviar con prioridad el paquete de capa de transporte sin codificar respectivo a un nodo de retransmisión predeterminado, retransmitiendo con prioridad el nodo de retransmisión predeterminado el paquete de capa de transporte sin codificar.

Una ventaja de la presente invención consiste en que mediante la utilización del paquete de capa de transporte sin codificar según la invención sin datos de usuario de capa de transporte, a continuación paquete GOHAR, se reduce el número de confirmaciones necesarias en la transmisión de paquetes de capa de transporte.

En particular mediante el envío con prioridad y mediante la retransmisión con prioridad del paquete GOHAR pueden suprimirse diferentes confirmaciones, en particular las confirmaciones de capa de seguridad y las confirmaciones de codificación de red. Esto se aclara por ejemplo al comparar la figura 2 con la figura 5, que se explicará a continuación con más detalle.

Además, el paquete GOHAR según la invención por la falta de datos de usuario de capa de transporte sólo presenta un volumen de datos reducido. De este modo se minimiza la carga necesaria de la red para la transmisión de los paquetes GOHAR.

Además los paquetes GOHAR según la invención, a diferencia de la transmisión de multidifusión o pseudodifusión habitual de las confirmaciones de capa de transporte, se envían o retransmiten en cada caso a un nodo predeterminado (transmisión de unidifusión). Mediante la transmisión de unidifusión según la invención de los paquetes GOHAR se reducen las probabilidades de interrupciones y de pérdidas de paquetes.

Además, de este modo se reduce también la probabilidad de nuevas transmisiones necesarias de confirmaciones de capa de transporte.

En total, mediante la aplicación de la presente invención, se aumenta la tasa de transmisión de datos en la red conmutada por paquetes. El solicitante ha realizado para ello una implementación de una conexión TCP a través de dos nodos de retransmisión sin el uso de los paquetes GOHAR según la invención y mediante el uso de los paquetes GOHAR según la invención. Sin la utilización de los paquetes GOHAR según la invención se obtuvo una tasa de transmisión de datos de 88 kBit/s en un sentido y de 105 kBit/s en el otro sentido. Por el contrario, con la misma conexión TCP mediante el uso del paquete GOHAR según la invención se obtuvo una tasa de transmisión de datos de 143 kBit/s en un sentido y 134 kBit/s en el otro sentido.

En el sentido de la presente solicitud, una capa fiable, como una capa de seguridad fiable o capa de transporte fiable, significa que ésta da acuse de recibo de la recepción de un mensaje de la capa respectiva al emisor de este mensaje con una confirmación, en particular transmite un paquete de confirmación al emisor del mensaje.

Configuraciones y perfeccionamientos ventajosos de la invención se obtienen a partir de las reivindicaciones dependientes así como de la descripción haciendo referencia a los dibujos.

Según un perfeccionamiento preferido, la capa de seguridad fiable respectiva de los nodos se configura para transmitir una confirmación de capa de seguridad para confirmar un paquete de capa de seguridad recibido al nodo que envía el paquete de capa de seguridad.

Según un perfeccionamiento preferido adicional la capa de transporte fiable respectiva de los nodos se configura para transmitir una confirmación de capa de transporte para confirmar un paquete de capa de transporte recibido, codificado por medio de codificación de red, al nodo que envía el paquete de capa de transporte codificado.

Según un perfeccionamiento preferido adicional el paquete de capa de transporte sin codificar respectivo se envía con prioridad con respecto a paquetes de capa de transporte codificados por medio de codificación de red.

Una ventaja de la retransmisión con prioridad del paquete de capa de transporte sin codificar con respecto a los paquetes de capa de transporte codificados consiste en que pueden suprimirse determinadas confirmaciones diferentes, en particular las confirmaciones de capa de seguridad y las confirmaciones de codificación de red.

Según un perfeccionamiento preferido adicional la capa de seguridad fiable respectiva de los nodos se configura para detectar el paquete de capa de transporte sin codificar y en función de ello retransmitir con prioridad el paquete de capa de transporte sin codificar, detectado.

Una ventaja de la detección del paquete de capa de transporte sin codificar a través de la capa de seguridad fiable respectiva consiste en que a consecuencia de la detección el paquete de capa de transporte sin codificar respectivo puede retransmitirse inmediatamente y sin un tiempo de latencia adicional, en particular con prioridad.

Según un perfeccionamiento preferido adicional en la detección de paquetes de capa de transporte sin codificar se analizan los paquetes de capa de transporte recibidos por la capa de seguridad fiable respectiva para detectar la falta de datos de usuario de capa de transporte.

La detección con respecto a una falta de datos de usuario de capa de transporte puede configurarse ventajosamente de forma sencilla y de este modo representarse de forma económica.

Según un perfeccionamiento preferido adicional el paquete de capa de transporte respectivo recibido por la capa de seguridad fiable, cuando faltan los datos de usuario de capa de transporte, se retransmite con prioridad por la capa de seguridad fiable.

En caso de que la detección dé como resultado que el paquete de capa de transporte no presenta datos de usuario de capa de transporte, éste puede retransmitirse inmediatamente de manera ventajosa al siguiente nodo o los siguientes nodos.

Según un perfeccionamiento preferido adicional un campo predeterminado (Type, Sub type) de la cabecera del paquete de capa de transporte sin codificar se dota de una información de indicación, que se configura para indicar a la capa de seguridad fiable respectiva de un nodo que recibe el paquete de capa de transporte sin codificar, que el paquete de capa de transporte recibido es un paquete de capa de transporte sin codificar sin datos de usuario de capa de transporte.

Ventajosamente mediante la información de indicación se proporciona una posibilidad sencilla para la detección de un paquete de capa de transporte sin codificar.

Según un perfeccionamiento preferido adicional la capa de seguridad fiable respectiva de los nodos se configura para interpretar el campo predeterminado (Type, Sub type) de la cabecera del paquete de capa de transporte sin codificar.

Mediante la posibilidad de interpretación del campo predeterminado de la cabecera del paquete de capa de transporte sin codificar la capa de seguridad fiable respectiva puede detectar de manera sencilla paquetes de capa de transporte sin codificar o paquetes GOHAR.

Según un perfeccionamiento preferido adicional la capa de codificación de red respectiva de los nodos de la red se configura para, al recibir un paquete de capa de transporte codificado, transmitir una confirmación de codificación de red al nodo de envío del paquete de capa de transporte codificado y al recibir un paquete de capa de transporte sin codificar retransmitir el paquete de capa de transporte sin codificar recibido sin la transmisión de una confirmación de codificación de red.

Una ventaja del perfeccionamiento anterior se encuentra en la diferenciación de la necesidad de confirmaciones de codificación de red. Mediante las confirmaciones de codificación de red que se suprimen según la invención se reduce ventajosamente la carga total de la red.

Según un perfeccionamiento preferido adicional cada mensaje de señalización se empaqueta en un paquete de capa de transporte sin codificar respectivo sin datos de usuario de capa de transporte.

Según un perfeccionamiento preferido adicional la capa de seguridad fiable presenta una capa MAC y una capa LLC y/o la capa de transporte fiable se configura como capa TCP.

Según un perfeccionamiento preferido adicional un TCP-ACK, un TCP-SYN y un TCP-FIN se empaquetan en un paquete de capa de transporte sin codificar respectivo sin datos de usuario de capa de transporte.

Según un perfeccionamiento preferido adicional el campo predeterminado de la cabecera del paquete de capa de transporte sin codificar se configura como campo Ethertype de la capa LLC.

Según un perfeccionamiento preferido adicional el campo predeterminado (Type, Sub type) de la cabecera del paquete de capa de transporte sin codificar se configura como campo Type (Type) o como campo Sub-type (Subtype) de la capa MAC.

Los dos perfeccionamientos anteriores tienen la ventaja común de que la invención puede aplicarse sin ampliación ni modificación de las normas existentes.

Según un perfeccionamiento preferido adicional una confirmación de capa de seguridad se genera entonces por la capa de seguridad fiable como respuesta a un paquete de capa de transporte recibido y se transmite al nodo de envío del paquete de capa de transporte, cuando el campo predeterminado (Type, Sub type) no presenta la información de indicación para indicar un paquete de capa de transporte sin codificar.

Según un perfeccionamiento preferido adicional no se genera ninguna confirmación de capa de seguridad como respuesta a un paquete de capa de transporte recibido ni se transmite al nodo de envío del paquete de capa de transporte, cuando el campo predeterminado (Type, Sub type) indica un paquete de codificación de red en los datos de usuario del paquete de capa de transporte.

Con referencia a la figura 1 o la figura 4 puede observarse que para la transmisión de un segmento de datos de capa de transporte, por ejemplo de un segmento de datos TCP, en una red conmutada por paquetes con codificación de red de un nodo al siguiente son necesarias cuatro transmisiones. En la primera transmisión el segmento D de datos de capa de transporte se transmite del primer nodo 10 de envío/recepción al nodo 30 de retransmisión (véase 1).Éste se transmite por ejemplo en una trama MAC al nodo 30 de retransmisión. La segunda transmisión muestra la confirmación M MAC consecutiva, que se devuelve según el protocolo 802.11 como confirmación para la trama MAC recibida anteriormente con el segmento D de datos de capa de transporte codificado (véase 2). La capa de codificación de red, que está configurada por ejemplo como capa COPE, soporta el protocolo COPE, que prevé que se confirme una decodificación satisfactoria de un segmento D de datos o paquete de capa de transporte codificado mediante una confirmación C COPE (véase 3) al nodo 10 de envío/recepción. Esta confirmación C COPE también se transmite como trama MAC y requiere así también una confirmación M MAC (véase 4).

Habitualmente el segmento D1 de datos de capa de transporte se transmite como multidifusión o pseudodifusión a varios nodos. No obstante, en cada caso, sólo puede direccionarse uno de los receptores del segmento D de datos de capa de transporte. A pesar de todo todos los receptores reciben este segmento D de datos de capa de transporte en el denominado modo promiscuo y obtienen de la cabecera COPE en los datos de usuario de la trama MAC si son los receptores direccionados en cada caso y por tanto tienen que procesar adicionalmente el paquete recibido del segmento D de datos de capa de transporte. En este caso sólo un único receptor del segmento D de datos de capa de transporte envía una confirmación MAC. Sin embargo, la confirmación de capa de seguridad o confirmación M de capa MAC (véase 2) tiene una utilidad reducida, ya que sólo comunica, si un único nodo de recepción de varios ha recibido correctamente la trama MAC correspondiente. Además el contenido de información a través de la transmisión de la confirmación C COPE es redundante (véase 3).

A continuación la confirmación de capa de seguridad sólo se genera cuando el campo predeterminado no indica ningún paquete de codificación de red en los datos de usuario del paquete de capa de seguridad. Por el contrario la confirmación de capa de seguridad se genera cuando el campo predeterminado de la trama MAC recibida no indica ni anuncia un protocolo COPE en los datos de usuario de esta trama MAC. Esta confirmación COPE se interpreta por la capa de seguridad, a este respecto en particular por la capa MAC, del nodo de recepción del mismo modo que una confirmación MAC según el protocolo como confirmación de una trama MAC enviada anteriormente para una pseudodifusión. Sin embargo, en caso de que la decodificación no sea posible, preferiblemente se manda una confirmación negativa al nodo de envío. Esta confirmación negativa puede contener la información adicional, como en el caso de una confirmación COPE positiva, de que la trama MAC recibida anteriormente se recibió correctamente.

Según un perfeccionamiento preferido adicional sólo se genera una confirmación de codificación de red por la capa de codificación de red como respuesta a un paquete de capa de transporte recibido y se transmite al nodo de envío del paquete de capa de transporte, cuando el campo predeterminado (Type, Sub type) indica un paquete de

codificación de red en los datos de usuario del paquete de capa de transporte y cuando el paquete de codificación de red puede decodificarse por la capa de codificación de red respectiva.

Según un perfeccionamiento preferido adicional la etapa d) se configura al:

-: retransmitir con prioridad el paquete de capa de transporte sin codificar respectivo a través del nodo de retransmisión a un nodo de retransmisión predeterminado adicional o a un nodo de envío/recepción adicional.

Además se propone un producto de programa informático, que en un dispositivo con control de programa da lugar a la realización de un procedimiento tal como el descrito anteriormente según la invención.

Un producto de programa informático como un medio de programa informático puede proporcionarse o suministrarse por ejemplo como medio de almacenamiento, como tarjeta de almacenamiento, memoria USB, disquete, CD-ROM, DVD o también en forma de un archivo que puede descargarse de un servidor en una red. Esto puede producirse por ejemplo en una red de comunicación inalámbrica mediante la transmisión de un archivo correspondiente con el producto de programa informático o el medio de programa informático.

Según una configuración preferida el nodo de retransmisión respectivo presenta una capa de transmisión de bits, la capa de seguridad fiable, la capa de codificación de red y una capa IP.

Según una configuración preferida adicional el nodo de envío/recepción respectivo presenta una capa de transmisión de bits, la capa de seguridad fiable, la capa de codificación de red, una capa IP, la capa de transporte fiable y una capa de aplicación.

La invención se explica en más detalle a continuación mediante los ejemplos de realización indicados en las figuras esquemáticas. Muestran:

las figuras 1 y 2 diagramas de bloques esquemáticos de una red conmutada por paquetes;

la figura 3 un diagrama de flujo esquemático de un ejemplo de realización del procedimiento según la invención para transmitir mensajes de señalización en una red conmutada por paquetes;

las figuras 4 y 5 diagramas de bloques esquemáticos de una red conmutada por paquetes según la invención; y

la figura 6 un diagrama de bloques esquemático de una cabecera 802.11.

En todas las figuras los medios y dispositivos iguales o con la misma función, siempre que no se indique lo contrario, están dotados de los mismos números de referencia.

En la figura 3 se representa un diagrama de flujo esquemático de un ejemplo de realización del procedimiento según la invención para transmitir mensajes de señalización en una red 1 conmutada por paquetes.

A continuación se explica el procedimiento según la invención mediante el diagrama de bloques en la figura 3 con referencia a los diagramas de bloques de las figuras 4 y 5. Las figuras 4 y 5 muestran diagramas de bloques esquemáticos de una red 1 conmutada por paquetes según la invención.

La red 1 conmutada por paquetes tiene al menos tres nodos 10-30. Al menos dos de los al menos tres nodos 10-30 están configurados como nodos 10, 20 de envío/recepción. Los nodos 10, 20 de envío/recepción son el origen y/o destino de los paquetes transmitidos mediante la red 1 conmutada por paquetes.

La red 1 conmutada por paquetes está configurada por ejemplo como red WLAN. Además un nodo 30 de retransmisión está configurado por ejemplo como encaminador u ordenador de encaminamiento. Los nodos 10, 20 de envío/recepción pueden estar diseñados como servidor o como terminal de abonado.

Sin limitación de la generalidad la red 1 conmutada por paquetes según las figuras 4 y 5 tiene dos nodos 10, 20 de envío/recepción y un nodo 30 de retransmisión. Evidentemente la red 1 conmutada por paquetes puede tener una pluralidad de nodos de envío/recepción y una pluralidad de nodos de retransmisión.

El nodo 30 de retransmisión tiene al menos una capa 31 de seguridad fiable y una capa 32 de codificación de red. Preferiblemente el nodo 30 de retransmisión tiene una capa de transmisión de bits, la capa 31 de seguridad fiable, la capa 32 de codificación de red y una capa IP.

El nodo 10, 20 de envío/recepción respectivo tiene al menos una capa 11, 21 de seguridad fiable, una capa 12, 22 de codificación de red y una capa 13, 33 de transporte fiable. Preferiblemente el nodo 10, 20 de envío/recepción respectivo tiene una capa de transmisión de bits, la capa 11, 21 de seguridad fiable, la capa 12, 22 de codificación de red, una capa IP, la capa 13, 33 de transporte fiable y una capa de aplicación.

El nodo 10, 20 de envío/recepción respectivo se configura para empaquetar al menos un mensaje de señalización en un paquete G de capa de transporte sin codificar respectivo sin datos de usuario de capa de transporte y enviar con prioridad el paquete G de capa de transporte sin codificar respectivo, denominado a continuación también paquete G GOHAR, a un nodo 30 de retransmisión predeterminado. En cambio, el nodo 30 de retransmisión predeterminado respectivo se configura para retransmitir con prioridad el paquete G de capa de transporte sin codificar.

Los paquetes transmitidos entre los nodos 10, 20 y 30 están designados en cada caso con una letra y un número. Los números de los paquetes indican su orden cronológico. Con respecto a las letras “D” designa un segmento de datos de capa de transporte, “M” una confirmación de capa de seguridad, “C” una confirmación de codificación de red, “T” una confirmación de capa de transporte y “G” el paquete GOHAR según la invención.

El procedimiento según la invención según la figura 1 presenta las etapas de procedimiento S1 a S4:

Etapa de procedimiento S1:

Se proporciona una red 1 conmutada por paquetes con al menos tres nodos 10, 30, teniendo un nodo 30 de retransmisión respectivo al menos una capa 31 de seguridad fiable y una capa 32 de codificación de red y teniendo un nodo 10, 20 de envío/recepción respectivo adicionalmente una capa 13, 23 de transporte fiable.

Etapa de procedimiento S2:

Un mensaje de señalización respectivo se empaqueta en un paquete G de capa de transporte sin codificar respectivo sin datos de usuario de capa de transporte, a continuación paquete GOHAR, a través de un nodo 10 de envío/recepción, por ejemplo un primer nodo 10 de envío/recepción.

Etapa de procedimiento S3:

El paquete G de capa de transporte sin codificar respectivo se envía con prioridad por el nodo 10 de envío/recepción a un nodo 30 de retransmisión predeterminado.

Etapa de procedimiento S4:

El paquete G de capa de transporte codificado respectivo se retransmite con prioridad a través del nodo 30 de retransmisión predeterminado, por ejemplo a un nodo de retransmisión adicional o al nodo 20 de envío/recepción objetivo.

Preferiblemente la capa 11, 21, 31 de seguridad fiable respectiva de los nodos 10-31 se configura para transmitir una confirmación M de capa de seguridad para confirmar un paquete de capa de seguridad recibido al nodo 10-30 que envía el paquete de capa de seguridad. Además la capa 13, 23 de transporte fiable respectiva del nodo 10, 30 de envío/recepción puede configurarse para transmitir una confirmación T de capa de transporte para confirmar un paquete de capa de transporte recibido, codificado por medio de codificación de red, al nodo 10-30 que envía el paquete de capa de transporte codificado. A este respecto el paquete G de capa de transporte sin codificar respectivo se envía o retransmite con prioridad con respecto a paquetes de capa de transporte codificados por medio de codificación de red.

En el envío o la retransmisión con prioridad la capa 11, 21, 31 de seguridad fiable respectiva de los nodos 10-30 se configura en particular para detectar el paquete G de capa de transporte sin codificar y en función de ello retransmitir con prioridad el paquete G de capa de transporte sin codificar, detectado. En la detección de paquetes G de capa de transporte sin codificar se analizan los paquetes G de capa de transporte recibidos por la capa 11, 21, 31 de seguridad fiable respectiva para detectar la falta de datos de usuario de capa de transporte. En caso de que falten los datos de usuario de capa de transporte, entonces la capa 11, 21, 31 de seguridad fiable interpreta el paquete de capa de transporte recibido como un paquete GOHAR según la invención y lo retransmite con prioridad.

Además para la detección de paquetes G de capa de transporte sin codificar puede usarse un campo predeterminado (Type, Sub type) de la cabecera H del paquete G de capa de transporte sin codificar. Para ello el campo predeterminado Type, Sub type (véase figura 6) se dota de una información de indicación. La información de indicación se configura preferiblemente para indicar a la capa 11, 21, 31 de seguridad fiable respectiva de un nodo 10-30 que recibe el paquete G de capa de transporte sin codificar, que el paquete de capa de transporte recibido es un paquete G de capa de transporte sin codificar sin datos de usuario de capa de transporte. A este respecto el campo predeterminado de la cabecera H del paquete G de capa de transporte sin codificar puede interpretarse por la capa 11, 21, 31 de seguridad fiable respectiva de los nodos 10-30.

Además la capa 12, 22, 32 de codificación de red respectiva de los nodos 10-30 de la red 1 se configura preferiblemente para, al recibir un paquete de capa de transporte codificado, transmitir una confirmación C de

codificación de red al nodo 10-30 de envío del paquete de capa de transporte codificado y al recibir un paquete G de capa de transporte sin codificar retransmitir el paquete G de capa de transporte sin codificar sin la transmisión de una confirmación C de codificación de red. De este modo, en este caso, puede suprimirse una confirmación C de codificación de red habitual.

5 Por ejemplo, la capa 11, 21, 31 de seguridad fiable presenta una capa MAC y una capa LLC. La capa 13, 33 de transporte fiable sólo puede estar configurada como capa TCP. A este respecto preferiblemente cada TCP-ACK, cada TCP-SYN y cada TCP-FIN se empaqueta en un paquete G GOHAR respectivo.

10 El campo predeterminado de la cabecera H del paquete G de capa de transporte sin codificar puede estar configurado como campo Ethertype de la capa LLC. Alternativamente el campo predeterminado Type, Sub type de la cabecera H del paquete G de capa de transporte sin codificar puede estar configurado como campo Type Type o como campo Sub type Sub type de la capa MAC.

15 Para ello la figura 6 muestra un diagrama de bloques esquemático de una cabecera H 802.11.

Al usar el campo Ethertype de la capa LLC o el campo Type Type o el campo Sub type Sub type de la capa MAC es necesario adaptar correspondientemente la semántica de estos campos. En la tabla siguiente se indica el significado según la norma del campo Sub type Sub type en función del campo Type Type. Como en el caso de un paquete G

20 GOHAR desde el punto de vista del protocolo 802-11 se trata de una trama de datos 802-11, preferiblemente la identificación como paquete G GOHAR se realiza con respecto al campo Type Type reservado.

Sub type value (valor Sub type) Sub type name (nombre Sub type) Management frames (type=00) (tramas de gestión) (tipo=00) 0000 Association request (petición de asociación) 0001 Association response (respuesta de asociación) 0010 Reassociation request (petición de reasociación) 0011 Reassociation response (respuesta de reasociación) 0100 Probe request (petición de comprobación) 0101 Probe response (respuesta de comprobación) 1000 Beacon (baliza) Announcement traffic indication (ATIM) (mensaje de indicación de

tráfico de anuncio (AVIN) 1010 Disassociation (disociación) 1011 Authentification (autenticación) 1100 Deauthentification (desautenticación) 1101 Action (for spectrum management with 802.11h, también para QoS)

Acción (para gestión de espectro con 802.11h, también para QoS) Control frames (type=01)

(Tramas de control) (tipo =01) 1000 Block Acknowledgement Request (petición de confirmación de bloques) 1001 Block Acknowledgement (confirmación de bloque) (QoS) 1010 Power Save (PS)-Poll (ahorro de energía) 1011 RTS 1100 CTS 1101 Acknowledgement

(ACK)(Confirmación) 1110 Contention-Free (CF)-End (extremo sin contienda) 1111 CF-End+CF-Ack

Data frames (type=10) (tramas de

datos (tipo=10)) 0000 Data (datos) 0001 Data+CF-Ack 0010 Data+CF-Poll 0011 Data+CF-Ack+CF-Poll 0100 Null data (ningún dato) (no transmission) (ninguna transmisión de

datos) 0101 CF-Ack (no data transmitted) (ninguna transmisión de datos) 0110 CF-Poll (no data transmitted) (ninguna transmisión de datos) 0111 CF-Ack+CF-Poll (no data transmitted) (ninguna transmisión de datos) 1000 QoS Datac 1001 QoS Data + CF-Ackc

1010 QoS Data + CF-Pollc 1011 QoS Data + CF-Ack + CF-Pollc 1100 QoS Null (no data transmitted)(ninguna transmisión de datos)c 1101 QoS CF-Ack (no data transmitted) (ninguna transmisión de datos)c 1110 QoS CF-Poll (no data transmitted) (ninguna transmisión de datos)c 1111 QoS CF-Ack+CF-Poll (no data transmitted) (ninguna transmisión de

datos)c (Frame type 11 is reserved) (Tipo de trama 11 está reservada)

Por tanto una trama 802.11 es exactamente un paquete G GOHAR cuando el campo Type Type tiene el valor “11” como información de indicación. En este caso la semántica del campo Sub type Sub type corresponde a la de un Sub type con un valor de “10” del campo Type Type.

5 Data frames (type=11) including a GOHAR packet (Tramas de datos (tipo=11) que presenta un paquete GOHAR) 0000 Data

0001 Data+CF-Ack 0010 Data+CF-Poll 0011 Data+CF-Ack+CF-Poll

Null data (no data transmitted) (ninguna transmisión de 0100

datos) 0101 CF-Ack (no data transmitted) (ninguna transmisión de datos) 0110 CF-Poll (no data transmitted) (ninguna transmisión de datos) 0111 CF-Ack+CF-Poll (no data transmitted) (ninguna transmisión de datos)

1000 QoS Datac 1001 QoS Data + CF-Ackc 1010 QoS Data + CF-Pollc 1011 QoS Data + CF-Ack + CF-Pollc

QoS Null (no data transmitted) (ninguna transmisión de 1100

datos)c 1101 QoS CF-Ack (no data transmitted) (ninguna transmisión de datos)c

1110 QoS CF-Poll (no data transmitted)(ninguna transmisión de datos)c

1111 QoS CF-Ack+CF-Poll (no data transmitted)(ninguna transmisión de datos)

Además una confirmación M de seguridad puede generarse entonces por la capa 11, 21, 31 de seguridad fiable como respuesta a un paquete de capa de transporte recibido y transmitirse al nodo 10, 30 de envío del paquete de capa de transporte, cuando el campo predeterminado Type, Sub type no presenta la información de indicación, por 10 ejemplo “11”, para indicar un paquete G de capa de transporte sin codificar. Además preferiblemente no se genera ninguna confirmación M de capa de seguridad como respuesta a un paquete de capa de transporte recibido ni se transmite al nodo 10-30 de envío del paquete de capa de transporte cuando el campo predeterminado Type, Sub type indica un paquete de codificación de red en los datos de usuario del paquete de capa de transporte. Además sólo se genera una confirmación C de codificación de red por la capa 12, 22, 32 de codificación de red como

15 respuesta a un paquete de capa de transporte recibido y se transmite al nodo 10-30 de envío del paquete de capa de transporte, cuando el campo predeterminado Type, Sub type indica un paquete de codificación de red en los datos de usuario del paquete de capa de transporte y cuando el paquete de codificación de red puede decodificarse por la capa 12, 22, 32 de codificación de red respectiva.

20 Aunque la presente invención se haya descrito anteriormente mediante los ejemplos de realización preferidos, no se limita a los mismos, sino que puede modificarse de múltiples maneras.

Claims

REIVINDICACIONES

1. Procedimiento para transmitir mensajes de señalización en una red (1) conmutada por paquetes, con las etapas de:

a) proporcionar una red (1) conmutada por paquetes con al menos tres nodos (10-30), teniendo un nodo

(30) de retransmisión respectivo al menos una capa (31) de seguridad fiable y una capa (32) de codificación de red y teniendo un nodo (10, 20) de envío/recepción respectivo adicionalmente una capa (13, 23) de transporte fiable;

b) empaquetar al menos un mensaje de señalización en un paquete (G) de capa de transporte sin codificar respectivo sin datos de usuario de capa de transporte en un nodo (10) de envío/recepción;

c) enviar con prioridad el paquete (G) de capa de transporte sin codificar respectivo a un nodo (30) de retransmisión predeterminado a través del nodo (10) de envío/recepción; y

d) retransmitir con prioridad el paquete (G) de capa de transporte sin codificar respectivo a través del nodo

(30) de retransmisión.
2.

Procedimiento según la reivindicación 1, caracterizado porque la capa (11, 21, 31) de seguridad fiable respectiva de los nodos (10, 20, 30) se configura para transmitir una confirmación (M) de capa de seguridad para confirmar un paquete de capa de seguridad recibido al nodo (10, 20, 30) que envía el paquete de capa de seguridad.
3.

Procedimiento según la reivindicación 1 ó 2, caracterizado porque la capa (13, 23) de transporte fiable respectiva de los nodos (10, 30) se configura para transmitir una confirmación (T) de capa de transporte para confirmar un paquete de capa de transporte recibido, codificado por medio de codificación de red, al nodo (10, 20) que envía el paquete de capa de transporte codificado.
4.

Procedimiento según la reivindicación 1, 2 ó 3, caracterizado porque el paquete (G) de capa de transporte sin codificar respectivo se envía con prioridad con respecto a paquetes de capa de transporte codificados por medio de codificación de red.
5.

Procedimiento según la reivindicación 1 o una de las reivindicaciones 2-4, caracterizado porque la capa (11, 21, 31) de seguridad fiable respectiva de los nodos (10-30) se configura para detectar el paquete (G) de capa de transporte sin codificar y en función de ello retransmitir con prioridad el paquete (G) de capa de transporte sin codificar, detectado.
6.

Procedimiento según la reivindicación 5, caracterizado porque en la detección de paquetes (G) de capa de transporte sin codificar se analizan los paquetes (G) de capa de transporte recibidos por la capa (11, 21, 31) de seguridad fiable respectiva para detectar la falta de datos de usuario de capa de transporte.
7.

Procedimiento según la reivindicación 6, caracterizado porque el paquete de capa de transporte respectivo recibido por la capa (11, 21, 31) de seguridad fiable, cuando faltan los datos de usuario de capa de transporte, se retransmite con prioridad por la capa (11, 21, 31) de seguridad fiable.
8.

Procedimiento según la reivindicación 5, caracterizado porque un campo predeterminado (Type, Sub type) de la cabecera (H) del paquete (G) de capa de transporte sin codificar se dota de una información de indicación, que se configura para indicar a la capa (11, 21, 31) de seguridad fiable respectiva de un nodo (10-30) que recibe el paquete (G) de capa de transporte sin codificar, que el paquete (G) de capa de transporte recibido es un paquete (G) de capa de transporte sin codificar sin datos de usuario de capa de transporte.
9.

Procedimiento según la reivindicación 8, caracterizado porque la capa (11, 21, 31) de seguridad fiable respectiva de los nodos (10-30) se configura para interpretar el campo predeterminado (Type, Sub type) de la cabecera (H) del paquete (G) de capa de transporte sin codificar.
10.

Procedimiento según la reivindicación 1 o una de las reivindicaciones 2-9, caracterizado porque la capa (12, 22, 32) de codificación de red respectiva de los nodos (10-30) de la red (1) se configura para, al recibir un paquete de capa de transporte codificado, transmitir una confirmación (C) de codificación de red al nodo (10-30) de envío del paquete de capa de transporte codificado y al recibir un paquete (G) de capa de transporte sin codificar retransmitir el paquete (G) de capa de transporte sin codificar recibido sin la transmisión de una confirmación (C) de codificación de red.
11.

Procedimiento según la reivindicación 1 o una de las reivindicaciones 2-10, caracterizado porque cada mensaje de señalización se empaqueta en un paquete (G) de capa de transporte sin codificar respectivo sin

datos de usuario de capa de transporte.
12.

Procedimiento según la reivindicación 1 o una de las reivindicaciones 2-11, caracterizado porque la capa (11, 21, 31) de seguridad fiable presenta una capa MAC y una capa LLC y/o la capa (13, 33) de transporte fiable se configura como capa TCP.
13.

Procedimiento según la reivindicación 12, caracterizado porque un TCP-ACK, un TCP-SYN y un TCP-FIN se empaquetan en un paquete (G) de capa de transporte sin codificar respectivo sin datos de usuario de capa de transporte.
14.

Procedimiento según la reivindicación 12, caracterizado porque el campo predeterminado de la cabecera del paquete (G) de capa de transporte sin codificar se configura como campo Ethertype.
15.

Procedimiento según la reivindicación 12, caracterizado porque el campo predeterminado (Type, Sub type) de la cabecera (H) del paquete (G) de capa de transporte sin codificar se configura como campo Type (Type) o como campo Sub-type (Sub-type) de la capa MAC.
16.

Procedimiento según la reivindicación 8 o una de las reivindicaciones 9-15, caracterizado porque una confirmación (M) de capa de seguridad se genera entonces por la capa (11, 21, 31) de seguridad fiable como respuesta a un paquete de capa de transporte recibido y se transmite al nodo (10-30) de envío del paquete de capa de transporte, cuando el campo predeterminado (Type, Sub type) no presenta la información de indicación para indicar un paquete (G) de capa de transporte sin codificar.
17.

Procedimiento según la reivindicación 9 o una de las reivindicaciones 9-15, caracterizado porque no se genera ninguna confirmación (M) de capa de seguridad como respuesta a un paquete de capa de transporte recibido ni se transmite al nodo (10-30) de envío del paquete de capa de transporte, cuando el campo predeterminado (Type, Sub type) indica un paquete de codificación de red en los datos de usuario del paquete de capa de transporte.
18.

Procedimiento según la reivindicación 9 o una de las reivindicaciones 9-17, caracterizado porque sólo se genera una confirmación (C) de codificación de red por la capa (12, 22, 32) de codificación de red como respuesta a un paquete de capa de transporte recibido y se transmite al nodo (10-30) de envío del paquete de capa de transporte, cuando el campo predeterminado (Type, Sub type) indica un paquete de codificación de red en los datos de usuario del paquete de capa de transporte y cuando el paquete de codificación de red puede decodificarse por la capa (12, 22, 32) de codificación de red respectiva.
19.

Procedimiento según la reivindicación 1 o una de las reivindicaciones 2-18, caracterizado porque la etapa d) se configura al:

- retransmitir con prioridad el paquete (G) de capa de transporte sin codificar respectivo a través del nodo

(30) de retransmisión a un nodo de retransmisión predeterminado adicional o a un nodo de envío/recepción adicional.
20.

Producto de programa informático, que en un dispositivo con control de programa da lugar a la realización de un procedimiento según una de las reivindicaciones 1 a 19.
21.

Red (1) conmutada por paquetes para transmitir mensajes de señalización, con:

-

al menos tres nodos (10-30), teniendo un nodo (30) de retransmisión respectivo al menos una capa (31) de seguridad fiable y una capa (32) de codificación de red y teniendo un nodo (10, 20) de envío/recepción respectivo adicionalmente una capa (13, 33) de transporte fiable;

-

estando configurado el nodo (10, 20) de envío/recepción respectivo para empaquetar al menos un mensaje de señalización en un paquete (G) de capa de transporte sin codificar respectivo sin datos de usuario de capa de transporte y enviar con prioridad el paquete (G) de capa de transporte sin codificar respectivo a un nodo (30) de retransmisión predeterminado; y

-

retransmitiendo con prioridad el nodo (30) de retransmisión predeterminado el paquete (G) de capa de transporte sin codificar.
22. Red conmutada por paquetes según la reivindicación 21, caracterizada porque el nodo (30) de retransmisión respectivo tiene una capa de transmisión de bits, la capa (31) de seguridad fiable, la capa

(32) de codificación de red y una capa IP y/o el nodo (10, 20) de envío/recepción respectivo tiene una capa de transmisión de bits, la capa (11, 21) de seguridad fiable, la capa (12, 22) de codificación de red, una capa IP, la capa (13, 33) de transporte fiable y una capa de aplicación.