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

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 2009.

A continuación se detallan las diferentes actividades que componen el entregable.

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

La experiencia previa de la Universidad Rey Juan Carlos a través de la Fundación EHAS, de la que es patrono, con empotrados de bajo consumo para entornos rurales de países en desarrollo es un punto de partida ideal para este proyecto. Así, el estudio del estado del arte en relación a estos temas se ha centrado especialmente en cotejar los datos de consumo y versatilidad de los dispositivos empleados por la Fundación EHAS en sus proyectos para, comparativamente, ir revisando los nuevos productos existentes en el mercado y sus posibilidades con el fin de establecer si la solución de partida (la solución EHAS) es también la más adecuada para el entorno del proyecto AROMA.

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.

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 pequeña 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] y Ubiquiti [13].

La experiencia de la Fundación EHAS en el diseño e implementación de redes WiFi de área extensa en zonas rurales de países en desarrollo es un bagage altamente valioso que emplearemos como base para este trabajo. En sus proyectos, la Fundación EHAS, 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 levemente 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 al menos 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, y es que 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 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...

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: No

Consumo de la placa: 4 W

Se trata del empotrado de referencia. Empleado en los proyectos de la Fundación EHAS 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 la posibilidad de alimentación mediante Power over Ethernet ni 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: No

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.

Soekris net4826-48

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 de la Fundación EHAS 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

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 copletamente para la funcionalidad deseada, y es el elevadísimo 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.

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: ?

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-7800

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 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 Mini-PCI, que podría estudiarse solventar utilizando su interfaz PC/104, 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.

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:

1. ALIX 3d2 2. net4826-48 3. ALIX 2d2 4. RB433UAH 5. RouterStation Pro 6. TS-7800 7. RB600A

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 802.15-4 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 automáticamente 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.

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.

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” a la carta 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 podemos hacer una breve descripción de 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 imágen .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 802.11b.

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 incluso en sistemas comerciales, tiene una carga sorprendentemente rápida (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 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 tantas 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 de la Fundación EHAS 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 "know-how" 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, 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 montarse sobre un PC de sobremesa. Tiene una versión específica para ALIX, un buen sistema de construcción de la distribución "a la carta", 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

Zeroshell

Monowall

PfSense

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 cómun 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 Wi-Fi.

La Fundación EHAS 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 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, llegándo 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 802.11b 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-the-self". Sin ningun tipo de control de potencia, el tiempo de funcionamiento del router era corto. La batería se acababa en 4 días con algun 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.

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 projectos 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 802.11 b y g e incluyen una antena omnidireccional de 2 dBi.No disponen de 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 1000”. 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.

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 puede producirse por dos motivos, descargas eléctricas entre componentes de la línea y efecto corona. El primero de ellos sólo se presenta en lineas de alta tensión por debajo de 70 kV, por lo que su estudio no es de interés en este caso, ya que trataremos con líneas de alta tension de 400 kV.

El efecto corona, por el contrario, sí es de nuestro interés, ya que afecta a líneas por encima de los 110 kV. Este efecto consiste en la ionización del aire que rodea a los conductores de alta tensión, al ionizarse las móleculas 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 see denomina radiointerferencia. Este fenómeno se produce cuando el gradiente eléctrico en los conductores supera la rigidez dieléctrica del aire.

El efecto corona tiende a dominar el espectro de frecuencia entre los 10 y 30 MHz.

La dependencia del efecto corona con las condiciones climatológicas es elevada, lo que imposibilita su cálculo de un modo determinista y lleva a la necesidad de emplear estimadores estadísticos diferenciados para cada condición climatológica.

Del artículo [33] podemos obtener la siguiente tabla que muestra los niveles de interferencia emitidos por líneas de la red de transporte de 400 kV en España.

Niveles de radiointerferencia emitidos por líneas de 400 kV

Estos niveles están calculados con el estimador L1 para lluvía abundante, en decibelios sobre 1 microV/m. Como podemos observar el valor máximo absoluto de radiointerferencia emitida obtenido es de 87 dB y el valor máximo que se obtiene a una distancia horizontal de 15 del centro de la línea es de 82 dB. La disminución de la radiointerferencia emitida a una distancia lateral puede variar entre 5 y 14 dB. De la figura puede deducirse también que los niveles de interferencia son

mayores cuando se emplean conductores por fase (frente a tres).

Del mismo artículo puede obtenerse que los niveles de radiointerferencia estimados con el estimador L50 para buen tiempo no superan en ningún caso los 65 dB sobre 1 microV/m.

El artículo [34] describe un desarrollo analítico y experimental desarrollado para evaluar los efectos de los campos electromágneticos producidos por la líneas de alta tensión de 400 kV, bajo diferentes condiciones atmosféricas en transmisiónes de datos inalámbricas en la banda de 900 MHz. Algunos de los resultados obtenidos de este trabajo pueden extrapolarse a Wi-fi 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. Por lo tanto se puede concluir que la radiointerferencia generada por la líneas de alta tensión disminuye logarítmicamente con la distancia a la linea de tensión y con la frecuencia, por lo tanto sería recomendable que el sistema de comunicación opere a la frecuencia más alta posible.

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. Si bien puede variar entre 200m y 2 Km. Distancias de más de 1 km son casos excepcionales como cruce de valles o embalses.

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, es decir un salto, pero habrá que comprobar en cuantos saltos sigue manteniéndose la visibilidad.

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 sobre 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.

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 (comunmente en inglés, QoS) y definir los tipos de servicio deseados.

Existen fundamentalmente 2 arquitecturas de QoS (Quality of Service) con diferente filosofía, a saber, IntServ o modelo de Servicios Integrados y DiffServ o modelo de Servicios Diferenciados, estandarizadas ambas por el IETF.

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 802.11a/g (WiFi) en su modo EDCA, tiene poco sentido hablar de este modelo de QoS, y es que el protocolo 802.11 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.

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 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.

Las disciplinas de colas más empleadas son:

• PRIO

se trata de una disciplina de colas con clases, es decir, una disciplina que puede contener a su vez otras subclases (otras disciplinas en su interior). Su mecanismo permite priorizar de forma absoluta unos flujos frente a otros, definiendo 3 tipos de prioridad. Mientras exista un paquete

en la cola de mayor prioridad, no se cursan los paquetes de prioridad inferior. Puede ser útil para gestionar tráfico que requiera atención inmediata frente al resto del tráfico. No obstante, hay que tener en cuenta que su uso puede generar escenarios de abuso de los tráficos más prioritarios hacia los menos prioritarios, que pese a tener menor prioridad, en muchas ocasiones no es conveniente que sean completamente obstaculizados.

• HFSC (Hierarchical Fair Service Curve)

es una disciplina de colas con clases donde se permiten hacer configuraciones complejas, como que de todo el caudal disponible exitan flujos que cedan su uso de los recursos hacia otros, permitiendo un control fino del tráfico.

• HTB (Hierarchical Token Bucket)

es una disciplina de colas con clases. Realiza una compartición jerárquica y personalizable del enlace.

• DSMARK

es una disciplina de colas con clases bastante peculiar. Sirve para remarcar el campo DSCP (Differentiated Services Code Point) de IP, que es el campo a partir del cual se establece el PHB al que pertenece el paquete en cuestión.

• FIFO (First Input First Output)

es una disciplina de colas sin clases, o lo que es lo mismo, de ella no pueden pender más disciplinas de colas anidadas. Es la disciplina más sencilla y consiste en que el primer paquete que llega es el primero en salir.

• TBF (Token Bucket Filter)

es una disciplina de cola sin clases, y se emplea como conformador de tráfico ()

• SFQ (Stochastic Fairness Queuing)

se trata de una disciplina de colas sin clases que sirve para hacer más justo el encolado/desencolado haciendo que ningún flujo pueda monopolizar el interfaz.

• RED

disciplina sin clases que, de hecho, es más que una disciplina de encolado, una disciplina de descarte. Configura un descarte de paquetes preventivo en varios niveles de forma que cuando se supera un umbral se comienzan a descartar paquetes con probabilidad "p", y a partir de otro umbral se descartan todos los paquetes hasta salir de la situación de congestión.

Todo lo anterior sobre DiffServ a nivel IP y disciplinas de colas se completa con el paquete iproute2 que se encarga de agregar el "enrutado avanzado y gestión del tráfico" en GNU/Linux, cuyas entrañas pueden desgranarse en [35].

QoS a nivel MAC

Es importante tener en cuenta a nivel IP las políticas necesarias para priorizar un tráfico u otro, pero cuando nos encontramos en una situación de saturación en que no sólo intervienen en el resultado final del tratamiento para cada flujo las accinones de la capa IP, sino también la situación de la capa MAC (cuando un paquete llega para ser transmitido, casi nunca se encuentra el medio libre o las colas de transmisión MAC vacías). Por tanto, para poder determinar completamente la calidad de servicio de una red hemos de intervenir de forma integral, realizando también una intervención a nivel MAC. En este sentido, la QoS en WiFi queda incorporada en el modo EDCA a partir de la aparición del estándar 802.11e, que establece a nivel MAC 4 colas y distintos parámetros configurables para cada una (tamaño de ventana máximo, mínimo, oportunidad de transmisión y espacio de tiempo arbitrario entre tramas):

• AC_VO

cola de máxima prioridad, pensada para flujos que necesiten unos requisitos máximos de QoS, como por ejemplo, una conversación de VoIP.

• AC_VI

cola de prioridad alta, pensada para flujos que tienen ciertos requisitos de QoS como por ejemplo en materia de jitter, pero menos restrictivos que la cola anterior

• AC_BE

cola de best effort, pensada para flujos sin requerimientos específicos de QoS a los que hacer el mayor esfuerzo posible por que sea entregado, pero sin un requerimiento específico

• AC_BK

cola de background, pensada para el tráfico de fondo de un enlace con la menor prioridad.

Conocidos estos principios de QoS sobre Linux, para el proyecto AROMA es necesario establecer qué tipos de servicios van a estar presentes en la red, y por tanto, qué prioridades será necesario establecer sobre el tráfico tanto a nivel IP como a nivel MAC.

Inicialmente los servicios que se pretenden ofrecer sobre la red serán los de:

• Comunicación de voz y datos entre operarios de mantenimiento y la central de REE. • Comunicación de vídeo desde las cámaras de video-vigilancia hacia la central de REE si se

detecta presencia en las torres. • Información de sensado de diferentes aspectos. • Comunicaciones de administración y gestión de alta prioridad.

Desglosados, estos servicios se desgranan en las siguientes posibilidades:

• VoIP: las comunicaciones de los operarios de mantenimiento son exclusivamente de voz y no requieren, en lo que a respeto de frecuencias de la voz se refiere, de ninguna calidad especial más allá de una calidad telefónica mínima. Por ello, se puede emplear una codificación para la comunicación con pérdidas y baja tasa, pues nos es muy preciado el recurso del caudal. Los requisitos de la VoIP serán los de mayor QoS de todos, pues se requiere un canuto de comunicación con bajo jitter (<100ms), bajo retardo (<150ms), no excesivas pérdidas de paquetes, y muy poco caudal, pero constante. Algunas posibilidades,

entre los codecs más empleados, son: • Speex: 2.15-24.6kbps de caudal; 30ms de retardo adicional. • G.711-u/alaw: 64kbps de caudal; 0ms de retardo adicional. • GSM: 8kbps de caudal; 22.5ms de retardo adicional. • G.726: 8kbps de caudal; 0ms de retardo adicional.

• Video-streaming: el video-streaming, es un servicio adicional que brindará el sistema con el objeto de poder establecer un sistema de video-vigilancia con detección de movimiento. De cara al tipo de servicio que se pretende definir, nos interesa conocer qué tipo de video-vigilancia se pretende realizar (si se desea poder reaccionar frente a un robo mediante alertas al servicio de seguridad, si se pretende dejar constancia grabada del robo, si se quiere poder monitorizar remotamente el vídeo capturado, etc). Es necesario tener en cuenta multitud de parámetros adicionales que se discutirán en el apartado dedicado a este servicio. En lo que al tipo de servicio se refiere veremos que algunas posibilidades son:

• Transmisión contínua de vídeo en tiempo real: Este tipo de servicio, que desaconsejamos fuertemente, tiene el objeto de poder llevar la imágen a un servidor de vídeo centralizado que pueda realizar tareas pesadas como el procesamiento de la imágen para la detección automática de patrones y generación de alertas específicas. Con este esquema el caudal transmitido puede llegar a ser muy elevado, reduciendo enormemente los límites físicos del sistema (el tráfico agregado en una red lineal haría que en sólo unos pocos saltos se alcanzara el límite de caudal disponible en la red). Aparte de ésto, este tipo de servicio demandaría unos muy elevados requisitos de QoS en materia también de jitter y retardo que, en situaciones de saturación, se haría muy difícil de cumplir y que, atendiendo al sentido común, en la mayor parte de las situaciones nos llevaría a la situación de estar limitando los recursos del sistema para conseguir transmitir un vídeo irrelevante (pues únicamente nos interesará el vídeo asociado a los eventos que queramos monitorizar). Es posible también que no requiramos de vídeo, sino que únicamente con la captura de unos pocos frames por segundo nos sea suficiente para nuestras necesidades.

• Transmisión bajo demanda o en reacción a eventos de vídeo en tiempo real: Si bien en el momento de la transmisión de vídeo con este esquema tendríamos los mismos requerimientos de los que hablábamos antes, la transmisión frente a eventos o bajo demanda reduce enormemente la carga de la red así como el consumo eléctrico. Igualmente, con este esquema de funcionamiento, los límites del sistema no se verían grávemente afectados, pues no es probable el escenario en que todos los sistemas estuviesen transmitiendo simultáneamente, sino que cada sistema estaría la mayor parte del tiempo comprobando la imágen y únicamente cuando detectara determinados patrones o variaciones entre frames comenzaría la transmisión. Asímismo, se permitiría la opción de que un cliente pudiera conectarse a las cámaras de un apoyo para verificar su funcionamiento o visibilidad.

• Transmisión contínua de capturas en tiempo real: la única diferencia que existe es el número de frames por segundo que se transmite. Podemos considerar vídeo un nivel de 15 capturas de imágen por segundo, lo que en el plano del software tiene poca relevancia, pero mucha en el plano de red, pues supone mayor o menor carga y mayores restricciones de QoS.

• Transmisión bajo demanda o en reacción a eventos de capturas en tiempo real: se trata del tipo de servicio que mejor encaja en un esquema de funcionamiento en zona aislada con limitaciones de potencia disponible como el que tenemos. El motivo es que no requiere de un gran caudal, retardo ni jitter específicos y cumple la función para la que es requerido, capturar imágenes cada cierto tiempo cuando se produzca un evento. El caudal introducido a la red es muy inferior a los casos anteriores y

permite tener muy poco impacto sobre los límites del sistema y la planificación de la red.

Debido a que el vídeo será capturado desde una altura considerable que sólo es posible alcanzar utilizando la propia estructura de los apoyos y a que el sistema tiene otras prioridades mayores que la transmisión contínua de vídeo del que sólo será de relevancia en determinados momentos pequeñas porciones de él, y a que la percepción de movimiento (superar las 15 capturas por segundo) no es una necesidad para cumplir el fin de la video-vigilancia de los apoyos, se recomienda emplear la transmisión bajo demanda o en reacción a eventos de capturas en tiempo real, activadas además las cámaras sólo cuando se produzca un evento en un sensor de intrusión, de forma que mientras el sensor no detecte presencia y no se exija por parte de un administrador remoto la cámara estará apagada, reduciendo el consumo (hay que tener en cuenta que para una cierta precisión en la video-vigilancia, 2 cámaras ubicadas en un apoyo tendrían un consumo del mismo orden de magnitud que un empotrado, 5W aprox.). Definamos una tasa de capturas de 2 por segundo y una resolución de cámara (en digital) de 720x540 píxeles (si empleamos una cámara CCD 1/3'' de 540 líneas), es decir, 388800 píxeles para codificar cada 500ms, o lo que es lo mismo, 777600 píxeles por segundo. Lo recibido por la cámara es traducido por un capturador a PAL (720x576 píxeles @ 25 capturas por segundo) y enviado a un empotrado (que se recomienda no sea responsable de tareas de red, pues el procesado de la imágen en sí tiene un coste computacional fuerte). Este empotrado, conectado por ethernet a los otros 2 presentes en el apoyo se responsabilizaría de examinar la imágen cuando el sensor de presencia estuviera activo, detectar movimiento y en caso de haberlo producir una salida de vídeo hacia la central de REE asumible por la red. La codificación de h.264 es posible y versátil utilizando las bibliotecas de GNU/Linux libavcodec y x264 con licencias GPL y LGPL, empleadas por el potente software VLC [37] de linux. Éste en combinación con motion (detector de movimiento y grabación en consecuencia) [38] junto con unos tantos scripts que gestionen la tarea pueden convertir el empotrado en un detector de presencia con transmisión de capturas a baja tasa y video-streaming bajo demanda. Así pues, definamos un máximo caudal reservado para el envío de las capturas de las 2 cámaras de un apoyo (que estará directamente ligado a la resolución de las mismas) en 1Mbps sin requerimientos específicos de retardo (dado que la reacción frente a las imágenes no estará en el orden de magnitud de los milisegundos o incluso de los segundos, el retardo no es relevante aquí), con un jitter tampoco relevante (la percepción final de un jitter elevado es de cortes en el visionado o audición, lo que no tiene sentido pretender evitar con un nivel de 2 capturas por segundo donde la percepción de vídeo no existe). No obstante, pese a no tener los requisitos típicos de una aplicación de tiempo real, sí que es importante la entrega de todas las tramas, por lo que la pérdida de paquetes deberá minimizarse. En este sentido se tratará de excluir a este tráfico de cualquier política de descarte. Si quisiéramos aprovechar toda la potencialidad de la resolución de una cámara como la arriba citada, se podría aumentar la reserva por cámara, pero en este caso tendrían que redefinirse los límites del sistema (reduciendo el número de saltos hasta los que se puede garantizar QoS) o las premisas de partida (aumentando la distancia mínima entre transmisiones simultáneas). Otra opción podría ser hacer al sistema adaptativo de forma que la detección de un umbral de saturación de la cola de salida del interfaz que sirve el tráfico de vídeo provocara hacia atrás una alerta que hiciese reducir la calidad con que el vídeo de cada cámara es transcodificado o la periodicidad de las capturas que son transmitidas por éstos.

• Tráfico de administración/gestión: el tráfico propio del sistema de gestión de red empleado y de la administración remota de los equipos es un tráfico que frecuentemente no tiene requerimientos especiales en términos de retardo o jitter y requiere un caudal realmente reducido. Sin embargo, para garantizar la posibilidad de reaccionar frente a esquemas de saturación y reaccionar en consecuencia o poder administrar en estas situaciones remotamente los sistemas (mediante un terminal remoto) es buena práctica dar a este tipo de tráfico (SNMP y SSH) unas mínimas garantías de prioridad sobre el tráfico best effort que, sin embargo, no entorpezca las comunicaciones de tiempo real (menor prioridad que las

comunicacinoes VoIP o video-streaming). • Tráfico de sensado: El sensado del entorno de los apoyos o situaciones • Resto del tráfico: Todo el tráfico que no entre en las anteriores clasificaciones seguirá una

política de entrega "best effort", por la que sólo será cursado en el próximo enlace mientras que su tramitación no incurra en una violación de los requerimientos de QoS de alguna otra clase. Podrá ser descartado, retardado o ajustado a los requerimientos de cada situación.

Por todo lo anterior podemos definir que cada apoyo tiene potencialmente la capacidad de inyectar en la red un tráfico de...

1 conversación bidireccional de VoIP sobre codec Speex (no se considera un escenario de más de un operario hablando simultáneamente con varios destinos diferentes) + 2 transmisiones de 2 capturas por segundo empleando una resolución de 540 líneas traducidas a PAL@25fps (720x576 píxeles) y a su vez transcodificadas en el empotrado con h.264 sin audio (se consideran 2 cámaras tipo [36] por apoyo ubicadas en 2 vértices opuestos de su sección horizontal, enfocadas hacia abajo y conectadas a tarjetas capturadoras de vídeo USB a su vez conectadas a la placa de empotrados para la completa vigilancia del mismo, y en caso de detección de movimiento en ambas cámaras se contempla que puedan estar transmitiendo simultáneamente) + tráfico de gestión SNMP + tráfico de sesión remota SSH + tráfico best effort (por ejemplo, correo electrónico, web o transferencia de ficheros).

El orden de prioridad con la que el tráfico debiera cursarse en la red sería:

1. Tráfico VoIP. 2. Tráfico de video-vigilancia. 3. Tráfico de administración/gestión. 4. Tráfico best effort.

Las precondiciones que asumiremos para que el grado de servicio sea respetado (será poco probable que se envíen simultáneamente operarios a todos los apoyos contíguos mientras estos mismos apoyos detectan movimiento en ambas cámaras y un administrador abre simultáneamente sesiones remotas en todos esos apoyos) serán:

• Se contemplará que la mayor cercanía en saltos de red entre intervenciones de operarios de mantenimiento de REE será de 1 equipo cada 20 saltos (si tenemos en cuenta 500m por vano, ésto supone una separación máxima de 10 kilómetros entre equipos).

• Ya que las cámaras de los apoyos detectarán el movimiento de los operarios se contemplará detección de 2 cámaras cada 20 saltos y la posibilidad de que otras 2 cámaras en esos 20 saltos estén también detectando movimiento debido a algún intento de robo o falsa alarma, en suma, 4 flujos de vídeo por cada 20 saltos.

• Simultáneamente en la red contemplaremos la posibilidad de que un administrador abra una sesión de terminal remoto hacia cada salto de la red, generando en el enlace más cercano a la pasarela de entrada/salida de la red WiFi el tráfico agregado que resulta de multiplicar un flujo por el número de saltos total de la red que atraviese esa pasarela.

Así pues, salvando el tráfico best effort, cada enlace punto a punto debiera ser capaz de agregar con garantías un caudal de...

24,6kbps (máxima tasa de codec VoIP Speex) * 2 + (2000/20) kbps (vídeo) + 25kbps (administración/gestión) = 174,2 kbps

Si tenemos en cuenta que el balance de potencia de cada enlace se ha ajustado para permitir el funcionamiento de WiFi a su tasa de 54Mbps (en capa MAC), que supone un caudal disponible aproximado de 37Mbps en nivel de Aplicación, podemos establecer que con una disposición de red lineal donde cada apoyo constituye un nodo retransmisor el límite total de saltos en que puede garantizarse al 100% la QoS será de 37000 [kbps]/174,2 [kbps/salto] = 212 saltos. Para

tener en cuenta los efectos sobre el caudal de cada retrasmisión debido a interferencias entre radios, antenas, buffers intermedios, etc, aplicaremos una caída de caudal típica que la Fundación EHAS ha comprobado empíricamente en sus redes rurales aisladas de alrededor de 200kbps por salto, reduciendo el número de saltos posibles a 37000/374,2 = 98 saltos, o expresado en términos de distancia (tomando la distancia media entre apoyos de 500m), la máxima longitud. No obstante, dada la poca probabilidad de que este caso peor suceda (es poco probable que se envíen simultáneamente operarios a todos los apoyos contíguos mientras estos mismos apoyos detectan movimiento en ambas cámaras y un administrador abre simultáneamente sesiones remotas en todos esos apoyos), será posible respetar al 100% las garantías de QoS de todo el tráfico generado bajo las pre-condiciones citadas anteriormente para una red lineal entre apoyos conectados punto a punto sin saltos de más de un apoyo y con una única salida de hasta 49 kilómetros.

No obstante, existirían formas de aumentar el alcance de estas garantías de QoS:

• Si un apoyo A tiene visibilidad con otro apoyo B no contíguo y todos los apoyos intermedios tienen visibilidad con A o B, entonces A y B pueden crear sendas redes punto a multipunto hacia los apoyos intermedios creando un enlace troncal más largo. La ventaja de ésto es que los se eliminan gran parte de las pérdidas por multisalto, aumentando el radio de acción. Además, debido a que los nodos STA de las redes punto a multipunto no tendrían que realizar trabajo de enrutado podrían permanecer más tiempo apagados ahorrando mucho consumo y, por tanto, permitiendo un dimensionamiento solar más barato.

• Ablandando las restricciones de QoS, por ejemplo asumiendo que no puedan existir falsas alarmas en la detección de las cámaras o que un administrador no podrá estar conectado a más de un porcentaje de los nodos de una red que comparte salida única

• En los casos en que la línea de apoyos se subdivida en varias y que más de una tenga disponibilidad de salida hacia internet o la red privada de REE, entonces el tráfico podrá balancearse entre los enlaces.

• Estableciendo dos enlaces entre cada par de apoyos que permitan balancear la carga entre las interfaces y doblar la capacidad del enlace (conocido como WiFi bonding tiene el problema de aumentar también el consumo, pues a mayor número de radios WiFi, mayor consumo y, por tanto, mayor coste económico de la solución y tiene también la ventaja de agregar robustez a los enlaces).

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

Dado que uno de los requisitos fundamentales del sistema es un consumo reducido, es razonable el uso de tarjetas inalámbricas mini PCI de baja potencia. Entre las existentes en el mercado podemos destacar las tarjetas mini PCI CM9-GP de Wistron. Estas tarjetas funcionan para los modos 802.11a, b y g. El modo 802.11 a a 5 GHz es el que nos va a interesar. En modo 802.11a en Europa soportan 19 canales no superpuestos entre 5,15 y 5,35 Ghz y entre 5,47 y 5,725 Ghz. Proporcionan una potencia de transmisión máxima en modo 802.11a de 13 dBm si la velocidad es de 54 Mbps y de 17 dBm si es de 6 Mbps. Presentan una sensibilidad en modo 802.11a de -71 dBm a 54 Mbps, de -73 dBm a 48 Mbps, de -75 dBm a 36 Mbps, de -80 dBm a 24 Mbps, -83 dBm a 18 Mbps, de -85 dBm a 12 Mbps, de -87 dBm a 9 Mbps y de -88 dBm a 6 Mbps. Proporcionan la posibilidad de utilizar Wake-on-Wlan, explicado anteriormente, que permite reducir el consumo. Su consumo depende del estado en el que se encuentren, para el modo 802.11a, si se encuentran transmitiendo el consumo máximo es de 420 mA, recibiendo de 300 mA, en modo standby de 260 mA, en modo ahorro de energía de 50 mA y en modo RF Kill 40 mA.

Tarjeta mini PCI CM9-GP

Debido a que no hay grandes distancias entre routers consecutivos, no vamos a necesitar antenas de una gran directividad como pudieran ser las parabólicas etc... pero si nos interesan antenas de directividad moderada como por ejemplo las tipo panel o "patch antenna", de manera que podamos reducir la potencia de transmisión de las tarjetas inalámbricas y con ello el consumo de las mismas. Un ejemplo de este tipo de antenas es la LBW-523 de LANBOWAN, con una ganancia de 23 dBi. Esta antena dispone además de una caja exterior resistente a la intemperie.

Antena LBW-523 de 5 Ghz

Dado que la PIRE máxima permitida es de 30 dBm utilizando esa antena o una similar podríamos bajar el consumo hasta 7 dBm y aún seguiríamos teniendo la PIRE máxima permitida.

Para calcular el balance energético del enlace podemos servirnos de la siguiente fórmula que permite calcular el balance de potencia en un radioenlace formado por un sistema transmisor y un sistema receptor separados una distancia determinada.

Pr= Ptx + Gtx + Gr - Pprop - Margen (1)

De esta fórmula se obtiene que la potencia recibida es la potencia transmitida más la ganancia de las antenas transmisora y receptora menos las pérdidas de propagación y menos un margen que se utiliza ya que puede haber variaciones en los valores calculados y además para incluir otros tipos de pérdidas que no se han tenido en cuenta como pueden ser :

• Pérdidas de desapuntamiento, si las antenas no están orientadas en la dirección que presenta su máxima ganancia.

• Pérdidas de desadaptación, si la antena transmisora y la receptora no están correctamente adaptadas al generador y al receptor respectivamente.

• Pérdidas por desajuste de polarización, si el estado de polarización de la antena transmisora y receptora no es el mismo.

• Pérdidas en los conductores...

La mejor aproximación para la calcular las pérdidas de propagación suele obtenerse con los llamados modelos semi-deterministas o modelos de terreno irregular entre los que destaca el modelo Longley-Rice. Este es un método para predecir la atenuación de señales de radio en un enlace de telecomunicación, en el rango de frecuencias entre 20 MHz y 20 GHz. No obstante, para una aproximación general a las pérdidas de propagación en enlaces con línea de vista, puede utilizarse el modelo de propagación en espacio libre, teniendo en cuenta que los resultados serán ligeramente diferentes según el efecto del medio y el terreno.

Para calcular las pérdidas de propagación en espacio libre tenemos que tener en cuenta dos valores que son la distancia entre el emisor y el receptor y la frecuencia de transmisión. La fórmula para calcular estas pérdidas es la siguiente:

Pprop(db)=32,4 + 20*log d (km) + 20*log f (Mhz) (2)

Como se ha indicado en el apartado A1.2, la distancia media es de unos 450 m, pero en casos excepcionales puede llegar a los 2 km. Para elegir la frecuencia de transmisión debemos elegir un canal entre 5,15 y 5,35 Ghz o entre 5,47 y 5,725 Ghz. Por ejemplo el canal 120 a 5600 Mhz.

Si calculamos las pérdidas de propagación con esos valores para la distancia media (450 m), el resultado es de 100,428 dB Si calculamos las pérdidas de propagación con esos valores para la distancia máxima (2 km), el resultado es de 113,384 dB

Suponemos que utilizamos el enlace a la velocidad máxima permitida es decir, 54 Mbps, la potencia máxima de transmisión es de 13 dBm y la sensibilidad de -71 dBm.

Si aplicamos la fórmula (1) utilizando como distancia la distancia media, y aquella potencia de transmisión para la cual la PIRE es la máxima permitida, es decir 30 dBm, y un margen de 10 dB obtenemos una potencia recibida de -57,428 dBm que es considerablemente mayor a la sensibilidad, y por tanto considerablemente mayor a la señal mínima que el sistema es capaz de recibir.

Si utilizamos en el mismo cálculo la distancia máxima, obtenemos una potencia recibida de -70,384 que aunque cerca del límite, también es superior a la sensibilidad. Por lo tanto utilizando la potencia máxima permitida (que es inferior a la máxima que podríamos obtener con nuestro sistema), no tendríamos límites físicos de distancia en cuanto a las pérdidas de propagación.

Para calcular la potencia mínima necesaria del transmisor para que se reciba señal en el receptor

para los casos de distancia media y distancia máxima, igualamos en la fórmula (1) la potencia recibida a la sensibilidad, usando como valor de ganancia de las antenas 23 dBi. Para el caso de distancia media, obtenemos una potencia mínima de -6,572 dBm y por tanto una PIRE de 16,428 dBm. Para el caso de distancia máxima, obtenemos una potencia mínima de 6,384 dBm y por tanto una PIRE de 29,384 dBm.

• Dimensionado solar • Dimensionado del panel

Para realizar el dimensionamiento solar vamos a utilizar el método basado en el mes peor, que consiste en conseguir que el sistema de alimentación suministre la energía suficiente a la cargas durante el mes en el que la irradiación solar en los paneles presente un menor valor. En España ese mes es Diciembre y el ángulo de inclinación del panel que hace que la irradiación en Diciembre sea la mayor posible es aproximadamente 60º(?), unos 20º más que la latitud. En el siguiente mapa podemos observar la distribución de la irradiación global media diaria en España en Diciembre del 2006. Tomaremos el valor de Soria: 1,81 Kwh/m2 que puede considerarse un valor medio. De todas maneras a la hora de dimensionar concretamente para cada zona habrá que tomar el valor concreto de la región, ya que como puede observarse, hay variaciones importantes de unas zonas a otras.

Irradiación global media diaria en España Diciembre 2006

Para realizar un correcto dimensionado es necesario estimar la energía diaria que se ha de suministrar a la carga. En este caso tenemos que tener en cuenta el consumo de la placa y de las tarjetas inalámbricas.

Teniendo en cuenta los datos aportados en el apartado 1.1, vamos a considerar que la placa en reposo consume 4 W. De las especificaciones de la tarjeta inálambrica obtenemos que utiliza una

tensión de 3,3 V +/- 5% y que para 802.11a según el estado en el que se encuentre tiene el siguiente consumo: FTP Tx 420mA

FTP Rx 300mA

Standby mode 260mA

Power saving mode 50mA

RF Kill 40mA

Vamos a realizar el cálculo para el caso peor, es decir que la tarjeta esté 24 horas al día activa, 12 horas transmitiendo y 12 recibiendo. Con estos datos obtenemos que transmitiendo consume 1,4553 W, con lo que al día consumirá 17,4636 W. Recibiendo consume 1,0395, con lo que al día consumirá 12,474 W. En total el consumo diario de la tarjeta será de 29,9376 W-h. El consumo total de la placa más tarjeta será de 125,9376 W-h.

También tenemos que tener en cuenta la eficiencia del panel, suelen considerarse valores entre el 10 y el 15%.

Se asumirá un factor de corrección de 1.2 (generar al menos un 20% más de lo que se consumiría)

• Dimensionado de la batería

Para realizar el dimensionado del sistema de almacenamiento, es decir de la batería hay que tener en cuenta los siguientes criterios:

• Energía que necesita la carga en un día • Días de autonomía (N), es decir días en los que el sistema debe operar bajo una irradiación

mínima (días nublados contínuos), en los cuales se va a consumir más energía de la que el sistema es capaz de producir. En este momento vamos a considerar 4 días, ya que se considera un valor típico en el dimensionado de sistemas aútonomos solares.

• Profundidad de descarga diaría de la batería (Pdmax), esta profundidad no debería superar el 80%, ya que la eficiencia de la batería decrece en gran medida con ciclos de carga-descarga profundos.

La capacidad (en W-h) de las baterías debe ser suficiente como para entregar a la carga la energía necesaria cada día, por el numero de días de autonomía deseado, y teniendo en cuenta que las baterías sólo se descargarán al 80% de su capacidad total tras esos cuatro días.

C (W-h)= total W-h/ día * N * Pdmax

De aquí obtenemos que la capacidad de la batería debe ser 629,688 W-h

Referencias [1] J. Simó, A. Martínez, P. Osuna, S. Lafuente, J. Seoane. The design of a Wireless Solar-Powered Router for Rural Environments Isolated from Health Facilities. IEEE Wireless Communications. Junio 2008.

[2] http://developer.ubicom.com/documents/ubicom/distro/sdk_help_full.html

[3] http://free-electrons.com/docs/

[4] http://www.imedialinux.com/

[5] http://www.dd-wrt.com/site/index

[6] http://www.fli4l.de/

[7] http://www.openwrt.org/

[8] http://linux.voyage.hk/

[9] http://www.zeroshell.net/eng/

[10] http://www.soekris.com/index.htm

[11] http://www.pcengines.ch/index.htm

[12] http://www.mikrotik.com/

[13] http://www.ubnt.com/

[14] http://www.embeddedarm.com/products/board-detail.php?product=TS-7800

[15] http://www.uclinux.org/

[16] http://www.tti-test.com/products-tti/pdf-brochure/prec-1906-4p.pdf

[17] http://sites.google.com/site/prologix2/home

[18] http://prologix.biz/

[19] http://allan.88-mph.net/blog/entry/multimeter-recordings-with-the-prologix-gpib-usb-controller/

[20] Nilesh Nishra et al. Wake-On-WLAN

[21] Amit P. Jardosh et al. Green WLAN: On-Demand WLAN Infrastructures

[22] http://www.green-wifi.org/

[23]http://pdos.csail.mit.edu/roofnet/doku.php

[24]http://www.green-wifi.org/solutions/technology/

[25] http://wiki.personaltelco.net/NetgearWgt634u

[26] http://www.linksysbycisco.com/US/en/products/WRT54GL

[27] http://www.powerupco.com/panels/shell/Shell%20ST10.pdf

[28] http://tier.cs.berkeley.edu/wiki/Home

[29] Sonesh Surana, Rabin Patra, Sergiu Nedevschi and Eric Brewer. Deploying a Rural Wireless Telemedicine System: Experiences in Sustainability. IEEE Computer. Volume 41, Number 6, pp. 48-56, June 2008

[30] http://www4.usp.br/

[31] http://meraki.com/

[32] http://meraki.com/products_services/access_points/solar_overview/

[33] Pablo Martín Muñoz. Radiointerferencia emitida por efecto corona en líneas aéreas de alta tensión. Revista Electricidad. Número 36. Enero 2009

[34] J. I. Huertas, R. Barraza. J. M. Echeverry. Wireless Data Transmission from Inside Electromagnetic Fields. Automotive Engineering Research Center- CIMA, ITESM

[35] http://lartc.org/

[36] http://www.seguridadplus.com/camara_color_exterior_sensor_1538_1.htm

[37] http://www.videolan.org/vlc/

[38] http://www.lavrsen.dk/foswiki/bin/view/Motion/WebHome