Proyecto: Acceso Remoto Operacional Multimedia a Apoyos (AROMA)

Transcripción

1 Proyecto: Acceso Remoto Operacional Multimedia a Apoyos (AROMA) Código PEP: K-IT07-IDPTO RESULTADO 1: Definidas las especificaciones hardware y software para los puntos de acceso a instalar en los apoyos de alta tensión Departamento de Teoría de la Señal y las Comunicaciones de la Universidad Rey Juan Carlos

2 Índice Introducción... 1 Introducción...1 A1.1: Revisión del estado del arte con relación a sistemas empotrados de bajo consumo, alimentación de sistemas autónomos de telecomunicación y compatibilidad electromagnética entre sistemas de telecomunicación y redes de alta tensión A1.1.1 Sistemas empotrados de bajo consumo...3 A Otras estrategias de reducción del consumo...9 A1.1.2 Sistemas Operativos de Software Libre capaces de funcionar sobre empotrados...9 A1.1.3 Alimentación de Sistemas Autónomos de Telecomunicación...12 A1.1.4 Compatibilidad Electromagnética entre Sistemas de Telecomunicación y Redes de Alta Tensión. 15 A Mediciones de estudio de viabilidad del proyecto...16 A1.2: Cálculo de parámetros básicos de distancia media entre torres, visibilidad, altura y despejamiento del terreno A1.3: Cálculo, en función del tipo de servicio deseado, de los requisitos de caudal, retardo y variación de retardo máximos A1.3.1 Servicios Integrados...20 A1.3.2 Servicios Diferenciados...20 A1.3.3 QoS a nivel MAC...23 A1.3.4 Caracterización del tráfico...23 A1.4: Cálculo, en función de los datos de las dos actividades previas, del número máximo de saltos para asegurar compatibilidad TCP/IP, de la PIRE necesaria, del consumo máximo por encaminador, del dimensionamiento solar y de los límites físicos del sistema Referencias

3 Introducción La Universidad Rey Juan Carlos, y más concretamente su departamento de Teoría de la Señal y las Comunicaciones está desarrollando, como socio tecnológico del proyecto AROMA, una solución integral de comunicaciones multimedia para los apoyos de la red eléctrica de la empresa Red Eléctrica Española. Este proyecto tiene por objetivo específico el desarrollo de un prototipo de encaminador inalámbrico solar, compacto y de bajo coste, de fácil instalación, que pueda proporcionar conectividad inalámbrica segura de banda ancha soportando al menos un sistema de video-vigilancia con captura sobre los apoyos, e interconectado con la red privada IP de REE. En el presente documento se detalla el resultado R1 del proyecto, entregable que tiene por fecha límite según la planificación del proyecto el día 31 de diciembre de A continuación se detallan las diferentes actividades que componen el entregable. -1-

4 A1.1: Revisión del estado del arte con relación a sistemas empotrados de bajo consumo, alimentación de sistemas autónomos de telecomunicación y compatibilidad electromagnética entre sistemas de telecomunicación y redes de alta tensión El reto de la elaboración de un enrutador solar para una zona aislada de comunicaciones y aprovisionamiento de electricidad a baja tensión, no afecta únicamente al campo de las telecomunicaciones. Su realización implica también ciertas especificidades en el terreno de la alimentación eléctrica que lo hacen ideal para el enfoque especializado de la línea de investigación en telecomunicaciones para el desarrollo que el departamento de Teoría de la Señal y las Comunicaciones que la Universidad Rey Juan Carlos ha estado desarrollando en los últimos años. El estudio del estado del arte en relación a estos temas se ha realizado de forma comparativa tomando como referencia aquéllos dispositivos que el departamento ha empleado anteriormente en sus proyectos en regiones aisladas de países en desarrollo. Se contrastarán los datos de consumo y versatilidad de todos los equipos con el fin de seleccionar el mejor equipamiento para las condiciones dadas. Las especificaciones que se le exigen al enrutador solar son: Debe ser un sistema con el menor consumo eléctrico posible para conseguir un dimensionamiento de alimentación eléctrica más económico. Debe ser administrable remotamente, puesto que los apoyos objetivo del proyecto serán aquéllos donde otras tecnologías no llegan o no de forma económica, que acostumbran a ser lugares de mayores dificultades de acceso. Debe ser robusto frente a errores, disponiendo de watchdog hardware capaz de reiniciar el sistema en caso de bloqueo. Debe garantizar un alto grado de disponibilidad de la red, pues debido a que la disposición de los apoyos constituye la topología de la red (lineal), la probabilidad de error conjunta resulta del producto de las probabilidades individuales de error. Debe ser software libre, ya que la disponibilidad de las fuentes del software hacen posible su mejor adaptación a las condiciones específicas del proyecto, amén de rebajar el impacto de licencias sobre el presupuesto final. Debe poder funcionar en el entorno de líneas de alta tensión, puesto que se empleará en los apoyos de las mismas, y por tanto no sufrir de interferencias debido a éstas. Debe ser capaz de ofrecer un mínimo de caudal, retardo y variación del retardo tales que garanticen la video-vigilancia y la conectividad de operarios de mantenimiento con la red de REE. Con estas especificaciones puede verse claro que la consecución del objetivo no pasa por la selección individual de hardware y software sino por la revisión, interrelacionada, de: Sistemas empotrados de bajo consumo. Sistemas Operativos de Software Libre capaces de funcionar en esos empotrados y con una buena gestión de los recursos. Alimentación de Sistemas Autónomos de Telecomunicación. Compatibilidad Electromagnética entre Sistemas de Telecomunicación y Redes de Alta Tensión. -2-

5 A1.1.1 Sistemas empotrados de bajo consumo Los sistemas empotrados, sistemas diseñados generalmente con un propósito específico, pueden tener un amplio espectro de actuación. Para nuestro propósito, el de desarrollar un enrutador inalámbrico de bajo consumo que interconecte las torres de alta tensión de la red de Red Eléctrica Española, se impone como requisito indispensable realizar una actualización del estado del arte en cuanto a empotrados con bajo nivel de consumo. El motivo, como bien se explica en [1], es la estrecha relación que existe entre el consumo eléctrico de un enrutador empotrado y el coste final de la instalación (alto consumo = mayores dificultades y más costosas soluciones para la selección de una adecuada fuente de alimentación del equipamiento). En cuanto a los fabricantes de sistemas empotrados, tenemos también multitud de posibilidades para seleccionar. De los existentes, los principales fabricantes de empotrados con los requerimientos necesarios para un enrutador de las características deseadas son Soekris Engineering [10], PC Engines [11], Mikrotik [12], Ubiquiti [13] y Technologic Systems [40]. En sus proyectos, el departamento de TSC, emplea actualmente sistemas empotrados ALIX (PCEngines), que han demostrado ofrecer un bajo consumo frente a su alto rendimiento, sobre los que se ha instalado una distribución Voyage GNU/Linux adaptada a las necesidades de estos entornos. Si bien se hace necesaria también una actualización del rendimiento de cada uno de los sistemas operativos que trataremos en el siguiente punto y más en profundidad en el Resultado 2 del proyecto, en cuanto al empotrado a usar, han sido también revisados los distintos modelos de empotrados de los fabricantes mencionados anteriormente. Para la comparativa, se han seleccionado empotrados con, al menos, 2 interfaces Mini-PCI (necesarias para disponer de 2 interfaces inalámbricas con chipset Atheros), watchdog hardware y ranura de expansión para memoria compact flash con el fin de poder empotrarle un sistema operativo. Éstas restricciones vienen dadas por la solución escogida, y es que si bien se podrían emplear también interfaces inalámbricas por puerto USB, éstas se han demostrado incapaces de ser plenamente configurables con éxito bajo las distribuciones de GNU/Linux para empotrados existentes actualmente. Si bien es posible su funcionamiento, para su uso es necesario emplear el driver ndiswrapper, cuya configuración de los parámetros específicos para WiFi largas distancias (WiLD) no es posible bajo GNU/Linux. Por contra, las interfaces inalámbricas por puerto Mini-PCI con chipset Atheros permiten el uso del driver Madwifi [41] para GNU/Linux, que mediante su plenamente configurable /proc filesystem, nos permiten establecer las modificaciones apropiadas al protocolo WiFi para adaptarlo a largas distancias. El watchdog hardware nos brinda la posibilidad de la protección frente a bloqueos del software disponiendo además de drivers específicos para GNU/Linux probados con éxito en estos empotrados, así como la ranura de expansión para Compact Flash si bien no es un requisito indispensable, sí que es un aspecto deseable puesto que permite al administrador poder extender el almacenamiento únicamente cambiando la memoria, además de facilitar enormemente el proceso de instalación del sistema operativo. Los modelos comparados son: ALIX 2d2 / 3d2 net4826 de Soekris Engineering. RB600A / RB433UAH de Mikrotik Ubiquiti RouterStation Pro Technologic Systems TS-7800 Las características de estos modelos son

6 ALIX 2d2 CPU: 500MHz AMD Geode LX800 (x86) DRAM: 256MB DDR DRAM Almacenamiento: 1 socket CompactFlash Expansión: 2 ranuras Mini-PCI Conectividad: 2 puertos Ethernet 10/100 I/O: 1 puerto RS232, 2 puertos USB Firmware: TinyBIOS Watchdog Hardware: Sí Power over Ethernet: Sí Consumo de la placa: 4 W Se trata del empotrado de referencia. Empleado en los proyectos del departamento de TSC en zonas rurales aisladas de países en desarrollo, su robustez y buen funcionamiento está demostrada. Su principal problema radica en que no dispone de arranque por red (empleando TinyBIOS). Uno de sus grandes fuertes radica en la arquitectura x86, que facilita enormemente la adaptación del software para el empotrado y la compilación cruzada. ALIX 3d2 CPU: 500MHz AMD Geode LX800 (x86) DRAM: 256MB DDR DRAM Almacenamiento: 1 socket CompactFlash Expansión: 2 ranuras Mini-PCI Conectividad: 1 puerto Ethernet 10/100 I/O: 1 puerto RS232, 2 puertos USB Firmware: TinyBIOS Watchdog Hardware: Sí Power over Ethernet: Sí Consumo de la placa: 3 W Esta placa, en lo elemental, es similar a la anterior, pero con un menor tamaño. Debido a que elimina aspectos que no son necesarios para la aplicación que se le quiere dar en este proyecto, presenta también un menor consumo. -4-

7 Soekris net CPU: 233MHz AMD Geode SC1100 (x86) DRAM: 256MB SDRAM Almacenamiento: 128MB CompactFlash (Soldada en placa) Expansión: 2 ranuras Mini-PCI Conectividad: 1 puerto Ethernet 10/100 I/O: 1 puerto RS232 Firmware: net48xx BIOS con arranque por red Watchdog Hardware: Sí Power over Ethernet: Sí Consumo de la placa: 5 W Los trabajos previos con otros modelos de empotrados de Soekris Engineering por parte del departamento de TSC dan ciertas garantías de confiabilidad a este fabricante. Su arquitectura x86 facilita el desempeño del desarrollador. Como puntos fuertes posee la posibilidad de alimentación por PoE y, sobre todo, su net48xx BIOS con posibilidad de arranque por red. Combinado con el watchdog hardware, el arranque por red da robustez a la instalación, y facilita enormemente el proceso de reinstalación y actualización del firmware. Como puntos débiles tiene el almacenamiento, que al estar soldado en placa no permite su extensión así como la baja frecuencia de reloj de la CPU, que sólo alcanza los 233MHz. Ésto trae ventajas en el consumo energético pero al mismo tiempo suscita dudas sobre su capacidad de procesamiento de todas las funcionalidades que se le exigirán. Mikrotik RB600A CPU: 400MHz MPC8343E (PowerPC) DRAM: 64MB DDR SDRAM Almacenamiento: 64MB NAND chip + 2 sockets CompactFlash Expansión: 4 ranuras Mini-PCI Conectividad: 3 puertos Ethernet 10/100/1000 I/O: 1 puerto RS232 Firmware: RouterBOOT Watchdog Hardware: No Power over Ethernet: Sí Consumo de la placa: 9 W -5-

8 Este empotrado de Mikrotik tiene por ventaja fundamental el gran número de slots Mini-PCI de que dispone (4), así como de puertos ethernet. Éste elevado número da la posibilidad al empotrado de ofrecer no solo conectividad inalámbrica entre apoyos sino también hacia el propio apoyo (cámaras de video-vigilancia WiFi, sensores inalámbricos, etc). Del mismo modo, sus ranuras de expansión en número de 2, ofrecen también unas capacidades de almacenamiento muy deseadas. No obstante, tiene un punto flaco que lo descarta casi completamente para la funcionalidad deseada, y es el elevado consumo de la placa (9W), que llega incluso a rivalizar con el consumo de las radios WiFi. En una aplicación donde el consumo es tan crucial, pues puede determinar directamente que el coste de la solución se dispare al disparar el dimensionamiento energético (más consumo = más o más caras placas solares), este empotrado quedaría en la reserva para aplicaciones específicas en entornos sin problemas de alimentación. Mikrotik RB433UAH CPU: 680MHz Atheros AR7161 (MIPs) DRAM: 128MB DDR SDRAM Almacenamiento: 512MB NAND chip + slot microsd Expansión: 3 ranuras Mini-PCI Conectividad: 3 puertos Ethernet 10/100/1000 I/O: 1 puerto RS232, 2 puertos USB Firmware: RouterBOOT Watchdog Hardware: No Power over Ethernet: Sí Consumo de la placa: 3 W El empotrado RB433UAH tiene unas propiedades a considerar para rivalizar con su homólogo de PCEngines (ALIX 3d2). Así pues, sus 680MHz de procesador le convierten en un buen candidato para desempeñar todas las funciones que se requieren en las aplicaciones de video-vigilancia, transmisión de VoIP, enrutado con QoS y arranque rápido. La disposición de 3 slots Mini-PCI igualmente ofrece la posibilidad de la conectividad inalámbrica intra-apoyo con otros dispositivos y/o sensores, así como los puertos USB serían una buena solución para abaratar el coste de las cámaras de video-vigilancia, que en sus modelos con conexión USB son más baratas que con conectividad WiFi. Su bajo consumo, tan solo 3W la hace también más seleccionable. Como puntos flacos tendría fundamentalmente la memoria flash, que al estar soldada en placa no puede ser extendida fácilmente, la no existencia de watchdog hardware que la hace más vulnerable en zonas aisladas así como su arquitectura MIPs que dificulta la compilación específica para el empotrado. -6-

9 Ubiquiti RouterStation Pro CPU: 680MHz RAM: 128MB Almacenamiento: 16MB Memoria Flash (soldada en placa) Expansión: 3 ranuras Mini-PCI Conectividad: 4 puertos Ethernet 10/100/1000 I/O: 1 puerto RS232, 1 puertos USB Firmware: RouterStation Firmware con arranque por red Watchdog Hardware: No Power over Ethernet: Sí Consumo de la placa: 3 W El modelo RouterStation Pro de Ubiquiti entra entre las posibilidades con sus 680MHz de CPU. No obstante, su reducido espacio de almacenamiento no extensible limitan considerablemente las posibilidades del sistema operativo. Su principal ventaja, la alimentación por PoE. Su principal problema, el espacio de almacenamiento y la ausencia de un Watchdog hardware. Technologic Systems TS Mesa Electronics PC/104 to dual MiniPCI Adapter CPU: 500MHz ARM DRAM: 128MB DDRAM Almacenamiento: 512MB NAND Flash (soldada en placa) Expansión: PC/104 Compatible + 2 Puertos SD (full-sd + micro-sd) Conectividad: 1 puerto Ethernet 10/100/1000 I/O: 1 puerto RS232, 2 puertos USB, 2 puertos SATA Firmware: Fast Bootup firmware + kernel configurado para arranque rápido (0.68s) Watchdog Hardware: Sí Power over Ethernet: Sí Consumo de la placa: 4 W + Sleep mode (1mW) Como se puede observar, éste último se ha revisado excepcionalmente pese a no cumplir el requisito de poseer integrados en placa 2 puertos Mini-PCI para la disposición de 2 interfaces inalámbricas. La razón de su inclusión entre los empotrados seleccionables son sus otras excepcionales virtudes. La mayor pega que presenta es la no disponibilidad de puertos MiniPCI, -7-

10 que se solventa fácilmente utilizando su interfaz PC/104 en la que puede insertarse una tarjeta de expasión con slots Mini-PCI como la que se muestra en la imágen (Mesa Electronics 4I67 dual PC/104-plus to MiniPCI/Wireless Adapter [39]), así como su relativamente elevado consumo (4W). Es relativo, pues realmente la principal fuente de consumo serán las radios WiFi, pero un consumo de 4W es ya reseñable para el empotrado aislado. La ventaja fundamental, que quedaría pendiente de estudio su impacto, es su perfecta adaptación para un arranque rápido (hasta 0.68s de arranque de una distribución debian GNU/Linux). Ésta ventaja, combinada con un esquema de arranque bajo demanda (como el Wake-On-WLAN que se explicará más adelante), puede llegar a reducir enormemente el consumo del sistema sin apenas percepción del usuario final. Ésta placa consigue un especial rendimiento en el arranque debido a que tiene preinstalada una distribución debian con modificaciones apropiadas al kernel amén de un firmware de rápido arranque. Adicionalmente dispone de un modo sleep con un consumo casi nulo (1mW), que haría infinitamente más sencillo y rápido el esquema de Wake-On-WLAN. El uso del puerto de expansión PC/104 permitiría agregar más módulos en función de la variación de las necesidades del escenario. Así pues, en caso de que fuera necesario agregar más tarjetas inalámbricas, sólo habría que añadir otro módulo encima del ya introducido hasta un total de 4 (por lo que podríamos tener en total hasta 8 tarjetas inalámbricas). Los empotrados identificados, por tanto, deberán ser considerados de cara al Resultado 2 del proyecto (donde se profundizará en el software y, por tanto, pueden surgir dificultades en algunos empotrados que hagan replantearse la elección de uno u otro empotrado), por orden de adecuación a los requisitos hardware del proyecto. Así, inicialmente estableceríamos el orden de adecuación del siguiente modo: TS Mesa Electronics dual PC/104-MiniPCI Adapter ALIX 3d2 net ALIX 2d2 RB433UAH RouterStation Pro RB600A -8-

11 A Otras estrategias de reducción del consumo En la misma línea de la reducción del consumo, algunos papers hablan sobre lo que se viene denominando Wake-on-WLAN. Ésto consiste básicamente en hacer que el camino por el que la información tiene que viajar vaya siendo habilitado a medida que se va necesitando. Así, en [20] se detalla la experiencia de la red testbed Digital Gangetic Plains (DGP) en la India. En esta solución, se han empleado motas compliant de bajo consumo eléctrico para detectar la transmisión WiFi. La mota está conectada mediante un splitter a la misma antena que la radio WiFi. Una vez que detecta señal la alimentación se conmuta desde la mota al empotrado y se enciende el empotrado (placa ALIX). De esta forma, se tendrá una cierta latencia dependiente del número de sistemas en el camino a despertar y el tiempo de arranque de cada sistema, pero por contra se produce un gran ahorro energético dependiente del nivel de carga de la red. Cuando un empotrado detecta que lleva un tiempo pre-establecido sin actividad, automáticamente se conmuta la alimentación a la mota, apagando el empotrado. Si el consumo de la mota es realmente bajo, el ahorro en el consumo energético puede llegar a ser muy considerable. El esquema sería como el que vemos a continuación. Si seguimos la línea de Wake-On-WLAN, la reducción de la latencia se hace completamente dependiente del número de saltos que atraviese nuestro camino de comunicaciones y de la probabilidad de que algún enrutador en el camino se encuentre apagado en el momento de nuestra transmisión. Ésto nos obliga a escoger un sistema operativo que tenga una carga muy rápida. De momento se ha visto entre los mencionados anteriormente que el Open-WRT es el más rápido, con una carga inferior a los 10 segundos frente a la voyage que puede llegar a cargas de hasta 1 o 1,5 minutos. Por supuesto, el tiempo de carga de la distribución es completamente dependiente del empotrado que seleccionemos. Estos ejemplos se refieren a una ALIX 2d2. Otras experiencias de recursos bajo demanda (RoD) son las llevadas a cabo por los autores de [21], que con su propuesta SEAR que subtitulan Green-WLAN, consiguen alcanzar ahorros energéticos de hasta un 46% sin apenas impacto sobre el usuario final de los servicios de la red. A1.1.2 Sistemas Operativos de Software Libre capaces de funcionar sobre empotrados Debido a que el núcleo de GNU/Linux es en sí mismo un potente enrutador, y a que sobre este sistema operativo se lleva trabajando más de 10 años ofreciendo soluciones para empotrados, parece lógico seleccionar sistemas empotrados donde se pueda instalar una distribución compacta de Linux que nos ofrezca las ventajas de este sistema así como la experiencia y trabajos previos de sus comunidades de desarrollo y del mundo del código abierto. -9-

12 Las ventajas del código abierto sobre un sistema empotrado son enormes, y alcanzan su máxima expresión cuando tratamos con un proyecto de investigación en el que pretendemos desarrollar un sistema específico. La disponibilidad del código y la infinidad de herramientas [3] para su desarrollo y adaptación nos ofrecen un marco incomparable para la preparación del software a la carta, conocidas las necesidades. Algunas distribuciones de Linux específicamente diseñadas para ser construidas sobre estos sistemas son imedia [4], DD-WRT [5], fli4l [6], OpenWRT [7], Voyage Linux [8], Zeroshell [9]. Por otro lado, otras distribuciones no Linux (*nix como) adaptadas a empotrados serían Monowall (Free-BSD), PfSense (Free-BSD) y OpenBSD. Si hacemos caso a lo expresado en [21], el consumo de la radio WiFi, pese a ser muy importante en el presupuesto final de consumo, no lo es todo, y cobra enorme importancia la gestión de la energía que la propia placa realice. Como veremos en los siguientes apartados de este entregable que se refieren al cálculo de potencias y balances de enlace, para la mayor parte de los enlaces que se requerirán en este proyecto nos sobrará mucha potencia, es decir, podremos reducir la potencia de transmisión de las radios WiFi enormemente, lo que tendrá un drástico impacto sobre el consumo final del sistema y dará mayor relevancia al ahorro de consumo en el propio empotrado. Para conseguir este ahorro, además de utilizar técnicas como las citadas en el apartado anterior de RoD, también tendrá un cierto impacto el uso de sistemas operativos compactos, diseñados específicamente para la función que van a desempeñar de modo que no consuman energía en servicios que no sean estrictamente necesarios. En este sentido vamos a continuación a describir los sistemas operativos anteriormente mencionados para ver cuáles de ellos serán o no seleccionables en una futura fase del proyecto (Resultado 2): imedia La distribución imedia es una solución versátil y con gran capacidad de adaptación a escenarios específicos. Es ampliamente empleada en el mundo de los empotrados y dispone de una distribución específica casi para cada ocasión, y más concretamente, para los empotrados ALIX y las aplicaciones de enrutado inalámbrico. La instalación de la distribución es realmente sencilla usando una imagen.iso, lo que facilita enormemente el mantenimiento del equipamiento y permite la selección de los servicios para los que se desea la instalación dejando en manos del administrador sólo algunas cuestiones de configuración de red. El arranque sobre una placa ALIX 2d2 está en el mismo orden de magnitud que la Voyage, ésto es, en torno al minuto con muy pocos servicios activos. Presenta 2 problemas fundamentales que la dejan inicialmente fuera de la discusión del SO a elegir: No dispone de un sistema de gestión de paquetes. Este problema dificulta mucho la instalación, administración y mantenimiento del sistema a largo plazo. Presenta dificultades para cargar con éxito los módulos de Madwifi, siendo únicamente capaz de arrancar las interfaces Mini-PCI Atheros en su modo b. Por estas cuestiones esta distribución no será inicialmente tenida en cuenta. DD-WRT Ésta distribución para empotrados de Linux es muy prometedora. Muy empleada en sistemas comerciales, tiene un tiempo de carga sorprendentemente corto (en torno a los 10s), un gestor de paquetes ya asentado en el mundo del software libre (ipkg), requiere de muy poca capacidad de almacenamiento para funcionar (hasta 16MB), un sistema de ficheros comprimido con rápido acceso para el punto de montaje raíz (squashfs) y dispone de un interfaz de configuración gráfico

13 visual, intuitivo y aparentemente bastante depurado de errores. Todo ésto lo hace muy administrable y seleccionable para un esquema de funcionamiento tipo RoD. Sin embargo, dispone de 2 versiones, de las cuales la versión completamente libre para la que no es necesario el pago de ninguna licencia de uso no tiene una buena integración de los módulos Madwifi para interfaces inalámbricas con chipset Atheros. Dado que el sentido de este proyecto es la construcción de un enrutador inalámbrico, este sistema operativo quedaría por tanto también descartado de la selección posterior que deba hacerse en el Resultado 2 del proyecto. Open-WRT La distribución Open-WRT para sistemas empotrados es, aparentemente, una de las mejores adaptadas para el escenario que deseamos crear. Derivada de la distribución anterior junto con otras como Free-WRT o Gargoyle, se trata de una distribución con una enorme comunidad de usuarios y desarrolladores. El motivo es que fue ésta la distribución que las redes ciudadanas comenzaron a usar sobre los ya tradicionales enrutadores Linksys de Cisco. Este empuje, junto con las ventajas que ya citamos en el DD-WRT sin su inconveniente, pues éste sí que es capaz de hacer funcionar con éxito el driver Madwifi, sitúan a este sistema operativo a la cabeza de las posibilidades. Voyage La distribución Voyage, que ya cuenta con bastantes años de desarrollo, tiene además una ventaja agregada muy importante, y es que se trata de la distribución empleada en los proyectos del departamento de TSC de la URJC en los entornos más inhóspitos y aislados de las regiones rurales de países en desarrollo como Perú, Colombia o Ecuador. Éste constituye un no desdeñable "knowhow" que unido a las evidentes pruebas de estabilidad que ha dado la distribución (en algunos casos con varios años de funcionamiento ininterrumpido en regiones de selva), nos hacen contemplar esta opción con gran preferencia. Se trata de una distribución muy completa, basada en debian lenny (su versión 0.6.2), cuya comunidad de desarrolladores garantiza la continuidad del proyecto, tiene un buen gestor de paquetes (apt-get) y es posible sobre ella montar casi cualquier servicio que pudiera proporcionarse sobre un PC de sobremesa. Tiene una versión específica para empotrados ALIX, un buen sistema de personalización de la distribución, para diseñar el sistema sin que nada sobre y nada falte, y su funcionamiento es muy estable. No obstante, para la aplicación específica que vamos a desarrollar, sólo si se decide utilizar un esquema de RoD, puede presentar una tara importante ya que su tiempo de arranque sobre una ALIX 2d2 considerablemente elevado (1 min. aprox.). fli4l Se trata de una distribución de GNU/Linux pensada para empotrados y dispositivos x86 de bajos recursos con el objetivo de construir enrutadores RDSI, DSL, WLAN y ethernet. Tiene todo lo que es necesario y es capaz de funcionar en sistemas con tan solo 16MB de RAM. Su mayor problema se presenta en la traducción lingüística, y es que se trata de una distribución alemana y aparentemente no integra otras traducciones del interfaz. No obstante proporciona algunas ventajas muy importantes, y es que tiene un interfaz web muy avanzado y atractivo. Asimismo, integra algunas funciones avanzadas como soporte para Wake-On-LAN o modificaciones del protocolo de arranque

14 Zeroshell La distribución Zeroshell de GNU/Linux está pensada para aprovechar sistemas descartados para el uso de escritorio o viejos servidores (e incluso PCs de escritorio en uso) como enrutadores avanzados sin necesidad alguna de instalación, empleando su arranque desde CD. Sus requisitos son superiores a la mayoría del resto de distribuciones para empotrados, requiriendo al menos un procesador de 233MHz y 96MB de RAM. Su principal ventaja es su probado funcionamiento con el driver Madwifi para tarjetas inalámbricas con chipset Atheros. No obstante, sus requerimientos descartan inicialmente su uso. Monowall m0n0wall es un proyecto que se enfoca hacia la creación de un firewall software empaquetado para sistemas empotrados que, cuando es usado en combinación con una placa para empotrados, provee todas las herramientas importantes de un firewall comercial (incluyendo facilidad de uso) basándose para ello en software libre (FreeBSD). Una ventaja especial que tiene m0m0wall es que la configuración completa del sistema es almacenada en un único fichero de texto XML, manteniendo un elevado grado de transparencia con el usuario. Se trata probablemente del primer sistema UNIX que realiza su configuración de arranque mediante PHP en lugar de usar los habituales shell scripts, y el primero también en almacenar toda la configuración en un fichero XML. PfSense PfSense surge como un fork del proyecto m0n0wall, y por tanto, está también basado en el sistema operativo de software libre FreeBSD. Incluye un buen sistema de empaquetado software, permitiendo la expansión de las funcionalidades del sistema de forma relativamente sencilla. Su principal ventaja radica en la granularidad con la que es capaz de ofrecer la información del estado del sistema gracias a su así llamada tabla de estado, que es directamente importada de las habilidades del software pf de OpenBSD. Otra gran ventaja es el gran control que ofrece sobre el tráfico entrante/saliente, permitiendo además un balanceo de la carga de red equitativo, y al igual que en el caso de m0n0wall, su intuitivo y potente interfaz web, que permite un control completo sin necesidad de acceder a un terminal. A1.1.3 Alimentación de Sistemas Autónomos de Telecomunicación La manera más común de alimentar equipos de comunicación en zonas sin suministro de energía eléctrica es mediante el uso de energía solar. Un sistema de alimentación solar común está compuesto por un módulo o panel solar, un sistema de regulación de carga y descarga de la batería y de una batería. Hemos encontrado diversos casos en los que se hace uso de este tipo de sistemas solares para alimentar equipos WiFi. La Fundación Enlace Hispano Americano de Salud (EHAS) [1], grupo de cooperación para el desarrollo e investigación con sede en la Universidad Politécnica de Madrid y de la que la URJC es uno de los patronos, como resultado de sus investigaciones ha obtenido un primer prototipo de nodo solar inalámbrico mesh de bajo coste, autoconfigurable y de alta mantenibilidad y con soporte de de QoS. Está basado en placas Soekris de arquitectura x86, funcionando con una distribución propia,"pebble-ehas" basada en la minidistro Pebbles, la cual cuenta con las herramientas de red necesarias para realizar el enrutamiento, además de servidores DHCP,DNS y NTP y un watchdog software. Además se le ha añadido una centralita software Asterisk de VoIP. El sistema de

15 alimentación cuenta con panel solar, baterías, cargador/regulador y cableado de interconexión. Se utilizan sobre todo baterías de gel que no requieren mantenimiento. Esta primera versión fue usada para implementar redes de comunicación en Perú y en Colombia, llegando a enlazar 40 km con un throughput de más de 65 Mbps. En la actualidad se ha dejado de trabajar con la distribución "pebble-ehas" y con las placas Soekris y se utilizan más la distribución Voyage de Linux y las placas Alix de PcEngines. Esquema del router wireless solar de EHAS Green-wifi [22] es un proyecto diseñado por Bruce Baikie y Marc Pomerleau (Sun Microsystems) y patrocinado por la Organización "One Laptop per Children" cuyo objetivo es usar la tecnología existente para crear sistemas wifi de bajo coste, robustos y alimentados por energía solar para países en desarrollo. Se basa en otro proyecto de red inalámbrica llamado "Roofnet" [23] del MIT. Su prototipo de nodo Wifi [24] consta de un router Wi-Fi, panel solar y batería y circuito de control: Wi-Fi hotspot y wireless grid router: siguiendo el enfoque del "Roofnet" del MIT el proyecto comenzó usando como hardware el router WGT634U [25]de Netgear basado en Open-WRT y software open source para wireless grid. Se plantean el uso futuro del router Lynksys WRT54G [26]. Permiten funcionar en modo b y g. Panel Solar y batería: Por el momento han usado el panel solar Shell ST10 [27] en la unidad de prototipo. Este módulo solar ofrece buen rendimiento bajo condiciones de poca luz y sombra y tolerancia a altas temperaturas, por lo que proporciona una alimentación fiable en condiciones variables o adversas. De todas maneras siguen evaluando modelos de otros fabricantes. Utilizan una batería gel solar de 20 AH. Circuito de carga y control de potencia: Primero usaron la unidad de SunGuard de 5.5 amperios y 12 Voltios para comprobar como funcionaría una unidad de bajo coste y "off-theself". Sin ningún tipo de control de potencia, el tiempo de funcionamiento del router era corto. La batería se acababa en 4 días con algún día lluvioso o con nubes. Más tarde emplearon un diseñó modificado que permitía que el router funcionará solo durante un periodo de tiempo específico y fuera apagado durante otro. Estó hizo que el tiempo se alargará hasta 28 días. Todavía dos semanas de tiempo lluvioso o con nubes hacían que el tiempo de funcionamiento no superara los 30 días. El diseño definitivo puede controlar el día y tiempo y además permite al usuario acceder a través de una interfaz web al software del dispositivo y a la potencia de salida del dispositivo y además permite monitorizar el nivel de carga de la batería

16 Prototipo de router wireless solar de Greenwifi El grupo de investigación TIER (Technology and Infraestructure for Emerging Regions) de la Universidad de California [28], Berkeley tambíen hace uso de routers Wi-Fi solares en algunos de sus proyectos de redes Wi-Fi de larga distancia en la India [29]. Para mejorar el tiempo de funcionamiento de la red e incrementar el tiempo de vida de los componentes, han desarrollado un controlador de potencia de bajo coste que proporciona una corriente estable de 18 A a los routers wireless combinando energía obtenida a través del panel solar y de la batería. Combina en una unidad controlador de carga, PoE ("Power over Ethernet"), medidor de potencia de pico (PPT) y monitorización remota. Controlador solar del TIER La Universidad de Sao Paulo [30] en Brasil está trabajando en un proyecto coordinado por Marcelo Zuffo para permitir el acceso a internet en zonas aisladas para lo que están construyendo routers WiFi solares autónomos. Estos constan de un panel solar, una batería de motocicleta y un circuito que se encarga de la gestión de energía. La meta de los investigadores es que los dispositivos lleguen a tener una autonomía de 10 días. También existen productos comerciales, entre ellos destacan los de las empresas Lumin Innovative Products y Meraki. Meraki[31] comercializa el producto "Meraki Solar" [32], un dispositivo mesh Wi-fi alimentado por energía solar. Estos dispositivos pueden transmitir con una potencia de pico de 200 mw, permiten los modos b y g e incluyen una antena omnidireccional de 2 dbi. No disponen de

17 puertos de Ethernet externos. Incluyen batería y controlador de carga. El panel solar se vende por separado, dependiendo de la zona geográfica en la que se vaya a instalar se necesitará un panel de 20, 40 o 60 Watios. El dispositivo un panel de control que permite monitorizar y configurar la unidad de manera remota. Meraki Solar Lumin Innovative Products comercializa los routers Lightwave AP Estos terminales están basados en un punto de acceso Orinoco de la marca Proxim encapsulado en una carcasa estanca, están equipados con paneles solares y provistos de baterías recargables. Poseen un alcance de hasta 40 km. Estos terminales se utilizarón en el despliegue de una red wifi en la ciudad de Boulder (Colorado) para dotar de acceso a internet a sus habitantes, fueron instalados en los tejados de las viviendas y con ello se cubrieron seis manzanas del centro de la ciudad. A1.1.4 Compatibilidad Electromagnética entre Sistemas de Telecomunicación y Redes de Alta Tensión La presencia de líneas de alta tensión puede afectar a las comunicaciones inalámbricas. El ruido electromagnético generado alrededor de estas líneas puede considerarse como una señal que puede interrumpir, obstruir, o degradar la señal original. Este ruido en las líneas de alta tensión es debido principalmente al efecto corona. Este efecto, como se indica en [33] consiste en la ionización del aire que rodea a los conductores de la líneas de alta tensión, cuando el valor del campo eléctrico en la superficie de estos supera un determinado umbral. Al ionizarse las moléculas de aire, estas comienzan a conducir la energía eléctrica y una parte de los electrones que circulaban por la líneas pasa a circular por el aire. Esto se denomina radiointerferencia. La dependencia del efecto corona con las condiciones climatológicas es elevada, esto se ha tenido en cuenta al realizar las mediciones que se presentan en el punto siguiente de este apartado. Se ha encontrado un artículo [34] que describe un desarrollo analítico y experimental desarrollado para evaluar los efectos de los campos electromagnéticos producidos por la líneas de alta tensión de 400 kv, bajo diferentes condiciones atmosféricas en transmisiones de datos inalámbricas en la banda de 900 MHz. A pesar de que no se va a trabajar a esas frecuencias, ya que la banda de frecuencia que se utilizará es la de 5,6 Ghz, algunos de los resultados obtenidos de este trabajo pueden extrapolarse a WiFi ya que los fenómenos físicos involucrados en el proceso de transmisión de la señal portadora de la información son los mismos

18 De entre las conclusiones de este artículo destacamos que la radiointerferencia generada por la líneas de alta tensión disminuye logarítmicamente con la distancia a la linea de tensión, lo que tendrá que tenerse en cuenta al colocar los equipos, y con la frecuencia, por lo que sería recomendable que el sistema de comunicación opere a la frecuencia más alta posible. A Mediciones de estudio de viabilidad del proyecto Cumpliendo con la petición de realizar un estudio de viabilidad de interconexión de torres de alta tensión de la empresa Red Eléctrica Española, la Universidad Rey Juan Carlos realizó en noviembre de 2008 unas mediciones previas para estudiar la viabilidad de realizarlo utilizando redes inalámbricas WiFi. Las mediciones realizadas tuvieron como finalidad contemplar de forma práctica la posible existencia de interferencias que imposibilitaran la comunicación inalámbrica en frecuencias de microondas (f>1ghz). Estas medidas fueron obtenidas el Jueves 13 de Noviembre de 2008 en la subestación que REE tiene en San Sebastián de los reyes. Se diseñaron 2 escenarios básicos de pruebas con los que se pretendían contemplar las situaciones más adversas para el enlace y poder decidir la viabilidad de éste en cada caso. Las pruebas estuvieron limitadas fundamentalmente por la disposición arquitectónica de la subestación (lo que obligó a rediseñar los escenarios in situ ), la presencia de fuerte viento el día de las mediciones y las obras que se estaban realizando en la base de la torre de alta tensión. Todo ello no obstante no hizo más que añadir factores negativos en los enlaces, por lo que de demostrarse viabilidad en este caso, se podría asegurar robustez de redes bien dimensionadas, con material de calidad y condiciones normales

19 Escenarios Se presenta a continuación el diagrama de mediciones: En el escenario 1 el nodo STA está subido en la torre y el nodo AP está en tierra a una distancia aproximadamente igual a la empleada en el escenario 1. La dirección del enlace es perpendicular a la dirección de las fases. El escenario 2 tiene la misma distribución que el escenario 1 situando al nodo AP debajo de los cables de alta tensión. En ambos escenarios, el nodo STA se situó a unos pocos metros de la fase de la torre de alta tensión también con el fin de empeorar el enlace en caso de existir radiointerferencias relevantes. Datos Las pruebas de throughput se realizaron en un escenario preconfigurado con la cola AC_VI de e a los valores de WiFi estándar (txoplimit=0 aifsn=2 cwmin=5 cwmax=10) y con las funciones super a/g de Atheros [42] en el nodo AP desactivadas. Se usó para todo ello un script que lo automatizaba en el nodo AP (Nota: los valores de WiFi estándar están escritos en el formato que el driver Madwifi para tarjetas inalámbricas con chipset Atheros en Linux lo entiende. En realidad cwmin=2^5-1=31 y cwmax=2^10-1=1023). Los comandos ejecutados para medición de throughput fueron: En servidor: iperf -s -u -l1472 -S0xb8 En cliente: iperf -c <IP_servidor> -u -d -l1472 -S0xb8 -b 30M -t 60 Las mediciones de nivel de señal y ruido se extrajeron directamente del comando iwconfig. La distancia entre los nodos fue la misma en los 3 escenarios, y corresponde a la altura hasta el punto de la torre donde se realizaron las mediciones. Distancia aproximada: 50m

20 Los valores que se presentan a continuación son una media de 10 valores para los niveles de señal y ruido, y 60 segundos de medición en cada medida de throughput. Para el throughput se inyectaron 30 Mbps en cada sentido (AP=>STA y STA=>AP) para asegurar la saturación del enlace. Escenario Nivel de señal (dbm) Nivel de ruido (dbm) Throughput (Mbps) AP STA AP STA AP STA STA AP ,43 2, ,97 1,91 Conclusión A la vista de los datos obtenidos, quedó demostrado que existía enlace en las peores condiciones posibles e incluso con throughputs aceptables para un buen nivel de comunicación (en el peor de los resultados obtenidos el caudal sería suficiente, por ejemplo, para albergar simultáneamente hasta unas 38 conversaciones de voz usando un codec Speex). Por tanto, teniendo en cuenta se trataba de un caso anormalmente negativo, y que los enlaces de ambos escenarios tuvieron en media un throughput total de 4,375 Mbps, concluimos que el proyecto es viable y no existe interferencia electromagnética de relevancia entre sistemas WiFi de telecomunicación y redes de alta tensión que impida la comunicación para las distancias requeridas en el proyecto

21 A1.2: Cálculo de parámetros básicos de distancia media entre torres, visibilidad, altura y despejamiento del terreno La distancia media entres las torres está entre los 400 y 500 m. En casos excepcionales como cruce de valles o embalses puede ser de más de 1 Km. Hay tres tipos de apoyos básicos en la Red Eléctrica española cada uno con distintas dimensiones. Apoyo tipo 41A4 Angulo: tienen una altura total de 42,80 m, pero las fases más bajas están situadas a 36 m. Apoyo tipo 43A2: tienen una altura total de 66 m, pero las fases más bajas están situadas a 44 m. Apoyo tipo DRAGO 1600: tienen una altura total de 40,9 m, pero las fases más bajas están situadas a 24 m. No obstante, dado que la Red Eléctrica Española ha asumido activos de las restantes empresas eléctricas la tipología puede ser muy variada. Dada la distancia media entre las torres y la altura de estas se tiene visibilidad garantizada de una torre a otra. La existencia de línea de vista es una condición necesaria en este proyecto ya que se van a utilizar equipos a y el uso de estos equipos en exteriores cuando las distancias son de centenares de metros está restringido a puntos en línea de vista. La visibilidad en un salto está garantizada pero habrá que comprobar en cuantos saltos sigue manteniéndose. Para la ubicación de equipos de telecomunicación u otro tipo de equipamiento electrónico se considera típicamente una distancia de seguridad de 3 metros bajo las fases. Por despejamiento entendemos la distancia mínima de las fases al suelo, que será la altura de la fase menos el valor de la flecha. Está estipulada una distancia mínima de las fases al suelo de 9m para líneas de 400kV y de 8 m para líneas de 220kV, con una altura media de 20 m. Si las fases están muy bajas, la línea estaría diseñada con menor flecha para cumplir estos criterios

22 A1.3: Cálculo, en función del tipo de servicio deseado, de los requisitos de caudal, retardo y variación de retardo máximos Una vez determinadas las posibilidades hardware y vistas someramente las distribuciones software que servirán conformarán la estructura de la solución, hemos de entrar en detalle sobre los servicios que se espera que este sistema ofrezca. Y cuando hablamos de servicios en redes, es inevitable, si se desea tener ciertas garantías, hablar también de calidad de servicio (comúnmente en inglés, QoS) y definir los tipos de servicio deseados. Existen fundamentalmente 2 arquitecturas de QoS (Quality of Service) para redes IP con diferente filosofía, a saber, IntServ o modelo de Servicios Integrados y DiffServ o modelo de Servicios Diferenciados, estandarizadas ambas por el IETF. A1.3.1 Servicios Integrados Según este modelo de QoS, cuando se va a transmitir se debe hacer una reserva previa de recursos antes de establecer la comunicación entre dos puntos. Si todos los nodos que forman el camino entre esos dos puntos pueden comprometer los recursos necesarios para proporcionar la calidad requerida entonces la comunicación es aceptada. De esta forma cada nodo tratará de forma particular a cada paquete de ese flujo hasta que termine la conexión. Para realizar la reserva de los recursos necesaria a lo largo de todo el camino de la comunicación, tanto para la propia comunicación como para la señalización necesaria, se utiliza un protocolo llamado RSVP (ReSerVation Protocol). A priori esta aproximación pudiera resultar la más apropiada en cualquier caso, pues estaríamos garantizando que cada comunicación individualmente tiene garantizados los recursos para ser cursada. No obstante, cuando el nivel inferior de la comunicación es a/g (WiFi) en su modo EDCA, tiene poco sentido hablar de este modelo de QoS, y es que el protocolo es un protocolo con acceso al medio estadístico donde es imposible dar garantías absolutas de QoS. Por otra parte, el medio inalámbrico es un medio fluctuante, que introduce una gran cantidad de ruido y errores en la comunicación, y donde las prestaciones de la red pueden variar rápida y drásticamente, lo que dificulta la gestión de los recursos. Asimismo, la gestión centralizada de los recursos de la red suscita un gran problema asociado a la necesidad de mantener el estado de cada comunicación por parte del nodo gestor, lo que se hace insostenible. A1.3.2 Servicios Diferenciados Como solución a los problemas que el anterior modelo presenta, existe otra aproximación al problema de establecer ciertas garantías a cada servicio deseado, y éste es el modelo de servicios diferenciados. La óptica de este modelo consiste en ver el tráfico agregado que llega a cada nodo como una serie de comunicaciones con una prioridad asociada. Así, en este caso no se reservan recursos sino que cada paquete de información va marcado con un identificador que indica la clase de servicio a la que pertenece. De esta forma, definiendo un número apropiado de clases de servicio, podremos diferenciar en los nodos intermedios de la comunicación qué paquetes

23 pertenecen a una comunicación con determinadas garantías de servicio y actuar en cada salto de forma apropiada (encolado, priorización, descarte, etc) para cumplir con las garantías deseadas. Este modelo tiene el problema de que, al tratar el tráfico salto a salto sin tener en cuenta el conjunto, no puede en ningún caso dar garantías estrictas, sino más bien aproximadas o relativas. Por contra, escala sin problemas a arquitecturas de extensas dimensiones. Habitualmente cuando hablamos de Servicios Diferenciados en capa IP, solemos hablar de las siguientes clases de servicio (distinguidas en el campo DSCP de IP), conocidas como PHBs (Per Hop Behaviour) refiriéndose a que definen el comportamiento por salto: BE (Best Effort) Tráfico que no tiene ningún requisito y por tanto no requiere de tratamiento especial EF (Expedited Forwarding) Tráfico de mayor prioridad, con requisitos estrictos en materia de caudal, retardo y jitter. AF (Assured Forwarding) Lo integra el tráfico con ciertos requisitos, y se definen 4 clases de servicio con 3 niveles de prioridad cada una, conocidas como AFxy (Assured Forwarding clase x prioridad y, siendo 1<=x<=4 && 1<=y<=3). Debido a que escala mejor con las dimensiones de la red y a que se trata del modelo de calidad de servicio más empleado (y por tanto cuyo desarrollo está más depurado), se usará para aplicar calidad de servicio el modelo DiffServ. También hay que tener en cuenta que siendo un requisito primordial el ahorro de transmisiones radio (ahorro de consumo energético), es preferible usar una arquitectura que no requiere de transmisiones adicionales para reserva de recursos. La implementación software de esta arquitectura en GNU/Linux se lleva a cabo empleando lo que se conocen como disciplinas de colas. Cuando un paquete llega, las disciplinas de colas (implementadas en el núcleo del sistema operativo), entran en juego. De forma jerárquica, se puede establecer un árbol de disciplinas de colas tan complejo como se necesite. Se le pueden aplicar al paquete disciplinas de descarte o remarcado antes de ser procesado, se puede enviar a las capas altas de la arquitectura de red para que sea tratado por el sistema operativo, se pueden tomar decisiones antes de reenviarlo y se puede encolar en una u otra cola en función de sus características. El kernel 2.6 de GNU/Linux, empleado por defecto en la mayor parte de las distribuciones que se usan actualmente sobre empotrados, ya integra el soporte para la mayor parte de las disciplinas de colas que se requerirán. No obstante, es posible sin demasiado esfuerzo recompilar el núcleo del sistema operativo para activar este soporte