ES2227196T3 - Asignacion de canal sin hilos en un procesador de estacion base. - Google Patents

Abstract

Método de asignación de canales sin hilos en un sistema de comunicaciones de datos sin hilos, que comprende: proporcionar una pluralidad de canales adaptados para transmitir mensajes a través de un procesador de estación base; recibir un primer mensaje desde un emisor en dicho procesador de la estación base; caracterizado por determinar un tipo descriptivo de dicho primer mensaje; calcular un período de latencia asociado con un mensaje de retorno correspondiente a dicho tipo; y programar uno de dichos canales adaptados para transmitir dicho mensaje de retorno para ser asignado en un instante que depende de dicho período de latencia.

Description

Asignación de canal sin hilos en un procesador de estación base.

Antecedentes de la invención

Los equipos de infraestructura de redes sin hilos están siendo usados en medida creciente para permitir a dispositivos de ordenadores comunicar a través de un medio sin hilos con una red cableada tal como Internet. En una red de datos sin hilos, una pluralidad de dispositivos de cálculo locales, tales como ordenadores personales, están soportados por medio de unidades de acceso de abonados sin hilos. Una unidad de acceso de abonado proporciona un enlace de radio sin hilos a un procesador de estación base. El procesador de la estación base está conectado también a un portal de acceso a Internet que proporciona una conexión a una red cableada. De modo similar a una red de telefonía celular, el procesador de la estación base asigna una pluralidad de canales sin hilos sobre una base de demanda para proporcionar la transmisión de mensajes a y desde las unidades de abonado. Los canales sin hilos son asignados a mensajes enviados y recibidos desde la unidad de abonado por cuenta del dispositivo de ordenador local.

En un procesador de estación base típico, los canales sin hilos son un recurso escaso que son compartidos por las unidades de abonado. Los mensajes se ponen con frecuencia en cola, pendientes de la disponibilidad de un canal. Además, las redes cableadas emplean típicamente técnicas para detectar la velocidad con la que un receptor está procesando los mensajes. Estas técnicas reducen la congestión al evitar sobrecargar a un receptor mediante la reducción del ritmo al que son enviados los mensajes, y reduciendo en consecuencia el rendimiento. Tales técnicas pueden interpretar la puesta en cola de los mensajes en el procesador de la estación base como congestión en la red cableada, y reducir por tanto el rendimiento. En particular, los protocolos empleados en la red cableada no se prestan bien por sí mismos para una comunicación eficiente a través de conexiones sin hilos.

En una red TCP/IP, por ejemplo, se emplean técnicas de control de la congestión tales como inicio lento, evitación de congestión, retransmisión rápida y recuperación rápida. De acuerdo con la técnica de inicio lento, tal como se define en Internet RFC 2581, se espera un mensaje de aceptación (ack) como mensaje de retorno a cada mensaje enviado. El número de octetos, o mensajes, enviados se aumenta gradualmente a medida que los mensajes de aceptación se reciben de manera secuenciada. Si los mensajes de aceptación no se reciben de manera secuenciada, los mensajes adicionales se enviarán con menor frecuencia, reduciéndose el rendimiento. La puesta en cola de los mensajes en el procesador de la estación base no es sin embargo indicativa de congestión en el procesador de la estación base. Por el contrario, la puesta en cola es indicativa de la demora de propagación inherente en las redes sin hilos. Esta demora de propagación es interpretada sin embargo como congestión por los protocolos de líneas cableadas tales como TCP/IP.

Sería beneficioso por tanto proporcionar un método y un aparato que puedan anticipar la llegada del mensaje de retorno, y programar un canal para que esté disponible para transmitir el mensaje por medio del procesador de la estación base de modo que el rendimiento en la red cableada no sea reducido por las propiedades de control de la congestión del protocolo de la red cableada, tales como inicio lento.

Compendio de la invención

Se proporcionan un sistema y un método para asignar canales sin hilos en un sistema de comunicaciones sin hilos para soportar la transmisión de mensajes entre un abonado y un procesador de estación base. Se determina un período de latencia correspondiente a la cadencia de un mensaje de retorno esperado desde un nodo respondedor en respuesta a un mensaje de salida enviado desde un emisor por medio del procesador de la estación base. Un gestor de latencia en el procesador de la estación base calcula el período de latencia y memoriza el período de latencia en una tabla de asignación. Un programador programa un canal, antes de la recepción del mensaje de retorno, para que esté disponible al final del período de latencia indicado en la tabla de asignación. Aproximadamente al final del período de latencia, se recibe el mensaje de retorno y el programador asigna un canal, tal como se define en la tabla de asignación. El canal asignado se usa para transmitir el mensaje de retorno a o desde el abonado correspondiente.

El gestor de latencia calcula el período de latencia usando una variedad de parámetros de transmisión definidos en el protocolo de la red de línea cableada. Por ejemplo, en una red TCP/IP, los parámetros de transmisión usados para calcular el período de latencia pueden incluir el tamaño de la ventana, espacio disponible en la ventana, tamaño medio de los mensajes, número de mensajes de aceptación pendientes, tipo de mensajes, número de mensajes recibidos en la sesión, número de mensajes de aceptación pendientes, número máximo de mensajes de aceptación pendientes, y otros parámetros de transmisión.

Breve descripción de los dibujos

Los anteriores y otros objetos, propiedades y ventajas de la invención resultarán evidentes según la descripción más particular que sigue de realizaciones preferentes de la invención, tal como se ilustran en los dibujos adjuntos, en los que caracteres de referencia iguales se refieren a las mismas partes a todo lo largo de las diferentes vistas. Los dibujos no están necesariamente a escala, poniéndose el énfasis por el contrario en ilustrar los principios de la invención.

Fig. 1 es un diagrama de bloques de un sistema de comunicaciones apropiado para llevar a cabo la asignación de canales sin hilos tal como se define aquí;

Fig. 2 muestra un procesador de estación base en comunicación con una pluralidad de unidades de acceso de abonados;

Fig. 3a muestra la transmisión de mensajes en el sistema de Fig. 2;

Fig. 3b muestra una tabla de asignación de canales correspondiente a los mensajes de Fig. 3a;

Fig. 4 muestra un diagrama de flujo de la asignación de canales tal como se define aquí;

Fig. 5a muestra una búsqueda de página web usando el sistema de Fig. 1;

Fig. 5b muestra la tabla de asignación correspondiente a los mensajes de Fig. 5a;

Fig. 5c muestra un diagrama de cadencia correspondiente a la tabla de asignación de Fig. 5b; y

Fig. 6 muestra una tabla de perfiles de abonados para la asignación de canales tal como se define aquí.

Descripción detallada de la invención

Fig. 1 es un diagrama de bloques de un sistema de comunicaciones 10 operable para la asignación de canales en una red sin hilos tal como se define aquí. El sistema de comunicaciones incluye un dispositivo de ordenador local tal como un ordenador personal 12, una unidad de acceso de abonado 14, un procesador de estación base 16, y un portal de acceso a Internet 18. El ordenador personal 12 está en comunicación con el abonado 14 por medio de una conexión cableada 20. El abonado 14 está en comunicación con un procesador de estación base 16 por medio de una conexión sin hilos 26. El procesador de la estación base está en comunicación con un portal de acceso a Internet 18 por medio de un enlace cableado 24. El portal de acceso a Internet 18 está adaptado para comunicación por medio de una red de acceso público tal como Internet.

El ordenador personal 12 puede ser provisto por tanto de acceso al servidor 18 de la red, que puede ser cualquier entidad remota situada en Internet o en otra red, a través de una combinación de las conexiones cableadas 20, 24 y sin hilos 26. Las conexiones cableadas 20, 24 están soportadas típicamente por un protocolo tal como TCP/IP o UDP. La conexión sin hilos está soportada por protocolos tales como el protocolo descrito en la Solicitud de Patente de EE.UU. pendiente titulada "Dynamic Frame Size Settings for Multichannel Transmission", publicada como Solicitud PCT Nº WO 99/44341, el 2 de septiembre 1999. Típicamente, el ordenador personal 12 proporciona un lote de Protocolo Internet (IP) al abonado 14 a través de la conexión cableada 20, que puede ser por ejemplo una conexión del tipo Ethernet. El abonado 14 elimina el enmarcado del lote IP y transfiere los datos en el lote IP al procesador de la estación base 16 a través de la conexión sin hilos 26 de acuerdo con un protocolo de enlace sin hilos. El procesador de la estación base 16 extrae los marcos de la conexión sin hilos y los dirige, en forma de lotes IP, a través de la conexión de línea cableada 24, al portal de acceso a Internet 18. El abonado 14 y el procesador de la estación base 16 se consideran por tanto como "puntos finales" de la conexión sin hilos 20.

Haciendo referencia a Fig. 2, se muestra en mayor detalle el procesador de la estación base 16. El procesador de la estación base 16 está en comunicación con una pluralidad de abonados 14a-14d. Pueden estar previstas unidades de abonados adicionales (14x). Los abonados comunican con el procesador de la estación base por medio de canales sin hilos 22a-22j que se muestran. Se pueden añadir canales adicionales 22(x). Tal como se indica más arriba, los canales 22 se usan para transmitir mensajes a y desde los abonados 14. Un programador 28 asigna los canales 22 sobre una base de demanda, y asigna canales disponibles a mensajes transmitidos entre los abonados 14 y el procesador de la estación base 16.

Los canales 22 son unidireccionales entre los abonados 14 y el conmutador 16, si bien se pueden asignar canales múltiples a mensajes originarios de o destinados a un abonado particular 14. En el ejemplo mostrado, el canal 22a es asignado para transmitir un mensaje desde el procesador de la estación base 16 al abonado 14b. El canal 22b es asignado para recibir un mensaje en el procesador de la estación base 16 desde el abonado 14c, mientras que el canal 22c es asignado para enviar un mensaje al abonado 14c. Los canales 22d y 22e son asignados para transmitir un mensaje al abonado 14d, y el canal 22f es asignado para recibir un mensaje desde el abonado 14d. Típicamente, tal como se indica más arriba, el programador 28 está asignando rápidamente canales a los abonados para adaptarse a las solicitudes de canales para mensajes a ser enviados a y recibidos desde los abonados 14.

Dos canales dedicados, comunes a todos los abonados 14, se emplean para iniciar el tráfico de mensajes en un canal. Un canal de acceso común 30 es usado por un abonado 14 para solicitar un canal al procesador de la estación base 16. Un canal de buscapersonas común 32 es usado para notificar a un abonado 14 que se le está asignando un canal. Los mensajes son entonces dirigidos por los abonados 14 al ordenador personal 12 o al procesador de la estación base 16, dependiendo de la dirección.

El procesador de la estación base 16 incluye también un gestor de latencia 34, para determinar las demoras de latencia, y una tabla de asignación 36, que se describen ambos más abajo. En una transmisión de mensajes típica, tal como se indica más arriba, ocurren cierto número de demoras de latencia entre el emisor del mensaje y el receptor, o nodo respondedor. Por ejemplo, ocurre una demora de propagación sin hilos al transmitir un mensaje desde el procesador de la estación base 16 al abonado 14 (Fig. 1). Una demora de propagación de la red ocurre al ser transmitido un mensaje a través de Internet u otra red de acceso público. Hay presentes otras demoras de latencia, tal como se describirá más abajo. Es común en un protocolo tal como TCP/IP esperar un mensaje de retorno, típicamente un mensaje de aceptación, en respuesta a un mensaje enviado a un nodo respondedor. De acuerdo con la invención tal como se define aquí, el gestor de latencia está incluido en el procesador de la estación base para calcular la demora de latencia y programar un canal en consecuencia. La asignación de canales se refiere a los mensajes enviados desde un emisor en cualquier dirección; el mensaje de retorno será devuelto al emisor por el nodo que recibe el mensaje. Por tanto, una asignación de canal para un mensaje de retorno será programado de modo predecible cuando un mensaje es enviado a o desde los abonados 14.

Haciendo referencia a Fig. 3a y 3b, se muestra un diseño más detallado del procesador de la estación base 16, que incluye el gestor de latencia 34, la tabla de asignación 36 y el programador 28. El gestor de latencia 34 es un proceso que calcula la demora de latencia asociada con el mensaje de retorno enviado por un modo respondedor 40. La tabla de asignación 36 es una estructura de memoria que memoriza una entrada 38a, 38b para cada asignación de canal 22b, 22c, y tiempos de latencia asociados T_{0} y T_{0} + T_{L}. Un programador 28 es un proceso que lee la tabla de asignación 36 y la información de latencia para determinar la asignación de canales a los mensajes esperados.

En una transmisión de mensajes típica, el ordenador personal 12 envía un mensaje de solicitud de conexión a un nodo respondedor 40, tal como se indica mediante la flecha 42. El mensaje 42 es enviado en el instante T_{0}. En consecuencia, se escribe una entrada 38a en la tabla de asignación 36 para asignar el canal 22b con el abonado 14c en el instante T_{0}. Al ser recibido el mensaje 42 a través del canal 22b, el gestor de latencia 34 examina el mensaje. El gestor de latencia 34 determina que el tipo del mensaje es una solicitud de conexión TCP/IP, y que por tanto un mensaje de aceptación puede ser esperado como mensaje de retorno.

El gestor de latencia 34 determina el período de latencia que transcurrirá antes de la recepción del mensaje de retorno en el procesador de la estación base 16. Por ejemplo, el gestor de latencia 34 determina que una demora ISP (Proveedor de Servicio de Internet) 44 ocurrirá entre el portal de acceso a Internet 18 e Internet 50, tal como se indica mediante \DeltaT_{1}; además, una demora de propagación de la red 46 ocurrirá al ser el mensaje 42 transmitido por medio de Internet 50, tal como se indica mediante \DeltaT_{2}; y seguidamente una demora 48 del nodo respondedor ocurrirá mientras el nodo respondedor 40 procesa los mensajes y envía el mensaje de retorno, tal como se indica mediante \DeltaT_{3}. El período de latencia T_{L} 52 es calculado por tanto por el gestor de latencia, siendo T_{L} = \DeltaT_{1} + \DeltaT_{2} + \DeltaT_{3}. El gestor de latencia escribe seguidamente la entrada 38b en la tabla de asignación 36 para indicar que a continuación del período de latencia, se puede esperar un mensaje de retorno 54 desde el nodo respondedor 40 al abonado 14c.

En consecuencia, el canal 22c es asignado en el instante T_{0} + T_{L} para el abonado 14c. El mensaje de retorno 54 es enviado por el nodo respondedor 40, y recibido por el procesador de la estación base 16, en el instante T_{0} + T_{L}. De acuerdo con la tabla de asignación 36, el programador 28 asigna el canal 22c para transmitir el mensaje de retorno 54 al abonado 14c.

En realizaciones alternativas, los canales son programados como una agrupación general en la tabla de asignación, y no son asignados a un abonado específico hasta que se recibe realmente el mensaje de retorno.

En el ejemplo anterior, el gestor de latencia 34 calcula el período de latencia T_{L} 52 sobre la base del tipo del mensaje y el mensaje de retorno correspondiente esperado. Muchos protocolos, incluyendo el protocolo TCP/IP, especifican no sólo el mensaje de retorno, sino también otros parámetros de transmisión. La manera de determinar el período de latencia depende por tanto de cierto número de factores que dependen del protocolo en uso. En un protocolo TCP/IP, tales factores pueden incluir parámetros de transmisión tales como tamaño de la ventana, espacio libre en la ventana, tamaño medio de los mensajes, número de mensajes de aceptación pendientes, tipo de mensaje, número de mensajes recibidos en la sesión, número de mensajes de aceptación pendientes, número máximo de mensajes de aceptación pendientes, y otros parámetros de transmisión. Por ejemplo, TCP/IP emplea una propiedad de mejora del comportamiento de ventana deslizante, tal como se define en Internet RFC 1323. Tales propiedades se pueden emplear en unión con los parámetros de transmisión para mejorar el comportamiento a través de un procesador de estación base tal como se define aquí.

Una red TCP/IP puede operar de acuerdo con el protocolo de ventana deslizante en un esfuerzo para proporcionar un suministro de corriente fiable a la vez que se maximiza el ancho de banda. Bajo este protocolo, ambos puntos finales de una TCP/IP negocian un tamaño de ventana aceptable. El tamaño de la ventana designa un número máximo de octetos que pueden ser transmitidos por una unidad emisora antes de recibir una aceptación desde la unidad receptora. Generalmente, se hace referencia a la ventana en términos de número máximo de lotes no aceptados. Una vez que la unidad emisora recibe una aceptación para el primer lote en la ventana, "desliza" la ventana a lo largo y envía el lote siguiente.

En el mensaje 42 enviado en el ejemplo de Fig. 3a, el gestor de latencia examina el lote TCP/IP de manera no destructiva para determinar el tipo del mensaje. Otros aspectos del lote TCP/IP, enumerados más arriba, podrían ser examinados también para obtener parámetros de transmisión, y emplear estos parámetros para determinar el período de latencia 52 asociado con el mensaje de retorno. En los ejemplos que siguen en Fig. 4 y 5a-5c, el gestor de latencia 34 incluye además una tabla 56 de perfiles de abonados para memorizar parámetros de transmisión correspondientes a cada uno de los abonados 14.

Haciendo referencia al diagrama de flujo representado en Fig. 4 junto con el diagrama del sistema de Fig. 3a, un mensaje es recibido en el procesador de la estación base 16, tal como se muestra en la etapa 100. El gestor de latencia 34 examina la información del lote TCP/IP, tal como se describe en la etapa 102. Se efectúa una búsqueda en la tabla de perfiles de abonados para encontrar la entrada correspondiente al abonado, tal como se representa en la etapa 104. Se recuperan los parámetros de transmisión correspondientes, tal como se muestra en la etapa 106. Los parámetros de transmisión se actualizan para reflejar la información del lote TCP/IP examinado en la etapa 102, tal como se describe la etapa 108. Se hace una determinación para indicar si se espera un mensaje de retorno para complementar el mensaje, tal como se representa en la etapa 110. Si no se espera mensaje alguno, se envía el mensaje, tal como se muestra en la etapa 120, y el control vuelve a la etapa 100 hasta que se recibe el mensaje siguiente, tal como se describe en la etapa 122. Si se espera un mensaje de retorno, el gestor de latencia 34 calcula el período de latencia 52 usando los parámetros de transmisión del abonado actualizados en la etapa 108, tal como se representa en la etapa 112. Una nueva entrada correspondiente al período de latencia 52 calculado se memoriza en la tabla de asignación 36, tal como se muestra en la etapa 114. El mensaje es enviado seguidamente al nodo respondedor 40, tal como se representa en la etapa 116. El control vuelve a la etapa 118 hasta que se recibe el mensaje siguiente.

En Fig. 5a-5c se muestra en mayor detalle otra realización de la secuencia de transmisión de mensajes de Fig. 3b. Una solicitud de conexión 42 es enviada por el ordenador personal 12 en el instante T_{0}. El gestor de latencia 34 examina la información del lote y determina el abonado 14d. El gestor de latencia busca los parámetros de transmisión del abonado 14d en la tabla 56 de perfiles de abonados, y actualiza los parámetros en consecuencia para corresponder a la nueva información del lote. El gestor de latencia 34 determina que un mensaje de aceptación de conexión 54 es esperado como mensaje de retorno. El gestor de latencia calcula las demoras de latencia \DeltaT_{1}, \DeltaT_{2} e \DeltaT_{3} como resultado de los parámetros de transmisión actualizados, y calcula el período de latencia T_{A} como el resultado T_{A} = \DeltaT_{1} + \DeltaT_{2} + \DeltaT_{3}. El gestor de latencia 34 memoriza la entrada 58 en la tabla de asignación 36 para informar al programador para asignar el canal 22d para el abonado 14d en el instante TA, tal como se indica mediante la entrada 68 en el diagrama de cadencia 86.

El nodo respondedor 40 envía seguidamente el mensaje de retorno 54. El procesador de la estación base 16 recibe el mensaje de retorno 54, y el gestor de latencia 34 examina la información del lote. El gestor de latencia busca los parámetros de transmisión del abonado 14d en la tabla 56 de perfiles de abonados, y actualiza la entrada en consecuencia. El gestor de latencia 34 determina que el tipo del mensaje de retorno es una aceptación de respuesta de conexión, y que un mensaje de solicitud será enviado probablemente desde el ordenador personal como mensaje de retorno.

Al ser enviado el mensaje al abonado 14d, el período de latencia se calcula como sigue. El tiempo de propagación sin hilos \DeltaT_{4} es indicativo de la latencia asociada con la transmisión por medio de la conexión sin hilos 26 entre el procesador de la estación base 16 y el abonado 14d. El tiempo de respuesta del abonado \DeltaT_{5} es indicativo de la latencia asociada con la transmisión por medio de la línea cableada 20 entre el abonado 14d y el ordenador personal 12. En consecuencia, el gestor de latencia 34 usa la tabla de perfiles de abonados para calcular el período de latencia \DeltaT_{B} a partir de \DeltaT_{4} + \DeltaT_{5}. Una entrada correspondiente 60 es escrita en la tabla de asignación 36 para informar al programador que debe asignar el canal 22f para el abonado 14d en el instante T_{B}, tal como se indica mediante la entrada 70 en el diagrama de cadencia 86.

El ordenador personal 12 envía un mensaje de obtención HTTP 78 tras recibir el mensaje de aceptación 54. Los parámetros de transmisión correspondientes se buscan en la tabla 56 de perfiles de abonados, y se actualizan en consecuencia para corresponder al mensaje 78. Como resultado de los parámetros de transmisión actualizados, el gestor de latencia 78 determina que un mensaje de aceptación de obtención HTTP 80 y un mensaje de datos HTTP 82 serán enviados probablemente como mensajes de retorno al mismo tiempo. En consecuencia, el gestor de latencia calcula el período de latencia \DeltaT_{C} a partir de \DeltaT_{C} = \DeltaT_{1} + \DeltaT_{2} + \DeltaT_{3}, y escribe dos entradas en la tabla de asignación 36. La entrada 62 asigna el canal 22d, y la entrada 64 asigna el canal 22e, para el abonado 14d en el instante T_{C}, tal como se muestra mediante las entradas 72 y 74 en el diagrama de cadencia 86.

Al ser recibido el mensaje de datos HTTP en el conmutador 16, el gestor de latencia 34 determina que un mensaje de aceptación de datos HTTP 84 es el mensaje de retorno, y escribe la entrada 66 para asignar el canal 22f en T_{D} = \DeltaT_{4} + \DeltaT_{5}, tal como se muestra mediante la entrada 76 en el diagrama de cadencia 86.

En Fig. 6 se muestra un ejemplo de la tabla 56 de perfiles de abonados. Cada entrada 86 está adaptada para memorizar los parámetros de transmisión 88 correspondientes a los mensajes recibidos por un abonado particular 14. Tales parámetros incluyen tamaño de la ventana, espacio disponible en la ventana, tamaño medio de los mensajes, número de mensajes de aceptación pendientes, tipo de mensaje, número de mensajes recibidos en la sesión, número de mensajes de aceptación pendientes, y número máximo de mensajes de aceptación pendientes. Se pueden especificar otros parámetros, tales como se definen en el protocolo TCP/IP u otro protocolo, según sean empleados por el procesador de la estación base.

Los expertos en la técnica apreciarán fácilmente que los programas que definen las operaciones y los métodos definidos aquí pueden ser suministrados al procesador de la estación base en muchas formas, que incluyen pero no se limitan a: a) información memorizada permanentemente en medios de memoria que no pueden ser escritos, tales como dispositivos ROM, b) información alterable memorizada en medios de memorización que pueden ser escritos, tales como disquetes, cintas magnéticas, discos compactos, dispositivos RAM, y otros medios magnéticos y ópticos, o c) información transferida a un ordenador a través de medios de comunicación, por ejemplo usando técnicas de señalización de banda base o de señalización de banda ancha, como en redes electrónicas tales como Internet o líneas por módem telefónicas. Las operaciones y los métodos se pueden implementar en un soporte lógico (software) ejecutable desde una memoria por un procesador. Alternativamente, las operaciones y los métodos se pueden realizar en todo o en parte usando componentes de equipo físico (hardware), tales como Circuitos Integrados de Aplicaciones Específicas (ASIC), máquinas de estado, controladores u otros componentes o dispositivos de hardware, o una combinación de componentes de hardware y software.

Claims (10)

1. Método de asignación de canales sin hilos en un sistema de comunicaciones de datos sin hilos, que comprende:

proporcionar una pluralidad de canales adaptados para transmitir mensajes a través de un procesador de estación base;

recibir un primer mensaje desde un emisor en dicho procesador de la estación base;

caracterizado por determinar un tipo descriptivo de dicho primer mensaje;

calcular un período de latencia asociado con un mensaje de retorno correspondiente a dicho tipo; y

programar uno de dichos canales adaptados para transmitir dicho mensaje de retorno para ser asignado en un instante que depende de dicho período de latencia.

2. Método según la reivindicación 1, que comprende además:

recibir dicho mensaje de retorno desde un nodo respondedor; y

transmitir dicho mensaje de retorno a dicho emisor por medio de dicho canal asignado.

3. Método según la reivindicación 1, en el que el cálculo de dicho período de latencia comprende además:

determinar una demora ISP:

determinar una demora de propagación de la red;

determinar una demora del nodo respondedor; y

agregar dicha demora de propagación de la red, dicha demora ISP, y dicha demora de respuesta del servidor para calcular dicho período de latencia.

4. Método según la reivindicación 1, en el que el cálculo de dicho período de latencia comprende además:

determinar una demora de propagación sin hilos;

determinar una demora de respuesta del abonado; y

agregar dicha demora de propagación sin hilos y dicha demora de respuesta del abonado.

5. Método según la reivindicación 1, y o bien:

a) en el que dicho emisor es un portal de acceso a Internet y dicho canal programado es operable además para recibir dicho mensaje de retorno desde dicho abonado, en cuyo caso, opcionalmente,

en el que dicho portal de acceso a Internet está adaptado para comunicar por medio de una red de acceso público; o

b) en el que dicho emisor es un abonado y dicho canal programado es operable además para transmitir dicho mensaje de retorno a dicho abonado, en cuyo caso, opcionalmente,

en el que dicho abonado es operable para comunicar con un dispositivo de ordenador personal; o

c) en el que dicha pluralidad de canales soportan comunicaciones a través de un medio de RF; o

d) en el que dicha programación comprende además:

leer dicho período de latencia desde una tabla de asignación adaptada para designar dichos canales en un instante predeterminado, y

asignar uno de dichos canales a dicho mensaje de retorno una vez que expira dicho período de latencia, en cuyo caso, opcionalmente,

en el que el cálculo de dicho período de latencia comprende además:

llamar a un gestor de latencia en comunicación con dicha tabla de asignación y operable para calcular dicho período de latencia; y

memorizar una entrada en dicha tabla de asignación indicativa de dicho período de latencia, o

e) en el que el cálculo de dicho período de latencia comprende además determinar un tamaño de ventana TCP/IP, en cuyo caso, opcionalmente,

en el que dicho tamaño de ventana es indicativo de un número de mensajes de retorno esperados.

6. Método según la reivindicación 2, en el que el cálculo de un período de latencia comprende además hacer referencia a una tabla de perfiles de abonados adaptada para memorizar parámetros de transmisión correspondientes a cada uno de dichos abonados, y, opcionalmente,

en el que hacer referencia comprende además:

determinar un abonado correspondiente a dicho mensaje de retorno;

indexar en dicha tabla de perfiles de abonados para encontrar una entrada de abonado correspondiente a dicho abonado correspondiente a dicho mensaje de retorno;

hacer referencia a por lo menos uno de dichos parámetros de transmisión correspondientes a dicho abonado; y

calcular dicho período de latencia como resultado de dichos parámetros de transmisión, en cuyo caso, aún opcionalmente,

en el que cada una de dichas entradas de abonados comprende además al menos un parámetro de transmisión indicativo de dichos mensajes de retorno correspondientes a dicho abonado, en cuyo caso, aún además opcionalmente,

en el que la transmisión de dicho mensaje de retorno es seguida por la actualización de dicha tabla de perfiles de abonados para corresponder a dicho mensaje de retorno, en cuyo caso, aún además opcionalmente,

en el que dichos parámetros de transmisión incluyen parámetros seleccionados entre el grupo que consiste en tamaño de la ventana, espacio disponible en la ventana, tamaño medio de los mensajes, número de mensajes de aceptación pendientes, tipo de mensaje, número de mensajes recibidos en la sesión, número de mensajes de aceptación pendientes, y número máximo de mensajes de aceptación pendientes.

7. Método de asignación de canales en un procesador de estación base, que comprende:

proporcionar un procesador de estación base que tiene una pluralidad de canales sin hilos adaptados para transmitir mensajes;

recibir un primer mensaje en dicho procesador de la estación base;

caracterizado por determinar un tipo descriptivo de dicho mensaje;

calcular un período de latencia asociado con un mensaje de retorno desde un nodo respondedor correspondiente a dicho tipo;

programar un canal de retorno entre dicha pluralidad de canales sin hilos adaptados para transmitir dicho mensaje de retorno para ser asignado a continuación de dicho período de latencia;

asignar dicho canal de retorno a dicho mensaje de retorno una vez que expira dicho período de latencia;

recibir dicho mensaje de retorno desde un nodo respondedor; y

transmitir dicho mensaje de retorno a dicho emisor por medio de dicho canal de retorno.

8. Sistema de comunicación de datos sin hilos que comprende:

un procesador de estación base;

una pluralidad de canales adaptados para transmitir mensajes sin hilos;

un programador operable para asignar dichos canales a dichos mensajes sin hilos en un instante predeterminado;

una tabla de asignación adaptada para memorizar dicho instante predeterminado; y

un gestor de latencia operable para determinar un período de latencia de un mensaje de retorno asociado con un mensaje transmitido y operable además para memorizar dicho instante predeterminado en dicha tabla de asignación sobre la base de dicho período de latencia;

en el que dicho programador asigna dichos canales a dichos mensajes sin hilos de acuerdo con dicho instante predeterminado en dicha tabla de asignación.

9. Sistema de comunicación de datos sin hilos según la reivindicación 8, y o bien:

a) en el que dicho gestor de latencia determina dicho instante predeterminado sobre la base de un mensaje de retorno, en cuyo caso, opcionalmente, o bien:

i) en el que dicho mensaje de retorno es enviado en respuesta a un primer mensaje enviado desde dicho procesador de la estación base, en cuyo caso, aún opcionalmente,

en el que dicho primer mensaje tiene un tipo indicativo de dicho período de latencia, en cuyo caso, aún además opcionalmente,

en el que dicho gestor de latencia es operable además para calcular dicho período de latencia en respuesta a dicho tipo; o

ii) en el que dicho mensaje de retorno es conforme a un protocolo, y, opcionalmente,

en el que dicho protocolo es TCP/IP, en cuyo caso, aún opcionalmente,

en el que dicho mensaje de retorno es un mensaje de aceptación; o

b) en el que dicho procesador de la estación base es operable para comunicar con una pluralidad de abonados por medio de dicha pluralidad de canales, en cuyo caso, opcionalmente,

en el que dichos canales son operables para enviar dicho mensaje de retorno a por lo menos uno de dichos abonados, o

en el que dichos canales son operables para recibir dicho mensaje de retorno desde por lo menos uno de dichos abonados; o

c) en el que dicho gestor de latencia es operable además para calcular dicho período de latencia como resultado de una demora de propagación de la red, una demora de direccionamiento ISP, y una demora del nodo respondedor; o

d) en el que en el que dicho gestor de latencia es operable además para calcular dicho período de latencia como resultado de una demora de propagación sin hilos y una demora de respuesta del abonado; o

e) en el que dicho gestor de latencia incluye además una tabla de perfiles de abonados y dicho gestor de latencia es operable además para calcular dicho período de latencia sobre la base de dicha tabla de perfiles de abonados, en cuyo caso, opcionalmente,

en el que dicha tabla de perfiles de abonados está adaptada para memorizar entradas correspondientes a por lo menos uno de dichos abonados, en cuyo caso, aún opcionalmente,

en el que dichas entradas incluyen parámetros de transmisión correspondientes a dichos abonados, en cuyo caso, aún además opcionalmente,

en el que dichos parámetros de transmisión incluyen parámetros seleccionados entre el grupo que consiste en tamaño de la ventana, espacio disponible en la ventana, tamaño medio de los mensajes, número de mensajes de aceptación pendientes, tipo de mensaje, número de mensajes recibidos en la sesión, número de mensajes de aceptación pendientes y número máximo de mensajes de aceptación pendientes; o

f) en el que dichos canales son operables para comunicar en un protocolo sin hilos; o

g) en el que dichos canales son operables para comunicar por medio de un medio de RF; o

h) que comprende además un direccionador de línea cableado, en el que dicho direccionador de línea cableado es operable para comunicar con un dispositivo de ordenador remoto, en cuyo caso, opcionalmente,

en el que dicho dispositivo de ordenador remoto es una unidad de servidor de red adaptada para comunicar por medio de una red de acceso público, en cuyo caso, aún opcionalmente,

en el que dicha red de acceso público es Internet.

10. Sistema para gestionar la asignación de canales sin hilos, que comprende:

un procesador de estación base que tiene una pluralidad de canales operables para transmitir una pluralidad de mensajes sin hilos;

al menos un abonado operable para comunicación con dicho procesador de la estación base por medio de dichos canales;

una tabla de asignación adaptada para memorizar un instante predeterminado indicativo de cuál de dichos canales asignar en dicho instante predeterminado;

un gestor de latencia operable para calcular un período de latencia y operable además para memorizar dicho instante predeterminado sobre la base de dicho período de latencia;

un programador en comunicación con dicha tabla de asignación y operable para asignar dichos canales a dichos mensajes sin hilos;

en el que dicho programador asigna dichos canales a dichos mensajes sin hilos de acuerdo con dicho instante predeterminado en dicha tabla de asignación.