WARSO

VIII WORKSHOP ARQUITECTURA, REDES Y SISTEMAS OPERATIVOS - WARSO -

XIX Congreso Argentino de Ciencias de la Computación - CACIC 2013 : Octubre 2013, Mar del Plata, Argentina : organizadores : Red de Universidades con Carreras en Informática RedUNCI, Universidad CAECE / Armando De Giusti ... [et.al.] ; compilado por Jorge Finochietto ; ilustrado por María Florencia Scolari. - 1a ed. - Mar del Plata : Fundación de Altos Estudios en Ciencias Exactas, 2013.

E-Book.

ISBN 978-987-23963-1-2 1. Ciencias de la Computación. I. De Giusti, Armando II. Finochietto, Jorge, comp. III. Scolari, María Florencia, ilus.

CDD 005.3 Fecha de catalogación: 03/10/2013

AUTORIDADES DE LA REDUNCI Coordinador Titular De Giusti Armando (UNLP) 2012-2014 Coordinador Alterno Simari Guillermo (UNS) 2012-2014 Junta Directiva Feierherd Guillermo (UNTF) 2012-2014 Padovani Hugo (UM) 2012-2014 Estayno Marcelo (UNLZ) 2012-2014 Esquivel Susana (UNSL) 2012-2014 Alfonso Hugo (UNLaPampa) 2012-2013 Acosta Nelson (UNCPBA) 2012-2013 Finochietto, Jorge (UCAECE) 2012-2013 Kuna Horacio (UNMisiones) 2012-2013 Secretarias Secretaría Administrativa: Ardenghi Jorge (UNS) Secretaría Académica: Spositto Osvaldo (UNLaMatanza) Secretaría de Congresos, Publicaciones y Difusión: Pesado Patricia (UNLP) Secretaría de Asuntos Reglamentarios: Bursztyn Andrés (UTN)

AUTORIDADES DE LA UNIVERSIDAD CAECE Rector Dr. Edgardo Bosch Vicerrector Académico Dr. Carlos A. Lac Prugent Vicerrector de Gestión y Desarrollo Educativo Dr. Leonardo Gargiulo Vicerrector de Gestión Administrativa Mg. Fernando del Campo Vicerrectora de la Subsede Mar del Plata: Mg. Lic. María Alejandra Cormons Secretaria Académica: Lic. Mariana A. Ortega Secretario Académico de la Subsede Mar del Plata Esp. Lic. Jorge Finochietto Director de Gestión Institucional de la Subsede Mar del Plata Esp. Lic. Gustavo Bacigalupo Coordinador de Carreras de Lic. e Ing. en Sistemas Esp. Lic. Jorge Finochietto

COMITÉ ORGANIZADOR LOCAL Presidente Esp. Lic. Jorge Finochietto Miembros Esp. Lic. Gustavo Bacigalupo Mg. Lic. Lucia Malbernat Lic. Analía Varela Lic. Florencia Scolari C.C. María Isabel Meijome CP Mayra Fullana Lic. Cecilia Pellerini Lic. Juan Pablo Vives Lic. Luciano Wehrli

Escuela Internacional de Informática (EII) Directora Dra. Alicia Mon Coordinación CC. María Isabel Meijome

comité académico Universidad

Representante

Universidad de Buenos Aires

Echeverria, Adriana (Ingeniería) – Fernández

Universidad Nacional de La Plata

Slezak, Diego (Cs. Exactas)

Universidad Nacional del Sur

De Giusti, Armando

Universidad Nacional de San Luis

Simari, Guillermo

Universidad Nacional del Centro de la

Esquivel, Susana

Provincia de Buenos Aires

Acosta, Nelson

Universidad Nacional del Comahue

Vaucheret, Claudio

Universidad Nacional de La Matanza

Spositto, Osvaldo

Universidad Nacional de La Pampa

Alfonso, Hugo

Universidad Nacional Lomas de Zamora

Estayno, Marcelo

Universidad Nacional de Tierra del Fuego

Feierherd, Guillermo

Universidad Nacional de Salta

Gil, Gustavo

Universidad Nacional Patagonia Austral

Márquez, María Eugenia

Universidad Tecnológica Nacional

Leone, Horacio

Universidad Nacional de San Juan

Otazú, Alejandra

Universidad Autónoma de Entre Ríos

Aranguren, Silvia

Universidad Nacional Patagonia San Juan

Buckle, Carlos

Bosco Universidad Nacional de Entre Ríos

Tugnarelli, Mónica

Universidad Nacional del Nordeste

Dapozo, Gladys

Universidad Nacional de Rosario

Kantor, Raúl

Universidad Nacional de Misiones

Kuna, Horacio

Universidad Nacional del Noroeste de la

Russo, Claudia

Provincia de Buenos Aires Universidad Nacional de Chilecito

Carmona, Fernanda

Universidad Nacional de Lanús

García Martínez, Ramón

comité académico Universidad

Representante

Universidad Nacional de Santiago del Estero

Durán, Elena

Escuela Superior del Ejército

Castro Lechstaler Antonio

Universidad Nacional del Litoral

Loyarte, Horacio

Universidad Nacional de Rio Cuarto

Arroyo, Marcelo

Universidad Nacional de Córdoba

Brandán Briones, Laura

Universidad Nacional de Jujuy

Paganini, José

Universidad Nacional de Río Negro

Vivas, Luis

Universidad Nacional de Villa María

Prato, Laura

Universidad Nacional de Luján

Scucimarri, Jorge

Universidad Nacional de Catamarca

Barrera, María Alejandra

Universidad Nacional de La Rioja

Nadal, Claudio

Universidad Nacional de Tres de Febrero

Cataldi, Zulma

Universidad Nacional de Tucumán

Luccioni, Griselda

Universidad Nacional Arturo Jauretche

Morales, Martín

Universidad Nacional del Chaco Austral

Zachman, Patricia

Universidad de Morón

Padovani, Hugo René

Universidad Abierta Interamericana

De Vincenzi, Marcelo

Universidad de Belgrano

Guerci, Alberto

Universidad Kennedy

Foti, Antonio

Universidad Adventista del Plata

Bournissen, Juan

Universidad CAECE

Finochietto, Jorge

Universidad de Palermo

Ditada, Esteban

Universidad Católica Argentina - Rosario

Grieco, Sebastián

Universidad del Salvador

Zanitti, Marcelo

Universidad del Aconcagua

Gimenez, Rosana

Universidad Gastón Dachary

Belloni, Edgardo

Universidad del CEMA

Guglianone, Ariadna

Universidad Austral

Robiolo, Gabriela

comité científico Coordinación Armando De Giusti (UNLP) - Guillermo Simari (UNS) Abásolo, María José (Argentina) Acosta, Nelson (Argentina) Aguirre Jorge Ramió (España) Alfonso, Hugo (Argentina) Ardenghi, Jorge (Argentina) Baldasarri Sandra (España) Balladini, Javier (Argentina) Bertone, Rodolfo (Argentina) Bría, Oscar (Argentina) Brisaboa, Nieves (España) Bursztyn, Andrés (Argentina) Cañas, Alberto (EE.UU) Casali, Ana (Argentina) Castro Lechtaller, Antonio (Argentina) Castro, Silvia (Argentina) Cechich, Alejandra (Argentina) Coello Coello, Carlos (México) Constantini, Roberto (Argentina) Dapozo, Gladys (Argentina) De Vicenzi, Marcelo (Argentina) Deco, Claudia (Argentina) Depetris, Beatriz (Argentina) Diaz, Javier (Argentina) Dix, Juerguen (Alemania) Doallo, Ramón (España) Docampo, Domingo Echaiz, Javier (Argentina) Esquivel, Susana (Argentina) Estayno, Marcelo (Argentina) Estevez, Elsa (Naciones Unidas) Falappa, Marcelo (Argentina) Feierherd, Guillermo (Argentina) Ferreti, Edgardo (Argentina) Fillottrani, Pablo (Argentina) Fleischman, William (EEUU) García Garino, Carlos (Argentina) García Villalba, Javier (España) Género, Marcela (España) Giacomantone, Javier (Argentina) Gómez, Sergio (Argentina) Guerrero, Roberto (Argentina) Henning Gabriela (Argentina)

Janowski, Tomasz (Naciones Unidas) Kantor, Raul (Argentina) Kuna, Horacio (Argentina) Lanzarini, Laura (Argentina) Leguizamón, Guillermo (Argentina) Loui, Ronald Prescott (EEUU) Luque, Emilio (España) Madoz, Cristina (Argentina) Malbran, Maria (Argentina) Malverti, Alejandra (Argentina) Manresa-Yee, Cristina (España) Marín, Mauricio (Chile) Motz, Regina (Uruguay) Naiouf, Marcelo (Argentina) Navarro Martín, Antonio (España) Olivas Varela, José Ángel (España) Orozco Javier (Argentina) Padovani, Hugo (Argentina) Pardo, Álvaro (Uruguay) Pesado, Patricia (Argentina) Piattini, Mario (España) Piccoli, María Fabiana (Argentina) Printista, Marcela (Argentina) Ramón, Hugo (Argentina) Reyes, Nora (Argentina) Riesco, Daniel (Argentina) Rodríguez, Ricardo (Argentina) Roig Vila, Rosabel (España) Rossi, Gustavo (Argentina) Rosso, Paolo (España) Rueda, Sonia (Argentina) Sanz, Cecilia (Argentina) Spositto, Osvaldo (Argentina) Steinmetz, Ralf (Alemania) Suppi, Remo (España) Tarouco, Liane (Brasil) Tirado, Francisco (España) Vendrell, Eduardo (España) Vénere, Marcelo (Argentina) Villagarcia Wanza, Horacio (Arg.) Zamarro, José Miguel (España)

VIII Workshop Arquitectura, Redes y Sistemas Operativos - WARSO -

ID

Trabajo

Autores

5600

Análisis de las prestaciones de 802.11e en redes MANET

María Antonia Murazzo (UNSJ), Nelson R. Rodriguez (UNSJ), Daniela A. Villafañe (UNSJ)

5777

Caso de estudio de comunicaciones seguras sobre redes móviles ad hoc

Sergio H. Rocabado Moreno (UNSa), Daniel Arias Figueroa (UNSa), Ernesto Sánchez (UNSa), Javier Díaz (UNLP)

5648

Estudio del desempeño de OLSR en una red mallada inalámbrica en un escenario real

Eduardo Rodríguez (UCA), Claudia Deco (UCA), Luciana Burzacca (UCA), Mauro Petinari (UCA)

5652

NetworkDCQ: A Multi - platform Networking Framework For Mobile Applications

Federico Cristina (UNLP), Sebastián Dapoto (UNLP), Fernando G. Tinetti (UNLP), Pablo Thomas (UNLP), Patricia Pesado (UNLP)

5669

Estimación de “H” con transformada ondita

Luis Marrone (UNLP), Reinaldo Scappini (UTN-FRRe)

5752

IP Core Para Redes de Petri con Tiempo

Orlando Micolini (UNC), Julian Nonino (UNC), Carlos Renzo Pisetta (UNC)

5836

Analysis of Radio Communication Solutions in Small and Isolated Communities under the IEEE 802.22 Standard

Alejandro Arroyo Arzubi (EST-IESE), Antonio Castro Letchtaler (IESE), Antonio Foti (UTN), J. Garcia Guibout (UNCUYO), Rubén Jorge Fusario (UBA), L. Sens (UTN)

5834

Posicionamiento indoor determinado por la distancia en función de la potencia medida de balizas bluetooth

Marcelo Marinelli (UNaM), Juan Toloza (UNCPBA), Nelson Acosta (UNCPBA)

VIII Workshop Arquitectura, Redes y Sistemas Operativos - WARSO -

ID

Trabajo

Autores

5835

Posicionamiento WIFI con variaciones de Fingerprint

Carlos Kornuta (UNCPBA), Nelson Acosta (UNCPBA), Juan Toloza (UNCPBA)

5693

Monitoreo remoto de sistemas y redes para la auditoria informática

María Elena Ciolli (IUA), Claudio Porchietto (IUA), Roberto Rossi (IUA), Juan Sapolski (IUA)

5863

DJBot: Administrando las salas de PC evitando la consola

Javier Díaz (UNLP), Aldo Vizcaino (UNLP), Alejandro Sabolansky (UNLP), Einar Felipe Lanfranco (UNLP)

Análisis de las prestaciones de 802.11e en redes MANET María Murazzo1*, Nelson Rodríguez2*, Daniela Villafañe3* 1

marite@unsj-cuim.edu.ar, 2nelson@iinfo.unsj.edu.ar, 3villafañ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 802.11e, para analizar el retardo y la sobrecarga que sufren las transmisiones en ambientes con baja y alta granularidad de nodos.

Keywords: MANET, QoS, 802.11e, 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.

1046

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.

1047

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

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 802.11e 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 802.11e no hay necesidad de sincronizarse con los nodos de la ruta seleccionada. Por otra parte, al ser

1048

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 802.11e 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 802.11e 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 802.11e [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

1049

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

1050

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 802.11e. 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 802.11e, 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

1051

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 802.11e 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 802.11e. 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).

1052

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

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 802.11e no estaba implementado fue de 4122 paquetes (±3104 paquetes), mientras que cuando no se implementó se obtuvo un promedio de 2561 paquetes (±1294 paquetes).

1053

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 802.11e 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 802.11e. 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 802.11e, 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 802.11e, la estabilidad cuando la granularidad es baja no es un factor

1054

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 802.11e 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 – 2007.

[2] Kim, Anbin. “QoS support for advanced multimedia systems”. Information Networking (ICOIN), 2012 International Conference.Page(s): 453 - 456 [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 802.11e 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 Ns2”. National Institute of Technology, Rourkela 2009.

1055

Caso de estudio de comunicaciones seguras sobre redes móviles ad hoc Sergio H. Rocabado Moreno1, Daniel Arias Figueroa1, Ernesto Sánchez1, Javier Díaz2 2

1 C.I.D.I.A. – Centro de Investigación y Desarrollo en Informática Aplicada (UNSa) L.IN.T.I. – Laboratorio de Investigación en Nuevas Tecnologías Informáticas (UNLP) 1 srocabad@cidia.unsa.edu.ar, 1daaf@cidia.unsa.edu.ar, 1esanchez@cidia.unsa.edu.ar, 2 jdiaz@unlp.edu.ar

Resumen. En este trabajo se presenta el estudio de un caso de integración de una MANET desplegada en zona remota a una red de infraestructura, buscando un equilibrio entre el nivel de seguridad y el consumo de recursos como la energía y el ancho de banda. Se implementaron canales de comunicación extremo a extremo, entre un nodo de la MANET y el servidor de infraestructura. Inicialmente se efectuaron pruebas inyectando tráfico de datos sobre un canal “no seguro”, con la finalidad de obtener métricas de referencia como latencia, throughput y consumo de energía. Luego se configuraron canales “seguros” sobre los que se realizaron las mismas pruebas utilizando protocolos como IPSEC y SSL/TLS. Las métricas obtenidas utilizando canales seguros fueron comparadas con las de referencia para determinar las diferencias de consumo de recursos introducidas por la seguridad.

Palabras Clave: MANET, Latencia, Energía, Throughput, IPSec, SSL, TLS, Bluetooth, GPRS.

1. Introducción Una red móvil ad-hoc o MANET (Mobile Ad hoc NETworks en inglés) [1] es una colección de nodos inalámbricos móviles que se comunican de manera espontánea y autoorganizada constituyendo una red temporal sin la ayuda de ninguna infraestructura preestablecida (como puntos de acceso WiFi o torres de estaciones base celulares) ni administración centralizada.

Por sus características las MANET constituyen una tecnología ideal para facilitar servicios de comunicación a dispositivos móviles en zonas remotas donde no es posible montar y configurar redes de infraestructura debido a inconvenientes físicos y recursos limitados, como la energía y/o cobertura de red celular.

Una ventaja adicional de este tipo de redes es la posibilidad de integrarlas a redes de infraestructura con diferentes fines, entre otros podemos mencionar, el acceso a Internet y a sistemas de información de una intranet desde los dispositivos móviles que forman parte de la MANET. Las características intrínsecas de este tipo de redes (incluyendo autoconfiguración, ausencia de infraestructura, movilidad de los nodos, topología dinámica, ancho de banda limitado, falta de seguridad, conservación de

1056

energía, entre otras), plantean exigencias que deben resolverse antes de realizar la integración [2].

Nuestra investigación se enfoca en los siguientes aspectos: - Seguridad. Las redes móviles utilizan un medio compartido (aire) para transmitir los datos y se encuentran expuestas a “ataques” o accesos no autorizados, y por esta razón se hace necesario utilizar protocolos de seguridad que permitan una integración “segura” de los dispositivos móviles a la red de infraestructura, garantizando el cumplimiento de los siguientes aspectos de seguridad: Confidencialidad, integridad, autenticación y no repudio.

- Conservación de Energía. Los dispositivos móviles que conforman la MANET tienen capacidad limitada de energía y pocas posibilidades para recarga de baterías cuando se encuentran en zonas remotas de recursos energéticos limitados, por lo tanto se debe optimizar el consumo de energía.

- Ancho de banda limitado. La integración de una MANET en zona remota a una red de infraestructura requiere el uso de la red celular. En este tipo de zonas la cobertura de red celular es muy baja y debido a ello proporciona un ancho de banda reducido y variable.

Los tres aspectos son importantes y están directamente relacionados, se debe tener en cuenta que la implementación de un protocolo de seguridad implica un consumo de energía adicional por tres motivos: 1. Se incrementa el uso de CPU y memoria para realizar cálculos, 2. Se generan encabezados adicionales (overhead) que deben ser transmitidos y 3. Se intercambian mensajes para el establecimiento de canales de comunicación seguros.

Por otra parte, la implementación de niveles de seguridad elevados implica un aumento en el consumo de energía en los nodos móviles que reduce drásticamente el tiempo de vida de la red, y un consumo adicional de ancho de banda que puede comprometer el normal funcionamiento de las aplicaciones. Debido a estas razones se hace necesario establecer un compromiso entre seguridad y consumo de recursos.

En este trabajo se presenta el estudio de un caso de integración de una MANET, desplegada en una zona remota, a una red de infraestructura. El objetivo principal es el de proporcionar, a los nodos de la red ad hoc, acceso “seguro” a un servidor de la red de infraestructura, sin comprometer recursos como ancho de banda y energía que son limitados en la zona de despliegue. Para ello, se implemento un escenario de pruebas que comprende el despliegue de una MANET en zona remota y la integración de la misma a una red de infraestructura a través de la red celular. Sobre el escenario propuesto se establecieron canales de comunicación extremo a extremo, entre un nodo de la MANET y un servidor de infraestructura. Inicialmente, se realizaron pruebas inyectando tráfico de datos sobre un canal “no seguro” para obtener valores de referencia para latencia, throughput y consumo de energía. Luego, se efectuaron las mismas pruebas utilizando canales de comunicación “seguros” configurados sobre protocolos IPSEC y SSL/TLS. Los resultados obtenidos utilizando canales “seguros” fueron comparados con los valores de referencia para determinar las diferencias de consumo de recursos. Las desviaciones que surgieron de estas comparaciones, permitieron: - Establecer el consumo adicional de recursos generado por el uso de protocolos seguros.

1057

- Realizar un estudio comparativo de rendimiento, entre diferentes configuraciones de protocolos de seguridad.

- Determinar que protocolo seguro se adapta mejor a este tipo de entornos.

2 Trabajos previos del grupo de investigación En [3], se desplegó un escenario de pruebas indoor sin considerar condiciones externas como distancia, interferencias y otras. Se efectuaron mediciones sobre un canal “no seguro” y luego sobre un canal “seguro”, el aseguramiento del canal se implemento utilizando diferentes configuraciones del protocolo IPSec en modo transporte (extremo a extremo). En los resultados se presentan gráficos comparativos de consumo de energía entre las diferentes configuraciones de seguridad.

En [4], continuamos con esta línea de investigación, utilizando IPSec para el aseguramiento del canal de comunicaciones, esta vez sobre un escenario de pruebas outdoor afectado por factores externos que disminuyen el rendimiento e incrementan el consumo de recursos en los nodos de la red ad hoc. En el desarrollo de la publicación, se fundamenta la elección de Bluetooth como tecnología de soporte para la formación de la MANET remota y de GSM/GPRS para la integración de la misma a la red de infraestructura. Entre los resultados se presentan gráficos que muestran el consumo de energía para cada configuración de canal y la distribución del consumo entre los siguientes ítems: Establecimiento de sesión, encriptación, autenticación y transmisión.

En [5], se describe una experiencia del uso de MANETs en zonas rurales de recursos limitados (energía y ancho de banda). En el trabajo de campo realizado, se desplegaron MANETs de bajo consumo en escuelas rurales, con la finalidad de facilitar a docentes y alumnos el acceso a contenidos m-learning instalados en un servidor de infraestructura. Se consiguió mantener el rendimiento de la MANET dentro niveles aceptables de eficiencia y sin comprometer los recursos, lo que posibilito un funcionamiento correcto de las estrategias de m-learning en este tipo de zonas. Entre las conclusiones de esta publicación se destaca la siguiente: “El uso de las MANETs es efectivo y eficiente para el desarrollo de experiencias de m-learning en zonas de recursos energéticos limitados”.

3. Escenario de pruebas En la Figura 1 se observa la representación gráfica del escenario implementado para realizar las pruebas y mediciones. En el mismo se conecta una MANET, desplegada en zona remota, a la Intranet del campus universitario de la UNSa, a través de la red celular (GSM/GPRS). Los dispositivos móviles (nodos) de la MANET se conectan al servidor “testing” utilizando un canal de comunicación TCP/IP extremo a extremo (end to end). El tráfico entre el nodo móvil y el servidor se gestiona a través de uno de los nodos que actúa como Gateway entre la MANET y la red celular. Este nodo es el encargado de enviar los paquetes de datos hacia los routers de la red celular; desde

1058

donde y a través de Internet son encaminados a la intranet para ser entregados al servidor.

Internet

GSM - GPRS Router

Gateway Bluetooth/GPRS

DMZ - UNSa

CANAL EXTREMO A EXTREMO

Nodo Cliente

Servidor Testing

INTRANET (Universidad Nacional de Salta)

MANET SUBORDINADA (Desplegada en zona remota)

Figura 1. Escenario de pruebas

La conexión del dispositivo móvil cliente al punto de acceso a la red (NAP Network Access Point) se realizó utilizando el perfil PAN (Personal Área Network) [6] del estándar Bluetooth [7]. El punto de acceso a la red se configuro sobre el nodo Gateway utilizando la funcionalidad “Bluetooth Tethering” de Android, que utiliza el Framework netfilter e iptables para implementar un puente entre la PAN bluetooth y la red GSM/GPRS [8].

El canal de comunicación provee comunicación TCP/IP, extremo a extremo, entre el nodo cliente y el servidor “Testing”. En el trayecto los datagramas IP son encapsulados en BNEP [9] por la red Bluetooth y GTP [10] por la red GPRS. GSM - GPRS

Internet

GTP Header

Gateway Bluetooth/GPRS

UDP/TCP Header

IP Header

Payload

IP over GPRS GPRS Tunneling Protocol Router

NAP (Network Access Point)

DMZ - UNSa Nodo cliente

BNEP Header

IP Header

Payload

IP over Bluetooth Bluetooth Network Encapsulation Protocol

Servidor Testing

INTRANET (Universidad Nacional de Salta)

Figura 2. Comunicación extremo a extremo

La Figura 2 ilustra el envío de un datagrama IP desde el nodo móvil hasta el servidor de la intranet siguiendo los siguientes pasos: 1.

2.

3.

El nodo móvil envía el datagrama IP, encapsulado en BNEP [9], al punto de acceso a la red (NAP).

El NAP transmite el datagrama al SGSN de la red GPRS, desde donde viaja al GGSN encapsulado en GTP [10].

El GGSN re-envía el datagrama a Internet, por donde viaja hasta llegar al router frontera de la red destino.

1059

4.

El router frontera de la red destino encamina el datagrama hacia el servidor, encapsulado en una trama Ethernet.

3.1 Configuración del nodo cliente La configuración del dispositivo móvil con el cual se realizaron las pruebas, es la siguiente: Equipo: CPU: Chipset: RAM: SO: Root: Bluetooth: Bateria:

Samsung I9300 Galaxy S III Quad-core 1.4 GHz Cortex-A9 Exynos 4412 Quad 1024MB RAM. Android OS ver. 4.1.2 (Jelly Bean) SI ver 3.0 Lítio-íon, 2100 mAh, 3.7 v.

Este equipo fue especialmente preparado para minimizar el consumo de batería, se procedió entonces a: desinstalar las aplicaciones no indispensables para su funcionamiento, deshabilitar dispositivos de hardware no utilizados en las pruebas y habilitar el modo de bajo consumo.

4. Métricas y aplicaciones elegidas para efectuar las mediciones Para medir el rendimiento del canal de comunicaciones extremo a extremo, entre el nodo cliente y el servidor, se eligieron las siguientes métricas: Latencia, Throughput y Consumo de energía. En la tabla 1 se muestran las aplicaciones, del lado del cliente y del lado del servidor, que fueron utilizadas para obtener las métricas.

Tabla 1. Aplicaciones utilizadas para obtener las métricas

Métrica Latencia ICMP Latencia HTTP Throughput TCP Throughput HTTP Throughput FTP Consumo de energía

Aplicación Cliente Busybox Ping [11] HTTPing [12] Iperf Client [13] Busybox Wget [11] Busybox Wget [11] Powertutor [14]

Aplicación Servidor Windows Stack TCP/IP HTTP Server (IIS6) Iperf Server HTTP Server (IIS6) FTP Server (Filezilla) ------------------

5. Configuraciones de canal Los canales fueron divididos en 2 grupos: 1. Canal no seguro y 2. Canal seguro basado en VPN (L2TP/IPSEC, OPENVPN SSL/TLS y OPENVPN SSL/TLS con compresión LZO). La tabla 2 resume las aplicaciones utilizadas para la implementación de los canales.

1060

Para establecer un canal de comunicación NO seguro, alcanza con brindar transporte IP entre el nodo cliente y el servidor (ver figura 2), mientras que para el establecimiento de canales seguros se requiere el uso de protocolos seguros como IPSec y SSL/TLS. Tabla 2. Configuraciones de seguridad (Cliente/Servidor)

Protocolo seguro

Cliente (Android)

Servidor (Windows)

Ninguno IPSEC SSL/TLS SSL/TLS/LZO

N/A CLIENTE L2TP/IPSEC OPENVPN Client [15] OPENVPN Client [15]

N/A RRAS L2TP/IPSEC OPENVPN Server [16] OPENVPN Server[16]

CANAL No seguro Seguro

El canal seguro IPSec se implemento utilizando el protocolo L2TP encapsulado en IPSec [17]. IPSec se configuro en modo transporte utilizando una asociación de seguridad (SA) entre el nodo cliente y el servidor. Elegimos: 1. El algoritmo RSA para la autenticación mutua, entre el nodo cliente y el servidor 2. El algoritmo SHA1 para calcular el código de autenticación de mensaje (MAC), utilizado para verificar la integridad de los mensajes y 3. El algoritmo de encriptación 3DES para la confidencialidad.

El canal seguro SSL/TLS [18] se configuro utilizando la aplicación OPENVPN con y sin compresión LZO [19]. Elegimos: Autenticación RSA de tipo desafío respuesta para el servidor y autenticación RSA para el nodo cliente, HMAC-SHA1 para la integridad y 3DES para la confidencialidad.

La gestión de lo certificados utilizados por los protocolos seguros, fue realizada por una CA montada en el servidor “Testing”.

Tabla 3. Protocolos y algoritmos utilizados para la implementación de canales seguros

Canal

Protocolo

Autenticación

Cifrado

Integridad

Compresión

NO Seguro Seguro L2TP/IPSEC Seguro OPENVPN Seguro OPENVPN

IP IPSEC

n/a RSA (mutual) RSA (Servidor, Cliente) RSA (Servidor, Cliente)

n/a 3DES (168 bits) 3DES (168bits) 3DES (168 bits)

n/a HMAC-SHA1 (160 bits) HMAC- SHA1 (160 bits) HMAC- SHA1 (160 bits)

n/a n/a

SSL/TLS SSL/TLS

n/a LZO

6. Mediciones realizadas En la tabla 4 se presentan las mediciones efectuadas para cada configuración de canal y el mecanismo utilizado para generar trafico entre el cliente y el servidor.

Tabla 4. Mediciones y mecanismos utilizados

Medición Latencia ICMP Latencia HTTP Throughput TCP y

Mecanismo utilizado para generar tráfico Echo Request/Reply (32 bytes) HTTP GET Inyección de tráfico TCP aleatorio (1024 Kbytes)

1061

consumo de energía Throughput HTTP y consumo de energía Throughput FTP y consumo de energía

Descarga de archivo (de 1024 Kbytes) utilizando HTTP. Descarga de archivo (de 1024 Kbytes) utilizando FTP.

Las mediciones se realizaron de manera automática, utilizando aplicaciones (figura 3) que se ejecutaron de manera continua durante 7 días en la franja horaria 6:00 am a 11:00 pm, de esta manera fueron contemplados diferentes niveles de carga de la red GPRS. Los resultados obtenidos se promediaron para determinar el valor final de cada medición.

CONFIGURACION DE CANAL

MEDICIONES NO SEGURO

L2TP IPSEC

OPENVPN (SSL/TLS)

OPENVPN LZO (SSL/TLS)

Latencia ICMP (Busybox Ping)

SI

SI

SI

SI

Latencia HTTP (HTTPing)

SI

SI

SI

SI

SI

SI

SI

SI

SI

SI

SI

SI

SI

SI

SI

SI

Consumo de energía (Powertutor)

Throughput TCP (Iperf)

Throughput HTTP (Busybox Wget)

Throughput FTP (Wget - ANDftp)

Figura 3. Resumen de configuraciones de canal implementadas, mediciones realizadas y aplicaciones utilizadas para medir.

El consumo de energía en el nodo cliente se midió utilizando la aplicación PowerTutor [14], esta herramienta permite estimar el consumo de energía en tiempo real y por proceso utilizando el modelo de consumo de energía descrito en [20] .

6.1 Metodología de medición A continuación se enumeran los pasos necesarios para efectuar una medición: - Establecer comunicación extremo a extremo, según la configuración de canal utilizada (ver tabla 3).

- Ejecutar la aplicación Powertutor.

- Arrancar el monitoreo de consumo de energía (“Start Profiler”) - Generar tráfico entre el Cliente y el Servidor, el mecanismo depende de la medición realizada (ver tabla 4) - Detener Powertutor (“Stop Profiler”) - Guardar el “log” de Powertutor (Pulsar Menú -> Save Log).

- Copiar el “log” generado por “Powertutor”.

- Copiar el “log” generado por la aplicación utilizada para la medición.

- Analizar y procesar los archivos de logs.

- Promediar resultados.

1062

7. Resultados A continuación se presentan algunos de los resultados obtenidos, utilizando gráficos que resumen los aspectos estudiados.

Echo Request/Reply (32 bytes) Nodo Cliente - Servidor "Testing"

280

272,35 270

Latencia (ms)

260 250 240 232,29

230,12

231,53

230 220 210 200 NO SEGURO

L2TP/IPSEC 3DES SHA1

OPENVPN 3DES SHA1

OPENVPN 3DES SHA1 LZO

Figura 4. Latencia ICMP echo request/Reply

En la figura 5 se presenta el Throughput alcanzado una descarga de archivo de 1024 Kbytes, utilizando los protocolos HTTP y FTP. Se observa que HTTP alcanza un rendimiento ligeramente superior a FTP en todos los casos.

Descarga de archivo de 1024 Kbytes Nodo Cliente - Servidor "Testing" Comparativo HTTP/FTP

Throughput (Kbyte/s)

30 23,9

25

22,1

20 15,2

13,9

15

14,2

12,9

10,5

9,7

10 5 0 TP HT

NO SEGURO

P FT

L2TP/IPSEC

OPENVPN

OPENVPN LZO

Figura 5. Throughput de descarga HTTP y FTP

El grafico de la figura 6 muestra el Throughput, obtenido por la aplicación Iperf para cada configuración de canal, y la cantidad de energía (en joules) consumida por iperf para efectuar la prueba. Comparando los resultados obtenidos para el canal no seguro y el canal seguro con compresión, se observa que la compresión mejora considerablemente el Throughput (~ 400%) e introduce un consumo adicional de energía (~ 200%).

25,00 19,05

50

17,21 14,96

40

20,00 15,00

30 20

48,30

6,73

10,65

9,33

8,61

0,00

0

NO

10,00 5,00

10

RO GU SE T L2

P P/I

SS DE C3 SE

1 HA VP EN OP

S DE N3

IPERF

A1 SH VP EN OP

Energia (Joules)

Throughput (Kbyte/s)

IPERF - 1024 Kbytes de tráfico TCP Nodo Cliente - Servidor Testing 60

N

O LZ A1 SH ES 3D

POWERTUTOR

Figura 6. Rendimiento TCP/Iperf (throughput vs energía consumida)

1063

8. Conclusiones y trabajos futuros La seguridad implica un consumo adicional de recursos que puede variar dependiendo de los protocolos que se elijan para el establecimiento de un canal seguro, en los gráficos comparativos presentados se visualiza que la opción de seguridad basada en SSL/TLS con compresión (3DES - SHA-1 - LZO) es la que mayor energía consume, triplicando el consumo de un canal no seguro.

Se evidencia que el incremento en el consumo de energía introducido por la compresión es proporcionalmente bajo en relación a la mejora de throughput alcanzada. Esto hace, que la compresión sea una opción a considerar en escenarios donde se requiera mejorar el rendimiento del ancho de banda y la energía no sea un factor critico.

Observamos que el protocolo IPSec consigue un mejor aprovechamiento del ancho de banda y menor consumo de energía, comparado con el protocolo SSL/TLS sin compresión.

El uso de canal seguro en lugar de un canal no seguro, introduce una disminución en el rendimiento del ancho de banda (entre un 10% y 20%) y un incremento en el consumo de energía (entre un 100% y 200%). La elección de un nivel de seguridad en los nodos ad hoc dependerá de las posibilidades de recarga de energía y del ancho de banda disponible en la zona de despliegue de la MANET. Para continuar con esta línea de investigación tenemos previsto: - Utilizar dispositivos con interfaces Bluetooth 4.0 de bajo consumo.

- Efectuar pruebas variando la potencia de transmisión del nodo cliente y la distancia entre el nodo cliente y el nodo Gateway.

- Incorporar compresión DEFLATE al protocolo IPSEC y comparar los resultados con los obtenidos para la compresión LZO. - Utilizar herramientas de simulación para modelar el comportamiento aleatorio y la congestión de la red GPRS. - Estudiar la distribución del consumo de energía entre los componentes de un protocolo seguro: Intercambio de claves, autenticación, integridad, encriptación y transmisión de datos.

Referencias 1 2

3

4

IETF. MANET Active Work Group. http://tools.ietf.org/wg/manet CORDEIRO DE MORAIS, Carlos and AGRAWALL Dharma. (2011). Integrating MANETs, WLANs and Cellular Networks. In World Scientific Publishing (Ed.), Ad Hoc and Sensor Networks - Theory and Applications (pp. 587-620). Singapore: World Scientific Publishing.

ROCABADO, Sergio; SANCHEZ, Ernesto; DIAZ, Javier y ARIAS FIGUEROA, Daniel. (2011). Integración Segura de MANETs con Limitaciones de Energía a Redes de Infraestructura. Paper presented at the CACIC 2011, La Plata - Buenos Aires Argentina. http://sedici.unlp.edu.ar/handle/10915/18771 ROCABADO, Sergio; SANCHEZ, Ernesto; DIAZ, Javier y ARIAS FIGUEROA, Daniel. (2012). Integración Segura de MANETs, desplegadas en zonas de recursos

1064

5

6

7 8

9 10 11 12 13 14 15 16 17 18 19 20

limitados, a Redes de Infraestructura. Paper presented at the CACIC 2012, Bahia Blanca - Buenos Aires - Argentina. http://sedici.unlp.edu.ar/handle/10915/23762 ROCABADO, Sergio; HERRERA, Susana y Otros. (2013). M-LEARNING EN ZONAS DE RECURSOS LIMITADOS. Paper presented at the TE&ET 2013, Santiago del Estero - Argentina.

CORDEIRO DE MORAIS, Carlos and AGRAWALL Dharma. (2011). Wireless PANs. In World Scientific Publishing (Ed.), Ad Hoc and Sensor Networks - Theory and Applications (pp. 196-258). Singapore: World Scientific Publishing.

SPECIAL INTEREST GROUP (SIG) Bluetooth. (2001). Specification of the Bluetooth System, tomo 2. Bluetooth Profiles Specification Version 1.1.

ETSI EN 301 344. (2000). Digital cellular telecommunications system, General Packet Radio Service (GPRS), Service description. Retrieved from http://www.etsi.org/index.php/technologies-clusters/technologies/mobile/gprs SPECIAL INTEREST GROUP (SIG) Bluetooth. (2001). Bluetooth Network Encapsulation Protocol (BNEP) Especification.

3GPP. (2011). Specification 29060 - GPRS Tunneling Protocol, release 11.0. from http://www.3gpp.org/ftp/Specs/html-info/SpecVsWi--29060.htm STERICSON, Stephen. (2011). BusyBox. from https://play.google.com/store/apps/details?id=stericson.busybox FOLKERT van Heusden. HTTPing for Google Android mobile phones. Retrieved from http://www.vanheusden.com/Android/HTTPing MAGICANDROIDAPPS.COM. (2011). Iperf for Android. from https://play.google.com/store/apps/details?id=com.magicandroidapps.iperf GORDON, Mark; ZHANG, Lide and TIWANA, Birjodh. PowerTutor. University of Michigan. Retrieved from http://ziyang.eecs.umich.edu/projects/powertutor SCHĂ„UFFELHUT, Friedrich. OpenVPN Installer. Retrieved from http://code.google.com/p/android-openvpn-installer OpenVPN for Windows. (2010). from http://openvpn.net/index.php/download.html PATEL, B.; ABOBA, B y Otros (2001). L2TP/IPsec, RFC 3193. IETF. Retrieved from http://tools.ietf.org/html/rfc3193 DIERKS, T.; RESCORLA, E. (2008). The Transport Layer Security (TLS) Protocol (ver 1.2). IETF. Retrieved from http://tools.ietf.org/html/rfc5246 OBERHUMER, Markus F.X.J. (2010). LZO compression. from http://www.oberhumer.com/opensource/lzo/ ZHANG, Lide; TIWANA, Birjodh; QIAN, Zhiyun and WANG, Zhaoguang. (2010).

Accurate online power estimation and automatic battery behavior based power model generation for smartphones. Paper presented at the 2010 IEEE/ACM/IFIP International Conference on Hardware/Software Codesign and System Synthesis (CODES+ISSS), Scottsdale, AZ. http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5751489

1065

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

1066

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

1067

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.

1068

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.

1069

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 10.03.1, que es la estable más reciente, solamente con el agregado del protocolo OLSR versión 0.6.1-3 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 0.6.0.

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

1070

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

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.

1071

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

1072

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

1073

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. 455--487 (2005) 2. Acuña Martínez, D., Roncallo Kelsey, R.: Redes inalámbricas enmalladas metropolitanas. pp. 46--91 ( 2006) 3. http://www.olsr.org/ Consultado el 02/05/2013 4. http://www.open-mesh.org/ Consultado el 08/03/2013 5. http://wiki.freifunk.net/Kategorie:Espanol / Consultado el 01/04/2013 6. https://commotionwireless.net/ Consultado el 01/04/2013 7. https://openwrt.org/ Consultado el 08/03/2013

1074

NetworkDCQ: A Multi-platform Networking Framework For Mobile Applications Federico Cristina1, Sebastián Dapoto1, Fernando G. Tinetti1,2, Pablo Thomas1, Patricia Pesado1,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.

1075

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 Q3 2012 [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).

1076

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.

1077

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.

1078

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

1079

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

1080

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.

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

1081

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

1082

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

1083

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.

1084

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 2012. http://gs.statcounter.com/#mobile vs desktop-IN-monthly-201110-201210.

4. Meeker, M. D10 Conference. Internet Trends. (2012), http://www.kpcb.com/insights/2012-internet-trends.

5. Asymco. The Rise and Fall of Personal Computing (2012), http://www.asymco.com/2012/01/17/the-rise-and-fall-of-personal-computing/.

6. Gartner, Inc. Nov.2012 Press Release, http://www.gartner.com/it/page.jsp?id=2237315.

7. IDC. Nov.2012 Press Release, https://www.idc.com/getdoc.jsp?containerId=prUS23771812.

8. Google, Inc. Google Official Blog (2012), http://officialandroid.blogspot.com.ar/2012/09/google-play-hits-25-billion-downloads.html 9. Markus Falk. Mobile Frameworks Comparison Chart, http://www.markus-falk.com/mobile-frameworks-comparison-chart/ 10.Digital Possibilities. Mobile Development Frameworks Overview

1085

http://digital-possibilities.com/mobile-development-frameworks-overview/ 11.PhoneGap, http://phonegap.com/ 12. Unity3D, http://unity3d.com/ 13.Titanium, http://www.appcelerator.com/platform/titanium-platform/ 14.Corona, http://www.coronalabs.com/products/corona-sdk/ 15.Reuters. Oracle sues Google over Android (2012), http://www.reuters.com/article/2010/08/13/us-google-oracle-android-lawsuitidUKTRE67B5G720100813 16.Gamma, E. Design Patterns: Elements of Reusable Object-Oriented Software (1994).

17.Martin, R. C. The Dependency Inversion Principle. (1996), http://www.objectmentor.com/resources/articles/dip.pdf 18.Fowler, M. Inversion of Control Containers and the Dependency Injection Pattern, http://martinfowler.com/articles/injection.html 19.NetworkDCQ for Android Project, https://code.google.com/p/networkdcq/ 20.Asteroids for Android Project, http://code.google.com/p/asteroidsa/ 21.Tic-Tac-Toe for Android Project, http://code.google.com/p/ticatacatoe/ 22.NetworkDCQ for J2ME Project, https://code.google.com/p/networkdcq-j2me/ 23.Asteroids for Android Example Video, http://www.youtube.com/watch?v=HiRTk8daqi4 24.Tic-Tac-Toe for Android example video, http://www.youtube.com/watch?v=mrf01putSec

1086

Estimación de “H” con transformada ondita Reinaldo Scappini1, Luis Marrone2, 1

2

UTN Facultad Regional Resistencia, calle French 414 Resistencia, Rep. Argentina rscappini@gmail.com 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:

1087

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.

1088

Reinaldo Scappini1, Luis Marrone2,

2.1

3

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 d s ( 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ámetro j 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 X ( j, k ), j = 1, 2,...J , k ∈ } ,

es un proceso estacionario para

cada octava j, si el Nº de momentos desvanecientes de la wavelet madre

N≥

α −1 2

ψ0,

es

. La varianza del conjunto d X ( j , k ) reproduce el comportamiento de

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 d X ( 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 X ( j, k )2  ≈ 2 jα α = 2 H + 1, y − ∞ < j < ∞ LRD, α = 2 H − 1 ; j2 = ∞ , y j1 debe

(1)

Si X (t ) es Hsssi → Si X (t ) , presenta

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

γ corresponde a la ley de potencias expresada y el rango de escalas ( j1 , j2 ) , debe obtenerse partiendo de las frecuencias ( f1 , f 2 ) .

genéricamente procesos 1 / f ),

1089

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:

E [ d X ( j , k ) d X ( j , k ') ] ≈ k − k '

α −1− 2 N

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.

Por otra parte la expresión E  d X ( j , k )  = 2 E  d X (0, k )  ; 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. 3.3.4 y 3.7, se puede estimar la varianza del proceso d X ( j , k ) , según: j (2 H +1)

2

1 µj = nj

nj

∑ d ( j, k )

2

2

(3)

x

k =1

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

1090

Reinaldo Scappini1, Luis Marrone2,

exponente de escala del proceso

5

α , lo podemos estimar como una regresión lineal de

y( j ) ≡ log2 ( µ j ) , como una función de la octava 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 α = 2 H − 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:

(

)

log 2 E  d X ( j , k ) 2  = jα + log 2 ( c )

(5)

Lo que nos lleva a la siguiente aproximación:

log 2 ( µ j ) = jα + log 2 ( c )

(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 octavas j1 , j2 , 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

f (v) ≈ cf (v) −α cuando v → 0 , donde v , es la frecuencia, α es el exponente de escala, que es adimensional, y cf es dada en términos del espectro de potencia

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

α y cf

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 de j1 (figura izquierda), lo que permite una mejor elección de las octavas j1, j2 • 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

1091

6

Reinaldo Scappini1, Luis Marrone2,

examina los datos para encontrar un punto de corte inferior de la escala j1 , y otro punto de corte superior j2 , 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 rango j1 , j2 , 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

Q ( j1 ) , 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

1092

Reinaldo Scappini1, Luis Marrone2,

7

elección de j(1) , a partir de donde se estabiliza el valor de Q ( j1 ) , La estimación visual de la región de alineación es difícil, cuando los intervalos de confianza se vuelven muy pequeños, en escalas pequeñas, en este caso la estadística Q (

j1 ) ,

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:

1093

8

1.

2.

3.

4.

5.

6.

7.

Reinaldo Scappini1, Luis Marrone2,

Ethernet 10 Mbits.

Ethernet 100 Mbits.

Ethernet 1 Gbits.

Ethernet 10 Gbits.

OC12 OC48 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 1000000 –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]

1094

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 j1 como función del j2 que se encuentre como óptimo.

Tomando los valores sugeridos por la script para j1 y j2 , se repite la estimación obteniendo los datos que se muestran en la tabla 1: Parámetro

j1

j2

α

α [95%]

H

H [95%]

10Mbit. pAug89.TL 10Mbit. pOct89.TL 100Mbit. Tokio(200701090800) 100Mbit. Tokio(200701091200) Gigabit-Ethernet (20040130-132000-0) 10Gigabit Ethernet (20040212-130000-0) ampath-oc12.20070109.dag0.20070109-0000.anon ampath-oc12.20070109.dag0.20070109-1500.anon OC48-20020814-103000-0-anon.pcap OC48-20020814-115000-0-anon.pcap equinix-chicago.dirA.20090115-060100.UTC.anon equinix-chicago.dirB.20090115-060100.UTC.anon

9 6 8 6 10 10 10 12 5 4 9 8

16 16 16 16 16 14 16 16 16 16 16 16

0,642 0,51 0,315 0,304 0,557 0,508 0,693 0,303 0,195 0,175 0,461 0,282

[0.590, 0.693] [0.494, 0.527] [0.280, 0.349] [0.288, 0.321] [0.479, 0.634] [0.286, 0.731] [0.616, 0.771] [0.106, 0.499] [0.184, 0.207] [0.167, 0.183] [0.410, 0.512] [0.248, 0.317]

0,821 0,755 0,657 0,652 0,778 0,754 0,847 0,651 0,598 0,588 0,73 0,643

[0.795, 0.846] [0.747, 0.763] [0.640, 0.675] [0.644, 0.661] [0.740, 0.817] [0.643, 0.865] [0.808, 0.885] [0.553, 0.750] [0.592, 0.603] [0.584, 0.592] [0.705, 0.756] [0.624, 0.659]

Traza

Table 1.

6.1 Tabla Comparativa de Resultados Obtenidos con Distintos Métodos de Estimación de “H”.

La tabla 2, muestra los resultados de la estimación de H , utilizando las aplicaciones desarrolladas en [1], junto al resultado obtenido mediante la script de Darryl Veitch.

1095

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]http://postgrado.info.unlp.edu.ar/Carreras/Magisters/Redes_de_Datos /Tesis/Scappini_Reinaldo.pdf [2] http://www.cubinlab.ee.unimelb.edu.au/~darryl/secondorder_code.html [3] [Kihong Park, Walter Willinger Self-Similar Network Traffic and Performance Evaluation Copyright 2000 John Wiley & Sons, Inc. ISBNs: 0-471-31974-0 (Hardback); 0-471-20644X (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: 11 –24.

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

[6] http://imdc.datcat.org/collection/1-055M-0=WIDE-TRANSIT+100+Megabit+Ethernet+ Trace+2007-01-09+(Anonymized) [7] http://pma.nlanr.net/Special/sdsc1.html [8] http://pma.nlanr.net/Special/ [9] http://www.caida.org/home/ [10] http://www.wireshark.org/

1096

IP Core Para Redes de Petri con Tiempo Ornaldo Micolini1, Julián Nonino1 y Carlos Renzo Pisetta1 1Facultad

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.

1097

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.

1098

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: {đ?&#x2018;&#x192;, đ?&#x2018;&#x2021;, đ??ź+ , đ??ź â&#x2C6;&#x2019; , đ??ť, đ??ś, đ?&#x2018;&#x161;0 , đ??źđ?&#x2018;&#x2020; } Donde {đ?&#x2018;&#x192;, đ?&#x2018;&#x2021;, đ??ź + , đ??ź â&#x2C6;&#x2019; , đ??ť, đ??ś, đ?&#x2018;&#x161;0 } es una red de Petri plaza transiciĂłn marcada con brazos inhibidores y plazas acotadas, y đ??źđ?&#x2018;&#x2020; es la funciĂłn estĂĄtica de intervalos [đ?&#x2018;&#x17D;, đ?&#x2018;?] asociados a cada transiciĂłn.

DĂłnde: đ?&#x2018;ˇ: es un conjunto finito y no vacĂ­o de plazas. đ?&#x2018;ť: es un conjunto finito y no vacĂ­o de transiciones, P y T son conjuntos disjuntos đ?&#x2018;°+ , đ?&#x2018;°â&#x2C6;&#x2019; : son las matrices de incidencia positiva y negativa. La matriz đ?&#x2018;° es las diferencias entre đ?&#x2018;°+ , đ?&#x2018;°â&#x2C6;&#x2019; . đ?&#x2018;&#x192;đ?&#x2018;Ľđ?&#x2018;&#x2021; â&#x2020;&#x2019; đ?&#x2018;?

H: es la matriz de brazos inhibidores. đ?&#x2018;&#x192;đ?&#x2018;Ľđ?&#x2018;&#x2021; â&#x2020;&#x2019; {0,1} C: es el vector de cota de plaza đ??śâ&#x2020;&#x2019;đ?&#x2018; IS: es la funciĂłn estĂĄtica de intervalos asociados a cada transiciĂłn. đ?&#x2018;&#x2021; â&#x2020;&#x2019; â&#x201E;&#x161;+ Ă&#x2014; (â&#x201E;&#x161;+ â&#x2C6;Ş â&#x2C6;&#x17E;) 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 đ??źđ?&#x2018;&#x2020;(đ?&#x2018;Ą) = [đ?&#x2018;&#x161;đ?&#x2018;&#x2013;đ?&#x2018;&#x203A;, đ?&#x2018;&#x161;đ?&#x2018;&#x17D;đ?&#x2018;Ľ] â&#x2C6;&#x20AC; đ?&#x2018;Ą â&#x2C6;&#x2C6; đ?&#x2018;&#x2021; Como la funciĂłn IS representa un intervalo temporal, para cada transiciĂłn t sensibilizada se introduces el valor đ?&#x2018;Ąđ?&#x2018;&#x2013;đ?&#x2018;&#x161;đ?&#x2018;&#x2019;đ?&#x2018;&#x;đ?&#x2018;Ą , que se auto incrementa con el tiempo, si la transiciĂłn esta sensibilizada y se cumplir: min â&#x2030;¤ đ?&#x2018;Ąđ?&#x2018;&#x2013;đ?&#x2018;&#x161;đ?&#x2018;&#x2019;đ?&#x2018;&#x;đ?&#x2018;Ą â&#x2030;¤ đ?&#x2018;&#x161;đ?&#x2018;&#x17D;đ?&#x2018;Ľ el disparo sea posible.

Estas cotas deben cumplir las siguientes condiciones: ď&#x201A;ˇ ď&#x201A;ˇ ď&#x201A;ˇ ď&#x201A;ˇ

0 â&#x2030;¤ min < â&#x2C6;&#x17E; 0 â&#x2030;¤ max â&#x2030;¤ â&#x2C6;&#x17E; đ?&#x2018;&#x161;đ?&#x2018;&#x2013;đ?&#x2018;&#x203A; â&#x2030;¤ max đ?&#x2018; đ?&#x2018;&#x2013; max â&#x2030; â&#x2C6;&#x17E; đ?&#x2018;&#x161;đ?&#x2018;&#x2013;đ?&#x2018;&#x203A; < max đ?&#x2018; đ?&#x2018;&#x2013; max = â&#x2C6;&#x17E;

1099

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: ď&#x201A;ˇ Intervalo puntual [đ?&#x2018;&#x17D;, đ?&#x2018;&#x17D;]. En este caso, el tiempo de disparo es fijo, despuĂŠs de sensibilizaciĂłn se espera un tiempo đ?&#x2018;&#x17D;.

Un disparo inmediato es representado por Îą = 0 y se comporta como en las Redes de Petri plaza transiciĂłn. ď&#x201A;ˇ Intervalo sin restricciĂłn temporal, [đ?&#x2018;&#x17D;, â&#x2C6;&#x17E;]. 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 đ?&#x2018;&#x161;đ?&#x2018;&#x2013; y por el vector de valores de intervalos de transiciĂłn đ?&#x2018;Ąđ?&#x2018;&#x2013;đ?&#x2018;&#x161;đ?&#x2018;&#x2019;đ?&#x2018;&#x; de la red, que lleva la cuenta de tiempo de cada transiciĂłn sensibilizada. Por lo tanto el estado es: đ??¸ = (đ?&#x2018;&#x161;đ?&#x2018;&#x2013;, đ?&#x2018;Ąđ?&#x2018;&#x2013;đ?&#x2018;&#x161;đ?&#x2018;&#x2019;đ?&#x2018;&#x; ) 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 đ?&#x2019;&#x17D;đ?&#x2019;&#x152; , se dice que una transiciĂłn tj se encuentra habilitada o sensibilizada si y solo si (sii) todos los lugares del conjunto de plazas â&#x20AC;˘ tj de entrada a la transiciĂłn tienen al menos la cantidad de marcas igual al peso de los arcos ( đ?&#x2019;&#x2DC;(đ?&#x2019;&#x2018;đ?&#x2019;&#x160; , đ?&#x2019;&#x2022;đ?&#x2019;&#x2039; )) de entrada a la transiciĂłn tj, esto es: đ?&#x2018;?đ?&#x2018;&#x2013; â&#x2C6;&#x2C6; â&#x20AC;˘ đ?&#x2018;Ąđ?&#x2018;&#x2013; , đ?&#x2018;&#x161;(đ?&#x2018;?đ?&#x2018;&#x2014; ) â&#x2030;Ľ đ?&#x2018;¤(đ?&#x2018;?đ?&#x2018;&#x2013; , đ?&#x2018;Ąđ?&#x2018;&#x2014; ) Si el đ?&#x2018;Ąđ?&#x2018;&#x2013;đ?&#x2018;&#x161;đ?&#x2018;&#x2019;đ?&#x2018;&#x; de la transiciĂłn es cero, se debe habilitar đ?&#x2018;Ąđ?&#x2018;&#x2013;đ?&#x2018;&#x161;đ?&#x2018;&#x2019;đ?&#x2018;&#x;đ?&#x2018;Ą para que se incremente con el tiempo.

Las transiciones sensibilizadas pueden ser disparadas en el intervalo [a, b], disparo provoca un nuevo marcado es decir un cambio de estado. La ecuaciĂłn calcular el cambio de estado o la nueva marca alcanzada por el disparo de đ?&#x153;&#x2022; (đ?&#x2018;&#x161;đ?&#x2018;&#x2DC; , đ?&#x2018;Ąđ?&#x2018;&#x2014; ), y se define por la siguiente expresiĂłn:

auto y su para tj es

đ?&#x2018;&#x161;đ?&#x2018;&#x2DC;+1 (đ?&#x2018;?đ?&#x2018;&#x2013; ) = đ?&#x2018;&#x161;đ?&#x2018;&#x2DC; (đ?&#x2018;?đ?&#x2018;&#x2013; ) â&#x2C6;&#x2019; đ?&#x2018;¤đ?&#x2018;&#x2013;đ?&#x2018;&#x2014; , â&#x2C6;&#x20AC; đ?&#x2018;?đ?&#x2018;&#x2013; â&#x2C6;&#x2C6; đ?&#x2018;Ąđ?&#x2018;&#x2014; â&#x20AC;˘ , â&#x2C6;&#x20AC; đ?&#x2018;?đ?&#x2018;&#x2013; â&#x2C6;&#x2C6; đ?&#x2018;Ąđ?&#x2018;&#x2014; â&#x20AC;˘ đ?&#x2018;&#x161;đ?&#x2018;&#x2DC;+1 (đ?&#x2018;?đ?&#x2018;&#x2013; ) = đ?&#x2018;&#x161;đ?&#x2018;&#x2DC; (đ?&#x2018;?đ?&#x2018;&#x2013; ) + đ?&#x2018;¤đ?&#x2018;&#x2014;đ?&#x2018;&#x2013; đ?&#x153;&#x2022; (đ?&#x2018;&#x161;đ?&#x2018;&#x2DC; , đ?&#x2018;Ąđ?&#x2018;&#x2013;đ?&#x2018;&#x161;đ?&#x2018;&#x2019;đ?&#x2018;&#x;đ?&#x2018;Ą ) = min â&#x2030;¤ đ?&#x2018;Ąđ?&#x2018;&#x2013;đ?&#x2018;&#x161;đ?&#x2018;&#x2019;đ?&#x2018;&#x;đ?&#x2018;Ą â&#x2030;¤ đ?&#x2018;&#x161;đ?&#x2018;&#x17D;đ?&#x2018;Ľ , đ?&#x2018;&#x2019;đ?&#x2018;&#x203A; đ?&#x2018;&#x2019;đ?&#x2018;&#x2122; đ?&#x2018;&#x;đ?&#x2018;&#x2019;đ?&#x2018; đ?&#x2018;Ąđ?&#x2018;&#x153; đ?&#x2018;&#x2018;đ?&#x2018;&#x2019; đ?&#x2018;&#x2122;đ?&#x2018;&#x153;đ?&#x2018; đ?&#x2018;?đ?&#x2018;&#x17D;đ?&#x2018; đ?&#x2018;&#x153;đ?&#x2018; ; { đ?&#x2018;&#x161;đ?&#x2018;&#x2DC;+1 (đ?&#x2018;?đ?&#x2018;&#x2013; ) = đ?&#x2018;&#x161;đ?&#x2018;&#x2DC; (đ?&#x2018;?đ?&#x2018;&#x2013; ) đ?&#x2018;&#x161;đ?&#x2018;&#x2013;đ?&#x2018;&#x203A; = đ?&#x2018;&#x17D;, đ?&#x2018;&#x161;đ?&#x2018;&#x17D;đ?&#x2018;Ľ = b Donde el đ?&#x2018;Ąđ?&#x2018;&#x2013;đ?&#x2018;&#x161;đ?&#x2018;&#x2019;đ?&#x2018;&#x;đ?&#x2018;Ąđ?&#x2018;&#x2014; se incrementa en cada ciclo de reloj mientras la transiciĂłn se encuentra sensibilizada.

1100

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

Matriz I

Modulo de Calculo de la Ecuación de Estado

Matriz H

Cola de Salida

Matriz Cal proximo estado

Cotas de Plazas

Estado Sensibilizado

Transicion es Auto

Detect Red Activa

Vector EFT

I/O Datos

Estado de Transición

Matriz de Prioridad

Vector LFT

Vector Timer

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

1101

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đ?&#x2018;Ą . Si en una transiciĂłn sensibilizada Timerđ?&#x2018;Ą = 0 se arranca Timerđ?&#x2018;Ą y si Timerđ?&#x2018;Ą â&#x2030; 0 no se hace nada.

4. Disparo de una transiciĂłn. Las transiciones que cumplen con: đ?&#x2018;&#x2030;đ?&#x2018;&#x2019;đ?&#x2018;?đ?&#x2018;Ąđ?&#x2018;&#x153;đ?&#x2018;&#x; đ??¸đ??šđ?&#x2018;&#x2021; â&#x2030;¤ Vector Timerđ?&#x2018;Ą â&#x2030;¤ đ?&#x2018;&#x2030;đ?&#x2018;&#x2019;đ?&#x2018;?đ?&#x2018;Ąđ?&#x2018;&#x153;đ?&#x2018;&#x; đ??żđ??šđ?&#x2018;&#x2021; 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đ?&#x2018;Ą 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.

1 2 3 4

Interrumpible Representa las dos semĂĄnticas Matrices usadas Permite contener subredes

Con Tiempo Si Si I No

Temporizada No No I+, ISi

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.

1102

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™ Spartan6, 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

1103

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

2,0

Speed up

1,5

2 Escritores 1,73 4 Escritores 5 Escritores 1,35 1,26 1,24 1,101,16

1,74 1,26 1,24

1,0

0,5

0,0 10

1000

10000

Fig. 2. Tiempos de sincronización por iteración

Estas mediciones se realizaron con tiempos 𝐸𝐹𝑇 𝑦 𝐿𝐹𝑇 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.

1104

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.

1105

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

2. Domeika, M. Software Development for Embedded Multi-core Systems. 0 Corporate Drive, Suite 400, Burlington, MA 01803, USA : Linacre House, Jordan Hill, Oxford , UK., 2008.

3. Sundararajan Sriram, S. S. B. EMBEDDED MULTIPROCESSORS, Scheduling and Synchronization. Boca Raton, 2009.

4. Ramachandani, C. Analysis of Asynchronous Concurrent Systems by Timed Petri Nets.

Cambribge, Massachussets : Massachussets Institute of Technology, 1974.

5. Izquierdo, García. Modelado e implementación de sistemas de tiempo real mediante redes de petri con tiempo. Zaragoza, 1999.

6. IP Core for Timed Petri Nets. Micolini, Orlando, Nonino, Nulián and Pisetta, Carlos R. Buenos Aires, Argentina: s.n., 2013. 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., 2012. CASE 2012.

8. Jensen , Kurt y Kristensen, Lars M. Coloured Petri Nets: Modelling and Validation of Concurrent Systems. New York : Springer, 2009 .

9. Xilinx. MicroBlaze (UG708). 2012.

10. AXI Interconnect (DS768). 2012.

1106

Analysis of Radio Communication Solutions in Small and Isolated Communities under the IEEE 802.22 Standard A. Arroyo Arzubi1, A. Castro Lechtaler1 y 3, A. Foti 4, R. Fusario1, y 4, J. García Guibout2 and L. Sens4 1 Escuela Superior Técnica - Facultad de Ingeniería del Ejército - IESE, C1426, Buenos Aires; 2Instituto Tecnológico Universitario - Universidad Nacional de Cuyo, M5500, Mendoza; 3 Universidad Nacional de Chilecito, F5360, Chilecito, La Rioja; 4Universidad 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 802.22 standard as a solution to the wireless problem.

Keywords: IEEE 802.22, 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 1st, 2011, of the standard IEEE 802.22 - Cognitive Wireless RAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Policies and Procedures for Operation in the TV Bands [7].

1107

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 802.11 [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 802.3 to the Local Area Network and 802.11 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.

1108

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 802.11.  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 802.22 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 - ICT1 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

1109

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 2.000.000 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 (SDR3) 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. known as Software Radio.

3Also

1110

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 Mitola5 and Gerald Maguire, researchers from the Royal Institute of Technology6 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.

1111

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

1112

3.6

IEEE 802.22 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 802.22 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 - AFSCA8 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 802.22 standard to be considered in the spectrum reallocation under study by the National Argentine Spectrum Authority - CNC9.

4. IEEE 802.22. Cognitive Wireless RAN Medium Access Control (MAC) and Physical Layer (PHY) 4.1.

Introduction

On July 1st 2011, the standard IEEE 802.22: 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 series10, 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.

Comisión Nacional de Comunicaciones.

10 Wireless.

9

1113

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 802.22.111 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 3. 802.22: 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.

4.3. 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 802.22 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 Beacon12.  Other transmissions such as medical telemetry that may need to be protected in the local regulatory domain.

11

IEEE 802.22.1: Standard to Enhance Harmful Interference Protection for Low-Power Licensed Devices Operating in the TV Broadcast Bands. 2010.

12 IEEE 802.22.1 .

1114

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.

4.5. 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 802.3 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 802.22.

1115

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.

4.6. Physical Layer - PHY Similarly to the Asymmetric Digital Subscriber Line â&#x20AC;&#x201C; ADSL, the IEEE 802.22 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.

1116

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 802.22 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 802.22 standard to the problem of rural communications.

The Project Communitarian Private Networks continues its work on this line of research.

1117

6.

Acknowledgements

The financial support provided by Agencia Nacional para la Promoción Científica y Tecnológica (Project PICTO 11- PICTO 11-18621 is gratefully acknowledged.

7.

References

[1] Antonio Castro Lechtaler (Director). PICTO 11-18621. 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 978 - 950 – 656 – 109 – 3. pp. 56 a 67.

Corrientes. October 2007.

[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 978 - 950 – 656 – 109 – 3. pp. 68 a 79. Corrientes.

October 2007.

[4] J. García Guibout, C. García Garino, A. Castro Lechtaler and R. Fusario. Transmission voice over 802.11. Proceedings of 14th of Argentine Congress on Computer Science. ISBN 978 - 987 - 24611 - 0 - 2. pp. 307 a 318. Chilecito. October 2008.

[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 15th of Argentine Congress on Computer Science. ISBN 978 - 897 - 24068 - 4 - 1. pp.

1.117 a 1.126. Jujuy. October 2009.

[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 2010. - Volume III - ISBN - 13: 978 – 1 – 934272 – 96 - 1. PP. 121 a 127. Orlando, USA. June 2010.

[7] http://www.cplus.org/rmw/index.html (Radio mobile software).

[8] IEEE 802.22 - 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 802.22: An Introduction to the First Wireless Standard based on Cognitive Radios Journal of Communications, Vol. 1, N° 1, april 2006.

[10] C. Gómez. Spectrum Regulation and Policy Officer Radiocommunication Bureau. www.itu.int/ITU-D/asp/CMS/Events/.../ITU-APT-S3_Cristian_Gomez.pdf. ITU. Apia, Samoa. April 2013.

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

[12] http://www.wirelessinnovation.org/introduction_to_sdr [13] Dillinger, M; Madani, K; Alonistioti, N. Software Defined Radio: Architectures, Systems and Functions. Ed. Wiley & Sons, 2003.

[14] J. Mitola, G. Maguire. Cognitive radio: making software radios more personal. IEEE Personal Communications Magazine, vol. 6, Nr. 4, pp. 13–18, Aug. 1999.

[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 1403 - 5286. Sweden. May 8, 2000.

1118

Posicionamiento indoor determinado por la distancia en función de la potencia medida de balizas bluetooth Marcelo MARINELLI1, Juan TOLOZA2, 3, Nelson ACOSTA2 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 2560. 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

1119

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.

1120

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.

1121

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

Baliza BT

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.

1122

215 210 205

RSSI (dBm)

200 195 190 185 180 175 170 165 160 1

2

3

4

5

6

7

8

9

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 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 R2 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.

1123

RSSI (dBm)

210 205 200 195 190 185 180 175 170 165 160

y = -0.9796x + 201.85 R2 = 0.8234

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Distancia (metros) promedio

Lineal (promedio)

RSSI (dBm)

Figura 3. Promedio y su regresi贸n lineal

210 205 200 195 190 185 180 175 170 165 160

y = -0.9262x + 202.2 R2 = 0.7179 1 2 3 4 5 6

7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Distancia (metros) moda

Lineal (moda)

Figura 4. Moda y su regresi贸n lineal

1124

215 210 RSSI (dBm)

205 200 195 190 185 y = -0.8346x + 206.25 R2 = 0.7753

180 175 170

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 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 R2 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 - 201.85) / -0.9796 que se despeja de la que se observa para la regresión (y = -0.9796x + 201.85), 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.

8 7 6 5 Error (metros) 4 3 2 1 0 1

3

5

7

9

11

13

15

17

19

21

23

25

Distancia (metros) Magnitud del error

Figura 6. Magnitud del error entre el promedio y su regresión lineal

1125

10 9 8 7 6 Error (metros) 5 4 3 2 1 0 1

3

5

7

9

11

13

15

17

19

21

23

25

23

25

Distancia (metros) Magnitud del error

Figura 7. Magnitud del error entre la moda y su regresión lineal

10 9 8 7 6 Error (metros) 5 4 3 2 1 0 1

3

5

7

9

11

13

15

17

19

21

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.

1126

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

6. 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, 2003.

8. Cheung K., Intille S., and Larson K., 2006. An Inexpensive Bluetooth-Based Indoor Positioning Hack. Proceedings of UbiComp 2006 9. J. Hallberg, M. Nilsson, K. Synnes, “Bluetooth Positioning”, The Third Annual Symposium on Computer Science and Electrical Engineering (CSEE 2002), Luleå, Sweden, 27-28 May 2002 10. 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, 1375-1378.

1127

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.1002-1009, 4-6 May 2010 12. 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, 13-18 June 20 13. Huang, A., “An Inexpensive Bluetooth-Based Indoor Positioning Hack MIT” CSAIL. 2005.

Available at http://people.csail.mit.edu/albert/pubs/2005-ashuang-sm-thesis.pdf 14. 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, 2009. ITSC '09. 12th International IEEE Conference on , vol., no., pp.1,7, 4-7 Oct. 2009 16. 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. 267-271.

18. Acosta N. & Toloza J. (2012) “Techniques to improve the GPS precision,” International Journal of Advanced Computer Science and Applications, Volume 3 No. 8, pp. 125-130.

1128

Posicionamiento WIFI con variaciones de Fingerprint Carlos KORNUTA1, Nelson ACOSTA, Juan TOLOZA2 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 2

Becario CONICET Tipo I Becario Postdoctoral CONICET

1129

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.

1130

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 m2. 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 8.04. 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:

1131

 

 

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.

1132

 

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

3 Ventana no metálica (Vidrios) 5a8 Ventana Metálica 5a8 Pared Fina 10 Pared Media 15 a 20 Pared Gruesa (15 cm) 20 a 25 Pared muy gruesa (30 cm) 15 a 20 Piso o techo grueso 15 a 25 Piso o techo muy grueso

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.

1133

Coordenadas 1.1

1.6

6.1

6.6

Tabla 2. Análisis de la variación de los AP AP Promedio Máximo 3 -89 -81 7 -75 -71 6 -64 -57 3 -91 -77 7 -72 -71 6 -63 -57 3 -86 -77 7 -73 -69 6 -63 -53 3 -87 -79 7 -75 -71 6 -52 -45

Mínimo -97 -79 -69 -97 -79 -71 -95 -77 -71 -93 -81 -71

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

1134

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

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

5.3 Posición (4,5) Distancias Euclidianas

Figura 5. Gráfico de superficie MODA posición (4,5)

1135

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 2.4 – 3.6 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.

1136

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

[2] G. M. Djuknic and R. E. Richton, Geolocation and assisted GPS, IEEE Computer. Vol. 34, Nro. 2, pp:123-125. 2001 [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: 33-41. , 1996.

[4] K. Pahlavan, X. Li, and J. P. Makela, Indoor geolocation science and technology, IEEE Communications Magazine., Vol. 40, Nro. 2, pp: 112-118, 2002.

[5] P. Bahl and V. N. Padmanabhan. RADAR: An in-building RF based user location and tracking system, IEEE Infocom 2000. Vol.2, Nro. 1, pp: 775-784. 2000.

1137

[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, 2003.

[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, 2006.

[8] Ekahau, Ekahau positioning engine 2.0; 802.11 based wireless LAN positioning system, Ekahau Technology, Internal Report, www.eukahau.com, 2012.

[9] Roberto Battiti, Thang Lee Nhat, Alessandro Villani, Location-aware computing: a neural network model for determining location in wireless LANs, 2002.

[10] Pahlavan, K., & Krishnamurthy, P. Principles of Wireless Networks - A Unified Approach, Prentice Hall. 2002. ISBN-10: 0130930032 [11] Brachmann, F. A comparative analysis of standardized technologies for providing indoor geolocation functionality, Symposium on Computational Intelligence and Informatics (13th 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: 3-172. 1999.

[13] Marcelo Najnudel, Estudo de propagação em ambientes fechados para o planejamento de wlans, Universidad Católica de Rio de Janeiro. Tesis. 2004.

[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: 1-5. 2012.

1138

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 27002 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 27002 • FIPS PUB 200 • ISO/IEC TR 13335 • ISO/IEC 15408:2005 • TickIT • TOGAF • IT Baseline Protection Manual • NIST 800-14

1139

Fue seleccionada para esta investigación como base normativa la ISO/IEC 27002 [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.

1140

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.

1141

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.

1142

Athlon x2 250

FX4100

Administrador por consola web

TL-SF1016D

I3 2120

ML150G6

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.

1143

Tabla 1. Cuantificador numérico.

Herramienta, Atributo Inventario de Software Software de base con licencia -Sistema Operativo Actualizaciones de Sistema Operativo Software de aplicaciones con licencia Antivirus Software gratuito Inventario de Hardware Motherboard Procesadores Memoria Almacenamiento físico HDD Almacenamiento físico ( CD, pen, etc ) Almacenamiento lógico Video Sonido Red BIOS Monitor Dispositivos de entrada.

Impresoras Impacto en red Volumen de tráfico en la auditoría Volumen de tráfico en el despliegue Facilidades Desligue TOTAL

Valoracio de Importacia

OCS inventory Windows xp

5 3 5 4 4

5 5 4 4

5 5 5 5 5 5 5 3 5 5 4 3 4

2 4 4 5 4 5 3 3 5 4 5 4 4

4 1

3 1

3

5

OCS inventory Windows 7 5 3 4 3,2 0 0 2 4 4 5 4 5 3 1,8 5 4 4 2,4 3,2 0 2,4 0,2 0 3 68,2

4 5 4 4 2 4 4 4 4 5 3 3 5 4 5 4 4 3 1 3

OCS inventory ubuntu 4 3 4 3,2 0 0 2 4 4 4 4 5 3 1,8 5 4 4 2,4 3,2 0 2,4 0,2 0 1,8 65

5 5 2 4 4 5 4 5 3 3 5 4 1 2

5

Open Audit Windows xp 0 3 0 0 4 0 2 4 4 5 4 5 3 1,8 5 4 0,8 1,2 0 0 0 0 0 3 49,8

5 5 5 5 4 5 4 4 4 5 3 3 5 4 5 4 2 3 5 5

Open Audit Windows 7 5 3 5 4 0 0 4 5 4 4 4 5 3 1,8 5 4 4 2,4 1,6 0 2,4 1 0 3 71,2

4 5 5 5 4 5 4 4 4 5 3 3 5 4 5 4 2 3 5 5

Open Audit ubuntu 4 3 5 4 0 0 4 5 4 4 4 5 3 1,8 5 4 4 2,4 1,6 0 2,4 1 0 3 70,2

5 5 4 5 4 5 5 5 3 3 5 5 5 4 4 3 5 5

0 3 0 0 4 0 4 5 4 5 5 5 3 1,8 5 5 4 2,4 3,2 0 2,4 1 0 3 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.

1144

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

1145

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.

1146

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

1147

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.

1148

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: 10.0.0.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 1. http://auditoriasistemas.com/estandares-ti/ 2. 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.

1149

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

10.

11.

12.

Información. Ed. Alfaomega Grupo Editor. http://www.open-audit.org/ http://www.ocsinventory-ng.org/en/

http://www.iso2 7 0 0 0 . e s / http://www.17799.com/

1150

DJBot: Administrando las salas de PC evitando la consola Javier D´ıaz, Aldo Vizcaino, Alejandro Sabolansky y Einar Lanfranco LINTI Laboratorio de Investigaci´ on en Nuevas Tecnolog´ıas Inform´ aticas, calle 50 y 120, La Plata, Argentina {javierd,asabolansky,avizcaino,einar}@linti.unlp.edu.ar http://www.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´ atica de la UNLP dio lugar al desarrollo de DJBot: una aplicaci´ on web realizada en Python que permite ejecutar comandos en m´ ultiples computadoras en un solo paso. En este documento se describen los motivos y el camino recorrido para llegar a la versi´ on de la aplicaci´ on 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´ o de ser una simple herramienta ejecutable en la l´ınea de comandos a convertirse en una plataforma de administraci´ on centralizada que simplifica el mantenimiento, actualiza los equipos y permite ejecutar tareas programadas en la interfaz web.

Palabras clave: Botnet, Django, Fabric, Python, Redis

1151

1.

El contexto

La Facultad de Inform´ atica 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´ atedras, realizar competencias, jornadas y otras actividades extracurriculares.

Todos los equipos disponibles cuentan con dos sistemas operativos instalados: Microsoft Windows 7 y la distribuci´on de GNU/Linux que se desarrolla en la Facultad, Lihuen GNU/Linux[2], y queda a criterio de las c´atedras y de los alumnos cu´ al 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´ ublico, lo que permite que los equipos sean identificados desde Internet.

El grupo de trabajo que conforman los autores de este documento, adem´as de encontrarse a cargo de la administraci´on y mantenimiento de las tres salas de PC, tiene acceso a los routers y dem´as dispositivos de interconexi´on dado que tambi´en es el grupo responsable del mantenimiento del enlace troncal de datos de la Facultad.

2.

La problem´ atica

Se pueden identificar dos cuestiones principales para resolver.

Por un lado, la problem´atica relacionada con las cuestiones rutinarias. La gran cantidad de actividades acad´emicas 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´ un 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´on o la instalaci´on de un software requerido por alg´ un usuario debe realizarse sobre todos los equipos de la sala.

Junto con la problem´ atica planteada en relaci´on a las tareas de mantenimiento, surgi´ o la inquietud de c´ omo se podr´ıan utilizar los equipos de la sala en los tiempos en que el equipamiento est´a 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´aquinas involucradas mediante la interacci´on directa con cada uno de los equipos.

Para posibilitar y facilitar la realizaci´on 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´aticas planteadas en la secci´on anterior se ha desarrollado una aplicaci´ on de administraci´on simplificada y centralizada de terminales GNU/Linux la cual se controla mediante una interfaz web.

1152

Todo ello fue desarrollado siguiendo el principio DRY (Dont Repeat Yourself) mediante la reutilizaci´ on de componentes de software libre. A modo de resumen, se puede decir que DJBot fue realizado utilizando Python como lenguaje de programaci´ on, 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´on, se utiliz´o Parallel SSH (PSSH)[1], una herramienta que permite entre otras cosas, realizar acciones mediante la ejecuci´on de comandos y copiar archivos en diferentes computadoras en paralelo. PSSH se encuentra en los repositorios oficiales de la distribuci´on Debian de GNU/Linux, lo que transitivamente hace que tambi´en est´e disponible en Lihuen GNU/Linux y simplifica la puesta en producci´on del entorno.

Por su forma de funcionamiento, esta aplicaci´on requiere que las direcciones IP de las m´ aquinas 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´on propios de SSH[4] aparecieron restricciones: SSH funciona utilizando clave p´ ublica-privada. Los clientes –es decir, todas las m´ aquinas cuya IP se encuentra en el archivo– deben contar con la clave p´ ublica del que se conectar´a para autorizarlo en el archivo /authorized keys.

Esto se solucion´ o propagando la clave p´ ublica a todos los equipos de todas las salas.

SSH mantiene un archivo de confianza ( /.ssh/known hosts) donde guarda IP y clave p´ ublica de todos los pares con los con que dialoga en alg´ un momento. Si ante un nuevo intento conexi´on el par no coincide, el servidor rechaza la conexi´ on. Hist´oricamente las m´aquinas de la Facultad estuvieron configuradas mediante un servicio de asignaci´on din´amica de direcciones, de manera que la asignaci´ on de las direcciones IP se completaba en forma aleatoria. Con el servicio de SSH en funcionamiento, en cambio, el servicio de DHCP se modific´ o para que cada computadora pasara a tener una u ´nica IP fija y definitiva. As´ı, cuando se accedi´o por primera vez a las computadoras mediante SSH, se pudo generar el registro de identificaci´on de cada m´aquina 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´on 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´o 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

1153

tenga acceso a la consola de administraci´on. El hecho de que la implementaci´on de PSSH exija la ejecuci´ on del int´erprete 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´o 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 ´ordenes a los clientes.

Por ello se descart´ o, y buscando una alternativa se opt´o por Fabric[6], una biblioteca que re´ une las caracter´ısticas m´as u ´tiles de PSSH y que utiliza Paramiko para realizar las conexiones SSH. En resumen, mediante Fabric se facilita la configuraci´on de las tareas que se realizan en los equipos de las salas, facilitando la forma de indicar en qu´e terminales queremos ejecutar tareas, permitiendo utilizar distintos archivos de autenticaci´ on SSH y brindando la opci´on de elegir entre distintos usuarios, entre otras opciones.

Como u ´ltima instancia restaba decidir c´omo desarrollar la parte web; hoy es muy dif´ıcil pensar en desarrollar una aplicaci´on web utilizando el lenguaje u ´nicamente sin utilizar alg´ un framework de desarrollo que acorte y simplifique el proceso mediante la provision de componentes gen´ericos como ser filtros de seguridad, plugins de autenticaci´on, 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´as 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´ on Python[8].

Una caracter´ıstica particular de DJBot es su modo de funcionamiento. Las redes de zombis, m´ as conocidas como “botnet” en el ´area de la seguridad inform´atica, son redes formadas por equipos que realizan tareas automatizadas,donde hay un controlador principal, que generalmente a trav´es de Internet que indica qu´e hacer a una gran cantidad de equipos “zombis” que siguen las ordenes sin preguntar el por qu´e. El dise˜ no particularmente u ´til y simple que permite el framework de desarrollo Django, sumado al concepto b´asico de las “botnets”, dieron lugar al nombre de esta aplicaci´on: DJBot[11]. Como las partes que conforman su nombre lo indican, “DJ” hace menci´on 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´a compuesto por cuatro entidades: Aula, Computadora, Tarea y Configuraciones.

La entidad Aula est´ a conformada por m´ ultiples computadoras y presenta las siguientes caracter´ısticas principales: 1. nombre del aula,

1154

Figura 1. Clases del modelo de datos

2.

3.

4.

5.

usuario, direcci´ on IP de una m´ aquina intermediaria, nombre de la placa de red de la m´aquina intermediaria, y direcci´ on de red.

El nombre sirve para identificar el aula. La identificaci´on mediante usuario permite realizar el inicio de sesi´on en cada computadora del aula. La direcci´on IP y el nombre de la interfaz de la m´aquina intermediaria, que por lo general es un router, permiten encender las computadoras de cada aula a trav´es de la red (wake on LAN). La direcci´ on de red, por su parte, se utiliza para asignar todas las m´ aquinas encendidas dentro del rango de red indicado al aula espec´ıfica.

La entidad Computadora incluye los valores: 1.

2.

3.

4.

nombre de la computadora, direcci´ on MAC, direcci´ on IP, y aula a la que pertenece.

La entidad Tarea se define a trav´es 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´on entre todas las computadoras del aula, y se utiliza cuando resulta m´ as sencillo que hacer uso de las instrucciones de comandos.

En la actualidad, la entidad Configuraciones se utiliza para definir valores predeterminados para las dem´as entidades. La clave SSH de las aulas, por ejemplo, est´ a definida bajo la entidad Configuraciones. Sin embargo, en el futuro se

1155

planea configurar claves SSH espec´ıficas para cada aula en particular. As´ı, la entidad Configuraciones quedar´ıa disponible para cubrir cualquier necesidad de definici´ on de valores predeterminados.

6.

La optimizaci´ on de DJBot

El desarrollo de DJBot, es decir, la integraci´on del framework con las bibliotecas y con el modelo de datos que se describi´o anteriormente, se complet´o con el agregado de la interfaz web para lograr practicidad y flexibilidad en este trabajo.

La ejecuci´ on de tareas como la actualizaci´on del sistema y la instalaci´on de aplicaciones nuevas, por ejemplo, implican tiempos de trabajo que al ser procesados desde la interfaz web de DJBot devolver´ıan un error por tiempo de espera agotado. La utilizaci´on del buffer Redis[9] para almacenar las tareas solicitadas y los resultados devueltos evita, entonces, que el navegador quede como si estuviera cargando algo gener´andose retrasos innecesarios. Con la ayuda de la biblioteca RQWorker[10], Python se comunica con Redis y de esta manera las tareas se colocan en una cola de espera y son ejecutadas a su debido tiempo seg´ un el orden de solicitud. Esto independiza la interfaz web de DJBot para que el administrador pueda seguir interactuando con la misma sin tener demoras.

7.

Los casos de uso

DJBot ya ha sido utilizado en la administraci´on de las salas de PC de las facultad en diversas ocasiones, facilitando y automatizando las distintas tareas, entre las que podemos mencionar: Instalaci´ on de software solicitado por las c´atedras para la realizaci´on de las actividades acad´emicas.

Actualizaci´ on del sistema operativo ante actualizaciones de funcionalidad y seguridad de las distintas herramientas instaladas.

Despliegue de una arquitectura para la realizaci´on de un test de stress sobre una aplicaci´ on web.

8.

La liberaci´ on

DJBot est´ a liberado como software libre bajo licencia GPL en su versi´on 3, una licencia que garantiza los principios del software libre permitiendo el libre uso, distribuci´ on y modificaci´on del software a gusto de cualquiera que as´ı lo desee.

Actualmente el c´ odigo del proyecto puede encontrarse en los servidores de GitHub, uno de los repositorios de software libre m´as utilizados en la actualidad.

Por como funciona GitHub, el lector puede descargarlo libremente desde all´ı; si es para usarlo puede hacerlo en forma an´onima, pero en cambio si quiere generar alg´ un aporte va a necesitar generarse un usuario en el sistema que le permita luego integrar su contribuci´ on al desarrollo.

1156

Para acceder al desarrollo, solamente es necesario apuntar un navegador web a https://github.com/krahser/djbot.

9.

El trabajo a futuro

Despu´es de varios meses de trabajo y de tener la aplicaci´on web funcionando, son varios los beneficios obtenidos y tambi´en son muchas las mejoras que est´an planificadas para ser aplicadas en el corto plazo.

Las cuestiones m´ as importantes en las que se continuar´a trabajando involucran: Mejora de la interfaz gr´ afica para que resulte m´as simple de utilizar.

Aplicaci´ on de mecanismos asincr´onicos de notificaci´on a trav´es del uso de AJAX para agregar interacci´on a DJBot (ya se han realizado algunas pruebas con la biblioteca Dajaxice).

Mejora de la seguridad del sistema mediante el uso de claves SSH independientes por sala.

Agregado de un emulador de consola a la interfaz gr´afica.

Mejora del funcionamiento del buffer.

Comprobaci´ on de la funci´on de encendido de computadoras por red. Este ´ıtem es necesario para evitar el tener que desplazarse hasta las salas para iniciar los equipos.

Implementaci´ on de la funci´on de descubrimiento de computadoras encendidas disponibles para trabajar en tiempo real.

Carga autom´ atica de los valores de las computadoras que conforman una sala mediante una funci´ on de descubrimiento por red.

10.

Las conclusiones

La disponibilidad limitada de las salas de PC de la Facultad de Inform´atica motiv´ o que desde el LINTI se desarrollara una aplicaci´on web para poder realizar el trabajo de mantenimiento y administraci´on en tiempo y forma sin interferir con la utilizaci´ on acad´emica habitual de las distintas salas de PC. Adem´as de solucionar la problem´ atica original, DJBot aport´o soluciones colaterales, ya que no s´ olo permite ejecutar tareas y copiar archivos en m´as de una m´aquina al mismo tiempo, sino que ahora este trabajo no requiere de responsables expertos en la materia para poder hacerlo, ya que cualquiera puede invocar una tarea preprogramada desde la interfaz web. El acceso tambi´en es m´as simple; debido a que es una aplicaci´ on web, es posible acceder a la misma mediante un navegador web y as´ı, sin m´ as, tener acceso a todas las terminales salas de PC. Practicidad y flexibilidad son apenas dos de los beneficios que brinda esta herramienta. Por otro lado, gracias a que ahora las computadoras de la Facultad est´ an disponibles para ser utilizadas para realizar otras tareas en cualquier momento momento en que se encuentren ociosas y desde sitios remotos. Tambi´en

1157

se comenzaron a realizar tareas de investigaci´on, como pruebas de estabilidad y carga distribuida de servicios web.

La pr´ actica y experiencia de uso que se ha tenido hasta el momento son aspectos motivadores para continuar mejorando DJBot y seguir enfrentando los desaf´ıos diarios con creatividad y precisi´on. DJBot es tan solo un ejemplo del amplio abanico de soluciones que est´an a la espera de ser creadas.

Referencias 1. Parallel SSH, http://code.google.com/p/parallel-ssh/ 2. GNU/Linux Lihuen , http://www.lihuen.linti.unlp.edu.ar 3. Dinamic Host Configuration Protocol, http://linux.die.net/man/5/dhcpd.conf 4. SSH Known Hosts, http://www.linuxmanpages.com/man1/ssh.1.php 5. Paramiko, https://github.com/paramiko/paramiko 6. Fabric, http://docs.fabfile.org/en/1.6/ 7. Django, versi´ on 1.4.5, https://www.djangoproject.com/ 8. Python, versi´ on 2.7, http://www.python.org/ 9. Redis, http://redis.io/ 10. Django rqworker, https://github.com/ui/django-rq/ 11. DJBot, https://github.com/krahser/djbot

1158

Declarado de InterĂŠs Municipal por el Honorable Concejo Deliberante del Partido de General Pueyrredon