Comunicacion Inalambrica para Robots

Sistema de comunicaciones inalámbricas para robots
ÍNDICE DE CONTENIDOS
1. INTRODUCCIÓN..................................................................................................................... 4
1.1. PRESENTACIÓN ............................................................................................................ 4
1.2. ESTRUCTURA DEL PROYECTO ..................................................................................... 6
2. 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
3. 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
4. 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
5. CONCLUSIONES Y TRABAJO FUTURO .................................................................................. 75
6. REFERENCIAS BIBLIOGRÁFICAS ........................................................................................ 76
6.1. ENLACES DE INTERNET CONSULTADOS .................................................................... 76
6.2. LIBROS Y REVISTAS TÉCNICAS CONSULTADOS .......................................................... 76
-1-
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-
TABLAS
TABLA 2.1.: COMPARACIÓN TASA DE ERROR POR BIT. ............................................................... 24

TABLA 2.2.: DIFERENTES PROPUESTAS PARA LA ARQUITECTURA DE RED CABLEADA-
INALÁ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-
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-
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-
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-
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-
- 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-
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-
- 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.
2.1.3. 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 -
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 -
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 -
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 -
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 -
- 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.
(a) (b)
Figura 2.3: Modelo para la transmisión de tramas
- 15 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 BER

Medios cableados
Cable de cobre 10-6 a 10 -7
Fibra óptica 10-12 a 10 -14
Medios inalámbricos
Aire sin FEC 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 -
Aplicación Anfitriones desean acceso a servicios

como WWW, e-mail, FTP, mensajes,etc.
Transporte TCP, variantes, UDP, protocolos
experimentales
Red Todos los anfitriones deben soportar IP
(IPv6 e IP movile)
Enlace de red TCP- no alerta, TCP alerta (Snoop)5
Física 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 -
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 -
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 -
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 -
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 Payload Canal sin Canal con

(Mbps) (bytes) errores errores Rb Test Throughput
Throughput Throughput (Mbps) (Mbps)
(Mbps) (Mbps) 1 2,906
1500 6,071 1,259 2 0,707
1024 5,001 1,2 11 3 4,488
11 768 4,206 1,293 4 0,501
512 3,172 1,548 5 4,586
256 1,763 0,999
(a)-Throughputs obtenidos para diferentes (b)-Throughput obtenido en cinco

tamaños de datagrama y condiciones de canal pruebas sobre un canal ruidoso
utilizando UDP. 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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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
- 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 -
- 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 Pérdida en dB/100m

RG-216 136
RG-58 81
LMR-200 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 -
- 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 -
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 -
- 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 Configuración del control de acceso por

WEP MAC
Figura 3.11: Configuración de la seguridad en la red WLAN
- 41 -
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 -
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 [global]
hostname localhost
devp-pccard
domain Wlabelec
sleep 1 nameserver 130.206.33.1
io-net -d orinoco station=Cabrit, route 192.168.64.1 0.0.0.0 0.0.0.0
key1=0x6c61XXX, default_key=1.
-p tcpip [en0]
sleep 2 type ethernet
netmanager -f /etc/wirelessnet.cfg mode manual
manual_ip 192.168.64.23
manual_netmask 255.255.255.0
(a) /etc/rc.d/rc.local (b) /etc/wirelessnet.cfg
Figura 3.13: ficheros de configuración de la interfaz inalámbrica sobre QNX
- 43 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 CÓDIGO
DATA 1
ACK 2
SYN 3
FIN 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 -
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 -
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 4.6) nos muestra,
conceptualmente, la funcionalidad de este nivel de tramas:
Funcionamiento del procedimiento Funcionamiento del procedimiento

SendPacket 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 -
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 -
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 -
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 -
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 -
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 -
Figura 4.10: Ejemplo de envío de paquetes STCP

- 61 -
Figura 4.11: Ejemplo de recepción de paquetes STCP

- 62 -
- 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 -
(a)-Estructura para las variables de (b)-Vector de N estructuras STCP

una conexión 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 -
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: 13:54:49 .
OS date: 03/13/04 .
ip local: 192.106.1.100 |----Se han recibido datos ajenos----|
Master socket 1956 ip remota: 192.106.1.5
***Variables de estado de conexión:*** Siguiente número de secuencia a enviar:50
Estado de conexión--------- CLOSED Hemos recibido tipo de paquete que indica posibilidad de conexion
SendVars.SNToSend---------- 0 esperamos el tiempo de seguridad: 2
SendVars.SNExpectedAck---- 0 desbloqueo del timesleep: 0
SendVars.LastAppSN ---- 0
RcptVars.SNReceived------- 0 PASAMOS A HANDLER
RcptVars.SNRecognized----- 0 Hemos insertado al cliente que nos ha solicitado conexión
RcptVars.SNToConsume------- 0 Este es su mensaje/nombre inicial: CLIENT2
***************** Paquete tipo SYN
Número de secuencia inicial SYN local: 49 con SN:97
<<<<<<<SE ENVIA PAQUETE CON: Enviamos confirmación del nsec recibido
<<<Campo tipo--------------------SYN <<<<<<<SE ENVIA PAQUETE CON:
<<<Número de secuencia enviado:--- 49 <<<Campo tipo--------------------ACK
<<<Número de secuencia enviado:--- 98
LISTEN|-----Estamos dentro de bucle principal de Open----|
Enviamos nuestro SYN local
***Variables de estado de conexión:*** <<<<<<<SE ENVIA PAQUETE CON:
Estado de conexión--------- LISTEN <<<Campo tipo--------------------SYN
SendVars.SNToSend---------- 49 <<<Número de secuencia enviado:--- 49
SendVars.SNExpectedAck---- 50
SendVars.LastAppSN ---- 49 .
RcptVars.SNReceived------- 0 .
RcptVars.SNRecognized----- 0
RcptVars.SNToConsume------- 0 .
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 -
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, //cualquier tipo de evento que se considera relativamente importante para el usuario
ComunicationEstablished, //nueva comunicación establecida, el mensaje contiene IP y nombre de máquina remota
DatagramSended, //informa de paquete enviado por la red (no almacenado en buffer)
DatagramReceived, //informa de paquete recibido y almacenado
ReceivedDone, //informa de la extracción de un paquete del buffer de recpción
CloseDone //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 -
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 -
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 -
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 -
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 -
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 -
- 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 -
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 -
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 -
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 -
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 -
(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 -

Comunicacion Inalambrica para Robots

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Comunicacion Inalambrica para Robots

Загружено:

Авторское право:

Доступные форматы

Sistema de comunicaciones inalámbricas para robots

FIGURA 1.1: CABRIT ................................................................................................................... 4

TABLA 2.1.: COMPARACIÓN TASA DE ERROR POR BIT. ............................................................... 24

Figura 1.1: CABRIT

Siguiendo las líneas de investigación del grupo surge la necesidad de

Figura 1.2: Esquema del proyecto

Concretando el objetivo de este proyecto, podemos decir que consiste en

Para acabar con la introducción es importante mencionar que el hecho de

1.2. ESTRUCTURA DEL PROYECTO

Segunda parte: Sistema prototipo

Tercera parte: Software de comunicaciones.

2. ESTUDIO TEÓRICO-PRÁCTICO SOBRE LAS

2.1. CONSIDERACIONES SOBRE ENTORNOS DE RED INALÁMBRICOS

2.1.1. Características propias del medio inalámbrico.

2.1.2. Alternativas de infraestructura

- GPRS (General Packet Radio Service) es un servicio que permite el

- Bluetooth es una tecnología diseñada para permitir conectividad

o Es capaz de establecer y mantener más de 6 conexiones

- 802.11a utilizando la banda de frecuencia de 5GHz se diseñó para la

además es necesario un mayor número de células para cubrir la

- 802.11b es el estándar más extendido y barato (entre 802.11a, 802.11b y

- 802.11g nace por una necesidad de compatibilidad con 802.11b, por

2.1.3. Aspectos prácticos de una WLAN

- Topologías de redes WLAN. Las topologías existentes son;

o ESS (Extended Service Set). Conjunto de dos o más BSS que

El funcionamiento y rendimiento de cualquier red inalámbrica viene

Es posible calcular el nivel de recepción de señal en función de todos los

Nrs= Pt a -Pcoa-Pca a + Ga a –Pp + Ga b - Pca b - Pco b

2.2. ANÁLISIS DE PROTOCOLOS DE TRANSPORTE EN REDES

2.2.1. Aspectos teóricos

2.2.1.1. Arquitectura de protocolos TCP/IP

El siguiente paso en la capa de transporte es pasar cada una de las PDU’s a

Figura 2.1: Funcionamiento de una arquitectura de protocolos simplificada

Nótese que la cabecera de transporte no es “visible” al nivel de acceso a la

Figura 2.2: Modelo de arquitectura de protocolos TCP/IP

A continuación pasaremos a resumir muy brevemente cada una de estas

- En situaciones en las que los dos dispositivos que se desean comunicar

2.2.1.2. Control de flujo

2.2.1.2.1. Control de flujo mediante parada y espera

2.2.1.2.2. Control de flujo de 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

Figura 2.5:Ejemplo de protocolo de ventana deslizante

De forma similar al mensaje RR, la mayoría de los protocolos permiten que

2.2.1.3. Control de errores

Las técnicas más utilizadas para el control de errores se basan en alguna de

2.2.1.3.1. ARQ con parada y espera

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

La ventaja principal de ARQ Stop & Wait es su sencillez y como

2.2.1.3.2. ARQ con adelante atrás N

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

Como vemos, el protocolo es bastante más complejo, por ejemplo, el caso

2.2.1.3.3. ARQ con rechazo selectivo

retransmisiones. Por otra parte, el receptor deberá reservar zona de memoria lo

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

2.2.1.4. El nivel de transporte

2.2.1.4.1. El nivel TCP (Transmisión Control Protocol)

o pueden incorporar mecanismos propios de fiabilidad en estas aplicaciones. Los

Figura 2.9: Formato de cabecera TCP

El objetivo de TCP es ofrecer conexiones fiables, para lograr esto sobre un

2.2.1.4.2. UDP (User Datagram Protocol)

remoto. Únicamente coloca el datagrama sobre la red. No realiza fragmentación ni