Análisis de las prestaciones de e en redes MANET

Transcripción

1 Análisis de las prestaciones de e en redes MANET María Murazzo 1*, Nelson Rodríguez 2*, Daniela Villafañe 3* 1 marite@unsj-cuim.edu.ar, 2 nelson@iinfo.unsj.edu.ar, 3 villafañe.unsj@gmail.com * Docentes e Investigadores, Departamento e Instituto de Informática FCEFyN - UNSJ Abstract. El desarrollo de las redes de comunicaciones móviles y sus servicios, ha supuesto un gran esfuerzo científico y técnico para dotar de mecanismos capaces de garantizar QoS (Quality of Service) 1 a los usuarios. En el caso de las redes móviles ad-hoc (MANET), este esfuerzo es relevante debido a la complejidad y dinamicidad del entorno. Por lo cual, para proporcionar QoS en estas redes, es importante garantizar los requerimientos necesarios y gestionar eficientemente los recursos disponibles. Con el objeto de proporcionar la calidad demandada por las actuales aplicaciones, han surgido propuestas que abordan la problemática de la QoS en diferentes capas. Este trabajo aborda la problemática de la provisión de QoS en redes MANET desde la perspectiva de la subcapa MAC, mediante la implementación de e, para analizar el retardo y la sobrecarga que sufren las transmisiones en ambientes con baja y alta granularidad de nodos. Keywords: MANET, QoS, e, NS2, CBR 1 Introducción Una red móvil ad hoc (MANET) es una red de comunicaciones formada espontáneamente por un conjunto de dispositivos móviles inalámbricos capaces de comunicarse entre sí, sin la necesidad de una infraestructura de red fija o gestión administrativa centralizada. Estas redes nacen bajo el concepto de autonomía e independencia, al no requerir el uso de infraestructura pre-existente ni una administración centralizada como las redes cableadas. Debido a que el alcance de transmisión de los dispositivos es limitado, pueden llegar a ser necesarios nodos intermedios para transferir datos de un nodo a otro. Por ello, en una red MANET cada nodo puede operar como fuente, destino o router (naturaleza multihop ). 1 En español, calidad de servicio. ISBN

2 En estas redes, los nodos son libres para moverse arbitrariamente, produciendo cambios en la topología de la red. El grado de movilidad y cambio de la topología depende de las características de los nodos. Las variaciones en el canal de radio y las limitaciones de energía de los nodos pueden producir cambios en la topología y en la conectividad.por lo que, las MANET deben adaptarse dinámicamente para ser capaces de mantener las conexiones activas a pesar de estos cambios [1]. 2 QoS en Redes MANET Las actuales redes de telecomunicación, y principalmente las MANET, se caracterizan por un constante incremento del número, complejidad y heterogeneidad de los recursos que las componen. Esta heterogeneidad, se pone aun más de manifiesto según el tipo de aplicaciones que se ejecutan. En la actualidad, la mayoría del tráfico de red es generado por aplicaciones de tipo multimedial o con fuertes restricciones en cuanto a la cantidad de recursos que demandan de la red. El tráfico multimedia, como el utilizado en telefonía IP o videoconferencia, puede ser extremadamente sensible a los retardos y puede crear demandas de QoS muy restrictivas sobre las redes que los transportan. Cuando los paquetes son entregados usando el modelo de mejor esfuerzo, estos no arriban en una manera oportuna. El resultado son imágenes no claras, desiguales, movimientos lentos, y el sonido no se lo obtiene sincronizado con la imagen. Los aspectos críticos que causan la mayor parte de los problemas en aplicaciones con grandes restricciones de recursos son: falta de ancho de banda, retardo extremo a extremo y pérdida de paquetes. Respecto a la falta de ancho de banda, la mejor opción para contrarrestarlo, es clasificar el tráfico dentro de clases de QoS y priorizar tráfico de acuerdo a la importancia del mismo. El retardo extremo a extremo, se puede disminuir dándole a los paquetes pertenecientes a aplicaciones sensitivas, cierta prioridad para que en el camino extremo a extremo sean tratados de manera más ágil. Por último, y en relación a la perdida de paquetes, estos pueden ser descartados cuando un enlace está congestionado. Un paliativo para esta problemática es un esquema de scheduler de tráfico que permita proporcionar un mejor servicio a paquetes pertenecientes a aplicaciones sensibles [2]. La QoS, es un término usado para definir la capacidad de una red para proveer diferentes niveles de servicio a los distintos tipos de tráfico. Permite que los administradores de una red puedan asignar a un determinado tráfico prioridad sobre otro y, de esta forma, garantizar que un mínimo nivel de servicio le será provisto. Aplicando técnicas de QoS se puede proveer un servicio más acorde al tipo de tráfico y de esta manera permitir: priorizar ciertas aplicaciones de nivel crítico en la red, maximizar el uso de la infraestructura de la red, proveer una mejor performance a aplicaciones sensitivas al delay como son las de voz y video y responder a cambios en los flujos del tráfico de red. ISBN

3 Al aplicar técnicas de QoS, el administrador de la red puede tener control sobre los diferentes parámetros que definen las características de un tráfico en particular (retardo extremo a extremo, latencia, variaciones de latencia, perdida de paquetes, ancho de banda). El problema de la administración de QoS, está prácticamente resuelto en redes fijas, pero esto no sucede en redes inalámbricas y específicamente en redes MANET cuyas características hacen necesario un nuevo estudio para afrontar este problema. La topología dinámica, la naturaleza multihop y los escasos recursos de los nodos hacen necesario que los mecanismos de provisión de QoS sean lo más ligeros posibles, en cuanto a carga de procesamiento, como de recursos de red (ancho de banda), para evitar que el throughput o capacidad disponible por nodo se reduzca drásticamente [3]. De todo lo enunciado se puede llegar a la conclusión que la única manera de poder lograr la coexistencia de aplicaciones con diferentes niveles de requerimientos de recursos es realizando una adecuada administración del trafico mediante la priorización implícita o explícita de los paquetes de datos. La priorización de tráfico, permitirá que ciertos flujos de datos puedan ser tratados de forma preferencial logrando maximizar el uso del ancho de banda, minimizar el retardo extremo a extremo y minimizar la perdida de paquetes. Esta priorización se logra mediante la implementación de mecanismos de QoS que permita una gestión de los flujos de tráfico [4]. Existen diversas formas de proveer mecanismos de QoS a las redes: ruteo con QoS, señalización de QoS y MAC (Medium Access Control) con QoS. De todas estas opciones en este trabajo se seleccionó el análisis del impacto de la implementación de mecanismos de QoS en la capa MAC mediante el uso del estándar e. 2.1 QoS en Capa MAC Las características de movilidad de los nodos que pertenecen a una red MANET hacen muy difícil la administración de QoS en los niveles de red. Dicha movilidad produce una sobrecarga excesiva, lo cual produce un empeoramiento en la eficiencia de la red. El estándar e no congestiona la red con paquetes de señalización, ni con paquetes de descubrimiento de rutas, sino que plantea una forma de administración general, la cual se basa en los tiempos de espera. El que tiene mayor prioridad de transmisión es el que menos tiempo debe esperar. Esto hace, que no sea necesario inundar la red con paquetes, pues cada nodo por separado sabrá si tiene que transmitir o no de acuerdo al tiempo que tenga que esperar, de este modo cada nodo transmite de forma independiente, lo cual evita la necesidad de sincronizarse con los demás nodos para reservar recursos y asignar prioridades de forma conjunta. Otra diferencia importante es que se provee QoS a los paquetes o flujos de datos y no a los nodos que están transmitiendo, a diferencia del ruteo QoS el cual se encarga de hacer reserva de recursos de acuerdo a las capacidades de los nodos; por esta razón con e no hay necesidad de sincronizarse con los nodos de la ruta seleccionada. Por otra parte, al ser ISBN

4 tan dinámica, las MANET tienen caídas de enlaces muy frecuentemente, lo cual hace que se deban realizar procesos de retransmisión. Dichos procesos en el estándar e se realizan ejecutando algoritmos de backoff sin la necesidad de reenvíos de paquetes de manera global [5]. 3 Escenarios de trabajo Para poder analizar el comportamiento de las redes MANET con respecto a la implementación del estándar e que provee QoS, fue necesario el uso de un simulador de redes. La herramienta de simulación usada fue Network Simulator 2 (NS-2) versión 2.28, con el parche de e [6]. Se estudiaron dos parámetros en las transmisiones para el estudio de QoS en los ambientes MANET, el retardo extremo a extremo y la sobrecarga. Respecto a los escenarios de simulación, se trabajaron con cuatro escenarios de 20y 100 nodos, esta variación en la granularidad de los escenarios permitió el análisis del impacto de los distintos niveles de sobrecarga de paquetes de ruteo. La cantidad de transmisiones en las simulaciones es proporcional a la cantidad de nodos. Se usó la relación de n/2 cantidad de transmisiones activas, donde n es la cantidad de nodos que se crearon. De esta forma, y siempre que n sea un número par todos los nodos estarán involucrados en al menos un flujo de datos punto a punto. Con respecto a las transmisiones, se consideraron dos tipos. El primer tipo de transmisión es de voz 64 Kb/s, este flujo de datos está destinado a los nodos con mayor prioridad (nodos cero y n-1). Este flujo de datos se marcará con un ID particular para poder ubicarlo en los archivos resultantes de la simulación. Para el segundo tipo de transmisiones, se consideró que el resto de los nodos corriera una aplicación del tipo CBR de video (Constant Bit Rate Tasa de bits constantes) de 4Mbits/s. El protocolo de ruteo seleccionado para realizar las simulaciones es AODV (Adhoc On-demand Distance Vector Routing) debido a que el retardo que se produce por el rearmado de las tablas de ruteo tiende a estabilizarse cuando la granularidad de la red es alta (superior a los 10 y 15 nodos) [7], lo cual es propicio para los escenarios que se manejan en las simulaciones Las simulaciones se realizaron durante 2000 segundos sobre dos modelos de movilidad; RWPM (Random Waypoint Mobility Model) y RWKM (Random Walk Mobility Model) [8]. En cuanto a las aplicaciones, la transmisión de voz, marcada con un ID especial, comienza a ejecutarse en el segundo 1.0 (el nodo 0 comienza la transmisión de datos) y se detiene 5 segundos antes de que el tiempo de simulación llegue al final. Con las demás transmisiones el mecanismo es el siguiente: se toma el número de nodo que tiene la tarea de enviar datos (dicho número está entre los números (1, n/2-1)) y a ese número se le suman 5.0 segundos. El resultado de esa operación indica el momento dentro de la simulación en que el nodo comenzará a transmitir. Al igual que la ISBN

5 transmisión marcada, las demás finalizan 5 segundos antes que el tiempo de simulación llegue a su fin. 4 Resultados Obtenidos A continuación se muestran los resultados de las simulaciones, donde se evalúa el impacto de la implementación de e en el retardo extremo a extremo y la sobrecarga de paquetes de ruteo, también se analiza el comportamiento de esta implementación en escenarios con 20 y 100 nodos para evaluar si la granularidad posee efectos en el desempeño de la red. 4.1 Análisis del retardo La Figura 1 muestra que el retardo es mucho menor cuando se aplica QoS a través de e. El retardo promedio sin QoS es de 10,50 segundos (±7,50 segundos), mientras que en el caso de una red con QoS se registra un promedio de 0,010 segundos (± 0,014 segundos). Los valores registrados cuando no se aplica QoS son muy dispares durante toda la simulación. Figura 1: Retardo con 20 Nodos, con RWKM La Figura 2 muestra los resultados cuando el tipo de movimiento es RWPM. Aquí, el retardo promedio cuando no se implementó QoS es de 2,89 segundos (±1,30 segundos), en el caso contrario es de 0,003 (±0,004 segundos). Al igual que con el modelo RWKM, y aunque el retardo promedio es mucho más bajo, la inestabilidad del tiempo de retardo está presente también cuando el tipo de movimiento es RWPM. Figura 2: Retardo con 20 Nodos, con RWPM ISBN

6 Como una primera conclusión, se puede observar que el modelo de movilidad afecta el retardo extremo a extremo cuando no se aplica QoS. El tipo de movimiento RWPM produce menores retardos en transmisiones sin QoS que el modelo RWKM. Si la red tiene implementado QoS, el modelo de movilidad no produce un gran impacto. La Figura 3 muestra que el retardo es, en general menor a 1 segundo. Figura 3: Comparación de QoS según la movilidad para 20 nodos En caso de un escenario con 100 nodos, o sea, alta tasa de granularidad, se observa que el retardo se vuelve muy inestable en cualquiera de los dos tipos de movimiento cuando no se aplica e. En la Figura 4, el retardo promedio registrado fue de 11,13 segundos (±8,05 segundos) sin QoS. Mientras que cuando se aplica QoS el tiempo de retardo promedio es de 2,100 segundos (±1,266 segundos). Figura 4: Retardo con 100 Nodos, con RWKM La Figura 5 presenta los retardos cuando el movimiento es Random Waypoint. El tiempo promedio cuando no se aplica QoS en este caso 7,03 segundos (±6,37 segundos). De igual manera que en el caso anterior, se puede observar que la inestabilidad de los retardos, cuando no se aplica e, está muy marcada. El tiempo promedio cuando se aplica QoS es de 1,503 segundos (±1,204 segundos). Figura 5: Retardo con 100 Nodos, con RWPM ISBN

7 La Figura 6 muestra la comparativa entre los tipos de movimiento cuando se aplica QoS. Se puede percibir que el tipo de movimiento RWPM genera más inestabilidad que el RWKM. Así mismo, el retardo más alto se lo registró con el movimiento de tipo Walk. En líneas generales el aumento excesivo de la granularidad aumenta el retardo en la red, aún teniendo QoS, para cualquier tipo de movimiento. Figura 6: Comparación de QoS según la movilidad para 100 nodos 4.2 Análisis de la sobrecarga En la Figura 7 se observa la sobrecarga de paquetes de ruteo cuando la cantidad de nodos es 20 y el tipo de movimiento es de Random Walk. Se puede ver que la sobrecarga durante toda la simulación es inestable para la red sin QoS implementado, mientras que para aquella que tiene implementada e la sobrecarga es estable y en general es baja. Para el caso de la red sin QoS se registró una cantidad promedio de paquetes de ruteo de 66 paquetes (±43 paquetes), lo cual indica una gran inestabilidad en la sobrecarga de la red. Para su contraparte con QoS se registró una cantidad promedio de 5 paquetes (±2 paquetes), lo cual confirma lo expuesto en el primer párrafo. Figura 7: Sobrecarga con 20 Nodos, con RWKM En el caso de la red cuyo movimiento es el Random Waypoint, Figura 8, se observa que la sobrecarga sigue siendo mayor en la red sin e. La sobrecarga continúa siendo inestable pues se registró una cantidad promedio de 35 paquetes (±17 paquetes). En cuanto a la red con QoS se registró una cantidad promedio de 3 paquetes (±1 paquetes). ISBN

8 Figura 8: Sobrecarga con 20 Nodos, con RWPM Como se muestra en la Figura 9, al comparar el impacto del tipo de movimiento en las redes con QoS, se observa que el modelo de movilidad con la granularidad estudiada, no afecta en gran medida la sobrecarga de la red cuando se implementa e. Figura 9: Comparación de QoS según la movilidad para 20 nodos En la Figura 10, con el movimiento del tipo Random Walk, se evidencia que la sobrecarga es muy inestable cuando no se aplica QoS. El promedio de paquetes de ruteo en el caso de la red sin QoS implementado es de 5087 paquetes (±3304 paquetes), mientras que para la red con QoS el promedio de paquetes de ruteo registrado es de 2880 paquetes (±1354 paquetes). Figura 10: Sobrecarga con 100 Nodos, con RWKM En el caso de las redes con movimiento Random Waypoint, Figura 11, el promedio de paquetes de ruteo que se registró cuando el estándar e no estaba implementado fue de 4122 paquetes (±3104 paquetes), mientras que cuando no se implementó se obtuvo un promedio de 2561 paquetes (±1294 paquetes). ISBN

9 Figura 11: Sobrecarga con 100 Nodos, con RWPM La Figura 12 muestra la diferencia entre las redes con QoS implementado según el tipo de movimiento. Si bien no se puede observar claramente cuál es más inestable, el hecho de que la desviación estándar sea mayor que el promedio en el caso de la red con movimiento Random Walk, es un indicador de que esta es la que presenta mayor inestabilidad. Aunque en líneas generales la red con mayor sobrecarga es aquella cuyo movimiento es del tipo Random Waypoint. Figura 12: Comparación de QoS según la movilidad para 100 nodos 5 Conclusiones Respecto al retardo, se puede concluir que la implementación del estándar e produce mejores resultados en las redes que lo implementan. Cualquiera sea el tipo de movilidad, y la cantidad de nodos, el retardo es siempre más bajo y más estable cuando el tráfico pertenece a una red con e. Aun cuando la granularidad es alta el retardo promedio en las redes con QoS es menor a 1 segundo. Siempre que la granularidad de la red sea menor a 100 nodos, el retardo promedio será muy bajo, no importa qué tipo de movimiento tienen los nodos. En cuanto a la estabilidad de los tiempos de retardo se puede concluir que en los escenarios donde no se implementó el estándar e, el retardo fue muy inestable. Es decir, que sin importar el tipo de movimiento que tengan los nodos ni la cantidad, el retardo varía en forma significativa. Lo anterior permite afirmar que entornos con características de movimiento y granularidad como los que se simularon, no son aptos para aplicaciones en tiempo real sin una administración acorde de QoS a nivel MAC, las cuales son altamente sensibles a los cambios en el throughput de la red. Para las redes con e, la estabilidad cuando la granularidad es baja no es un factor ISBN

10 importante, debido a que, si bien en la mayoría de los casos la misma estaba presente, el retardo promedio es tan bajo (inferior al segundo) que la estabilidad o inestabilidad no afecta demasiado la eficiencia de las aplicaciones que son sensibles al mismo. Con respecto a la sobrecarga, el estándar e marca una gran diferencia en la recarga entre las redes que lo implementan de aquellas que no lo hacen. Mientras que la granularidad sea baja la sobrecarga se mantiene estable y no alcanza grandes valores cuando se implementa el estándar de QoS a nivel de MAC. Cuando la granularidad de la red es baja, y se implementa QoS, la sobrecarga de la red es estable y se mantiene en bajos niveles. Para una taza de granularidad alta, y si las aplicaciones son del tipo CBR, la sobrecarga se vuelve inestable y alta. Esto permite concluir que en el caso de redes con alta granularidad, las aplicaciones sensibles al ancho de banda se verán seriamente afectadas, debido a que la sobrecarga no sólo es alta sino que además es inestable. Las redes con alta granularidad, sin importar el tipo de movimiento que tengan los nodos, no son aptas para aplicaciones sensibles al ancho de banda, debido a que existe una gran sobrecarga de ruteo, y esta es muy inestable. De lo anterior se puede concluir que los entornos móviles con alta granularidad no son aptos para aplicaciones como video llamadas, juegos en línea, streaming de video HD, etc., que son, como se mencionó, sensibles al ancho de banda. En lo que respecta al efecto de los modelos de movilidad analizados, cuando no se aplica QoS a nivel de la subcapa MAC, el modelo de movilidad tiene un efecto directo y drástico en los retardos de los paquetes de datos. El modelo de movilidad junto con la granularidad fueron los causantes de la gran inestabilidad que se detectó en los retardos en las simulaciones. En general, el modelo Random Walk fue el que generó mayores y más inestables retardos que su contraparte, el Random Waypoint. 6 Bibliografía [1] Michel Barbeau y EvangelosKranakis. Principles of Ad-Hoc Networking.John Wiley and Sons [2] Kim, Anbin. QoS support for advanced multimedia systems. Information Networking (ICOIN), 2012 International Conference.Page(s): [3] Murazzo, Rodríguez, Vergara, Carrizo, González, Grosso. Administración de QoS en ambientes de redes de servicios convergentes. WICC 2013, Parana, Entre Rios, Argentina. [4] Robert Wójcik. Flow Oriented Approaches to QoS Assurance. Journal ACM Computing Surveys (CSUR).Volume 44 Issue 1, January 2012.Article No. 5. [5] Díaz, Marrone, Barbieri, Robles. Ruteo en redes ad-hoc. WICC 2010, Calafate, Santa Cruz, Argentina. [6] Wietholter, Hoene. Design and Verification of an IEEE e EDCF Simulation Model in ns-2.26.techical University Berlin Telecommunication Networks Group (2003). [7] Marrone, Robles, Murazzo, Rodríguez, Vergara. "Administración de QoS en MANET. WICC 2011 Rosario, Santa Fe, Argentina. [8] Mohapatra, Panda. "Implementation and Comparison of Mobility Models In Ns- 2. National Institute of Technology, Rourkela ISBN

11 Estudio del desempeño de OLSR en una red mallada inhalámbrica en un escenario real Eduardo Rodríguez, Claudia Deco, Luciana Burzacca, Mauro Petinari Departamento de Investigación Institucional, Facultad de Química e Ingeniería, Universidad Católica Argentina, 2000 Rosario, Argentina {ejrodriguez, cdeco, lucianaburzacca, mauro_pettinari}@uca.edu.ar Abstract. El objetivo de este trabajo es analizar el comportamiento del protocolo OLSR sobre una red mallada configurada con firmware OpenWrt utilizando distintos equipos de hardware. Se presentan los resultados empíricos de varias pruebas utilizando el mismo escenario. El escenario que se presenta es una red de mundo real (no de laboratorio) con pruebas reales y no simulaciones. OpenWrt es un software perfectamente válido que puede ser utilizado en una gran variedad de dispositivos y su configuración para utilizarlo con protocolo OLSR es sencilla de realizar y no presenta problemas de funcionamiento con dicho protocolo. Keywords: Redes Malladas Inalámbricas, Redes Mesh, Protocolos, OLSR, OpenWrt. 1 Introducción El objetivo de este trabajo es analizar el comportamiento del protocolo OLSR sobre una red mallada configurada con firmware OpenWrt utilizando distintos equipos de hardware. Las redes malladas inalámbricas (Wireless Mesh Networks) han tenido un gran éxito en la historia de las ciencias de la computación y de la ingeniería. Sus aplicaciones son numerosas en el dominio industrial, militar y comercial. Son en particular un dominio rápidamente creciente y esto trae muchos desafíos. En particular, un desafío difícil e inmediato es el enrutamiento efectivo debido a la volatilidad típica de tráfico en topologías complejas. Muchos estudios han intentado resolver el problema de enrutamiento mediante métodos heurísticos, pero este enfoque no proporciona los límites de cuán bien se asignan los recursos. Sin embargo, este tipo de investigación generalmente asume que el tráfico de demandas de la red es estático y conocido de antemano. Como resultado, estos algoritmos tienden a sufrir un desempeño pobre. De hecho, trabajos recientes han demostrado que el tráfico inalámbrico es muy variable y difícil de caracterizar. Comprender el impacto de la incertidumbre de la demanda en el ruteo y el diseño de algoritmos de enrutamiento para proporcionar robustez, es relativamente un problema de investigación aún incipiente. Las redes Mesh abiertas son redes ad-hoc descentralizadas que no se basan en infraestructuras previas, como routers o puntos de acceso. En su lugar, cada nodo participa en el enrutado, siendo él mismo un router y enviando datos de otros, y de ese modo la determinación de las rutas se hace dinámicamente, basándose en la conectividad que va surgiendo. Para ello, necesitan de protocolos que viabilicen ese comportamiento. Es de suma importancia el análisis de la perfomance de diferentes protocolos de comunicación que deben interactuar con diversos dispositivos que hacen al enlace de los ISBN

12 nodos de la red a los fines de establecer la integración tecnológica disponible. No menos importante es la determinación de la relación costo/beneficio de una determinada implementación. El conocimiento en tiempo real de la configuración topológica de la red, mediante el uso de distintas herramientas de hardware y software, nos permite el monitoreo del comportamiento y sus alcances. Todo ello posibilita optimizar la red para que brinde un mejor servicio. En general, la optimización se basa en lograr el mejor camino para enrutar los paquetes de datos, sin demoras o con una demora mínima en función de lograr un mejor aprovechamiento de los recursos utilizados. En la Sección 2 se presentan algunos conceptos básicos sobre redes malladas y protocolos de ruteo. En la Sección 3 se describe el escenario, hardware y software utilizados. En la Sección 4 las pruebas realizadas. Finalmente, se presentan las conclusiones. 2 Conceptos Básicos Una Red Mallada Inalámbrica (Mesh) es una red compuesta por nodos organizados en una topología de malla. Son redes en las cuales la información es pasada entre nodos en una forma de todos contra todos y en una jerarquía plana, en contraste a las redes centralizadas. Toda variación no prevista en el diseño, puede cambiar su topología, afectar a la distribución de carga de la red y al rendimiento general [1]. Las ventajas que presenta frente a otras redes son el bajo costo al utilizar enlaces inalámbricos, la facilidad de aumentar el área de cobertura incluyendo nuevos nodos, ya no es necesario cambiar infraestructuras como en el caso de las redes cableadas, la robustez que presenta ante fallos al disponer de rutas alternativas y la capacidad de transmisión que permiten aplicaciones a los usuarios en tiempo real de voz, video y datos. Por tanto se puede incluir un nuevo nodo en cualquier momento y lugar. Como consecuencia el costo de este tipo de redes inalámbricas es mucho menor que en las redes cableadas, ya que no hay que invertir en materiales de cableado y en estudios enfocados a la unión más óptima de los nodos. En la realidad, la topografía raramente viene en forma de anillo, línea recta o estrella. En terrenos difíciles, sean remotos, rural o urbano, donde no todos los usuarios ven uno o algunos puntos centrales, lo más posible es que el usuario solo vea a uno o más usuarios vecinos. En una red mallada un conjunto de nodos se comunican entre sí de manera directa transmitiendo la información de nodo a nodo hasta que llega a su destino final. La información atraviesa múltiples saltos y no hay necesidad de una unidad centralizada que controle el modo de transmisión. La comunicación se realiza entre los nodos directamente. Cada nodo puede ser origen y destino de los datos o encaminar la información de otros nodos. Las redes malladas inalámbricas son robustas al tener varios caminos disponibles entre el nodo origen y el destino, de modo que el servicio no se ve afectado por la caída de un nodo o por la ruptura de un enlace. Dado que la forma de operar que tienen estas redes consiste en que los datos pasan de un nodo a otro hasta que llegan a su destino, los algoritmos de ruteo dinámico necesitan que cada nodo comunique información de ruteo a otros nodos en la red. Cada nodo determina qué hacer con los datos que recibe, ya sea pasarlos al próximo nodo o quedárselos, dependiendo del protocolo utilizado. El algoritmo de ruteo usado siempre debería asegurar que la información tome el camino más apropiado de acuerdo a una métrica. Una métrica es ISBN

13 el valor por el cual los protocolos determinan cuál ruta tomar o con cuál nodo comunicarse. Una de las debilidades y limitaciones de las redes Mesh es la latencia (el retardo de propagación de los paquetes), que crece con el número de saltos. Los efectos del retardo son dependientes de la aplicación. Por ejemplo los correos electrónicos no son afectados por grandes latencias, mientras que los servicios de voz son muy sensibles a los retardos. Otra debilidad es la disminución del rendimiento en todas las redes multisalto, esto es, a mayor número de saltos, se tiene menor rendimiento. Con respecto al hardware, prácticamente cualquier nodo inalámbrico puede convertirse en un nodo Mesh simplemente mediante modificaciones de software. Protocolos de Encaminamiento La principal función de los protocolos de encaminamiento es seleccionar el camino entre el nodo fuente y destino de una manera rápida y fiable. Las redes malladas inalámbricas pueden utilizar los protocolos de encaminamiento de otras redes ya existentes, pero modificándolos para que funcionen correctamente con ellas. Si se elige esta opción, el protocolo de encaminamiento modificado debe asegurar las principales características que son el número de saltos, el rendimiento, la tolerancia a fallos, el equilibrado de carga, la escalabilidad y el soporte adaptativo. Otra opción es diseñar un nuevo protocolo de encaminamiento para las redes malladas inalámbricas. Esta solución es más costosa ya que cuando se desarrolla un nuevo protocolo hay que probarlo, modificarlo y solucionar los fallos. Por tanto el tiempo de realización es mayor que si nos centramos en un protocolo ya experimentado. En este trabajo utilizamos el protocolo OLSR para el encaminamiento en la red mesh dado que es uno de los más difundidos en este tipo de redes inalámbricas, a continuación una breve reseña. OLSR: Optimized Link State Routing Protocol ([2], [3]) es un protocolo proactivo que se basa en el estado de los enlaces. Se utiliza la técnica MPR (Multipoint Relaying) que consiste en elegir un conjunto de nodos vecinos que cubran el acceso de nodos distantes a 2 saltos o más. Se adapta bien en redes con un gran número de nodos y de alta movilidad. El formato del paquete es igual para todos los datos del protocolo, así es fácil la extensión del mismo. Para saber el estado de un enlace se envían mensajes de HELLO. Cada nodo tiene asociado a cada vecino el estado del enlace. Cuando un nodo detecte la aparición de un nuevo vecino se debe incluir una nueva entrada a la tabla de encaminamiento e incluir el estado del enlace. Además si se detecta una variación en el estado de un enlace, se debe comprobar en la tabla de encaminamiento que el cambio ha sido reflejado. Si no se recibe información de un enlace durante un tiempo determinado se elimina de la tabla de encaminamiento el enlace y el vecino correspondiente. Para calcular las rutas, cada nodo contiene una tabla de encaminamiento con el estado del enlace y el nodo. El estado del enlace se mantiene gracias al intercambio de mensajes periódicos. La tabla de encaminamiento se actualiza si se detecta algún cambio en el campo de enlace, de vecino, de vecino de dos saltos o en la topología. ISBN

14 3 Escenario y Tecnologías Utilizadas Se montó una red experimental distribuida en tres edificios del campus de la Universidad a los efectos de tener un campo de pruebas más parecido a la realidad de las redes mesh. En la Figura 1 se muestra la distribución del equipamiento y métricas del protocolo OLSR. Al momento de montar la red mesh, se realizó un análisis del campo electromagnético en la frecuencia 2.4 ghz. Para esto se utilizó un analizador de frecuencia de Ubiquiti AirView2 ext. Se detectó que el canal 11 no estaba siendo utilizado por la red inalámbrica de infraestructura. A raíz de esto se eligió esta frecuencia para la red mesh. Fig. 1. Escenario Tabla 1. Hardware utilizado. ISBN

15 En el montaje de esta red se utilizaron equipos de las marcas Linksys (WRT54GL), Ubiquiti (Nonostation 2, Nanostation Loco M2), TP-Link (TL-WR743ND, TLWR842ND) como se muestra en la Tabla 1. Se eligieron por la gran popularidad y su bajo precio. Se utilizó como sistema de operativo OpenWrt [4] que es una distribución de Linux usada para dispositivos embebidos tales como routers personales. El soporte fue limitado originalmente al modelo Linksys WRT54G, pero desde su rápida expansión se ha incluido soporte para otros fabricantes y dispositivos. OpenWrt utiliza principalmente una interfaz de línea de comando, pero también dispone de una interfaz web en constante mejora. El soporte técnico es provisto como en la mayoría de los proyectos de Software Libre, a través de foros y su canal IRC. El desarrollo de OpenWrt fue impulsado inicialmente gracias a la licencia GPL, que obligaba a todos aquellos fabricantes que modificaban y mejoraban el código, a liberar éste y contribuir cada vez más al proyecto en general. Como se puede ver en la tabla de dispositivos se utilizaron distintas versiones de SO: - OpenWrt en su versión , que es la estable más reciente, solamente con el agregado del protocolo OLSR versión que es la que viene standart con esa versión de openwrt - Freifunk [5] que es una adaptación basada en OpenWrt hecha por grupos de usuarios alemanes que la utilizan para el montado de redes mesh en varias ciudades de ese país. Este sistema operativo presenta varias adaptaciones específicas para redes mesh y entre ellas una muy útil como es la graficación de los enlaces de toda la red y los valores de las métricas de OLSR para cada una como se puede ver en la Figura 1, viene instalada por defecto. La versión de OLSR es la Commotion [6] es otra adaptación de OpenWrt hecha especialmente para montado plug and play de redes mesh. Está basada en las últimas versiones de OpenWrt (10.03 en adelante) y para ser usada principalmente en equipos Ubiquiti de la serie M. Al igual que Freifunk (de hecho muchas aplicaciones vienen de esta distribución) presenta varias herramientas y utilidades para el análisis y la visualización del comportamiento de la red. También utiliza protocolo OLSR por defecto en su versión Si uno no utiliza las configuraciones por defecto para el armado de la mesh presenta algún grado de dificultad para realizar la configuración que uno desee. En todas estas versiones de OpenWrt se utilizaron las versiones de OLSR que se instalan por defecto desde los repositorios. Todas estas versiones de OpenWrt utilizan un interface web que permite la configuración de todas las opciones para que la mesh funcione. 4 Pruebas realizadas Utilizando el escenario, se realizaron pruebas para medir la efectividad del protocolo. En la ejecución de estas pruebas se utilizó el camino formado por los nodos 20, 7, 9, 16 y 14. Las métricas de rendimiento son: El tiempo de ida y vuelta (Round-trip time - RTT), Jitter, la probabilidad de error y testeo de ancho de banda. RTT: es el tiempo que le lleva a un paquete alcanzar un nodo remoto y regresar. Está relacionado con la latencia de la conexión. Cuanto más bajo es el RTT, mejor es la conexión. ISBN

16 Jitter: es la variación en la latencia de paquetes recibidos de un nodo remoto. Cuanto más bajo es, mejor conexión. Es importante cuando se utiliza aplicaciones de voz sobre IP. Probabilidad de error: Los errores en una red causan que los paquetes se pierdan, corrompan, se dupliquen o queden fuera de servicio. Cuando ocurre un error es importante saber la probabilidad con la que suceden y el tiempo entre ellos. Lo ideal es no tener errores, pero una tasa baja es aceptable. Ancho de banda: es la tasa de transmisión de un enlace o sistema de transporte de datos y se puede definir como la capacidad de un enlace o sistema para transmitir datos. Se expresa en bit por segundo. Nuestra herramienta principal de testeo fue iperf para todas las métricas a excepción de RTT, que se midió con ping. Iperf es una herramienta que se utiliza para hacer pruebas en redes informáticas. El funcionamiento habitual es crear flujos de datos TCP y UDP y medir el rendimiento de la red. Iperf permite al usuario ajustar varios parámetros que pueden ser usados para hacer pruebas en una red o para optimizar y ajustar la red. Puede funcionar como cliente o como servidor y puede medir el rendimiento entre los dos extremos de la comunicación, unidireccional o bidireccionalmente. Es software de código abierto y puede ejecutarse en varias plataformas incluyendo Linux, Unix y Windows. Cuando se utiliza el protocolo UDP, Iperf permite al usuario especificar el tamaño de los datagramas y proporciona resultados del rendimiento y de los paquetes perdidos. Cuando se utiliza TCP, Iperf mide el rendimiento de la carga útil. Típicamente la salida de Iperf contiene un informe con marcas de tiempo con la cantidad de datos transmitidos y el rendimiento medido. Para medir el valor de RTT se utilizó la herramienta ping. Ping es el acrónimo de Packet Internet Groper, que significa "Buscador o rastreador de paquetes en redes". Es un utilitario que analiza el estado de la comunicación entre un host local y uno o varios remotos por medio del envío de paquetes. Se utiliza para diagnosticar el estado, velocidad y calidad de una red determinada. En nuestras pruebas siempre se utilizó como tamaño de paquete La Figura 2 muestra los resultados de RTT obtenidos utilizando el protocolo OLSR. Los resultados muestran un patrón donde RTT se incrementa con el número de saltos. ISBN

17 Fig. 2. Evaluación de Round-trip Time en OLSR La Figura 3 muestra los resultados de la variación del retardo (jitter) obtenidos. A medida que aumenta el número de saltos aumenta el valor de retardo y el aumento se torna significativo para 3 y 4 saltos. Fig. 3. Evaluación de Jitter en OLSR La Figura 4 muestra los resultados de Probabilidad de error usando OLSR. Se observa que la pérdida de paquetes crece con el número de saltos y se vuelve significativa a partir de 3 saltos. Fig. 4. Evaluación de la Probabilidad de Error en OLSR ISBN

18 La Figura 5 muestra los resultados obtenidos de las pruebas con TCP y UDP. En ambos casos el comportamiento es similar. El ancho de banda sufre un decrecimiento a medida que se incrementa el número de saltos. Fig. 5. Evaluación del ancho de banda en OLSR con UDP y TCP Además, utilizando el mismo escenario, se realizaron pruebas para medir el tiempo de recuperación del protocolo cuando cae un nodo de la red y para medir el tiempo que tarda el protocolo en entrar en funcionamiento cuando se incorpora un nuevo nodo a la red. Para medir el tiempo de recuperación cuando cae un nodo de la red, se procedió al apagado del nodo 9 y se midió cuánto tiempo tardaba la red mallada en encontrar un camino alternativo. El promedio obtenido fue de 25,63 segundos. Para medir el tiempo de arranque, se apagó el nodo 14, luego se volvió a arrancar este nodo registrando la hora de encendido. Este procedimiento se realizó ejecutando un script para evaluar cuantos segundos demoraba en re arrancar. Se tomó la hora de la ejecución del primer ping inalcanzable y luego la hora del primer 0% paquetes perdidos. El promedio obtenido fue de 42,46 segundos. Para complementar las pruebas con servicios reales se montaron sobre la red mesh, una central telefónica IP Elastix con cinco teléfonos internos: tres internos utilizando un ATA (Linksys phone adapter PAP2-NA) y dos por medio de software cliente de centrales IP. También se montó una cámara IP sobre uno de los nodos más alejados. En estas pruebas (video y voz sobre IP) sobre la red se pudo visualizar un desempeño aceptable de la misma para dichos servicios aunque la aplicación de video no responde eficientemente a cambios bruscos. 5 Conclusiones En este trabajo se presentó un estudio sobre el rendimiento del protocolo OLSR. Se presentaron los resultados empíricos de varias pruebas utilizando el mismo escenario. El escenario que se presenta es una red de mundo real (no de laboratorio) con pruebas reales y ISBN

19 no simulaciones. Cuando se trata con este tipo de entornos, los experimentos son cada vez más difíciles de repetir en forma exacta al anterior. Por lo observado se confirma que el rendimiento de la red decrece con el número de saltos. Su valor, que en nuestro caso es bajo para cuatro saltos, depende mucho de la ubicación y la conectividad entre dispositivos, como así también de la actividad radioeléctrica circundante. A la luz de los resultados hay algunos descubrimientos interesantes: a) OpenWrt es un software perfectamente válido que puede ser utilizado en una gran variedad de dispositivos y b) su configuración para utilizarlo con protocolo OLSR es sencilla de realizar y no presenta problemas de funcionamiento con dicho protocolo. Ex-profeso se utilizó hardware variado para demostrar que se puede realizar una mesh con los dispositivos disponibles en mercado (como los TP-LINK) e incluso algunos más antiguos, como es el caso de los Linksys WRT54GL. De todas maneras en el relevamiento de redes existentes realizado y en el grado de desarrollo de los firmware, se pudo observar que los equipos más utilizados son las distintas versiones de Nanostation de la marca Ubiquiti. Las pruebas con servicios reales sobre la red no tienen rigor de investigación y fueron hechas a los efectos de visualizar en forma sencilla el comportamiento de la red y la validez de la provisión de estos servicios sobre la misma. Cabe aclarar que por tratarse de una red montada sobre un escenario real y no de laboratorio hemos tenido que escoger adecuadamente los horarios de realización de las pruebas dado que las otras redes inalámbricas instaladas en el edificio y la circulación de personas tienen una marcada influencia en el funcionamiento de la red mallada. Bibliografía 1. Akyildiz, I., Wang, X., Wang, W.: Wireless mesh networks: a survey, In Computer Networks. Vol. 47. No.4 pp (2005) 2. Acuña Martínez, D., Roncallo Kelsey, R.: Redes inalámbricas enmalladas metropolitanas. pp ( 2006) 3. Consultado el 02/05/ Consultado el 08/03/ / Consultado el 01/04/ Consultado el 01/04/ Consultado el 08/03/2013 ISBN

20 NetworkDCQ: A Multi-platform Networking Framework For Mobile Applications Federico Cristina 1, Sebastián Dapoto 1, Fernando G. Tinetti 1,2, Pablo Thomas 1, Patricia Pesado 1,2 1 Instituto de Investigación en Informática LIDI - Facultad de Informática Universidad Nacional de La Plata - Argentina 2 Comisión de Investigaciones Científicas de la Provincia de Buenos Aires - Argentina {fcristina, sdapoto, fernando, pthomas, ppesado}@lidi.info.unlp.edu.ar Abstract. Currently, the number of mobile applications that require (wireless) connectivity is constantly increasing. The need for sharing information among mobile devices exists in many applications, and almost every data exchange between these devices involve the same requirements: a means for discovering other mobile devices in a wireless network, establishing logical connections, communicating application data, and gathering information related to the physical connection. This paper proposes an open source developer-oriented framework that acts as a network support layer for host discovery, data communication among devices, and quality of service characterization, which can be used for developing several types of applications and is proposed for different platforms, such as Android Java, J2SE, and J2ME. Keywords: mobile devices, host discovery, communication, QoS, networking 1 Introduction The middleware presented in this paper, called NetworkDCQ, is proposed bearing in mind the evolution of mobile devices as well as specific network requirements of mobile applications. The following subsections briefly explain three topics: trends in mobile devices, mobile network applications, and the initial development platform selected for (a proof-of-concept) implementation. The remainder of this paper is organized as follows. The next section describes the proposed Application Program Interface (API). Afterwards, an architectural overview of the framework is given. The following section presents several applications which use NetworkDCQ. Finally, we describe the results and benefits of using the proposed framework and conclude with an outlook on future work. ISBN

21 1.1 Trends in Mobile Devices The worldwide internet mobile traffic is expected to overtake the desktop internet traffic by 2014 [1], which means that more users will be accessing the Internet through their mobile phones than through their PCs. This phenomena has already been experienced in some countries, like China [2] or India [3, 4]. Currently, nearly 50% of recent device sales are mobile (smartphones, tablets) [5]. Mobile applications are tightly related with this trend. The increasing number of these devices in the last years has led to a revolution in terms of mobile application development and usage. Among all OS mobile systems, Android is by far the most deployed platform [4, 6], with 136 million units shipped and 75% market share in Q [7], seconded by ios and BlackBerry OS with 14.9% and 7.7% market share respectively. Additionally, Android has a large community of developers writing applications that extend the standard functionality of the devices. Google play has hit the 25 billion-download mark by September 2012 [8]. 1.2 Mobile Network Applications Although there is a large number of standalone mobile applications (which require no connectivity at all), a currently increasing trend in mobile environments is the development of applications in which several devices on a network share real time information. These applications rely on some sort of connectivity support in order to achieve the proper interaction among devices. This support can be grouped into three main categories, or services: a) Host discovery, a mean for searching other reachable devices ready to communicate in a network, b) Data communication, a service for handling the specific exchange of information between devices, and c) Quality of service, a monitoring service that provides QoS related information. Since these services are application-independent, a framework can be implemented in order to support specific aids, simplifying the network-related aspects to the developer. The main purpose of the proposed infrastructure is to meet these service s requirements. The features provided by NetworkDCQ allow several types of implementations with different network configurations, such as a typical client/server architecture or a centralized/decentralized peer-to-peer solution. Even though there are several mobile development frameworks [9, 10], none of them proposes an open source, multi-platform solution that presents the features proposed in this paper. Some of these frameworks refer to networking features as simply retrieve wireless connection information, but no additional functionality is supported. Other frameworks cover these features, but as a part of a complete paid solution for mobile-apps development. The most representative examples are PhoneGap [11], Unity3D [12], Titanium [13] and Corona [14]. 1.3 Development Platform The reason for choosing Android as the primary development target for the proposed framework is based on its widespread use and popularity (as previously explained). ISBN

22 However, two additional benefits should be mentioned. First, it is an open source software released under the Apache License. This allowed several non-official versions such as Android for x86, ARM, and MIPS architectures. Some examples given in the present paper were tested on these versions running in a Virtual Machine, without the need for real devices. Second, Android Java is functionally much richer than J2ME. Actually, the similarities with J2SE API (Application Programming Interface) led to the Oracle vs Google lawsuit [15]. As will be shown, this is a considerable advantage due the compatibility between both languages in matters of network communication. This means that the proposed API can be referenced from both types of Java projects. Given that one of the purposes of the framework is to achieve multi-platform compatibility, a J2ME version is also being developed, allowing interoperability between the other platforms. 2 Proposed and developed API The main goal is having a minimal (yet useful) communication-related software infrastructure so that different mobile devices can be programmed. The focus is on the Java language since it is (by definition) cross platform. Even when currently development platforms tend to be very different, it is possible to use Java in almost all of them. While the first problem to be solved is programmability, other issues such as interoperation are left open for future release/development. This section will present the main classes and interfaces of the framework from an application developer point of view. Based on the previous analysis, and the types of interaction required among hosts, the highest level of the API is directly focused on application data communication (Application Support) and the lowest level is divided into three main parts, as shown in Fig. 1: HostDiscovery, for handling the information related to hosts that are ready to communicate to/from each device. As its name suggests, HostDiscovery services/operations include searching for hosts and/or hosts status. NetworkCommunication, for handling the specific exchange of information between applications. Basically, NetworkCommunication should include the necessary send and receive services/operations for applications. QoSMonitor, for providing the user and/or programmer the necessary information on signal quality as well as performance indexes such as startup time (latency) and available network bandwidth. The initial aim for each part is to achieve a very simple interface for the user, simplifying the API usage as well device programmability. As a general concept, the framework is designed to support different implementations for each of the services (Discovery, Communication, and QoS). Through an Abstract factory pattern [16], the user can specify which implementation should be used in each case. The details explained in this section go beyond any implementation, covering the issues at a higher level of abstraction. ISBN

23 2.1 Application Data, Producer, Consumer Generally, the framework will require a data producer, a data consumer, and the data itself to be transferred among hosts. The three will be instances of user-developed classes which extend/implement a specific class/interface. Based on Inversion of Control [17, 18], these instances will be passed to the framework as arguments. Specific methods of the instances will be called from the framework in order to generate new data, process incoming data, handle a new host in the network, etc. The base class for the application-level data is the abstract class NetworkApplicationData. This class will be the superclass for any information to be sent/received through the NetworkCommunication services. Currently, the only information contained in this class is a reference to the source host (the one that originates the message). Subclasses must augment the data structure as needed, and any data type/object can be used as long as it implements the Serializable interface. The producer class is in charge of generating the updated local information to be sent to the other hosts. This class must implement the NetworkApplicationDataProducer interface. This interface only requires the method producenetworkapplicationdata to be implemented, which returns an instance of a subclass of NetworkApplicationData with the actual data. This method will be called periodically if the periodic Broadcast feature from the NetworkCommunication service is active. The period is given by the user in milliseconds, also provided by the API. If this feature is not desired, then there is no real need for this class to be implemented. However, it is advisable to centralize the creation of data in a specific class. In this case, calls to producenetworkapplicationdata method will have to be done manually from some application-level class when required. The consumer handles every type of incoming information, mainly related to application data from other hosts as well as notifications of arrivals and departures of hosts to/from the network. Every time a new message arrives, the framework will invoke the newdata method so that the application can act accordingly. A NetworkApplicationData object is received as a parameter, containing the actual data. The consumer will have to cast this object to the corresponding application-level data type. When the HostDiscovery service identifies some network change related to hosts, the corresponding method will be called. This allows applications to behave in a specific way in this cases. Thus newhost or byehost methods will be called when there is a new host in the network or when a host leaves the network respectively. 2.2 Host Discovery As mentioned above, this service is responsible of searching for new hosts in the network as well as exchange host status periodically. The status of a host is simply an online/offline flag in order to know if the host is ready to receive information at a certain moment. The discovery service can be started simply by invoking the startdiscovery method. This will make the framework to look/listen for/to new hosts, calling a specific method each time a host joins or leaves the network. When the service is not needed anymore, the stopdiscovery method can be invoked. This implies neither sending local status nor receiving other hosts status anymore. ISBN

24 The periodicity a host sends its status can be set depending on the application requirements. Making available stopdiscovery as well as the periodicity value to the programmer is necessary in order to have control on energy and communication overhead/usage. The current list of hosts which are part of the network can be accessed through the otherhosts collection so that at any time, the application would be able to search for specific hosts available and the total number of hosts with which could exchange information. 2.3 Network Communication Network communication services (provided by NetworkCommunication) allow hosts to exchange application-level data in different ways, depending on the specific needs of the application being developed. Client/server, broadcast, and Producer/Consumer communication models are available to the applications. In order to establish an application-level communication with other hosts, the startservice method must be started. Once started, the service waits for incoming connections from other hosts. A host can establish a connection to another host through the connecttoserverhost method. An established connection will be used for sending and receiving the application-level data. When a message is received, a Consumer will be able to process the incoming information. Sending a message simply implies specifying the target host and the data to be sent (using NetworkApplicationData, as mentioned above), through the sendmessage method. Additionally, a host might need to send information to every online host in the network calling the sendmessagetoallhosts method. When the service is not needed anymore, the stopservice should be called. This will close all currently established connections. Also, the framework is able to handle sending data to all hosts periodically. In this case, NetworkDCQ will require in each sending the updated local information. A Producer will have to generate this information. This feature is available by calling the startbroadcast method and is useful in cases when a constant exchange of data among hosts is needed at regular intervals, for instance in a network game. The application-level periodic data broadcast can be stopped by simply invoking stopbroadcast method. The periodicity a host sends data can be set depending on the application requirements. 2.4 QoS Monitor A useful set of services is currently being defined, so that each application will be able to decide if it is possible to run under the current network bandwidth, signal strength, etc. At the lowest level of abstraction, an application should be able to ask for the current startup and available bandwidth, so that it will be possible to model the time required to send a message of n data items. Also, some of these performance indexes would depend on wi-fi signal strength, so it would be useful to provide the application with the current signal strength as well as some previous values so that the tendency would be able to be estimated. From a ISBN

25 higher level of abstraction, a method such as calculatemps for an estimation of the number of application-data messages per second would be able to be exchanged, and it would aggregate some low level information, along with the specific application data to be communicated periodically. Although an initial API is proposed, this service is currently under development and unavailable to user applications. 3 NetworkDCQ proposed architecture This section will discuss in detail the implementation aspects of the proposed architecture. As mentioned before, the framework supports different implementations for each low level service. Currently, an UDPDiscovery and TCPCommunication was developed for HostDiscovery and NetworkCommunication services respectively, and QoSMonitor is under development. Fig. 1 shows the most relevant details on each layer, which will be explained in the following subsections (excepting QoSMonitor). Fig. 1. Detailed Architecture of the Framework In Fig. 1, abstract classes are identified with dotted lines, and interfaces are those in italic font. The current implementation of the project can be found at [19] hence the description in this section will be far from explaining the code (or code details), which can be downloaded, used, etc. Section 4 will explain in detail (via specific examples) the step-by-step guide in order to configure and use every feature of the framework. 3.1 Application support This layer involves additional classes which are referenced along several parts of the ISBN

26 framework. For instance, NetworkApplicationDataConsumer is related with Discovery and Communication services. Host instances exist in Discovery, but they are also used in Communication. A special class in this layer is NetworkDCQ, which is explained in detail in the next subsection NetworkDCQ This class is the framework main entry point, and has two main static methods. Method configurestartup allows the developer to specify the Producer and Consumer instances. Method dostartup is the one in charge of starting each service or feature (discovery, communication, broadcast), since they can be started independently. It is expected that configurestartup is called before any usage of the framework and method dostartup identifies the point from which the application would start using every framework service (discovering hosts, establishing communication/s, etc.). 3.2 UDPDiscovery UDPDiscovery is the implementation of HostDiscovery, extending its abstract class. As such, it implements startdiscovery and stopdiscovery methods. When the discovery service is started, the UDPDiscovery spawns two threads: UDPListener and UDPClient as shown in Fig. 2a. The former first joins the network group via a MulticastSocket, and then waits for incoming host status updates from other hosts. The latter periodically sends multicast packets with its local host status. Fig. 2. a) UDPDiscovery Hierarchy, b) TCPCommunication Hierarchy UDPDiscovery has an additional responsibility, which is to check for hosts that leave the network without giving the proper signal. This is achieved by a connection timeout validation, i.e. by checking - for each remote host - the timestamp of the last received status update. If the lapse of time exceeds a predefined threshold, then the host is removed from otherhosts list and byehost method is invoked. This validation is executed periodically. ISBN

27 3.3 TCPCommunication TCPCommunication is the implementation of NetworkCommunication, extending its abstract class. This service will spawn several threads, depending on the framework configuration. The following is a brief explanation of the methods discussed above and taking into account the details shown in Fig. 2b. Method startservice will spawn a TCPListener, in charge of listening for new TCP connections from other hosts. For each new connection, this class will spawn a new TCPServer thread, which is in charge of receiving NetworkApplicationData objects from a specific host. Method startbroadcast will spawn a TCPCommunication thread, which will periodically send a NetworkApplicationData object (relying on the configured NetworkApplicationDataProducer that generates the data), using the sendmessagetoallhosts method. This last method simply iterates the HostDiscovery.otherHosts collection, and calls sendmessage method in each case. TCPCommunication has a pool of TCPClient objects (the ones in charge of writing data through a socket), one for each host. Method connecttoserverhost instantiates a new TCPClient when invoked and will keep it in the pool for later use. Every time a message is sent to a host, TCPCommunication first retrieves the corresponding connection with that host, avoiding having to reconnect continuously. 4 Examples In this section three different examples will be discussed, in which the network requirements for each application differs considerably. The first one is a competitive multiplayer Asteroids-like game (referred to as Asteriods, from now on) and the second one is a two players Tic-Tac-Toe game, both currently running in Android. The third example is a simple chat application implemented both in Android and J2ME in order to show multi-platform communication. In each case, sample code will be given in order to highlight the most relevant details related to networking. The complete code of the first two examples can be found at [20] and [21] respectively. Also, these projects are completely built on top of the NetworkDCQ project [19], i.e. there is no access to other Host Discovery and Communication services beyond those provided by the NetworkDCQ framework. For the third example, the J2ME version of the chat application is built on top of the J2ME version of the NetworkDCQ project [22]. ISBN

28 Fig. 3. a) Asteroids running on three Android x86 v2.2 virtual machines, b) Tic-Tac-Toe running on two Samsung Galaxy SII mobile devices with Android 4.0.3, c) Chat application running on Android x86 (left) and J2ME Emulator (right). 4.1 Asteroids Multiplayer Asteroids is a very simple game, in which a ship (controlled by a user) must destroy enemy ships firing laser shots. Every ship corresponds to a user in a host (i.e. mobile device, tablet, etc.) in the network, as shown in Fig. 3a. The local ship will be rendered in green and remote ships will be rendered in blue. An example video of the game can be found at [23], where it is also shown that the entire example is run on virtual machines with Android. Although very basic, the application is representative in terms of CPU and network usage of a class of game applications: the game must continuously update its local model, share local information among all hosts, receive and update remote hosts information, and render the corresponding graphics. Considering an update rate equivalent to 30 frames per second, the network consumption is considerably high and grows proportionally to the number of players. Furthermore, the game uses the Periodic Broadcast feature from the Communication service. The data defined to be sent/received through the network includes ship position and heading, as well as shots position and heading that the ship shoots when the user triggers the fire action. The producer has a unique and reusable AsteroidsNetworkApplicationData instance (in order to avoid continuous Garbage Collector calls), which is filled in new data every time is needed with its current ISBN

29 values according to the model changes. The Consumer is the place where remote ships information is updated with the received data. A cast to AsteroidsNetworkApplicationData is needed in order to retrieve the members in the instance (ship heading, position, etc.). The last step simply requires setting the corresponding application-level instances of Producer and Consumer of the framework, and starting the Discovery, Communication and Broadcast services. 4.2 Tic-Tac-Toe Tic-Tac-Toe has been selected as a representative example of a completely different type of application, compared to the Asteriods game, since Tic-Tac-Toe is a twoplayers game, turn-based and there is no need for a continuous sending of information, specific events (players taking turns) trigger communications. Fig. 3b shows a running example of the game on two Samsung Galaxy devices with Android 4.0.3, and an example video of the game running on a virtual machine and a Samsung Galaxy can be found at [24]. While the Tic-Tac-Toe game impose a very different usage of the network during the game (turns, non-periodic messages, etc.) as compared to the Asteroids game, other service requirement such as those related to host Discovery remain the same. The data structure for this application is very simple: an action value representing the possible states of the game: a) resolve who will start the game, b) set a cell with an X or an O - in this case a position value is also needed, or c) restart the game. Since there is no need for a periodic update of local host information, no Producer has to be implemented. The Consumer is the place where each remote action is replicated locally (e.g.: the other player placed an X in cell 7). A cast to an application-level data type is needed in order to retrieve the members in the instance (action and position if needed). As explained previously, the sending of information is not performed periodically. The application sends a message to the other host each time an action event occurs (e.g. when the user clicks in one of the nine cells). The application access the Communication service through the static method NetworkDCQ.getCommunication in order to use the sendmessage method. The other host is retrieved by accessing the HostDiscovery static member otherhosts. The final step is starting the required services. In this case, the Producer and the Broadcast service will not be started. 4.3 Multi-platform chat application A simple chat application has been selected in order to show multi-platform networking capability, requiring only the NetworkDCQ communication features. By simply specifying an IP address and a message, the chat-app sends the corresponding text to the target host, the which shows its content on the display. Fig. 3c shows the achieved interaction among two virtual devices, one running the application on Android, and the other running on J2ME. ISBN

30 The biggest problem in this case is the serialization-deserialization issue. Each platform implements (if it does) a specific serialization method, which can or cannot be compatible with the other platforms. In order to solve this problem, NetworkDCQ defines a NetworkSerializable interface, containing the definition for the networkserialize and networkdeserialize methods. Applications must contain a class which implements this interface in a consistent way on each platform. At run time, NetworkDCQ then delegates the serialization-deserialization work to these classes. 5 Conclusions and Further Work The paper presented a framework for handling network-related issues in the development of applications running on mobile devices, such as host discovery, data communication and broadcasting; designed to support different implementations for each of these services, gaining flexibility, and versatility. Its main goal is to fill a gap in the mobile development frameworks area, where currently there is no open source, multi-platform solution with the features proposed in this paper. The proposed API and reference implementation is actually useful for several types of applications, network requirements, and configurations. The examples shown in the previous section cover applications with a wide variety of network-related requirements like continuous data broadcasting and event driven communication. Using Android as a general development platform allowed an immediate integration with J2SE applications. Additionally, specific interaction problems with other platforms where solved by defining the corresponding interfaces and development methodologies, allowing communication with platforms such as J2ME. As explained previously, the QoS service is still in development. Completing this feature is a short-term objective. Implementing the complete set of features for ios, Windows Mobile, and BlackBerry 10 are mid to long-term objectives. References 1. Morgan Stanley. The Mobile Internet Report, 1st edition. (2009) 2. China Internet Network Information. China Internet Development Statistics Report. (2012). 3. Mobile vs Desktop Internet Traffic Report from Oct 2011 to Oct vs desktop-in-monthly Meeker, M. D10 Conference. Internet Trends. (2012), 5. Asymco. The Rise and Fall of Personal Computing (2012), 6. Gartner, Inc. Nov.2012 Press Release, 7. IDC. Nov.2012 Press Release, 8. Google, Inc. Google Official Blog (2012), 9. Markus Falk. Mobile Frameworks Comparison Chart, 10.Digital Possibilities. Mobile Development Frameworks Overview ISBN

31 11. PhoneGap, Unity3D, 13.Titanium, 14.Corona, Reuters. Oracle sues Google over Android (2012), Gamma, E. Design Patterns: Elements of Reusable Object-Oriented Software (1994). 17.Martin, R. C. The Dependency Inversion Principle. (1996), Fowler, M. Inversion of Control Containers and the Dependency Injection Pattern, 19.NetworkDCQ for Android Project, Asteroids for Android Project, Tic-Tac-Toe for Android Project, NetworkDCQ for J2ME Project, Asteroids for Android Example Video, 24.Tic-Tac-Toe for Android example video, ISBN

32 Estimación de H con transformada ondita Reinaldo Scappini 1, Luis Marrone 2, 1 UTN Facultad Regional Resistencia, calle French 414 Resistencia, Rep. Argentina rscappini@gmail.com 2 LINTI, Facultad de Informática-UNLP, cqalle 50 y 120 La Plata, Rep. Argentina lmarrone@linti.unlp.edu.ar Abstract. El análisis de tráfico se ha convertido en un proceso fundamental a la hora de evaluar la performance de una red. También se ha tornado crítico en la actualidad por la presencia de componentes auto-similares en él. Esta componente cambia el paradigma del modelo de tráfico utilizado hasta hace unos pocos años con serias dificultades analíticas; por lo menos comparándolos con los utilizados hasta el momento. Un parámetro clave en este nuevo modelo es el parámetro H o de Hurst por lo que importa una correcta detección y estimación. Presentamos con esa motivación los resultados obtenidos de la aplicación de un script basado en la transformada ondita o wavelets. Keywords: tráfico, autosimilaridad, onditas, parámetro H, QoS, performance, modelos 1 Introducción Una actividad fundamental en la evaluación de performance y diseño de las redes telemáticas, es el análisis del tráfico que transportan, materializado en parámetros tales como, tiempos de arribo, longitud de los mensajes, tiempos de transmisión, comportamiento en diferentes escalas de tiempo, etc. Este conocimiento permite optimizar los recursos de las redes, y también posibilita, que los servicios ofrecidos, cuenten con la calidad requerida. El logro este objetivo, es un área activa de estudio e investigación. Promediando el año 1990, estudios realizados sobre muestras de tráfico tomadas de redes en funcionamiento, han demostrado en forma inequívoca que el tráfico tiene propiedades autosimilares, esto es, la existencia de patrones estadísticos o comportamientos que se repiten a diferentes escalas de tiempo. Un tráfico con características autosimilares, afecta en forma negativa el desempeño de la red. Se puede observar que el retardo promedio de los mensajes resulta mucho mayor que lo previsto por el análisis de colas tradicional. Esto representa un inconveniente por partida doble. Una peor performance y la imposibilidad de un tratamiento analítico completo. En este escenario, con tráfico originado en diversas fuentes, con sus respectivas características y particularidades, abordar un estudio para cuantificar o medir de manera apropiada la demanda que los usuarios imponen sobre los recursos de una red, requiere del uso de modelos que representen de una manera eficaz y eficiente un comportamiento compatible con las características observables en el tráfico real. Surgen entonces, dos desafíos de importancia central: ISBN

33 2 Reinaldo Scappini1, Luis Marrone2, El desarrollo de modelos generales que abarquen las principales características del tráfico a estudiar. El desarrollo de aplicaciones, que utilizando esos modelos, permitan obtener conclusiones válidas. El éxito de los modelos autosimilares radica en su capacidad de capturar las complejas dependencias que muestra el tráfico a distintas escalas de tiempo mediante el uso de pocos parámetros, en particular el parámetro de Hurst " H ". Dada la importancia del mismo en la caracterización del tráfico, es necesaria su correcta detección y estimación. Si bien este trabajo muestra en forma resumida las ventajas de un método particular, todos los detalles y desarrollos teóricos se pueden encontrar en un trabajo previo [1] donde se analizaron en mayor profundidad. En particular brindaremos los resultados obtenidos aplicando LDestimate [2], una script para la estimación del parámetro H implementada para el software Matlab y basada en la transformada wavelet u ondita. 2 Por qué utilizar la transformada Ondita ( Wavelets )? En la lectura de diversos estudios e investigaciones realizados en los últimos años sobre el tráfico autosimilar en las redes telemáticas, se evidencian las ventajas que aportan los métodos basados en las wavelets u onditas, atendiendo a criterios de validez, confianza estadística y eficiencia computacional. En consecuencia, la utilización de las wavelets se ha convertido en una útil y eficaz herramienta para tareas de análisis, detección, estimación, modelado y simulación en el ámbito del tráfico autosimilar. Como se menciona en las referencias bibliográficas [3] Pág. 84, y [4] Pág. 23; entre las ventajas del estudio del tráfico autosimilar por medio de wavelets u onditas podemos mencionar: La wavelets u onditas ofrecen un marco teórico que se puede aplicar tanto a procesos autosimilares, procesos LRD (Long Range Dependence, o dependencia de rango largo), trazas muéstrales etc. Pudiendo hacer un análisis en el dominio de la escala, de forma que se adapta naturalmente a las necesidades de poder estudiar un comportamiento en este dominio. Permite la división controlada de un proceso madre de variabilidad extrema, en subprocesos a diferentes escalas tornando manejable su comportamiento, aprovechando la independencia de los subprocesos obtenidos, se pueden emplear herramientas de la estadística clásica sobre las secuencias de los coeficientes wavelets, y de esta forma poder diseñar estimadores simples y eficientes. Los bancos de filtros de análisis y síntesis, proporcionan una forma computacionalmente eficiente de llevar a cabo tareas de análisis y síntesis de procesos autosimilares. ISBN

34 Reinaldo Scappini1, Luis Marrone2, Relación entre las Wavelets y los procesos Hss, Hsssi y LRD Hss es un proceso puramente autosimilar, Hsssi es autosimilar con incrementos estacionarios, LRD es cuando presenta dependencia de rango largo. Si bien no es motivo de este trabajo, el estudio de la transformada Waveletet u Ondita, por cuestiones de contexto es importante señalar que existe un cuerpo teórico llamado análisis multiresolución (MRA) que propone la existencia de una función llamada Wavelet madre y cuyo producto interno con la señal " S " representada por el procesos estocástico X ( t ), da como resultado dos conjuntos de coeficientes llamados aproximación as ( j, k ) y detalles ds ( j, k ) respectivamente, que preservan las características de la señal original y permiten su estudio a distintos niveles de escalas frecuenciales y temporales. El parámetroj representa el nivel de escala también denominado octava y el parámetro k la traslación o desplazamiento temporal. Si la señal X ( t) es proceso un proceso estocástico que presenta un fenómeno de escala representado por el exponente " α ", los coeficientes correspondientes a su transformada wavelet, tendrán las siguientes características: El conjunto { d ( j, k), j 1,2,... J, k } X =, es un proceso estacionario para cada octava j, si el Nº de momentos desvanecientes de la wavelet madre ψ 0, es 1 N α. La varianza del conjunto dx ( j, k ) reproduce el comportamiento de 2 escala subyacente, dentro de un rango de octavas j1 j j2. Dado que el valor medio de la wavelet es cero por la condición de admisibilidad, el segundo momento de dx ( j, k) es proporcional a 2 jα, donde j1, j2 y α, dependen del tipo de fenómeno de escala que exhiba el proceso original X ( t ). Se cumplen entonces, las siguientes relaciones entre estos tres parámetros de la siguiente ecuación: E d j k 2 (, ) 2 j α X Si X ( t) eshsssi α = 2H + 1, y < j < Si X ( t ), presenta LRD, α = 2H 1; j = 2, y j1 debe identificarse en función de los datos obtenidos en el análisis. En caso de que el proceso obedezca una ley de potencias, pero en un determinado rango de frecuencias, f 1 f f 2, ( a este tipo de procesos se los denomina (1) genéricamente procesos 1/ f ), γ corresponde a la ley de potencias expresada y el rango de escalas ( j1, j 2), debe obtenerse partiendo de las frecuencias ( f1, f 2). ISBN

35 4 Reinaldo Scappini1, Luis Marrone2, 3 Estimación mediante la script LDestimate La script LDestimate, a diferencia de otras herramientas utilizadas en la estimación de H, proporciona información extra acerca del contexto en el que se estima H, esto es, tiene funciones accesorias que nos permiten escoger con bastante certeza la octava donde se inicia la alineación descartando las regiones que producen sesgo en el resultado, proporcionando además un estadístico que nos indica la bondad del ajuste, en función de los valores estudiados, y asegura que el rango escogido tenga una efectiva alineación, evidenciando el fenómeno de escala y no una simple aproximación promediada con eventuales desviaciones propias de la técnica de regresión lineal. En los otros métodos la estimación en forma general se hace tomando la máxima cantidad de datos y se pueden producir importantes desviaciones que no son tenidas en cuenta por carecer de estas funciones tales como mostrar el intervalo de confianza y la bondad del ajuste, se muestra a continuación los fundamentos del método y unos comentarios acerca de los parámetros involucrados 3.1 Diagrama Log-escala Estimación de H La gran ventaja estadística del análisis Wavelet en el dominio de las escalas se evidencia en la expresión: 1 2N E [ dx ( j, k) dx ( j, k ')] k k ' α k k ' (2) ; a medida que Esto nos permite medir los promedios temporales y utilizarlos como estimaciones de los promedios estadísticos, y la falta de correlación entre los distintos coeficientes wavelets asegura que los estimadores temporales tengan una varianza pequeña. 2 j(2h + 1) 2 Por otra parte la expresión E d ( j, k) = 2 E d (0, k) X X ; puede tomarse como un estimador del espectro de potencia del proceso en las inmediaciones de la frecuencia correspondiente a la octava j, y como se demuestra en [1], sec y d j k, según: 3.7, se puede estimar la varianza del proceso (, ) X n j 1 µ = j dx( j, k) n j k = 1 2 (3) Donde n j es el número de coeficientes en la octava j, y se observa que la varianza decrece conforme n j aumenta, entonces la variable µ j es una forma eficiente de representar en forma compacta el comportamiento de segundo orden del proceso estudiado X ( t ) en la octava j, y si se tiene en cuenta la expresión, los µ j son prácticamente independientes entre sí generando un desacoplamiento del comportamiento de X ( t ) en las distintas octavas j, y dado que en el estimador la varianza decae hiperbólicamente en función de la octava j, se puede asumir que el ISBN

36 Reinaldo Scappini1, Luis Marrone2, 5 exponente de escala del proceso α, lo podemos estimar como una regresión lineal de y µ, como una función de la octava j. ( ) log j 2 ( j ) En general se puede afirmar que un proceso que presenta LRD tiene una densidad espectral que obedece a: f cf ( ν ), cuando ν 0 ν α (4) Dondeν es la frecuencia; cf es una constante positiva, y α = 2H 1. Es sabido que la densidad espectral o potencia del proceso es proporcional al segundo momento de la variable y con relación a lo expuesto en el punto 3.1 (eq.1, 2 y 3), se pueden establecer equivalencias en ambas expresiones y expresar lo siguiente: 2 ( (, ) ) = jα + log ( c) log E d j k Lo que nos lleva a la siguiente aproximación: 2 X 2 log ( µ ) = jα + log ( c) 2 j 2 (5) (6) A la gráfica de esta recta de regresión (eq.6) acompañada de los correspondientes intervalos de confianza en cada punto calculado, se la conoce como Diagrama Logescala y de la pendiente se puede extraer el valor de α y despejar el valor de H. En realidad lo expuesto hasta aquí es el fundamento básico del método, donde la pendienteα, se puede estimar en la región del diagrama donde los puntos se alinean entre dos octavasj 1, j 2, dado que es posible que no exista alineamiento en otras regiones. Según las notas que acompañan esta script, el autor parte de la definición de LRD α dada en términos del espectro de potencia f ( v) cf ( v) cuando v 0, dondev, es la frecuencia, α es el exponente de escala, que es adimensional, y cf es un coeficiente con dimensión de varianza y describe aspectos cuantitativos de la longitud o extensión del comportamiento LRD, y como ejemplo de la importancia de cf expresa que los intervalos de confianza de la estimación de la media de LRD son proporcionales a cf. La script entrega una estimación de sendos parámetros α ycf junto a otros que toman importancia según el contexto como se muestra a continuación. El diagrama Log-escala, nos proporciona una gráfica con la bondad de la estimación en cada punto como función dej 1 (figura izquierda), lo que permite una mejor elección de las octavas j1, j 2 Diferentes tipos de escala son posibles, sin embargo, el procedimiento de análisis es el mismo en cada caso. En primer lugar, el diagrama de Logscale se genera, y ISBN

37 6 Reinaldo Scappini1, Luis Marrone2, examina los datos para encontrar un punto de corte inferior de la escala j 1, y otro punto de corte superiorj 2, en los que la alineación (línea recta) se observa. Estos puntos de corte deben ser experimentados para encontrar un rango que se ajuste a la regresión de los intervalos de confianza sobre el Diagrama Logscale (Los valores iniciales se deben especificar en la lista de argumentos de "LDestimate", pero estos se pueden cambiar interactivamente.). Para cada rango de alineación elegido, la función de los resultados de la estimación de la pendiente "alfa", toma valores reales. El valor de alfa, y el rangoj 1, j 2, ayudará a determinar qué tipo de escala se presenta. Por conveniencia, alfa se transforma en valores de los parámetros relacionados, como el parámetro de Hurst H, o la dimensión fractal de la muestra (válida sólo si es gaussiana). El usuario debe determinar qué tipo de escala está presente. NOTA: en el caso de LRD, alfa es el parámetro pertinente directamente, sin embargo, a veces es reescrita como una «H», pero esta no es la H de auto-similitud estricta, es simplemente una convención para reescribir alfa de esta forma para procesos LRD. La experimentación con el número momentos desvanecientes N de la wavelet es necesario para: (a) asegurarse de que la onda detalles están bien definidas (con valores de H altos, serán necesarios valores más altos de N, N = 1 es suficiente para estudiar LRD), y (b) eliminar o disminuir la influencia de las tendencias deterministas, como ser tendencias lineales o variaciones de nivel medio, que pueden estar presentes. En ambos casos es conveniente un aumento de N, hasta logar un diagrama Logscale estable. Una estadística de bondad de ajuste ( ) 1 Q j, basado en Chi-Cuadrado se emite para ayudar con la elección del rango de escala, y se representa en el título del gráfico correspondiente (Fig.1.), como se muestra a continuación:. Fig. 1. Es la probabilidad de observar que los datos, con las estimaciones de la varianza en cada escala realmente siga la forma de una recta para asegurar la efectividad de la regresión lineal. Un valor superior a 0,05 es aceptable y es aconsejable la ISBN

38 elección de Reinaldo Scappini1, Luis Marrone2, 7 j, a partir de donde se estabiliza el valor de ( ) Q j, La estimación ( 1) 1 visual de la región de alineación es difícil, cuando los intervalos de confianza se Q j, vuelven muy pequeños, en escalas pequeñas, en este caso la estadística ( ) 1 es una mejor guía. 4 Utilizando LDestimate La script puede utilizarse como una función con 7 argumentos de entrada con la siguiente sintaxis: LDestimate(data,regu,j1,j2,discrete_init,calcj1,printout) data = Vector con los datos que se desean analizar (debe ser un vector fila). regu = N o número de momentos desvanecientes de la wavelet, este parámetro está relacionado con la regularidad de la estimación, a mayor valor mejoramos la bondad del ajuste Q, la variable regu está disponible desde 1 a 10. (sugiero empezar con 1 e ir aumentando para observar la variación de Q y el grafico de regresión respectivamente). j1 = octava de corte inferior debe ser 1. j2 = octava de corte superior, su valor máximo está relacionada con la longitud de los datos, pero se puede cambiar interactivamente durante la ejecución de la script, sugiero arrancar con el valor 2 y luego ir probando otros valores. discrete_init = con el valor 1 realiza la inicialización MRA para datos intrínsecamente discretos si el valor es cero, asume la de entrada de datos ya inicializado (es decir, ya está calculada la aproximación de secuencia o se utiliza un vector correspondiente a una aproximación). calcj1 = con el valor 1 realiza el cálculo de j1 optimo utilizando la script newchoosej1 mencionada más arriba, si el valor es cero omite el cálculo. (sugiero dejarlo en 1). printout = con el valor 1 realiza los dos gráficos correspondientes a Q y la regresión del diagrama Log-escala. Con el valor cero no realiza los gráficos y solamente entrega los valores calculados. 5 Análisis realizado A continuación y a manera de muestra de las posibilidades de estudio que brinda esta metodología, se analizan una serie de trazas que están disponibles para su uso en la investigación conforme las políticas de cada fuente (más detalle a continuación en las correspondientes descripciones). El análisis se realiza sobre muestras tomadas de siete tipos de enlaces: ISBN

39 8 Reinaldo Scappini1, Luis Marrone2, 1. Ethernet 10 Mbits. 2. Ethernet 100 Mbits. 3. Ethernet 1 Gbits. 4. Ethernet 10 Gbits. 5. OC12 6. OC48 7. OC192 Trazas Ethernet 10 Mb: Son las clásicas trazas utilizadas en muchísimos trabajos y que fueran utilizadas en el trabajo seminal de Leland et.al [5]; Si bien trabajo es de mucha antigüedad, es considerado como el punto de partida en este campo de análisis y es muy útil como referencia, pues casi todos los estudios comparativos realizados por distintos investigadores lo utilizan Trazas Ethernet 100 Mb: Las trazas pertenecen a la colección: WIDE-TRANSIT 100 Megabit Ethernet Trace (Anonymized).. Se encuentran disponibles en [6]. Trazas Gigabit Ethernet: Estas trazas corresponden a capturas realizadas por NLANR PMA, mediante una tarjerta Endace DAG4.2GE dual Gigabit Ethernet network. Las trazas encuentran disponibles en la página del proyecto en el link [7]. Trazas 10 Gigabit Ethernet Cluster TeraGrid SDSC: Estas trazas se recogieron mediante un monitor del proyecto PMA [8] (Passive Measurement and Analysis) Trazas sobre Fibra Óptica: Tres grupos de trazas sobre fibra óptica, OC12 OC48, y OC192; fueron facilitadas por el Proyecto CAIDA [9] (CAIDA: The Cooperative Association for Internet Data Analysis). 5.1 Procedimiento previo aplicado a las trazas Debido al importante tamaño de los archivos de las trazas (típicamente del orden de los gigabytes), para poder procesarlos con PC s convencionales, a todas las trazas se las sometió al siguiente tratamiento: Se utiliza el software Wireshark [10], que es un conocido analizador de protocolos basado en tcpdump, que permite manipular trazas que utilicen formato compatible con el tcpdump y además cuenta con una utilidad de línea de comandos llamada Tshark [11], que resulta particularmente apropiada para esta tarea como se muestra a continuación: Se toma el primer millón de tramas de la traza y se lo convierte en un archivo con la extensión.pcap. La sintaxis del comando es: Tshark r [nombre de la traza] c w [nombre.pcap]. Si se quiere trabajar con los tiempos entre arribos, creamos el archivo correspondiente, de la siguiente manera: Tshark r [nombre.pcap] e frame.time_delta T fields > nombre.txt. Esto lo que hace es, leer el archivo.pcap que se creo con el millón de trazas, y lo filtra mediante el contenido del campo timestamp, del que a su vez establece la diferencia con la lectura anterior creando el valor tiempo entre arribos para cada trama y luego guarda el archivo en formato ASCII. Del mismo modo si se desea trabajar con la longitud en bytes de la trama, se utiliza el campo frame.len para el filtrado de la siguiente forma: Tshark r [nombre.pcap] ISBN

40 Reinaldo Scappini1, Luis Marrone2, 9 e frame.len T fields > nombre.txt. Obteniendo de esta forma la salida en formato ASCII que es la más cómoda para poder utilizarla con el Matlab. Aclarados todos los detalles que permitirán repetir los análisis aquí expuestos, a continuación se muestra el resumen de los resultados del análisis efectuado a estas trazas, con el primer millón de datos para cada una de ellas, los datos corresponden a tiempos entre arribos y se muestran en la siguiente tabla. 6 Resultados obtenidos Se exhiben los resultados de la estimación del parámetro H realizada con la script de Darryl Veitch, tomando una muestra de cada traza, conforme se describe anteriormente. Se aclara que las condiciones iniciales para todas las estimaciones son las mismas, es decir inicialmente se fijan los parámetros como: N= 4 momentos desvanecientes, j1 = 2; j2 = 20 y los tres parámetros restantes igual a uno, esto significa que la script calculará en función de los resultados iniciales para cada caso lo siguiente: El mejor valor para j 1 como función del j2 que se encuentre como óptimo. Tomando los valores sugeridos por la script para j1 y j 2, se repite la estimación obteniendo los datos que se muestran en la tabla 1: Parámetro Traza j 1 j 2 α α [95%] H H [95%] 10 Mbit. paug89.tl ,642 [0.590, 0.693] 0,821 [0.795, 0.846] 10 Mbit. poct89.tl ,51 [0.494, 0.527] 0,755 [0.747, 0.763] 100 Mbit. Tokio ( ) ,315 [0.280, 0.349] 0,657 [0.640, 0.675] 100 Mbit. Tokio ( ) ,304 [0.288, 0.321] 0,652 [0.644, 0.661] Gigabit-Ethernet ( ) ,557 [0.479, 0.634] 0,778 [0.740, 0.817] 10 Gigabit Ethernet ( ) ,508 [0.286, 0.731] 0,754 [0.643, 0.865] ampath-oc dag anon ,693 [0.616, 0.771] 0,847 [0.808, 0.885] ampath-oc dag anon ,303 [0.106, 0.499] 0,651 [0.553, 0.750] OC anon.pcap ,195 [0.184, 0.207] 0,598 [0.592, 0.603] OC anon.pcap ,175 [0.167, 0.183] 0,588 [0.584, 0.592] equinix-chicago.dira utc.anon ,461 [0.410, 0.512] 0,73 [0.705, 0.756] equinix-chicago.dirb utc.anon ,282 [0.248, 0.317] 0,643 [0.624, 0.659] Table Tabla Comparativa de Resultados Obtenidos con Distintos Métodos de Estimación de H. La tabla 2, muestra los resultados de la estimación deh, utilizando las aplicaciones desarrolladas en [1], junto al resultado obtenido mediante la script de Darryl Veitch. ISBN

41 10 Reinaldo Scappini1, Luis Marrone2, Table 2. 1-Varianza/Tiempo 2-Rango Reescalado 3- Diagarma Log-Escale 4- Varianza/Octavas Resaltados en cursiva, se encuentran los resultados de la estimación de H, por el método del diagrama log-escala implementado mediante la script LDestimate de Darryl Veitch, que es el de mayor precisión y menor sesgo. Referencias Bibliográficas [1] /Tesis/Scappini_Reinaldo.pdf [2] [3] [Kihong Park, Walter Willinger Self-Similar Network Traffic and Performance Evaluation Copyright 2000 John Wiley & Sons, Inc. ISBNs: (Hardback); X (Electronic). [4][M. Alzate y A. Monroy, Uso de la transformada wavelet para el estudio de tráfico fractal en redes de comunicaciones. Revista Ingeniería Vol. 7 No. 1 Junio 2002 Páginas: Universidad Distrital Francisco José de Caldas. [5] [W. E. Leland, M. S. Taqqu, W. Willinger, and D. V. Wilson, On the self-similar nature of ethernet traffic (extended version), IEEE/ACM Transactions on Networking, vol.2, pp.1 15, Feb [6] Trace (Anonymized) [7] [8] [9] [10] ISBN

42 Monitoreo remoto de sistemas y redes para la auditoria informática María Elena Ciolli, Claudio Porchietto, Roberto Rossi, Juan Sapolski Grupo de Investigación Instituto Universitario Aeronáutico, Córdoba, Argentina {mciolli,porchietto,roberto.rossi}@gmail.com Resumen. Esta ponencia presenta el resultado del análisis e implementación de herramientas para el control remoto del hardware y software de una red informática basado en la conceptualización GLPI (gestión libre del parque informático) y en la norma ISO dominio 7 (gestión de activos) sección 7.1(inventario de activos). Se realizó un estudio comparativo entre dos herramientas: OCS Inventory NG y Open Audit. Se tomaron como factores claves la identificación unívoca de hardware y el software del parque informático y asimismo se consideraron relevantes: el impacto en el tráfico de la red, las facilidades de las herramientas y la explotación de la base de datos resultante para su integración con otros sistemas de información. Se pretende implementar un sistema de información automática de inventario que registre los cambios de la configuración de una red informática, aplicándose en primer término a la red interna del Instituto Universitario Aeronáutico que cuenta con un plantel de 1000 máquinas aproximadamente, repartidas entre dependencias del IUA central y centros de apoyo de Rosario y Buenos. Aires. Palabras clave: OCS Inventory NG, Open Audit, GLPI, Auditoria, Monitoreo. 1 Introducción Existen diversos estándares y prácticas [1] que definen cómo gestionar diferentes puntos de la función IT entre ellos : COBIT COSO ITIL ISO/IEC FIPS PUB 200 ISO/IEC TR ISO/IEC 15408:2005 TickIT TOGAF IT Baseline Protection Manual NIST ISBN

43 Fue seleccionada para esta investigación como base normativa la ISO/IEC [11],[12], por ser un estándar internacional en la cual los puntos de control son la clave para su implementación. En este proyecto se tomó de la misma el dominio 7, Gestión de activos, sección 7.1 ya que el mismo trata sobre Inventario de Activos y Directrices para su clasificación. A los efectos de disponer de un estudio de campo que permita determinar el uso de aplicaciones GLPI en el entorno de las universidades tanto públicas como privadas de la ciudad de Córdoba Capital se ha realizado un relevamiento en distintas universidades, entre ellas la UNC y la UCC. En este sentido se ha podido determinar que sólo en algunas áreas muy limitadas se utiliza software del tipo GLPI con fines de seguimiento de intervenciones sobre los equipos, como en el caso de soporte técnico, y no como gestión global de recursos informáticos, licencias de software o automatización del inventario. En un diagrama como muestra la figura 1, pueden apreciarse los distintos roles que intervienen en una auditoría que realiza el control de activos informáticos:, a saber: Estaciones de trabajo. Auditor. Informe o reporte. Base de datos. Estación para el análisis de datos. Lista de procedimientos. Figura 1. Auditoria estándar. En la actualidad, en el organismo donde se realiza la investigación, el rol de auditor lo encarna una persona física apoyado por el software AIDA. El informe o reporte es transportado en un pendrive y la base de datos es una PC donde se guardan todos los informes. Todo esto se ejecuta en base a unos procedimientos internos estandarizados por normativas de la Fuerza Aérea Argentina, de la cual depende este instituto. ISBN

44 Como resulta evidente, es muy ardua la tarea de tener actualizada dicha base de datos, por lo que resulta imprescindible la investigación, desarrollo e implementación de un software que permita el control automático del parque informático de la institución y la generación y actualización de reportes mediante supervisión de la base de datos del mismo. Se pretende, en síntesis, tener un control del inventario de la red informática tanto lógico como físico. Al realizarlo de manera autónoma, los períodos de actualización de la información resultan menores que cuando se realiza con un técnico que releva máquina por máquina en forma local y registra la información en una base de datos preexistente. Los beneficios más importantes son: Menor tiempo de actualización de la información. Disminución de la probabilidad de errores originados por el ingreso manual de los datos. Reducción de costos de mantenimiento. 2 Metodología A la hora de implementar una solución al problema de la auditoría surgen distintas interrogantes, qué Herramienta usar?, cómo se implementa?, qué datos se pueden extraer?, qué datos son relevantes extraer?, entre otros. Habiéndose analizado diferentes opciones para lograr este objetivo, se planteó un análisis de dos herramientas preseleccionadas de código abierto, a saber: OCS Inventory [2], [10] y Open Audit [9]. Con el fin de tener una primera aproximación al funcionamiento de las herramientas, este análisis fue llevado a cabo sobre un entorno de trabajo virtual. Posteriormente se realizó sobre una pequeña red LAN de arquitectura heterogénea Nuestro esquema de funcionamiento está centrado en la auditoría de las máquinas que pertenecen a una red. En principio esta red está segmentada, con diferentes dominios, diferentes sistemas operativos, y diferentes usuarios. El primero de los interrogantes es qué es necesario modificar o agregar a mi red para poder implementar el sistema de auditoría? Luego surge la pregunta cómo voy a enviar al auditor a cada estación de trabajo?. Todas estas preguntas tienen un elemento en común que consiste en cómo factores externos a la herramienta afectan al despliegue de la misma [3]. De más esta decir que una herramienta de auditoría es netamente un sistema distribuido en toda la red. Para responder estas preguntas es válida la utilización de un entorno de trabajo virtual. ISBN

45 El esquema de funcionamiento del sistema que se plantea se aproxima al que se muestra en la figura 2. Figura 2. Estructura de la red virtual. Esta estructura simula la red informática y se implementó en máquinas virtuales emuladas con Oracle VirtualBox. qué datos se pueden extraer? Al extraer datos tales como: usuarios, programas, configuraciones, etc, en general datos lógicos, la virtualización no presenta mayores inconvenientes, pero a la hora de extraer datos de los componentes físicos la misma no es suficiente. De aquí surge la segunda etapa del proyecto, centrada en la fidelidad de los datos extraídos. Nuestro nuevo entorno de trabajo es una pequeña red aislada, compuesta por 4 estaciones de trabajo todas de hardware diferente (distintos microprocesadores, placas madres, monitores, etc). Además cada estación de trabajo también contiene 4 sistemas operativos instalados. Si bien con solo 4 estaciones no se puede tener toda la diversidad de hardware que hay en una red de 1000 máquinas, esta configuración es una muestra representativa de un entorno real. El esquema de funcionamiento del sistema que se plantea se aproxima al que se muestra en la figura 3. ISBN

46 Athlon x2 250 Administrador por consola web FX4100 TL-SF1016D ML150G6 I Servidor De GLPI virtual E3300 Figura 3. Topología de red real para entorno de pruebas. Se puede apreciar en la figura 3 que el servidor de GLPI sigue siendo virtual. Esto no supone problemas a la hora de validar los datos ya que no es la máquina donde se alojan los servidores la que nos interesa auditar. 3 Resultados De la primer etapa del proyecto surgen las guías de instalación y despliegue de las herramientas. Además se pudo estimar el impacto en la red para cada una de ellas. Se observó en un análisis de tráfico de red que el volumen de éste es directamente proporcional a la cantidad de máquinas. Esto nos permite estimar el tráfico total para la red de la institución. Con el fin de no congestionar a la red se programan los horarios y la velocidad de la auditoria. En la segunda etapa se realizó una comparación de la fidelidad de los datos extraídos, inspeccionando los informes de cada herramienta y verificando contra el hardware y software real de cada máquina. Con todos estos informes se confeccionó la Tabla 1, donde se obtienen los siguientes indicadores, cuyos valores oscilan entre cero y cinco donde cinco es el máximo valor y cero el mínimo. ISBN

47 Tabla 1. Cuantificador numérico. Herramienta, Valoracio de OCS inventory OCS inventory OCS inventory Open Audit Open Audit Open Audit Atributo Importacia Windows xp Windows 7 ubuntu Windows xp Windows 7 ubuntu Inventario de Software Software de base con licencia -Sistema Operativo Actualizaciones de Sistema Operativo Software de aplicaciones con licencia Antivirus 4 4 3,2 4 3, Software gratuito Inventario de Hardware Motherboard Procesadores Memoria Almacenamiento físico HDD Almacenamiento físico ( CD, pen, etc ) Almacenamiento lógico Video Sonido 3 3 1,8 3 1,8 3 1,8 3 1,8 3 1,8 3 1,8 Red BIOS Monitor , Dispositivos de entrada ,4 4 2,4 2 1,2 4 2,4 4 2,4 4 2,4 Impresoras 4 4 3,2 4 3, ,6 2 1,6 4 3,2 Impacto en red Volumen de tráfico en la auditoría 4 3 2,4 3 2, ,4 3 2,4 3 2,4 Volumen de tráfico en el despliegue 1 1 0,2 1 0, Facilidades Desligue , TOTAL 68, ,8 71,2 70,2 65,8 Inventario de Software 5 corresponde a datos fidedignos y completos (nombre, versión, números de serie, licencia, etc, ). 4 corresponde a datos fidedignos (nombre, versión, etc, pudiendo faltar algún número de serie o licencia pero auditando todo lo que tiene el sistema) 3 corresponde a datos parciales (ejemplo: No reconoce todo el software instalado o solo los nombres pero no las versiones) 2 corresponde a datos incompletos (Ejemplo: No detecta cierto software.) 1 corresponde a datos inciertos (Completa campos con nombres o números no significativos) Inventario de Hardware 5 corresponde a datos fidedignos y completos (nombre, revisión, números de serie, etc, ). 4 corresponde a datos fidedignos (nombre, modelo, pudiendo faltar algún número de serie, pero auditando todo lo que tiene el sistema) 3 corresponde a datos parciales (ejemplo: Reconoce cuanta memoria RAM tiene pero no el modelo.) 2 corresponde a datos incompletos (Ejemplo: No detenta un microprocesador, no detecta tarjetas de expansión.) 1 corresponde a datos inciertos (Completa campos con nombres o números no significativos) Impacto de red 5 corresponde a volumen de tráfico excedente menor a la mitad al excedente promedio. 4 corresponde a volumen de tráfico excedente mayor a la mitad al excedente promedio. 3 corresponde a volumen de tráfico excedente cercano al excedente promedio. ISBN

48 2 corresponde a volumen de tráfico excedente menor al doble del excedente promedio. 1 corresponde a volumen de tráfico excedente mayor al doble del excedente promedio. De la tabla 1 se puede concluir que Open Audit es la mejor elección. cómo funciona Open Audit para auditar un dominio? La figura 4 muestra un esquema general de auditoria de dominio con la herramienta Open Audit. Figura 4. Auditoria de dominio. Al iniciar sesión los usuarios del dominio se registran ante el PDC (controlador primario de dominio), que es implementado por el servidor Samba, que los instruye a ejecutar un Script de auditoria. Dependiendo del sistema operativo el Script es diferente. El Script para Linux está compuesto de una serie de sentencias de consola cuya salida es analizada clasificada y segmentada por herramientas para procesar texto como awk. ISBN

49 En Windows se utiliza un Script semejante al de Linux que está codificado en Visual Basic y basado en instrucciones de WMI Service (Windows Management Instrumentation). cómo funciona Open Audit para auditar máquinas fuera del dominio? Un servidor con un método de Polling es el encargado de enviar el auditor. En la figura 5 se observa que aunque el segundo proceso de distribución parece más simple, no lo es, ya que es necesario cargar máquina por máquina en una lista con sus correspondientes nombres de usuario con privilegios de administrador. Figura 5. Auditoria fuera del dominio. Todo esto conlleva a la necesidad de tener una gestión distribuida en la red y no concentrada. cómo almacenan la información? Ambos Scripts guardan en cadenas de texto la información extraída que contiene un identificador de cabecera y caracteres especiales como separador de campos. Estas cadenas son almacenadas temporalmente en un archivo de texto (reporte) cuyo nombre es el de la máquina auditada. Una vez realizadas todas las consultas, el archivo de reporte es enviado por html al servidor del Open Audit que se encarga de cargar los datos en el servidor de base de datos. ISBN

50 cómo se genera un reporte del estado general de la red? En la figura 6 se aprecia cómo es el flujo de información a la hora de realizar una consulta. No es necesario que las máquinas auditadas estén en linea al momento de realizar la consulta. esto cumple con la disponibilidad de datos pedida por la ISO. Figura 6. Consulta genérica. En concordancia con el sistema actual, el rol del auditor es cambiado de una persona física a un Script, el reporte que se trasladaba y almacenaba manualmente ahora lo hace a través de la red LAN interna cuyo único requerimiento es que brinde conectividad entre las estaciones de trabajo y el servidor del Open Audit. Los procedimientos estandarizados están almacenados en el controlador de dominio que es quien va a decidir qué máquinas son auditadas y cuándo. ISBN

51 Esquema general En la figura 7, se presenta un diagrama en bloques que muestra el esquema general que es necesario agregar a la red para implementar la herramienta. Figura 7. Modelo de implementación en red. El área pintada de gris representa una red como la existente en el IUA, el área pintada de turquesa son los servidores que se incorporarán o modificarán. Hay que destacar que hay un área compartida que es el servidor de dominio que al momento de implementar el sistema en la red real será necesario modificar su configuración. Por esto mismo es de vital importancia que estas configuraciones y modificaciones sean exhaustivamente probadas, a los efectos de evitar fallos en la red. ISBN

52 4 Conclusiones Se generó un ambiente virtual donde se simuló un dominio real sobre el que se realizaron las pruebas de las herramientas de una forma controlada para poder medir bien sus facilidades. El mismo está compuesto por máquinas virtuales emuladas con Oracle VirtualBox. Algunas de ellas actúan como servidores y otras como estaciones de trabajo, estas últimas fueron instaladas dentro de un mismo servidor, configurándolas en distintos ambientes operativos, para simular la situación real de la red del IUA, o de cualquier red informática con muchas estaciones de trabajo conectadas. Además se generó un entorno de trabajo real que fue útil para verificar fidedignamente los datos que extraen las herramientas, el cual está compuesto por máquinas reales de hardware y software heterogéneo con el fin de tener una muestra más representativa del parque informático. El éxito de estas pruebas originó que este logro técnico esté documentado y a disposición de los otros proyectos del Ministerio de Defensa en ejecución en la actualidad. Las pruebas realizadas sobre el software demostraron que el mismo no es afectado por la topología de la red, ya que se parte de la presunción de que todas las máquinas tienen conectividad contra su servidor de dominios o la puerta de enlace a Internet, por lo que nos limitamos a simular solamente una subred: x Como se puede apreciar en la Tabla 1 la extracción de datos no cumple totalmente con lo requerido por la norma, por lo que es preciso continuar con el perfeccionamiento del código de Open Audit. Este es uno de lo motivos de que se elijan herramientas de trabajo de código fuente libre. 5 Trabajos futuros Adaptación del frontend PHP que brinda la herramienta Open Audit con nuevas consultas SQL que faciliten la interacción con la información recolectada. En la siguiente etapa se implementará una integración entre la base de datos de Open Audit y la base de datos de la institución a los fines de su convergencia a una única solución. Referencias Barzan T. A. (2010). IT Inventory and Resource Management with OCS Inventory NG 1.02, Ed. Packt Publishing. 3. Jackson C. (2010 ). Network Security Auditing. Ed. Cisco Press. 4. Fettig A. (2005). Twisted Network Programming Essentials. Ed. O'Reilly. ISBN

53 5. Philippe J. y Flatin M. (2002). Web Based Management of IP Network Systems. Ed. John Wiley & Sons. 6. McNab C. (2007). Network Security Assessment, 7. Echenique Garcia J. A.(2001). Auditoria en Informática. Ed. Compañía Editorial Continental. 8. Piattini V. M. y Del Peso N. E. (2008). Auditoria de Tecnologías y Sistemas de Información. Ed. Alfaomega Grupo Editor ISBN

54 IP Core Para Redes de Petri con Tiempo Ornaldo Micolini 1, Julián Nonino 1 y Carlos Renzo Pisetta 1 1 Facultad de Ciencias Exactas Físicas y Naturales Universidad Nacional de Córdoba, Argentina omicolini@compuar.com, {noninojulian, renzopisetta}@gmail.com Abstract. En este trabajo, se presenta un procesador de Redes de Petri con Tiempo, el que es la evolución del Procesador de Petri Temporizado. Este procesador es programado directamente con las matrices y vectores del formalismo de Petri, lo que permite aprovechar el poder de las redes de Petri para modelar sistemas de tiempo real y verificar formalmente sus propiedades, evitando errores de programación al implementar el programa a ejecutar. Este desarrollo ha sido realizado como un IP-cores y es usado en un sistema Multi-core. De esta manera, es posible realizar la implementación del sistema utilizando este IP-core, lo que asegura las propiedades del modelo realizado con la red de Petri con Tiempo, que verifican los requerimientos del modelo que representa al sistema real, sean cumplido. Key words: Multi-core, Red de Petri, Procesador 1 Introducción Los sistemas informáticos son complejos tanto en su estructura como en su comportamiento, más aun cuando tienen un gran número de estados y numerosas combinaciones de datos y eventos de entrada. Abordar soluciones de sistemas complejos y crítico, para dar solución a sistemas en tiempo real, tiene problemas como: la complejidad inherente de la especificación, la coordinación de tareas concurrentes, la falta de algoritmos portables, entornos estandarizados, software y herramientas de desarrollo. Y teniendo en cuenta, las tendencias inequívocas en el diseño de hardware, que indican que un solo procesador no puede ser capaz de mantener el ritmo de incrementos de rendimiento. Por lo que la evolución de los procesadores, que es consecuencia de la mayor integración y la composición de distintos tipos de funcionalidades integradas en un único procesador. Más aun, hoy la disponibilidad de transistores ha hecho factible construir en una sola pastilla varios núcleos de procesador que ha resultado en el desarrollo de la tecnología Multi-core [1]. La obtención de rendimiento decreciente del paralelismo a nivel de instrucción (ILP) y el costo del incremento en la frecuencia debido principalmente a las limitaciones de potencia (se sugiere que un 1% de aumento de velocidad de reloj resultados en un aumento de potencia del 3% [2]) ha motivado el uso de los Multi-core. ISBN

55 Por lo cual los procesadores Multi-core son una propuesta para obtener aumento de rendimiento. Lo que se traduce principalmente en menores tiempos de ejecución, consumo ruido, densidad de energía, latencia y más ancho de banda en las comunicaciones inter-core. Si también consideramos a los Multi-core heterogéneos que tienen como ventaja emplear cores especializados, diseñados para tareas específicas. Es decir, optimizado según la necesidad. Estos tienen la capacidad de usar los recursos de hardware disponibles donde el software específicamente lo requiere. [3] Con el fin de aumentar el desempeño, estos sistemas hacen uso colaborativos de multi-hilos y/o multi-tarea, lo que permite aprovechar los múlti-núcleos. Pero se requiere de más trabajo en el diseño de las aplicaciones, ya que emergen con fuerza la problemática de los sistemas concurrentes. Por lo que con estos procesadores, la programación paralela es indispensable para la mejora del desempeño del software en todos los segmentos de desarrollo y con más razón en el segmento de sistemas de tiempo real. Para dar solución a los sistemas reactivos, paralelos y de tiempo real, en relación con los siguientes aspectos: Problemas de concurrencia que emergen en la programación paralela, por no ser componible, es decir, no se puede obtener un programa paralelo de la composición directa de dos programas secuenciales. Que el hardware de soporte a la implementación de sistemas concurrentes, permitiendo mejorar los algoritmos paralelos. Asegurar los requerimientos temporales en los sistemas de tiempo real, es decir, los intervalos mínimos y máximos para la ocurrencia de un evento. Para lo cual el hardware facilite la programación de estas restricciones en forma directa. Tareas de codificación, que se requieren para la implementación de un modelo, conducen a errores e incrementan el esfuerzo, por lo que es muy valorable que no exista ninguna tarea entre el modelo y el software a ejecutar. 2 Objetivo 2.1 Objetivo Principal El objetivo principal de este trabajo es diseñar e implementar un procesador de Redes de Petri con Tiempo, que ejecute la semántica temporal y se programe en forma directa a partir de las ecuaciones de estado del modelo. 2.2 Objetivos Secundarios Los objetivos secundarios de este trabajo son: Describir brevemente las Redes de Petri con Tiempo con el fin de realizar su implementación por hardware. Mantener la ejecución de las Redes de Petri ordinarias con parámetros temporales en dos ciclos de reloj. Implementar el procesador de Redes de Petri en un IP-core. ISBN

56 3 Redes de Petri con Tiempo En estas redes, cada transición con tiempo tiene asociado un intervalo de tiempo [a, b] que establece el intervalo de tiempo dentro del cual puede ser disparada la transición, con el fin de homogenizar las definición matemática definimos transiciones inmediatas con límite inferior cero. [4] 3.1 Definición Matemática Una Red de Petri con Tiempo (TPN) [5] y marcada, se define matemáticamente como una 8-tupla de la siguiente manera: {P, T, I +, I, H, C, m 0, IS } Donde {P, T, I +, I, H, C, m 0 } es una red de Petri plaza transición marcada con brazos inhibidores y plazas acotadas, y IS es la función estática de intervalos [a, b] asociados a cada transición. Dónde: P: es un conjunto finito y no vacío de plazas. T: es un conjunto finito y no vacío de transiciones, P y T son conjuntos disjuntos I +, I : son las matrices de incidencia positiva y negativa. La matriz I es las diferencias entre I +, I. PxT Z H: es la matriz de brazos inhibidores. PxT {0,1} C: es el vector de cota de plaza C N IS: es la función estática de intervalos asociados a cada transición. T Q + (Q + ) La función IS asocia a cada transición un par de valores que representan los límites temporales máximo y mínimo entre los cuales la transición podrá ser disparada. De manera tal que IS(t) = [min, max] t T Como la función IS representa un intervalo temporal, para cada transición t sensibilizada se introduces el valor timer t, que se auto incrementa con el tiempo, si la transición esta sensibilizada y se cumplir: min timer t max el disparo sea posible. Estas cotas deben cumplir las siguientes condiciones: 0 min < 0 max min max si max min < max si max = ISBN

57 Al valor min lo lamamos Earliest Firing Time EFT (Instante de disparo más temprano). Y, al valor max se le llama Latest Firing Time LFT (Instante de disparo más tardío). Existen dos tipos de intervalos destacables: Intervalo puntual [a, a]. En este caso, el tiempo de disparo es fijo, después de sensibilización se espera un tiempo a. Un disparo inmediato es representado por α = 0 y se comporta como en las Redes de Petri plaza transición. Intervalo sin restricción temporal, [a, ]. Se disparara en algún momento después de sensibilizarse y un tiempo a. 3.2 Estados en una Red de Petri Temporizada En las Redes de Petri con tiempo, el estado de la red es definido por el vector de marcado m i y por el vector de valores de intervalos de transición timer de la red, que lleva la cuenta de tiempo de cada transición sensibilizada. Por lo tanto el estado es: E = (mi, timer ) 3.3 Transición Sensibilizada y Disparo de una Transición Cundo nos referimos a una transición hay que distinguir las siguientes cuestiones: transición habilitada o sensibilizada, transición no habilitada y disparo de una transición. En una Red de Petri marcada, con una marca m k, se dice que una transición t j se encuentra habilitada o sensibilizada si y solo si (sii) todos los lugares del conjunto de plazas tj de entrada a la transición tienen al menos la cantidad de marcas igual al peso de los arcos ( w(p i, t j )) de entrada a la transición tj, esto es: p i t i, m(p j ) w(p i, t j ) Si el timer de la transición es cero, se debe habilitar timer t para que se auto incremente con el tiempo. Las transiciones sensibilizadas pueden ser disparadas en el intervalo [a, b], y su disparo provoca un nuevo marcado es decir un cambio de estado. La ecuación para calcular el cambio de estado o la nueva marca alcanzada por el disparo de tj es (m k, t j ), y se define por la siguiente expresión: m k+1 (p i ) = m k (p i ) w ij m (m k, timer t ) = k+1 (p i ) = m k (p i ) + w ji min timer t max { m k+1 (p i ) = m k (p i ), p i t j, p i t j, en el resto de los casos; min = a, max = b Donde el timer tj se incrementa en cada ciclo de reloj mientras la transición se encuentra sensibilizada. ISBN

58 4 Arquitectura y Funcionamiento del Procesador de Petri con Tiempo El procesador ejecuta la ecuación de cambio de estado resolviendo solo un disparo de una transición a la vez, esto permite resolver todos los casos de disparos, los simples (disparo único) y los disparos múltiples, realizándolos como una secuencia de disparos simples, esto simplifica el hardware. Las disparos son transmitidos por los hilos que se ejecutan en los cores a través del bus del sistema, según las solicitudes emergentes del sistema que se está ejecutando. Esto disparos son recibidos por el Procesador de Petri con Tiempo y almacenado en la cola de disparos de entrada. Existe una cola FIFO por cada transición, la salida de este conjunto de colas es una palabra con tamaño igual a la cantidad de transiciones, la cual tiene unos en las posiciones correspondientes a las transiciones con disparos solicitados, el orden del bit en la palabra es igual al número de la transición que solicita el disparo. Los bits, que se corresponden con las transiciones que no tiene disparo solicitado, son cero, es decir no hay solicitud de disparo. La cola de salida tiene una estructura similar, pero comunica los disparos resueltos a los hilos. En la Fig. 1 se muestran los distintos módulos que componen el procesador, resaltando las principales diferencias con versiones anteriores. [6] El módulo de I/O Datos gestiona el acceso de los cores a las matrices y vectores que programan el sistema. Marcado Modulo de Calculo de la Ecuación de Estado Matriz Cal proximo estado Estado Sensibilizado Detect Red Activa Estado de Transición Matriz de Prioridad Matriz I Matriz H Cotas de Plazas Transicion es Auto Vector EFT Vector LFT Vector Timer Cola de Salida I/O Datos Cola de Entrada Bus del Sistema Multi-Core Fig. 1. Procesador de Petri con Tiempo. El programa del sistema son las matrices y vectores descriptas en la ecuación de estado, esto permite programar el procesador en forma directa a partir de la Red de Petri con Tiempo. Aquí se han agregado la matriz de Brazos Inhibidores y el vector de Cota de Plaza que no figuran en la ecuación de estado presentada en este trabajo, pero son los mismos que en el Procesador de Petri presentado en otros trabajos [7]. ISBN

59 La responsabilidad del Módulo de Cálculo de la Ecuación de estado es la siguiente: 1. Calcular el nuevo estado que resultaría por disparar solamente una transiciones una vez, por lo que resultan tantos vectores de estados calculados como transiciones, y se almacenan. Esto se realiza en paralelo sumando al estado actual a cada columna de I y almacenando todos los vectores resultantes, los que serán evaluados para determinar si son los posibles nuevos estado. Esta operación es realizada siempre que cambia el estado del procesador, vector Marcado. 2. Determinar que transición esta sensibilizada. Se toma todos los vectores calculados en 1 y se verifica que se cumpla que ninguna plaza tenga marcado negativo y tampoco supere la cota de plaza, estas son las transiciones sensibilizadas. 3. Se arranca o para los Timer t. Si en una transición sensibilizada Timer t = 0 se arranca Timer t y si Timer t 0 no se hace nada. 4. Disparo de una transición. Las transiciones que cumplen con: Vector EFT Vector Timer t Vector LFT Las transiciones que cumplen con esta condición y han recibido por la cola de entrada un disparo o el disparo están programado como automático, conforman un conjunto de disparos posibles De este conjunto se selecciona el de mayor prioridad y se ejecuta la transición. Según la transición ejecutada se actualiza el vector de estado, y se pone Timer t a cero. 5. Se ejecuta como un ciclo continuo los pazos 1, 2, 3 y 4. El sistema posee una unidad que detecta cuando ninguna transición esta sensibilizada y Vector Timer supera el tiempo máximo; esta condición genera una interrupción que comunica que el sistema ha finalizado o esta interbloqueado, esta característica es de suma utilidad para verificar el diseño e implementación del sistema. La Tabla 1 muestra las diferencias significativas, desde el punto de vista de la ejecución de las distintas semánticas, estas son: Tabla 1. Comparación entre Semánticas Temporales. Con Tiempo Temporizada 1 Interrumpible Si No 2 Representa las dos semánticas Si No 3 Matrices usadas I I+, I- 4 Permite contener subredes No Si De este cuadro se desprenden las siguientes observaciones: 1. Siendo que las TPN son interrumpibles y las Redes de Petri Temporizadas (TdPN) no lo son, para el caso de múltiples disparos y transiciones en conflicto, un TPN lo resuelve según el intervalo de tiempo; en cambio una TdPN lo hace explícitamente en la matriz de prioridad. Esto hace más complejo el modelado con TdPN e indispensable incluir en el procesador una matriz de prioridades. ISBN

60 Dado que la mecánica de ejecución de las TdPN requiere de un estado más para no ser interrumpibles los tokens son retirados inmediatamente de la plaza y no pueden ser solicitados por otra transición. 2. Dada una red con TPN, una transición, que por semántica es interrumpible, puede transformarse en una no interrumpible modificando la red. Esto se logra encerrando con una transición inmediata la transición temporiza. Lo que tiene como impacto un incremente de una plaza y una transición adicional por cada transición no interrumpible. 3. Para realizar el cálculo de un nuevo estado las TPN lo hacen con una matriz de enteros con signo mientras que las TdPN lo realizan con dos matrices de enteros sin signo; por lo cual debemos analizar dos casos: a. Si los pesos de los arcos son uno: i. Las TPN requieren de una matriz con 2 bit por elemento. ii. Las TdPN requieren de dos matrices binarias. b. Si los pesos de los arcos son uno o mayor a uno: i. Las TPN requieren de una matriz de enteros con signo. ii. Las TdPN requieren dos matrices de enteros sin signo. En el primer caso los recursos utilizados son similares. Por lo que la selección de uno u otro procesador depende de la semántica a utilizar. Mientras que, en el segundo caso los recursos utilizados por las TdPN son mayores. La ventaja de una con respecto a la otra en cuestión de recursos está determinada por incremento de la matriz de incidencia dada por la conversión de las transiciones Time a su equivalente no interrumpibles. 4. El procesador que implementa la semántica TdPN utiliza dos estados para realizar el cálculo de los toquen que entran de una transición y los que salen de esta. Esta diferenciación de estados nos permite insertar una nueva red de Petri entre los dos estados de una transición, lo que posibilita que el procesador puede ser extendido a redes de Petri jerárquicas; ya sea haciendo uso de la semántica TdPN o de las redes de Petri ordinarias. Esto en la actualidad es motivo de una nueva investigación. Las dos semánticas son investigadas, puesto que las TPN requieren de menos recursos para resolver problemas no interrumpibles (que son los más habituales). Mientras que las TdPN presentan potencial de mejora al permitir construir redes de Petri jerárquicas. [8]. 5 Análisis de Rendimiento La implementación de sistema ha sido realizada en una plataforma Atlys Spartan- 6, los cores utilizados son los MicroBlaze ver8.40 [9] que ejecuta un Sistema Operativo XilKernel ver5.01a. Interconectado con el Procesador de Petri Temporizado por un bus AXI [10]. Para comprobar correcto funcionamiento del IP Core y analizar los tiempos de sincronización, se realizaron mediciones para distinto número de iteraciones y numero ISBN

61 de hilos tratando de acceder a una variable compartida en exclusión mutua. Luego se compararon el Procesador de Petri con una implementación utilizando semáforos, ambos resolviendo un mismo problema. La elección de este segundo método de sincronización se basa en que son el mecanismo más ligero para realizar éstas tareas. A partir de estas mediciones se calculó el Speedup, los resultados se muestran en la Fig. 2, se puede observar que, para todos los casos, el procesador de Petri es en promedio es entre un 15% y un 30% más rápido que el uso de semáforos para resolver el problema de sincronizar múltiples hilos que desean escribir sobre una variable compartida e incluso, se alcanzan picos de hasta un 70%. Speed up 2,0 1,5 1,0 0,5 2 Escritores 1,73 1,74 4 Escritores 5 Escritores 1,35 1,101,16 1,26 1,24 1,26 1,24 0, Fig. 2. Tiempos de sincronización por iteración Estas mediciones se realizaron con tiempos EFT y LFT cero, de manera que el rendimiento es el mismo obtenido en el procesador de Redes de Petri sin la semántica temporal. Esto es válido ya que el tiempo de una transición es parte del modelo, es decir, es el mismo para el procesador de Petri como para la implementación con semáforos y el propósito es medir únicamente los tiempos de sincronización. Además, como se observa en la Fig. 3, el procesador necesita únicamente un semiciclo de reloj, desde que el contador alcanza el valor EFT hasta que el disparo se coloca en la cola de salida. La demora introducida es despreciable en relación con el tiempo que tiene un δt de un ciclo de reloj. Teniendo en cuenta lo despreciable de la latencia y tomando el tiempo como parte del modelo es posible analizar el rendimiento sin tener en cuenta los vectores EFT y LFT. Fig. 3. Ejecución en hardware. ISBN

62 6 Crecimiento del IP Core Se analizó el crecimiento del procesador en función de los parámetros que posee. Para esto se generaron procesadores de 8x8, 16x16, 32x32, 48x48 y 64x64 (Plazas por Transición) con capacidad de 7 bits por plaza y elementos de tiempo de 48 bits y se graficaron los resultados, los que se pueden observar en la Fig. 4. Se observa que el crecimiento del IP Core no es algo para despreciar, puesto que la cantidad de elementos empleados crese rápidamente con el producto de las Plazas por las Transiciones. Fig. 4. Crecimiento del IP Core Por otra parte, ya que es posible sintetizar un procesador para cada semántica es deseable determinar y comparar el consumo de recursos para cada uno. La Fig. 5 muestra la comparación del crecimiento entre las distintas implementaciones. Se puede observar que ambos procesadores utilizan aproximadamente la misma cantidad de Flip-Flops pero la implementación para redes temporizadas utiliza un 90% mas LUTs para el mismo número de plazas y transiciones. Fig. 5. Recursos usados por distintas semánticas. ISBN

63 7 Conclusión y Aportes En el presente trabajo, se desarrolla el Procesador de Petri con Tiempo, que permite desacoplar los la concurrencia del procesamiento secuencial. Teniendo en cuanta que el Procesador de Petri con Tiempo permite utilizar Redes de Petri Temporizadas, este procesador puede remplazar a su predecesor y preserva sus particularidades. El modelo de Petri es adecuado para implementar, validar y verificar un sistema paralelo con concurrencia, este tiene una representación algebraica que este procesador usa como el código ejecutable. Las ventajas de este procesador son la disminución de: Esfuerzo de programación, la ecuación de estado es ejecutada directamente en el procesador, y no se requiere programación adicional. El gap entre las restricciones temporales y sus programaciones. Puesto que se trata de los vectores temporales propios de la semántica usada por el procesador. Referencias 1. Hennessy, John L. Computer Architecture A Quantitative Approach.: Denise E. M. Penrose, Domeika, M. Software Development for Embedded Multi-core Systems. 0 Corporate Drive, Suite 400, Burlington, MA 01803, USA : Linacre House, Jordan Hill, Oxford, UK., Sundararajan Sriram, S. S. B. EMBEDDED MULTIPROCESSORS, Scheduling and Synchronization. Boca Raton, Ramachandani, C. Analysis of Asynchronous Concurrent Systems by Timed Petri Nets. Cambribge, Massachussets : Massachussets Institute of Technology, Izquierdo, García. Modelado e implementación de sistemas de tiempo real mediante redes de petri con tiempo. Zaragoza, IP Core for Timed Petri Nets. Micolini, Orlando, Nonino, Nulián and Pisetta, Carlos R. Buenos Aires, Argentina: s.n., CASE 2013,unpublished 7. Procesador de Petri para la Sincronización de Sistemas Multi-Core Homogéneos. Micolini, Orlando, y otros. Buenos Aires, Argentina : s.n., CASE Jensen, Kurt y Kristensen, Lars M. Coloured Petri Nets: Modelling and Validation of Concurrent Systems. New York : Springer, Xilinx. MicroBlaze (UG708) AXI Interconnect (DS768) ISBN

64 A B C DAB BA D E F F F C A B A BCDCE F C C C B C C E CB C BC BCEC C CD C E CB C B C BC BCDCE B E C C E C ECC B E C C E C C B B E C C E C E C E C C D CDC C E E BC E CB E C F E CEC C C C C E E C B C D BC E D E ECE B E B B C C C B E DC EC C BC C E B BCB C E E C F E E C B C B C B C DC B C E B E EC D BC C B C C ECE E D BC E B C B C B C B E C B C BC C D C C C C DC C E B B C BC D EC C E BC C B C CEC B C E B C C C E C C E B C E B E B E B EC C ECE F F C B C C B A D F BBA D C E CE B F F D E B C B BB E E C D B B BC E C C C C C CEC B E C E C C C EC E C C B C CD B EC B E CBB E CB DC B C CE CB B C CEC BC CB BC C F B C B C E C C C CB C B E B BCB C E C C E E D C B C E E C B C E D E C B B B CE B C C B D C E E B C C C C CE B C E E E C D ECE E C C C E E C B C B E E B C CBB C C C E CB E C C E E E C C E C F C BC CB BC BC E E E B E C B CB C B C E C B C ECE E E C E BC C B E DC EC CE C C E ECE B CB E ISBN

65 C C C C B C E D C E C C C CB C CB BC C B E FA C E C E B C E C C C C EC B C C C C C CBB C CE C C CB B C C B E ECE C C CB C E E C C E E C B C C C C E B E C B E ECE E B C ECE ECE C BCB E D F BA D D FE E B C C F BC CB ECE CEC E C BC D ECE C C BC C E DC C B C E B C C C E B B CE C E D C B E C DB D ACA C CB E C F C C C C E E C B C E C E B C E C C B D C E E B C DC C E D E C B C C B E DC EC E B E C CD C B C E B C CB CE E D B C C CB E B E ECE BC B E C CE B C B C E C C C C C B B C BCD CE CE B C CE E D C E BC D C C C C CD B E BC C E B BCB C C C CB E E ECE CE BC C B E C E E B E BC E EC E C E B CE B C E C B E DC EC E B C B C E C C BCB D E C C C CB B C CD B B ECE B E B CDC C E E BC E CB E C F E CEC C C C C C E E C B C D B C E B C C E E C E CE B CBB C E E C E E C B C B B B C B E DC EC C CE C C E E C C B C E DC B E E E C F C C C CB E C C C C E E C B C C C E C E B C D B C CD B BC C E B BCB C E E C F E E C B C B C C C DC B C E B E EC D BC C C C D C E B C C C C B C B E C B C C C DC C E BC C E B BCB B CE D B CE D E C E BC C B C CE B C E B C C C E C C E B C E B E B C E CB E C B C CB CD B B CE B C E B CE E B ISBN

66 A C C E B C C E E E B CB E B E ECE C B CEC C C E F F A EF AD AE BA D E B C E DC B E C B E B C B E C B C B C C B C E B D BC C D BC C C C E BC C C E E B CB E B B E C C CE C B B C C E B E C C E B CB E ECE B C B C C E CB C E B C C C C E BC C E B BCB C D B C E DC C B CE CB E E B C B E B E E C E CE B E C E C D BCB EC C C BB E B B C E C C C CB E C F C E F A C C C CB E C C C C E E C B C CE C B C B E C C C BCEC B CB E BC C C E D B E B CD B E B CB C BCB C E B D C B C E E F C C E B CE C C B E DC EC CDC E BC C CE E C F E DC B B C C B C C ECE E CB C C E B C CBB C B E C C CE E E C B C B C E E C F E CB CD E B B C B B D B C B B E C C C E C E C C B B E C D BCB E CBC C E C F B B C C E C E B C E C C E B B CE B D FA F C C D C C CB BC E B C CE C C C C C DC E B B B C C F E CEC C C C C C E BC C E C C C C E C E B C F A E E E C F B B C C E C E BC C E B BCB C E E B E E C C C E E E CB C B C C C F C E B C E BC CE E C C E EC CB C E C E B C E E ISBN

67 E E C C E BC CE C C C C C CE C E Internet GSM - GPRS Gateway Bluetooth/GPRS Router DMZ - UNSa Nodo Cliente CANAL EXTREMO A EXTREMO Servidor Testing MANET SUBORDINADA INTRANET (Desplegada en zona remota) (Universidad Nacional de Salta) AE F B C E DC C B E E B C E CBB C C E BB C C E C C E EC E CBB C C E B D E C C C E C B C ECE E E E C C CD C C C C D C E F A BC C E B BCB B BCB C E B E C B EC C C C BC CE C E C E A GSM - GPRS Internet Gateway Bluetooth/GPRS GTP Header UDP/TCP Header IP Header Payload IP over GPRS GPRS Tunneling Protocol NAP (Network Access Point) Router DMZ - UNSa Nodo cliente BNEP Header IP Header Payload IP over Bluetooth Bluetooth Network Encapsulation Protocol Servidor Testing INTRANET (Universidad Nacional de Salta) AE F BCB C C C C E EC C C C E E E C C E E C C E C E C EC C C C BC CE C E CBB C C E C EC C C C C E C E A E E E E C C C BC CE C EC C C C C E E C C C C C C C E C E E ISBN

68 C E C E E BC C EC C C C CB C E BC CE C C C D AE F BA D D B A D C B CB E E B B C C C C DC C C C C CE B CE A F F A F E E C A C C B C C CE C C C B E DC C B E B C E C C C C BCB E CD C C B C E CD C E E C E C CE C DC CD C E E DC B FAB AB BA D EA F B F C ABA D C C E E E BC C E B BCB C E B E C BC C B C E C C CD C C C C BCB E CE E B E CE E E CEC C C D C BC BCB CEC C C D C BC F BC BCB BCB E C B C F D E CB C B C D D C E C D AE F BA D B D BC C E E E C C C C DC CE B B C CD C C C BCB CEC C C C CB E BC C ISBN

69 C C CD B BC C E B BCB C BC C B D EC C E B E C C C C CD B E BC C E B B B CB E ECE E B E E E E E F AA E F BC C B C E B BC CE B B B E C C E C C B CB E ECE E B E C A C C C C BCB C E B E C C C BC B C B E E C BCB E C F CE C C BC C ECE E C C E B CB C C C B E B C ECE BC C B C E C C BCB B B BCB A E E C C C C E C BCB A C C E B F C C C ECE C C C B E B C ECE C E B BCE CE B C CEC C CEC E B C CE C C C CB E BC C C C B BCB CE ECE C C C C A F C C D D A F C E D D A F E D D ABA D F A C CD C C C E B B CEC C C BCEC B CB E BC C BC CE C C C C B B E F E B BC CE F E B F BC CE C C C B C B C F B A A D C B C BB E B C C D ISBN

70 B E C B E C B E C BC C E C B E D C E BC C E C B E D C E C E B C C E C C C BC C E C BCB C B C E C C B C E C E C C C C C C C C E C C C B CE E E BC C E C E A CE D E E C C C E C C C E BCEC E B A F A C B C F D C B C Consumo de energía (Powertutor) D AE F A E B CB E BC C CEC E B C CEC C BCB CEC C C E B E C E B E C E C C BCB C C C C B E C C B C E E E B E C E B E C ABA D B CB C C B C C C B C C E B - CD B B BCB C C B CB E BC C CEC CD C - B C C C BCB - C BC E B E C C - C B E BC E E E C E B C CEC CD C - - C EC E C F C - C CE - C CE C C BCB CEC C C C E B - C C B C C B E - E C CE ISBN

71 B CB C C E CE D E C E B C B E CE Echo Request/Reply (32 bytes) Nodo Cliente - Servidor "Testing" 272, Latencia (ms) ,12 232,29 231, NO SEGURO L2TP/IPSEC 3DES SHA1 OPENVPN 3DES SHA1 OPENVPN 3DES SHA1 LZO AE F C B C F B A C C C C BC CE C E BC C E C B E D C E B D C C BC C E C C E BC 30 Descarga de archivo de 1024 Kbytes Nodo Cliente - Servidor "Testing" Comparativo HTTP/FTP Throughput (Kbyte/s) ,2 13,9 12,9 23,9 14,2 10,5 9,7 22,1 0 HTTP NO SEGURO L2TP/IPSEC OPENVPN OPENVPN LZO AE F E E BC C C B E C C C D E C C BCB C C BCEC B CB E BC C C BC ECE E C B EC C C B C C DC C C E CE D E C C BC C BC C B B D C C B C B E CD E B B CE B C E C FTP Throughput (Kbyte/s) NO SEGURO 6,73 IPERF Kbytes de tráfico TCP Nodo Cliente - Servidor Testing 14,96 17,21 10,65 9,33 8,61 L2TP/IPSEC 3DES SHA1 OPENVPN 3DES SHA1 OPENVPN 3DES SHA1 LZO 19,05 48,30 25,00 20,00 15,00 10,00 5,00 0,00 Energia (Joules) IPERF POWERTUTOR AE F A E C B EC ISBN

72 DB A D F F C ECE BC B CE B C E B E C C E E E E B C C C CD B E BC C B B C C CE C C C B E ECE DC CEC B B C C C B BC E B E BC C E B C B B E C E B E C B B C DC CB C C C E C BC CEC CB C B C C B C B E C B C E E C C E E C B E DC EC C C C CB B B D C B B B C B C E C B E DC EC B E C B C CE B B B E BC C C E BC C E B C E B E E C B E DC EC B B E C C BB E E ECE E CE B E E E C D ECE E BC C E C E C B E DC EC E D C C E E E C F C C B C B C C E CB - C E B CB E DC B - B C DC C C E C B C E C E E B C E C B C E B E C C - B C B C B B C C CE B D E C C C B - C C C E CB C C E C B C C C C B E C E A - E C C E D B E B E C B E B BC D E B C C BCB ECE B CB C E EC F DBA ABCD E F D D C A A F A C C E A C C C F C E C E B B D E D ED D DA D DC D D E C E B B D A C A A C E D D D ABC DE D E D DB D D D D E C E C C C C C E B E C C E A C A A C E D D D ABC D D D D D E D ISBN

73 D D D D E C E C C C C BC C E B E C C E A AA A C C B A A DBAD A D BD B D C C E C C C E C A A F A C C E A C C E B B D E D ED D DA D DC D D E C E B B D A A B BC D D E E D D DE D E E D D D E D D F E D D F E D E A E E B B B D A A BC C B B BC B BC A B C B B A C B C E C E B D D A C E E E D A E C E B E E F A F E E C B C E C E B C BC E EC A FC E C E E F B C A E C B B E B E B C A E B E B C E E C E E E CE D C E D D A E B A A A C DC D D E D C D E D F D A E B A F A FC B D B B E E C E C C EE D D D D D ED D F D D D D D D C E C F C C B C E C C E C E B EC C B C C D ISBN

74 Posicionamiento indoor determinado por la distancia en función de la potencia medida de balizas bluetooth Marcelo MARINELLI 1, Juan TOLOZA 2, 3, Nelson ACOSTA 2 1 Departamento de Informática, Facultad de Ciencias Exactas Químicas y Naturales. Universidad Nacional de Misiones 2 Facultad de Ciencias Exactas Universidad Nacional del Centro de la Provincia de Buenos Aires 3 Becario postdoctoral CONICET marcelomarinelli@gmail.com, {jmtoloza, nacosta}@exa.unicen.edu.ar Abstract. El presente artículo presenta una experiencia de captura de datos de dispositivos que emiten señales bluetooth usando una placa tipo Arduino Mega Se analizan los datos con algunas técnicas y se detalla la magnitud de errores encontrados en las diferentes muestras. Además, se proponen algunas nuevas medidas para intentar alcanzar una mejor precisión en el posicionamiento. Keywords: Posicionamiento indoor, Balizas Bluetooth, RSSI. 1 Introducción Los métodos de posicionamiento fueron evolucionando en el tiempo. Los fenicios usaban el sol, la luna y las estrellas para guiarse [1][2]. En la actualidad, se usan micro dispositivos electrónicos [3]. A finales del siglo XX, la aparición de calculadoras y computadoras electrónicas, facilitó grandemente el cálculo; pero la aparición del GPS, poco después, revolucionó la forma de localizar un objeto [4]. Esta tecnología para el posicionamiento en exteriores carece de utilidad en un espacio cerrado como puede ser un edifico. Es difícil usar esta tecnología para distinguir en que habitación o en que planta se encuentra ubicado una persona. Es por ello, que en los últimos años se han presentado diversas soluciones de posicionamiento en espacios interiores. Entre ellas, se encuentra Bluetooth la cual se experimenta aquí y se analiza con diversas técnicas para lograr posicionar un objeto en un ambiente interior. Bluetooth utiliza frecuencias de radio del orden de 2.4 Ghz, representa una tecnología económica [5], pero es de corto alcance, de esta manera, para cubrir la zona de un recinto, se necesitarían varios dispositivos. El error asociado a la estimación puede encontrarse en torno a los 1.5 metros de precisión. En este sentido, el parámetro RSSI Received Signal Strength Indicator, (Intensidad de la Señal Recibida) no es preciso, motivo por el cual, no se puede estimar con exactitud la ISBN

75 ubicación de un dispositivo, sino que se identifica el entorno en el que se encuentra, en un radio determinado. En general, los sistemas de posicionamiento heredan características dependientes del tipo de sensor. Algunas de ellas son: Retardo en la propagación, difracción, reflexión y la dispersión que afectan a todos los tipos de señales. Las características propias de la señal son las siguientes [6]: Atenuación por distancia: A mayor separación entre el emisor y el receptor, la potencia de la señal decrece con el tiempo de forma logarítmica, si el receptor se encuentra a una distancia corta del emisor, la potencia decrece rápidamente y si el receptor se encuentra en un rango de alcance medio, la señal decrece a una velocidad menor. Absorción de la señal: Cuando la señal atraviesa algún material, la potencia de la misma se debilita o atenúa en mayor o menor intensidad, dependiendo de las características físicas del material y de la frecuencia propia de la onda. Reflexión: Este fenómeno ocurre, cuando una onda, choca con un obstáculo, parte de la potencia de la señal no se absorbe, sino que es reflejada y la misma puede tener distinta fase que la señal original, dependiendo de las características propias del obstáculo. Dispersión: Este fenómeno ocasiona que parte de la energía sea irradiada en numerosas direcciones diferentes y ocurre cuando el medio por el cual viaja la señal, está formado por objetos con dimensiones pequeñas, comparados con la longitud de onda propia de la señal. Es el fenómeno contrario a la reflexión, la cual ocurre cuando los objetos poseen dimensiones grandes. Difracción: Cuando una señal impacta con el borde de un obstáculo, se originan diferentes frentes de onda en distintas direcciones. Los factores de los cuales dependen la intensidad de este fenómeno son: la calidad y tipo del material con el que está compuesto el obstáculo, así como también de la amplitud o fase de onda. Los tres últimos fenómenos citados anteriormente, dan lugar un fenómeno denominado: Multitrayecto (Multipath) que origina que la señal llegue al receptor a través de diferentes caminos y por lo tanto a diferentes tiempos ocasionando retardos e interferencias en las transmisiones. De esta manera, las comunicaciones inalámbricas en interiores se caracterizan por este fenómeno, donde no solamente existen señales directas entre el emisor y el receptor, sino que también se encuentran señales difractadas, dispersadas y reflejadas por los diferentes obstáculos y objetos que se encuentran en el medio. En el trabajo desarrollado en [7] se dispone de tres ordenadores portátiles que actúan como emisores de señal Bluetooth y un dispositivo móvil como receptor de la señal Bluetooth. El dispositivo móvil es quien calcula la posición donde se encuentra mediante triangulación de la señal que emiten los tres portátiles. En [8] se presenta una arquitectura en la que los emisores son de bajo costo y el receptor es un dispositivo móvil. El artículo quiere enfatizar en la ventaja de usar este tipo de arquitectura pasiva de bajo costo. ISBN

76 La plataforma Alipe [9] mezcla diversas topologías para obtener la posición. En esta plataforma por un lado hay dispositivos Bluetooth que envían información sobre su ubicación al realizarle una petición por parte de otro dispositivo Bluetooth cliente. Si el dispositivo al que se le ha realizado la petición no está adaptado para comunicar su posición, el dispositivo cliente que ha realizado la petición registra la dirección Bluetooth remota y busca en una base de datos centralizada la ubicación asociada a esa dirección Bluetooth. Follow me [10] presenta una aplicación práctica para un sistema de posicionamiento en interiores. El sistema consiste en dispositivos Bluetooth rastreadores cuya ubicación es conocida. Estos dispositivos rastreadores están constantemente escaneando dispositivos Bluetooth, cada vez que se detecta un dispositivo se almacena su dirección Bluetooth junto con su ubicación, que es la ubicación del dispositivo rastreador, en una base de datos centralizada. La aplicación ofrecida al usuario es poder obtener su ubicación en el edificio, consultando esa base de datos y publicar la ubicación en una aplicación web como puede ser Twitter. En el pabellón de Finlandia en la expo de Shangai 2010 se desarrolló una aplicación para móvil [11] en la que los usuarios podían obtener su posición dentro del pabellón mediante puntos de acceso Bluetooth que calculaban posiciones mediante distribuciones de probabilidad del indicador RSSI. Los sistemas de posicionamiento en interiores no sólo se limitan el uso de tecnologías inalámbricas también, como se puede ver en [12], se ha desarrollado un sistema de posicionamiento en interiores basado en visión por ordenador, en el que se cuenta con una base de datos de imágenes georefenciadas que se usa para buscar coincidencias con lo que está viendo el dispositivo móvil en ese momento. En la mayoría de los sistemas de posicionamiento indoor analizados se opta por estimar la posición usando el indicador de Fuerza de Señal de Recepción (RSSI), recolectando medidas desde distintos puntos para inferir un modelo probabilístico que estima las posiciones una vez que el sistema está en funcionamiento. Albert Huang [13] utiliza la infraestructura de computadoras existentes en un edificio agregando 30 balizas BT en los puertos USB de las mismas, logrando una exactitud de 3-10 metros, dependiendo de la densidad de baliza en la zona. Fernández Gorroño [14] utiliza un sistema de posicionamiento en interiores basado en la tecnología Bluetooth para aplicaciones en Dispositivos Móviles (DM), con el objeto de proveer información en estaciones de subterráneos. La característica de este sistema es que el peso de la lógica está en el DM y las balizas son pasivas y de bajo costo. Sudarshan S. Chawathe [15] estudia los retrasos en la fase de descubrimiento de balizas Bluetooth y propone métodos para aliviarlos de forma de poder utilizarlos para aplicaciones de localización en interiores como, complejos de edificios grandes o terminales de aeropuertos usando coordenadas adecuadas al lugar como número de piso y número de habitación o terminal del aeropuerto y dársena. La sección 2 presenta el proceso de adquisición de datos, la 3 muestra el análisis que se hace a los datos recavados con algunas técnicas propuestas, aquí se muestran los resultados a los que se llegó luego de procesar los datos. Por último, la 4, presenta las conclusiones y futuros trabajos. ISBN

77 2 Toma de muestras y experimentos realizados Se diseña un escenario para la toma de muestras en una de las oficinas del edificio INTIA/INCA, de la Facultad de Ciencias Exactas perteneciente a la Universidad Nacional del Centro de la Provincia de Buenos Aires. Se hacen marcas de precisión en el suelo cada un metro llegando a completar 25 metros. Se toman 100 muestras de cada punto. Las primeras marcas, hasta los 3 metros corresponden al interior de una oficina y hasta los 7 metros a otra oficina contigua. Luego hasta los 25 metros las tomas se hacen en un pasillo del edificio. Para la toma de datos se especifica un sistema de medición de potencia de dispositivos Bluetooth (BT) remotos (baliza BT) utilizando comandos AT. Para ello, se desarrolla un programa de control residente en la placa Arduino Mega que setea al dispositivo Bluetooth local en modo master. De esta forma, se interroga a los dispositivos detectados, se identifican por su dirección MAC y se mide su potencia. La figura 1 muestra un diagrama de los componentes del sistema de adquisición. PC Arduino Mega 2560 BT Baliza BT d Figura 1. Diagrama de componentes del sistema Los dispositivos que se usan para adquirir los datos son módulos transceptores de tecnología inalámbrica Bluetooth RS232 TTL V2.0 con chipset RSE. Para el procesamiento de los datos se desarrolla un programa en Ansi C que, por medio del puerto USB conectado al Arduino, recibe cien datos de medición de potencia y los almacena en un archivo de texto plano. 3 Análisis de los datos con las técnicas propuestas Los datos obtenidos se vuelcan en una plantilla de cálculo donde se obtienen por cada grupo de datos: la moda, el valor máximo, el mínimo y el promedio. Luego se proponen algunas técnicas novedosas a implementar aplicadas en [16][17][18]. En la figura 2 se observa el comportamiento de cada una de las técnicas aplicadas. Cabe aclarar que el mínimo no se muestra en el gráfico ya que tiene valores extremos que no permiten visualizar con claridad el resto de los resultados obtenidos. ISBN

78 RSSI (dbm) Distancia (metros) moda promedio max Figura 2. Gráfico de la potencia en función de la distancia La figura 2 presenta un comportamiento similar para las tres medidas. Cuando la distancia aumenta, el indicador de fuerza de la señal (RSSI) disminuye. Hasta los 3 metros puede verse como el comportamiento es ideal para la moda ya que cada uno de los valores es menor a medida que se aleja de la baliza. No pasa lo mismo con las otras medidas. Al pasar a la oficina contigua, y esto puede ser debido a la presencia de paredes que obstaculizan la señal, la moda oscila bruscamente pero el promedio y los máximos mantienen consistencia hasta los 8 metros inclusive. Desde allí y hasta los 12 metros, el comportamiento es similar para todas las medidas. A los 13 y 14 metros, prácticamente coinciden en valor las tres. Luego, se observan muchas oscilaciones en todas las medidas, esto se puede atribuir a los rebotes de la señal en las paredes del pasillo y en el amoblamiento de las oficinas que se encuentra al paso de la señal. Ahora si se calcula la regresión lineal de cada una de las medidas se puede observar la distancia entre la medida ideal y la real. En el caso de la figura 3, se observa la regresión lineal para el promedio, en la 4 para la moda; y finalmente en la 5, para el máximo. También se muestran las ecuaciones de las rectas en cada caso y el valor de R 2 que representa cuanto se ajusta la recta a los valores reales obtenidos. Cuanto mayor es este valor, significa que mejor se ajusta la regresión a los valores reales. ISBN

79 RSSI (dbm) y = x R 2 = Distancia (metros) promedio Lineal (promedio) Figura 3. Promedio y su regresión lineal RSSI (dbm) y = x R 2 = Distancia (metros) moda Lineal (moda) Figura 4. Moda y su regresión lineal ISBN

80 RSSI (dbm) y = x R 2 = Distancia (metros) max Lineal (max) Figura 5. Máximo y su regresión lineal Según lo analizado la mejor regresión, es decir, el mayor R 2 se da para el promedio. Por lo tanto, el mejor estimador estadístico para el caso estudiado que más se asemeja a un comportamiento lineal es el promedio. Entonces si se aplica a los datos de entrada (RSSI) la ecuación x = (y ) / que se despeja de la que se observa para la regresión (y = x ), se puede tener una salida (metros) donde se obtenga una distancia a la baliza de tal manera de estimar su posición relativa. Las siguientes tres figuras (6, 7 y 8) analizan la magnitud del error cometido entre la medida tomada y la que indicaría la regresión lineal. Esto se realiza luego de aplicar la ecuación despejada para la entrada (x) como se mostró en el caso del promedio. En la figura 6 se muestra el error del promedio, en la 7 de la moda y en la 8 del máximo Error (metros) Distancia (metros) Magnitud del error Figura 6. Magnitud del error entre el promedio y su regresión lineal ISBN

81 Error (metros) Distancia (metros) Magnitud del error Figura 7. Magnitud del error entre la moda y su regresión lineal Error (metros) Distancia (metros) Magnitud del error Figura 8. Magnitud del error entre el máximo y su regresión lineal El error máximo para todos los casos está cercano a los 9 metros cuando la distancia al dispositivo es de 14 metros aproximadamente. El mínimo es 0 para algunos casos. En las tres estimaciones se denota que en el rango medio de distancia es donde se obtiene la mayor magnitud de error. Este fenómeno se puede deber a los obstáculos que debe sortear la señal para llegar al dispositivo y obviamente cuando más se aleja, menor es la recepción. También se observa que cercano al dispositivo de captura el error medido es alto pero no se tienen detalles de su ocurrencia. ISBN

82 4 Conclusiones y trabajos futuros Se ha presentado un sistema ad-hoc para posicionamiento indoor usando un entorno libre como es Arduino con la posibilidad de ser montado en cualquier móvil. Las técnicas utilizadas muestran que es posible estimar la distancia con un cierto grado de error y por medio de triangulación, localizar un objeto en un ambiente interior. Los errores máximos se encuentran en los 9 metros cuando la distancia es casi del doble. Calculando el promedio de las medidas se obtiene un buen estimador pero no es suficiente para una buena precisión. La moda si bien es la que menos se ajusta a su regresión lineal, también es un buen estimador aunque el error acumulado es el más grande de los tres. Como futuros trabajos se prevé el desarrollo de técnicas que permitan mejorar la estimación de la distancia a partir de la fuerza de la señal recibida. Se va a tomar mas cantidad de muestras con rangos de distancias que van de a 50cm para verificar la aplicabilidad de las técnicas propuestas en este trabajo y de las futuras a desarrollar. También se va a utilizar el tiempo de vuelo de la señal para verificar los datos obtenidos. Se van a hacer pruebas en un ambiente sin obstáculos para ver el comportamiento de la señal en un ambiente ideal. Además, se van a realizar tomas de datos en un ambiente exterior de manera de analizar su comportamiento. Como se mencionó anteriormente, algunas de las técnicas que se proponen implementar son: filtro de Kalman con ajuste de la desviación estándar, lógica difusa y redes neuronales. Con ello se busca aumentar la precisión de posicionamiento. Referencias 1. Rao (2010) Global Navigation Satellite Systems. Tata McGraw-Hill Education, 478 pp. 2. Misra P. & Enge P. (2010) Global Positioning System: Signals, Measurements, and Performance. New York, Ganhga-Jamuna Press, 590 pp. 3. Asdrúbal V. (2004) De la técnica a la modernidad: Construcciones técnicas, ciencia, tecnología y modernidad. Universidad de Antioquia, 263 pp. 4. Maini A. K. & Agrawal V. (2010) Satellite Technology: Principles and Applications. 2nd Edition, John Wiley & Sons, United Kingdom, 704 pp. 5. Hallberg J., Nilsson M., Synnes K. (2003) Bluetooth Posittioning. 10th International Conference on Telecommunications, Volume 2, IEEE, pp Stewart J. W. (1983) Introduction to Wave Propagation, Transmission Lines, and Antennas. Navy Electricity and Electronics Training Series. U.S. Navy. 7. S. Feldmann, K. Kyamakya, A. Zapater, Z. Lue, An Indoor Bluetooth-Based Positioning System: Concept, Implementation and Experimental Evaluation, in: International Conference on Wireless Networks, Cheung K., Intille S., and Larson K., An Inexpensive Bluetooth-Based Indoor Positioning Hack. Proceedings of UbiComp J. Hallberg, M. Nilsson, K. Synnes, Bluetooth Positioning, The Third Annual Symposium on Computer Science and Electrical Engineering (CSEE 2002), Luleå, Sweden, May Polychronis Ypodimatopoulos and Andrew Lippman. 'Follow me': a web-based, locationsharing architecture for large, indoor environments. In Proceedings of the 19th international conference on World wide web (WWW '10). ACM, New York, NY, USA, ISBN

83 11. Pei, Ling; Chen, Ruizhi; Liu, Jingbin; Tenhunen, Tomi; Kuusniemi, Heidi; Chen, Yuwei;, "An Inquiry-based Bluetooth indoor positioning approach for the Finnish pavilion at Shanghai World Expo 2010," Position Location and Navigation Symposium (PLANS), 2010 IEEE/ION, vol., no., pp , 4-6 May Paucher, R.; Turk, M.;, "Location-based augmented reality on mobile phones," Computer Vision and Pattern Recognition Workshops (CVPRW), 2010 IEEE Computer Society Conference on, vol., no., pp.9-16, June Huang, A., An Inexpensive Bluetooth-Based Indoor Positioning Hack MIT CSAIL Available at Fernández Gorroño, J. L. SISTEMA DE GUIADO MULTIMEDIA EN INTERIORES MEDIANTE DISPOSITIVOS MÓVILES BLUETOOTH. 15. Chawathe, S.S., "Low-latency indoor localization using bluetooth beacons," Intelligent Transportation Systems, ITSC '09. 12th International IEEE Conference on, vol., no., pp.1,7, 4-7 Oct Toloza J. (2013) Algoritmos y técnicas de tiempo real para el incremento de la precisión posicional relativa usando receptores GPS estándar. Tesis Doctoral, Universidad Nacional de La Plata, 213 pp. 17. Toloza J., Acosta N. & De Giusti A. (2012) An approach to determine the magnitude and direction error in GPS system, Asian Journal of Computer Science and Information Technology, Volume 2 No. 9, pp Acosta N. & Toloza J. (2012) Techniques to improve the GPS precision, International Journal of Advanced Computer Science and Applications, Volume 3 No. 8, pp ISBN

84 Posicionamiento WIFI con variaciones de Fingerprint Carlos KORNUTA 1, Nelson ACOSTA, Juan TOLOZA 2 INCA/INTIA - Facultad de Ciencias Exactas - UNICEN TANDIL - Argentina { ckornuta, nacosta, jmtoloza }@exa.unicen.edu.ar Abstract. Los sistemas de posicionamiento Indoor estiman la posición de un dispositivo móvil en un entorno cerrado con una precisión relativa. Existen diversas técnicas de posicionamiento, donde el parámetro mayormente utilizado es el RSSI (Received Signal Strength Indicator). En este artículo se analiza la técnica Fingerprint con la finalidad de estimar el margen de error obtenido con la distancia euclidiana como métrica principal. Se presentan variantes de la construcción de la base de datos Fingerprint analizando distintos valores estadísticos con la finalidad de comparar la precisión de diferentes indicadores. Keywords: Posicionamiento indoor, Localización indoor, RSSI, Fingerprint 1. Introducción En la actualidad, es necesario contar con mecanismos que posibiliten determinar la ubicación de un dispositivo móvil en el interior de un edificio. Algunos ejemplos de ellos son mapas interactivos de centros comerciales y museos, mapas guiados de campus universitarios, sistemas de monitorización de pacientes en hospitales y/o albergues de personas mayores [1]. Se descarta el uso de GPS, ya que, no puede ser utilizado en ambientes interiores, porque necesitan una línea de visión clara y sin obstáculos entre el dispositivo y un mínimo de tres satélites [2] [14]. La estimación de la posición relativa de un dispositivo móvil, en adelante DM, es el proceso mediante el cual se obtiene información sobre la posición, con respecto a referencias sobre un espacio predefinido [3]. Las técnicas para estimación de la posición Indoor, dependiendo la tecnología de sensores utilizada, son: Tiempo de Arribo (ToA), Ángulo de Arribo (AoA), Indicador de potencia de la señal (RSSI). Dentro de esta última, el algoritmo más utilizado para estimar la posición es Fingerprint [4]. En el año 2000, el sistema RADAR [5] obtiene una precisión media en el rango de 2-3 m. En 2003 el sistema LEASE [6] consigue una precisión de 2.1 m. En 2007, se utiliza la técnica de Fingerprint [7] para estimar la posición del DM en conjunto con un algoritmo de redes Bayesianas, logrando una precisión de 1.5 m. En [8] se presenta un sistema que 1 Becario CONICET Tipo I 2 Becario Postdoctoral CONICET ISBN

85 utiliza Fingerprint y el método de la distancia euclidiana con un algoritmo de mejora utilizando lógica difusa, en una primera instancia obtienen una precisión de 4.47 m y luego con lógica difusa 3 m. El sistema de posicionamiento EKAHAU [9] basado en el parámetro RSSI logra una precisión de 1-5 m dependiendo de las condiciones del entorno. En [10] se presenta un sistema basado en un algoritmo utilizando redes neuronales, logrando la precisión de 1-3 m. En este artículo se analizan diversas variantes de la construcción de la base de datos Fingerprint. La sección 2 muestra el funcionamiento de la localización usando Fingerprint y plantea nuestra propuesta, la 3 muestra la experimentación, en la 4 se analizan los datos, la 5 muestra el análisis de los datos y la 6 las conclusiones y futuros trabajos. 2. Localización utilizando FINGERPRINT El método de Fingerprint se basa en que cada posición dentro de un recinto tiene una única firma, compuesta por una tupla (P/L), en donde P contiene información acerca del patrón único y L información relativa a la posición dentro del edificio. La información relativa a la posición, puede ser representada en un formato de tupla de coordenadas o una variable representativa. Esta técnica requiere entrenamiento, donde se realiza el muestreo de cada una de las firmas [11]. En primer lugar, se debe diseñar un Radio Map [6], que es un mapa patrón conteniendo las posiciones especificas dentro del edificio y un vector de potencias RSSI que contiene todas las potencias de los Access Point, en adelante AP, alcanzados en cada posición. La creación de un Radio Map incluye: 1. En cada posición del escenario se muestrean los valores de potencia de señal (RSSI), armando un vector de potencias para cada posición, cuya dimensión depende de la cantidad de AP visibles. 2. Para cada sector del área que puede recibir señal de N puntos de acceso, se obtiene un vector de los RSSI de cada AP. 3. Para vincular la firma y la información de localización se utiliza un método determinístico, para encontrar la posición del vector más cercano, en muchos casos se usa la distancia Euclídeana. Para estimar la posición del DM, se capturan los valores de todos los AP visibles desde la posición que se quiere estimar. Los valores adquiridos son comparados con los valores obtenidos en el Radio Map para obtener las coordenadas de ubicación del dispositivo [12]. La base de datos Fingerprint es un resumen de los datos de la Radio Map, que facilita la ubicación minimizando el cálculo y reduce el error. Los algoritmos de estimación correlacionan los valores obtenidos entre la información de la localización y la base Fingerprint, para determinar la posición relativa del DM. El método determinístico más conocido es el vecino más próximo, donde se utilizan los vectores medios, los cuales contienen el promedio de los valores RSSI de cada AP en cada punto del mapa. ISBN

86 3. Creación del Radio Map y la base de datos Fingerprint La experimentación se realiza en el sector de becarios del instituto de investigación INTIA/INCA, de la Facultad de Ciencias Exactas de la Universidad Nacional del Centro de la Provincia de Buenos Aires. El área tiene una dimensión aproximada de 36 m 2. Para realizar las mediciones y captura de datos se divide el área correspondiente en un eje de coordenadas (fila, columna) (Figura 1), cada región del mapa tiene una separación de 90 cm con respecto al punto anterior. Figura 1. Ubicación de las coordenadas en el mapa La captura de datos se realiza usando IWLIST en Ubuntu El proceso de captura de datos para el armado del Radio Map (Figura 1) es: 1. Posicionamiento del DM en un punto de coordenadas del mapa. 2. Escaneo y captura de RSSI por 180 segundos para estabilizar la señal. 3. Escaneo, captura y almacenamiento de RSSI y SSID, de la señal de los diferentes AP que están al alcance, en esa posición por 90 segundos. 4. Traslado del dispositivo al siguiente punto de coordenadas del mapa, y se retoma en el punto (1) si no es el último. En la Figura 2 se visualiza la distribución de los AP. El sector de becarios del INTIA es el AP 4, y el edificio tiene 58 m de largo. Por cada punto de muestreo se obtienen 100 vectores de parámetros RSSI, conteniendo 11 valores correspondientes a los AP disponibles en el rango de alcance del DM. Por convención, cuando un AP se encuentra fuera del rango de alcance, se asigna el valor 0. Con los datos del Radio Map se construye la base de datos Fingerprint (formada por los valores promedio), y además se ha estudiado otros valores para representar cada AP en cada posición: ISBN

87 Media RSSI: la media aritmética de todas las observaciones del AP. Dupla Intercuartílica: Considerando el total de valores obtenidos por cada AP, se ordenan los datos en forma ascendente, luego se divide en 4 conjuntos con igual cantidad de elementos. Se eliminan los cuartiles extremos, y de los cuartiles centrales se calcula: o promedio y o moda aritmética. Moda: Se calcula la moda con el total de muestras obtenidas. Promedio de Dupla Intercuartílica: Se promedian los valores promedio y moda de la Dupla Intercuartílica. Figura 2. Distribución de los AP, denominados 1: chacra, 2: default, 3: inca, 4: inca2, 5: intia, 6: isistan-2, 7: pladema-2, 8: pladema-invitado, 9: slab, 10:unicen2, 11: wlbiolab. 4. Análisis de datos 1 Tomando como referencia el AP 3, que se encuentra a aproximadamente 15 m, 4 paredes de ladrillos y un durlock, del lugar donde se realiza la captura y muestreo de los valores correspondientes a la señal de los AP encontrados. Las variaciones con respecto a la potencia de la señal, analizando por filas, son las siguientes: Desde la posición inicial (1,1) en línea recta, cada 180 cm la potencia de la señal, disminuye en 2 dbm. En la posición (1,5), vuelve a su valor normal y luego vuelve a disminuir. Por lo que fluctúa entre -86 y -90. Si consideramos la fila 2 de coordenadas, el valor de la potencia de la señal, disminuye luego de los 270 cm en 2 dbm. La fila 3, el valor disminuye, en 360 cm en 2 dbm, y aumenta a -89 en el punto siguiente, para volver a su punto inicial en el siguiente par de coordenadas. La fila 4, el valor se mantiene constante, sin grandes variaciones, hasta el último punto, en el cual el valor de la potencia aumenta a -79. ISBN

88 La fila 5, desde la posición inicial, luego de 90 cm, el valor de la señal disminuye a -86, se mantiene estable y en el punto (5,4), vuelve a aumentar la potencia en 3 dbm y disminuye la misma a -92, y se mantiene estable en los valores iniciales. La fila 6, luego de 180 cm la señal aumenta 5 dbm y disminuye, alcanzando el valor -91, y regresa a los valores iniciales. En contraste con los valores obtenidos por el AP 4 que se encuentra dentro del mismo sector de muestreo. Los valores de la potencia de la señal, son los siguientes: Se comienza (1,1) con un valor inicial de -54, luego la señal fluctúa entre +- 9 dbm, a excepción del punto (1,6). La fila 2, existen fluctuaciones y variaciones menores que en el punto anterior, la señal oscila en un rango de 3 dbm, con la excepción del punto (2,5) que la señal disminuye 10 dbm y culmina con un valor aproximado al -55 dbm. La fila 3, varía entre -41 y -17 dbm, se estabiliza cerca de sus valores iniciales. La fila 4, varía entre -43 y -8 dbm en (4,3), en la posición (4,5) a 180 cm vuelve a estabilizarse en sus valores iniciales. La fila 5, varía entre -47 y -55 dbm, y entre -47 y -55 dbm, oscilando en 8 dbm La fila 6, varía entre -49 y -59 dbm, con una variación de +-10 dbm. Se infiere al efectuar un análisis de los datos que los valores de la señal fluctúan en un espectro más amplio, si el AP se encuentra a menor distancia física del punto de muestreo. Si el AP se encuentra más distante del punto de referencia, el valor de la señal no tiene grandes cambios, oscila en +-3 aproximadamente. En la Tabla 1 se presentan los valores de absorción de la señal Wifi según el Material [13], que influyen en la degradación del parámetro RSSI. Tabla 1. Atenuación de la potencia Wifi producida por los materiales a 2.4 GHz: Obstáculo Pérdida Adicional (db) (aprox.) Ventana no metálica (Vidrios) 3 Ventana Metálica 5 a 8 Pared Fina 5 a 8 Pared Media 10 Pared Gruesa (15 cm) 15 a 20 Pared muy gruesa (30 cm) 20 a 25 Piso o techo grueso 15 a 20 Piso o techo muy grueso 15 a 25 En la Tabla 2 se identifican 4 coordenadas principales dentro del mapa que corresponden a puntos determinados en los cuales podría existir una discrepancia de los valores y del conjunto de AP detectados, se seleccionan tres AP a modo ejemplo, identificando RSSI promedio, máximo y mínimo. ISBN

89 Tabla 2. Análisis de la variación de los AP Coordenadas AP Promedio Máximo Mínimo Análisis de Resultados Se posiciona el dispositivo en un punto del mapa (Figura 1) y se obtiene el vector de potencias de los AP visibles. Luego, con este vector patrón y con cada uno de los vectores de potencias almacenados (Media, Dupla intercuartílica, moda, promedio de dupla) se calcula la distancia euclidiana obteniendo las distancias a cada punto de coordenadas. Se determina la posición estimada como el menor valor que satisface la ecuación, es decir la menor distancia entre el conjunto de entrenamiento obtenido (base de datos Fingerprint) y el patrón de datos ingresado. 5.1 Posición (1,5): Distancias Euclidianas Figura 3. Gráfico de superficie PROMEDIOS posición (1,5) Considerando la Figura 3, con el patrón: [0, 0, 0, -89, -61, -59, -75, -75, -67, -89, 0] y realizando el cálculo con los vectores promedios, la sección que minimiza la distancia es la posición de coordenadas (1,2), en este caso podemos observar que existe un error de 1.80 m, el cual considerando la tabla 1, puede ser originado por las fluctuaciones de las ISBN

90 señales de los AP, producida por la atenuación provocada por la pared adyacente al punto de muestreo, provocando disminución de RSSI e impidiendo la visibilidad de un AP Posición (5,3) Distancias Euclidianas Figura 4. Gráfico de superficie PROMEDIOS posición (5,3) La Figura 4 muestra el vector patrón de la posición (5,3): [0,0, -91, -45, 0, -63, -81, - 83, -69, 0, -93]. La menor distancia obtenida por los promedios corresponde justamente a la posición 5.3, donde se observa un mínimo en el punto. Algunos vectores donde varía la señal de los AP más cercanos (3, 6 y 9); en un rango entre +- 2/4 dbm, la precisión, se reduce obteniendo la ubicación del DM en el punto (4,5) con un error de 1.7 m. Observando el plano presentado en la Figura 1, se advierte que en ese entorno no existen paredes adyacentes al punto de captura, ver ejemplo (1,5) Figura Posición (4,5) Distancias Euclidianas Figura 5. Gráfico de superficie MODA posición (4,5) ISBN

91 Distancias Euclidianas Figura 6. Gráfico de superficie PROMEDIO posición (4,5) Las Figuras 5 y 6 muestran el patrón: [-95, 0, -93, -43, 0, -57, -77, -75, -65, -89, 0], correspondiente a la posición (4,5). Ambos gráficos coinciden en la posición, sin embargo, la Figura 5 obtenido por el cálculo de la distancia de los vectores moda almacenados en la base de datos, proporciona una mejor representación, originando un valor mínimo absoluto en el punto de posicionamiento. La Figura 6 calculada en base al promedio tiene otro resultado bastante cercano. En ambos ejemplos no existen obstáculos como paredes o ventanas adyacentes que provoquen un aumento de la absorción de la señal. 6. Conclusiones y Futuros Trabajos Para analizar la tasa de error realizan 60 pruebas en cada punto del mapa (Figura 1), obteniendo el vector patrón para estimar la posición del DM. Del total de pruebas realizadas, se registró que el 70 % de las mismas obtenían las distancias presentadas en el gráfico de la Figura 7. Como se observa, en las coordenadas centrales del mapa es donde existe un menor margen de error, obteniendo como valor mínimo 1.2 m y como máximo 2.4 m. Al analizar los resultados, obtenidos en las secciones inferiores y superiores, se comprueba que el rango de errores varía entre m. De esta manera, se infiere que en las secciones donde existen determinados obstáculos adyacentes (paredes, ventanas, entre otros) los cuales causan el aumento de la absorción de la señal y del efecto multi-trayectoria es donde se presentan márgenes de errores mayores. Se ha documentado una experiencia donde se ha logrado localizar un DM con un menor error trabajando con promedio y moda, sobre una base de datos Fingerprint con variantes. Considerando toda la zona de análisis se logra posicionar con un error máximo promedio de 3.6 metros. En las zonas centrales, alejadas a unos 0.90 metros de las paredes, se logra posicionar con un error máximo de 1.7 metros. ISBN

92 La tecnología promete y se seguirá trabajando para reducir el error. Los próximos enfoques incluyen un método de votación para selección de la mejor técnica de forma automática, complementar el análisis considerando tiempo de vuelo de señal WIFI, pruebas en diversas oficinas, y pruebas en espacios abiertos. Figura 7. Errores obtenidos en el posicionamiento, donde se destaca cómo se incrementa el error cerca de las paredes Referencias [1] A. M. Ladd, K. E. Bekris, G. Marceau, A. Rudys, L. E. Kavraki, and D. S. Wallach, Roboticsbased location sensing using wireless ethernet. ACM International Conference on Mobile Computing and Networking (MOBICOM'02), New York, [2] G. M. Djuknic and R. E. Richton, Geolocation and assisted GPS, IEEE Computer. Vol. 34, Nro. 2, pp: [3] T. S. Rappaport, J. H. Reed, and B. D. Woerner, Position location using wireless communications on highways of the future, IEEE Communic. Vol. 34, Nro.10, pp: , [4] K. Pahlavan, X. Li, and J. P. Makela, Indoor geolocation science and technology, IEEE Communications Magazine., Vol. 40, Nro. 2, pp: , [5] P. Bahl and V. N. Padmanabhan. RADAR: An in-building RF based user location and tracking system, IEEE Infocom Vol.2, Nro. 1, pp: ISBN

93 [6] M. A. Youssef, A. Agrawala, and A. U. Shankar, WLAN location determination via clustering and probability distributions, in Proc. IEEE International Conference on Pervasive Computing and Communications, Fort Worth, [7] A. Teuber, B. Eissfeller, WLAN indoor positioning based on Euclidean distances and fuzzy logic, Proceedings of the 3rd Workshop on Positioning, Navigation and Communication (WPNC'06), Munich, Alemania, [8] Ekahau, Ekahau positioning engine 2.0; based wireless LAN positioning system, Ekahau Technology, Internal Report, [9] Roberto Battiti, Thang Lee Nhat, Alessandro Villani, Location-aware computing: a neural network model for determining location in wireless LANs, [10] Pahlavan, K., & Krishnamurthy, P. Principles of Wireless Networks - A Unified Approach, Prentice Hall ISBN-10: [11] Brachmann, F. A comparative analysis of standardized technologies for providing indoor geolocation functionality, Symposium on Computational Intelligence and Informatics (13 th CINTI), 2012 IEEE, Hungary, Budapest 2012 [12] P. Enge and P. Misra, Special issue on gps: The global positioning system, Proceedings of the IEEE.Pp: [13] Marcelo Najnudel, Estudo de propagação em ambientes fechados para o planejamento de wlans, Universidad Católica de Rio de Janeiro. Tesis [14] J. Toloza, N. Acosta, A. de Giusti. An approach to determine magnitude and direction error in gps system. Asian Journal of computer science And Information Technology. Vol. 2, Nro. 9, Pp: ISBN

94 Analysis of Radio Communication Solutions in Small and Isolated Communities under the IEEE Standard A. Arroyo Arzubi 1, A. Castro Lechtaler 1 y 3, A. Foti 4, R. Fusario 1, y 4, J. García Guibout 2 and L. Sens 4 1 Escuela Superior Técnica - Facultad de Ingeniería del Ejército - IESE, C1426, Buenos Aires; 2 Instituto Tecnológico Universitario - Universidad Nacional de Cuyo, M5500, Mendoza; 3 Universidad Nacional de Chilecito, F5360, Chilecito, La Rioja; 4 Universidad Tecnológica Nacional, C1042, Buenos Aires; República Argentina. {A. Arroyo Arzubi, arroyoarzubi@iese.edu.ar, A. Castro Lechtaler, acastro@iese.edu.ar, A. Foti, foti.antonio@gmail.com, R. Fusario, rfusario@speedy.com.ar, J. García Guibout, jgarcia@itu.uncu.edu.ar, L. Sens, lsens@frba.utn.edu.ar} Abstract. In recent years the use of wireless communications has increased significantly. Rural communities without cable network communication have found a solution in wireless technologies. Based on previous fieldwork, this paper analyzes software development of integration based technologies for communication equipment. It focuses on the feasibility of the IEEE standard as a solution to the wireless problem. Keywords: IEEE , White Spaces, Cognitive Radio, Rural Communications, Digital TV Broadcast. 1 Introduction In the framework of the Project Communitarian Private Networks [1], different technologies providing links to small and isolated communities have been analyzed and compared. These communities, with low population densities, hold no commercial interest to service providers [2], [3], [4]. Notwithstanding, several rural facilities maintain operations in these isolated areas, providing significant quantities of food products at different stages of manufacturing. They supply not only nearby cities, but also constitute an important source of export commodities and revenue for many countries. The geographic dispersion of these facilities interfere with cable communications either with copper pairs, coaxial or optic fiber cables due to high costs and maintenance problems. Consequently, the solution consists of establishing full duplex links via radio waves at a 30 to 70 km distance between antennas and at frequencies not restricted by government regulations [5], [6]. Towards the end of the 90s and beginning of this century, technical problems evolved side by side with their solutions. The process lead to the approval, on July 1 st, 2011, of the standard IEEE Cognitive Wireless RAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Policies and Procedures for Operation in the TV Bands [7]. ISBN

95 The present work analyzes the use of this type of links in the same area where our group is conducting fieldwork. 2 Previous Fieldwork and Testing of New Technologies The Project Communitarian Private Networks [5] explores different technologies providing communications to small and isolated rural communities with low population densities and without telephone services, whether these may be landlines or cellular. Hence, these communities do not have access to voice, data or internet networks. A small community which met the requirements of the Project was searched: an isolated and distant town where experiences can be appropriately implemented. The community Corral de Lorca, in the department of General Alvear, province of Mendoza was finally selected. Its location is shown in Figure 1. Figure 1. Geographic Location of Corral de Lorca The technologies under study were: Power Line Communications (PLC) [2, 3] and the standard [4]. Both experiences show that PLC technology is not recommended for outdoor links under the required conditions. The considered solution involves establishing a point to point link where one endpoint is located in the department s main city, General Alvear, with access to the PSTN network, and the other in the Corral de Lorca community, located in the southwest of the province of Mendoza, Argentina. Two Motorola Canopy platforms are used at bandwidths of 2.4 GHz and 5.7 GHz (similar to WiMax). At the Corral de Lorca node [6], phone services can be implemented through VoIP as well as to the Local Area Network and for Wireless Internet Services. The link is placed at a critical distance. Corral de Lorca is 70 kilometers from General Alvear in a straight line over a desert but with dense vegetation close to the base station area. To analyze the propagation issues the freeware Radio Mobile developed by Roger Coude [8] is used. ISBN

96 The outcome is not entirely satisfactory. Significant attenuation is registered due to the distance of the trans-horizon link and to the strong attenuation resulting from the dense vegetation at the outskirts of General Alvear. These factors contribute to a low value in the signal/noise ratio at the reception end in Corral de Lorca. The conclusions are: The link is studied as a typical case to solve the general problem of rural populations. Hence, it could be generalized later for the application of analogous situations. In these cases, the distance to cover should range between 60 to 70 kilometers. Coordinates and terrain conditions are detailed between the two endpoints. Estimates for different bandwidths are established, i.e. 2.4 GHz and 5.7 GHz. The distance between the endpoints (60 km) is greater than regular distances contemplated in the theory for the application of standard In addition, the analysis focuses on the fact that, in practice, transmitted signals in rural areas behave differently from those in urban settings because the former suffer less from noise spectrums. Radio Mobile software is considered to be a valuable tool in the design of radio electric links. As a result of these experiences, continuing work is focusing on the new standard. 3 Technical Problems and New Solutions 3.1 Introduction The boundaries between the fields of communications and computer science have merged over time. Several concepts used in the field of telecommunications are now encountered in computer science and vice versa. Also, methodological practices of computer science are an integral part of telecommunications nowadays. Consequently, today we refer to both disciplines as Information and Communications Technology - ICT 1 or as Teleinformatics, as referred to by European and American scholars. Moreover, by the end of the 90s and beginning of this century, wireless communications increased exponentially. For instance, currently the total number of mobile phone users exceeds the number of existing landlines. The pervasive use of mobile communications presents several technical difficulties, which in turn lead to the development of their consequent technical solutions. In the following section, the main changes of the advance in wireless technology are outlined. 1 Also known as TICs in Spanish ISBN

97 3.2 White Space and Congestion Bands Modern societies are increasingly relying on radio spectrum use. The pervasiveness of wireless services and communication devices (mobile phones, police communications, Wi-Fi and digital TV broadcasting) are examples of this dependency. It has become one of the most necessary resources of modern times [9]. Global demand growth for mobile data traffic has increased between 2011 and 2012 at a rate over 100%. The expected growth rate of this demand for the period 2008 and 2013 is estimated to average at 131% per year [10], exceeding Terabytes per month by the end of the current year. The intense spectrum use, up to 5 GHz, and more specifically at the coverage below 1 GHz, has lead to a thorough review of regulatory policies, along with a renewed interest in White Space research 2 [11]. Possible solutions to the increasing traffic, especially below 1 GHz, are: review and redesign of the regulatory framework, reduction of wireless services broadcasting, improved compression standards, replacement of various services by satellite or cable, dynamic spectrum access, and development of cognitive radio technologies. The latter is oriented to take advantage of under-utilized frequencies, temporary voids of primary signals, and different types of white space. The CEPT, European Conference of Postal and Telecommunications Administrations, has defined White Space as a label indicating a part of the spectrum, which is available for radio communication applications (service or system) at a given time in a given geographical area on a non-interfering or non-protected basis with regard to other services with a higher priority on a national basis [12]. Currently, several research efforts from different organizations, national and international, are working on white space. Cognitive Radio Technology (CRT) is considered another possibility to address the rising spectrum shortage. When fully operational, CRT could provide technologies for a variety of applications (rural broadband, public safety and emergency response, and urban frequency use). This technology will also have significant consequences for dynamic detection and spectrum management. 3.3 Software Defined Radio With the exponential growth of the ways and means by which people need to communicate through wireless communications, modifying radio devices easily and costeffectively has become critical. The technology Software Defined Radio (SDR 3 ) provides flexibility and profitability, as well as grants end users with comprehensive benefits from service providers and product developers [13]. The Wireless Innovation Forum defines Software Defined Radio as radio in which some or all of the physical layer functions are software defined. The radio is a device which transmits or receives wireless signals using a portion of the radio spectrum. Traditional radio devices exclusively based on hardware (e. g.: 2 Or white holes. 3 Also known as Software Radio. ISBN

98 mixers, filters, amplifiers, modulators/demodulators, and detectors) are limited because their features can be modified only by physical intervention. On the other hand, a Software Defined Radio (SDR) is implemented by means of software on a computer or embedded system. The concept is not new, but the rapidly evolving capabilities of digital electronics render practical many processes which used to be only theoretically feasible before [13]. Under this technology, the software proves to be efficient at a relatively inexpensive cost, with multimode and multiband wireless devices which can be continuously improved with software updates. In some cases, the software manages some or all of the functions to operate the radio equipment (including those of the physical layer processing). 3.4 Cognitive Radios 4 At the end of the decade of the 90s, Joseph Mitola 5 and Gerald Maguire, researchers from the Royal Institute of Technology 6 developed what they called Cognitive Radio, an improvement of their previous work on Software Defined Radio technology [14] [15], While Software Defined Radio offers great potential, it also requires arduous processing, limiting its flexibility and adequacy of network response. Cognitive Radio embedded in communications software, such as Radio Knowledge Representation Language - RKRL, can be considered an intelligent and efficient system for radio communications and protocols. Basically, it provides mechanisms based on the use of smart technology to optimize the spectrum. As mentioned in 3.2, the allocation of frequencies in a saturated spectrum is not optimal, originating White Space. A special range is assigned to the operators for the use of Digital TV Broadcasting. Those were the reasons which led to develop Cognitive Radio for wireless communications: to detect the parts of the radio frequency spectrum used inefficiently and to allow reuse without causing interference with the services assigned to them. The solution of these problems by variable frequency allocation, allows others to take advantage of unused parts of the spectrum. Using intelligent software, Cognitive Radio periodically scans the spectrum in search of white holes, detects the use given to each of them, and then determines whether it is reusable. The system operates by changing the transmitter parameters based on interaction with the environment. It has the ability and the technology to capture or sense the information from other radio equipment, providing spectrum awareness whereas reconfigurability enables the radio to be dynamically programmed. It can be programmed to transmit and receive on a variety of frequencies and to use different transmission access technologies supported by its hardware design. 4 Mitola defines cognitive as the mix of declarative and procedural knowledge in a self-aware learning system. 5 Joseph Mitola III received his doctorate in the Royal Institute with his thesis Cognitive Radio: An Integrated Agent Architecture for Software Defined Radio. 6 Located in Stockholm, Sweden. ISBN

99 These operating procedures show the interaction between hardware design and application software development. They also represent a typical teleinformatics application, as characterized by Minola in his thesis. 3.5 Digital TV Broadcasting Frequency spectrum use for TV broadcasting has varied since the first black and white broadcasts to the current digital high definition systems. Two bands are used: VHF (54 to 88 and 174 to 216 MHz) and UHF (512 to 806 MHz). Figure 2a. Province of Buenos Aires Figure 2b. Rest of the country In several South American countries, the Japanese standard Integrated Services Digital Broadcasting (ISDB) has been adopted with a few variants, such as the replacement of the compressing system MPEG-2 for MPEG-4 7. It was developed by the Association of Radio Industries and Businesses, known as ARIB, which promotes the efficient use of the spectrum. ISDB include four standards depending on the used medium: ISDB-S (satellite), ISDB-T (terrestrial), ISDB-C (cable) and 2.6 GHz mobile broadcasting. All of them are based on multiplexing with a transport stream structure and are capable of High- Definition Television (HDTV) and standard definition television. The name of the standard was chosen for its similarity to ISDN (Integrated Services Digital Network). Both allow the simultaneous transmission of multiple channels of data through the multiplexing method. In most cases, broadcasting stations have antennas reaching about 150 meters high, with significant coverage areas. In the case of Argentina, more that 50 broadcasting stations have been set up as of July of 2013, covering a significant area of the country. The plan is to cover practically all of the populated areas, giving service to 90% of the population. Figures 2a and 2b illustrate the cities where these stations have been installed. 7 International Services Digital Broadcast, Terrestrial Brazilian version ISDB-TB. ISBN

100 3.6 IEEE as a Solution for Rural Areas In Argentina, as in many countries with large rural areas, most cities are located within a range of 40 to 80 km apart in average. The Project Communitarian Private Networks focuses on evaluating solutions to the communication problems of rural areas, in particular, isolated communities with low population density. In our countries, the intensive use of spectrum and saturation in many of its frequency bands is due to wireless communications which has been the only feasible solution. The standard aims at using the vacancies in the TV spectrum. These frequencies are particularly suitable for remote areas where cables signal transmission are expensive or difficult to implement. Cables could only be replaced by costly satellite services. Thus, to implement a link using spare frequencies in these bands may be a practical and inexpensive solution. In our country, the TV on the VHF band will be eliminated in 2016 (analogic blackout), liberating most of the UHF band, considering that the Argentine National Authority for Broadcasting Services - AFSCA 8 has licensed only a few channels in the main cities (22 to 36). As the new digital TV technology allows several standard definition programs in the same bandwidth of one high definition channel, there is a significant spectrum saving, and we still can get lots of free frequencies (channels 38 to 69), mainly in small cities. It is an opportunity for this IEEE standard to be considered in the spectrum reallocation under study by the National Argentine Spectrum Authority - CNC IEEE Cognitive Wireless RAN Medium Access Control (MAC) and Physical Layer (PHY) 4.1. Introduction On July 1st 2011, the standard IEEE : Cognitive Wireless RAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Policies and Procedures for Operation in the TV Band was approved under the sponsorship of the LAN / MAN Standards Committee. The standard aims to set up criteria for the deployment of multiple interoperable products of the 802.xx series 10, offering fixed broadband access in various geographical areas, including especially those of low population density in rural areas, and avoiding interference to services working in the television broadcasting bands. The standard, commonly known as Wireless Regional Area Networks WRANs, has been developed to operate primarily as broadband access to data networks in rural areas. 8 Autoridad Federal de Servicios de Comunicación Audiovisual. 9 Comisión Nacional de Comunicaciones. 10 Wireless. ISBN

101 4.2. General features The standard includes cognitive radio techniques to moderate interference to other existing operators, to grant geolocation capability, to provide access to a database of incumbent services, and to detect the presence of other services through spectrumsensing technology, such as different WRAN systems or IEEE wireless beacons. The WRAN systems involve the use of channels ranging from 54 to 862 MHz in the VHF and UHF bands. The use of cognitive radio technologies scans for spare frequencies while avoiding interference with TV stations operating in the same bands. Figure : Working scheme Figure 3 illustrates a typical design. Assuming different quality of service (QoS), a Base Station - BS complying with the standard provides high-speed Internet services of up to 512 Customer Premise Equipments - CPEs, fixed or portable, or groups of devices Cognitive Radio Capability The cognitive radio capabilities supported by the standard are required to meet regulatory requirements for protection of frequency of incumbent s operators as well as to provide for efficient operation. They include: spectrum sensing, geolocation services, database access, registration and tracking of channel set management [8]. In areas where a computer with the IEEE standard is intended to operate, the detection of operational channels which could be subject to interference includes the following: Television broadcasts. Wireless microphone transmissions. Transmissions from protecting devices, such as a Wireless Beacon 12. Other transmissions such as medical telemetry that may need to be protected in the local regulatory domain. 11 IEEE : Standard to Enhance Harmful Interference Protection for Low-Power Licensed Devices Operating in the TV Broadcast Bands IEEE ISBN

102 4.4. Topology The standard topology is point-to-multipoint. The protocol works in a master/slave procedure, so that each CPE requires approval from the BS to transmit. The system functions with a Base Station - BS and multiple Customer Premise Equipment - CPEs. The base station controls the whole link, as well as its own performance and the CPE stations. It executes media access control, modulation of the RF transmission, coding, and selection of operating frequencies. The CPE uses an antenna system as shown in figure 4. It has a directional antenna similar to those used for transmitting/receiving TV signals, one sensing antenna that surveys the spectrum to determine which frequencies are available and a GPS antenna to determine the exact location of the transmitting station [8]. Figure 4. Customer Premise Equipment Antennas When the sensing antenna detects a band of the spectrum in use, the cognitive radio system changes the transmission features to avoid interference while granting priority to TV operators. The GPS determines the exact location of the detected signal, so that the system searches the database service of the regulatory agency and find free frequencies for frequency hopping. According to the received information, the base station changes or not the parameters of transmission/reception The IEEE 802 LAN/MAN Committee: Family of Wireless Standards The IEEE 802 LAN/MAN Standard Committee has developed a large and diverse family of wireless data communication standards. Since the first version to the present, they have dealt with different requirements in wireless communications. Figure 5 illustrates the most significant wireless standards and the relative position of the ISBN

103 Figure 5. Different Wireless Standards Developed by the IEEE 802 Committee The standard provides wireless broadband access in rural areas within a range of 30 up to a maximum of 100 km from a base station Physical Layer - PHY Similarly to the Asymmetric Digital Subscriber Line ADSL, the IEEE standard provides broadband access at a data transfer rate of 1.5 Mbps for uplink and 384 kbps for downlink (Figure 6). Figure 6. Different Wireless Standards Developed for the IEEE 802 Committee It works with multiplexing Orthogonal Frequency Division Multiple Access - OFDMA and defines twelve combinations of three modulations: QPSK - Quaternary Phase Shift Keying, 16-QAM, and 64-QAM Quadrature Amplitude Modulation; and convolutional coding for error handling with the procedure Forward Error Control - FEC. ISBN

104 Figure 7. Details the Different Features of the Standard 4.7. Medium Access Control Layer - MAC The MAC layer supports cognitive capabilities. Thus, it must have mechanisms for flexible and efficient data transmission. It must guarantee the reliable protection of services in the TV band and should be allowed to coexist with other systems. This layer is applicable to any region in the world and does not require countryspecific parameter sets. It is connection-oriented and provides flexibility in terms of QoS support. It also regulates downstream medium access by TDM, while the upstream is managed by an OFDMA system. The BS manages all the activities within its cell and the associated CPEs are under the control of the BS. 5. Conclusions Societies today have become highly dependent on the radio spectrum with the intensive use of wireless devices and communication services. Cognitive Radio, using intelligent software and taking advantage of white holes, may be a solution to spectrum saturation. The Project Communitarian Private Networks has focused on evaluating solutions to the communication problems of rural areas. It has concluded that wireless communications may be among the feasible solutions. Taking advantage that Argentina has a plan to cover a significant area of its territory with a TV broadcasting system, the conditions may be the ideal to introduce simultaneously the standard to the problem of rural communications. The Project Communitarian Private Networks continues its work on this line of research. ISBN

105 6. Acknowledgements The financial support provided by Agencia Nacional para la Promoción Científica y Tecnológica (Project PICTO 11- PICTO is gratefully acknowledged. 7. References [1] Antonio Castro Lechtaler (Director). PICTO Redes Privadas Comunitarias. Proyecto FONCyT, ANPCyT. Working Paper. [2] J. Garcia Guibout, C. García Garino, A. Castro Lechtaler, R. Fusario and Guillermo Sevilla. Physical and Link Layer in Power Line Communications Technologies. Proceedings of 13 th of Argentine Congress on Computer Science. ISBN pp. 56 a 67. Corrientes. October [3] J. García Guibout, C. García Garino, A. Castro Lechtaler, R. Fusario and Guillermo Sevilla. Power Line Communications in the Electric Network. Proceedings of 13 th of Argentine Congress on Computer Science ISBN pp. 68 a 79. Corrientes. October [4] J. García Guibout, C. García Garino, A. Castro Lechtaler and R. Fusario. Transmission voice over Proceedings of 14 th of Argentine Congress on Computer Science. ISBN pp. 307 a 318. Chilecito. October [5] A. Castro Lechtaler, A. Foti, R. Fusario, C. García Garino and J. García Guibout. Communication Access to Small and Remote Communities: The Corral de Lorca Project. Proceedings of 15 th of Argentine Congress on Computer Science. ISBN pp a Jujuy. October [6] A. Castro Lechtaler, A. Foti, C. García Garino, J. García Guibout, R. Fusario and A. Arroyo Arzubi. Proyecto Corral de Lorca: Una solución de conectividad a grupos poblacionales pequeños, aislados y distantes de centros urbanos. Proceedings de la Novena Conferencia Iberoamericana en Sistemas, Cibernética e Informática: CISCI Volume III - ISBN - 13: PP. 121 a 127. Orlando, USA. June [7] (Radio mobile software). [8] IEEE Cognitive Wireless RAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Policies and Procedures for Operation in the TV Bands. [9] Carlos Cordeiro, Kiran Challapali, and Dagnachew Birru, Sai Shankar N. IEEE : An Introduction to the First Wireless Standard based on Cognitive Radios Journal of Communications, Vol. 1, N 1, april [10] C. Gómez. Spectrum Regulation and Policy Officer Radiocommunication Bureau. ITU. Apia, Samoa. April [11] CEPT Report 24. A preliminary assessment of the feasibility of fitting new/future applications/services into non-harmonized spectrum of the digital dividend (namely the so-called "white spaces" between allotments. Report C from CEPT to the European Commission in response to the Mandate on: Technical considerations regarding harmonization options for the Digital Dividend. 1 July [12] [13] Dillinger, M; Madani, K; Alonistioti, N. Software Defined Radio: Architectures, Systems and Functions. Ed. Wiley & Sons, [14] J. Mitola, G. Maguire. Cognitive radio: making software radios more personal. IEEE Personal Communications Magazine, vol. 6, Nr. 4, pp , Aug [15] J. Mitola. Cognitive Radio: An Integrated Agent Architecture for Software Defined Radio. Dissertation submitted in partial fulfillment of the degree of Doctor of Technology. Royal Institute of Technology (KTH) - Teleinformatics. ISSN Sweden. May 8, ISBN

106 DJBot: Administrando las salas de PC evitando la consola Javier Díaz, Aldo Vizcaino, Alejandro Sabolansky y Einar Lanfranco LINTI Laboratorio de Investigación en Nuevas Tecnologías Informáticas, calle 50 y 120, La Plata, Argentina {javierd,asabolansky,avizcaino,einar}@linti.unlp.edu.ar Resumen La necesidad de optimizar las tareas de mantenimiento y uso remoto en las salas de PC de la Facultad de Informática de la UNLP dio lugar al desarrollo de DJBot: una aplicación web realizada en Python que permite ejecutar comandos en múltiples computadoras en un solo paso. En este documento se describen los motivos y el camino recorrido para llegar a la versión de la aplicación disponible hoy en día. DJBot se encuentra liberado como Software Libre para que cualquiera que desee pueda utilizarlo y contribuir en el proyecto. Desde su desarrollo evolucionó de ser una simple herramienta ejecutable en la línea de comandos a convertirse en una plataforma de administración centralizada que simplifica el mantenimiento, actualiza los equipos y permite ejecutar tareas programadas en la interfaz web. Palabras clave: Botnet, Django, Fabric, Python, Redis ISBN

107 1. El contexto La Facultad de Informática de la Universidad Nacional de La Plata (UNLP) actualmente cuenta con tres salas de PC, las cuales suman aproximadamente 80 equipos, que habitualmente se utilizan para dictar clases de las diferentes cátedras, realizar competencias, jornadas y otras actividades extracurriculares. Todos los equipos disponibles cuentan con dos sistemas operativos instalados: Microsoft Windows 7 y la distribución de GNU/Linux que se desarrolla en la Facultad, Lihuen GNU/Linux[2], y queda a criterio de las cátedras y de los alumnos cuál utilizar. Las tres salas se encuentran conectadas a la red troncal de la Facultad con acceso restringido desde el exterior, pero utilizando direccionamiento IPv4 público, lo que permite que los equipos sean identificados desde Internet. El grupo de trabajo que conforman los autores de este documento, además de encontrarse a cargo de la administración y mantenimiento de las tres salas de PC, tiene acceso a los routers y demás dispositivos de interconexión dado que también es el grupo responsable del mantenimiento del enlace troncal de datos de la Facultad. 2. La problemática Se pueden identificar dos cuestiones principales para resolver. Por un lado, la problemática relacionada con las cuestiones rutinarias. La gran cantidad de actividades académicas que requieren el uso diario de las salas hace que la disponibilidad de espacio temporal para realizar tareas de mantenimiento en cada computadora sea casi nulo. Peor aún es el escenario que se presenta habitualmente donde los trabajos no se hacen sobre un equipo sino que se quieren realizar tareas en todos los equipos de la sala en un solo paso. Por ejemplo, un cambio de configuración o la instalación de un software requerido por algún usuario debe realizarse sobre todos los equipos de la sala. Junto con la problemática planteada en relación a las tareas de mantenimiento, surgió la inquietud de cómo se podrían utilizar los equipos de la sala en los tiempos en que el equipamiento está ocioso para realizar alguna tarea específica como por ejemplo una prueba distribuida de carga a un servidor web. Hasta el día de hoy, para realizar cualquier tipo de tareas era necesario ejecutar el software en forma manual por el operador en cada una de las máquinas involucradas mediante la interacción directa con cada uno de los equipos. Para posibilitar y facilitar la realización en tiempo y forma de estas tareas se ha desarrollado DJBot, el proyecto que aquí se presenta. 3. La propuesta Como respuesta a las problemáticas planteadas en la sección anterior se ha desarrollado una aplicación de administración simplificada y centralizada de terminales GNU/Linux la cual se controla mediante una interfaz web. ISBN

108 Todo ello fue desarrollado siguiendo el principio DRY (Dont Repeat Yourself) mediante la reutilización de componentes de software libre. A modo de resumen, se puede decir que DJBot fue realizado utilizando Python como lenguaje de programación, junto con diversos componentes y bibliotecas, como el framework Django para la interfaz de usuario, la biblioteca Fabric y el protocolo SSH, entre otros. 4. El camino En un primer intento de solución, se utilizó Parallel SSH (PSSH)[1], una herramienta que permite entre otras cosas, realizar acciones mediante la ejecución de comandos y copiar archivos en diferentes computadoras en paralelo. PSSH se encuentra en los repositorios oficiales de la distribución Debian de GNU/Linux, lo que transitivamente hace que también esté disponible en Lihuen GNU/Linux y simplifica la puesta en producción del entorno. Por su forma de funcionamiento, esta aplicación requiere que las direcciones IP de las máquinas a las cuales les solicita acciones se encuentren listadas en un archivo de texto. Con este archivo se ejecutan conexiones por SSH a cada una de las direcciones listadas. Por los mecanismos de protección propios de SSH[4] aparecieron restricciones: SSH funciona utilizando clave pública-privada. Los clientes es decir, todas las máquinas cuya IP se encuentra en el archivo deben contar con la clave pública del que se conectará para autorizarlo en el archivo /authorized keys. Esto se solucionó propagando la clave pública a todos los equipos de todas las salas. SSH mantiene un archivo de confianza ( /.ssh/known hosts) donde guarda IP y clave pública de todos los pares con los con que dialoga en algún momento. Si ante un nuevo intento conexión el par no coincide, el servidor rechaza la conexión. Históricamente las máquinas de la Facultad estuvieron configuradas mediante un servicio de asignación dinámica de direcciones, de manera que la asignación de las direcciones IP se completaba en forma aleatoria. Con el servicio de SSH en funcionamiento, en cambio, el servicio de DHCP se modificó para que cada computadora pasara a tener una única IP fija y definitiva. Así, cuando se accedió por primera vez a las computadoras mediante SSH, se pudo generar el registro de identificación de cada máquina que asocia la computadora con su IP. Una vez concluida esta etapa, se contaba con un software funcional que cubría en forma parcial las expectativas planteadas ya que permitía la administración remota de las salas. Sin embargo, la herramienta seguía sin cumplir las expectativas en su totalidad, tanto las originales como las que fueron surgiendo a medida que el desarrollo avanzaba. En una segunda etapa del proyecto, surgió el desarrollo de una interfaz web como respuesta a la necesidad de que las tareas de mantenimiento y soporte pudieran ser realizadas desde cualquier lugar y por personal que no necesariamente ISBN

109 tenga acceso a la consola de administración. El hecho de que la implementación de PSSH exija la ejecución del intérprete de comandos BASH del sistema operativo GNU/Linux sumaba direccionamientos indirectos al proceso retrasando las tareas. Por esto, se comenzaron a estudiar alternativas y apareció la biblioteca Paramiko[5] utilizada por PSSH que no presenta la desventaja de los direccionamientos indirectos, pero solo permite establecer las conexiones de SSH de forma simple, lo cual dificulta el envio de órdenes a los clientes. Por ello se descartó, y buscando una alternativa se optó por Fabric[6], una biblioteca que reúne las características más útiles de PSSH y que utiliza Paramiko para realizar las conexiones SSH. En resumen, mediante Fabric se facilita la configuración de las tareas que se realizan en los equipos de las salas, facilitando la forma de indicar en qué terminales queremos ejecutar tareas, permitiendo utilizar distintos archivos de autenticación SSH y brindando la opción de elegir entre distintos usuarios, entre otras opciones. Como última instancia restaba decidir cómo desarrollar la parte web; hoy es muy difícil pensar en desarrollar una aplicación web utilizando el lenguaje únicamente sin utilizar algún framework de desarrollo que acorte y simplifique el proceso mediante la provision de componentes genéricos como ser filtros de seguridad, plugins de autenticación, acceso a la bases de datos o mecanismos de templates para el desarrollo de las interfaces de usuario. Si bien existen numerosos frameworks disponibles para el desarrollo, el elegido en este caso fue Django[7], uno de los frameworks más difundidos y utilizados en el mundo del software libre; Seleccionado en este caso, fundamentalmente porque tiene la particularidad al igual que la biblioteca Fabric, de estar codificado en el lenguaje de programación Python[8]. Una característica particular de DJBot es su modo de funcionamiento. Las redes de zombis, más conocidas como botnet en el área de la seguridad informática, son redes formadas por equipos que realizan tareas automatizadas,donde hay un controlador principal, que generalmente a través de Internet que indica qué hacer a una gran cantidad de equipos zombis que siguen las ordenes sin preguntar el por qué. El diseño particularmente útil y simple que permite el framework de desarrollo Django, sumado al concepto básico de las botnets, dieron lugar al nombre de esta aplicación: DJBot[11]. Como las partes que conforman su nombre lo indican, DJ hace mención a Django y Bot hace referencia al funcionamiento similar al de una botnet. Así, DJBot es un sistema que integra manejo de conexiones SSH con una interfaz web. 5. El modelo de datos El modelo de datos representado en la Figura 1 está compuesto por cuatro entidades: Aula, Computadora, Tarea y Configuraciones. La entidad Aula está conformada por múltiples computadoras y presenta las siguientes características principales: 1. nombre del aula, ISBN

110 Figura 1. Clases del modelo de datos 2. usuario, 3. dirección IP de una máquina intermediaria, 4. nombre de la placa de red de la máquina intermediaria, y 5. dirección de red. El nombre sirve para identificar el aula. La identificación mediante usuario permite realizar el inicio de sesión en cada computadora del aula. La dirección IP y el nombre de la interfaz de la máquina intermediaria, que por lo general es un router, permiten encender las computadoras de cada aula a través de la red (wake on LAN). La dirección de red, por su parte, se utiliza para asignar todas las máquinas encendidas dentro del rango de red indicado al aula específica. La entidad Computadora incluye los valores: 1. nombre de la computadora, 2. dirección MAC, 3. dirección IP, y 4. aula a la que pertenece. La entidad Tarea se define a través de: 1. nombre de la tarea, 2. conjunto de instrucciones, y 3. archivo opcional. La lista de instrucciones completa la tarea en su totalidad. El archivo opcional permite compartir información entre todas las computadoras del aula, y se utiliza cuando resulta más sencillo que hacer uso de las instrucciones de comandos. En la actualidad, la entidad Configuraciones se utiliza para definir valores predeterminados para las demás entidades. La clave SSH de las aulas, por ejemplo, está definida bajo la entidad Configuraciones. Sin embargo, en el futuro se ISBN