Caracterización de dispositivos Wi-Fi comerciales para su aplicación en comunicaciones entre UAVs y dispositivos de tierra

i Proyecto Fin de Grado GITT Intensificación en Sistemas Electrónicos Caracterización de dispositivos Wi-Fi comerciales para su aplicación en comunicaciones entre UAVs y dispositivos de tierra Autor: Carlos Beltrán Hortelano Sancho Tutor: Daniel Gutiérrez Reina Dept. de Ingeniría Electrónica Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2017 ii Proyecto Fin de Grado GITT Intensificación en Sistemas Electrónicos Caracterización de dispositivos Wi-Fi comerciales para su aplicación en comunicaciones entre UAVs y dispositivos de tierra Autor: Carlos Beltrán Hortelano Sancho Tutor: Daniel Gutiérrez Reina Doctor Ingenierio en Electrónica Dept. de Ingeniería Electrónica Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2017 iv Trabajo Fin de Grado: Caracterización de dispositivos Wi-Fi comerciales para su aplicación en comunicaciones entre UAVs y dispositivos de tierra Autor: Carlos Beltrán Hortelano Sancho Tutor: Daniel Gutiérrez Reina El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2017 El Secretario del Tribunal v A todos los que lo hicieron posible vii Agradecimientos Adaptando uno de los refranes más populares en lengua castellana, escribió Ángel de Saavedra, duque de Rivas: Porque el ser agradecido la mayor obligación es para el hombre bien nacido Las escuetas líneas que siguen no son más que un intento de acreditar dicha condición. Es obligado que la primera mención vaya dirigida al tutor de este proyecto, Daniel Gutiérrez. Desde el día de octubre de 2016 en el que le mostré mi interés por este trabajo su disponibilidad, atención y diligencia han estado siempre presentes. Gracias a su planificación, acatada por quien escribe estas líneas, este proyecto se ha realizado con paciencia y constancia. Sus consejos e indicaciones han resultado indispensables. La colaboración de Sergio Vigorra fue inestimable. Su Trabajo de Fin de Máster fue el germen de este, y no sólo eso: el dron que él fabricó fue el que se utilizó para realizar las pruebas de comunicaciones en vuelo. A él debo agradecerle su tiempo, proactividad durante la fase de obtención de resultados, interés y algunos comentarios que a él pasaron desapercibidos cuando los pronunció y que a mí, sin embargo, me ayudaron a mejorar este trabajo. En lo que corresponde a la redacción de este proyecto, Salvador Núñez ofreció sugerencias de estilo y emprendió una minuciosa búsqueda de erratas, propia de sabuesos. Toda la responsabilidad por las que permanezcan recae sobre mí. Por último, este es el fruto de los conocimientos y las buenas prácticas adquiridos gracias a la labor de decenas de profesores durante estos años en la Escuela. Dirijo mi sincero agradecimiento hacia todos ellos. Todas las personas referidas han sido, de manera puntual o persistente, acompañantes en un camino no exento de obstáculos y del que este proyecto no es más que una marca. Se trata por tanto de un camino que no termina aquí pues, como dijo otro poeta español, se hace al andar. Y sigo andando. Carlos Beltrán Hortelano Sancho Sevilla – Cádiz – Sevilla, septiembre de 2017 ix Resumen Los vehículos aéreos no tripulados (popularmente conocidos como drones) constituyen en la actualidad una tecnología emergente y con aplicaciones en múltiples campos. Este trabajo pretende construir un sistema de comunicaciones inalámbrico basado en el estándar Wi-Fi entre dos Raspberry Pi para su uso en estos dispositivos y medir su calidad. Antes de conseguir este objetivo será necesario cumplir varios hitos:  Preparar las Raspberry Pi para que se adapten a las exigencias del sistema de comunicaciones.  Considerar las opciones disponibles en el mercado para conseguir la comunicación inalámbrica.  Determinar qué características de las comunicaciones quieren medirse y aplicar las herramientas necesarias para ello.  Diseñar unos programas que consigan obtener, de las herramientas mencionadas en el punto anterior, los parámetros para definir la calidad de las comunicaciones. Una vez procesados los parámetros de calidad de las comunicaciones se podrá reflexionar acerca de las posibilidades de un sistema de comunicaciones inalámbrico basado en Raspberry Pi, y proponer aquellas aplicaciones que, de acuerdo con los datos obtenidos y los recursos manejados, resultaran más provechosas para su uso en UAVs. 16 2 INTRODUCCIÓN: WI-FI PARA COMUNICACIONES ENTRE UAVS Y DISPOSITIVOS DE TIERRA If we all worked on the assumption that what is accepted as true is really true, there would be little hope of advance. - Orville Wright, padre de la aviación – l presente proyecto consiste en el despliegue de una red inalámbrica ad-hoc y la medición de la calidad de comunicaciones con base en criterios estandarizados. Para ello se contará con dos Raspberry Pi 3 Model B ®. Las configuraciones de redes a probar se describirán de forma prolija en sucesivas páginas, pero a grandes rasgos consistirán en dos Rasberry Pi enviándose mensajes en un entorno estático y, posteriormente, en una de ellas dispuesta sobre un vehículo aéreo no tripulado (UAV, por sus siglas en inglés) y la restante en una estación de tierra. Los sistemas transmisor y receptor los constituirán dos con la imagen Jessie del sistema operativo Raspbian ® corriendo en ellas. Insertas en puertos USB de cada una de las Raspberry Pi se encuentra un módulo Wi-Fi para conseguir la conectividad entre ambas a partir de distintas configuraciones que serán programadas para tabular sus parámetros de servicio, si bien se prescindirá de estos dispositivos cuando se mida la calidad de la interfaz Wi-Fi interna con la que cuenta el modelo 3B. Para monitorizar las comunicaciones Wi-Fi y evaluar su calidad, en la estación de tierra se contará con el analizador de protocolos Wireshark ®, que habrá sido previamente instalado en la imagen de Raspbian ®. Será imprescindible considerar aspectos cruciales en la comunicación, tales como las limitaciones que ofrece el estándar 802.11 con nodos desplazándose tridimensionalmente y, además, en espacios abiertos donde pueden verse expuestos a una cantidad inconmensurable de otras señales radioeléctricas (ruido), además de obstáculos físicos. 2.1 Antecedentes de los vehículos aéreos no tripulados l igual que muchos descubrimientos e invenciones realizados a lo largo de la historia, la primera motivación de los vehículos no tripulados fue militar. Sus orígenes se remontan a los primeros tiempos de nuestra era, mucho antes del primer vuelo a motor en 1903 con uno de los hermanos Wright a los mandos. En el siglo III d.C. el estratega chino Zhuge Liang ideó unos globos de papel que en su interior contenían una llama que, al mismo tiempo que calentaban el aire y propiciaban que el globo se alzase, suponían una amenaza contra los enemigos que, al ver llamas de fuego de origen ignoto suspendidas en el aire, las consideraban una amenaza divina. Muchos años después, en 1848, los conocimientos científicos disiparon de forma considerable esos miedos atávicos, pero los sistemas para amedrentar a los pueblos hostiles se mantuvieron básicamente imperturbables. En dicho año, Austria ejecutó un ataque aéreo sobre Venecia por medio de globos propulsados por el viento que portaban explosivos. Posteriormente, tanto la primera como la segunda guerra mundial fueron acicates para el perfeccionamiento de estos vehículos. En la actualidad la tecnología en la que se basan los drones se encuentra en constante evolución y ello, unido a la universalización de su uso debido a sus precios cada vez más asequibles, variedad de tamaños y pesos y abanico de prestaciones (ver Tabla 1), da lugar a un amplio rango de aplicaciones, desde las más intuitivas, como la toma de imágenes aéreas con fines recreativos o de vigilancia, hasta las más sofisticadas. Bajo este último calificativo se engloban actividades como la meteorología, la agricultura, el transporte de mercancías, la investigación de zonas de acceso difícil o arriesgado para las personas, tales como regiones volcánicas, misiones humanitarias u operaciones de rescate. En todas estas misiones los drones brindan la capacidad de monitorizar un determinado entorno y, con los datos que éste aporta, tomar de forma rápida una decisión que ayude a completarla de forma exitosa. E A Categoría Peso al despegue (kg) Altitud de operación (m) Velocidad (km/h) Grupo 1 < 9 < 366 sobre el nivel de la tierra < 185 Grupo 2 9,55 - 25 < 1588 sobre el nivel de la tierra < 463 Grupo 3 < 599 < 8164 sobre el nivel del mar Grupo 4 > 599 Cualquiera Grupo 5 > 8164 sobre el nivel del mar Tabla 1. Clasificación de los vehículos aéreos no tripulados En paralelo, la proliferación masiva de estas aeronaves ha generado problemas no sólo técnicos, sino también relacionados con la seguridad aérea o la privacidad. Numerosos gobiernos nacionales y supranacionales han elaborado o están en proceso de desarrollar normativas encaminadas a garantizar el correcto uso de estos dispositivos. Quizá esta sobrevenida urgencia por regular el tráfico de los UAVs sea el síntoma más palpable de que estos dispositivos han llegado para quedarse 1 . Como se deduce de las aplicaciones mencionadas anteriormente, todas ellas precisan en menor o mayor medida de la transmisión y recepción de datos para su correcto funcionamiento. Así, los drones utilizados en el ámbito del transporte necesitan tomar datos de satélites que les indiquen la ruta idónea hasta su destino y notificar al lugar desde donde partió cualquier incidencia que se produzca durante el trayecto. Del mismo modo, los que sobrevuelen una zona catastrófica, como un bosque asolado por un incendio, deben adquirir y transmitir imágenes y otros datos (temperatura, dirección y velocidad del viento, etc.) al contingente de bomberos para que éste conozca a qué condiciones se enfrenta a la hora de intentar sofocarlo. Por la naturaleza móvil de los vehículos aéreos no tripulados la transmisión de datos a través de un medio cableado debe ser directamente descartada. No tendría sentido que un vuelo se viese limitado por la longitud del cable que une al dron con la estación de tierra: al final, se trataría de un sistema análogo a una cometa, con la salvedad de que entre sus extremos se produciría un intercambio de datos. Para dotar de mayor libertad de maniobra al vehículo resulta obligado recurrir a redes de comunicaciones basadas en estándares no cableados. Es en este punto cuando resulta pertinente introducir el estándar 802.11. 2.2 Introducción a IEEE 802.11 or medio del estándar 802.11 el IEEE define las comunciaciones basadas en red local inalámbrica o WLAN. Las WLAN responden a la necesidad de proporcionar conectividad en prácticamente cualquier situación a dispositivos portátiles, dando lugar a redes flexibles y versátiles que se caracterizan por su movilidad, su capacidad para llegar a zonas donde es difícil instalar redes cableadas y su coste indiscutiblemente más económico respecto de estas últimas. Para garantizar las comunicaciones inalámbricas, el estándar IEEE 802.11 utiliza las bandas del espacio radioeléctrico denominadas ISM (Industrial, Scientific and Medical). La marca Wi-Fi certifica la compatibilidad entre las distintas variantes del estándar y establece criterios de calidad de los nodos que conforman la red. Desde su versión prístina de 1997, las investigaciones de los grupos de trabajo del IEEE han ido encaminadas a mejorar las prestaciones del estándar, sobre todo en lo concerniente a la tasa máxima de 1 nytimes.com. (2016). Drone Regulations Should Focus on Safety and Privacy. [online] Disponible en: https://www.nytimes.com/2016/01/10/opinion/sunday/drone-regulations-should-focus-on-safety-and-privacy.html?_r=0 [Accedido el 6 de mayo de 2017]. Este artículo, partiendo de la constancia del creciente número de drones en manos de particulares, aborda problemas de seguridad y privacidad relacionados con su uso y las normativas elaboradas para paliarlos. P 18 transmisión. La Tabla 2 muestra la evolución del estándar. Estándar Lanzamiento Frecuencia (GHz) Ancho de banda (MHz) Tasa de transmisión máxima (Mb/s) Modulación Rango exterior (m) 802.11-1997 1997 2.4 20 2 DSSS, FHSS 100 802.11a 1999 5 20 54 OFDM 120 802.11b 1999 2.4 20 11 DSSS 140 802.11g 2003 2.4 20 54 DSSS, OFDM 140 802.11n 2009 2.4, 5 20, 40 600 OFDM 250 802.11ac 2013 5 40, 80, 160 6930 OFDM 300 802.11ad 2016 60 2160 6760 SC, OFDM 100 Tabla 2. Estándares 802.11 En la actualidad prácticamente todos los estándares trabajan en las bandas de 2.4 y 5 GHz del espectro radioeléctrico. En función de la naturaleza del medio en el que se desarrollen las comunicaciones inalámbricas, una banda u otra resulta preferible. En la Tabla 3 se explica de manera sucinta la diferencia entre ambas. Banda (GHz) Canales Rango de cobertura Presencia de interferencias 2.4 3, no solapados Amplio Mayor 5 23, no solapados Reducido Menor Tabla 3. Comparación de prestaciones entre bandas de 2.4 y 5 GHz En comunicaciones que impliquen grandes distancias entre nodos la banda de 2.4 GHz es preferible. Se recomienda su uso para tráfico elástico, es decir, aquel que puede adaptarse a variaciones en el medio de transmisión sin perjudicar a la aplicación. Se trata de una banda más proclive a interferencias debido a que se comparte esta franja del espectro radioeléctrico con tecnologías de uso masivo como telefonía inalámbrica, aparatos microondas, Bluetooth e, incluso, las alarmas antirrobo de los vehículos a motor. La banda de 5 GHz, por el contrario, tiene un radio de cobertura menor. En un entorno sin línea de visión (o LOS, por sus siglas en inglés) entre antenas transmisora y receptora, las señales con frecuencias altas se verán atenuadas debido a la presencia de obstáculos que serán salvados por otras con frecuencias más bajas [4]. En cuanto a la presencia de interferencias estas son menores, debido a la ocupación escasa de esta banda en comparación con la de 2.4 GHz. La banda de 5 GHz se destina a tráfico inelástico, esto es, aquel que precisa de un régimen binario elevado y no puede permitirse retrasos en la transmisión. El estándar 802.11ad, lanzado en 2016, supone una revolución al utilizar la banda alrededor de los 60 GHz. Por la desocupación de esta banda, un gran número de dispositivos pueden trabajar en ella transmitiendo a regímenes binarios muy superiores a los de las bandas convencionales. Se trata de un estándar donde la seguridad se ve reforzada, debido a que resulta complicado interceptar las transmisiones. Sin embargo, y por las razones antes expuestas, el operar en un rango de frecuencias tan elevado del espectro electromagnético provoca pronunciadas atenuaciones que hacen a este estándar poco recomendable en entornos donde haya elementos que obstaculicen el paso de la señal. En este proyecto la configuración de IEEE 802.11 a utilizar es ad-hoc. Este modo de conexión resulta propicio en todas aquellas operaciones que involucren drones, ya que no requiere de puntos de acceso: los propios módulos de conexión inalámbricos, montados sobre los UAVs o las estaciones de tierra, pueden comunicarse entre ellos sin estos dispositivos intermediarios. Esto supone una considerable ventaja en situaciones donde sea primordial una rápida intervención de los drones, ya que de forma presta se puede constituir la red y comenzar la comunicación. No se trata, de todos modos, de una bicoca: entre los inconvenientes asociados a una red de este tipo se encuentran la dificultad a la hora de gestionar la red de forma centralizada (todos los nodos de la red ad-hoc se encuentran al mismo nivel) y, asimismo, la imposibilidad de acceder a internet, a no ser que en uno de los dispositivos de la red, con acceso a internet, se permita una conexión compartida. Es por estos motivos que las redes ad-hoc están orientadas a un grupo limitado de usuarios y no resultan eficientes como redes masivas. Para las características de este proyecto, sin embargo, una red ad-hoc resulta idónea. Hay desventajas inherentes a las comunicaciones inalámbricas con independencia del estándar IEEE 802.11 con el que se esté trabajando o del modo de conexión utilizada, puesto que se deben única y llanamente a la naturaleza del medio de transmisión. Las investigaciones en el campo de las comunicaciones inalámbricas encaminadas a la elaboración de estándares que respondan a nuevas necesidades pueden mitigar, pero en ningún caso eliminar por completo, estas contingencias. En los párrafos siguientes se desarrollarán los cuatro grandes retos [2] que las tecnologías de comunicación inalámbricas deben domeñar. En primer lugar, considérese una estación transmisora (en adelante, estación TX) y otra receptora (en adelante, estación RX) en la que la señal puede tomar distintos caminos. Cada una de estas rutas se caracteriza por la mayor o menor presencia de obstáculos y otras incidencias que modifican el comportamiento de la señal en sus parámetros típicos. Este fenómeno se conoce como propagación multitrayecto y es causado por fenómenos de reflexión, difracción y dispersión. De este modo, las interferencias entre señales pueden ser destructivas o constructivas en función de la amplitud, la fase y el retraso con el que estas señales llegan a una antena RX en función del camino que hayan seguido. Esto se conoce como desvanecimiento de pequeña escala, o SSF por sus siglas en inglés, y generalmente da lugar a la atenuación de la señal de interés. Estrechamente relacionado con este concepto está el de desvanecimiento de amplia escala, o LSF por sus siglas en inglés. Son dos fenómenos que, obviamente, no son independientes; todo lo contrario, pues se combinan en la mayoría de ocasiones. La diferencia cuantitativa entre LSF y SSF estriba en que en la primera se dan repentinas caídas de la potencia recibida por un dispositivo en movimiento al pasar desde zonas con LOS hasta otras sin visión directa. Esto se conoce como shadowing, y es la principal causa del desvanecimiento de amplia escala. En resumen, mientras que SSF genera atenuaciones suaves en la señal, las provocadas por LSF son abruptas. Debido a la naturaleza de este proyecto, en el que se tendrá un UAV desplazándose en las tres dimensiones de un espacio abierto, el fenómeno de desvanecimiento de amplia escala se deberá tener muy en consideración a la hora de medir la calidad de las comunicaciones. Figura 1. Fenómeno de interferencia intersímbolo 20 El descrito arriba no es el único problema causado por la propagación multitrayecto. Supóngase que, para una misma señal, cada uno de los caminos por los que puede pasar da lugar a retrasos. Esto da lugar a que en un instante t, la señal que ha seguido el camino 1 entrega a la antena RX el bit k, mientras que la señal que llega por el camino 2 entrega el bit k-1, y por el camino 3 se recibe k-2. Esto da lugar a la recepción de signos contradictorios en un mismo instante, generando una distorsión de la señal. Este fenómeno se conoce como interferencia intersímbolo, o ISI por sus siglas en inglés. ISI se debe principalmente a los retrasos inherentes a cada trayecto y depende de la proporción entre la duración de cada símbolo y la duración de la respuesta del canal de comunicaciones. La Figura 1 representa esta contingencia. Obsérvese que para los datos transmitidos (TX data), cada camino presenta un retraso distinto. La ruta 1 apenas retrasa respecto del ritmo de los datos emitidos por la antena. La ruta 2, además de un mayor retraso, presenta gran atenuación. En definitiva, los retrasos y debilitamientos de la señal contribuyen a que la secuencia de bits correspondiente a la suma total de las señales no concuerde con los datos transmitidos. El segundo desafío de las redes inalámbricas se relaciona con algo ya mencionado antes: la existencia de un espacio radioeléctrico compartido con otras tecnologías (algo especialmente notorio en la banda de 2,4 GHz). El espacio radioeléctrico es limitado y, por tanto, preciado. Es por ello que las comunicaciones inalámbricas deben buscar altos índices de eficiencia espectral, es decir, de densidad de tráfico que puede procesarse por unidad de ancho de banda y de área. Para garantizar un reparto eficaz del espectro radioeléctrico que minimice fenómenos de interferencia, la Unión Internacional de Telecomunicaciones (o ITU, por sus siglas en inglés), organismo dependiente de Naciones Unidas, se encarga de asignar regiones del espacio radioeléctrico a distintas tecnologías de comunicaciones inalámbricas en función de sus características y requerimientos. Para más información a este respecto, [3] constituye una referencia fidedigna y completa a pesar de su antigüedad. El tercer factor que limita de forma decisiva las comunicaciones inalámbricas es el consumo energético. Como se verá en el apartado correspondiente a trabajos previos, son incontables las investigaciones dedicadas a este asunto, y tanto cubren el diagnóstico de la situación (por qué existe una robusta relación entre la capacidad de transmisión y el consumo enegético) como exploran posibles soluciones para rebajar la correlación entre ambos factores. De forma resumida, pues no es ésta la principal motivación del proyecto, puede concluirse que las características deseables de un sistema de comunicación inalámbrica son las que siguen: se precisa de antenas receptoras con alta sensibilidad (para evitar, por ejemplo, los problemas mentados en párrafos anteriores de este apartado); los dispositivos deben disponer de sistemas de ahorro de energía (la monitorización continua acerca de la situación de la red consume ingentes cantidades de recursos de alimentación) y, al mismo tiempo, los amplificadores con los que trabajan las antenas deben ser altamente eficientes. Por eficiencia de un amplificador se entiende la cantidad de potencia útil de salida que se obtiene a partir de potencia de señal a la entrada, y determina el ciclo de trabajo del dispositivo. En este sentido, amplificadores Clase C, con un nivel de eficiencia del 75%, o variaciones del mismo, como Clase F, resultan preferibles (en ningún caso idóneos, pues no existe un amplificador idealmente eficiente). Figura 2. Clasificación de amplificadores según su eficiencia y ángulo de conducción Sin embargo, una mayor eficiencia de los amplificadores hace de estos menos lineales y por tanto más sensibles a distorsión de la señal. La solución a esta contingencia pasa por modular la señal de acuerdo a configuraciones más sofisticadas (modulaciones con señal envolvente no constante, por ejemplo) que no se vean afectadas por estas no linealidades. Sin embargo, con este tipo de modulaciones se pierde eficiencia espectral, esto es, la capacidad de acoger en el sistema de comunicaciones al máximo posible de usuarios [15]. Como se observa, se trata de un círculo vicioso en el que hay que buscar la compensación entre las características referidas. El último factor con el que deben lidiar las comunicaciones inalámbricas es, posiblemente, el más visible e intuitivo: el de la movilidad. Cuando el usuario (o, en el caso que ocupa este proyecto, un sistema teledirigido) se desplaza, la antena transmisora que le provee de servicio puede cambiar. Es por esta razón que la estación receptora debe enviar con periodicidad tramas al sistema proveedor que informen de su localización y permitan a éste planificar la configuración más adecuada para proporcionar un servicio con unos mínimos requisitos de calidad. Pese a los inconvenientes comunes a las comunicaciones inalámbricas referidos, lo cierto es que hay diferencias entre las distintas posibilidades que hoy están disponibles en el mercado. Se ha visto, asimismo, que en Wi-Fi se mantiene una lucha entre el rango de cobertura y las interferencias sufridas por la señal. Cuando uno de estos aspectos mejora, el otro empeora: hasta ahora no se ha conseguido una optimalidad simultánea de los mismos. Es por ello que llegados a este punto sería natural preguntarse si otras tecnologías de comunicaciones inalámbricas, véanse ZigBee o Bluetooth, podrían ofrecer mejores prestaciones en lo que a la consecución de las metas de este proyecto se refiere: autonomía, rango de cobertura, caudal, etc. En el caso de ZigBee, basado en el estándar 802.15-4, su principal inconveniente radica en la pobre tasa de transmisión que ofrece, en ningún caso superior a 250 Kb/s. Dado que esta es una cifra basada en modelos teóricos, lo cierto es que se reduce dramáticamente en la realidad, llegando incluso a una décima parte del valor nominal [20]. Esto se debe principalmente a la naturaleza de CSMA/CA: los numerosos bits llamados overhead, es decir, aquellos que no transmiten datos eficaces, representan una considerable proporción del tamaño de la trama y, por lo tanto, del caudal transmitido. A este fenómeno, ya de por sí de gran calado, se suman los propios del medio de transmisión. Es por estas razones que ZigBee es una tecnología apropiada para comunicaciones que no precisan de una gran tasa de transmisión ni demasiado ancho de banda, por lo que se orienta principalmente a control y seguimiento en entornos industriales. 2.3 Dispositivos comerciales a Raspberry Pi será el dispositivo que controlará y procesará las comunicaciones inalámbricas entre la estación de tierra y el vehículo aéreo. Este producto cuenta con un adaptador integrado destinado a las comunicaciones inalámbricas Wi-Fi, no obstante, antes de recurrir a este módulo, las comunicaciones basadas en el estándar IEEE 802.11 se llevarán a cabo a través de un adaptador USB o dongle. El modelo de Raspberry Pi dispone de cuatro puertos USB por lo que dedicar uno a las comunicaciones inalámbricas no supone demasiada pérdida de funcionalidad. A la hora de decantarse por uno u otro hay que tener en cuenta características tales como las versiones del estándar que soporta, la compatibilidad con sistemas operativos o si precisa de software adicional a instalar para su funcionamiento, algo que puede mermar el rendimiento de la Raspberry Pi. El mercado ofrece distintas alternativas que responden a esta pretensión, algunos de los cuales se detallan en la Tabla 4. Fabricante Modelo Compatible con Raspbian Frec. (MHz) Interfaz Modos de conexión Estándares de seguridad AirLink AirLink101 AWLL6075 Wireless N Mini USB Adapter Sí 2.4 b/g/n 64/128-bit WEP, WPA2-PSK, WPA-PSK Asus USB-N10 Sí (imagen Wheezy) 2.4 b/g/n 64/128-bit WEP, WPA2-PSK, L 22 WPA-PSK Broadcom Wi-Fi Adapter and 2 Port USB Hub for Raspberry Pi Sí 2.4 b/g/n Infraestructura, Wi-Fi Direct, soft-AP WPA, WPA2, AES/TKIP, WAPI Edimax EW-7811Un Sí 2.4 b/g/n 64/128-bit WEP, WPA2-PSK, WPA-PSK, WPS- compatible Element14 Wi-Pi Sí 2.4 b/g/n Ad-hoc 64/128-bit WEP, WPA/WPA2, WPAPSK,/WAK2- PSK Iogear Compact Wireless-N USB Adapter No 2.4 b/g/n Ad Hoc, Infraestructura WEP, TKZP, AES, WPA, WPA2 Panda PAU09 Sí 2.4, 5 ac/b/g/n Infraestructura 64/128-bit WEP, WPA/WPA2, WPA-PSK Rosewill N150 Sí 2.4 b/g/n Ad-hoc 64/128-bit WEP, WPA, WPA2, WPA2-PSK, WPA-PSK, TKIP/AES Trendnet TEW-648UB N150 Mini Wireless USB Adapter Sí 2.4 b/g/n 64/128-bit WEP, WPA/WPA2, WPA2-PSK, WPA-PSK, Tabla 4. Modelos de adaptadores Wi-Fi para Raspberry Pi 2.4 Trabajos previos omo se ha explicado en el apartado 1, el leitmotiv de este proyecto es la calibración del rendimiento del estándar IEEE 802.11 en espacios tridimensionales con redes ad-hoc, también llamadas IBSS. En este sentido, la proliferación de vehículos aéreos no tripulados y el amplio abanico de funciones que pueden realizar han generado gran cantidad de literatura que aborda la cuestión de las comunicaciones tierra-aire a través de IEEE 802.11, con nodos desplazándose en un espacio tridimensional. Así, el presente trabajo condensa el acervo de conocimientos en la materia recogidos por otros estudios y los aplica en el caso de un vehículo aéreo controlado por una Raspberry Pi. C La abundante literatura recopilada en torno a este asunto se justifica por las nuevas posibilidades que los estándares inalámbricos ofrecen en relación a la transmisión de datos en entornos donde el cable no puede llegar, pero también por los desafíos que supone en lo que refiere a conectividad y cobertura respecto a los medios cableados, inconvenientes que además se ven potenciados en el caso de transmisión de datos en vuelo [10]. En el común de las situaciones, con redes en las que su ancho y su largo son bastante superiores a su altura, una aproximación en dos dimensiones es correcta (ver Figura 3). Sin embargo, esta no va a ser la situación que se va a abordar. Para una red de N nodos, donde el dron está a una altura sobre el eje Y mayor que las dimensiones del plano XZ es necesario abordar una perspectiva tridimensional para así comprender la situación en toda su complejidad. Como se mencionó en el apartado 1, en estas circunstancias los nodos pueden encontrarse a distintas alturas y orientaciones, y ello no debe ser óbice para que las comunicaciones deban seguir siendo eficientes (ver Figura 4). Las señales inalámbricas son mucho más sensibles a factores externos que las guiadas por un medio de transmisión como un cable. Los entornos abiertos, donde controlar las condiciones ambientales es harto más difícil que en habitaciones confinadas, plantean multitud de variables (humedad, temperatura, fenómenos meteorológicos como lluvia o viento, presencia de obstáculos, etc.) a los que el estándar de comunicaciones debe sobreponerse para así cumplir con unos criterios de calidad en cuanto a caudal de transmisión, retrasos y pérdidas de paquetes. Verbigracia, en [12] se explica cómo detalles tan nimios (la especie de los árboles que se encuentran en un determinado entorno) influyen sobre la señal. Resulta evidente que la aportación individual de cada uno de estos elementos es, en correspondencia, insignificante, pero habida cuenta de la inmensa cantidad de factores despreciables que están presentes, el efecto total puede ser considerable. La altura a la que se encuentran dispuestas las antenas de los dispositivos modifica también el comportamiento de las señales. Esto es lo que se conoce como efecto paraguas. La imagen resulta ilustrativa: cuanta mayor sea la altura de la antena, hay una mayor cobertura debajo de la misma. Como consecuencia de las variaciones que presenta el medio es arriesgado contar con un sistema electrónico de comunicación inalámbrica que conste de una única antena. Es por esta razón que los dispositivos que proporcionan conectividad inalámbrica hacen uso de la diversificación de antenas. Se trata de una técnica cuyos funcionamiento y resultados, aplicados a la comunicación entre una estación de tierra y una aeronave no tripulada, se detallan en [5]. En este paper se demuestra que la utilización de múltiples antenas transmisoras y/o receptoras incrementa de forma notable la robustez de los enlaces inalámbricos. Esta conclusión se basa en el hecho de que múltiples antenas colaborando dan lugar a una compensación del comportamiento individual de cada una de ellas: así, se experimentó con distintas rutas de vuelo y en el caso más favorable se produjo una mejora del 32% en los parámetros de calidad de la comunicación. Entre otros trabajos que abordan las contingencias asociadas a las comunicaciones entre estación de tierra y un vehículo aéreo no tripulado, [13] propone un sistema de comunicación de relevos (relay) para situaciones donde cada UAV se encuentra más allá de la línea de vision del resto (beyond-line-of-sight, o BLOS por sus siglas en inglés). BLOS supone no sólo la imposibilidad de los sistemas para establecer comunicaciones entre ellos debido a que la distancia que los separa es superior al rango de alcance de la señal, sino también la presencia de obstáculos que mitigan la señal y hacen imposible que el receptor pueda decodificarla. Figura 3. Modelo de red en 2D Figura 4. Modelo de red en 3D 24 La Figura 5 ilustra un caso en el que, debido a la presencia de una alta montaña, el ordenador que constituye la estación de tierra no puede comunicarse directamente con el dron que se encuentra en la otra cara de la montaña. Es por ello que ambos necesitan de un UAV de apoyo situado sobre la cima de la montaña, con el que los sistemas transmisor y receptor gozan de visión directa y alcance. Un proyecto relacionado íntimamente con el presente es [9]. En él, el dispositivo que hay a bordo del UAV es el modelo Galileo, resultado de la colaboración de Intel y Arduino. Se trata de un producto idóneo para tareas de sensado y monitorización con requerimientos de memoria que presenta sensibles diferencias con respecto a RPi: Galileo cuenta con un reloj propio y un procesador de 400MHz (las prestaciones del ordenador que será utilizado en este trabajo serán objeto de desarrollo en apartados posteriores). Retomando los experimentos realizados con la placa Galileo, se trabajó con un UAV en situación de campo abierto, actuando como punto intermedio entre dos estaciones de tierra. Todas las comunicaciones se realizaron con estándares IEEE 802.11, adaptados automáticamente en función de las condiciones del entorno, y se tomaron mediciones de potencia de señal y velocidad de descarga para distintos escenarios (altura sobre el nivel del suelo del dron, modo de conexión utilizado, etc.). Entre las conclusiones que resultan de especial utilidad para este trabajo destaca el hecho de que un modo de conexión ad-hoc proporciona un rendimiento mayor cuando los paquetes a transmitir son grandes (por ejemplo, se pasó de un caudal de 4.5 Mb/s para paquetes de 512 bytes a 7.5 Mb/s para paquetes de 1024 bytes). Además, se constató que la corriente consumida por las baterías de Galileo es menor cuando el modo de conexión es ad-hoc. Una red ad-hoc se caracteriza por su simetría, es decir, cada nodo que la compone posee las mismas características funcionales (a diferencia de la configuración en infraestructura, donde se encuentran puntos de acceso y estaciones por separado, cada uno con una función diferenciada). En las redes ad-hoc los nodos suelen ser dispositivos portátiles muy dependientes de alimentación. En caso de que en esta configuración un nodo quiera transmitir a otro necesita orientar la antena y ajustar la potencia de la señal en función de las exigencies del entorno. A grandes rasgos, y considerando únicamente efectos de separación física entre puntos transmisor y receptor, la señal se debilita siguiendo una relación de 1/𝑑𝑎, donde d es la distancia entre nodos y a un factor de declive de la señal (o signal decline factor) que normalmente varía entre 2 y 4. Este fenómeno, a priori limitante y perjudicial, puede sin embargo convertirse en una virtud: en una red ad-hoc basta con que la potencia de la señal transmitida por un nodo sea suficiente como para llegar sin excesiva degradación al vecino más próximo, de forma que éste pueda decodificarla. Es decir, no es necesario alcanzar un AP a una distancia cualquiera, lo que en ciertas circunstancias puede suponer una atenuación intolerable de la señal. En definitiva, en las redes ad-hoc la potencia de transmisión de un nodo la determina principalmente la distancia al nodo vecino [16], consiguiendo una mayor eficiencia energética y, por ende, una mayor autonomía de las baterías, factor cuya relevancia en este proyecto es crucial. Figura 5. Sistema de comunicación inalámbrica basado en relevos 3 HARDWARE Y SOFTWARE UTILIZADOS I do not fear computers. I fear the lack of them - Isaac Asimov, bioquímico y escritor – n este apartado se detallarán los componentes del sistema de comunicaciones. Estos elementos necesitan de una configuración previa para ponerlos a punto de manera que se adecúen a las pretensiones que se persiguen, por lo que los ajustes necesarios a realizar sobre ellos también serán materia de desarrollo en los párrafos siguientes. En resumen, los dispositivos serán descritos a niveles tanto hardware como software, prestando especial atención a aquellos puntos que más relevantes resulten en relación con los objetivos del proyecto y a aquellas fases de la configuración que hayan supuesto escollos. 3.1. Raspberry Pi a tecnología de los vehículos aéreos no tripulados no es la única que ha experimentado un proceso de democratización en su uso. Sin ir más lejos, el dron incorporará un ordenador que, por su bajo precio, su tamaño reducido y su peso liviano resulta idóneo como controlador de este tipo de producto. En un principio, las Raspberry Pi se comercializaron con el objetivo de proporcionar a los niños un ordenador de bajo coste con el que poder dar sus primeros pasos en programación. Sin embargo, sus características prestaciones pronto la convirtieron en una buena opción para aplicaciones que no precisaban del consumo de un ordenador de sobremesa o similar para su funcionamiento. En los albores del proyecto se optó por usar el modelo de Raspberry Pi 2 Model B, si bien las mayores prestaciones del modelo inmediatamente superior, Raspberry Pi 3 Model B, hicieron decantarse por este último. En este sentido, Raspberry Pi 3 Model B aporta una novedad respecto a su predecesora que resulta muy interesante en el desarrollo de este proyecto. Este salto cualitativo consiste en sendos módulos Wi-Fi y Bluetooth integrado. La evaluación de la calidad de conexiones por Bluetooth escapa del objetivo de este proyecto; por el contrario, el hecho de disponer de una interfaz Wi-Fi integrada permitirá comparar su potencial respecto al del dongle USB. E L Figura 6. Componentes de la Raspberry Pi Model 3 32 controlados por un dispositivo master concreto.  robustez, debida precisamente a la estructura distribuida de la red, que en caso de que un nodo fallara no la dejaría inutilizada, como sí sería en caso de contar con un punto de acceso que no cumpliera con sus funciones debidamente.  menor complejidad en la instalación: sólo es necesario realizar unos ajustes en software, explicados posteriormente, para conseguir que varios dispositivos compartan una red.  menor coste y mayor rentabilidad en entornos habitualmente despoblados, donde los puntos de acceso estarán durante la mayor parte del tiempo inutilizados [26], Todas estas particularidades hacen de las redes ad-hoc una opción interesante en aplicaciones militares, industriales o de rescate (imagínese que es necesario llevar a cabo una operación de este tipo en un medio que no cuenta con una infraestructura Wi-Fi previa, por ejemplo, una zona escarpada de una alta montaña). En lo que atañe a este proyecto, las RPi colocadas sobre la estación de tierra y el vehículo aéreo formarán un IBSS, siglas con las que también se designa a las redes ad-hoc. Con las direcciones de las interfaces inalámbricas configuradas en el apartado anterior es posible conformar una red ad-hoc que proporcione conectividad a las dos RPi. En primer lugar y como es obvio, los dongles deberán soportar este modo de conexión para llevar a buen término la operación. Cumplido este requisito la red puede configurarse mediante unos ajustes sencillos en el fichero /etc/network/interfaces, que se muestran en la Figura 14. En concreto, estos cambios atañen a los valores de wireless-mode, que debe ser ad-hoc; y, por otro lado, a wireless-channel y wireless-essid, que en ambos nodos deben ser idénticos para que haya conexión entre ellos. La línea auto wlan0 provoca que esta interfaz se active inmediatamente al arrancar el sistema, haciendo que la conexión a la red ad-hoc se realice automáticamente. Esto se puede corroborar posicionando el cursor sobre el icono de gestión de conexiones en la barra superior de Raspbian. Si todo el proceso se ha desarrollado correctamente, debería mostrarse lo indicado en la Figura 15. Llegados a este punto, ambas RPi son capaces de comunicarse entre ellas sin necesidad de que ninguna de ellas esté conectada a internet, como se puede corroborar a partir de la Figura 16, que muestra el resultado de un ping realizado desde 192.168.1.137 con destino 192.168.1.138. Esto supone un avance clave en el proyecto, pues propicia la consecución de las comunicaciones entre cliente y servidor cuya calidad se evaluará posteriormente. No obstante, es imprescindible para la consecución de los objetivos de este proyecto que una de las RPi, en concreto la que actúa en la estación de tierra, conste de al menos una conexión a internet, pues Figura 14. Configuración de la interfaz WLAN Figura 15. Visualización de conexiones activas en Raspbian así se logrará que ambas estén sincronizadas. Como se ha explicado anteriormente, Raspberry Pi 3 cuenta con un módulo Wi-Fi incorporado. La conectividad inalámbrica mediante este sistema puede configurarse a voluntad comentando o descomentando el siguiente comando: dtoverlay=pi3-disable-wifi, en el fichero /boot/config.txt. Es recomendable que, cuando se vayan a hacer las pruebas con el dongle USB, se descomente dicho comando, pues en caso contrario el módulo Wi-Fi integrado (o built-in) tendrá preminencia sobre el dongle. 3.1.4. Sincronización de fecha y hora: el protocolo NTP Una de las razones que hacen de Raspberry Pi un producto al alcance de todos los bolsillos es su carencia de algunas prestaciones básicas. Una de ellas es el reloj interno (RTC): este dispositivo, si bien es bastante económico (alrededor de 10 USD) es, en términos relativos respecto al coste de Raspberry Pi, caro, pues supondría cerca de un 20 por ciento de su precio de venta. Si el RTC no está presente, la Rasberry Pi precisa de una conexión a la red para conocer cuál es la hora y la fecha. Esto lo realiza a través del protocolo NTP (Network Time Protocol) [28], gracias al cual el cliente se conecta a un servidor que le proporciona periódicamente esta información. NTP es un protocolo antiguo, datado de 1985, y hoy día su uso es generalizado. Utiliza UDP como capa de transporte y el puerto 123. El motivo de usar un protocolo no orientado a conexión es que en internet el tiempo es un factor crítico, y por tanto se precisa de una conexión rápida, sin apenas latencia. NTP permite que todos los equipos pertenecientes a una misma red reciban la misma señal de reloj. Cabría preguntarse, entonces, cómo especificar a qué servidor hay que conectarse para obtener la hora correcta de acuerdo a la localización geográfica. En www.pool.ntp.org/ se recopilan todos estos servidores y se clasifican según la zona del planeta a la que dan servicio. En el momento de escribir estas líneas, en Europa hay unos dos mil ochocientos servidores NTP. La precisión de los mismos depende de quién le proporciona la información sobre la hora y fecha (ver Figura 17). Es en este momento cuando resulta pertinente explicar el concepto de estrato – stratum-. Se define como una medida de la distancia de sincronización, definida como el número de servidores que hay hasta llegar a un reloj de referencia. Así, los relojes atómicos de muy alta precisión constituyen el estrato 0, son la referencia primaria de información, y, al mismo tiempo, la más escasa por el alto coste que supone adquirir y mantener sistemas basados en relojes atómicos de cesio o rubidio, receptores GPS y CDMA. Se caracterizan por no presentar retraso y, si lo hubiere, de una magnitud infinitesimal. Los servidores que reciben información UTC del estrato 0 a través de radio, satélite o módem y la proporcionan a otros clientes de nivel inferior constituyen el estrato 1. Constituyen, además, el primer nivel de servidores NTP insertos en la red. Estos clientes que recibieron información del nivel 1 componen el estrato 2, y a su vez son servidores para clientes del estrato 3 [25], y así sucesivamente hasta el estrato 16. Un servidor sincronizado con otro de estrato n formará parte del estrato n+1. Cada estrato debe incluir varios dispositivos, es decir, se busca la redundancia en caso de fallo. Un reloj que se encuentra en el estrato 16 se considera inalcanzable, y en caso de que así sea será necesario buscar otros más cercanos. En este sentido recuerda a protocolos de routing como RIP, que utilizan el valor de métrica 16 para señalar que un punto de la red es inaccesible. Figura 16. Pruebas de conectividad en la red ad-hoc 34 De una red NTP se dice, utilizando un término anglosajón, que es semi-self-organizing. Esto significa que todos los nodos pertenecientes a la red precisan de una configuración manual previa que, una vez realizada, hace que funcionen según se requiere de forma automática. Dentro del fichero /etc/ntp.conf se puede listar, con permisos de súperusuario, las direcciones de los servidores de los que se puede obtener la fecha y hora (ver Figura 18). Es práctica recomendable incluir al menos dos direcciones para que los errores en un servidor no resulten críticos y dejen al sistema sin referencia horaria. Sirva como ejemplo el servidor con dirección hora.roa.es, situado en la localidad gaditana de San Fernando, que resultaría adecuado por criterios de proximidad geográfica. Es necesario, además, realizar otro cambio para conseguir que la Raspberry Pi que no está conectada a internet mediante la interfaz Ethernet reciba de la RPi conectada la información horaria. Dicha variación se muestra en la Figura 19. Se trata de descomentar, en el fichero /etc/ntp.conf de la RPi no conectada a internet, sus dos últimas líneas. Con esto lo que se consigue es que la RPi escuche mensajes de difusión NTP dentro de la WLAN y actualice su información horaria en función de estos mensajes. Figura 19. Modificación en /etc/ntp.conf para escuchar mensajes de difusión NTP Figura 17. Jerarquía de servidores NTP Figura 18. Direcciones de los servidores en el fichero /etc/ntp.conf El comando ntpq -pn muestra revela parámetros sobre los datos que se están recibiendo (ver Figura 20). En la primera columna se observa que, a la izquierda de las direcciones de los servidores, hay una serie de símbolos. Los asteriscos indican que es ése el servidor del que se está tomando la información en este momento. El símbolo “+” refiere a que ese servidor actúa como respaldo en caso de que el principal caiga. Por último están los marcados con “-“, que no cumplen en este momento ninguna función, pero pueden pasar a ser servidores de respaldo en cualquier momento. La columna “t” indica la categoría (el estrato) de cada uno de los servidores. Se observa que el servidor NTP en uso es de estrato 1, es decir, que está directamente comunicado con una fuente primaria. “Delay” se refiere al round-trip time (RTT), o tiempo necesario desde que un pulso viaja desde una fuente hasta su destino para luego hacer el camino inverso. “Offset” indica la diferencia en milisegundos entre la hora ofrecida por el servidor y la del sistema. “Jitter” es la diferencia hallada entre dos muestras consecutivas. Se trata, por tanto, de un sistema que no es perfecto, pues depende fuertemente de la calidad de la red y de la precisión de los relojes que aportan la información. Con todo, es sin duda la opción idónea en caso de que los nodos de la comunicación no cuenten con un reloj interno, como es el caso. Hay que dejar pasar un cierto intervalo, en torno a dos minutos, para conseguir que todos los nodos de la red se sincronicen. NTP es, en ocasiones, un protocolo con un tiempo de convergencia prolongado hasta que los equipos a la escucha de tramas NTP actualicen sus tablas y actualicen sus datos horarios. Esto se debe a que las tramas de difusión UDP proporcionan información muy precisa pero no demasiado frecuentemente, pues se envían aproximadamente cada minuto. Si pasado un tiempo prudencial siguiera sin haber sincronización se recomienda ejecutar, con permisos de súperusuario, el comando “/etc/init.d/ntp restart”. Con respecto a este tema, se comprobó que la sincronización horaria en el modelo Raspberry Pi 3 es mucho más rápida que en el 2B. Puede concluirse que cuanto menor sea la cifra que refleje el campo “st” en el servidor, más fidedigna será la información que se recibe de él. Cifras altas, cercanas a 16, son muy desaconsejables, pues no aseguran precisión. Se ve, por tanto, que NTP depende irremisiblemente de la comunicación dentro de una red. En caso de que la conexión a internet cayera, Raspberry Pi puede seguir ofreciendo la hora en función de la información que recibiera del servidor NTP antes de la desconexión. Sin embargo, una vez que Raspberry Pi se apaga toda esta información se pierde, y al volver a encenderla se comprueba que la hora se ha desconfigurado. Es en este punto donde la red ad-hoc configurada previamente entra en juego: puesto que una de las RPi, la que está dispuesta sobre el dron, no va a tener acceso a internet, su única fuente de información horaria es la RPi asociada a la estación de tierra. Si esta última tiene conexión a un servidor NTP actuará como servidor horario de la RPi del UAV. En el caso del proyecto, la RPi conectada a internet, y por tanto la que actuará como servidor NTP para la red ad-hoc, será la de dirección de red 192.168.1.137. La RPi con 192.168.1.138 sincronizará su información horaria con esta última 2 . 3.2. Alimentación ados el entorno en el que se van a desarrollar las pruebas y las necesidades de movilidad de las Raspberry Pi, éstas precisan de unas fuentes de alimentación externas que aseguren su disponibilidad durante el tiempo en el que se desarrollen las pruebas. Se utilizaron sistemas de alimentación distintos según se tratasen de pruebas estáticas o dinámicas. Para las primeras se utilizó la batería Poweradd MP- 1311RR Slim2, cuyas características figuran en la Tabla 8. 2 Para repasar la configuración de red de cada una de las Raspberry Pi se recomienda acudir a la Tabla 7. D Figura 20. Resultado de ejecutar ntpq -pn 36 Parámetros de la alimentación Tipo de batería VideoCore IV multimedia @ 400 MHz Capacidad 5000 mAh Ciclo de vida útil 500 cargas Voltaje y corriente de entrada DC 5V / 2A Voltaje y corriente de salida DC 5V / 2.1A Tabla 8. Características de la batería Poweradd MP-1311RR Slim2 Para ejecutar las pruebas dinámicas, la Raspberry Pi fue alimentada utilizando la conexión que la batería del UAV utilizado proveía, de forma que esta última alimentaba tanto al sistema de comunicaciones Wi-Fi como a todo el circuito que conformaba el vehículo aéreo. 3.3. Dispositivos de conexión inalámbrica on respecto a todos los dispositivos referenciados en la Tabla 4, el producto Wi-Pi de Element14 reúne varias características interesantes: su especificidad (está diseñado expresamente para proporcionar conectividad IEEE 802.11 a una Raspberry Pi, asegurando compatibilidad con el sistema operativo utilizado y soporte especializado), su compatibilidad con el modo de conexión ad-hoc, así como su bajo coste en comparación con dispositivos similares hacen de él una solución apta. En lo que respecta a los modos de conexión utilizados y estándares soportados, estos son ad-hoc y 802.11 b/g/n respectivamente, no suponiendo estos aspectos una diferencia cualitativa respecto a los que presentan los demás productos examinados. En lo que respecta a sus condiciones de trabajo, tanto la temperatura (-40 a 70ºC) como la humedad ambiental relativa (10-90%) establecidas para su funcionamiento con garantías se dan con creces en los entornos donde se testeará la aplicación. En situaciones donde estos dispositivos podrían estar sometidos a estrés, es decir, aquellas en las que las características del dispositivo son testadas al límite, véase incendios, sería imprescindible idear un acondicionamiento para los mismos que permitiera un correcto funcionamiento. Las características del dongle utilizado pueden examinarse mediante el comando sudo lshw -class network. En el caso del dongle Wi-Pi, arroja los resultados que se muestran en la Figura 21. Entre la información que refleja dicha figura, interesa especialmente conocer el estándar IEEE 802.11 que está utilizando. En este caso es IEEE 802.11n. C Figura 21. Características del dongle Wi-Pi Como se ha comentado en el apartado 3.1, se comparará el rendimiento del dongle Wi-Pi con el transmisor integrado del que dispone Raspberry Pi 3B. Este también hace uso del estándar IEEE 802.11n, hecho que asegura uniformidad en las condiciones del experimento y por tanto unos resultados más fidedignos que en el caso de que se usaran estándares distintos. Además, como se verá en páginas posteriores, el uso de IEEE 802.11n tiene implicaciones en los efectos del fenómeno de interferencia electromagnética sobre la calidad de la señal inalámbrica. 3.4. Elementos software 3.3.1. Lenguaje de programación: Python Python es un lenguaje de programación lanzado en 1991 por el científico de la computación neerlandés Guido von Rossum. Entre sus características, pueden destacarse:  Su simplicidad, basada en una sencilla sintaxis, similar a la de C.  Su condición de software libre y de código abierto (open source), sustentado por una comunidad de programadores.  El uso de un lenguaje de alto nivel (HLL).  Su portabilidad, de modo que puede utilizarse en una gran cantidad de sistemas operativos, entre ellos Linux, Windows y Mac.  Es interpretado, es decir, no requiere de una compilación a lenguaje máquina.  Está orientado a objetos. 3.3.2. Entorno de desarrollo: Anaconda Anaconda es una distribución libre de Python respaldada por una comunidad de desarrolladores y que dispone de una colección de unos 720 paquetes de código abierto. Este software, sencillo de instalar, supuso el primer contacto con lenguaje Python. Anaconda dispone de Spyder, un entorno de desarrollo interactivo que permite hacer labores de edición, testeo y debugging de forma simple, y que además realiza tareas de computación numérica valiéndose de librerías de Python como matplotlib, que será indispensable para la representación gráfica de los datos obtenidos durante el examen de las comunicaciones inalámbricas. 3.3.3. Programa cliente-servidor basado en TCP y UDP Para realizar las comunicaciones entre la estación de tierra y el UAV se escribieron programas cliente y servidor, ambos basados en dos protocolos de transporte distintos: TCP y UDP. Puesto que está suficientemente demostrado [22], [24] que según el protocolo de transporte utilizado se obtienen distintos resultados, la motivación de usar ambos radica en el deseo de ampliar y perfeccionar la caracterización de las comunicaciones inalámbricas. Los programas servidores de ambos protocolos (servidortcp.py y servidorudp.py) están configurados de tal forma que muestren un log con el contenido y la hora de recepción de los mensajes (ver Figura 22). Estos ficheros logs constituyen un respaldo a las capturas de Wireshark, ya que indican de forma explícita qué mensajes se han recibido desde el cliente (en las capturas de Wireshark, para ver el contenido de las tramas, hay que hacer una inspección mucho más exhaustiva). TCP es un protocolo orientado a conexión, seguro, con control de flujo y congestión y monitorización de la comunicación. Se trata de un protocolo de tráfico elástico, es decir, se adapta a las limitaciones de la red. Que un protocolo sea orientado a conexión implica que precisa del establecimiento de una conexión lógica entre nodos (three-way handshake) antes de efectuarse el intercambio de información y, asimismo, antes de terminar la comunicación. TCP permite que los paquetes lleguen al receptor con el mismo orden con el que fueron emitidos desde el transmisor y chequea si se han producido errores en la comunicación. Si el emisor del paquete no recibe confirmación de que éste ha llegado a su destino, vuelve a enviarlos. Es por estas Figura 22. Script que ejecuta el arranque del servidor 38 características del protocolo que no es apropiado para aplicaciones que necesiten velocidad, pues tanto la sincronización, la desincronización y la comprobación de errores ocupan parte significativa del régimen binario de la comunicación. En cambio, sí resulta útil en casos donde la fiabilidad y la integridad de los mensajes son importantes. En la cabecera de dicho protocolo existe un identificador de secuencia (sequence number) de 4 bytes (ver Figura 23). Este campo es compartido entre los dos extremos de la comunicación, lo que facilita en gran medida la identificación de los paquetes. Protocolos basados en TCP con Telnet, para el manejo remoto de terminales; FTP, para la transmisión de ficheros; SMTP, para el envío de correo electrónicos; HTTP, la base de las páginas web, o RMC, para la ejecución de procesos remotos. Figura 23. Estructura de la cabecera TCP Por el contrario, el otro gran protocolo de la capa de transporte, UDP, ofrece un servicio no fiable y no orientado a conexión basado en la filosofía best-effort, consistente en que los nodos reciben el mejor servicio posible en cada momento. Este “mejor servicio posible”, variante según las circunstancias, depende estrechamente de la velocidad de envío de datos por parte del emisor, y no garantiza la llegada de los paquetes (datagramas) a su destino, pues en caso de saturación de la capacidad los datagramas se pierden. En definitiva, en UDP los paquetes simplemente se envían, pero no se comprueba si llegan a su destino. Del mismo modo, pueden llegar desordenados o duplicados. Las menores prestaciones de UDP reducen su complejidad, y esto redunda en una reducción del tamaño de su cabecera en comparación con TCP. Por esta simplicidad, UDP se utiliza en aplicaciones donde la velocidad es más importante que las pérdidas, tales como juegos on line o vídeos en streaming. Todas estas aplicaciones tienen como características comunes que:  Tienen sus propios mecanismos para conexiones, control de flujo y comprobación de errores.  Alivian la carga de retransmisiones.  Se basan en un modelo de petición – respuesta. Protocolos basados en UDP son DNS, para la resoluciçon de nombres en internet, o BOOTP, este último utilizado para el arranque remoto de sistemas. Como puede verse en la Figura 24 la cabecera del protocolo UDP sólo consta de campos indicadores del puerto origen y destino en las comunicaciones, la longitud de los datos y un campo de seguridad o checksum para comprobar que estos no son modificados durante su trayecto, siendo además este último optativo. No se cuenta, por tanto, con un identificador de trama como en el caso de TCP. Este inconveniente dificulta la identificación de los paquetes enviados y recibidos, rémora que se tendrá en consideración a la hora de medir la calidad de las conexiones. 3.3.4. Wireshark: gestión de capturas de tráfico Para analizar los datos relativos a la calidad de las comunicaciones es necesario realizar anteriormente capturas del tráfico que se produce entre las aplicaciones cliente y servidor. Para ello se utilizará la herramienta tshark. Se trata de un analizador de protocolos de red que, tras ejecutarse desde consola (previa instalación en Raspbian), originará un fichero de captura con extensión .pcap que procesará y registrará en tiempo real todo el tráfico que se esté dando. Una vez finalizado el proceso de comunicacíón, el fichero de captura podrá abrirse con Wireshark. Wireshark otorga gran manejabilidad en el tratamiento de la captura previamente guardada. Una de las potencialidades a destacar es la posibilidad de filtrar los paquetes según las necesidades del usuario. Se distinguen dos tipos de filtro: los de captura (capture filters) y visualización (display filters). Como su propio nombre indica, los de captura indican aquellos paquetes que deben registrarse en el fichero de captura, y por tanto deben indicarse con anterioridad al comienzo de la misma. Por otro lado, los filtros de visualización se aplican sobre el fichero de captura ya guardado, y hacen que se muestren sólo una parte de los paquetes que han sido capturados. Esto, sin embargo, no significa que los paquetes que no concuerden con el filtro aplicado sean eliminados: simplemente se ocultan mientras el filtro esté activo. A modo de ejemplo, en la Figura 25 se muestra un filtro de visualización que atañe a los paquetes en los que el protocolo de transporte utilizado sea Figura 24. Estructura de la cabecera UDP 40 TCP y que hayan sido enviados desde la dirección de red 192.168.1.137, que fue asignada con anterioridad a la interfaz inalámbrica de una de las RPi. A continuación se indican algunos filtros que han resultado útiles para la obtención de los parámetros de las comunicaciones:  tcp && ip.src==192.168.1.137 && ip.dst==192.168.1.138 && (frame.time >= "Sep 2, 2017 21:55:54") && (frame.time <= "Sep 2, 2017 21:57:48") && frame.len!=66. Este filtro visualiza los paquetes TCP con datos “útiles” (es decir, los mensajes que se han mandado) enviados desde desde el cliente (192.168.1.137) hasta el servidor (192.168.1.138) en un intervalo de tiempo dado, entre las 21:55:54 y las 21:57:48 del 2 de septiembre.  udp && !ntp && ip.src==192.168.1.137 && ip.dst==192.168.1.138 && frame.time < "Sep 2, 2017 21:46:40.9638000". Muestra los paquetes UDP (sin incluir al protocolo NTP de sincronización horaria) enviados desde el cliente (192.168.1.137) hasta el servidor (192.168.1.138) antes de las 21:46:40 del 2 de septiembre.  tcp && ip.src==192.168.1.137 && ip.dst==192.168.1.138 && !ssh && tcp.dstport==9999 && tcp.len!=0 && frame.time>"Sep 7, 2017 17:47:10.805947" && frame.time<"Sep 7, 2017 17:48:28.805947". Con este filtro se visualizan los segmentos TCP enviados desde el cliente hasta el servidor, siendo el puerto de destino el 9999 (que es el que se ha preconfigurado en el programa clientetcp.py). Se han excluido las tramas SSH (protocolo que se sirve de TCP), así como los segmentos que no tengan carga útil (es decir, aquellos que sirven para sincronizar los extremos de la conexión o bien los asentimientos ACK).  tcp && ip.src==192.168.1.137 && ip.dst==192.168.1.138 && !ssh && tcp.dstport==9999 && tcp.len!=0 && frame.time>"Sep 7, 2017 17:47:10.805947" && frame.time>"Sep 7, 2017 17:48:28.805947" && !tcp.analysis.retransmission. Filtro que actúa del mismo modo que el anterior, pero con la condición de no mostrar retransmisiones de paquetes.  tcp && ip.src==192.168.1.137 && ip.dst==192.168.1.138 && !ssh && tcp.dstport==9999 && tcp.len!=0 && frame.time>"Sep 7, 2017 17:47:10.805947" && frame.time>"Sep 7, 2017 17:48:28.805947" && !tcp.analysis.retransmission && !tcp.analysis.duplicate_ack_frame. Con la misma función que el último, añadiendo además la eliminación de asentimientos duplicados. Otra prestación de Wireshark de la que se sacará provecho es aquella que permite exportar datos en un archivo CSV. Un archivo CSV (comma separated value, por sus siglas en inglés) es una representación en texto plano de datos tabulares, que quedarán separados por comas. Wireshark exportará al archivo CSV aquellos campos que se muestren en la lista de paquetes, previa aplicación de los filtros de visualización mencionados con anterioridad. La ventaja de estos ficheros es que Python provee de módulos dedicados a su procesamiento de forma sencilla, de forma que, por ejemplo, puedan pasarse a un array determinadas columnas del archivo CSV mediante un algoritmo simple. La interfaz de Wireshark se muestra en la Figura 26. Como se ve, se divide en tres zonas bien diferenciadas: una correspondiente a la lista de paquetes, otra a detalles de cada paquete reproduciendo la estructura del modelo OSI (así se muestran parámetros referidos al medio físico, posteriormente Ethernet, Internet Protocol, Transmission Control Protocol, etc.) y, por ultimo, la parte inferior muestra la información en bytes de cada paquete, es decir, el paquete en sí como una secuencia de unos y ceros. Esta última sección resulta útil cuando se transmiten cadenas de texto y se quiere ver cómo son codificadas en el paquete. Sin embargo, las secciones que más se utilizarán serán las dos primeras. Las columnas que se muestran (en este caso número de paquete, tiempo de captura, dirección de red origen y destino, etcetera) son aquellas cuyos campos se pasarán al fichero CSV una vez se seleccione la opción de exportar. Estas columnas, no obstante, pueden añadirse o eliminarse al Figura 25. Filtro de visualización en Wireshark gusto, es decir, es posible que la configuración por defecto de Wireshark no muestre en la sección superior ciertas columnas que resulten de interés. En la sección de detalles de cada paquete se muestran una serie de campos que, en caso de interesar, son susceptibles de pasarse a la sección superior para que así se muestren en el archivo CSV. Esto facilitará en gran medida la labor de caracterización de las comunicaciones inalámbricas, pues permitirá que a partir de un único fichero de captura éste pueda manipularse de la forma que se ha indicado antes para mostrar en el archivo CSV los datos que resulten pertinentes para cumplir con esta labor. Resulta importante reseñar que, para conseguir que las dos RPi tengan una visión integral de lo que está ocurriendo en la red, las capturas deben comenzar en el momento en que se enciendan los ordenadores, y a partir de ahí esperar a que se registren transmisiones en la red. Esto se consigue introduciendo los comandos necesarios para realizar la captura en un script que se localice en el directorio ~/.config/autostart. Una operación similar ya se hizo para tener siempre listo el servidor VNC, sin necesidad de iniciarlo manualmente. El script a utilizar se muestra en la Figura 27. Las líneas más relevantes del mismo son la tercera y la cuarta. En la línea tercera se ejecuta la captura del tráfico que se produce en la interfaz inalámbrica de la RPi. Obsérvese que una de las opciones que acompañan al comando es “-i 2”; con ella se indica la interfaz cuyo tráfico queremos capturar, en este caso la inalámbrica. Para conocer la correspondencia entre números e interfaces basta con ejecutar el comando tshark -D (ver Figura 28). Figura 27. Script que realiza la captura del tráfico Figura 26. Interfaz de Wireshark 48 En las siguientes gráficas se comprobarán las diferencias en comportamiento en función de la distancia entre Raspberry Pi y protocolo en lo que refiere a la tasa de recepción de paquetes, la velocidad de transmisión y el retardo medio. De la Figura 35 se desprende que la tasa de recepción de paquetes es máxima a una distancia de seis metros, con independencia del protocolo utilizado. Los resultados son, así, plenamente satisfactorios. Figura 34. Fichero log correspondiente a la prueba E.2 Figura 35. Pruebas E.1 y E.2: Tasa de recepción de paquetes en función de la distancia y el protocolo de transporte utilizado En lo que respecta a la tasa binaria, se mantiene estable para distintas distancias, si bien en TCP este caudal es mayor. Sin embargo, esto no debe llevar a equívoco: téngase en cuenta que la carga de cabecera del protocolo TCP es considerablemente mayor que la UDP, y por tanto, la mayor tasa de TCP se debe en gran parte a la transmisión de datos ajenos a los mensajes enviados. En cuanto a los retardos, aumentan sensiblemente en TCP para la distancia máxima de dieciocho metros. Figura 36. Pruebas E.1 y E.2: Retardo en la recepción de paquetes en función de la distancia y el protocolo de transporte utilizado Figura 37. Pruebas E.1 y E.2: Tasa binaria de recepción de paquetes en función de la distancia y el protocolo de transporte utilizado 50 4.2. Pruebas E.3 y E.4: UDP y TCP con transmisor integrado Estas pruebas testarán la calidad de las comunicaciones entre RPi en posiciones fijas cuando estas se valen del módulo Wi-Fi integrado. Figura 39. Fichero log correspondiente a la prueba E.3 Figura 38. Fichero log correspondiente a la prueba E.4 Fijando ahora el foco sobre el modulo Wi-Fi integrado, la Figura 40 sigue la tónica de los resultados de las pruebas E.1 y E.2, con tasas de recepción máximas en todos los casos. El caudal de transmisión (ver Figura 41) se mantiene estable, siendo las divergencias encontradas achacables a fenómenos aleatorios de los cuales no se pueden obtener conclusiones en cuanto a calidad de las comunicaciones. Los retardos (ver Figura 41) resultan estables en TCP, no así en UDP. De todos modos, en ningún caso toman valores prohibitivos que inhabiliten el uso del sistema de comunicaciones para aplicaciones cotidianas del UAV. Figura 41. Tasa binaria de recepción de paquetes en función de la distancia y el protocolo de transporte utilizado Figura 40. Pruebas E.3 y E.4: Tasa de recepción de paquetes en función de la distancia y el protocolo utilizado 52 4.3. Pruebas D.1 y D.2: UDP y TCP con dongle Figura 42. Pruebas E.3 y E.4: Retardo en la recepción de paquetes en función de la distancia y el protocolo de transporte utilizado En este apartado se presentan los resultados obtenidos en las pruebas dinámicas 1 y 2. En ellas, el dongle USB se colocó en la parte posterior del dron según la línea de visión. Dicho dispositivo utiliza el estándar IEEE 802.11n (ver Figura 21). El fichero log correspondiente a la prueba D.1 se muestra en la Figura 44, y refleja la terna de distancias con sus respectivos mensajes (a seis metros, aquellos enviados desde las 17:40:26 hasta las 17:41:28; a doce metros, los que transcurren desde las 17:41:35 y las 17:42:45; a dieciocho metros, aquellos desde las 17:43:00 y las 17:43:56). Por otro lado, en la Figura 45 se presenta el log correspondiente a la prueba D.2 (transmisiones basadas en el protocolo TCP). Entre las 17:46:58 y las 17:48:00 se mandaron mensajes a seis metros; a doce, entre las 17:48:08 y las 17:49:16; por último, los mensajes a dieciocho metros fueron enviados a partir de las 17:49:25. Figura 43. UAV en vuelo durante las pruebas dinámicas 54 Obsérvese en las siguientes figuras la caída en la tasa de recepción que se experimenta a la distancia máxima (ver Figura 46), y que arrastra por tanto al resto de las métricas dando lugar a un caudal ínfimo. Los retardos, asimismo, fueron considerablemente mayores que los obtenidos en las pruebas de comunicaciones estáticas. Figura 45. Fichero log correspondiente a la prueba D.2 Figura 44. Fichero log correspondiente a la prueba D.1 Figura 46. Pruebas D.1 y D.2: Tasa de recepción de paquetes en función de la distancia y el protocolo de transporte utilizado Figura 47. Pruebas D.1 y D.2: Tasa binaria de recepción de paquetes en función de la distancia y el protocolo de transporte utilizado 56 4.4. Pruebas D.3 y D.4: UDP y TCP con transmisor integrado A continuación se presentan los resultados obtenidos de las pruebas dinámicas 3 y 4. El fichero .log correspondiente al protocolo UDP corrobora que todos los mensajes transmitidos desde la GCS han llegado a su destino correctamente (ver Figura 49). Figura 48. Pruebas D.1 y D.2: Retardo en la recepción de paquetes en función de la distancia y el protocolo de transporte utilizado Figura 49. Fichero log correspondiente a la prueba D.3 El fichero muestra las tres ráfagas de mensajes enviadas a distintas distancias (a seis metros, entre las 17:40:44 y las 17:41:57 horas; a doce metros, entre 17:42:10 y 17:43:15; y a dieciocho metros, desde las 17:43:23 y las 17:44:32). Como se refirió en el apartado 3.3.5, la simplicidad del protocolo UDP hace que, a la hora de calcular el número de paquetes transmitidos con éxito, el fichero log sirve de mayor ayuda que la captura de Wireshark. En lo que corresponde a las transmisiones realizadas con el protocolo TCP, el fichero log se muestra en la Figura 50. Se ve, también, cómo todos los mensajes han llegado correctamente al servidor, independientemente de la distancia a la que se encontraran (nuevamente cinco -entre las 17:46:07 y las 17:47:10-; 10 – entre las 17:47:18 y las 17:48:26 - y 15 metros – entre las 17:48:35 y las 17:49:40 -). Figura 50. Fichero log correspondiente a la prueba D.4 65 ÍNDICE DE FIGURAS Figura 1. Fenómeno de interferencia intersímbolo 19 Figura 2. Clasificación de amplificadores según su eficiencia y ángulo de conducción 20 Figura 3. Modelo de red en 2D 23 Figura 4. Modelo de red en 3D 23 Figura 5. Sistema de comunicación inalámbrica basado en relevos 24 Figura 6. Componentes de la Raspberry Pi Model 3 25 Figura 7. Comparativa del rendimiento de 2B y 3B de acuerdo con los tests de Linpack y Dhyrstone 27 Figura 8. Máximo consumo de modelos de RPi durante la puesta en marcha del dispositivo 27 Figura 9. Diagrama de pines en Raspberry Pi 3 Model B 28 Figura 10. Configuración de interfaces de las respectivas RPi 29 Figura 11. Script que fuerza el arranque del servidor VNC al encender Raspberry Pi 30 Figura 12. Opción que permite compartir la conexión inalámbrica con la interfaz Ethernet 31 Figura 13. Direccionamiento proporcionado a la interfaz Ethernet 31 Figura 14. Configuración de la interfaz WLAN 32 Figura 15. Visualización de conexiones activas en Raspbian 32 Figura 16. Pruebas de conectividad en la red ad-hoc 33 Figura 17. Jerarquía de servidores NTP 34 Figura 18. Direcciones de los servidores en el fichero /etc/ntp.conf 34 Figura 19. Modificación en /etc/ntp.conf para escuchar mensajes de difusión NTP 34 Figura 20. Resultado de ejecutar ntpq -pn 35 Figura 21. Características del dongle Wi-Pi 36 Figura 22. Script que ejecuta el arranque del servidor 37 Figura 23. Estructura de la cabecera TCP 38 Figura 24. Estructura de la cabecera UDP 39 Figura 25. Filtro de visualización en Wireshark 40 Figura 26. Interfaz de Wireshark 41 Figura 27. Script que realiza la captura del tráfico 41 Figura 28. Relación de interfaces cuyo tráfico puede capturarse con tshark 42 Figura 29. Opción para fijar una referencia temporal en Wireshark 43 Figura 30. Autenticación basada en el protocolo SSH 44 Figura 31. Escenario de las pruebas estáticas 45 Figura 32. Escenario de las pruebas dinámicas 46 Figura 33. Fichero log correspondiente a la prueba E.1 47 Figura 34. Fichero log correspondiente a la prueba E.2 48 Figura 35. Pruebas E.1 y E.2: Tasa de recepción de paquetes en función de la distancia y el protocolo de transporte utilizado 48 66 Figura 36. Pruebas E.1 y E.2: Tasa binaria de recepción de paquetes en función de la distancia y el protocolo de transporte utilizado 49 Figura 37. Pruebas E.1 y E.2: Retardo en la recepción de paquetes en función de la distancia y el protocolo de transporte utilizado 49 Figura 38. Fichero log correspondiente a la prueba E.3 50 Figura 39. Fichero log correspondiente a la prueba E.4 50 Figura 40. Pruebas E.3 y E.4: Tasa de recepción de paquetes en función de la distancia y el protocolo utilizado 51 Figura 41. Tasa binaria de recepción de paquetes en función de la distancia y el protocolo de transporte utilizado 51 Figura 42. Pruebas E.3 y E.4: Retardo en la recepción de paquetes en función de la distancia y el protocolo de transporte utilizado 52 Figura 43. UAV en vuelo durante las pruebas dinámicas 53 Figura 44. Fichero log correspondiente a la prueba D.1 54 Figura 45. Fichero log correspondiente a la prueba D.2 54 Figura 46. Pruebas D.1 y D.2: Tasa de recepción de paquetes en función de la distancia y el protocolo de transporte utilizado 55 Figura 47. Pruebas D.1 y D.2: Tasa binaria de recepción de paquetes en función de la distancia y el protocolo de transporte utilizado 55 Figura 48. Pruebas D.1 y D.2: Retardo en la recepción de paquetes en función de la distancia y el protocolo de transporte utilizado 56 Figura 49. Fichero log correspondiente a la prueba D.3 56 Figura 50. Fichero log correspondiente a la prueba D.4 57 Figura 51. Pruebas D.3 y D.4: Tasa de recepción de paquetes en función de la distancia y el protocolo de transporte utilizado 58 Figura 52. Pruebas D.3 y D.4: Tasa binaria de recepción de paquetes en función de la distancia y el protocolo de transporte utilizado 58 Figura 53. Pruebas D.3 y D.4: Retardo en la recepción de paquetes en función de la distancia y el protocolo de transporte utilizado 59 ÍNDICE DE TABLAS Tabla 1. Clasificación de los vehículos aéreos no tripulados 17 Tabla 2. Estándares 802.11 18 Tabla 3. Comparación de prestaciones entre bandas de 2.4 y 5 GHz 18 Tabla 4. Modelos de adaptadores Wi-Fi para Raspberry Pi 22 Tabla 5. Comparativa de modelos 2B y 3B 26 Tabla 6. Nombre y funcionalidad de los pines de la Raspberry Pi 3 Model B 29 Tabla 7. Configuración de red de las Raspberry Pi 30 Tabla 8. Características de la batería Poweradd MP-1311RR Slim2 36 69 CÓDIGOS UTILIZADOS En esta sección se recopilan todos los códigos escritos en lenguaje Python que han sido necesarios para el desarrollo del proyecto. clienteudp.py Programa que envía mensajes al servidor valiéndose del protocolo UDP 1. # -*- coding: utf-8 -*- 2. """ 3. Created on Thu May 04 19:26:53 2017 4. 5. @author: Carlos 6. """ 7. 8. import socket 9. #ip target is introduced 10. UDP_IP = raw_input("Target IP >> ") 11. UDP_PORT = 5005 12. #print target IP and port 13. print "UDP target IP:", UDP_IP 14. print "UDP target port:", UDP_PORT 15. while True: 16. MESSAGE = raw_input("Message >> ") 17. 18. #print message 19. print "Received message:", MESSAGE 20. 21. sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) 22. sock.sendto(MESSAGE, (UDP_IP, UDP_PORT)) 23. 24. #if message is "close", communication ends 25. if MESSAGE == "close": 26. break servidorudp.py Programa que recibe mensajes del cliente UDP. 1. # -*- coding: utf-8 -*- 2. """ 3. Created on Thu May 04 19:30:16 2017 4. 5. @author: Carlos 6. """ 7. 8. import socket 9. from datetime import datetime 10. 11. #UDP_IP = "127.0.0.1" 12. UDP_IP = "192.168.1.138" 13. UDP_PORT = 5005 14. 15. sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) # UDP 16. sock.bind((UDP_IP, UDP_PORT)) 17. 18. while True: 19. data, addr = sock.recvfrom(1024) # buffer size is 1024 bytes 20. if data == "close": 21. break 22. 23. #Si se reciben datos nos muestra la IP y el mensaje recibido 70 24. print "Mensaje recibido de " + str(addr[0]) + " el día "+ datetime.now().strftime(' %d-%m-%Y') + " a las " + datetime.now().strftime('%H:%M:%S') + ": " + data + " " 25. #print "received message:", data clientetcp.py Programa que envía mensajes al servidor valiéndose del protocolo TCP 1. # -*- coding: utf-8 -*- 2. """ 3. Created on Sat Mar 04 14:33:13 2017 4. 5. @author: Carlos 6. """ 7. 8. import socket 9. #ip target is introduced 10. TCP_IP = raw_input("Target IP >> ") 11. TCP_PORT=9999 12. #Create socket object 13. s = socket.socket() 14. print "TCP target IP:", TCP_IP 15. print "TCP target port:", TCP_PORT 16. s.connect((TCP_IP, TCP_PORT)) 17. 18. 19. while True: 20. message = raw_input("Message >> ") 21. 22. #message to be sent 23. s.send(message) 24. data=s.recv(1024) 25. print "Received data: " + data 26. 27. #if "message is close" communication ends 28. if message == "close": 29. break 30. 31. #close socket instance 32. s.close() servidortcp.py Programa que recibe mensajes del cliente TCP. 1. # -*- coding: utf-8 -*- 2. """ 3. Created on Sat Mar 04 14:44:34 2017 4. 5. @author: Carlos 6. """ 7. 8. #!/usr/bin/env python 9. 10. #importamos el modulo socket 11. import socket 12. #importamos librería de fechas 13. from datetime import datetime 14. 15. 16. s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 17. s.bind(("", 9999)) 18. s.listen(1) 19. print "Esperando conexiones..." 20. sc, addr = s.accept() 21. 22. 23. while True: 24. 25. recibido = sc.recv(1024) 26. 27. #Si el mensaje recibido es la palabra close se cierra la aplicacion 28. if recibido == "close": 29. break 30. 31. #Si se reciben datos nos muestra la IP y el mensaje recibido 32. print "Mensaje recibido de " + str(addr[0]) + " el día "+ datetime.now().strftime(' %d-%m-%Y') + " a las " + datetime.now().strftime('%H:%M:%S') + ": " + recibido + " " 33. 34. #Devolvemos el mensaje al cliente 35. sc.send(recibido) 36. print "Cerrando" 37. 38. #Cerramos la instancia del socket cliente y servidor 39. sc.close() 40. s.close() functions.py Funciones auxiliares utilizadas en otros programas 1. # -*- coding: utf-8 -*- 2. """ 3. Created on Thu May 11 14:52:42 2017 4. 5. @author: Carlos 6. """ 7. import csv 8. 9. def sumarLista(lista): 10. sum=0 11. for i in range(0,len(lista)): 12. sum=sum+lista[i] 13. 14. return sum 15. 16. def csv_to_array(file_csv, column): 17. with open (file_csv, "rb") as csvfile: 18. reader = csv.reader(csvfile) 19. array = [] 20. for row in reader: 21. array.append(row[column]) 22. return array 23. 24. def common_elements(list1, list2): 25. return list(set(list1) & set(list2)) receptionrate.py Programa que calcula la tasa de recepción de paquetes TCP gracias al número de secuencia de cada una de las tramas. En UDP, al no disponer de un campo similar, este cálculo debe realizarse a través de la observación del fichero log. 1. # -*- coding: utf-8 -*- 2. """ 3. Created on Fri Jul 28 17:49:02 2017 4. 5. @author: Carlos 6. """ 7. from __future__ import division 8. 9. com1=[] 10. data = open(r"C:\Users\Carlos\Downloads\tcp5m.csv") 11. for line in data: 12. cells = line.split(",") 72 13. com1.append( ( cells[1] ) ) #we're interested in first CSV column 14. 15. data.close() 16. print com1 17. com2=[] 18. data2 = open(r"C:\Users\Carlos\Downloads\tcp5mCLI.csv") 19. for line in data2: 20. cells = line.split(",") 21. com2.append( ( cells[1] ) ) #we're interested in first CSV column 22. 23. data2.close() 24. print com2 25. 26. lista=list(set(com1).intersection(com2)) 27. tasarec= (len(lista)/len(com2))*100 28. print "La tasa de recepción es del " + str(tasarec) + "%" throughput.py Programa que calcula la tasa de transmisión de paquetes. Sirve indistintamente tanto para UDP como TCP. 1. # -*- coding: utf-8 -*- 2. """ 3. Created on Wed May 17 17:42:21 2017 4. 5. @author: Carlos 6. """ 7. 8. from __future__ import division 9. length=[] 10. time=[] 11. 12. data = open(r"C:\Users\Carlos\Downloads\Capturas E1 y E2\udpSERV5m.csv") 13. for line in data: 14. cells = line.split( "," ) 15. length.append( ( cells[7] ) ) 16. time.append((cells[3])) 17. time_total=time[-1]; 18. data.close() 19. 20. data = [float(i) for i in length] 21. data_total=sum(data) 22. throughput=data_total/float(time_total); 23. 24. print "El caudal de recepcion es de " + str(throughput) + " bytes por segundo" delayudp.py Programa que calcula el retardo de los paquetes UDP. Debido a las limitaciones de este protocolo este programa únicamente funciona cuando la tasa de recepción es del cien por cien. 1. # -*- coding: utf-8 -*- 2. """ 3. Created on Sat Sep 09 18:11:31 2017 4. 5. @author: Carlos 6. """ 7. from __future__ import division 8. 9. 10. from functions import csv_to_array 11. 12. hortotal=0 13. horasserv=csv_to_array(r"C:\Users\Carlos\Downloads\Capturas E1 y E2\udpSERV15m.csv",3) 14. horascli=csv_to_array(r"C:\Users\Carlos\Downloads\Capturas E1 y E2\udpCLI15m.csv",3) 15. 16. for i in range(len(horascli)): 17. hor = float(horasserv[i]) - float(horascli[i]) 18. hortotal=hortotal+hor 19. 20. print "El retardo medio es de " + str (hortotal/len(horascli)) + " segundos" delaytcp.py Programa que calcula el retardo de los paquetes TCP. Para ello, primero toma los números de secuencia de los paquetes enviados y recibidos, y entre ellos selecciona los comunes (es decir, los que han llegado correctamente). Una vez conseguido esto, toma los tiempos de transmicsión y recepción asociados a cada número de secuencia y, para calcular el retraso medio, resta tiempos elemento a elemento y divide entre el número de paquetes recibidos. 1. # -*- coding: utf-8 -*- 2. """ 3. Created on Wed May 31 20:20:07 2017 4. 5. @author: Carlos 6. """ 7. from __future__ import division 8. from functions import common_elements 9. from datetime import datetime 10. 11. 12. 13. com1=[] 14. data = open(r"C:\Users\Carlos\Downloads\Capturas E1 y E2\tcpCLI15m.csv") 15. for line in data: 16. cells = line.split( "," ) 17. com1.append( ( cells[1] ) ) #we are interested in column with Sequence Number 18. 19. data.close() 20. print com1 21. com2=[] 22. data2 = open(r"C:\Users\Carlos\Downloads\Capturas E1 y E2\tcpSERV15m.csv") 23. for line in data2: 24. cells = line.split( "," ) 25. com2.append( ( cells[1] ) ) #we are interested in column with Sequence Number 26. 27. data2.close() 28. print com2 29. c=common_elements(com1,com2) 30. print c 31. lines_c=set(c) 32. 33. 34. #calculamos índices asociados a valores de secuencia 35. ind=[] 36. for i in lines_c: 37. 38. ind.append(com1.index(i)) 39. 40. print ind 41. horas1=[] 42. horas2=[] 43. 44. ind2=[] 45. for i in lines_c: 46. 47. ind2.append(com2.index(i)) 48. 49. print ind2 50. hortotal=0 51. with open (r"C:\Users\Carlos\Downloads\Capturas E1 y E2\tcpCLI15m.csv") as csvfile: 52. lines_set = set(ind) 53. for line_number, row in enumerate(csvfile): 54. if line_number in lines_set: 55. #print line_number, row 56. test=row 57. #print test 58. last=test.split(",")[3]