Comunicacion Inalambrica Para Robots

Sistema de comunicaciones inalámbricas para robots ÍNDICE DE CONTENIDOS 1.

2.

3.

4.

5. 6.

INTRODUCCIÓN..................................................................................................................... 4 1.1. PRESENTACIÓN ............................................................................................................ 4 1.2. ESTRUCTURA DEL PROYECTO ..................................................................................... 6 ESTUDIO TEÓRICO-PRÁCTICO SOBRE LAS COMUNICACIONES ............................................. 7 2.1. CONSIDERACIONES SOBRE ENTORNOS DE RED INALÁMBRICOS ................................. 7 2.1.1. CARACTERÍSTICAS PROPIAS DEL MEDIO INALÁMBRICO..................................... 7 2.1.2. ALTERNATIVAS DE INFRAESTRUCTURA .............................................................. 7 2.1.3. ASPECTOS PRÁCTICOS DE UNA WLAN ............................................................. 10 2.2. ANÁLISIS DE PROTOCOLOS DE TRANSPORTE EN REDES INALÁMBRICAS................... 12 2.2.1. ASPECTOS TEÓRICOS ........................................................................................ 12 2.2.1.1. ARQUITECTURA DE PROTOCOLOS TCP/IP............................................... 12 2.2.1.2. CONTROL DE FLUJO ................................................................................. 15 2.2.1.3. CONTROL DE ERRORES ............................................................................. 18 2.2.1.4. EL NIVEL DE TRANSPORTE ....................................................................... 21 2.2.2. CARACTERIZACIÓN DE LOS PROTOCOLOS TCP Y UDP SOBRE PLATAFORMAS INALÁMBRICAS ................................................................................................................... 23 2.2.3. CONCLUSIONES DEL ANÁLISIS DE PROTOCOLOS .............................................. 30 SISTEMA PROTOTIPO .......................................................................................................... 31 3.1. DEFINICIÓN DEL MARCO DE TRABAJO ...................................................................... 31 3.2. HARDWARE ................................................................................................................ 32 3.2.1. HARDWARE E INFRAESTRUCTURA DISPONIBLE. .............................................. 32 3.2.1.1. PLACA PC104+......................................................................................... 32 3.2.1.2. HARDWARE DE ESTACIÓN BASE E INFRAESTRUCTURA DE RED ............... 33 3.2.2. SELECCIÓN DE HARDWARE ............................................................................... 34 3.2.2.1. PC104-PCMCIA-1................................................................................... 34 3.2.2.2. ORINOCO PC CARD SILVER ..................................................................... 34 3.2.2.3. ORINOCO WIRELESS RANGE EXTENDER ANTENNA ................................ 35 3.2.2.4. ORINOCO AP-500 ..................................................................................... 36 3.2.2.5. WIDE-ANGLE ANTENNA ........................................................................... 36 3.3. SOFTWARE BÁSICO .................................................................................................... 39 3.3.1. SISTEMA OPERATIVO DE LA ESTACIÓN BASE .................................................... 39 3.3.2. SISTEMA OPERATIVO DE LAS ESTACIONES MÓVILES :QNX ............................. 39 3.4. CONFIGURACIÓN DEL HARDWARE E INFRAESTRUCTURA ......................................... 40 3.4.1. SOFTWARE DE GESTIÓN ORINOCO.................................................................... 40 3.4.2. CONFIGURACIÓN DE LA INTERFAZ INALÁMBRICA SOBRE QNX....................... 42 SOFTWARE DE COMUNICACIONES ...................................................................................... 44 4.1. PROPUESTA DE SOLUCIÓN DE SOFTWARE DE COMUNICACIÓN ................................. 44 4.1.1. MODELO CLIENTE - SERVIDOR ......................................................................... 45 4.1.2. API DE COMUNICACIONES ................................................................................ 46 4.2. STCP (SIMPLEX TCP) ............................................................................................... 47 4.2.1. DISEÑO GENERAL DEL PROTOCOLO (POSIBLES SOLUCIONES)......................... 47 4.2.2. DESCRIPCIÓN DEL PROTOCOLO STCP.............................................................. 51 4.2.2.1. DECLARACIÓN DEL PROTOCOLO A NIVEL DE COMUNICACIÓN ................ 51 4.2.2.2. DECLARACIÓN DEL PROTOCOLO A NIVEL DE TRAMA ............................... 52 4.2.2.3. DECLARACIÓN DEL PROTOCOLO A NIVEL DE FIABILIDAD ....................... 55 4.2.2.4. DECLARACIÓN DEL PROTOCOLO A NIVEL DE INTERFAZ DE USUARIO ..... 65 4.3. APLICACIONES DE EJEMPLO...................................................................................... 69 4.3.1. APLICACIÓN DE TRANSFERENCIA DE FICHEROS .............................................. 69 4.3.2. APLICACIÓN PARA MÚLTIPLES COMUNICACIONES SIMULTÁNEAS ................... 70 CONCLUSIONES Y TRABAJO FUTURO .................................................................................. 75 REFERENCIAS BIBLIOGRÁFICAS ........................................................................................ 76 6.1. ENLACES DE INTERNET CONSULTADOS .................................................................... 76 6.2. LIBROS Y REVISTAS TÉCNICAS CONSULTADOS .......................................................... 76

-1-

Sistema de comunicaciones inalámbricas para robots FIGURAS FIGURA 1.1: CABRIT ................................................................................................................... 4 FIGURA 1.2: ESQUEMA DEL PROYECTO ........................................................................................ 5 FIGURA 2.1: FUNCIONAMIENTO DE UNA ARQUITECTURA DE PROTOCOLOS SIMPLIFICADA ...... 13 FIGURA 2.2: MODELO DE ARQUITECTURA DE PROTOCOLOS TCP/IP ........................................ 14 FIGURA 2.3: MODELO PARA LA TRANSMISIÓN DE TRAMAS ........................................................ 15 FIGURA 2.4: MODELO PARA LA TRANSMISIÓN DE TRAMAS MEDIANTE VENTANA DESLIZANTE. 16 FIGURA 2.5:EJEMPLO DE PROTOCOLO DE VENTANA DESLIZANTE ............................................ 17 FIGURA 2.6: ARQ CON PARADA Y ESPERA (“STOP & WAIT”) .................................................... 19 FIGURA 2.7: ARQ ADELANTE ATRÁS N (“GO BACK N”) ............................................................ 20 FIGURA 2.8: ARQ CON RECHAZO SELECTIVO (“SELECTIVE REJECT”) ..................................... 21 FIGURA 2.9: FORMATO DE CABECERA TCP ............................................................................... 22 FIGURA 2.10: FORMATO DE CABECERA UDP............................................................................. 23 FIGURA 2.11: THROUGHPUT IDEAL UDP................................................................................... 27 FIGURA 2.12: THROUGHPUT IDEAL TCP.................................................................................... 28 FIGURA 2.13: COMPORTAMIENTO TCP CON BAJO SNR EN WLAN........................................... 29 FIGURA 3.1: ZONAS A CUBRIR .................................................................................................... 31 FIGURA 3.2: PLACA PC104+ (JUMPTEC MOPSLCD6).............................................................. 32 FIGURA 3.3: EQUIPO DE DESARROLLO. ...................................................................................... 33 FIGURA 3.4: PC104-PCMCIA-1................................................................................................. 34 FIGURA 3.5: LUCENT ORINOCO PC CARD SILVER ..................................................................... 35 FIGURA 3.6: ORINOCO WIRELESS RANGE EXTENDER ANTENNA .............................................. 36 FIGURA 3.7: ORINOCO AP-500 ................................................................................................... 36 FIGURA 3.8: 12 DBI DIRECTIONAL WIDE ANGLE ANTENNA ...................................................... 39 FIGURA 3.9: INTERFAZ GRÁFICO DE QNX ................................................................................. 39 FIGURA 3.10: ACCESO A LA GESTIÓN DEL AP ............................................................................ 41 FIGURA 3.11: CONFIGURACIÓN DE LA SEGURIDAD EN LA RED WLAN ..................................... 41 FIGURA 3.12: ESTACIONES ASOCIADAS AL PUNTO DE ACCESO. ................................................. 42 FIGURA 3.13: FICHEROS DE CONFIGURACIÓN DE LA INTERFAZ INALÁMBRICA SOBRE QNX.... 43 FIGURA 4.1: ESTRUCTURA DE INTERFACES DE COMUNICACIONES ............................................ 46 FIGURA 4.2: ESTRUCTURA DEL PROCESO DE ENTRADA TCP/IP................................................ 48 FIGURA 4.3: PRIMER DISEÑO STCP ........................................................................................... 50 FIGURA 4.4: FORMATO DE CABECERA STCP ............................................................................. 52 FIGURA 4.5: COMPARACIÓN TAMAÑO CABECERAS TCP Y UDP ................................................ 54 FIGURA 4.6: FUNCIONALIDAD DEL NIVEL DE TRAMAS .............................................................. 55 FIGURA 4.7: DISEÑO DE LA GESTIÓN DE TEMPORIZADORES ..................................................... 56 FIGURA 4.8: DISEÑO DE LA GESTIÓN DE TEMPORIZADORES DEFINITIVO ................................. 57 FIGURA 4.9:FASE DE ESTABLECIMIENTO DE COMUNICACIÓN STCP ........................................ 59 FIGURA 4.10: EJEMPLO DE ENVÍO DE PAQUETES STCP............................................................ 61 FIGURA 4.11: EJEMPLO DE RECEPCIÓN DE PAQUETES STCP ................................................... 62 FIGURA 4.12:FASE DE CIERRE DE COMUNICACIÓN STCP......................................................... 63 FIGURA 4.13: ESTRUCTURA PARA LAS VARIABLES DE CONEXIÓN STCP ................................... 64 FIGURA 4.14: ESTRUCTURA DEL PROCESO PARA MÚLTIPLES COMUNICACIONES ..................... 64 FIGURA 4.15: EJEMPLO DE FICHERO DE REGISTRO STCP ........................................................ 65 FIGURA 4.16: CONTENIDO DEL FICHERO STCPEVENTS.H........................................................ 66 FIGURA 4.17: EJEMPLO DE DECLARACIÓN DE LA FUNCIÓN PARA GESTIÓN DE EVENTOS ......... 68 FIGURA 4.18: EJEMPLO DE TRANSFERENCIA DE FICHERO........................................................ 70 FIGURA 4.19: VENTANA PARA LA GESTIÓN DE UNA COMUNICACIÓN STCP. ............................. 71 FIGURA 4.20: EJEMPLO DE COMPROBACIÓN DEL ENTORNO GRÁFICO. ..................................... 72 FIGURA 4.21: FUNCIÓN DEL BOTÓN EXAMINAR ......................................................................... 73 FIGURA 4.22: BLOQUEO EN ESPERA DE RECIBIR MENSAJE NUEVO ........................................... 73 FIGURA 4.23: EJEMPLO DE DOS COMUNICACIONES ACTIVAS. ................................................... 74 FIGURA 5.1: APLICACIÓN ENLACE DE COMUNICACIONES. ........................................................ 75

-2-

Sistema de comunicaciones inalámbricas para robots TABLAS TABLA 2.1.: COMPARACIÓN TASA DE ERROR POR BIT. ............................................................... 24 TABLA 2.2.: DIFERENTES PROPUESTAS PARA LA ARQUITECTURA DE RED CABLEADAINALÁMBRICA. .................................................................................................................... 25 TABLA 2.3: RESULTADOS TESTS THROUGHPUT EN CANAL CON Y SIN ERRORES ........................ 29 TABLA 3.1.:RELACIÓN ENTRE MODELOS DE CABLE Y PÉRDIDA DE SEÑAL ................................ 38 TABLA 4.1: CONSTANTES NUMÉRICAS DE LOS TIPOS DE TRAMA DEFINIDOS............................. 53

-3-

Sistema de comunicaciones inalámbricas para robots

1. INTRODUCCIÓN 1.1. PRESENTACIÓN Este documento presenta un proyecto de ingeniería técnica en telecomunicaciones que forma parte de otro proyecto de mayor envergadura dentro del grupo SRV (Systems, Robotics and Vision Group) de la Universitat de les Illes Balears consistente en la creación de una flota de robots autónomos capaces de llevar a cabo misiones de relativa complejidad. Las líneas de investigación del grupo dentro del campo de la robótica apuntan hacia el estudio y diseño de arquitecturas de control para robots móviles, desarrollo de prototipos para robots móviles así como el diseño y desarrollo de entornos de simulación para robots móviles específicamente orientado a entrenamiento y test. Uno de los componentes de esta flota es el CABRIT (Car Based Robot for Intelligent Transport) (Figura 1.1), un robot autónomo terrestre montado sobre una base de coche de radio control y dotado de diversos sensores tales como infrarrojos, sonars y brújula electrónica que le permiten interactuar con el entorno que le rodea así como cierta capacidad de inteligencia proporcionada por un microcontrolador y un ordenador de abordo.

Figura 1.1: CABRIT

Siguiendo las líneas de investigación del grupo surge la necesidad de disponer de comunicaciones fiables para el control y/o la monitorización de estos robots, y teniendo como base el CABRIT, se desea obtener un sistema completo para la comunicación entre una estación base y los robots así como entre los propios robots. Esta es, por tanto, la finalidad del presente proyecto. Las bases sobre las que se van a trabajar durante el desarrollo de este proyecto, están fundamentadas en la robótica y en las comunicaciones. Obviamente el hecho de trabajar con robots móviles obliga a pensar en comunicaciones inalámbricas de forma que no limiten esa movilidad. Trabajar con redes inalámbricas requiere unas consideraciones especiales que también serán tratadas durante este documento. En la figura 1.2 podemos ver un primer esbozo de los objetivos del proyecto.

-4-

Sistema de comunicaciones inalámbricas para robots

Figura 1.2: Esquema del proyecto

Concretando el objetivo de este proyecto, podemos decir que consiste en adquirir los elementos y herramientas necesarias para dotar de comunicación a la flota anteriormente mencionada. Este objetivo se afronta de forma que abarca todos los aspectos, tanto hardware como software. Como marco general se distinguen tres tipos de datos que el sistema deberá ser capaz de transmitir: - Ordenes o comandos; será el tipo de dato más común que se transmita. Como posibles ejemplos serían; petición de distancias, petición de orientación, velocidad, o incluso ordenes como “frenada de emergencia” o “vuelta a casa”. - Imágenes; en momentos determinados, podría ser necesario el envío de imágenes a fin de obtener una vista estática desde la posición del vehículo. Cabe recalcar que no se trata de transmisión de vídeo sino la obtención de una imagen estática desde el punto de vista del vehículo en un determinado momento. - Ficheros; como consecuencia del trabajo con robots móviles es de gran utilidad obtener una herramienta para transmitir ficheros desde una máquina sobre la que se realiza la programación hasta el robot en el cual se va a ejecutar este código. En este caso concreto, cabe mencionar que, a diferencia de los otros tipos de datos con los que trabajaremos, la transferencia de ficheros no tiene requerimientos de tiempo real, pero si de integridad del fichero. Para acabar con la introducción es importante mencionar que el hecho de transmitir ordenes, comandos o imágenes no tiene como finalidad el control remoto de estos robots, como ya se ha dicho, estos son robots autónomos que disponen de cierta inteligencia para tomar, dentro de sus capacidades, decisiones sobre el comportamiento a adoptar.

-5-

Sistema de comunicaciones inalámbricas para robots

1.2. ESTRUCTURA

DEL PROYECTO

A la hora de afrontar la realización del proyecto se diferencian claramente tres partes, que serán documentadas en el mismo orden de realización. El comienzo de este proyecto arrancó con un estudio del entorno con el que nos vamos a enfrentar (redes inalámbricas) que finalmente ha producido el primer bloque importante, dejando de ser un estudio inicial para pasar a ser una fase muy importante del desarrollo del proyecto, la segunda parte no es más que el hardware y software básico necesario para suministrar las comunicaciones y la tercera es el software desarrollado que nos permitirá comunicar los diferentes terminales. Primera parte: Estudio teórico-práctico sobre las comunicaciones Esta primera parte determina muchas de las decisiones tomadas a lo largo del proyecto afectando tanto a la parte de hardware como a la de software. La documentación de este bloque pretende, en primer lugar, mostrar las consideraciones necesarias que hay que tener en cuenta en este nuevo entorno y como esto afecta a cada una de las partes del proyecto y en segundo lugar dar a conocer estudios y antecedentes sobre el comportamiento de las comunicaciones en redes inalámbricas mostrando las conclusiones obtenidas a partir de estos estudios. Segunda parte: Sistema prototipo Por ‘sistema prototipo’ entendemos el hardware del que disponemos y el nuevo hardware necesario para alcanzar los objetivos planteados así como el software base necesario para su funcionamiento, es decir, software de instalación y configuración junto con los sistemas operativos. Este es el siguiente frente de actuación, de forma que partiendo del hardware disponible y atendiendo a las necesidades de este se deberá seleccionar el nuevo material para cubrir las necesidades del proyecto. Dentro de este frente, podríamos distinguir el hardware de la estación móvil (los robots) y el de la estación base, así mismo, también dentro de esta primera parte se tendrá en cuenta la configuración de todos los elementos. Diferenciamos entonces dos puntos dentro de esta primera parte: - Selección del hardware apropiado y montaje de la infraestructura. - Instalación del software y configuración de los elementos hardware. Tercera parte: Software de comunicaciones. Como ya se ha comentado, una vez que tenemos la infraestructura necesaria montada y funcionando, será necesario un software que ofrezca una interface que finalmente trabaje con los datos que pretendemos transmitir. Esta tercera parte de diseño e implementación es la que tiene más peso en el proyecto ya que conlleva un estudio concienzudo de las posibilidades e implica decisiones que afectarán directamente al comportamiento de las comunicaciones. Dentro de esta tercera parte se puede diferenciar entre un primer punto de diseño de las comunicaciones y otro de implementación. Estas dos fases están estrechamente relacionadas entre ellas de forma que muchos aspectos de la implementación afectan en el diseño y viceversa.

-6-

Sistema de comunicaciones inalámbricas para robots

2. ESTUDIO TEÓRICO-PRÁCTICO SOBRE LAS COMUNICACIONES En este capítulo se pretende dar a conocer de forma general las características y herramientas que nos encontramos en el entorno del proyecto, así como los aspectos teóricos que manejaremos a lo largo del desarrollo del mismo.

2.1. CONSIDERACIONES SOBRE ENTORNOS DE RED INALÁMBRICOS Como ya se comentó en la introducción, el hecho de trabajar en entornos inalámbricos obliga a tener en cuenta numerosos aspectos que son inherentes al medio de transmisión así como la repercusión de estos efectos en los niveles superiores. Con esta finalidad, se hace inevitable hablar de capas, niveles, estándares y protocolos, puesto que, lógicamente, las redes inalámbricas no dejan de ser redes de computadores.

2.1.1.

Características propias del medio inalámbrico.

Las redes inalámbricas locales en muchas ocasiones son planteadas como una red de computadores sin hilos sin más consideración y esto es sin duda un grave error puesto que las características del medio físico, al ser un medio no guiado, presenta unas notables diferencias con otros medios existentes. A pesar de que la teoría nos dice que las diferentes capas de la arquitectura TCP/IP son independientes, en realidad utilizar el aire como medio de transmisión afecta a muchos aspectos de las capas superiores haciendo obligatoria la reflexión sobre las ventajas e inconvenientes de este medio. A continuación mencionaremos, las características que hay que tener presentes al trabajar con este medio: - Es un medio no controlado en el sentido de que al ser no guiado, el acceso al medio es mucho más difícil de controlar. - El rango de cobertura real es muy difícil de conocer. - No se puede limitar voluntariamente la cobertura. No es posible limitar la cobertura a la zona deseada puesto que las “zonas de sombra” o de “exceso de cobertura” no se pueden controlar al 100% - No es estable. Cambios atmosféricos, del entorno, de aparejos electrónicos, etc.. nos modifican dinámicamente la cobertura. - Las WLAN son más lentas. En general se entiende una WLAN como una extensión de la LAN existente. La velocidad entre estas dos topologías puede ser muy diferente. - Las WLAN requieren configuración. Debido a muchos de los puntos mencionados, y sobre todo por motivos de seguridad las redes inalámbricas requieren una configuración y gestión más cuidadosa que las LAN.

2.1.2.

Alternativas de infraestructura

Una vez fijados los objetivos a cumplir, debemos conocer cual será la mejor forma de alcanzar estos objetivos, en el mercado actual existen diferentes estándares de tecnologías inalámbricas que definen los primeros niveles de la arquitectura TCP/IP (nivel físico y de acceso a la red en al mayoría de los casos). A continuación describiremos muy brevemente algunas de estas tecnologías para seleccionar la más adecuada. -7-

Sistema de comunicaciones inalámbricas para robots -

GPRS (General Packet Radio Service) es un servicio que permite el intercambio de datos a través de una red de telefonía móvil. GPRS se basa en la conmutación de paquetes realizando la transmisión sobre la red GSM e IP. Los paquetes se envían utilizando todas las rutas disponibles, en vez de esperar una especifica, lo que aumenta la velocidad de transmisión con respecto a la red GSM-DATA. Aparte de la velocidad de transferencia, la mayor diferencia con una conexión GSM es que los usuarios de una célula comparten el mismo canal de conexión, sobre el que emiten sus paquetes IP, en vez de utilizar un circuito de voz diferente para cada usuario. Ente sus características podemos citar su velocidad máxima teórica de 171,2 kbps .

-

Bluetooth es una tecnología diseñada para permitir conectividad inalámbrica entre terminales digitales a corta distancia. A diferencia de otros estándares, Bluetooth incluye dos capas; la capa de enlace y la de aplicación para los desarrolladores de productos que soporten datos, voz y aplicaciones de contenido centralizado. Los dispositivos que soportan esta tecnología no requieren licencia y trabajan en el espectro de 2,4GHz. Estos dispositivos usan FHSS1. Destacamos entre sus características las siguientes; o Es capaz de establecer y mantener más de 6 conexiones simultáneas o Cada dispositivo tiene una dirección única de 48 bits basada en el estándar 802.11 o Las conexiones son uno a uno con un rango máximo de 10 metros, aunque mediante el uso de repetidores se puede lograr un alcance de aproximadamente 100 metros con algo de distorsión. o El ancho de banda que se alcanza entre dispositivos es 1 Mbps (vers 1.1)

-

802.11a utilizando la banda de frecuencia de 5GHz se diseñó para la conexión de las distintas WLAN. Este estándar se basa en OFDM2 y utiliza 8 ó 4 canales. Esta norma es incompatible con el resto de tecnologías. Podemos destacar las siguientes características; o Velocidad de 55Mbps con caídas a 48Mbps, 36Mbps, 24Mbps, 18Mbps, 12Mbps, 8Mbps y 6Mbps dependientes de la distancia. o Rango aproximado de 7,6 metros en interiores hasta 50 metros en exteriores dependiendo de las interferencias. o Debido a la frecuencia de trabajo (5GHz), la atenuación es muy elevada, y por tanto se hace necesario transmitir a más potencia y

1 FHSS – (Frequency Hopping Spread Spectrum).Técnica de transmisión del Espectro Amplio (Spread Spectrum) que, al igual que Ethernet, divide los datos en paquetes de información pero que, por motivos de seguridad, para dificultar su interceptación por terceros, los envía a través de varias frecuencias (Hopping Pattern) seleccionadas al azar y que no se superponen entre sí. Para llevar acabo la transmisión además es necesario que tanto el aparato emisor como el receptor coordinen este "Hopping Pattern". 2 OFDM – (Orthogonal Frequency Division Multiplexing )Técnica de modulación FDM para transmitir grandes cantidades de datos digitales a través de ondas de radio. OFDM divide la señal de radio en múltiples subseñales más pequeñas que luego serán transmitidas de manera simultánea en diferentes frecuencias al receptor. OFDM reduce la cantidad de ruido (crosstalk) en las transmisiones de señal.

-8-

Sistema de comunicaciones inalámbricas para robots además es necesario un mayor número de células para cubrir la misma distancia. o El mercado actual dispone de un “reducido” número de productos que cumplen este estándar. -

802.11b es el estándar más extendido y barato (entre 802.11a, 802.11b y 802.11g ), funciona a una frecuencia de 2,4GHz y puesto que esta banda está más colapsada las interferencias son mayores y utiliza 3 canales. Utiliza una tecnología de DSSS3 y CSMA-CA (Collision Avoidance). Destacamos las siguientes características: o Velocidad de 11Mbps con caídas a 5,5Mbps, 2Mbps y 1Mbps. o Certificado Wi-Fi (Wireless Fidelity). o Es el estándar más conocido y soportado por los fabricantes por tanto es el más accesible. o Rango de cobertura; En interiores: 30 metros a 11Mbps – 90 metros a 1Mbps En exteriores: 120 metros a 11Mbps –460 metros a 1Mbps

-

802.11g nace por una necesidad de compatibilidad con 802.11b, por tanto trabaja a la misma frecuencia (2,4GHz). Mejora el ancho de banda hasta un máximo de 54Mbps aunque el precio de los dispositivos sigue siendo mayor al de los dispositivos 802.11b y la compatibilidad con 802.11b limita esta velocidad máxima de 54Mbps ya que si trabajan bajo la misma red dispositivos de los dos estándares se reduce el ancho de banda para todos a 11Mbps. Podemos destacar lo siguiente: o Ancho de banda de hasta 54Mbps . o Compatible con 802.11b. o Precio y accesibilidad peores que 802.11b o Rango de cobertura entre 30 metros y 56 metros aproximadamente.

Tenemos por tanto que tomar una decisión sobre la tecnología a utilizar, y teniendo presentes los objetivos y el marco de trabajo podríamos destacar, entre otros, los siguientes motivos que nos han llevado a elegir el estándar 802.11b como base para nuestro proyecto: - El hecho de que 802.11b sea el estándar más extendido y barato es muy beneficioso puesto que vamos a trabajar con software un tanto especial que nos obliga a buscar las soluciones más comunes en el mercado - Entre los objetivos a cumplir, se encuentra la intención de cubrir la mayor superficie exterior posible, lo cual nos obliga a abandonar Bluetooth y decantarnos por 802.11b

3

DSSS – (Direct Sequence Spread Spectrum). A diferencia de la técnica de transmisión de Espectro Amplio (Spread Spectrum) FHSS, DSSS no precisa enviar la información a través de varias frecuencias sino mediante transmisores; cada transmisor agrega bits adicionales a los paquetes de información y únicamente el receptor que conoce el algoritmo de estos bits adicionales es capaz de descifrar los datos .Es precisamente el uso de estos bits adicionales lo que permite a DSSS transmitir información a 10Mbps y una distancia máxima entre transmisores de 150 metros.

-9-

Sistema de comunicaciones inalámbricas para robots -

2.1.3.

Puesto que trabajamos con robots móviles tenemos que observar las condiciones de trabajo de la tecnología. Una de las principales limitaciones de la robótica es el consumo, y por tanto quedará descartada la opción de 802.11a, entre otras cosas, por el consumo que supone.

Aspectos prácticos de una WLAN

Antes de comenzar con la implementación de la red inalámbrica hay que conocer y planear algunos aspectos de la red 802.11b. Para empezar, a modo de glosario, se muestran algunos términos relacionados con las tecnologías inalámbricas, que debemos conocer: -

-

-

Topologías de redes WLAN. Las topologías existentes son; o Ad-Hoc: Topología de red en la que los dispositivos inalámbricos se comunican directamente entre sí, eliminando la necesidad de un punto de acceso o una conexión a una red cableada (estación base). El modo Ad-Hoc también se denomina modo peer-to-peer o IBSS Independ Basic Service Set o Infraestructura: a diferencia de la topología anterior, en este caso, la red inalámbrica consta, como mínimo, de un punto de acceso conectado a la infraestructura de red cableada y un grupo de estaciones finales inalámbricas. Pueden ser infraestructuras BSS ó ESS. Elementos de una WLAN. o AP (Access Point): Dispositivo inalámbrico central de una WLAN que se encarga de recibir información de diferentes estaciones móviles ya sea para su centralización, o para su enrutamiento. o Tarjeta inalámbrica: Tarjeta típica de red (con conectividad para LAN) pero diseñada y optimizada para entornos inalámbricos. Dependiendo de la interfaz de conexión al equipo, existen diversas versiones: CompactFlash, PCI, PCMCIA, USB o Antena: Dispositivo capaz de radiar y recibir ondas de radio que adapta la entrada/salida del receptor/transmisor del medio. Dependiendo de hacia que punto emitan la señal podemos encontrarlas direccionales, omnidireccionales y sectoriales. o Conectores. Conjunto de cables y uniones que hacen posible la conexión entre antenas, puntos de acceso o tarjetas inalámbricas. o Software de instalación y configuración. Complemento para el hardware inalámbrico necesario para lograr comunicación. Otra terminología. o SSID (Service Set Identifier). Identificador de conjunto de servicio será el nombre de la red inalámbrica que puede ser diferente a la cableada, pretende proporcionar un primer nivel de seguridad o control de acceso aunque en realidad este identificador es muy fácil de obtener. o BSS (Basic Service Set). Cuando un punto de acceso está conectado a una red cableada y a un conjunto de dispositivos inalámbricos, se denomina conjunto de servicio básico. - 10 -

Sistema de comunicaciones inalámbricas para robots o ESS (Extended Service Set). Conjunto de dos o más BSS que forman una subred sencilla. o WEP Encryption. (Wired Equivalent Privacy Encription) es un protocolo de seguridad para redes de área local inalámbricas definido dentro de la norma 802.11b. Como su nombre indica, WEP fue diseñado para alcanzar el mismo nivel de seguridad de las redes cableadas. o Célula. Espacio físico en el que un número de dispositivos de redes inalámbricas pueden comunicarse. Una agrupación de células forma un cluster en el que cada célula utiliza un canal diferente al canal de la célula adyacente.(en 802.11b existen 3 canales diferentes). o Propagación multicamino (o multipath). La variación de la señal de radio cuando esta toma varios caminos desde el emisor al receptor. Es uno de los fenómenos más perjudiciales de los entornos inalámbricos. El funcionamiento y rendimiento de cualquier red inalámbrica viene condicionado por diversos factores: - Potencia de transmisión de las tarjetas - Calidad de los conectores - Ganancias y tipos de antenas - Distancia entre antenas - Zona de Fresnel4 - Condiciones del entorno Es posible calcular el nivel de recepción de señal en función de todos los factores condicionantes, la siguiente fórmula muestra esta relación: Nrs= Pt a -Pcoa-Pca a + Ga a –Pp + Ga b - Pca b - Pco b Dónde: Nrs = Nivel de recepción de señal Pt a = Potencia de transmisión a Pcoa = Pérdida de los conectores a Pca a = Pérdida de los cables a Ga a = Ganancia de la antena a Pp = Pérdida de propagación Ga b = Ganancia de la antena b Pca b = Pérdida de los cables b Pco b = Pérdida de los conectores b. Esta fórmula tiene sentido, cuando para un enlace óptimo, el Nrs es mayor que la sensibilidad más un margen de ruido que viene determinado por el entorno.

4

La llamada zona de Fresnel es una zona de despeje adicional que hay que tener en consideración además de haber una visibilidad directa entre las antenas. Este factor deriva de la teoría de ondas electromagnéticas respecto de la expansión de las mismas al viajar en el espacio libre. Esta expansión resulta en reflexiones y cambios de fase al pasar sobre un obstáculo. El resultado es un aumento o disminución del nivel de señal recibido.

- 11 -

Sistema de comunicaciones inalámbricas para robots

2.2. ANÁLISIS DE PROTOCOLOS DE TRANSPORTE EN REDES INALÁMBRICAS

Como veremos más adelante, uno de los aspectos más afectados por el hecho de trabajar en este entorno inalámbrico es el funcionamiento de la pila de protocolos sobre la que se trabaja puesto que esta, en sus principios, fue diseñada para trabajar en redes cableadas.

2.2.1.

Aspectos teóricos

En esta subsección del proyecto se recogen, de manera resumida, todos aquellos conceptos teóricos que, de alguna manera, afectan al desarrollo y, por tanto a la comprensión del presente trabajo de fin de carrera. Previamente a la descripción técnica de la pila de protocolos empleada en el transcurso de este proyecto, se da una introducción a la tecnología de las redes de área local. 2.2.1.1. Arquitectura de protocolos TCP/IP En términos muy generales, se puede decir que las comunicaciones involucran a tres agentes; aplicaciones, computadores y redes. Un ejemplo de aplicación podría ser la transferencia de ficheros. Los computadores se conectan a redes, y los datos que se intercambian se transfieren por la red de un computador a otro. Así, la transferencia de un fichero implica en primer lugar obtener el fichero y en segundo lugar hacerlo llegar a la aplicación del otro ordenador. Para afrontar esta transferencia es lógico dividir la tarea en tres capas independientes: capa de acceso a la red, capa de transporte y capa de aplicación. De esta manera, cada una de las capas realiza su trabajo de forma independiente a las otras capas. Se puede decir que cada una de las capas ofrece un servicio a la capa superior de forma que la capa que solicita un servicio a la capa inferior no tiene que preocuparse por la problemática de ese nivel. Siguiendo con el ejemplo del fichero y la arquitectura de tres capas, podríamos decir que la capa de acceso a la red trata el intercambio de datos entre el computador y la red a la que está conectado, esta capa no tiene conocimiento del tipo de datos con que está tratando y su única función es hacer llegar los datos que le proporciona la capa superior al destino que se le indica, de forma que la red pueda encaminar estos datos. Independientemente de la naturaleza de las aplicaciones que estén intercambiando datos, se desea que los datos se intercambien de una manera segura, es decir, que es deseable estar seguros de que todos los datos llegan a la aplicación destino y además llegan en el mismo orden en que fueron enviados. Como se verá, los mecanismos que proporcionan dicha seguridad son independientes de la naturaleza de las aplicaciones. La capa que concentra todos estos procedimientos es la capa de transporte, siendo compartida por todas las aplicaciones. Finalmente, la capa de aplicación contiene la lógica necesaria para admitir varias aplicaciones de usuario y para cada tipo distinto de aplicación, tal como la transferencia de un fichero, se necesita un módulo separado que será particular de cada una. Planteemos ahora una operación sencilla, supongamos que una aplicación en el computador A de la figura 2.1, desea transmitir un mensaje a otra aplicación del computador B. La aplicación en A pasará el mensaje a la capa de transporte con la instrucción de que lo envíe a la aplicación correspondiente de B. La capa de transporte pasará el mensaje a la capa de acceso a la red, la cual proporciona las instrucciones - 12 -

Sistema de comunicaciones inalámbricas para robots necesarias a la red para que envíe el mensaje a B. Para controlar esta operación, se debe transmitir información de control junto a los datos de usuario. Veamos que sucede con los datos desde que salen de la capa más alta del emisor hasta llegar a la capa del mismo nivel del receptor. En el momento que la aplicación emisora genera un bloque de datos y se lo pasa a la capa de transporte, esta puede romper el bloque en unidades más pequeñas para hacerlas más manejables. A cada una de estas pequeñas unidades la capa de transporte añadirá una cabecera, que contendrá información de control según el protocolo. La unión de los datos generados por la capa superior junto con la información de control de la capa actual se denomina unidad de datos del protocolo (PDU, “Protocol Data Unit”); en este caso se referirá como unidad de datos del protocolo de transporte. La cabecera en cada PDU de transporte contiene información de control que se usará por el mismo protocolo de transporte en el computador B. La información de estas cabeceras podría ser, por ejemplo: - SAP (Service Access Point) destino. La capa de transporte identificará el destino de los datos a partir de ese punto de acceso al servicio - Número de secuencia. Puesto que el protocolo de transporte envía secuencias de PDU’s, estas estarán numeradas. - Código de detección de error. La entidad de transporte emisora incluye un código calculado en función del contenido del resto de la PDU y este código sirve, en la parte receptora para asegurar la integridad de la PDU. El siguiente paso en la capa de transporte es pasar cada una de las PDU’s a la capa de red, con la instrucción de que sea transmitida al computador destino. Para completar este requerimiento, el protocolo de acceso a red debe pasar los datos a la red con una petición de transmisión. Como anteriormente, esta operación requiere el uso de información de control. En este caso, el protocolo de acceso a la red añade la cabecera de acceso a la red a los datos provenientes de la capa de transporte, creando así la PDU de acceso a la red. Dicha cabecera podría contener, por ejemplo: - La dirección del computador destino - Petición de facilidades. El protocolo de acceso a la red podría pedir a la red que realiza algunas funciones, como por ejemplo dar prioridad. En la figura 2.1 se muestra gráficamente todos estos elementos comentados, mostrando la interacción entre los módulos para transferir un bloque de datos. A B

Figura 2.1: Funcionamiento de una arquitectura de protocolos simplificada

- 13 -

Sistema de comunicaciones inalámbricas para robots Nótese que la cabecera de transporte no es “visible” al nivel de acceso a la red, en otras palabras, a dicho nivel no le concierne el contenido concreto de la PDU de transporte. Hay dos arquitecturas que han sido determinantes y básicas en el desarrollo de los estándares de comunicación: el conjunto de protocolos TCP/IP y el modelo de referencia OSI. TCP/IP es la arquitectura más adoptada y la única que se incluye en este resumen, posteriormente se desarrollará con más detalle dentro de la sección de análisis de protocolos de transporte en redes inalámbricas. TCP/IP, al contrario que OSI no tiene un modelo oficial de referencia, sin embargo, basándose en los protocolos estándar que se han desarrollado, todas las tareas involucradas en la comunicación se pueden organizar en cinco capas relativamente independientes, de esta forma, por similitud con el modelo simplificado de arquitectura de protocolos mostrado en la figura 2.1, podemos dar como válido el modelo TCP/IP de la figura 2.2.

Figura 2.2: Modelo de arquitectura de protocolos TCP/IP

A continuación pasaremos a resumir muy brevemente cada una de estas cinco capas; - La capa física contempla la interfaz física entre el dispositivo de transmisión de datos junto con el medio de transmisión o red. Esta capa está relacionada con la especificación de las características del medio de transmisión, la naturaleza de las señales, la velocidad de datos y cuestiones afines. - La capa de acceso a la red es responsable del intercambio de datos entre el sistema final y la red a la cual se está conectado. El software en particular que se use en esta capa dependerá del tipo de red que se disponga; se han desarrollado diversos estándares para conmutación de circuitos, conmutación de paquetes, redes de área local, entre otros. El software de comunicaciones situado por encima de la capa de acceso a la red no tendrá que preocuparse sobre las particularidades de la red por la que se va a transmitir. Este mismo software deberá funcionar apropiadamente con independencia de la red a la que el computador particular se conecte. - 14 -

Sistema de comunicaciones inalámbricas para robots -

-

-

En situaciones en las que los dos dispositivos que se desean comunicar estén conectados a través de redes diferentes, se necesitarán una serie de procedimientos para permitir que los datos atraviesen las diferentes redes interconectadas. Esta es la función de la capa internet. El protocolo Internet (IP “Internet Protocol”) se utiliza en esta capa para ofrecer el servicio de encaminamiento a través de varias redes. Independientemente de la naturaleza de las aplicaciones que están intercambiando datos, es usual requerir que los datos se intercambien de forma segura, se puede decir que, sería deseable asegurar que todos los datos llegan a la aplicación destino y en el mismo orden en el que fueron enviados. Como se verá más adelante, los mecanismos necesarios para ofrecer la seguridad requerida son esenciales, independientemente de la naturaleza de la aplicación. La capa encargada de esta labor es la capa de transporte, en TCP/IP existen dos protocolos comunes de la capa de transporte: el orientado a conexión TCP (“Transmission Control Protocol”) y el no orientado a conexión UDP (“User Datagram Protocol”) Finalmente la capa de aplicación contiene toda la lógica necesaria para llevar a cabo las aplicaciones de usuario. Para cada tipo específico de aplicación, como es por ejemplo la transferencia de un fichero, se necesitará un módulo particular dentro de esa capa.

2.2.1.2. Control de flujo El control de flujo es una técnica utilizada para asegurar que la entidad de transmisión no sobrecargue la entidad receptora con una excesiva cantidad de datos. Cuando en la entidad receptora se reciben datos, el receptor debe realizar algún tipo de procesamiento antes de pasar los datos al software de los niveles superiores. Si no hubiera procedimientos para el control de flujo, la memoria temporal del receptor podría llenarse y eventualmente desbordarse mientras se procesan los anteriores. El modelo de la figura 2.3 muestra un diagrama donde, en el eje vertical se representa el tiempo y cada fila representa una única trama. Los datos se envían usando una secuencia de tramas, dónde cada trama contiene un campo de datos más información de control. En este primer diagrama (2.3. a) supondremos que todas las tramas que se transmiten se reciben con éxito, ninguna se pierde, ni ninguna llega con errores, incluso supondremos que las tramas llegan en el mismo orden en que fueron transmitidas. Sin embargo, cada trama sufre un retardo arbitrario y variable antes de ser recibida. En la figura de la derecha (2.3.b) vemos el comportamiento en caso de error sin aplicar ningún control de flujo.

(b)

(a)

Figura 2.3: Modelo para la transmisión de tramas

- 15 -

Sistema de comunicaciones inalámbricas para robots 2.2.1.2.1. Control de flujo mediante parada y espera Este es el procedimiento más sencillo para controlar el flujo y actúa de la siguiente manera; una entidad transmite una trama. Tras la recepción, la entidad destino indica su deseo de aceptar otra trama enviando confirmación de la trama que acaba de recibir. La fuente, antes de enviar la siguiente trama debe esperar hasta que se reciba la confirmación. Este procedimiento funciona bien, y de hecho, es difícil mejorar su rendimiento cuando el mensaje se envía usando un reducido número de tramas de gran tamaño, aunque por otra parte, cuanto más larga sea la transmisión, más alta será la posibilidad de que haya errores. Si las tramas se rompen en bloques de datos más pequeños, estos errores se detectarán antes y menor será la cantidad de datos que se deba retransmitir. Así pues ya podemos concluir que un tamaño de trama adecuado determina las prestaciones de una técnica de control de flujo. En situaciones donde la longitud del enlace sea mayor que la longitud de la trama aparecen ineficiencias importantes. 2.2.1.2.2. Control de flujo de ventana deslizante El problema comentado anteriormente es debido a que sólo puede haber una trama en tránsito. Las situaciones en las que la longitud del enlace en bits (е) es mayor que la longitud de la trama (‫)ح‬, dan lugar a problemas de ineficiencia. Si se permitiesen transitar varias tramas al mismo tiempo en el enlace, la eficiencia se puede mejorar significativamente. Examinemos con más detenimiento como este procedimiento actuaría para dos estaciones A y B. La estación B reserva memoria temporal suficiente para almacenar n tramas. Por tanto B puede aceptar n tramas, y a A se le permite enviar n tramas sin tener que esperar ninguna confirmación. Para mantener conocimiento de qué tramas se han confirmado, cada una de ellas se etiqueta con un número de secuencia. B confirma una trama enviando una confirmación que incluye el número de secuencia de la siguiente trama que se espera recibir, esta confirmación, implícitamente también indica que B está preparado para recibir las n tramas siguientes, a partir de la especificada. Este esquema también se puede utilizar para confirmar varias tramas simultáneamente. Por ejemplo, B podría recibir las tramas 2, 3 y 4 pero retener la confirmación hasta que la trama 4 llegue. Al devolver la confirmación con número de secuencia 5, B confirmará las tramas 2, 3 y 4 simultáneamente, A mantiene una lista de los números de secuencia que está esperando recibir. Cada una de estas listas se puede considerar como una ventana de tramas. La figura 2.4 muestra el esquema de transmisión de tramas mediante ventana deslizante.

Figura 2.4: Modelo para la transmisión de tramas mediante ventana deslizante.

Es necesario hacer algunos comentarios adicionales. Debido a que la numeración de las tramas ocupa un campo de las mismas, evidentemente dicha numeración tendrá un tamaño limitado. Por ejemplo, si se considera un campo de 3 bits, los números de secuencia pueden variar entre 0 y 7. Por consiguiente las tramas se numeran módulo 8. En general, para un campo de números de secuencia de k bits, el - 16 -

Sistema de comunicaciones inalámbricas para robots rango de números de secuencia irá desde 0 hasta 2k-1, y las tramas se numerarán módulo 2k. En la figura 2.5 se muestra un ejemplo, en el que se supone un campo de 3 bits para los números de secuencia y un tamaño máximo para las ventanas igual a siete tramas. Inicialmente, A y B tienen sendas ventanas indicando que A puede transmitir siete tramas, comenzando con la trama 0 (F0). Tras transmitir tres tramas (F0,F1,F2)sin confirmación, A habrá cerrado su ventan hasta tener un tamaño de 4 tramas. B entonces transmite una trama Receptor Preparado RR3 (“Receive Ready”3), lo que significa: “He recibido todas las tramas hasta la trama número 2 y estoy listo para recibir trama 3; de hecho estoy listo para recibir siete tramas, empezando por la 3”.

Figura 2.5:Ejemplo de protocolo de ventana deslizante

De forma similar al mensaje RR, la mayoría de los protocolos permiten que cada estación pueda cortar totalmente la transmisión de tramas desde el otro extremo enviando un mensaje Receptor No Preparado (“Receive Not Ready”) con el que confirman las tramas anteriores pero prohíbe la transmisión de tramas adicionales. Mientras que el control de flujo es un mecanismo relativamente sencillo en la capa de enlace, en la capa de transporte es bastante complejo por dos razones principales: - El control de flujo en la capa de transporte supone la interacción de usuarios de servicio de transporte, entidades de transporte y servicios de red - El retardo de transmisión entre entidades de transporte es generalmente grande comparado con el tiempo de transmisión real y lo que es peor, variable. Con un servicio de red segura, la técnica de ventana deslizante funcionará realmente bien puesto que si nos basamos en este supuesto, podemos afirmar que la entidad de transporte emisora puede suponer que los segmentos han llegado y que la falta de confirmaciones es debido a una táctica de control de flujo. Esta táctica no funcionará bien en una red no segura, ya que la entidad de transporte emisora no sabría si la falta de confirmaciones es debida al control de flujo o a la pérdida de un segmento. En capítulos posteriores se discutirá el comportamiento de este tipo de técnicas en redes inalámbricas. - 17 -

Sistema de comunicaciones inalámbricas para robots 2.2.1.3. Control de errores El control de errores hace referencia a los mecanismos necesarios para la detección y la corrección de errores que aparecen en la transmisión de tramas. Al igual que el caso anterior, partimos de la idea que los datos llegan en el mismo orden en el que fueron enviados, y cada trama sufre un retardo variable antes de recibirse. Se contempla sin embargo dos tipos de errores: - Tramas perdidas: Por ejemplo, una ráfaga de ruido puede dañar una trama de forma que el receptor no se de cuenta que se ha recibido tal trama. - Tramas dañadas: Esta misma ráfaga de ruido podría afectar a una trama de forma que no dañe por completo todo su contenido, dañando únicamente algunos bits. Las técnicas más utilizadas para el control de errores se basan en alguna de las siguientes aproximaciones: - Detección de errores. Esta sencilla técnica, que consiste básicamente en añadir redundancia a los datos para detectar posibles errores sufridos en parte o la totalidad de la trama, se comentará con mayor detalle dentro del apartado de software de comunicaciones. - Confirmaciones positivas: el destino devuelve una confirmación positiva por cada trama recibida con éxito y libre de errores. - Retransmisión después de la expiración de un intervalo de tiempo: la fuente retransmite las tramas que no se han confirmado después de un período determinado. - Confirmación negativa y retransmisión: el destino devuelve una confirmación negativa al detectar errores en las tramas recibidas. La fuente retransmitirá de nuevo esas tramas. Todos estos mecanismos se denominan genéricamente solicitud de repetición automática ARQ (“automatic repeat request”); el objetivo de ARQ es convertir un enlace de datos no fiable en seguro. Hay tres variantes del ARQ que se han normalizado: ARQ con parada y espera, ARQ con adelante atrás N y ARQ con rechazo selectivo. Todos estos procedimientos se basan en la técnica de control de flujo presentada en la subsección 2.2.1.2. Puesto que no es objetivo de este proyecto la descripción completa del funcionamiento de todos estos procedimientos, aunque si son necesarias unas nociones básicas, se presentan a continuación tres puntos que describen superficialmente cada uno de estos tres procedimientos. 2.2.1.3.1. ARQ con parada y espera Basada en la técnica para el control de flujo con parada y espera mencionada en la subsubsección 2.2.1.2.1. y el esquema de la figura 2.6, la estación origen transmite una única trama y entonces, debe esperar la recepción de una confirmación (ACK). No se podrá enviar ninguna otra trama hasta que la respuesta de la estación destino vuelva al emisor. Pueden ocurrir dos tipos de error; el primero consistirá en que la trama llegue al destino dañada y el segundo consistirá en que la confirmación se deteriore de camino al emisor de la trama. Si observamos la figura 2.6 veremos como el “ARQ stop and wait” soluciona cada uno de estos problemas.

- 18 -

Sistema de comunicaciones inalámbricas para robots

Figura 2.6: ARQ con parada y espera (“Stop & Wait”)

La ventaja principal de ARQ Stop & Wait es su sencillez y como inconveniente tenemos la ineficiencia en situaciones en las que el enlace es mayor que el tamaño de la trama. 2.2.1.3.2. ARQ con adelante atrás N Es la técnica de control de errores más frecuente. Está basada en el procedimiento de control de flujo mediante ventanas deslizantes. Una estación puede enviar una serie de tramas numeradas secuencialmente módulo algún valor predeterminado. El número de tramas pendientes de confirmar se determina mediante el tamaño de la ventana. Mientras no aparezcan errores el destino confirmará (RR “Receive Ready”) si existen errores, enviará una confirmación negativa (REJ “Reject”) para esa trama. La estación destino descartará esa trama y todas las que se reciban en el futuro hasta que la trama errónea se reciba correctamente. Esta es la característica propia de esta técnica, el hecho de que cuando la estación fuente reciba un REJ, deberá retransmitir la trama errónea más las “N” tramas posteriores que hayan sido retransmitidas mientras tanto.

- 19 -

Sistema de comunicaciones inalámbricas para robots

Figura 2.7: ARQ adelante atrás N (“Go Back N”)

Como vemos, el protocolo es bastante más complejo, por ejemplo, el caso en que se pierde o deteriora un mensaje RR (RR (x+0) en la figura), en este caso, el emisor reacciona enviando una petición de confirmación RR (orden RR (P bit)) que espera como respuesta el RR con el último número de secuencia del mensaje que espera recibir el receptor (RR(x+2) en la figura). Como esta situación, nos podemos imaginar otras posibilidades como por ejemplo que sucedería si se perdiese esta orden RR(P bit) o la respuesta a esta. Hay que destacar, de entre otros posibles errores en la transmisión lo siguiente; supóngase que una estación envía la trama 0 y recibe de vuelta una RR1, posteriormente envía las tramas 1,2,3,4,5,6,7,0 y recibe otra RR1. Esto podría significar que todas las 8 tramas se recibieron correctamente y que la RR1 es una confirmación acumulativa. También se puede interpretar como que las 8 tramas se han deteriorado o incluso perdido por el camino. Esta posible ambigüedad se evita si el tamaño máximo de la ventana se fija a 7 (es decir, de forma general 2k-1). 2.2.1.3.3. ARQ con rechazo selectivo En ARQ con rechazo selectivo, las únicas tramas que se transmiten son aquellas para las que se recibe una confirmación negativa, denominada SREJ (“Selective Reject”), o aquellas para las que el temporizador correspondiente expira. Esto parece más efectivo que el “Go Back N”, debido a que se reduce el número de - 20 -

Sistema de comunicaciones inalámbricas para robots retransmisiones. Por otra parte, el receptor deberá reservar zona de memoria lo suficientemente grande para almacenar las tramas tras una SREJ, hasta que la trama se transmita, y además debe tener lógica adicional para reinsertar la trama reenviada en la posición correspondiente. Vemos como soluciona ARQ con rechazo selectivo (“Selective Reject”) la misma situación que la planteada con Stop & Wait.

Figura 2.8: ARQ con rechazo selectivo (“Selective Reject”)

Por lógica, es fácil comprobar que la casuística de esta técnica aumenta en complejidad y no es difícil imaginar problemas que los protocolos que implementen este control de errores deberán solucionar. Entre ellos podemos destacar las restricciones en cuanto al número de secuencia y de ventana que supone este proceso. Consideremos el caso en que A envía las 2k -1 tramas numeradas y la estación las recibe y envía un RR 7, debido a una ráfaga de ruido RR 7 se pierde y A retransmite la trama 0 debido a la expiración del temporizador, B ha desplazado su ventana de recepción indicando que acepta las tramas 7,0,1,2,3,4, y 5. Al recibir la trama 0 anterior supone que la trama 7 se ha perdido y que se trata de una trama 0 diferente y por tanto la acepta. Este es un problema que se soluciona haciendo que la ventana no sea nunca mayor a la mitad del rango de los números de secuencia. En general , para un campo de números de secuencia de k bits, es decir, para un rango de 2k, el tamaño máximo de la ventana se fija en 2(k-1). 2.2.1.4. El nivel de transporte La misión de los protocolos definidos en el nivel de transporte es ofrecer a sus usuarios un sistema transparente de transferencia de mensajes, y por tanto independiente de la tecnología de red utilizada en niveles inferiores. 2.2.1.4.1. El nivel TCP (Transmisión Control Protocol) Este nivel ofrece un flujo de octetos orientado a la conexión. TCP pretende ofrecer un servicio de transporte fiable (sin errores, pérdidas, duplicidades, desorden de tramas, etc.) y extremo a extremo, sobre las redes de conmutación de paquetes. Por esto TCP se usa en aplicaciones de red que necesitan liberación garantizada y que no desean - 21 -

Sistema de comunicaciones inalámbricas para robots o pueden incorporar mecanismos propios de fiabilidad en estas aplicaciones. Los beneficios del uso de TCP tienen un coste, respecto a otros protocolos de transporte más simples: requieren más CPU y ancho de banda de red. El formato de un segmento TCP es el siguiente:

Figura 2.9: Formato de cabecera TCP

El objetivo de TCP es ofrecer conexiones fiables, para lograr esto sobre un sistema de comunicaciones no fiable como IP, se tienen que añadir diversas funcionalidades: a) Transferencia básica de datos: Una conexión TCP es un canal bidireccional que permite flujo continuo de octetos (no mensajes). b) Fiabilidad: Recuperar datos dañados, duplicados, perdidos y desordenados. c) Control de flujo: Se realiza un control de flujo mediante ventana deslizante. El tamaño de la ventana se puede renegociar cada vez que se envía un segmento de confirmación. d) Multiplexación: TCP puede dar servicio a varios usuarios al mismo tiempo, para gestionar esto, una conexión TCP queda identificada con una pareja de 4 números (2 direcciones IP y 2 números de puerto). e) Conexiones: TCP ofrece un servicio orientado a conexión lo cual significa que deberá inicializar y mantener información de estado (sockets, números de secuencia, créditos en las dos direcciones, etc.). f) Prioridad y seguridad: Existen diferentes tipos de servicio en este sentido, que ofrece TCP y que son seleccionables por el usuario. 2.2.1.4.2. UDP (User Datagram Protocol) Este es el otro protocolo principal que trabaja sobre IP, es la alternativa a TCP. El servicio que ofrece a las aplicaciones de red no es más que una interfaz IP, por esto el núcleo de UDP es mucho más sencillo que el módulo TCP. UDP es un servicio de datagramas no orientado a conexión que no garantiza liberación. UDP no mantiene una conexión extremo a extremo con el módulo UDP - 22 -

Sistema de comunicaciones inalámbricas para robots remoto. Únicamente coloca el datagrama sobre la red. No realiza fragmentación ni seguimiento de los datagramas enviados El formato de la cabecera UDP es el siguiente:

Figura 2.10: Formato de cabecera UDP

El objetivo de UDP es simplemente permitir el intercambio de datos entre aplicaciones de red sin la sobrecarga de TCP. 2.2.1.4.3. Aplicaciones ¿Por qué razón existen dos protocolos de transporte (TCP y UDP)?. La respuesta es porque proporcionan dos servicios diferentes. Las aplicaciones sobre TCP se ajustan mejor cuando se necesita a) Un servicio de liberación de flujo de datos fiable y/o b) Eficiencia sobre circuitos de largo recorrido. UDP, por su parte será mejor cuando se requiera: a) Un servicio de datagramas y/o a) Eficiencia sobre redes rápidas con latencias pequeñas. Pronto veremos que en lo que a este proyecto concreto se refiere, tomar una decisión sobre cual de estos dos protocolos utilizar supone un reto puesto que nuestro entorno de trabajo requiere unas necesidades intermedias entre las ofrecidas por TCP y por UDP.

2.2.2. Caracterización de los protocolos TCP y UDP sobre plataformas inalámbricas TCP está diseñado para proporcionar una comunicación segura entre procesos (usuarios TCP ) paritarios a través de una gran variedad de redes seguras e inseguras así como un conjunto de redes interconectadas. Sin embargo, este diseño tan general tiene sus dificultades cuando se enfrenta a entornos tan concretos como son las redes inalámbricas. A modo de introducción, mostramos la tabla de la figura 2.1, que representa las tasas de error por bit (BER “Bit Error Rate”) en redes cableadas de diferentes medios físicos comparadas con la tasa en redes inalámbricas. Aunque TCP es capaz de funcionar en diferentes medios, en principio no fue diseñado para soportar específicamente una tasa de error por bit como la que presentan los medios inalámbricos, muestra de esto es la utilización, en capa de enlace, de técnicas de detección de error en vez de técnicas de detección y corrección, que no sólo detectan sino que corrigen estos errores. Esta técnica, conocida como Corrección - 23 -

Sistema de comunicaciones inalámbricas para robots de Error de Encaminamiento (FER, ”Fordward Error Correction”), muestra un comportamiento, en entornos inalámbricos, que mejora esta tasa de error de bit llegando a tasas comparables con los medios cableados. Medio de transmisión Medios cableados Cable de cobre Fibra óptica Medios inalámbricos Aire sin FEC

BER 10-6 a 10 -7 10-12 a 10 -14 Mayor a 10-1

Tabla 2.1.: Comparación tasa de error por bit.

No es raro encontrar situaciones en las que TCP se ve obligado a trabajar recorriendo diferentes tipos de redes, entre las que puede haber redes con latencia alta y ancho de banda baja y en redes de latencia baja y ancho de banda alto. Esto complica las cosas, puesto que el comportamiento de TCP deja de depender de la tasa de transferencia de por sí y pasa a depender del producto tasa de transmisión y demora de ida y vuelta. Sin embargo, como se ha mencionado, TCP funciona correctamente en multitud de medios, entre los cuales se encuentran medios con BER similares a los de las redes inalámbricas, entonces ¿Cuál es el problema?. Las versiones de TCP corrientes interpretan un segmento ausente como congestión en la red, lo que significa que el remitente debe reducir la velocidad de transmisión. Esta interpretación es a menudo correcta para las redes cableadas. Desafortunadamente, si también encontramos vínculos inalámbricos en la ruta de comunicación, esta suposición podría ser errónea. En estos casos, la interpretación del TCP es incorrecta y lleva a un mal comportamiento del nivel de transporte, perjudicando seriamente la comunicación. Otra característica propia de TCP, y muy relevante en nuestro caso particular, es el uso ineficiente de energía. Las implementaciones corrientes de TCP no se preocupan de si el protocolo hace un uso eficiente de energía; todos los anfitriones tienen acceso ilimitado a energía. Como ejemplo, algunos protocolos de la capa de enlace de datos implementan un esquema ARQ y al mismo tiempo TCP también provee una transmisión fiable extremo a extremo, se ha demostrado que esta redundancia lleva a un peor comportamiento del enlace. Una de las propuestas de mejora analizadas consiste en utilizar el modelo indirecto de conexión, esto es, partir la conexión TCP en dos partes, de manera que cada una sea gestionada independientemente y que un elemento situado entre ambas partes las coordine. Cada una de estas partes representará a cada uno de los mundos que forman el tipo de situaciones que se desean estudiar; el mundo inalámbrico y el cableado. La siguiente tabla (Tabla 2.2) nos presenta los diferentes enfoques que los investigadores han perseguido para poder resolver los posibles problemas mencionados anteriormente. Algunos de estos estudios se centran en la capa de datos, sugiriendo que esta sea la encargada de este control de errores. Otros favorecen una solución a nivel de la capa de transporte.

- 24 -

Sistema de comunicaciones inalámbricas para robots Aplicación Transporte Red Enlace de red Física

Anfitriones desean acceso a servicios como WWW, e-mail, FTP, mensajes,etc. TCP, variantes, UDP, protocolos experimentales Todos los anfitriones deben soportar IP (IPv6 e IP movile) TCP- no alerta, TCP alerta (Snoop)5 FEC

Tabla 2.2.: Diferentes propuestas para la arquitectura de red cableada-inalámbrica.

Existen numerosos estudios que analizan este aspecto de la tecnología TCP/IP, aunque la mayoría exponen resultados basados en complejos cálculos analíticos y simulaciones, las cuales básicamente se centran en la influencia del número de terminales que acceden al medio y en como afecta su presencia al rendimiento del sistema. Otros, sin embargo estudian los niveles propios de la arquitectura TCP/IP independientemente de los niveles de aplicación. La presente sección se basa en los informes correspondientes a algunos de estos estudios. El artículo “Análisis de protocolos de transporte en redes hibridas”6, estudia el comportamiento de estos protocolos para el acceso a Internet a través de los sistemas de telefonía celular GSM. Estos sistemas inalámbricos tienen, lógicamente, multitud de puntos en común con la tecnología 802.11b con la que se trabaja en este proyecto. Según este análisis, para asegurar la entrega de segmentos, TCP hace uso de ACK’ s y retransmisiones. Las causas por las que no se recibe ACK de un segmento pueden ser varias. Una de ellas es la congestión de la red, que puede haber causado el descarte del paquete enviado o del mismo ACK. Los mecanismos de control de congestión hacen uso de los temporizadores para reaccionar ante este problema. Cuando el temporizador expira, se considera el paquete perdido, achacándolo a la congestión de la red, como ya se ha mencionado, esta estimación suele ser correcta en redes cableadas, pero no así en inalámbricas. Como acción correctiva, se activan ciertos mecanismos como “show-start” y el algoritmo de Karn7 que tienen como respectivas consecuencias la reducción de la ventana de emisión y el aumento del valor de los temporizadores de retransmisión (hasta el doble del actual), en espera de aliviar así la congestión de la red. Este mecanismo de congestión es adaptativo, sus parámetros se van ajustando a la situación de la conexión. Diseñado en principio con acierto, pues la principal causa de tardanza de los ACK’ s en redes tradicionales (cableadas) es la pérdida por congestión, su uso en entornos inalámbricos supone un problema de ineficiencia. En estos entornos, los retardos de los enlaces son de una magnitud considerable y sufren grandes variaciones, debida a los mecanismos de control de errores. Todo esto hace que el mecanismo de control de la congestión se comporte de manera inadecuada. Resumiendo, el mecanismo de control de la congestión de TCP reduce significativamente su eficiencia en entornos inalámbricos. Además otras características de TCP, como la redundancia en las cabeceras de los paquetes, contribuyen al uso ineficiente del ancho de banda de los enlaces inalámbricos.

5

SNOOP. Modulo que, colocado lo más próximo al receptor gestiona las retransmisiones en entornos de alto BER incrementando el rendimiento de TCP 6 Referencia bibliográfica en: Referencias bibliográficas/ Enlaces de Internet consultados / Nº1. 7 Este algoritmo, es un ejemplo de los algoritmos adaptativos existentes para la gestión temporizadores.

- 25 -

Sistema de comunicaciones inalámbricas para robots Como propuestas de mejora, este estudio presenta varias soluciones como la compresión o reducción de las cabeceras TCP/IP o la omisión del control de congestión y de errores. Entre las propuestas finalmente se implementa un nuevo protocolo que sustituye al TCP únicamente en la parte inalámbrica utilizando el modelo indirecto ya comentado en este capítulo. Otro artículo en el que nos hemos basado es “Optimizing Internet flows over IEEE 802.11b wireless local area networks: A performance-enhancing Proxy based on fordward error correction”8, éste profundiza en el análisis de los protocolos existentes TCP y UDP introduciendo un Proxy (PEP “Performance Enhancement Proxy”), centrándose en el módulo FEC del Proxy. Nuestro punto de vista no se centra, como en este artículo en el nivel de enlace de red, más concretamente en el FEC, pero si podemos obtener valiosos datos del comportamiento de TCP y UDP sobre 802.11b y la forma en que estos pueden mejorar. Pasaremos a citar los aspectos más interesantes que hemos extraído de este artículo para cada uno de los dos protocolos. - Caracterización de UDP En primer lugar, en el artículo, se estudió el comportamiento del protocolo de transporte UDP sobre la WLAN, tanto sobre un canal ideal (con presencia de errores nula), como con una situación en la que la presencia de errores en el canal radio estuviera asegurada, con el fin de comprobar su influencia. Cabe decir que las aplicaciones que, en mayor medida harán uso del protocolo de transporte UDP son, como en nuestro caso, las que tienen requerimientos de tiempo real, por lo que, además de tomar medidas del throughput, el artículo caracteriza el comportamiento temporal de los datagramas UDP, con medidas de retardo medio entre datagramas consecutivos y de la varianza de dicho retardo. En el canal ideal se evaluó la contribución en bytes (overhead) de cada uno de los niveles del protocolo que conforman el método de acceso estándar IEEE 802.11 en el rendimiento global, validando las medidas con un análisis matemático. En la figura 2.11 se puede observar la contribución individual de todos los niveles. Se puede observar que la mayor parte de la tasa binaria bruta se emplea en la transmisión de la sobrecarga a nivel físico, en segundo lugar, las cabeceras IFS (InterFrame Space) y MAC añaden carga a los datos. Al caracterizar el comportamiento temporal de los datagramas sobre el canal libre de errores se obtuvo un resultado que cabía esperar, si se tiene en cuenta las características del método de acceso estudiado. En el mismo, la única contribución aleatoria es la del procedimiento de backoff que emplea el estándar, y que consiste en lo siguiente; entre la transmisión de dos tramas consecutivas se deja un período de tiempo que viene dado por un número determinado de ranuras temporales, siguiendo una distribución aleatoria entre 0 y 31, y con una longitud de 20 microsegundos cada una de ellas (es este procedimiento el que genera las cabeceras IFS). Pues bien, el valor medio y la varianza del tiempo entre datagramas se corresponden, con un elevado grado de exactitud, con el de la variable aleatoria descrita anteriormente.

8

Referencia bibliográfica en: Referencias bibliográficas/ Libros y revistas técnicas consultados/ Nº3

- 26 -

Sistema de comunicaciones inalámbricas para robots

Figura 2.11: Throughput9 ideal UDP

Una vez estudiado el comportamiento del protocolo UDP sobre la plataforma ideal, el artículo nos muestra los resultados obtenidos al evaluar la influencia que los errores que aparecen en el entorno radio tienen sobre dicho comportamiento. Para ello se situó el terminal móvil en un lugar en el que la relación señal ruido (SNR) fuera lo suficientemente pequeña para asegurar la presencia de errores. En esta situación se midió el tiempo entre datagramas consecutivos, el retardo medio y la varianza de dicho retardo. Los valores obtenidos, cuando la relación señal ruido se situaba por debajo de 10 dB desaconsejan el uso de este tipo de infraestructuras para servicios de tiempo real. - Caracterización de TCP Una vez finalizada la caracterización del protocolo 802.11b, empleando el tráfico UDP, se da paso al estudio del comportamiento de aplicaciones basadas en TCP sobre la misma plataforma. El protocolo de transporte TCP implementa mecanismos de control de flujo y errores, citando al contenido del artículo, se documenta de qué forma afecta esto en el overhead de las tramas y el retardo. Se utilizó para este análisis, el mismo proceso que en el caso UDP, es decir, primero se analizará el caso en el que el canal puede considerarse como ideal (sin

9

Throughput La cantidad de datos transmitidos entre dos puntos en una determinada cantidad de tiempo. Se entiende como el rendimiento total relacionando cantidad de información y tiempo.

- 27 -

Sistema de comunicaciones inalámbricas para robots presencia de errores), para más adelante estudiar la influencia que los errores tienen sobre el comportamiento de TCP. Sin embargo hay un aspecto que se modifica respecto al análisis realizado previamente. En esta ocasión, más que analizar los diferentes procedimientos que implementa el protocolo de acceso IEEE 802.11b, el artículo, hace especial hincapié en el efecto de los errores en los mecanismos implementados por TCP. Se tratará, pues, de un análisis más a nivel de capa de transporte que de enlace, a diferencia del estudio basado en UDP. En la figura 2.12 se muestra la contribución individual de todos los niveles que intervienen en la comunicación en el rendimiento global para las cuatro velocidades de trabajo. Vuelve a destacar la sobrecarga física en la que se derrocha la mayor parte de eficiencia, sobre todo cuando se trabaja a regimenes elevados. En el caso de aplicaciones basadas en TCP, la influencia de los errores del canal inalámbrico degradará su comportamiento de una manera radicalmente diferente al caso UDP. En primer lugar, dado que este protocolo de transporte implementa un mecanismo de control de errores, la pérdida IP es cero en todos los casos, ya que aunque falle la transmisión de un segmento, éste se retransmitirá posteriormente.

Figura 2.12: Throughput ideal TCP

En el caso de aplicaciones cuyo funcionamiento se base en TCP, el factor que más se penaliza debido a la mala condición del canal inalámbrico es el throughput, debido precisamente a los mecanismos de transmisión que TCP utiliza. Principalmente, se pueden citar tres aspectos puntuales que degradan el rendimiento de TCP cuando hay errores en el canal. - Las retransmisiones que se generan para recuperar segmentos perdidos. - Al producirse errores, el número de tramas MAC transmitidas será mayor que el número de segmentos. - El tiempo de inactividad global de la entidad TCP transmisora es mucho mayor que en el caso del canal ideal, por lo que su influencia en la pérdida de rendimiento será predominante; en algunos casos, la eficiencia desechada por la presencia de inactividades alcanza unas proporciones exageradas (entorno al 90% de la tasa global). Como el tercero de los aspectos mencionados era, con mucho, el más relevante, el artículo se detiene a analizarlo con detenimiento. Para ello se eligieron situaciones en las que fuera destacable, como la que aparece en la figura 2.13 y, a partir - 28 -

Sistema de comunicaciones inalámbricas para robots de las capturas que se disponían, se elaboraron unos programas para emular el comportamiento de una implementación de TCP en un núcleo Linux, comprobando, que todas las situaciones que se detectaron se correspondían con la implementación que se estaba usando de TCP.

Figura 2.13: Comportamiento TCP con bajo SNR en WLAN

Finalmente, la siguiente tabla (tabla 2.3) contiene dos tablas. En la primera de ellas (2.3 a) se muestra el throughput en un canal sin errores y en un canal ruidoso, analizando cada caso para diferentes tamaños de datagrama UDP (payload). En la segunda (2.3 b) se muestra el resultado de realizar 5 pruebas en un canal ruidoso utilizando TCP. Rb (Mbps)

11

Payload (bytes)

1500 1024 768 512 256

Canal sin errores Throughput (Mbps) 6,071 5,001 4,206 3,172 1,763

Canal con errores Throughput (Mbps) 1,259 1,2 1,293 1,548 0,999

(a)-Throughputs obtenidos para diferentes tamaños de datagrama y condiciones de canal utilizando UDP.

Rb (Mbps)

11

Test 1 2 3 4 5

Throughput (Mbps) 2,906 0,707 4,488 0,501 4,586

(b)-Throughput obtenido en cinco pruebas sobre un canal ruidoso utilizando TCP

Tabla 2.3: Resultados tests throughput en canal con y sin errores

De estas tablas podemos decir que el comportamiento de TCP en situaciones adversas con baja relación señal ruido es impredecible. Esta característica sumada a otras tantas comentadas durante esta sección hacen de TCP un protocolo no deseado para redes que requieren tiempo real ya que es más conveniente obtener un retardo constante y conocido que tiempos de respuesta desconocidos y variables.

- 29 -

Sistema de comunicaciones inalámbricas para robots

2.2.3.

Conclusiones del análisis de protocolos

La dificultad de extraer conclusiones de todos estos estudios, teniendo en cuenta los numerosos aspectos que se han resumido en él es claramente elevada. Sin embargo, quedan claros varios conceptos que nos llevarán a tomar varias decisiones en cuanto al software de comunicaciones, estos conceptos son: a) El uso de TCP para aplicaciones que trabajen sobre redes inalámbricas es inadecuado puesto que: o El control de congestión implementado por TCP reduce la eficacia del enlace o El uso ineficiente de la energía que realiza este protocolo. o El overhead introducido por las cabeceras TCP supone un mal uso del ancho de banda, que aunque no es excesivamente crítico para algunas aplicaciones, este ancho de banda es ya de por si considerablemente menor que en redes cableadas. o Las retransmisiones se hacen excesivas en caso de ruido en el enlace. o El tiempo de inactividad TCP en la entidad transmisora es elevado en caso de ruido. o Comportamiento temporal impredecible y variable debido al diseño del protocolo. b) El uso de UDP es adecuado para aplicaciones que requieren tiempo real siempre que la relación señal ruido sea menor que 10 dB. c) El control de congestión que implementa TCP, que ya de por sí supone un problema en redes inalámbricas, supone una sobrecarga innecesaria en nuestro caso. Esto es así puesto que nuestra red inalámbrica no es una red de tránsito.

- 30 -

Sistema de comunicaciones inalámbricas para robots

3. SISTEMA PROTOTIPO El siguiente capítulo está dedicado a mostrar el entorno concreto en el que se desarrolla nuestro proyecto. Para ello vamos a definir un marco de trabajo y dentro de este marco que nos ocupa, estudiaremos la gestión de este tipo de entornos así como las herramientas y características propias de los elementos seleccionados para alcanzar el objetivo final del proyecto.

3.1. DEFINICIÓN DEL MARCO DE TRABAJO Siguiendo la idea inicial de proporcionar comunicaciones inalámbricas a la flota terrestre de robots y teniendo presente el tipo de datos ya mencionado que se desea enviar, vamos a profundizar más concretamente en el entorno concreto que afecta a este proyecto para tener así una imagen global del caso que nos ocupa. El laboratorio en el que principalmente se desarrollan las actividades de robótica (figura 3.1 b), está localizado en el primer piso del edificio Anselm Turmeda dentro de la Universitat de les Illes Balears, frente al edificio se encuentran las carreteras que lo rodean y una parcela sin construir (figura 3.1 a), que forman la zona principal a cubrir, podemos decir, por tanto que diferenciaríamos entre una zona interior, la del propio laboratorio y una zona exterior, las carreteras y la parcela. En un primer momento la intención es tener totalmente cubierta la zona del laboratorio y cubrir el máximo posible en exteriores dónde se desarrollará la actividad de la flota. Hablamos, por tanto, de una primera zona a cubrir dispuesta dentro de un edificio (indoor), de una superficie aproximada de 67m2 y que por tanto tiene como principales obstáculos para ofrecer cobertura; los muebles, radiaciones electromagnéticas de los aparatos, paredes, materiales metálicos, etc. Por otra parte tenemos la zona exterior de aproximadamente 2800m2 en la que las principales características a tener en cuenta serán los edificios colindantes, las condiciones meteorológicas, otras infraestructuras inalámbricas, radiaciones electromagnéticas y los diferentes materiales que nos podemos encontrar.

(a) Zona exterior

(a) Zona interior Figura 3.1: Zonas a cubrir

Partiendo de la red estructurada existente en el laboratorio, se deberá crear una nueva infraestructura que nos permita nuestro objetivo. En las siguientes secciones se documenta con detalle la selección y configuración del nuevo material necesario.

- 31 -

Sistema de comunicaciones inalámbricas para robots

3.2. HARDWARE Dentro de esta sección se pretende mostrar cuales son las características del hardware que interviene en el proyecto, tanto el hardware disponible como el nuevo. Como se ha mostrado en el esquema del proyecto (figura 1.2), el hardware con el que nos encontramos se puede clasificar en dos categorías: - Hardware e infraestructura de la/las estación/estaciones base. - Hardware e infraestructura de la/las estación/estaciones móviles. La selección del nuevo hardware se determinará, en primer lugar, por el entorno concreto del proyecto que nos ocupa y en segundo lugar por el hardware de la estación móvil puesto que es éste hardware el que tiene más restricciones.

3.2.1.

Hardware e infraestructura disponible.

Como ya se ha comentado, la base de nuestro proyecto es el CABRIT, y este robot está construido con hardware un tanto particular que nos compromete a seleccionar el nuevo hardware teniendo en cuenta sus prestaciones y características. Los elementos hardware que constituyen el robot son de dos tipos: dispositivos de control y dispositivos finales. La selección de hardware para nuestro proyecto se centra únicamente en los dispositivos de control, ya que los dispositivos finales, actuadores o sensores, son totalmente independientes al nivel de comunicación sobre el que nosotros trabajamos. Los dispositivos de control son los encargados de ejecutar los procesos de control del sistema robótico en el que se montan. Estos procesos pueden ser de muy diversa naturaleza en función del tipo de robot en cuestión. En la estación móvil de nuestro proyecto se utilizan dos dispositivos de control: Una placa PC104+ y un microcontrolador 8051. De estos dos dispositivos, el que finalmente nos proporcionará comunicación con las otras estaciones será la PC104+ así que nos centraremos en sus características. 3.2.1.1. Placa PC104+ Este es el dispositivo más importante del robot ya que, por capacidad de proceso, se puede considerar como el dispositivo de control principal de dicho robot.

Figura 3.2: Placa PC104+ (JUMPtec MOPSlcd6)

La PC104+ es una placa madre de PC. El fabricante del modelo empleado es JUMPtec y su nombre comercial es MOPSlcd6 (figura 3.2). Esta placa posee algunas - 32 -

Sistema de comunicaciones inalámbricas para robots características específicas que la hacen muy adecuada en sistemas emportados y concretamente en robots. Algunas de estas características son: - Tamaño muy reducido. Dimensiones: 96 x 90 mm(3,8 x 3,6”). - Microprocesador INTEL Pentium a 166MHz o 266MHz - Hasta 64Mbytes de memoria SDRAM. - Consumo muy bajo. - Posibilidad de incrementar el número de puertos entrada/salida mediante placas de expansión específicas que siguen el estándar PC104+. - Posible instalación de sistemas operativos de tiempo real (como es el caso de QNX). - Posible instalación de memorias de almacenamiento masivo tipo disco chip, con interfaz EIDE. - Prestaciones varias: Controlador de teclado, reloj de tiempo real, controlador gráfico SVGA con interfaz LCD, bus PCI, dos puertos serie, un puerto paralelo, controlador para disquetera, controlador de disco duro EIDE, controlador para red Ethernet y puerto USB. En el laboratorio donde se desarrolla el proyecto, se dispone de dos placas PC104+, las dos versiones existentes; 166MHz y 266MHz. Las dos placas disponibles son operativas puesto que se les han instalado los dispositivos externos necesarios como memoria RAM, disco duro, lector de CD-ROM y conectores externos para teclado, usb, controlador SVGA, puertos serie y paralelo. La placa con microprocesador de 266MHz está instalada sobre el CABRIT junto con el microcontrolador y otros dispositivos finales. Mientras que la PC104+ de 166MHz está montada sobre una caja convencional de PC que previamente fue despojada de toda su anterior electrónica a excepción de la fuente de alimentación. Durante la realización del proyecto se trabajó mayormente sobre el equipo de desarrollo montado en el PC (figura 3.3) puesto que el CABRIT seguía en fase de desarrollo.

Figura 3.3: Equipo de desarrollo.

3.2.1.2. Hardware de estación base e infraestructura de red En cuanto al hardware disponible en la estación base, principalmente el proyecto se desarrolló sobre un PC Pentium II a 700MHz con 64 Mbytes de memoria RAM. Aunque el resultado final se ha probado en varios PC’ s con diferentes capacidades obteniendo un resultado satisfactorio en cada uno de ellos. En cuanto a la infraestructura de red existente en el laboratorio, se puede resumir en la existencia de tres hubs que, mediante una topología de estrella, interconectan seis ordenadores distribuidos por el laboratorio. Uno de estos ordenadores - 33 -

Sistema de comunicaciones inalámbricas para robots realiza tareas de servidor, haciendo las veces de puerta de enlace ofreciendo una salida hacia Internet.

3.2.2.

Selección de hardware

A continuación se describirán los elementos nuevos que se han adquirido para lograr los objetivos del proyecto. Enumerando para cada dispositivo sus características más relevantes por los que fueron seleccionados. 3.2.2.1. PC104-PCMCIA-1 Este hardware es esencial para proporcionar comunicación inalámbrica mediante el estándar IEEE 802.11b a la placa PC104+ ya que proporciona la interfaz que, mediante los buses de salida de la pc104+, hace posible la inserción de la tarjeta PCMCIA. Este dispositivo sigue el estándar PC104 y por tanto tiene un tamaño igual a la PC104+. La figura 3.4 muestra este dispositivo.

Figura 3.4: PC104-PCMCIA-1

Entre sus características técnicas destacamos: - Formato PC104 (16 bit). - Dimensiones 96 x 90 mm (3,8 x 3,6”). - Controlador VADEM 469 para 2 PCMCIAs tipo I, II o una PCMCIA tipo III. - Interfaz de bus tipo Bus PC104 - Dual-Slot-Drive (Soporte para dos PCMCIAs simultáneamente). 3.2.2.2. Orinoco PC Card Silver Antes de detallar las características propias de esta tarjeta cabe mencionar las razones que han llevado a seleccionar, de entre todos los productos 802.11b del mercado, los equipos Orinoco de la marca Lucent10 para el desarrollo del proyecto. Estas razones no son otras que el hecho de intentar encontrar una tecnología que al 10

Lucent Technologies tras descolgarse de AT&T se dividió en unidades de negocio más pequeñas. Fruto de esta división nació Avaya y Agere Systems. Avaya se encargaba de las redes dentro del sector empresarial mientras que Agere se encargaba de algo más específico como el negocio de la microelectrónica (chips). Orinoco es una división de Agere que fue comprada en el año 2000 momento en el cual pasó de llamarse WaveLan a llamarse Orinoco. En 2002, Proxim hizo suya la marca Orinoco y, al menos hasta el 2005, Agere y Proxim firmaron un acuerdo por el cual Agere proporcionaría chips, módulos y tarjetas 802.11 a Proxim.

- 34 -

Sistema de comunicaciones inalámbricas para robots mismo tiempo ofrezca productos comerciales y un funcionamiento contrastado y robusto en aplicaciones de desarrollo. En cuanto a los detalles de la tarjeta PCMCIA se refiere (figura 3.5), podemos destacar la utilización de 64-bits de encriptación WEP, que, frente a la encriptación de 128, 256 e incluso de 512 existentes actualmente, coloca a esta tarjeta entre las más pobres en este aspecto. Las razones que llevaron a seleccionar esta tarjeta fueron dos: - En el momento en que se realizó la compra del material, Lucent ofrecía únicamente dos posibilidades en cuanto a PC-Cards s refiere; PC Card Silver, con 64 bits y la PC Card Gold con 128 bits de encriptación WEP. - La selección de la primera frente a la segunda opción viene dada por el marco de trabajo. El consumo de energía que supone el uso de la tarjeta de 64 bits es menor al consumo de la de 128 bits y los requerimientos de seguridad son menos severos que los de consumo para nuestro proyecto concreto. Otras características que destacamos son: - Potencia nominal de salida: 15dBm11 - Consumo reducido: o Modo inactivo: 9mA o Modo recepción: 185 mA o Modo transmisión: 285 mA - Rango de cobertura: o Zonas abiertas: entre 160 m (a 11Mbps) y 550 m (a 1Mbps) o Zonas cerradas: entre 25 m (a 11Mbps) y 50 m (a 1Mbps) - Compatibilidad comprobada con sistemas operativos basados en Unix, gracias al chipset Aguere Systems.

Figura 3.5: Lucent Orinoco PC Card Silver

3.2.2.3. Orinoco Wireless Range Extender Antenna Se trata de una antena omnidireccional que mejora la calidad del enlace proporcionando un alcance extra en la cobertura de la PC Card, mejorando entre un 50% y un 15% el rango de cobertura en entornos abiertos o semiabiertos. La principal razón del uso de este tipo de antenas es para evitar posibles problemas de cobertura. Como principal característica destacaremos la ganancia de 2,5dBi. 11

dB: decibelio, unidad logarítmica de intensidad usada para indicar potencia ganada o perdida entre dos señales. dBi: ganancia en decibelios referente a un radiador isotrópico. Un radiador isotrópico es una antena teórica con igual ganancia a todos los puntos en una esfera isotrópica. dBm: decibelio referente a un milivatio dentro de una impedancia de 50 ohmios 0dBm= 1mW

- 35 -

Sistema de comunicaciones inalámbricas para robots

Figura 3.6: Orinoco Wireless Range Extender Antenna

3.2.2.4. Orinoco AP-500 Punto de acceso que proporciona la extensión de la red cableada a la WLAN y que soporta simultáneamente 50 usuarios conectados. Entre sus características destacamos: - Potencia nominal de salida: 15dBm 12 - Soporta “power over ethernet ” - Algoritmos de “Spanning tree13” - Tabla de control de acceso y autentificación Radius14 - DHCP y BOOTP15 - Soporta multi-canal - Rango de cobertura: o Zonas abiertas: entre 160 m (a 11Mbps) y 550 m (a 1Mbps) o Zonas cerradas: entre 25 m (a 11Mbps) y 50 m (a 1Mbps)

Figura 3.7: Orinoco AP-500

3.2.2.5. Wide-Angle Antenna Durante la descripción del marco del proyecto se define la zona principal a cubrir como la mayor zona exterior al edificio posible. Para lograr esta cobertura se ha seleccionado una antena direccional de ángulo de cobertura ancho que, colocada en el

12

Power Over Ethernet. Es una técnica que se emplea para llevar alimentación a puntos de acceso u otros dispositivos de red, empleando dos pares de conductores que quedan disponibles en los cables de conexión Ethernet. 13 Spanning Tree-Bridging Algoritmo o fórmula concreta que aplican los puentes transparentes para determinar dinámicamente la mejor ruta entre origen y destino. Este algoritmo evita los bucles de puentes dentro de una red 14 RADIUS: Sistema de autenticación y accounting empleado por la mayoría de proveedores de servicios de Internet (ISPs) si bien no se trata de un estándar oficial. Cuando el usuario realiza una conexión a su ISP debe introducir su nombre de usuario y contraseña, información que pasa a un servidor RADIUS que chequeará que la información es correcta y autorizará el acceso al sistema del ISP si es así. 15 DHCP(Dynamic Host Configuration Protocol) BOOTP (Bootstrap Protocol) Son protocolos de comunicaciones que permiten a los administradores de red gestionar y automatizar la asignación de direcciones IP en una red. DHCP es un protocolo más avanzado, pero ambos son los usados más normalmente

- 36 -

Sistema de comunicaciones inalámbricas para robots exterior del edificio, dará cobertura a la mayor distancia posible y con la mejor relación señal ruido posible. Llegados a este punto, la selección de la antena dependerá de las características de los otros elementos de la red inalámbrica, distancias, etc. Utilizando la fórmula que relaciona el nivel de señal con todos los factores condicionantes calcularemos aproximadamente la ganancia necesaria de nuestra antena. Esos son los datos para nuestros cálculos: - Distancia a cubrir (entre antenas): como primera aproximación podemos suponer 5km aproximadamente (siendo este nuestro máximo exagerado para asumir posibles pérdidas debidas a condiciones atmosféricas) - Longitud del cable A: El cable que conecta el access point con la antena externa mide aproximadamente 20,4 metros. - Longitud del cable B: El cable que conecta la antena (range extender antenna ) con la tarjeta de la estación móvil mide aproximadamente 1,5 metros. - Potencia tarjeta A: Entendemos tarjeta A como el punto de acceso ya que éste no es más que una tarjeta de las mismas características que la de la estación móvil. La potencia nominal es 15 dBm - Potencia tarjeta B: La potencia nominal es 15 dBm - Pérdida de conectores A: Consideramos de forma conjunta los 50 cm del pigtail16, los conectores tipo N y los empalmes desde el access point a la antena. Estos suman un total aproximado de 4,2dBm (2 dBm de pérdida cada conector más la pérdida de los 50 cm de pigtail) - Pérdida de conectores B: No se tienen en cuenta pérdidas en el conector de la estación móvil puesto que no existen empalmes y la pérdida en el conector de la PCMCA a la antena (range extender ) es mínima. - Ganancia de antena A: Valor a calcular - Ganancia de antena B: 2,5 dBi Ahora necesitaremos otros datos como son; la sensibilidad, el margen de ruido, la pérdida de señal por propagación y las pérdidas producidas por el tipo de cable. - Para un enlace correcto, la sensibilidad debe ser: o Para 11Mbit: -82dBm o Para 5,5Mbit: -87dBm o Para 2Mbit: -91dBm o Para 1Mbit: -94dBm - El margen ha de ser: o Mínimo: 15dB o Enlaces expuestos a interferencias (ciudad): 18dB o Enlaces con condiciones climáticas adversas: 22dB - La pérdida de señal por propagación entre antenas se puede calcular: Pp= 40 + 20 log (d)

Dónde Pp es la pérdida por propagación en dB y d es la distancia entre antenas en kilómetros.

16

Pigtail: Es un cable corto y flexible que se conecta entre la interfaz de red inalámbrica y el cable alimentador de antena Su función es el desacoplamiento mecánico

- 37 -

Sistema de comunicaciones inalámbricas para robots -

La siguiente tabla muestra la relación entre modelos de cable y la pérdida de señal / metro a una frecuencia de 2,4GHz: Cable RG-216 RG-58 LMR-200

Pérdida en dB/100m 136 81 54,2

Tabla 3.1.:Relación entre modelos de cable y pérdida de señal

Por tanto, aplicando esto a nuestro caso particular tenemos: Nivel de recepción de señal mínimo para nuestro enlace de 11 Mbit: -82 dBm, que podemos situar con un margen intermedio entre el mínimo y las interferencias que pueden crear los edificios colindantes en 20dB de margen, quedando: Nrs> -82 +20 Nrs> -62 dBm Calculamos ahora la pérdida por propagación en esos 5 km: Pp= 40 + 20 log (5)= 53,97 dB

El último dato que nos hace falta será la pérdida de los cables, utilizando la tabla y sabiendo que los cables son del tipo RG-216 y LMR-200: Pérdida del cable A: 20,4 m * 1,36 dB/m = 27,744 dB Pérdida del cable B: 1,5 m * 0,542 dB/m = 0,81 dB

Aplicando todo esto a la fórmula que recordamos a continuación, quedará: Nrs= Pt a -Pcoa-Pca a + Ga a –Pp + Ga b - Pca b - Pco b Entonces, el Nrs calculado deberá ser mayor a nuestro nivel de señal de recepción mínimo, quedando; (15 – 4,2 – 27,744 + Gaa – 53,97 + 2,5 – 0,81) > -62

Simplificando; (17,5 + Gaa ) > (86,724 - 62)

Por lo tanto; Gaa > 7,224 dB Nuestra antena, deberá por lo tanto, tener una ganancia mínima mayor de 7,224 dBi. Teniendo estos cálculos en consideración y sin olvidar que las suposiciones sobre el margen son variables, se selecciona una antena apropiada para nuestros requerimientos. Puesto que los requerimientos sobre tiempo real son muy deseables seleccionaremos una antena que cumpla con creces esta ganancia para asegurar una señal de ruido siempre menor a los 10 dB que hemos comentado que son mínimos para un buen desempeño de UDP en tareas de tiempo real. De entre las posibilidades del mercado se ha seleccionado la antena direccional “Wide Angle Antenna” de 12 dBi (figura 3.8). Estas son sus características - Ganancia 12 dBi (±1 dB) - Impedancia nominal: 50 Ω - Polarización: Vertical - Ángulo de apertura horizontal: 125° (±5°) - Ángulo de apertura vertical: 13° (±2°) - 38 -

Sistema de comunicaciones inalámbricas para robots -

Potencia media: 10 Vatios Tamaño: 537 x 181 x 76 mm Recubrimiento de plástico para exteriores.

Figura 3.8: 12 dBi Directional Wide Angle Antenna

3.3. SOFTWARE BÁSICO 3.3.1.

Sistema operativo de la estación base

En cuanto al software utilizado en la estación base no hay mucho que comentar puesto que se ha trabajado sobre la plataforma Windows. Se ha desarrollado código y probado el buen funcionamiento de este software sobre Windows 98, 2000 y XP.

3.3.2.

Sistema operativo de las estaciones móviles: QNX

La principal responsabilidad de todo sistema operativo es administrar los recursos de un computador. Todas las actividades en el sistema, como son manejar programas de aplicación, escribir ficheros en un disco, enviar datos a través de la red, etc. tienen que funcionar conjuntamente de la forma más compacta y transparente posible. Algunos contextos requieren una mayor rigurosidad en la administración y configuración de los recursos, comparado con otros. Las aplicaciones en tiempo real, por ejemplo, dependen del sistema operativo para manejar múltiples eventos en unos límites de tiempos fijos y críticos. El sistema operativo QNX está muy orientado a aplicaciones en tiempo real. Tiene la capacidad de proporcionar multitarea, y una rápida conmutación de contexto, entre otros, siendo todos ellos ingredientes esenciales para un sistema de tiempo real.

Figura 3.9: Interfaz gráfico de QNX

QNX permite además una gran flexibilidad. El programador puede personalizar el sistema para satisfacer las necesidades de su aplicación. Desde una - 39 -

Sistema de comunicaciones inalámbricas para robots configuración en bare-bone del kernel con una pequeña cantidad de módulos pequeños hasta un sistema de red amplia equipada para servir a cientos de usuarios, QNX nos permite configurar nuestro sistema para usar sólo aquellos recursos que requiramos con el fin de poder abordar nuestra tarea. QNX es capaz de alcanzar un alto grado de eficiencia, modularidad y simplicidad gracias a dos principios fundamentales: - Arquitectura de micro kernel - Comunicación entre procesos basada en paso de mensajes. Respecto a la interfaz con el usuario, cabe decir que este sistema operativo dispone de dos tipos de interfaces, como viene siendo habitual en muchos otros sistemas: Una interfaz en modo texto, sencilla, que permite interactuar con el sistema mediante comandos de sistema operativo que siguen el formato UNIX y una interfaz en modo gráfico llamada Photon (figura 3.9) que se activa como un programa independiente de forma similar a como lo hacía el antiguo Microsoft Windows 3.1x, respetando de esa manera su comentada modularidad. Otra de las ventajas importantes de este sistema operativo es que está muy orientado a la programación en el lenguaje C/C++.

3.4. CONFIGURACIÓN DEL HARDWARE E INFRAESTRUCTURA Los nuevos elementos de red adquiridos requieren una configuración y gestión. En este punto se comenta, tanto para la estación móvil como para la infraestructura base, los puntos principales de esta gestión y configuración. Hay que decir que la infraestructura que se ha montado en el laboratorio, siguiendo con la idea inicial del marco de trabajo ha sido la siguiente: - Colocación del punto de acceso como un elemento más dentro de la red cableada del laboratorio, proporcionándole una IP propia y configurando sobre este elemento los filtros de seguridad que se comentan más adelante - Instalación de la antena direccional en una plataforma exterior y ajuste de esta antena para obtener máxima cobertura y óptima señal. - Instalación y configuración de los elementos de comunicación, (tarjeta de red inalámbrica y antena omnidireccional), en la estación móvil.

3.4.1.

Software de gestión Orinoco

Junto con los elementos adquiridos se proporcionó un software que contenía los drivers, instrucciones de uso y aplicaciones de gestión que son utilizados para configurar el punto de acceso para proporcionar la comunicación así como seguridad necesaria en nuestro proyecto. Este software de configuración y gestión de la infraestructura base se llama AP Manager. A continuación se comentan los puntos más relevantes en la configuración del punto de acceso mostrando las reglas fijadas para el acceso a nuestra red inalámbrica y en que forma se configuran estos puntos con el software proporcionado por Orinoco. - Asignación de IP y máscara dentro del rango de la subred del laboratorio. (No es necesario añadir la puerta de enlace puesto que en esta configuración el dominio de broadcast es el mismo para la red cableada e inalámbrica). - Asignación del nombre de red inalámbrica (SSID). Este nombre de red, como ya se ha dicho, es independiente del nombre de grupo o nombre de dominio de la red cableada. Ningún elemento de red inalámbrica que no conozca este nombre de red será admitido por nuestro access point. - 40 -

Sistema de comunicaciones inalámbricas para robots -

Canal de frecuencias utilizado: De los tres canales disponibles se seleccionó el canal 10 (frecuencia portadora de 2,457GHz). - Activación de la seguridad de acceso mediante encriptación WEP. - Puesto que como se ha visto, la tarjeta de red inalámbrica utiliza 64 bits, se decidió una clave de 4 letras y se configuró el punto de acceso para denegar cualquier dato sin encriptación. - Como ya se ha comentado, la seguridad en redes inalámbricas es un punto muy relevante. El hecho de utilizar encriptación WEP no es suficiente así que se decidió añadir un último nivel de control de acceso; la autentificación por dirección MAC, de forma que actualmente el único elemento de red al que nuestro punto de acceso le la permiso para la comunicación con la red del laboratorio es nuestra PCMCIA. Las siguientes figuras nos muestran las capturas realizadas durante la configuración de la infraestructura inalámbrica:

(A) ZONA EXTERIOR Figura 3.10: Acceso a la gestión del AP

Configuración de la clave de encriptación WEP

Configuración del control de acceso por MAC

Figura 3.11: Configuración de la seguridad en la red WLAN

- 41 -

Sistema de comunicaciones inalámbricas para robots Además de la posibilidad de gestión del punto de acceso, la aplicación “AP Manager” proporciona la posibilidad de monitorización. Dentro de esta opción se encuentran herramientas útiles como la posibilidad de monitorizar en tiempo real la cantidad de tráfico UDP o TCP que circula en nuestra red inalámbrica. También es posible consultar las entidades asociadas a nuestro punto de acceso en un momento determinado.

Figura 3.12: Estaciones asociadas al punto de acceso.

3.4.2.

Configuración de la interfaz inalámbrica sobre QNX

En cuanto a la configuración de los dispositivos de la estación móvil se refiere, los drivers suministrados por el software que se incluía con los dispositivos no están soportados por el sistema operativo QNX. Sin embargo si existen drivers de libre distribución para este hardware que resuelven este problema. - Configuración de la PCMCIA. El módulo que proporciona el kernel para estas interfaces, soporta, entre otros, nuestro chipset de Avaya (Vadem VG-469) y por tanto podemos utilizar el servidor devp-pccard para lanzar este driver al iniciar el sistema operativo. El servidor ofrece diversas opciones para la gestión de el adaptador PCMCIA como son; los puertos de entrada- salida, las IRQ (quedando por defecto un intervalo de polling cada segundo para comprobar los posibles cambios de estado). - Configuración del controlador Orinoco. Para la gestión del controlador de red inalámbrico Orinoco se utilizan los drivers contenidos en el núcleo QNX indicándole, al mismo tiempo, que cargue la pila de protocolo TCP/IP completa. Para lanzar el soporte de este módulo se utiliza el comando io-net, que realiza la carga de drivers y protocolos de una forma dinámica. Por tanto la siguiente línea de comandos es la que indica los drivers y el protocolo a usar para nuestro controlador: io-net –d Orinoco –p tcpip - Parámetros de red inalámbrica. Para lograr la comunicación se deberán configurar los mismos parámetros que se han introducido en la estación base (mismo SSID, clave de encriptación17.). Estos datos se

17

Como se ve en la figura 3.13 a la clave está en formato hexadecimal. Nota: no se muestra la clave completa.

- 42 -

Sistema de comunicaciones inalámbricas para robots pasarán como parámetros durante la carga del controlador utilizando las opciones que proporciona el driver devn-orinoco.so. - Parámetros de interfaz de red. Por último será necesario indicar la IP, máscara de subred, dominio y puerta de enlace predeterminada. Esto se hace mediante el comando netmanager. Este comando, entre otros, acepta una opción (-f) de forma que, indicándole la ruta a un fichero, obtiene los datos de red contenidos en él. Para lograr toda la funcionalidad de la interface inalámbrica todos estos comandos se han unificado escribiéndolos dentro de un fichero de sistema (rc.local) y dotando a este fichero de propiedades de ejecución. De esta forma, cuando el sistema operativo arranca entiende el fichero rc.local como parámetros adicionales y ejecuta los comandos contenidos en él. A continuación se muestran estos ficheros de configuración. El primero de ellos (figura 3.13 a) es el contenido del fichero rc.local cuyo path es: /etc/rc.d/rc.local, el segundo (figura 3.13 b), es el fichero que contiene los parámetros de interfaz de red que se llama con el comando netmanager. Este fichero se ha llamado wirelessnet.cfg y su path es: /etc/wirelessnet.cfg. sleep 1 devp-pccard sleep 1

io-net -d orinoco station=Cabrit, key1=0x6c61XXX, -p tcpip

default_key=1.

sleep 2 netmanager -f /etc/wirelessnet.cfg

(a)

[global] hostname localhost domain Wlabelec nameserver 130.206.33.1 route 192.168.64.1 0.0.0.0 0.0.0.0

/etc/rc.d/rc.local

[en0] type ethernet mode manual manual_ip 192.168.64.23 manual_netmask 255.255.255.0 (b)

/etc/wirelessnet.cfg

Figura 3.13: ficheros de configuración de la interfaz inalámbrica sobre QNX

- 43 -

Sistema de comunicaciones inalámbricas para robots

4. SOFTWARE DE COMUNICACIONES En este capítulo se desarrollará todo lo referente al software necesario para completar los objetivos planteados en el presente proyecto. Una vez comprobado que existe enlace entre nuestra estación base y la estación móvil18 podemos adentrarnos en los aspectos que afectan al servicio final de comunicaciones que se desea ofrecer, esto es, una interfaz que permita al usuario final utilizar toda la infraestructura montada hasta ahora logrando un flujo de datos entre los extremos. Nuestro frente de actuación para mejorar en lo posible el comportamiento de las comunicaciones inalámbricas sobre TCP/IP se centra en este software de comunicaciones, más concretamente en la capa de transporte.

4.1. PROPUESTA DE SOLUCIÓN DE SOFTWARE DE COMUNICACIÓN En cuanto al protocolo de transporte que se utilizará para alcanzar los objetivos del proyecto, parece claro que se descarta el uso de TCP debido a los aspectos ya comentados. Sin embargo siguen siendo deseables algunos de los servicios que ofrece TCP, como puede ser la fiabilidad. Los requisitos que debe cumplir el software de comunicación en nuestro proyecto son los siguientes: - Fiabilidad. Se requiere un servicio que garantice la transferencia de mensajes extremo a extremo. - Mínima sobrecarga. Tanto en lo referente al hardware de las estaciones móviles (memoria y CPU) como al ancho de banda del enlace inalámbrico. - Tiempo real dentro de las posibilidades que ofrece el enlace. Como vemos estos tres requisitos nos sitúan en un compromiso a la hora de descartar el protocolo de transporte TCP puesto que la fiabilidad ofrecida por éste es el principal argumento para utilizarlo. No obstante, los requisitos de tiempo real y mínima sobrecarga son, claramente, características propias de UDP. Lo que definitivamente nos decanta a seleccionar UDP como nuestro protocolo de transporte base es el mal comportamiento que podría llegar a mostrar TCP sobre la red inalámbrica explicado en la sección 2.2. Será, por tanto, necesario realizar una aplicación que sea capaz de ofrecer esta fiabilidad que necesitamos y que UDP no nos ofrece. Esto significa implementar algún tipo de control de errores. Por fiabilidad se entiende que los mensajes se han de entregar íntegramente extremo a extremo, recuperándose de las pérdidas del nivel de red, paquetes duplicados y paquetes cuyo contenido ha sido alterado, siendo además un protocolo FIFO lo que implica que los mensajes se entregarán al receptor en el orden en el que fueron enviados por el emisor. Para implementar esta fiabilidad sobre UDP, se diseñará e implementará un nuevo protocolo que llamaremos STCP (SimplexTCP)19. No hay que olvidar que este nuevo protocolo se basa en el protocolo de transporte UDP, es decir, no será un nuevo protocolo de transporte sino que se trabaja a nivel de aplicación proporcionando, en este

18

Esta comprobación se hace mediante herramientas de gestión de redes (ping, tracert, netstat, arp, etc. ). A partir de ahora se hará referencia siempre a una única estación móvil aunque realmente puedan existir más de una. 19 El diseño de STCP está basado en algunos protocolos existentes que fueron consultados durante la fase de estudio teórico de este proyecto. El más relevante de los protocolos consultados, del cual se han obtenido algunas ideas, incluido el propio nombre ‘STCP’ es el diseñado en la “Práctica de Redes I” del GS y C de la Universidad Rey Juan Carlos (referencia bibliográfica en: Referencias bibliográficas/Enlaces de Internet consultados / Nº2).

- 44 -

Sistema de comunicaciones inalámbricas para robots nivel un control de errores adecuado. También es necesario mencionar que aunque UDP es un protocolo no orientado a conexión, STCP deberá, para poder implementar la fiabilidad, ser capaz de guardar el estado en ambos extremos de la comunicación (receptor y emisor). Sería incorrecto decir que logramos que UDP sea un protocolo orientado a conexión pero sí podemos decir, como se verá más adelante, que STCP deberá incluir fases de establecimiento y cierre de conexión. Es por ello que, en diversos puntos de este capítulo se utilizan los términos de establecimiento o cierre de conexión refiriéndose no a UDP, sino a la implementación realizada a nivel de aplicación.

4.1.1.

Modelo cliente - servidor

Desde el punto de vista de las aplicaciones, TCP/IP solo proporciona los mecanismos básicos para transferir datos. TCP/IP permite a un programador establecer comunicaciones entre programas de aplicación y transferir datos en los dos sentidos. Decimos, por tanto, que TCP/IP proporciona comunicación entre entidades del mismo nivel (peer-to-peer). TPC/IP especifica como se transfieren los datos entre aplicaciones. Pero no especifica como interactúan las aplicaciones que utilizan este nivel. El paradigma cliente - servidor especifica el método en que se organizan los programas de aplicación en entornos distribuidos. Para entendernos mejor, imaginemos un caso concreto. Pensemos en dos programas que, ejecutándose en máquinas distintas, desean comunicarse. Primero ejecutamos uno de estos programas. Éste, inmediatamente intenta iniciar una comunicación con la otra estación. Puesto que este segundo no se encuentra en funcionamiento, el primer programa producirá un mensaje de error indicando que no ha sido posible la conexión. Podemos reintentar la ejecución de los programas, pero la probabilidad de que coincidan, es decir, que se pueda establecer la conexión es muy baja. El modelo cliente - servidor proporciona una buena solución a este problema: una de las partes se ejecuta inicialmente, y se queda indefinidamente a la espera que la otra parte contacte con ella. El primer razonamiento puede llevar a pensar que TCP/IP se debería de encargar de esto, pero de hecho TCP/IP no proporciona ningún mecanismo para hacer que un programa pase a ejecutarse cuando llega un mensaje direccionado hacia él. Por tanto el paradigma cliente – servidor es el que nos proporciona esta interfaz de comunicación. Éste paradigma divide la comunicación en dos categorías: el que espera una comunicación y el que la inicia. Estas categorías son las que nos permiten diferenciar entre cliente y servidor. La ejecución de una aplicación cliente, el iniciador de la comunicación implica las siguientes acciones: - Ponerse en contacto con el servidor - Realizar una petición - Esperar la respuesta - Una vez llegada la respuesta continuar el proceso. En cuanto a la ejecución de un software servidor, estas son las acciones: - Quedar esperando peticiones de cliente cuando se inicia - Realizar las operaciones necesarias, conforme a las peticiones recibidas - Devolver los resultados a los clientes. Hay que decir que esto no es más que una primera aproximación, puesto que, como veremos, nuestro software servidor y cliente no son estrictamente programas que inician o esperan comunicación. Más bien podemos decir que tanto uno como otro - 45 -

Sistema de comunicaciones inalámbricas para robots son capaces de iniciar, realizar peticiones, realizar operaciones y devolver resultados, es decir, son al mismo tiempo servidor y cliente.

4.1.2.

API de comunicaciones

Se pueden desarrollar múltiples aplicaciones cliente servidor que cumplan con los objetivos de este proyecto. A continuación se describen sus requerimientos pero antes de ello, deberá quedar claro hasta dónde llegamos en este proyecto y que servicios se van a ofrecer al usuario del sistema de comunicaciones. Como se ha mencionado en varias ocasiones, el objetivo final del proyecto no es otro que la transferencia fiable de datos de control, imágenes y ficheros entre estaciones (tanto estaciones base como móviles). Para lograr esto, como se ha visto en la sección anterior, no es suficiente el montaje de una infraestructura de red inalámbrica y la configuración de los elementos. Será necesario desarrollar este software cliente servidor que proporcione la interfaz que, finalmente, será la que ofrezca, ocultando el resto de trabajo desarrollado en el proyecto, una manera de comunicar las estaciones. ¿De que forma ofrecerá esta interfaz los servicios demandados?. La respuesta es con una API20. El sistema operativo de un ordenador debe proporcionar a un programador de aplicaciones, que desee utilizar los servicios de la pila de protocolos TCP/IP, una interfaz mediante la cual su aplicación interactuará con el sistema operativo. Este es el módulo que “enlaza”, de alguna forma, el software de aplicación desarrollado por el programador con el software de protocolo interno al sistema operativo.

Figura 4.1: estructura de interfaces de comunicaciones

20

API - Application Program Interface o Application Programming Interface. Una interfaz de programa de aplicación o de programación de aplicaciones es el método específico prescrito por un sistema operativo o por cualquier otra aplicación mediante el cual un programador que escribe una aplicación puede hacer solicitudes al sistema operativo o a otra aplicación. Una API puede contrastarse con una interfaz gráfica de usuario (GUI) o una interfaz de comando (ya que ambas son interfaces directas del usuario) como formas de interactuar con un sistema operativo o un programa.

- 46 -

Sistema de comunicaciones inalámbricas para robots

Esta interfaz no es más que una serie de funciones que el programador puede utilizar para comunicarse con otras entidades remotas siguiendo las “normas” de los protocolos TCP o UDP. Al igual que esta interfaz del sistema operativo (interfaz de sockets21), ofrece un conjunto de funciones al programador y oculta otras tantas funciones que son internas al funcionamiento de la pila de protocolos, nuestra tarea consistirá en desarrollar un software de aplicación que, utilizando la interfaz de sockets de UDP añada ciertas funciones para lograr fiabilidad y ofrezca como públicas otro abanico de funciones que finalmente son las que usará el programador que desee comunicación. En la figura 4.1 se ilustra gráficamente esta estructura de interfaces y aplicaciones. Entre las funciones que nuestra interfaz propia (interfaz de aplicación de fiabilidad) ofrece a la aplicación que trabaja por encima hay que destacar las funciones que hacen posible que se informe a esta aplicación de usuario de ciertos eventos que ocurren dentro de nuestro programa y que afectan o pueden afectar de alguna forma a la aplicación de usuario. Así, por ejemplo, cuando se reciba un mensaje cualquiera de una entidad remota será necesario avisar a la aplicación de usuario para que tenga constancia de este evento.

4.2. STCP (SIMPLEX TCP) Llegados a este punto, nos introduciremos en las características de este nuevo protocolo desarrollado para aportar fiabilidad sobre UDP. Cuando nos enfrentamos al reto de diseñar e implementar un nuevo protocolo, existen multitud de aspectos a considerar, desde el conocimiento detallado del funcionamiento de la comunicación ofrecida por el sistema operativo, el diseño del formato de las tramas que se transferirán, la sincronización de los procesos, la selección, diseño e implementación del control de errores, etc. La documentación de este capítulo se estructura de forma que, para cada uno de los niveles desarrollados, quede claro el diseño y funcionamiento de los procedimientos que llevan a cabo las tareas correspondientes a este nivel. Por ello es inevitable documentar al mismo tiempo aspectos de diseño y de implementación ya que entender los detalles internos de nuestro protocolo STCP es de gran ayuda para desarrollar aplicaciones que aprovechen su funcionalidad.

4.2.1.

Diseño general del protocolo (Posibles soluciones)

En esta sección se muestran los posibles diseños barajados para proporcionar esa fiabilidad necesaria en la comunicación y se documenta el porqué se descartan las ideas iniciales dejando paso al protocolo definitivo. Para mantener las ventajas que ofrece el uso de UDP sobre TCP en nuestra comunicación es necesario diseñar un protocolo de aplicación evitando al máximo complicar el funcionamiento de UDP. Por tanto, el primer planteamiento es preguntarse dónde reside la complejidad de TCP y si es posible evitarla. A continuación vamos a resumir algunos aspectos de la estructura de proceso usada por TCP y UDP poniendo de manifiesto esta diferencia de complejidad.

21

Un descriptor de socket no es más que un índice, que el sistema operativo utiliza para apuntar a la estructura de datos que la aplicación necesita para realizar operaciones de comunicación de red. El socket por tanto es un valor entero que proporciona el sistema operativo a la aplicación que lo solicite. Puesto que no es objetivo de este proyecto profundizar en la interficie de socketes se hará mención a terminología relacionada con esta interficie sin profundizar en su significado.

- 47 -

Sistema de comunicaciones inalámbricas para robots La estructura del proceso usada para manejar datagramas UDP entrantes es muy diferente a la que se utiliza para TCP. Debido a que UDP es mucho más simple que TCP, el módulo de software UDP no ejecuta un proceso independiente. En su lugar, consta de procedimientos convencionales que ejecutan el proceso IP para manejar un datagrama UDP entrante. Estos procedimientos examinan el número de puerto destino y lo utilizan para seleccionar una cola (puerto) del sistema operativo para los datagramas entrantes. El proceso IP deposita el datagrama UDP en el puerto correspondiente, de donde un programa de aplicación puede extraerlo. La figura 4.2 muestra esta estructura frente a la utilizada por TCP.

Figura 4.2: Estructura del proceso de entrada TCP/IP

Esta estructura muestra como se utiliza un subproceso de ejecución independiente para aislar las piezas del software de protocolos, haciendo cada uno más fácil de diseñar, entender y modificar. Cada subproceso o proceso se ejecuta de manera independiente, ofreciendo un paralelismo aparente. La mayoría de software de protocolos tienen un proceso independiente para el IP, otro para la entrada, otro para la salida TCP y otro para la administración de temporizador de TCP, así como un proceso para cada programa de aplicación. Como hemos mencionado UDP no trabaja de la - 48 -

Sistema de comunicaciones inalámbricas para robots misma forma ya que utiliza procedimientos convencionales que ejecutan el proceso IP. Sin embargo, pronto veremos que para ofrecer fiabilidad se hace indispensable el uso de procesos independientes que funcionen de forma paralela gestionando los diferentes eventos que pueden suceder de forma asíncrona. Por tanto no nos libraremos de la complejidad de manejar varios procesos pero si podemos hacer estos procesos mucho más sencillos que los implementados en TCP. Pronto entraremos en detalle en estos procesos. Otro aspecto del protocolo TCP a nivel de funcionamiento es el hecho de que sea orientado a conexión. Este funcionamiento hace que sean necesarias fases de establecimiento y liberación de la comunicación. Estos son procedimientos muy costosos que implican un intercambio de datos considerable, lo que conlleva un consumo de recursos (tanto en términos temporales como de procesador), que se podría plantear eliminar en nuestro STCP. Estas fueron las bases del primer diseño del protocolo. Puesto que el tipo de información más común con el que se trabajará (los comandos), son paquetes de tamaño muy reducido (aproximadamente 80 bytes) y que además el tráfico no será un flujo constante sino más bien transmisiones eventuales entre estaciones (con lo que no tiene sentido implementar ventana deslizante en este caso) se planteó un protocolo que añadiese control de errores de la forma más simple posible. Esto significa añadir un número de secuencia (SN) en cada datagrama UDP. Para cada paquete recibido, la estación receptora enviará un reconocimiento (ACK) con el siguiente número de secuencia que espera recibir, de forma que la estación emisora no tuviese permiso para enviar el siguiente hasta recibir la confirmación de recepción correcta del primer datagrama enviado, exactamente de la misma forma que lo hace ARQ Stop & Wait estudiado en la subsubsección 2.2.1.3.1. En un primer momento, la idea de eliminar las fases de establecimiento y liberación de comunicación puede parecer una buena idea, puesto que aunque nos vemos obligados a guardar el estado y algunos datos de la comunicación (siguiente número de secuencia esperado, siguiente reconocimiento esperado, último datagrama enviado, etc.), nos liberamos de la carga de las pesadas fases de establecimiento y cierre de comunicación. Pero es fácil ver que este caso no es factible por varios motivos descritos a continuación: - ¿De que forma sabe la estación receptora cual es el primer número de secuencia que debe recibir?. - ¿Como puede saber la estación receptora en que momento debe dejar de “escuchar” a la estación emisora? Como solución a estas cuestiones se podría plantear establecer un número de secuencia inicial conocido por las dos estaciones o tal vez colocar una marca de identificación en el primer datagrama enviado, pero el problema se transforma puesto que ¿Cuándo se dejará de aumentar el número de secuencia?, es decir ¿en que momento se volverá a el número de secuencia inicial conocido?. Esta pregunta también tiene una posible solución y podría ser, por ejemplo, que la máquina emisora marcase también de alguna forma el último paquete que desea enviar por el momento. Pero de nuevo, aun superando este problema, veamos el funcionamiento de este diseño en el caso que muestra la figura 4.3.

- 49 -

Sistema de comunicaciones inalámbricas para robots

Figura 4.3: Primer diseño STCP22

La solución a este último problema mostrado en la figura 4.3 no es otro que no repetir el número de secuencia inicial cada vez que se cierre y vuelva a “establecer” una nueva comunicación. Normalmente las implementaciones existentes de TCP/IP deciden el primer número de secuencia de forma aleatoria, lo que implica, desde el punto de vista de implementación, seleccionar un número aleatorio en base a una semilla temporal, con lo que dos comunicaciones consecutivas como las que representa la figura anterior evitarán el problema en cuestión. Bien llegados a este punto, nos paramos a pensar en lo que ocurre si complicamos en un nivel el caso planteado. Esta complicación viene dada cuando, como se ha comentado, nuestra implementación no consta de una estación emisora y una receptora sino de dos estaciones trabajando como emisoras y receptoras al mismo tiempo. Esto no implica más que duplicar el esquema anterior de forma que tanto una estación como otra intercambien los datagramas iniciales para indicar a la estación remota cual será su número de secuencia inicial. Pues bien, ya hemos llegado a una solución válida para nuestro protocolo modificando en ciertos aspectos la idea inicial, sin embargo si nos paramos a ver lo que ha sucedido veremos que sin poder evitarlo hemos acabado realizando un establecimiento de conexión. Sin ir más lejos hemos llegado a una estructura de establecimiento de conexión estudiada en comunicaciones llamada three way handshake, o acuerdo de conexión de tres vías. Realmente no implementa tanta complejidad como el establecimiento utilizado por TCP pero aun así, inevitablemente nuestro protocolo se va complicado a medida que profundizamos en su comportamiento. Este y otros detalles serán tratados en las siguientes secciones. El siguiente punto fuerte de nuestro planteamiento de cara al diseño del protocolo fue la modularidad. Dividiendo el problema en varios niveles logramos obtener una estructura más clara de todas las tareas que son necesarias para implementar nuestra librería de fiabilidad sobre UDP. Implementando así, dentro de cada nivel, las funciones que requiere el nivel superior. Esta forma de dividir en capas el problema facilita la posibilidad de modificar el diseño introduciendo cambios en el código. Así, por ejemplo, si en un futuro se desease implementar un control de errores más complejo o tal vez algoritmos adaptativos en la gestión de los time out (expiración de temporizadores) no sería necesario modificar ni repasar punto por punto todo el código,

22

SYN es un valor que indica que, efectivamente, el número de secuencia de ese datagrama es el primero. FIN indica que este será el último datagrama que se desea enviar por el momento. DATA indica que el contenido del datagrama son datos de aplicación.

- 50 -

Sistema de comunicaciones inalámbricas para robots simplemente se vería afectado el módulo encargado de ello. La siguiente sección detalla uno a uno el diseño de estos niveles.

4.2.2.

Descripción del protocolo STCP

El conjunto de procedimientos que forman la librería de usuario implementada están agrupados en cuatro niveles: - Nivel de comunicación. Es el primer nivel, encargado de la interacción con la interfaz UDP ofrecida por el sistema operativo - Nivel de trama. Trata la información proporcionada por los niveles de la capa superior e inferior formando, ordenando, comprobando e insertando o extrayendo las cabeceras de las tramas STCP. - Nivel de fiabilidad. Gestiona la información proporcionada por los números de secuencia y los temporizadores actuando de forma consecuente para lograr la fiabilidad en la comunicación. - Nivel de interfaz con el usuario. En este módulo se incluye el conjunto de procedimientos que podrá manejar el usuario para la utilización del STCP. Quedarán ocultos el resto de niveles. Los siguientes puntos están dedicados a explicar uno a uno el diseño y la implementación de los cuatro niveles, para ello se describen las funciones que forman cada capa. Algunas de las funciones no se comentarán puesto que no son más que procedimientos utilizados para hacer posible la implementación en el lenguaje de programación, funciones cuyo objetivo es, por ejemplo, la transformación de tipos de variables. Las explicaciones que muestra este documento no pretenden profundizar en la implementación tanto como en el diseño, si se desea conocer más en detalle el funcionamiento, el código anexado, en el CD adjunto a la documentación, se encuentra debidamente comentado. Durante esta descripción no se diferenciará entre la implementación sobre QNX o Windows ya que las diferencias entre ellos son mínimas. La principal diferencia es el uso de la librería sockets.h o de winsock2.h por parte de QNX y de Windows respectivamente. 4.2.2.1. Declaración del protocolo a nivel de comunicación Este es el primer nivel del protocolo, es el que trabaja directamente con la interfaz de sockets UDP ofrecida por el sistema operativo. Los procedimientos contenidos en este nivel proporcionan una serie de servicios que ocultan la complejidad de la interfaz UDP. A continuación se enumeran y describen dos de las funciones más representativas: - ChangeBroadOpt. Esta función modifica las opciones del socket activando o desactivando el modo escuchar broadcast. - MakeBroadCastBind. Utilizando la función ChangeBroadOpt coloca al socket, pasado como primer parámetro, de forma que escuche los datagramas procedentes de cualquier IP (broadcast) con destino el puerto de protocolo23 introducido como segundo parámetro. Como se puede apreciar, en este primer nivel no existe mucha complejidad ni diseño, simplemente pretende ocultar al nivel superior los detalles de la interfaz de sockets. Proporcionando las herramientas que realmente le serán útiles a la siguiente

23

El puerto de protocolo sirve para especificar la aplicación concreta a la que van destinados los datos. Es decir, el número de puerto de protocolo es la herramienta que utiliza UDP para realizar el demultiplexado.

- 51 -

Sistema de comunicaciones inalámbricas para robots capa. El conjunto de funciones que forman este nivel están contenidas en los ficheros llamados UdpTools.c y UdpTools.h. La mayoría de las funciones que se irán mostrando devuelven un entero que informa de los posibles errores generados a los procedimientos de que hacen uso de estas funciones. Así, por ejemplo, todas las funciones de este primer nivel devuelven un (-1) como consecuencia de este posible error. 4.2.2.2. Declaración del protocolo a nivel de trama El formato de los paquetes STCP está constituido por tres campos. En la figura 4.4 se muestra este formato y a continuación se describen cada uno de los campos

Figura 4.4: Formato de cabecera STCP

Como se puede apreciar, los tres campos de la cabecera tienen un tamaño de 1 byte cada uno. Sin embargo esta es sólo una posible solución, ya que, la implementación de este nivel permite redefinir la estructura de la cabecera modificando el tamaño de cada uno de los campos. Al igual que TCP, todas las cabeceras de los paquetes STCP son similares, pero a diferencia de lo que ocurre con TCP, utilizaremos campos que no son banderas (flags), sino valores numéricos para distinguir entre los diferentes tipos de paquetes. El primer campo (Suma de comprobación) está dedicado a la detección de errores. La función de este campo es asegurar la integridad de los datos que llegan a la entidad receptora. Este campo se calcula, sencillamente, realizando una or exclusiva (XOR) del resto del datagrama UDP, es decir, el ámbito de la suma de comprobación será el campo tipo, el campo número de secuencia y la totalidad de los datos de usuario. Así, cuando la estación transmisora forma la trama STCP calcula este campo añadiéndolo a la trama, la entidad receptora, realiza de nuevo la XOR del ámbito de suma de comprobación y comprueba si el campo calculado y el recibido coinciden, de no ser así la función devuelve un (-1), avisando a las capas superiores del error. Existen numerosas técnicas para la detección de errores, desde la más sencilla comprobación de paridad hasta las complejas ecuaciones de comprobación de redundancia cíclica. De todas ellas se eligió la técnica utilizada puesto que nos ofrece un compromiso entre eficiencia y consumo de tiempo y recursos hardware. Incluso en un principio se planteó la utilización de técnicas de detección y corrección de errores aunque esta idea se descartó debido a la complejidad que implica este tipo de técnicas. Durante la sección 4.2.1. Diseño general del protocolo, se ha hablado de distinguir tramas que contienen marcas indicando inicio de comunicación (SYN), - 52 -

Sistema de comunicaciones inalámbricas para robots reconocimientos (ACK), datos (DATA) y finalización de la comunicación (FIN). Estos son los posibles valores que contendrá el campo Tipo. Como se ha mencionado, la distinción entre el tipo de tramas no se realiza, como en TCP, mediante flags, sino que cada uno de estos tipos es una constante numérica definida en ambas partes de la comunicación. La tabla siguiente nos muestra los códigos utilizados para cada tipo. TIPO DATA ACK SYN FIN

CÓDIGO 1 2 3 4

Tabla 4.1: Constantes numéricas de los tipos de trama definidos.

Cabe mencionar que siguiendo con la idea de lograr un protocolo modular, es posible añadir nuevos tipos de trama, así podríamos pensar en añadir un tipo reset (RST) que proporcionaría mayor funcionalidad al protocolo. El campo número de secuencia indica el número de secuencia del paquete. Los números de secuencia en STCP se refieren a números de paquete y no a números de bytes como en TCP. Así, para los paquetes tipo 1 (DATA), el número de secuencia se va incrementando con cada paquete consecutivo que se envía. Para los paquetes tipo 2 (ACK), el número de secuencia indica el número del siguiente paquete de datos que el receptor espera recibir. Para los paquetes de tipo 3 (SYN) y 4 (FIN), el número de secuencia indica, respectivamente el número de secuencia que tendrá el primer paquete de datos de la conexión y uno más que el que ha tenido el último paquete de datos de la conexión. Al igual que ocurre con el tamaño de cada paquete, la estructura que contiene estos campos están definidos en el fichero FrameLevel.h. Es posible, modificando la estructura, añadir o modificar los campos. Así podría resultar interesante añadir un nuevo campo (tamaño de ventana), que indicase el tamaño de ventana en caso de implementar ventana deslizante. La implementación que se presenta en esta documentación mantiene la estructura de cabeceras que muestra la figura 4.4. El tamaño máximo de un paquete STCP también está definido en este fichero. Puesto que inicialmente de entre los tipos de información que se pueden transmitir, la transmisión de ficheros es la que requiere mayor tamaño de datos, se ha fijado una longitud útil (sin incluir la longitud de la cabecera), que llega a un compromiso entre esta necesidad y el consumo de recursos que supone fijar un tamaño máximo mayor. Esta longitud útil son 512 bytes pudiendo ser modificada sin ninguna repercusión en el funcionamiento del protocolo. El tamaño de los datos de usuario no tiene porque ser 512, puede ser menor, y no es necesario indicar este tamaño en las cabeceras STCP ya que os protocolos de niveles inferiores (IP y UDP) llevan consigo la longitud del paquete. La longitud total del paquete STCP será por tanto 515 (datos de usuario más la cabecera STCP). La siguiente figura (figura 4.5), nos muestra la comparativa entre el tamaño de cabeceras TCP y STCP.

- 53 -

Sistema de comunicaciones inalámbricas para robots

Figura 4.5: Comparación tamaño cabeceras TCP y UDP

Observamos que el diseño de nuestro protocolo mejora notablemente el overhead debido a las cabeceras TCP, de hecho, el uso de nuestro protocolo supone un 45% menos de overhead que en el uso de TCP. En otras palabras, para cada paquete enviado con la misma cantidad de datos de usuario, nuestro protocolo envía 9 octetos menos que TCP. Otro aspecto importante es que STCP, al estar implementado sobre el protocolo UDP, la demultiplexación que habría que realizar al ser STCP un protocolo de transporte, no es necesaria, ya que UDP la hace por nosotros. El nivel de trama STCP está dedicado a aportar la funcionalidad necesaria relacionada con el envío y recepción de paquetes STCP sin entrar en la gestión de los números de secuencia ni el tipo de datos. A continuación haremos referencia al conjunto más relevante de procedimientos que forman este nivel. -

-

-

SendPacket. Esta función es básica para el protocolo, admite como parámetros los datos de la comunicación 24 de la máquina destino, el tipo de datos, el número de secuencia, los datos del nivel superior y la longitud de estos últimos datos. Los dos primeros parámetros junto con la suma de comprobación (Checksum), que se realiza dentro de esta función, forman la cabecera STCP. De esta forma la función SendPacket rellena la estructura de cabecera STCP y envía, utilizando las funciones proporcionadas por el nivel UdpTools, el PDU de la aplicación, a la capa IP. SendBroadCast . Utilizando la función SendPacket envía un paquete a la dirección IP de broadcast haciendo que cualquier ordenador dentro de la misma subred que la máquina emisora, que escuche en el puerto pasado como parámetro, reciba el paquete. RcvPacket. Esta función realiza la tarea inversa a SendPacket, es decir, cuando se llama, rellena los campos de la cabecera STCP con los datos leídos por la red y de esta forma devuelve la cabecera con formato

24

A partir de este momento, se entiende como datos de la comunicación el descriptor de socket, el puerto de protocolo y la estructura de dirección final remota.

- 54 -

Sistema de comunicaciones inalámbricas para robots STCP. Hay que decir que antes de rellenar la cabecera y devolver los datos de usuario recibidos, realiza la comprobación del Checksum y en caso de error devuelve el campo de datos vacío. De esta forma, el nivel superior puede detectar errores sucedidos en este nivel. Como resumen, la siguiente figura (figura conceptualmente, la funcionalidad de este nivel de tramas:

Funcionamiento del procedimiento SendPacket

4.6)

nos

muestra,

Funcionamiento del procedimiento RcvPacket

Figura 4.6: Funcionalidad del nivel de tramas

4.2.2.3. Declaración del protocolo a nivel de fiabilidad Éste es el nivel más importante del protocolo y, sin duda, el más complejo. En este nivel se implementan los algoritmos que aseguran la recepción de paquetes en el mismo orden en que fueron enviados, se encargan de la retransmisión en caso necesario, descartan los paquetes duplicados y erróneos, etc. Podemos decir que dentro de este nivel se diferencian tres fases; establecimiento de la comunicación, intercambio de datos entre entidades del mismo nivel y cierre de la comunicación. También dentro de este nivel nos enfrentamos a la gestión de varias comunicaciones simultáneas. Todas estas fases o procedimientos utilizan las herramientas proporcionadas por el nivel de trama, es decir, se fundamentan en el uso de SendPacket y RcvPacket para realizar sus tareas. Al mismo tiempo vemos que existen funciones que son comunes a estos procedimientos, por ejemplo, todas ellas necesitan gestión de temporizadores o requieren el uso de bufferes para cumplir con el diseño de alto nivel que explicaremos más adelante. Comenzamos esta sección detallando el diseño de los temporizadores así como el almacenamiento de los datos de envío y recepción. - Gestión de los temporizadores. Como ya se ha explicado en secciones anteriores, el uso de temporizadores es necesario para realizar un control de errores asegurando fiabilidad. A modo de resumen diremos que un temporizador se activa en el momento que se envía un paquete, si este temporizador expira y no ha llegado el reconocimiento afirmativo se retransmite el paquete. Esta parece una tarea sencilla a simple vista, pero si nos paramos a pensar vemos que el temporizador y la escucha, en espera del reconocimiento son tareas que - 55 -

Sistema de comunicaciones inalámbricas para robots deben funcionar de forma paralela sin ocupar el 100% del procesador, al mismo tiempo vemos que el evento de recepción de un paquete por la red es totalmente asíncrono, por tanto puede ocurrir en cualquier momento. Todo esto nos obliga a pensar en un método que dedique un proceso a cada tarea, de forma que el proceso empleado para la recepción de paquetes por la red quede bloqueado en espera de este evento, y el proceso dedicado al temporizador se inicie al enviar un paquete y finalice al recibir la confirmación de paquete recibido o se de su expiración. Si profundizamos más aun en el comportamiento de nuestro protocolo veremos que necesitamos un nuevo proceso, puesto que, el usuario de nuestra API puede solicitar, también de forma asíncrona, el envío de un paquete. De esta manera, con únicamente dos procesos, uno estará dedicado a los temporizadores y el otro a la escucha por la red, entonces no disponemos de mecanismos para atender la petición de envío del paquete. Por tanto serán como mínimo tres los procesos independientes necesarios en nuestra implementación; proceso encargado de los temporizadores, proceso de escucha y proceso principal o de usuario. Como vemos, de nuevo nos acercamos un poco más al funcionamiento de TCP ya que, la implementación de este protocolo, normalmente, utiliza un proceso independiente para la entrada, otro para la salida y otro para los temporizadores. Para llegar a una solución válida, aunque no tan compleja como la utilizada en TCP, se opta por no implementar procesos independientes sino hilos de ejecución o threads. Esta decisión evita la sobrecarga software que conlleva el cambio de contexto entre procesos así como el esfuerzo necesario para la creación y destrucción de estos procesos. Para lograr una mayor similitud del código desarrollado en QNX y el desarrollado en Windows se ha optado por utilizar el estándar POSIX en los dos casos. El primer diseño referente a la gestión de tiempos seguía la estructura mostrada en la figura 4.7. La idea es la siguiente; para cada paquete que se envía, automáticamente, se crea un nuevo hilo de ejecución (a partir de ahora thread), de forma que empieza la cuenta atrás, si el contador expira y no se ha recibido confirmación del paquete, se retransmitirá el último paquete enviado. Si por el contrario antes de la expiración del temporizador se recibe el reconocimiento válido, desde el thread de lectura se detiene y finaliza el thread correspondiente.

Figura 4.7: Diseño de la gestión de temporizadores

- 56 -

Sistema de comunicaciones inalámbricas para robots

Este diseño tiene, sin embargo, un mal comportamiento desde el punto de vista de implementación, puesto que, los threads, a pesar de ser menos costosos de manejar, crear y destruir que los procesos, suponen un esfuerzo excesivo (sobre todo para la estación móvil), lo que implica que la comunicación no se comporte de la forma esperada. Como solución a este problema se rediseñó la gestión de los temporizadores de forma que no fuese necesaria la creación y eliminación de un thread para cada paquete enviado. Esta solución consiste, por tanto en crear al principio de la comunicación un thread de escucha (igual que en el primer diseño), y otro thread dedicado a los temporizadores que se mantendrá durante toda la comunicación. De esta forma, cuando se envía un paquete se avisa al Alarm thread que inicie la cuenta atrás, en caso de recibir el reconocimiento de paquete esperado se detiene la cuenta atrás y el thread queda de nuevo en espera de la señal para iniciar el temporizador, al igual que en el caso anterior, en caso de expiración de la alarma será este mismo thread el encargado de retransmitir el último paquete. La figura 4.8 nos muestra este diseño definitivo.

Figura 4.8: Diseño de la gestión de temporizadores definitivo

El problema añadido que supone tener varios threads funcionando de forma concurrente sobre el código es el acceso a los recursos compartidos. Supongamos que, justo en el momento en el que el hilo de alarma desea retransmitir el último paquete, se recibe la confirmación correcta, de forma que el hilo principal desee actualizar este buffer que contiene el último paquete enviado. Ésta es sólo una de las múltiples situaciones en las que nos podemos encontrar problemas con el acceso a recursos compartidos. La solución a este problema se comenta en el siguiente punto. - Diseño y gestión de buffers de almacenamiento. La implementación de fiabilidad implica el almacenamiento de datos, como por ejemplo el último paquete enviado. De la misma forma, si analizamos cualquier técnica de control de errores vemos la necesidad de almacenar los datos que se desean transmitir. Más concretamente, en nuestro caso particular, un Stop & Wait implica que no se permita enviar el siguiente paquete hasta recibir el reconocimiento positivo del - 57 -

Sistema de comunicaciones inalámbricas para robots anterior, por tanto nos podemos preguntar ¿Qué ocurre si el usuario desea enviar más datos mientras se está esperando un ACK?. La respuesta a esta pregunta es que estos datos se almacenarán en un buffer en espera de ser transmitidos. Por otra parte ocurre algo similar en la recepción, veamos que ocurre desde el punto de vista de la estación receptora; supongamos que el hilo de escucha recibe un paquete STCP, inmediatamente responde con un asentimiento (ACK) a la parte emisora, y entonces avisa con un evento al usuario del nivel superior de la llegada de un nuevo paquete, pero, ¿Qué ocurre si el usuario no reacciona antes de la llegada del siguiente paquete?. La solución adoptada para este problema no es otra que la utilización de un buffer de almacenamiento de paquetes entrantes. Así cuando el hilo de escucha recibe un paquete envía inmediatamente el reconocimiento, lo almacena en el buffer correspondiente y seguidamente avisa al nivel superior de la llegada de éste paquete. El problema de la utilización de estos buffers (BuffWaitingToSend y BuffRcvd en la implementación del STCP), es que son finitos, es decir, que en la situación en que se llene cualquiera de estos buffers se deberá tomar una decisión sobre que postura a adoptar: descartar el último paquete recibido, eliminar el paquete que lleve más tiempo en cola, etc. La decisión tomada en nuestra implementación es la de no almacenar el último paquete y avisar con un evento al usuario del nivel superior para que él tome una decisión. La implementación de estos buffers se ha realizado de forma que no consuma más recursos de los necesarios (buffers circulares), dejando en manos del usuario de la API la decisión de cual es el máximo número de paquetes que es posible almacenar tanto en la recepción como en el caso de los paquetes pendientes de enviar. Esta cantidad máxima está definida, junto con otras constantes, como el time out máximo, en el archivo llamado config.h. Estos buffers descritos, junto con otras variables que irán surgiendo durante las siguientes secciones, forman la información necesaria para gestionar la comunicación. Muchas de estas estructuras o variables deben ser comunes para los tres threads. Son por tanto los recursos compartidos de los que hablábamos en el punto anterior sobre los que hay que asegurar la exclusión mutua. Para evitar el acceso simultáneo a estos recursos, la implementación hace uso de mutex y de variables condición25 para la sincronización y comunicación entre los hilos. Nos encontramos en situación de introducirnos en las diferentes fases que componen la comunicación, como se ha dicho, estas fases son tres: - Establecimiento de la comunicación - Intercambio de datos entre entidades del mismo nivel - Cierre de la comunicación A continuación describiremos el funcionamiento del protocolo STCP para cada una de las fases. -

Establecimiento de la comunicación

Como se comentó durante la sección 4.2.1. (Diseño general del protocolo), es necesario implementar una fase inicial para acordar un primer número de secuencia para cada una de las estaciones implicadas en la comunicación. El diseño de esta fase se basa en el acuerdo de conexión de tres vías que utiliza TCP, sin embargo, nuestro

25

Gracias a las funciones proporcionadas por el estándar POSIX es posible realizar la sincronización entre las tareas utilizando las mutex y variables condición de la misma forma en el software desarrollado sobre QNX como en el desarrollado sobre Windows

- 58 -

Sistema de comunicaciones inalámbricas para robots protocolo no necesita negociar tantos detalles de la conexión como TCP. Así pues nuestro esquema es una simplificación de este caso. La dificultad de esta fase reside en la sincronización de las dos estaciones relacionadas en la comunicación, es decir, lograr el estado de comunicación establecida pasa por el intercambio de varios paquetes STCP en un orden determinado. Por ejemplo, la figura 4.9 muestra un ejemplo de este intercambio.

Figura 4.9:Fase de establecimiento de comunicación STCP

La casuística se complica si suponemos situaciones en las que, por ejemplo, la estación A no reciba el reconocimiento del SYN enviado por la estación B (el ACK X+1). Entonces, de alguna forma, el procedimiento que realice el intercambio de paquetes STCP iniciales deberá ser capaz de superar éste y otros posibles fallos a fin de que, finalmente, las dos estaciones conozcan el primer número de secuencia que emplea la máquina remota. No profundizaremos en la totalidad de posibilidades que afronta la implementación de nuestro protocolo, para más información consultar el código adjuntado en el CD. Hay que decir que la finalización de forma correcta de esta fase implica la creación de los dos nuevos threads, ListenThread y AlarmThread, es decir, que durante la negociación del establecimiento de comunicación únicamente existe el hilo principal y una vez que se ha aceptado esta comunicación se crean los hilos necesarios para gestionarla y se inicia la fase de intercambio de datos. El diseño de STCP utiliza, para lograr el establecimiento de comunicación, el broadcast, es decir, cualquier máquina que inicie la aplicación, utiliza la función BroadcastBind para colocar al socket de forma que escuche los mensajes procedentes de cualquier IP y al mismo tiempo envía un paquete SYN a la IP de broadcast dentro de la subred a la que pertenece, de esta forma si existe alguna máquina ejecutando el protocolo leerá el paquete SYN y responderá con un reconocimiento. Todos los algoritmos y funciones necesarios para llevar a cabo esta fase se encuentran agrupados, principalmente, en dos funciones, OpenMasterBucle y StcpHandle ambas incluidas en el fichero STCPManagementLevel.c y declaradas en STCPManagementLevel.h Por tanto, para lograr una comunicación utilizando nuestro protocolo STCP es suficiente con iniciar la aplicación en cualquier estación y seguidamente lanzar la aplicación en otra máquina remota. En la implementación también se han tenido en cuenta aspectos como la posibilidad que la segunda máquina no se inicie inmediatamente tras la segunda, de esta forma, se implementa un sistema en el que, agotados n intentos de comunicación, se avisará al usuario del nivel superior de que no existe ninguna aplicación STCP activa en la subred. - 59 -

Sistema de comunicaciones inalámbricas para robots Una vez finalizada esta fase, las dos estaciones utilizan la función ChangeBroadOpt para aceptar únicamente paquetes procedentes de la máquina remota. Esto tiene un fallo importante y es que si un tercer terminal inicia la aplicación STCP mientras las dos primeras están en la fase de establecimiento, las dos máquinas recibirán el SYN de la tercera y esto podría confundir a la aplicación, logrando incluso que no se establezca la comunicación. -

Intercambio de datos entre entidades del mismo nivel.

Una vez finalizada satisfactoriamente la primera fase de establecimiento de comunicación, las dos estaciones están en situación de intercambiar datos. Para ello, las funciones Send y Receive utilizan los números de secuencia y los buffers BuffSended, BuffWaitingToSend y BuffRcvd así como las funciones del nivel inferior SendPacket y RcvPacket. Implementando una técnica de control de errores Stop & Wait. La figura 4.10 nos muestra un ejemplo del proceso de envío de paquetes. La gestión de la comunicación se basa en el uso de los números de secuencia. Así, por ejemplo, cuando sucede un evento de llegada de ACK, se consulta la variable SNExpectedAck para comprobar si el número de secuencia recibido es el esperado. De la misma forma, para gestionar los eventos generados por la llamada a Send o por la llegada de un paquete de datos desde la máquina remota, se guardan en una estructura contenida en el fichero STCPManagementLevel.h variables que contienen números de secuencia útiles para tomar decisiones sobre la comunicación. De nuevo, la figura 4.11 nos muestra un ejemplo de la recepción de paquetes STCP. Este caso es menos complicado que el de envío de datos puesto que no es necesario el uso del Alarm Thread, sin embargo sí existe un caso particular en el que se necesita un temporizador. Como se ve en la figura, si el usuario del nivel superior hace una llamada a la función Receive y en ese momento no existen datos que leer, es decir, el buffer de recepción de datos (BuffRcvd), está vacío, el protocolo quedará bloqueado en espera de la recepción de un nuevo paquete. Sin embargo, no es factible quedar en esa situación indefinidamente, por tanto es necesario el uso de un temporizador, el cual, en caso de expirar, indicará con un evento al usuario del nivel superior que la recepción no ha sido posible.

- 60 -

Sistema de comunicaciones inalámbricas para robots

Figura 4.10: Ejemplo de envío de paquetes STCP

- 61 -

Sistema de comunicaciones inalámbricas para robots

Figura 4.11: Ejemplo de recepción de paquetes STCP

- 62 -

Sistema de comunicaciones inalámbricas para robots -

Cierre de la comunicación

Cuando las estaciones involucradas en la comunicación den por finalizado el intercambio de datos será necesario que cada estación notifique a la estación remota la finalización de esta comunicación. Para ello se utiliza, al igual que se hace en la fase de establecimiento de comunicación, un tipo de paquete dedicado a ello. El paquete tipo FIN indica a la estación que lo recibe, que la estación emisora no desea enviar más paquetes y por tanto que esta última quedará pendiente de la recepción de un FIN para dar como cerrada la transmisión. La figura 4.12 nos muestra un posible escenario de cierre de comunicación.

Figura 4.12:Fase de cierre de comunicación STCP

El envío, por parte de una estación, del paquete tipo FIN no implica que la estación receptora de este FIN deba dejar de enviar paquetes, y por supuesto, la estación emisora no dejará de reconocer los paquetes recibidos. Por otra parte, el envío de un paquete tipo FIN si implica a la estación que lo emite, no poder enviar más paquetes de datos. De todo lo explicado hasta el momento, en cuanto al software de comunicaciones, somos capaces de iniciar, intercambiar datos y cerrar una comunicación STCP. Pero nuestro objetivo final va más allá puesto que se pretende lograr un sistema de comunicación en el que sea posible mantener varias comunicaciones simultáneas en una misma máquina. Ampliar la implementación comentada hasta el momento para añadir esta gestión de múltiples comunicaciones no es excesivamente complejo. Gracias a lo que hemos aprendido sobre hilos de ejecución, exclusión mutua y la interfaz de comunicaciones de los sistemas operativos involucrados en el proyecto, el diseño de esta última parte del proyecto resultó acertado desde un primer momento. La idea es la siguiente; implementar una estructura que contenga los números de secuencia, buffers, etc., independiente para cada conexión y mantener un vector de estructuras de forma que seamos capaces de manejar cada una de las comunicaciones a partir de un índice. La figura 4.13 (a) muestra la estructura de una comunicación STCP de una forma gráfica. La figura 4.13 (b) representa el vector de estructuras de comunicaciones, la variable N es el máximo número de comunicaciones simultáneas que se pueden establecer, esta constante está definida en el fichero config.h de nuestra librería.

- 63 -

Sistema de comunicaciones inalámbricas para robots

(a)-Estructura para las variables de una conexión STCP

(b)-Vector de N estructuras STCP

Figura 4.13: Estructura para las variables de conexión STCP

Una vez que tenemos implementado este vector con las estructuras, deberemos añadir una función que gestione constantemente los posibles intentos de comunicación. Esta función es un bucle infinito que, para cada establecimiento de comunicación, rellena los campos de la estructura, crea los threads (Listen Thread y Alarm Thread), para esta comunicación concreta y vuelve al estado de escucha. De esta forma, cuando el usuario haga una llamada a Send o Receive deberá indicar a que comunicación en particular está llamando mediante el índice al vector de estructuras. Esto es lo que se conoce como un servidor concurrente, puesto que el software es capaz de tratar múltiples peticiones al mismo tiempo. Inicialmente, existe un hilo de escucha en un puerto determinado y para cada comunicación entrante se crean nuevos hilos que gestionarán esta comunicación en particular. La figura 4.14 muestra un gráfico que representa el modelo de un servidor no orientado a la conexión (UDP) y concurrente (puesto que utiliza múltiples hilos para tratar varias comunicaciones al mismo tiempo).

Figura 4.14: Estructura del proceso para múltiples comunicaciones

- 64 -

Sistema de comunicaciones inalámbricas para robots 4.2.2.4. Declaración del protocolo a nivel de interfaz de usuario Esta sección esta dedicada a explicar el uso de la librería STCP, esto significa que en este punto detallaremos las funciones que ofrece la librería de forma que el programador de aplicaciones pueda sacar el máximo partido de su uso. Antes de profundizar en cada una de las funciones declaradas en el fichero STCPLib.h vamos a detallar algunos aspectos importantes del diseño del protocolo que afectan directamente a estas funciones. Existen, dentro del nivel de fiabilidad de la librería, otros procedimientos, a parte de los ya mencionados, que aportan una funcionalidad mayor al uso de la librería. Estos procedimientos están destinados a: - Mantener un fichero de registro para cada comunicación. - La gestión de eventos del protocolo. La idea de crear un fichero de registro para cada comunicación nació con la intención de descubrir los posibles fallos del protocolo durante su desarrollo, pero a medida que se avanzaba en el proyecto, se decidió ofrecer esta funcionalidad extra al usuario. El contenido del fichero es útil para realizar un seguimiento detallado de la comunicación, en él se incluye la fecha y hora en que se inició esta comunicación, se detalla el número de secuencia de cada paquete recibido y enviado, se muestra el contenido de las variables de estado de comunicación en el momento en que se recibe o envía un paquete, etc. La figura 4.15 nos muestra un ejemplo del contenido de este fichero. Registro WINDOWS OS time: OS date: ip local: 192.106.1.100 Master socket 1956 ***Variables de estado de conexión:*** Estado de conexión--------CLOSED SendVars.SNToSend---------0 SendVars.SNExpectedAck---0 SendVars.LastAppSN ---0 RcptVars.SNReceived------0 RcptVars.SNRecognized----0 RcptVars.SNToConsume------- 0 ***************** Número de secuencia inicial SYN local: 49 <<<<<<<SE ENVIA PAQUETE CON: <<
LISTEN|-----Estamos dentro de bucle principal de Open----| ***Variables de estado de conexión:*** Estado de conexión--------LISTEN SendVars.SNToSend---------49 SendVars.SNExpectedAck---50 SendVars.LastAppSN ---49 RcptVars.SNReceived------0 RcptVars.SNRecognized----0 RcptVars.SNToConsume------- 0 *****************

. . .

. .

13:54:49 03/13/04

|----Se han recibido datos ajenos----| ip remota: 192.106.1.5 Siguiente número de secuencia a enviar:50 Hemos recibido tipo de paquete que indica posibilidad de conexion esperamos el tiempo de seguridad: 2 desbloqueo del timesleep: 0 PASAMOS A HANDLER Hemos insertado al cliente que nos ha solicitado conexión Este es su mensaje/nombre inicial: CLIENT2 Paquete tipo SYN con SN:97 Enviamos confirmación del nsec recibido <<<<<<<SE ENVIA PAQUETE CON: <<
. . . esperamos recibir ACK con nsec: 50 y recibimos:ACKcon nsec: 50 desbloqueo del tiempo de seguridad para fin three way handshake estado de conexión: EST

Figura 4.15: Ejemplo de fichero de registro STCP

El nombre del fichero indica a que número de comunicación pertenece (un fichero de registro con nombre log0.txt, y otro con nombre log1.txt pertenecen a las comunicaciones número 0 y 1 respectivamente). Este registro, se sobrescribirá si se cierra la comunicación número 0 y se inicia de nuevo una comunicación con ese índice. Si nos fijamos en el ejemplo de fichero mostrado en la figura, veremos que cuando se establece la comunicación se registra el mensaje o nombre inicial de la estación remota. Este nombre inicial es otra constante definida en el fichero config.h y - 65 -

Sistema de comunicaciones inalámbricas para robots mediante este nombre se pueden diferenciar las múltiples comunicaciones (el mensaje inicial es el contenido del paquete tipo SYN intercambiado en la fase de establecimiento de comunicación y está asociado a un número de comunicación). Además del fichero de registros (log.txt), existe otro fichero que se crea para cada comunicación. Este fichero, times.txt, contiene valores temporales que indican el tiempo transcurrido entre el envío de un paquete cualquiera, (llamada a SendPacket), y la recepción del reconocimiento correspondiente, o en su defecto, la expiración del temporizador. Este archivo es útil para realizar un seguimiento del comportamiento del enlace. En cuanto a la gestión de eventos, ya hemos mencionado, en diversas ocasiones que el usuario de la librería debe ser informado de los eventos internos que sucedan durante el transcurso de la comunicación. La forma en la que la librería informa de los eventos es mediante una estructura de datos, en ella se guarda el tipo de evento del que se está informando, el número de conexión al que pertenece el evento y un mensaje de texto que añade información sobre el evento. Así, por ejemplo, cuando se establece una nueva comunicación, se levanta un evento tipo informativo que contiene como texto la IP de la máquina con la que se ha establecido la comunicación y el mensaje inicial que envía esta máquina. Los tipos de eventos posibles se encuentran enumerados en el fichero STCPEvents.h y se muestran, junto con la definición de la estructura de datos en la figura 4.16. //estructuras y tipos para tratamiento de errores: typedef enum { /*------empezamos con los eventos generados por errores o que pueden generarlos-----*/ NoError, SocketError, //relacionado con el nivel de sockets Winsock2.h ChecksumError, //error de checksum, puede ser un error aislado o un problema de red MutexOrCondVarError, //error relacionado con mutex o variables de condición PthreadError, //error relacionado con la gestión de threads (el mensaje de error puede aclarar en que punto sucedió) ReadBufferOverflow, //memoria destinada a almacenamiento de paquetes de entrada llena SendBufferOverflow, //memoria destinada al almacenamiento de paquetes pendientes de enviar llena TimeOutDone, //saltará este evento cada vez que salte un time out y sea necesario retransmitir //(de esta forma el usuario de la api podrá llevar un control optimo del timeout apropiado) TimeOutReceive, //timeOut bloqueados esperando llegada de un nuevo dato expirado ConnectFailed, //intento de conexión fallida (desconexión repentina del otro extremo,etc.) MaxConnectEst, RetransmisionFailed, //n intentos de retransmitir un paquete fracasados, (desconexión repentina del otro extremo,etc.) /*----------Los siguientes son eventos que suceden durante la comunicación y deberán ser tenidos en cuenta por el usuario de la API----------*/ InformationEvent, ComunicationEstablished, DatagramSended, DatagramReceived, ReceivedDone, CloseDone

//cualquier tipo de evento que se considera relativamente importante para el usuario //nueva comunicación establecida, el mensaje contiene IP y nombre de máquina remota //informa de paquete enviado por la red (no almacenado en buffer) //informa de paquete recibido y almacenado //informa de la extracción de un paquete del buffer de recpción //informa del envío de la finalización de la comunicación(por parte de las dos estaciones)

}EventKind; typedef struct { enum EventKind EvKind; int IDConnect; char *MsgEvent; }TEvent;

Figura 4.16: Contenido del fichero STCPEvents.h

La forma en que se hace llegar esta información al usuario de la librería es mediante la solicitud de una función que trate estos eventos. Esto significa que el usuario de la API deberá crear una función que gestione los eventos y utilizar la función SetEventFunct proporcionada por la librería, pasándole como parámetro un puntero a esta función de usuario, de forma que cada vez que se levante un evento cualquiera durante la comunicación, este evento se gestionará fuera de la librería mediante la

- 66 -

Sistema de comunicaciones inalámbricas para robots función creada por el usuario26. En el siguiente capítulo se mostrarán aplicaciones realizadas sobre el protocolo que demuestran la portabilidad y modularidad del código gracias a esas funciones de gestión de eventos. En cuanto al nivel de usuario, a continuación describiremos, detalladamente, cada una de las funciones que ofrece; - void WINAPI OpenApp(int ConnectNumber) Esta función crea un nuevo thread que quedará en un bucle en espera de recibir peticiones de comunicación. En caso de recibir una petición de inicio de comunicación lanzará el procedimiento de acuerdo de conexión de tres vías y una vez finalizada la fase de establecimiento creará los threads de escucha y de temporizador que tratarán esta comunicación. Durante la fase de establecimiento de comunicación, este procedimiento guardará en una tabla el nombre o mensaje inicial de la máquina remota y lo asociará a un número determinado (índice a la estructura STCP). La función espera como parámetro un entero, este número indica la cantidad máxima de comunicaciones que se desean establecer (no simultáneas), es decir, que si, por ejemplo, se llama a la función pasándole un “1” como parámetro, el bucle finalizará una vez establecida una comunicación. Pasándole un “0” como parámetro, la función entiende que no tiene límite en cuanto a las comunicaciones que debe aceptar, de esta forma el bucle únicamente finalizará con la llamada a CloseApp. - int WINAPI Send(char *ConexName, char *DataToSend) Esta función se ha mencionado en numerosas ocasiones durante la documentación del nivel de fiabilidad y de usuario, haciendo referencia al funcionamiento interno y los procesos implicados. En esta ocasión se documenta la declaración de la función. En primer lugar, la función espera como parámetro el nombre de la máquina remota a la cual se desea enviar los datos. Este nombre se consultará en la tabla comentada en la función anterior y, a partir de ella, se obtiene el índice a la estructura de datos STCP y mediante este índice se obtienen los datos de la comunicación necesarios para hacer llegar la cadena de caracteres pasada como segundo parámetro a la máquina remota. Este segundo parámetro son los datos de usuario. Como respuesta a la llamada a esta función, se devuelve un entero mayor que “0” indicando la cantidad de bytes enviados en caso de funcionamiento correcto, un “-1” en caso de no haber encontrado el nombre de máquina remota en la tabla de conexiones, o un “0” en caso de almacenar el paquete en espera de ser transmitido. - int WINAPI Receive(char *ConexName,char *DataToRead) La llamada a esta función implica consultar el buffer de almacenamiento de datos recibidos como se mostró en la figura 4.11 (Ejemplo de recepción de paquetes STCP). Los parámetros que acepta son similares a la función anterior; el primero de ellos es el nombre de la máquina remota y el segundo es una cadena de caracteres dónde se almacenarán los datos leídos. El entero que devuelve esta función puede tomar los mismos valores que en la función Send, valiendo “0” en caso de no existir datos que leer y expirar el tiempo en

26

Así por ejemplo, el usuario podría decidir utilizar la librería en una aplicación de entorno consola y mostrar los mensajes por pantalla haciendo un simple printf para imprimir el mensaje del evento por pantalla, o podría, en cambio, decidir trabajar con un entorno visual en el que se sustituya el printf por un AfxMessageBox. De la misma forma podría decidir la acción a realizar para cada tipo de evento; ignorar los eventos de información, cerrar y volver a iniciar comunicación en caso de fallo de conexión, etc.

- 67 -

Sistema de comunicaciones inalámbricas para robots espera de la llegada de nuevos datos, “-1” en caso de no haber encontrado el nombre de máquina remota en la tabla de conexiones, o la cantidad de bytes leídos en otro caso. - void WINAPI Close(char *ConexName) En cuanto a la finalización de las comunicaciones existen varias posibilidades de cierre, esta primera función enviará un paquete tipo FIN a la máquina remota cuyo nombre se pasa como parámetro. El comportamiento de la conexión sigue la idea mostrada en la figura 4.12 (Fase de cierre de comunicación STCP). - void WINAPI CloseApp(CloseParamType Param) Esta otra función no afecta a una comunicación concreta. Acepta un parámetro en función del cual realiza una de estas dos tareas: o Si el parámetro es NoMoreConnect, la llamada a esta función hará que no se acepten nuevas conexiones entrantes. o Si el parámetro es CloseAllApp, la función realiza un recorrido por la tabla de conexiones cerrando, mediante el uso de la función Close, todas las comunicaciones activas en ese momento. - void WINAPI SetEventFunct (void *EventFunct) Esta última función declarada en el fichero STCPLib.h ya ha sido comentada anteriormente para explicar la gestión de eventos. La única tarea de la función es asignar la función pasada por parámetro como la función a la cual se llamará cada vez que se levante un evento STCP. La figura 4.17 Muestra un ejemplo de asignación de esta función. void main (int argc, char *argv[]) { . .

SetEventFunct( (void *) HandleEvent); . .

} void HandleEvent (TEvent event) { . .

switch (event.ErrKind) { case (ReadBufferOverflow): . .

case (MaxConnectEst): . .

case (InformationEvent): . .

} }

Figura 4.17: Ejemplo de declaración de la función para gestión de eventos

- 68 -

Sistema de comunicaciones inalámbricas para robots

4.3. APLICACIONES DE EJEMPLO En esta sección veremos diversas aplicaciones programadas sobre la librería STCP, estas aplicaciones han sido desarrolladas para mostrar el uso y funcionalidad de la librería así como para ofrecer ejemplos de posibles desarrollos futuros. El código de estas aplicaciones se encuentra en las carpetas de los proyectos correspondientes en el CD que se añade. No comentaremos el código o los detalles de la implementación, simplemente se documenta el diseño de la aplicación poniendo de manifiesto la utilización de las funciones declaradas en STCPLib.h. Se han desarrollado dos aplicaciones diferentes; aplicación de transferencia de ficheros mediante STCP y aplicación para múltiples comunicaciones simultáneas STCP

4.3.1.

Aplicación de transferencia de ficheros

Al principio de la documentación se definieron tres tipos de datos posibles a transferir y a lo largo de la documentación se ha hablado únicamente de datos de usuario. Sin embargo, sigue siendo objetivo del proyecto lograr la transferencia de ficheros, imágenes y comandos entre estaciones. Hasta el momento se ha documentado el diseño e implementación de una aplicación que es capaz de transmitir datos entre terminales, sin profundizar en el tipo de datos o la estructura y contenido de estos datos puesto que estos, son propiedad del usuario de nivel superior. El motivo de esto es que los datos de usuario son transparentes para el nivel STCP. Esto implica que no se diferencie entre imágenes, caracteres alfanuméricos, números, etc. Ahora bien, la transferencia de ficheros requiere algunas consideraciones especiales como el tamaño de los datos que contiene el fichero o el nombre con el que se debe guardar este fichero en la máquina receptora. Por tanto para transferir ficheros de una estación a otra será necesario indicar, inicialmente, el nombre del fichero y dividir los datos de forma que quepan en paquetes STCP durante la transmisión. La aplicación desarrollada realiza básicamente esta tarea. La idea es la siguiente; cuando un usuario desea transferir un fichero a una máquina con la que tiene establecida una comunicación STCP, creará un paquete de datos, siguiendo un “formato especial”, en el que se incluya el nombre del fichero y su longitud en bytes. Enviará este paquete STCP y seguidamente introducirá el contenido del fichero en tantos paquetes de datos STCP como sean necesarios (esto es conocido como segmentación), y enviará estos paquetes. En recepción, se almacenarán todos los paquetes enviados por la máquina emisora en espera de ser leídos. Cuando se llame a la función Receive, se leerá el primer paquete y se comprobará su formato, si el formato coincide con el formato de envío de fichero se entiende que los siguientes paquetes contienen datos del fichero en cuestión, por tanto, del primer paquete se extrae el nombre del fichero y su longitud y se crea un nuevo fichero con ese nombre. A continuación se realizarán tantas llamadas a Receive como sean necesarias para recibir la misma cantidad de bytes que se indicó con el primer paquete, al mismo tiempo que se van introduciendo los datos en el fichero creado. La figura 4.18 muestra un ejemplo de transferencia de fichero. El proceso que comprueba si la cantidad de datos introducida en el fichero es mayor o menor que el tamaño indicado en el primer paquete es posible grácias a que la función Receive devuelve como valor la longitud de datos del paquete.

- 69 -

Sistema de comunicaciones inalámbricas para robots

Figura 4.18: Ejemplo de transferencia de fichero.

Este diseño presenta una limitación importante en cuanto al tamaño del fichero. Esta limitación viene dada puesto que, en un momento determinado, los paquetes que contienen datos del fichero se almacenan en el buffer de recepción de la estación remota. Si la cantidad de paquetes que es capaz de almacenar el buffer es menor al número de paquetes que requiere la transferencia del fichero, este buffer se desbordará. Así, por ejemplo, con las constantes fijadas en la actual implementación (Tamaño máximo de paquete: 512 bytes y número máximo de paquetes pendientes de ser leídos: 10), podríamos transferir un fichero de no más de 5120 bytes.

4.3.2. Aplicación para múltiples comunicaciones simultáneas Esta aplicación nació con la idea de comprobar el buen funcionamiento de STCP manteniendo múltiples comunicaciones. La versión gráfica a la que haremos referencia durante esta sección fue precedida por varias versiones en modo texto (aplicación de consola), que dificultaban enormemente la labor de comprobación. Hay que aclarar que esta aplicación se desarrolla para trabajar, únicamente, sobre la estación base, es decir, está implementada para el sistema operativo Windows. Esto es así por varias razones; la primera es que, inicialmente, no se desea que las estaciones móviles se comuniquen entre ellas puesto que es más difícil mantener el control de estas comunicaciones, y la segunda es porque las estaciones móviles no trabajarán con entorno gráfico, y por tanto sería sumamente difícil realizar pruebas de varias comunicaciones en modo consola. Como decimos, nació con la idea de comprobar el buen funcionamiento del protocolo, pero poco a poco, se ha convertido en una aplicación que contiene toda la funcionalidad ofrecida por la librería, incluida la aplicación de transferencia de fichero. Y por tanto es una buena oportunidad para documentar el uso de la librería. Es por ello que en el CD adjunto este es el único proyecto de C incluido, a parte de la propia librería STCP27 . La figura 4.19 nos muestra la interfaz gráfica de una comunicación STCP. Para iniciar una comunicación, como ya se mencionó, únicamente es necesario arrancar la aplicación en la máquina local, en este caso STCPGui.exe, y ejecutar la aplicación correspondiente en la máquina remota, se trata de la aplicación stcp.x en QNX28. Cuando finaliza la fase de establecimiento de comunicación, se 27

Los proyectos de visual C++ incluidos en el CD son; STCPLib y STCPGui, siendo el primero la librería STCP y el segundo el proyecto de la aplicación que se documenta en este apartado 28 Ambas se encuentran en la carpeta aplicaciones del CD adjuntado. Carpetas Windows y QNX para cada aplicación correspondiente.

- 70 -

Sistema de comunicaciones inalámbricas para robots muestra por pantalla un mensaje de Windows indicando este evento (gracias a la función de eventos declarada con SetEventFunct), y una vez cerrado este mensaje, aparece la ventana de la figura 4.19

Figura 4.19: Ventana para la gestión de una comunicación STCP.

Comenzaremos documentando cada uno de los elementos de la ventana comunes a todas las ventanas de comunicaciones: - Un área de información de la máquina remota, en esta área se muestra la dirección IP de la máquina remota y el nombre o mensaje inicial con el que se identifica esta comunicación. - Un área de información sobre los eventos, arriba, a la derecha de la ventana se muestra un campo que indica el último tipo de evento sucedido en la comunicación y el texto de ese evento, campo Tipo de evento y Descripción respectivamente. - Un área de transmisión, marcado con el título enviar, se diferencian dos zonas, la primera dedicada a la transmisión de mensajes (paquetes de datos de usuario), y la segunda dedicada a la transferencia de ficheros. - Un área de recepción, esta zona muestra información sobre los paquetes recibidos, en primer lugar se muestra un campo de texto en el que se visualizará el contenido del mensaje recibido cuando se pulse en el botón correspondiente. En segundo lugar, un campo numérico marcado como Mensajes pendientes, indica la cantidad de paquetes STCP que se encuentran en el buffer de recepción pendientes de ser leídos. Esto es posible mediante un contador que aumenta o disminuye una unidad para cada evento tipo DatagramReceived y DatagramSended respectivamente. - 71 -

Sistema de comunicaciones inalámbricas para robots -

Un botón de cierre de conexión, que en este caso llama a la función Close pasándole como parámetro el nombre de la comunicación asociada a esta ventana.

El entorno gráfico realiza un papel de intermediario entre el usuario y la librería. Esto se puede aprovechar para realizar un primer control antes de llamar a las funciones de la librería, así por ejemplo, la figura 4.20 nos muestra un mensaje de aviso que se levanta en caso de no rellenar los campos de transmisión antes de llamar a alguna de las funciones.

Figura 4.20: Ejemplo de comprobación del entorno gráfico.

Siguiendo con el área de transmisión, la zona dedicada a la transmisión de mensajes, tras comprobar que el contenido del campo es mayor que “0” y menor que “512” (longitud máxima de datos STCP), al pulsar el botón Enviar Mensaje, obtiene el contenido del campo de texto, y lo envía a la estación remota mediante la función Send. En caso de no recibir reconocimiento del paquete se dará un evento TimeOutDone y la aplicación gráfica tratará este evento manteniendo un contador, si este evento sucede un número determinado de veces, se avisará al usuario de este hecho. La función que se llama al pulsar el botón EnviarFichero, igual que en el caso de enviar mensaje, obtiene el contenido del campo de texto asociado y lo entiende como nombre del fichero, realizando los procedimientos explicados en la sección 4.3.1.(Aplicación de transferencia de ficheros). La única novedad es el botón Examinar, que hace posible seleccionar un fichero que se encuentre situado en una carpeta diferente a la carpeta en la que se está ejecutando la aplicación. Figura 4.21.

- 72 -

Sistema de comunicaciones inalámbricas para robots

Figura 4.21: función del botón Examinar

Por último, cabe mencionar otro detalle de la interfaz gráfica, y es que, como se explicó, la función Receive, en caso de no tener datos que leer en el buffer de recepción, queda bloqueada en espera de recibir nuevos datos durante un determinado tiempo. Pues bien, el entorno gráfico pone de manifiesto este bloqueo del hilo de escucha dejando el botón Recibir mensaje deshabilitado en esta situación concreta y avisando mediante un mensaje en el caso de expirar este temporizador. Figura 4.22.

Figura 4.22: Bloqueo en espera de recibir mensaje nuevo

- 73 -

Sistema de comunicaciones inalámbricas para robots En cuanto a la gestión de múltiples comunicaciones, el procedimiento es idéntico para cada una de ellas. Una vez que la aplicación está en marcha, si se solicitan nuevas comunicaciones desde estaciones remotas, la aplicación creará para cada una de ellas una ventana igual a la descrita hasta el momento mientras no se llegue al máximo número de comunicaciones permitidas. La figura 4.23 nos muestra un ejemplo en el que permanecen activas dos comunicaciones.

Figura 4.23: Ejemplo de dos comunicaciones activas.

- 74 -

Sistema de comunicaciones inalámbricas para robots

5. CONCLUSIONES Y TRABAJO FUTURO El presente proyecto ha sido desarrollado con el fin de lograr un sistema completo para la comunicación entre una estación base y la futura flota de robots. Esto se ha logrado de una forma general, gracias a la instalación y configuración de hardware inalámbrico, así como el desarrollo del software que funcionará sobre este hardware. La principal dificultad del proyecto recae en el desarrollo del software de comunicación, ya que, a pesar de intentar realizar un software lo más sencillo posible, las características del entorno nos obligan a complicar los procesos encargados de aportar la fiabilidad requerida en las comunicaciones. En cuanto a las posibles mejoras cabe destacar dos frentes de actuación: - En primer lugar el código de la librería ofrecida como solución software puede ser mejorable. Los principales aspectos en los que podría ser mejorable este código serían en la fase de establecimiento de comunicación, evitando el problema que surge al iniciar varias aplicaciones STCP al mismo tiempo así como la reducción del tiempo necesario para establecer una comunicación. - Y como segundo punto hay que decir, que existen algoritmos, dentro de este software, que pueden ser sustituidos por otros más complejos para obtener un mejor rendimiento del enlace de comunicaciones. Por ejemplo, el hecho de sustituir los procesos encargados de la gestión de los temporizadores, por otros procesos que implementen algoritmos adaptativos como los comentados durante la documentación. Dentro de las líneas de trabajo futuro, podemos decir, que la utilización del protocolo STCP implementado implica desarrollar nuevas aplicaciones de usuario que aprovechen la funcionalidad ofrecida por el protocolo. En este sentido, existen numerosas aplicaciones útiles para la comunicación entre robots, como por ejemplo el tratamiento de imágenes y la transferencia de éstas mediante el software desarrollado. Otra aplicación que podría ser de gran utilidad es el uso del protocolo STCP como un enlace de comunicación entre robots a través de la estación base, es decir, igual que se documentó en la aplicación de transferencia de ficheros, crear un formato en el que se indique a la estación base hacia quien van destinados los datos, haciendo la estación base, de esta forma de puente entre dos estaciones móviles tal como muestra la figura 5.1.

Figura 5.1: Aplicación enlace de comunicaciones.

- 75 -

Sistema de comunicaciones inalámbricas para robots

6. REFERENCIAS BIBLIOGRÁFICAS 6.1. ENLACES DE INTERNET CONSULTADOS Para todos los enlaces mencionados, última fecha de consulta: 12/04/2004.

1. “Análisis de Protocolos de Transporte en Redes Hibridas” Alberto Lluch Lafuente (Instituto de Informática, Universidad del País Vasco) http://www.informatik.uni-freiburg.de/~lafuente/papers/articulos.html 2. “Práctica de redes I. Curso 2000/2001” (Grupo de Sistemas y Comunicaciones, Universidad Rey Juan Carlos) http://gsyc.escet.urjc.es/docencia/asignaturas/redes-I/practicas-01-02/ 3. “ACM Crossroads Student Magazine: Can TCP be the transport protocolo of the 21st centuty?” Kostas Pentikousis http://www.acm.org/crossroads/espanol/xrds7-2/tcp21.html 4. “A comparison fo Mechanisms for Improving TCP Performance over Wireless Links” Kostas Pentikousis http://citeseer.ist.psu.edu/pentikousis00survey.html 5. “Ingeniería de protocolos de comunicaciones” Luis Mengual Galán (Facultad de Informática, UPM) http://pegaso.ls.fi.upm.es/~lmengual/inicio_IP.html 6. “Windows Sockets” http://world.std.com/~jimf/papers/sockets/winsock.html 7. “Getting Started with POSIX threads” Tom Wagner, Don Towsley (Department of Computer Science, University of Massachusetts at Amherst) http://dis.cs.umass.edu/~wagner/threads_html/tutorial.html

6.2. LIBROS Y REVISTAS TÉCNICAS CONSULTADOS 1. “Comunicaciones y redes de computadores”. William Stallings Ed. PRENTICE HALL 2. “Interconectividad de redes con TCP/IP. Volumen II. Diseño e implementación”. Douglas E. Comer y David L. Stevens. Ed. PRENTICE HALL

3. “Notas académicas de ingeniería y aplicaciones telemáticas”. Joseph Lluís Ferrer Gomila y Magdalena Payeras Capellá. - 76 -

Sistema de comunicaciones inalámbricas para robots (DMI, Universitat de les Illes Balears). 4. “Optimizing Internet Flows over IEEE 802.11b Wireless Local Area Networks: A Performance Enhancing Proxy Based on Forward Error Correction”. M. García, R. Agüero, L. Muñoz, P. Mähönen. IEEE Communications Magazine, Diciembre 2001, Vol. 39, Nº 12 pp.60-67 5. “Behavior of UDP-Based Applications over IEEE 802.11 Wireless Networks”. M. García, R. Agüero, L. Muñoz, P. Mähönen. 12th IEEE International Symposium on Personal Indoor and Mobile Radio Communication, PIMIRC 2001, Octubre 2001. Vol. 2, pp. 72-77 6. “Sistema de comunicaciones internas para un robot”. Alberto Rodríguez García. 7. “Getting started with QNX Neutrino 2. A guide for Realtime Programmers”. Rob Krten. Ed. PARSE. 8. “Visual C++ 6.0. Manual de referencia”. Chris H. Pappas y William H. Murray, III.

Ed. McGraw-Hill

9. “Introducción a la programación en C”. Iñaki Goirizelaia Ordorika. (Departamento de Electrónica y Telecomunicaciones Universidad del País Vasco)

- 77 -