telematica

Edición Monográfica i2 ComM 2006 Modelos de canal inalámbricos y su aplicación al diseño de redes WiMAX.

13

Alexander Galvis Quintero Cristina Gómez Santamaría Roberto Carlos Hincapié Reyes

Plataforma de acceso universal a mensajería i nstantánea móvil 35 O. M. Caicedo D.A. Caicedo Caic edo E. Figueroa F. O. Martínez J. A. Hurtado

Modelo de simulación de la capa MAC IEEE 802.16-2004 para modo Mesh

57

Javier Emilio Sierra Roberto Hincapié Roberto Bustamante († (†)) Leonardo Betancur

Evaluación del estimador de capacidad AdHoc Probe en redes MANET con tráfico cursado autosimilar

79

María del Pilar Salamanca Néstor Misael Peña

Impacts of mobility on wireless access to IPv6 networks

101

Christian Lazo R. Roland Glöckler

Desarrollo de un software Web y Móvil para la gestión de información de campo de cultivos agrícolas (AgrocomM)

113

Juan Manuel Delgado Christian Giraldo Andrés F. Millán Claudia Zúñiga José Abadía

Evaluación experimental de la capacidad de IEEE 802.11b para soporte de VoIP Guefry Agredo Méndez Jaime Gaviria Molano

SISTEMAS & TELEMÁTICA

1

125

2



3

4


Revista de la facultad de ingeniería INGENIERÍA DE SISTEMAS E INGENIERÍA TELEMÁTICA UNIVERSIDAD ICESI COMITÉ EDITORIAL DE LA UNIVERSIDAD Francisco Piedrahíta Plata José Hernando Bahamón Rector

Director Académico

Héctor Ochoa Díaz

Gonzalo Ulloa

Decano de la Facultad de Ciencias Administrativas y Económicas

Decano de la Facultad de Ingenierías

Lelio Fernández Druetta Decano de Derecho y Humanidades

COMITÉ EDITORIAL DE LA REVISTA Guillermo Londoño Acosta Juan Manuel Madrid Molina Director del Programa de Ingeniería de Sistemas

Director del Programa de Ingeniería Telemática

Álvaro Pachón de la Cruz

Narcís Cardona

Jefe del Departamento de Tecnologías de Información y Comunicaciones

Profesor de la Universidad Politécnica de Valencia, España

Andrés Navarro Cadavid

Joaquín Restrepo

Profesor de la Universidad Icesi

Profesor de la Pontificia Universidad Bolivariana de Medellín

Gonzalo Ulloa

Edwin Montoya

Decano de la Facultad de Ingenierías

Profesor de la Universidad EAFIT, Medellín

Luis Eduardo Múnera

David Fernández McCaan

Profesor de la Universidad Icesi

Profesor de la Universidad de Antioquia, Medellín

Andrés Navarro Newball

Homero Ortega

Profesor de la Pontificia Universidad Javeriana, Cali

Profesor de la Universidad Industrial de Santander, Bucaramanga

Susan Gauch Profesora de la Universidad de Kansas

OFICINA DE INVESTIGACIONES Y PUBLICACIONES UNIVERSIDAD ICESI EDITOR • Los autores de los artículos de esta publicación son responsables de los mismos. • El material de esta publicación puede ser reproducido sin autorización, mencionando título, autor y, como fuente, S & T. Revista de Ingenierí a de Sistemas e Ingeniería Telemática, Universidad Icesi. Http://www.icesi.edu.co Informes: Tel.: 555 2334. Ext. 377 Fax: 555 1706 - 555 1745 Editor. e-mail:[email protected] Canje: e-mail: [email protected]

Cali, Valle, Colombia, Sudamérica SISTEMAS & TELEMÁTICA

5

6


GUÍA PARA LOS AUTORES DE ARTÍCULOS

Para los autores de los artículos de la Revista «S & T Ingeniería de Sistemas e Ingeniería Telemática» de la Universidad Icesi. • El autor debe garantizar que su artículo no ha sido publicado en ningún medio. • Los autores de artículos serán responsables de los mismos, y por tanto no comprometen ni los principios o políticas de la Universidad, ni los del Comité Editorial. • El Comité Editorial se reserva el derecho de publicar o no los artículos que no cumplan con los criterios de publicación por parte de la Universidad Icesi. • La temática de los artículos debe ser de las diferentes áreas de Ingeniería de Sistemas, Informática y Telemática, resultado de investigación propiamente dicha, aplicaciones reales, productos de investigación formativa, procesos sistémicos de análisis de problemas y propuestas de solución. • Los artículos deben contener: - Título (claro y preciso) - Breve reseña del autor.

-

Abstract o resumen ejecutivo del artículo (máximo doce renglones a doble espacio). Palabras claves. Clasificación Colciencias*. Introducción. Desarrollo. Referencias y notas de pie de página. Conclusiones. Bibliografía o fuentes de información. Extensión: No exceder de 25 páginas en total. Tipo de letra: Arial (o equivalente) fuente No. 12 y con interlineado a doble espacio. Una copia impresa y su respectivo disquete en Word Win o compatible IBM. No enviar Macintosh.

Es conveniente resaltar los párrafos u oraciones más significativos del contenido del artículo y todo aquello que dé significado a la estructura del mismo. SISTEMAS & TELEMÁTICA

7

Los artículos se deben redactar en tercera persona del singular, impersonal, contar con adecuada puntuación y redacción, carecer de errores ortográficos. Conservar equilibrio en la estructura de sus párrafos. * Clasificación Colciencias para artículos científicos y tecnológicos: a) Artículos de investigación científica y de desarrollo tecnológico: documentos que presentan resultados derivados de proyectos de investigación científica y/o desarrollo tecnológico.

8


b) Artículos de reflexiones originales sobre un problema o tópico particular: documentos que corresponden a resultados de estudios realizados por el o los autores sobre un problema teórico o práctico. c) Artículos de revisión: estudios hechos por el o los autores con el fin de dar una perspectiva general del estado de un dominio específico de la ciencia y la tecnología, de sus evoluciones durante un período y donde se señalan las perspectivas de su desarrollo y evolución futuros.

GUÍA PARA LAS RESEÑAS BIBLIOGRÁFICAS

• Tipo de libro reseñado: Debe ser de tipo ejecutivo, no un texto académico. • Título del libro: Tomado de la carátula. • Autor del libro: Apellidos, Nombre (persona del autor, lo relevante). • Nombre del traductor (si lo tuviere). • ISBN • Editorial, ciudad y fecha. • Tamaño: 16.5 cm x 23.5 cm. Número de páginas.

• Fortalezas (puntos del porqué el ejecutivo debe leerlo, cómo está estructurado el libro: partes, capítulos) etc. • Debilidades (puntos no tan atractivos del libro). • Extensión entre 700 a 800 palabras (equivalente a página y media, a doble espacio). • Lenguaje ejecutivo (breve, no académico, darle ayuda / consejo práctico para hoy, con ejemplos del texto).


9

10


La Revista S & T Ingeniería de Sistemas e Ingeniería Telemática, está dirigida a ingenieros de sistemas, ingenieros electrónicos, ingenieros telemáticos y afines; profesores universitarios y estudiantes en las diferentes áreas de la ingeniería; profesionales especializados en estas áreas. La Revista S & T Ingeniería de Sistemas está indexada por Colciencias en el Índice Nacional de Publicaciones Seriadas Científicas y Tecnológicas (categoría C). Usted puede acceder a ella entrando en nuestra página Web en internet y bajar en formato PDF el artículo de su interés o la totalidad del número que desee, sólo debe entrar a la dirección: http://www.icesi.edu.co/es/publicaciones y seleccionar la edición correspondiente. Cualquier duda o comentario dirigirlo a la cuenta de correo [email protected] El presente número es monográfico y contiene una selección de artículos publicados en el Proceedings del i2ComM 206, “Tecnologías convergentes aplicadas a la computación móvil” realizado el 21 y 22 de septiembre de 2006 en la Universidad Icesi.

EL EDITOR


11

12


Modelos de canal inalámbricos y su aplicación al diseño de redes WiMAX. Ingeniero Alexánder Galvis Quintero Cristina Gómez Santamaría, MSc. Roberto Carlos Hincapié Reyes, MSc. Grupo de Investigación, Desarrollo y Aplicación en Telecomunicaciones e Informática (GIDATI). Universidad Pontificia Bolivariana - Medellín.

Fecha de recepción: 30-05-06

Fecha de selección: 30-10-06

ABSTRACT

This article details of general way the advance of a masters thesis developed within the framework of the Group of Investigation, Development and Application in Telecommunications and Informatics (GIDATI) af the Pontifical Bolivariana University. First stage of the project consists on the classification of wireless channel models and the identification of which they apply to the work conditions of the systems defined by the IEEE 802.16-2004 standard. The second phase corresponds to the comparative analysis of these models and to their implementation in the ICS Telecom software of the French company ATDI in order to optimize some processes related to the design of these networks. The results have allowed to date deducing some important

Fecha de aceptación: 30-08-06

conclusions and to contribute to support other research and development activities in execution currently. KEY WORDS Channel model, WiMAX, radio propagation, 802.16, FWA. RESUMEN

El presente artículo detalla de manera general el avance actual de un proyecto de maestría desarrollado en el marco de trabajo del Grupo de Investigación, Desarrollo y Aplicación en Telecomunicaciones e Informática (GIDATI) de la Universidad Pontificia Bolivariana. La primera fase del proyecto consiste en la clasificación de los modelos de canal inalámbricos y la identificación de aquellos que aplican a las condiciones de trabajo de los sistemas definidos por SISTEMAS & TELEMÁTICA

13

el estándar IEEE 802.16-2004. La segunda fase corresponde al análisis comparativo de estos modelos y a su implementación en el software ICS Telecom de la empresa francesa ATDI con el objetivo de optimizar algunos procesos relacionados con el diseño de estas redes. Los resultados han permitido hasta la fecha sacar

14


algunas conclusiones importantes y aportar realimentación a otras actividades de investigación y desarrollo en ejecución. PALABRAS CLAVE

Modelo de canal, WiMAX, radio propagación, 802.16, FWA. Clasificación Colciencias: A

I. INTRODUCCIÓN

Las actividades de planeación, diseño, despliegue y mantenimiento de redes inalámbricas implican el uso de una serie de herramientas computacionales que han sido creadas con el objetivo de predecir el comportamiento de estas redes para tomar decisiones basadas en los resultados obtenidos de dicha aplicación. Uno de los aspectos más complejos relacionados con los sistemas inalámbricos es la manera como se modela el medio de propagación de las señales, el canal de radio y el ambiente en el cual se encuentra inmerso un sistema particular. Actualmente existe gran variedad de modelos que han sido desarrollados para dar soluciones particulares a los problemas que surgen en cada caso y ambiente de aplicación específico; y aunque en general las soluciones planteadas han ofrecido hasta el momento buenos resultados, existe una notable dificultad relacionada con la elección del modelo óptimo para la situación en estudio, lo que le resta considerable flexibilidad a los procesos mencionados anteriormente. Debido a la importancia misma de las tecnologías involucradas, es necesario desarrollar herramientas que mejoren significativamente los procesos de análisis, diseño e implementación de redes inalámbricas de telecomunicaciones, a la vez que permitan optimizar los procesos de aprendizaje y las actividades de entrenamiento de personal técnico y científico al interior de las empresas, universidades y centros de investigación. Considerando lo anterior, dentro del Grupo de Investigación, Desarrollo y Aplicación en Telecomunicaciones e Informática (GIDATI) de la Uni-

versidad Pontificia Bolivariana está en actual desarrollo un proyecto de Maestría en Ingeniería, el cual se concentra en la definición del estado del arte en modelamiento de canales de radio, y en la clasificación de los modelos más representativos con el objetivo de apoyar y optimizar las actividades académicas y aquellas técnicas relacionadas con los procesos mencionados inicialmente. Partiendo de esta clasificación general, se ha dirigido la atención a la particularización de los modelos aplicables al estándar IEEE 802.16-2004 [1] y a su implementación en una herramienta de simulación para conformar un modelo general de capas inferiores para estos sistemas. Inicialmente se está realizando una revisión de los modelos de canal existentes que aplican a esta tecnología, extrayendo un subconjunto de ellos de acuerdo con ciertos criterios como el grado de aproximación, la correspondencia con los casos particulares a analizar, el nivel de complejidad previsto para su implementación, entre otros. Los modelos seleccionados son adaptados a los sistemas y ambientes particulares, tarea que implica el esfuerzo más significativo considerando la topografía colombiana. Seguidamente se realizará la simplificación de los mismos para su escritura en lenguaje C++ y generar finalmente las librerías (DLL) que los implementen como modelos de canal definidos/desarrollados por el usuario en el interior del software de planeación, diseño y simulación de redes inalámbricas ICS Telecom® de la empresa francesa ATDI. Las campañas de simulación se encuentran en fase de diseño para obtener resultados que permitan realizar análisis comparativos entre SISTEMAS & TELEMÁTICA

15

los diversos modelos estudiados y contrastarlos a la vez con los primeros datos de mediciones reales que se han realizado para el despliegue de infraestructura WiMAX1 en el país. Finalmente se concluirá y se presentarán propuestas para dar continuidad al trabajo considerando otras alternativas y tendencias. II .MODELAMIENTO DE CANALES DE RADIO

El modelamiento de canales de radio es uno de los aspectos más críticos a considerar en la construcción de herramientas software que apoyen los procesos de planeación y diseño de redes inalámbricas. Para el caso particular de WiMAX es de especial interés el modelo de canal utilizado para la predicción del comportamiento del sistema, tanto en la estimación de los niveles de cobertura como de las tasas de transmisión alcanzables, más aun teniendo en cuenta que el sistema se ha definido para condiciones de LOS, nLOS y NLOS 2 [2]. Como se expone en [3], la práctica más desarrollada y la que mejores resultados ha ofrecido es la de inicialmente describir el canal de forma matemática (modelarlo) para comprender mejor su comportamiento en ciertas condiciones y caracterizarlo de manera detallada. Posteriormente dicho modelo es llevado a un lenguaje computacional para el desarrollo de componentes de simulación que apoyen las actividades

1 2

de diseño de redes. El reto siempre es lograr modelos lo suficientemente completos, descriptivos y simples que permitan desarrollar simulaciones eficientes en todos los sentidos. En términos generales, los modelos de canal buscan predecir el nivel de pérdida de potencia que una señal de ciertas características sufre cuando se propaga por un ambiente geográfico determinado. Como se observa en la Figura 1, el comportamiento de la variable potencia en recepción es

Figura 1. Comportamiento de la potencia recibida en función de la frecuencia de operación y la distancia entre transmisor y receptor.

inversamente proporcional tanto a la distancia de separación entre transmisor y receptor como a la frecuencia de operación, y además, se presentan otros fenómenos (ensombrecimiento, desvanecimiento por multitrayectoria, desvanecimiento por efectos atmosféricos, difracción y refracción, centelleo, cell breathing , retardos,

WiMAX:Wireless interoperability for Microwave Access (estandarizado por el IEEE 802.16 WG) LOS/nLOS/NLOS: Line Of Sight / near LOS / No LOS.

16


otras atenuaciones, interferencias y re garantizar exactitud razonable. ruido) que cada modelo considera de Adicionalmente, gran cantidad de forma distinta. El tipo de ambiente modelos consideran solo algunos y los fenómenos mencionados hacen fenómenos y en consecuencia deben que la superficie mostrada en la aplicarse varios de ellos antes de Figura 1 cambie significativamente obtener un resultado práctico. Es volviéndola no determinística, así que esto precisamente lo que hacen heel desarrollo de un modelo matemá- rramientas como ICS Telecom®, que tico del canal de comunicaciones y su utiliza una interfaz para configurar posterior implementación software los parámetros de simulación en lo debe considerar tanto los medios de referente a los modelos de canal a propagación y las frecuencias utiliza- utilizar y fenómenos a considerar; das para la radiación de señales como cada fenómeno se simula virtualmenel ambiente geográfico en el cual se te por separado y luego se integran va a desplegar el sistema y el tipo de los resultados para entregar una sistema (servicios y aplicaciones). respuesta única. En [4] y [5] se realiza una clasifi- En cuanto a la clasificación de los cación general de radio canales, fenómenos de propagación, independiferenciando aquellos que han sido dientemente de cuál sea el fenómeno, formulados empíricamente (basados el efecto total sobre la señal normalen mediciones) de otros cuya formu- mente es una atenuación o desvanelación obedece a la física propiamente cimiento ( fading ), por lo que dichos dicha relacionada con los fenómenos fenómenos tradicionalmente se han de propagación de señales. clasificado como se muestra en la No obstante, con el advenimiento Figura 2. Con esta figura se puede exde la informática se han dado otras plicar por qué algunos modelos apliorientaciones en lo que a modela- can sólo a sistemas banda angosta, o miento matemático se refiere, las por qué en ciertos ambientes es más cuales incluyen análisis geométricos determinante un efecto que otro. como el ray tracing , y el análisis De los fenómenos presentes, aquel espaciotemporal que actualmente se que ha sido más analizado en lo que encuentra en pleno desarrollo con el va ejecutado del proyecto son las objetivo de impulsar nuevas tecnolo- pérdidas de trayecto o path losses, gías de comunicaciones. Una de estas pues comprenden un alto porcentaje tecnologías novedosas es WiMAX, de las pérdidas totales que experique opera en bandas de frecuencia y menta la señal WiMAX al propaen condiciones para las cuales pocos garse, incidiendo fuertemente en la modelos de canal desarrollados has- cobertura del sistema y en las tasas ta el momento aplican de manera de transmisión alcanzables. Los otros eficiente, debido a que aquellos que fenómenos como la multitrayectoria se ofrecen resultados más aproximados describen/analizan generalmente con a la realidad han sido construidos modelos basados en taps y las pérdidas empíricamente y su extrapolación a estimadas se adicionan a aquellas otras bandas de trabajo y condiciones sucedidas en el trayecto de propagade operación es compleja si se quie- ción. No obstante, antes de entrar


17

Manifestaciones del desvanecimiento en el canal

Desvanecimiento de gran escala debido a movimientos sobre áreas grandes

Desvanecimiento de pequeña escala debido a pequeños cambios en la posición Duales

Atenuación medio de la señal Vs. distancia

Variaciones alrededor de la media

Descripción en el dominio del tiempo (retardo)

Desvanecimiento selectivo en frecuencia

Transformada de Fourier

Desvanecimiento plano

Descripción en el dominio de la frecuencia

Desvanecimiento selectivo en frecuencia

Variación temporal del canal

Dispersión temporal de la señal

Descripción en el dominio del tiempo

Desvanecimiento plano

Desvanecimiento rápido

Transformada de Fourier

Desvanecimiento lento

Descripción en el dominio de la frecuencia (corrimiento Doppler)

Desvanecimiento rápido

Desvanecimiento lento

Duales

Figura 2. Diferentes tipos de desvanecimiento [7].

en la descripción de estos análisis se presentarán en seguida algunos de los resultados de la primera fase del proyecto, consistente en la clasificación general de los modelos de canal aplicados en radiocomunicaciones. III. CLASIFICACIÓN GENERAL

Durante la revisión bibliográfica para el desarrollo de la primera fase del proyecto se encontraron diversas clasificaciones y descripciones de los modelos de canal desarrollados hasta el momento por varios autores, pero dichas clasificaciones, como las presentadas en [5], [6] y [7], se concentran casi exclusivamente en la descripción superficial de los modelos revisados, mas no en la generación de una herramienta que permita “escoger” un modelo determinado para que sea aplicado en el diseño o estudio de un sistema particular. Por tal motivo se fijó desde el principio que uno de los objetivos del proyecto sería el desarrollo de una tabla general de clasificación para los modelos de ca-

18


nal más importantes con los cuales se cuenta en la actualidad. Para la clasificación se tuvieron en cuenta inicialmente aspectos como la banda y los ambientes de aplicación, al igual que las aplicaciones propiamente dichas (ver Figura 3), para posteriormente pasar a detallar un amplio conjunto de aspectos que se encuentran identificados en la Tabla I. Tabla I. Aspectos considerados en la clasificación de los modelos de canal inalámbricos. Proponentes Tipo Aplicación (Tecnologías) Tipo de zona de aplicación Otras consideraciones para su Ambiente de aplicación aplicación Clutter general Formulación matemática Banda(s) de aplicación Selectividad en frecuencia (WB Descripción de parámetros Variables de entrada o NB) Variables de salida Área de predicción Complejidad computacional Exactitud Formulación lógica Generalidad Referencias Implementado en software Enlaces y referencias Edad [¿En desarrollo?]

En total, se clasificaron 50 modelos de canal inalámbricos de acuerdo con los aspectos y parámetros mencionados (ver Tabla II), y se cuenta con des-

Figura 3. Descripción de la tabla de clasificación de modelos de canal.

cripciones breves de la formulación matemática y lógica, además de las referencias completas para cada uno

de ellos en caso de que quien utilice la tabla necesite profundizar más en un modelo particular.

Tabla II. Modelos de canal clasificados. Fiss model 2-ray model (ground reflection) Knife-edge difraction model Multiple knife-edge difraction model Longley-Rice model Durkin’s model Okumura-hata model COST231 - Okumura-Hata model COST231 - Walfisch-Ikegami model Okumura-Hata at 3,5GHz Walden FWA model for 3,5GHz Saunders-Bonar model Ibrahim-Parsons model Allsebrook-Parsons model Dual slop model Walfisch-Bertoni model Lee model Loo statistical model Corazza model Lutz model Rural dominant path model Urban dominant path model Indoor dominant path model Blaunstein models Street canyon model 2D/3D standard ray tracing 2D/3D intelligent ray tracing

Partition losses models Ericsson multiple breackpoint model Attenuation factor model One slope model Motley Keenan model Multi wall model Radar cross section model Log-normal shadowing model Clarke’s model for flat fading (TAP based model) 2-ray Rayleigh fading model Saleh-Valenzuela statistical model SIRCIM statistical model SMRCIM statistical model IHE model ECC-33 Time dispersion models (Delay spread - TAPs models) Frequency dispersion models (Doppler spread) Blaustein-Anderson models 2D/3D standard ray tracing 2D/3D intelligent ray tracing ITU-R model (P.840 y P.838) Crane model Emiliani ITU-R model (P.618) Rayleigh based models

Algunos de los modelos estudiados ya han sido implementados en MatLab® para realizar análisis comparativos, y un subconjunto de ellos –específicamente los macrocelulares– fue implementado en el software de simulación JavaDES® desarrollado por el MSc. Roberto Hincapié, del GIDATI. En dicha implementación no solo fueron considerados los efectos de propagación sino que también se incluyeron aspectos relacionados con los modelos de movilidad y las distribuciones de tráfico en sistemas predominantemente celulares. La Figura 4 muestra una captura de la interfaz de simulación del JavaDES. No obstante, la tabla general de clasificación aún se encuentra en proceso de revisión y depuración para incrementar la utilidad de la herramienta que constituye dicha clasificación.


19

Figura 4. Ambiente de simulación del JavaDES® [11].

IV. MODELOS APLICADOS A WiMAX

Como se mencionó anteriormente, la segunda fase del proyecto consiste en estudiar de manera más profunda un subconjunto de los canales clasificados en la fase inicial, centrando el interés en aquellos que aplican particularmente al estándar IEEE 802.16-2004 (WiMAX). En [8] y [9] se describen los modelos de canal inicialmente sugeridos en el interior del IEEE 802.16 WG para la simulación de los sistemas FWA.3 Para el caso particular de interés es importante tener en cuenta que la condición en la cual operarán normalmente las redes WiMAX será una condición de NLOS, por lo que los modelos que asumen LOS deben ser desde ya obviados en el análisis a realizar. Para el canal en condiciones de NLOS la señal puede 3 4

FWA: Fixed Wireless Access. RF: Radio Frequency.

20


experimentar dispersión, difracción, cambios de polarización y reflexión, factores que afectan la intensidad de la señal recibida. Se han desarrollado varios modelos que procuran caracterizar este ambiente de RF 4 y permitir la predicción de la intensidad de la señal de RF en recepción, los cuales en su mayoría están basados en medidas empíricas y son utilizados actualmente para predecir la cobertura a gran escala en sistemas celulares. Estos modelos proporcionan estimaciones de las pérdidas de trayecto considerando la distancia entre el transmisor y el receptor, factores del terreno, altura de las antenas y frecuencias de operación. Desafortunadamente ninguno de estos acercamientos trata adecuadamente las necesidades y las condiciones de los sistemas FWA.

En [2] se afirma que AT&T ha realizado una gran cantidad de mediciones en varias áreas a través de los Estados Unidos para modelar con mayor exactitud el ambiente fijo inalámbrico de RF. El modelo empírico de AT&T ya ha sido validado contra el despliegue de sistemas de acceso fijo inalámbrico y ha arrojado resultados comparables. Este modelo es la base de un modelo aceptado en la industria y es utilizado por los grupos de estandarización como el IEEE 802.16 WG. El modelo de pérdidas de trayecto de AT&T incluye parámetros como las alturas de antena, la frecuencia portadora y el tipo del terreno (clutter). Así mismo, la Universidad de Stanford desarrolló hace un par de años un conjunto de modelos de canal para la simulación del fenómeno de multitrayectoria en sistemas LMDS.5 Estos modelos se denominan Stanford University Interim Models (comúnmente abreviados SUI models). Los seis modelos SUI son una extensión del trabajo de AT&T y aplican para tres categorías de terreno: • Tipo A: Colinas pequeñas con moderada-alta densidad de árboles. • Tipo B: Colinas grandes con baja densidad de árboles, o plano con moderada-alta densidad de árboles. • Tipo C: Plano con baja densidad de árboles. Estas categorías de terreno proporcionan un método simple más exacto para la estimación de las pérdidas de trayecto sobre el canal de RF en condiciones de NLOS. Al ser estadística su naturaleza [9], el modelo puede 5

representar una gran gama de las pérdidas de trayecto experimentadas dentro de una comunicación real en la banda de RF. Los modelos SUI fueron seleccionados para el diseño, el desarrollo y la prueba de las tecnologías WiMAX en seis diversos panoramas, SUI-1 a SUI-6, descritos en [9]. Con el uso de estos modelos de canal es posible entonces predecir más exactamente la cobertura que se puede alcanzar con una estación base configurada de una manera determinada, lo que claramente es un apoyo a las actividades de planeación y diseño de redes WiMAX. No obstante, existe un inconveniente práctico con los modelos SUI, y está relacionado precisamente con la clasificación de terreno para la cual aplican, pues ninguno de los seis modelos considera zonas urbanas o urbanas densas que son de hecho donde se esperan los mayores despliegues de infraestructura WiMAX. Dentro de los modelos macrocelulares clasificados existe una gran variedad de ellos que han sido obtenidos empíricamente a partir de mediciones en condiciones de NLOS, y virtualmente cualquiera de éstos puede ser ajustado/extrapolado para que sea aplicado a la banda de 3,5GHz. La Figura 5 muestra algunas curvas comparativas de la potencia de recepción estimada con varios modelos de pérdidas de trayecto en condiciones equivalentes, donde es notable que en términos generales la diferencia entre sus predicciones es de varios dB. Por este motivo es de gran importancia la selección del modelo de pérdidas de trayecto a la hora de simular sistemas WiMAX y realizar

LMDS: Local Multipoint Distribution System.


21

-60 -80

B d a d i b i c e r a i c n e t o P

Friss Plane eart loss Path loss Clutter factor Okumura-Hata Walfisch-Ikegami

-100 -120 -140 -160 -180 -200 400

500

600

700

800

900

1000

1100

1200

1300

Frecuencia MHz

Figura 5. Curvas comparativas de Prx Vs. Frecuencia de operación para varios modelos de path loss macrocelulares [11].

cual se asume una distribución normal con las labores de diseño de la red, pues desviación estándar entre 8 y 10 dB. algunos son más optimistas que otros, y no todos aplican igual en las mis- Adicionalmente, en [8] se describen mas condiciones topográficas. En [8] algunos factores de corrección necese describe uno de los modelos de path sarios para ajustar los modelos a las loss adoptado por el IEEE 802.16 WG, bandas cercanas a los 2GHz. Debido el cual da las pérdidas de trayecto al ambiente dispersivo, el canal tiene según la Ec. 1. un perfil de retardos por el fenómeno de multitrayectoria. Este modelo de canal dispersivo en tiempo, también presentado en [8], es un típico modelo de multitrayectoria basado en taps, y su parametrización conduce a los Donde: A=20Log (4 πd / λ ), con λ dada seis modelos SUI mencionados anteen metros. γ es el exponente de path loss dado por γ=(a-b*hb+c/hb), con la altura de riormente. Para el caso de antenas la antena de estación base 10m
o

o

22


La curva utilizada para el modelamiento del perfil de retardo está dada por la Ec. 3, y los valores típicos del retardo RMS en el canal inalámbrico están en el rango de 0,1 a 5 µs. Adi-

cionalmente se considera el efecto Doppler y un factor de corrección K para incluir las características que el canal presenta en condiciones de NLOS, es decir, definirlo como tipo Rice o tipo Rayleigh [8].

En términos generales, para el diseño en la óptica geométrica) más que en y optimización de redes FWA, los mo- estadísticas obtenidas de conjuntos delos utilizados son de tipo empírico, de mediciones. Se encuentran muchos tanto para los cálculos de path loss modelos de este tipo descritos en la (modelos empíricos no dispersivos en mayoría de la bibliografía existente el tiempo) como para los análisis de sobre el tema, pero son modelos cuya multitrayectoria (modelos empíricos exactitud, capacidad y éxito en las predicciones depende de la informadispersivos en el tiempo). ción que se tenga acerca del ambiente En [12] son presentados varios mogeográfico de operación del sistema delos empíricos no dispersivos en tiempo, los cuales permiten calcular en estudio. Estos modelos pueden estar o no orientados a un sitio es path loss de manera aproximada en pecífico, y no solo deben aplicar las la mayoría de los casos. De todos los clasificados, son raros los modelos leyes físicas del electromagnetismo sino que deben incluir también una empíricos que proporcionan información sobre dispersión en el tiem- técnica sistemática para “mapear” po, y los pocos que existen son muy el ambiente real de propagación dentro del modelo mismo [12]. No similares. Al predecir las pérdidas obstante, existen modelos físicos no medias en el trayecto basándose en dispersivos en tiempo y orientados un conjunto de mediciones, podría a sitio específico, como por ejemplo utilizarse un modelo correspondiente de de dispersión temporal para obtener el modelo geométrico de trazado rayos en dos dimensiones ( 2D Ray el perfil de retardo temporal de cada Tracing model ), mejor conocido como curva derivada estadísticamente, el modelo de Anderson. Otro ejemplo o mediante tabulación de datos, –posiblemente más conocido– es el siendo ésta una forma de predecir modelo Longley-Rice, que ha sido la dispersión en el tiempo causada por algunos ambientes basándose en implementado en la mayoría de las herramientas computacionales para sus características [12]. Un ejemplo diseño de redes inalámbricas y radiode este tipo de modelos son los SUI enlaces. Este tipo de modelos aplica descritos anteriormente. muy bien para el diseño de redes de También existe la alternativa de acceso fijo inalámbrico; pero hay un aplicar o desarrollar modelos físicos tercer grupo de modelos físicos que basados en los principios físicos de están orientados a sitio específico y la radiopropagación (normalmente además son dispersivos en tiempo. SISTEMAS & TELEMÁTICA

23

Estos modelos aplican las leyes físicas por ser el modelo tradicionalmente de manera muy precisa sobre carto- aplicado para el cálculo de path loss grafía detallada del ambiente real de y para la predicción de niveles de operación; rastrean la trayectoria de recepción, ha sido extrapolado hasta las ondas electromagnéticas cuando la banda de 4GHz. El modelo resuldejan el transmisor e interactúan tante es descrito en [10] de manera con objetos en el ambiente. Esto no comparativa con otros dos modelos: el solo proporciona información sobre ECC-33 [13] y el modelo de path loss la dispersión en el tiempo sino tam- tomado para SUI y adaptado a FWA, bién información sobre el ángulo de como se describió anteriormente. llegada que es de gran interés para El modelo de path loss de Hata, sistemas que utilizan antenas adap- ajustado y extrapolado hasta 4GHz, tativas, por ejemplo. muestra que la atenuación en dB Es claro entonces que para la ade- tiene una función de distribución de cuada planeación y diseño de redes probabilidad gaussiana con media WiMAX se necesita la combinación A50 (ver Ec. 4) y determinada desde modelos predictivos tanto de pér- viación estándar (ver Ec. 4). El IEEE didas medias en el trayecto como de 802.16 WG ha adoptado también este fenómenos de multitrayectoria. En modelo como el modelo de path loss cuanto a los modelos de path loss, para el diseño de redes WiMAX, y es hasta el momento se han estudiado más conocido como el modelo ECC-33 los mencionados anteriormente más [13]. Dicho modelo de propagación es algunas modificaciones realizadas al path loss con atenuación aleatoria, modelo de Hata descritas brevemente teniendo en cuenta difracción sobre en [10]. Y en lo referente a los mo- tejados y múltiples reflexiones para delos de multipath y consideración media/alta cantidad de edificaciones, de otros fenómenos, se han revisado muy típico de Japón, al igual que los modelos propuestos por Stanford sus versiones anteriores. Aplica a y sus variantes para la banda de ciudades grandes y medianas, e in3,5GHz descritas en [8] y [10]. dica además correcciones para áreas En términos generales, todas las suburbanas y áreas abiertas. Las propuestas para el modelamiento de distancias límite son menores a 10 canales aplicable a WiMAX giran en km y las alturas de antena oscilan torno a estos modelos y sus variantes. entre 20 y 200 metros. El resultado Algunos modelos de path loss, como de la extrapolación es que la señal el de Walfish-Ikegami por ejemplo, recibida está dada por: tienden a ser demasiado optimistas para zonas urbanas, las cuales son de principal interés para los operadores Donde: Afs=92,4+20Log(D)+20log(RF), son las pérdidas espacio libre. WiMAX, y además tienen el inconveniente de ser aplicables sólo dentro A =20,41+9,83Log(D)+7,894Log(RF)+ de ciertas bandas de trabajo que no 9,56[log(RF)] , pérdida media básica de trayecto. serán de implementación comercial inmediata. El modelo de COST-231 GC=Log(hc/200){13,958+5.8[Log(D)]2}, ganancia en BS. Hata tiene la misma limitación, pero bm

2

24


G T=[42,57+13,7Log(RF)][Log(ht)–0,585] para ciudades medianas y G T=0,795ht– 1,862 para grandes ciudades. RF en GHz, D en km, hc y ht en m (altura BS y altura SS respectivamente).

Adicionalmente, a los modelos SUI de dispersión temporal –que también son empíricos– se les han realizado algunas modificaciones para aplicarlos a la banda de 3,5GHz, pues su planteamiento original fue para frecuencias entre 2,5 y 2,7 GHz. Como ya se explicó, los modelos SUI definen dos modelos para cada uno de los tipos de terreno (clutter) y hacen un total de seis clasificaciones. En [14] los autores exponen algunos aspectos encontrados inconsistentes en los modelos SUI, relacionados con el corrimiento Doppler en multitrayectoria, el perfil potenciaretardo, los patrones de radiación considerados, los valores asumidos para el factor K, y la función de correlación de frecuencia. De cualquier manera, los modelos SUI fueron desarrollados específicamente para uso en la banda de frecuencias de MMDS 6 en Norteamérica. En [8] se afirma que el modelo podría desempeñarse adecuadamente en el rango de 2 a 4 GHz, el cual incluye las bandas de 3,5GHz que han sido asignadas en Europa y en Colombia para la operación comercial de WiMAX. La ecuación de path loss en los modelos SUI fue derivada básicamente de mediciones en áreas suburbanas, y hasta el momento no se han incluido factores de corrección para zonas urbanas o de alta densidad de edificios, ni para zonas rurales. Además, tampoco hay manera de relacionar los tres tipos

o categorías de terreno a los clutters comúnmente disponibles o a bases de datos de terreno, así que el método para seleccionar la categoría a aplicar en algún escenario de despliegue de un sistema particular no es sistemático. Las medidas fueron tomadas a distancias cercanas a los 7 km, las cuales son adecuadas para la evaluación de cobertura y servicio; sin embargo, para redes FWA multicelda en las cuales se necesita la reutilización de frecuencias, se requieren los niveles de interferencia de la señal desde celdas que pueden estar alejadas varios radios de celda. Los modelos SUI no ofrecen orientación sobre path loss a estas distancias, y como se afirma en [12] se puede esperar que los valores de path loss arrojados por los SUI extrapolados a estas distancias pudieran casi ciertamente ser más grandes que aquellos experimentados en los sistemas reales. Por otro lado, hay gran variedad de modelos basados en la técnica de ray-tracing . Dichos modelos físicos –que pueden ser bidimensionales o tridimensionales– han demostrado tener los niveles de exactitud más altos en las pruebas comparativas, como se muestra en [12], limitados casi exclusivamente por el nivel de detalle de la información cartográfica proporcionada. Adicionalmente estos modelos realizan cálculos de reflexión, difracción, rayo directo, multitrayectoria (muy importante en sistemas WiMAX, especialmente en condiciones de NLOS), y respuesta impulsiva del canal, entregando

6 MMDS: Multichannel Multipoint Distribution System.


25

resultados de intensidad de campo, pérdidas de trayecto, delay spread, angular spread, y respuesta impulsiva del canal. La Figura 6 muestra curvas comparativas de las predic-

ciones realizadas utilizando algunos modelos mencionados, y es clara la superioridad de las técnicas de raytracing cuando se utiliza cartografía de alta definición.

Figura 6. Comparación de modelos predictivos aplicables a diseño de rdes WiMAX [12].

V. SIMULACIONES E IMPLEMENTACIONES

Hace un par de años el requerimiento de algunos modelos a los que se les proporcionó información muy detallada del sitio específico en el cual se va a desplegar la red era visto como una desventaja porque se disponía de pocas bases de datos con información de ese tipo. No obstante, en la actualidad existe cartografía de alta resolución de muchas zonas de interés para el despliegue de infraestructura y para el ofrecimiento de servicios, lo que convierte a los modelos físicos –especialmente los geométricos– en muy buenos candidatos para apoyar las actividades de planeación y diseño de redes WiMAX. No obstante, aunque el GIDATI cuenta con cartografía de alta resolución de Medellín, no se ha profundizado aún en el estudio

26


de este tipo de modelos y hasta el momento se han aplicado las configuraciones que por defecto permite el software ICS Telecom, concentrando la atención por el momento en las implicaciones que tiene la selección de modelo de path loss en la exactitud de los resultados. Para la planeación de redes WiMAX, es entonces de gran interés que los modelos utilizados proporcionen flexibilidad a los procesos y los doten de gran exactitud. Por este motivo, para la investigación actual se han seleccionado cinco modelos para su implementación y para la realización de comparaciones mediante los resultados de simulación: • Modelo ECC-33: Es una modificación del conocido modelo de Okumura-Hata, que permite

ajustarlo a condiciones de operación banda ancha y ambientes de alta influencia multitrayectoria. • Modelos SUI: Son los Stanford University Interim, que en total son seis y actualmente los más aplicados en el estudio de la tecnología WiMAX. • 3D Intelligent Ray Tracing: Desarrollado principalmente en Stuttgart University. Es un modelo geométrico algo complejo, pero considerando que se cuenta con información cartográfica detallada, su implementación deberá ofrecer buenos resultados. • Urban Dominant Path Model: También desarrollado en Stuttgart University, es una modificación del anterior que identifica

los trayectos dominantes en la comunicación y considera sólo las señales relacionadas con esos trayectos reduciendo así el volumen de cálculos a realizar. • Walden-Rowsell model: Es un modelo empírico simple de path loss presentado en [17], basado en mediciones realizadas directamente en la banda de 3,5GHz. Actualmente se está utilizando este modelo en otro proyecto en el interior del GIDATI para la creación de un modelo genérico de la capa física de sistemas WiMAX sobre Network Simulator 2, debido a que es el que mejor aproximación a datos reales presenta. En la Tabla III se realiza una comparación de cuatro de los cinco modelos seleccionados.

Tabla III. Comparación de modelos predictivos aplicables a diseño de redes WiMAX. Modelos empíricos (SUI y ECC-33)

DPM

3DRT

Rural X X Escenario Urbano X X X Interiores X X X Intensidad del campo, Pérdidas de trayecto, Potencia X X X Delay Spread X Resultados Angular Spread LOS/NLOS X X X Respuesta impulsiva del canal X Rayo directo X X X Reflexiones Incluido Ili mitado Difracciones Ilimitado 2 Cálculos Reflexiones y difracciones XX Reflexión, difracción y transmisión X X Multitrayectoria X Respuesta impulsiva del canal X Áreas grandes X Área de predicción Áreas medianas X X Áreas pequeñas X X Cerca del transmisor Satisface Muy alta Muy alta* Exactitud Lejos del transmisor Limitada Muy alta Media* Predicción Muy baja Corta Corta* Tiempo de cálculo Preprocesamiento Ninguno Ninguno Medio* * dependiendo de la configuración del modelo (ej. Número de interacciones)


27

X

En la actualidad, la mayoría de las VI. RESULTADOS OBTENIDOS herramientas software que asis- Y PROYECTADOS ten actividades de diseño de redes Varios investigadores ya han realiza –incluida ICS Telecom de ATDI –, do comparaciones entre los modelos aplican los tres tipos de orientaciones seleccionados y han sacado conclude manera individual. Por ejemplo, siones importantes. En [10], los aucomo se describe en [16] y [17], es tores analizan brevemente el modelo común aplicar modelos de path loss COST-231 Hata, el modelo ECC- 33 y como el ITU-R P.525/526 junto con un los modelos SUI aplicados al cálculo modelo geométrico de difracción como de path loss y comparan los resultael de Deygout, una integración media dos con mediciones reales. La Figura para atenuaciones en subtrayectos, y 7 muestra el resultado gráfico de la un modelo geométrico reflectivo 2D o comparación para una zona urbana, 3D para análisis de multitrayectoria que como ya se ha dicho es de especial y efecto cañón. La intención entonces interés para los operadores de redes de combinar estos diferentes tipos WiMAX. No obstante, una vez que de modelos es la validación de los estos modelos sean implementados SUI en actividades de diseño real, 7 en ICS Telecom, se espera que los y la aplicación de conceptos de ray- resultados varíen un poco considerando la topografía colombiana, y tracing en un modelo completo sobre la herramienta ICS Telecom, para lo precisamente determinar esas variacual se cuenta con cartografía de alta ciones y los factores más influyentes resolución de la zona metropolitana es otro de los objetivos del proyecto. de Medellín. Como ya se mencionó, Actualmente se lleva a cabo una con SUI se tiene el inconveniente de campaña de simulación que utiliza la que los modelos no aplican a zonas cartografía de alta resolución y la heurbanas ni rurales; con el modelo rramienta ICS Telecom con diversas ECC- 33 se tiene el problema de que configuraciones de los parámetros del es el resultado de una extrapolación modelo de propagación aplicado, con de un modelo que desde antes se pre- el objetivo de comparar la incidencia sentaba como demasiado optimista en de éstos en las predicciones y deterlas predicciones para zonas rurales; minar posteriormente el grado de y con ray-tracing existe un requeri- aproximación de cada configuración miento en procesamiento que no se a los datos reales obtenidos mediante tiene con los dos modelos anteriores. pruebas de drive test. La implementación de estos cinco En la Figura 8 se muestra la predicmodelos permitirá determinar cuál ción de cobertura para la zona sues la combinación adecuada de orien- burbana de la Universidad Pontificia taciones en modelamiento de canales Bolivariana, realizada aplicando el para el diseño de redes WiMAX. modelo COST-231 Hata, con alturas

7

Las simulaciones actuales se están realizando con ICS Telecom nG versión 7. La nueva versión del software cuenta ya con implementaciones de los modelos SUI, lo que proporciona otra alternativa para validación de resultados.

28


Figura 7. Comparación de modelos empíricos con mediciones en un ambiente típico urbano [10].

de antena de estación base y estación suscriptora iguales a 12m y 4m respectivamente, potencia de transmisión de 1W, antenas omnidireccionales con 14dB de ganancia, banda de

trabajo de 3,5GHz, ancho de banda de canal igual a 1,75GHz y esquemas de codificación/modulación 3/4 64-QAM (aunque el valor de estos dos últimos parámetros es indiferente).

Figura 8. Predicción de cobertura para WiMAX a 3,5 GHz usando el modelo COST-231 Hata.


29

Si se compara este resultado con el mostrado en la Figura. 9, se observa claramente que el modelo ITU-R 525 es mucho más optimista que COST231 Hata. En general, los modelos de Hata se comportan más pesimistas

que otros modelos en zonas distintas a Japón, y de hecho, ese fue motivo por el cual se seleccionó el modelo de Walden-Rowsell para el otro proyecto mencionado.

Figura. 9. Predicción de cobertura para WiMAX a 3,5 GHz usando el modelo ITU-R 525.

Las campañas de simulación incluyen una amplia variación de los parámetros de configuración de los modelos, y están llevándose a cabo mientras se termina la construcción de las DLL que permitan realizar simulaciones adicionales de los modelos seleccionados. Los resultados serán utilizados en el presente proyecto y en otros que se ejecutan de forma paralela al interior del GIDATI, y permiten la validación de resultados y la formulación de propuestas para futuros proyectos.

30


VII. CONCLUSIONES Y RECOMENDACIONES

Como se describió a lo largo del artículo, debido a las limitaciones citadas los modelos SUI son más apropiados para propósitos de dimensionamiento o de desarrollo de equipos que para la planeación y diseño detallados de la red WiMAX en locaciones específicas. Para propósitos de planeación son más apropiados los modelos físicos que puedan explotar la información detallada que se tenga del terreno, del clutter, y de las edificaciones circundantes.

Las simulaciones realizadas han proporcionado información suficiente para empezar a determinar qué factores son los que mayormente impactan en la selección del modelo de canal a utilizar, y cómo esto afecta las actividades de planeación y diseño. De esta manera se presenta la tabla de clasificación de canales como una herramienta propiamente dicha diseñada para asistir en las labores de ingeniería de red y apoyar las decisiones referentes al tema que se ha tratado. En cuanto a la herramienta ICS Telecom, se ha observado que los resultados que arroja no siguen un comportamiento basado completamente en modelos probabilísticos, pues los resultados siempre son los mismos con las mismas condiciones generales, pero se ha asumido en las campañas que los datos corresponden a valores medios estimados en cada punto de la cartografía. Finalmente, teniendo en cuenta los objetivos de esta primera fase, de todo el desarrollo se pueden consignar dos conclusiones generales: • Determinar el “estado del arte” en el modelamiento de canales de radio y clasificar los modelos existentes/disponibles estudiados ha facilitado el desarrollo de las actividades académicas y también de las ingenieriles como la planeación y el diseño de redes inalámbricas. • El desarrollo de cuadros clasificatorios y comparativos para los diferentes modelos de canal aplicables, permite que la creación y/u optimización de herramientas software para planeación, diseño

y simulación de redes sea más eficiente. Los resultados son en sí mismos un instrumento de estudio e ingeniería. AGRADECIMIENTOS

Los autores expresan sus agradecimientos a la empresa TES América Andina Ltda. por facilitar la cartografía sobre la cual se están desarrollando las campañas de simulación. También al ingeniero Néstor Orlando Bayona Acosta de la UPB por sus aportes en el desarrollo del simulador JavaDES®, y en general a todos aquellos que han colaborado en la ejecución del proyecto. BIBLIOGRAFÍA

[1] IEEE LAN/MAN SC. IEEE Std. 802.16-2004 – Part 16: Air Interface for Fixed Broadband Wireless Access Systems. IEEE

802.16 Working Group. Nueva York. 2004. 893p. [2] E. Crozier y A. Klein. WiMAX’s

technology for LOS and NLOS environments. WiMAX Forum.

Mountain View. 2003. 10p [3] A. Aguiar y J. Gross. Wireless channels models. Technical University Berlin. Berlín. Telecommunications Networks Group. 2003. 54p. [4] S. Saun ders . Antenas and

propagation for wireless communication systems. Londres.

John Wiley & Sons. 1999. [5] T. Rappaport. Wireless com-

munications: Principles and practice. Indianapolis. Prentice

Hall. 2002. 736p. [6] P. Smulders, et al.

State of the art channel modeling . Broad-

band Radio@Hand. 2002. 45p. SISTEMAS & TELEMÁTICA

31

[7] T.K Sarkar,

et al. A survey of various propagation models for mobile communications. IEEE

Antenas and Propagation Magazine, Vol.45, No.3, junio de 2003. Nueva York. P51-82. [8] IEEE 802.16.3c00/47. Channel

Models for Broadband Fixed Wireless Systems. IEEE 802.16

Working Group. Nueva York. 2000. 7p. [9] IEEE 802.16.3c00/49r2. Interim Channel Models for G2 MMDS Fixed Wireless Applications .

[15] E. Grenier. Signal propagation modeling in urban environment.

ATDI. París. 2005. 18p. [16]

Radio propagation in ICS Telecom: Training resources. ATDI;

París. 2005. 66p. [17] M. C. Walden y F.J. Rowsell. Urban propagation measurements and statistical path loss model at 3,5GHz. IEEE AP-S International Symposium and USNC/URSI National Radio Science Meeting. Cambridge. 2005.

IEEE 802.16 Working Group. CURRÍCULOS Nueva York. 2000. 13p. [10] V.S. Abhayawardhana, et al. Alexánder Galvis Quintero {[email protected]} Comparison of empirical propaes ingeniero en Electrónica y gation path loss models for Fixed Telecomunicaciones de la UniWireless Access systems. BT Moversidad del Cauca (Popayán, bility Research Unit. Ipswich. 2005) y candidato a Magíster en 2004. 5p. Ingeniería con énfasis en Teleco[11] A. Galvis, C. Gómez, R. Hincapié municaciones en la Universidad y N. Bayona. Modelamiento de Pontificia Bolivariana. canales inalámbricos: Estado Actualmente se desempeña del arte, clasificación y simucomo investigador y docente lación. Memorias JIDTEL/5° en dicha institución, además Congreso Nacional ETI – TECde coordinar el Semillero de NOCOM2005. Medellín. 2005. Tecnologías Inalámbricas (STI). 10p. Temas de interés: Radiocomuni[12] H.R. Anderson. Fixed broadcaciones, modelamiento de caband wireless systems design. nales, Software Defined Radio, John Willey & Sons Ltd. Surrey. coexistencia e interoperabilidad 2003. 526p. inalámbrica, simulación. [13] ECC Report 33. The analysis of Cristina Gómez Santamaría the coexistence of FWA cells in {[email protected]} the 3,4 – 3,8 GHz band. ECC/ recibió sus títulos de Ingeniera CEPT. Cavtat. 2003. 72p. Electrónica y de Magíster en [14] A. Sarajedini, et al. Issues with the Ingeniería con énfasis en Telecointerim broadband fixed wireless municaciones de la Universidad channel model. IEEE 802.16 WG Pontificia Bolivariana (Medey BeamReach Networks. Mounllín, 2002 y 2005 respectivamentain View. 2001. 7p. te). Actualmente es candidata a

32


Doctora en Ingeniería en la misma institución, y su trabajo está relacionado con el modelamiento de canales espacio-temporales. Temas de interés: Radiocomunicaciones, modelamiento de canales, MIMO, WiMAX. Roberto Carlos Hincapié Reyes {[email protected]} recibió sus títulos de Ingeniero Electrónica y de Magíster en Ingeniería con énfasis en Telecomunicaciones de la Universidad

Pontificia Bolivariana (Medellín, 1996 y 2004 respectivamente). Actualmente es candidato a Doctor en Ingeniería en la misma institución, y su trabajo está relacionado con el modelamiento de capas superiores de sistemas inalámbricos. Temas de interés: Radiocomunicaciones, planificadores, QoS en sistemas inalámbricos, redes mesh y ad hoc, simulación, WiMAX.


33

34


Plataforma de acceso universal a mensajería instantánea móvil O. M. Caicedo*

Miembro del Grupo de Ingeniería Telemática (GIT), Universidad del Cauca

D. A. Caicedo*


E. Figueroa*


F. O. Martínez,*


J. A. Hurtado*

Miembro del Grupo de Ingeniería Telemática (GIT), Universidad del Cauca Fecha de recepción: 30-05-06



ABSTRACT

KEYWORDS

One of the most succesful services is Instant Messaging (IM), due to the versatility and simplicity offered to users. Because of the success of mobile telephony, new horizons have been developed for IM. However, the diversity existing in protocols and transport technologies have lead the technology to a low interoperability environment. This papers describes a platform called PAUMIM , because its spelling in Spanish, proposed by our research group, that allows the communication between different providers of IM services using mobile devices.

Interoperability, Instant Messaging, Mobility, Jabber, Transport

*

RESUMEN

En la actualidad uno de los servicios más exitosos es la mensajería instantánea, gracias a la versatilidad y simplicidad de comunicación que ofrece a los usuarios, una característica clave en el exigente entorno de conectividad y movilidad que demanda la sociedad. Con el éxito de la telefonía móvil, nuevos horizontes hicieron su aparición para este tipo de servicios; sin embargo, la diversidad de protocolos y tecnologías de transporte también se hizo más diversa y

O. M. Caicedo, E. Figueroa, D. A. Caicedo, F. O. Martínez y J. A. Hurtado son miembros del grupo de interés en Desarrollo de Aplicaciones Móviles e Inalámbricas W@PColombia perteneciente al Grupo de Ingeniería Telemática (GIT), Universidad del Cauca, Calle 5 No. 4-70 Popayán, Colombia. (e-mail: {omcaicedo, dacaicedo, efigueroa, fomarti, javhur}@unicauca.edu.co).


35

dio origen a un ambiente de baja y compleja interoperabilidad. El presente artículo describe la plataforma PAUMIM (Plataforma de Acceso Universal a Mensajería Instantánea Móvil), propuesta por el grupo de interés en Desarrollo de Aplicaciones Inalámbricas Móviles e Inalámbricas (W@PColombia) del Grupo de Ingeniería Telemática

36


(GIT) de la Universidad del Cauca, para la comunicación entre distintos proveedores de este servicio, a través del uso de dispositivos móviles. PALABRAS CLAVE

Interoperabilidad, Mensajería Instantánea, Movilidad, Transportes, Jabber. Clasificación Colciencias: A

I. INTRODUCCIÓN

instantánea y proveer movilidad a los usuarios del servicio. El grupo de interés en el desarrollo de aplicaciones móviles e inalámbricas w@pcolombia del Grupo de Ingeniería Telemática (GIT) plantea la creación de una plataforma de acceso universal a mensajería instantánea móvil (PAUMIM), que será descrita de la siguiente forma: en la sección II se presentan los conceptos asociados a la mensajería instantánea tanto fija como móvil; en la sección III se describe con más detalle el protocolo de mensajería instantánea Jabber, como núcleo de la plataforma construida; en la sección IV se describe la plataforma en sí; en la sección V, el entorno de experimentación y pruebas; y finalmente en la sección VI se presentan las conclusiones del trabajo realizado.

En la actualidad el continuo crecimiento de internet brinda a los usuarios nuevos servicios soportados sobre tecnologías de banda ancha, los cuales les ofrecen alternativas para agilizar su trabajo, incursionar en el mundo de la información y el entretenimiento. Para llevar a cabo comunicaciones simples y de forma inmediata, uno de los servicios más utilizados es el de Mensajería Instantánea caracterizado por su amplia acogida y rápida expansión alrededor del mundo. Las ventajas del servicio de mensajería instantánea se pueden evidenciar en el entorno empresarial y en el sector del entretenimiento. Dentro de una empresa es vital contar con herramientas que permitan una comunicación interactiva entre los trabajadores, y compartir recursos y conocimientos, como una alternativa a los servicios de comunicación actua- II. MENSAJERÍA INSTANTÁNEA les como la telefonía fija o móvil. En A. Definición el campo del entretenimiento, en los El término mensajería instantánea últimos años el uso de este servicio ha hace referencia en internet a la posicobrado mucha importancia y ofrece bilidad de establecer conversaciones a los usuarios un medio inmediato de texto en directo entre individuos para comunicarse con la familia, [3]. Pero a diferencia de los chat, esta compañeros y amigos [1]. comunicación no se establece en una El principal problema que presenta sala en la que hay más personas, sino la mensajería instantánea móvil de forma exclusiva entre los dos indiy fija es la coexistencia de varias viduos involucrados, por lo tanto se redes [2], cada una de ellas con considera como un punto intermedio aplicaciones y protocolos distintos entre los sistemas de chat y los menque dificultan la interoperabilidad sajes de correo electrónico. entre los diferentes proveedores, Las herramientas de mensajería imposibilitando una verdadera co- instantánea son programas regularmunicación universal entre los usua- mente gratuitos y versátiles, de fácil rios a cualquier hora y lugar. Surge instalación y uso, que requieren una entonces la necesidad de garantizar conexión a Internet para su activala interoperabilidad entre los dife- ción. Dichos programas permiten rentes proveedores de mensajería realizar conversaciones de texto, SISTEMAS & TELEMÁTICA

37

envío de archivos y videoconferencia entre otros servicios [3]. B. Proveedores de mensajería instantánea

La mensajería instantánea ha ganado popularidad en forma abrumadora. En los últimos años el número de usuarios de los distintos proveedores como AOL (American OnLine), Microsoft Messenger, Yahoo e ICQ (I Seek You), se ha incrementado en forma sustancial y ha alcanzado casi el número total de usuarios de Internet [4]. A continuación se identifican las herramientas de mensajería instantánea más importantes. ICQ : Fue el primer sistema de mensajería instantánea que salió al mercado y proporcionó una nueva alternativa a los sistemas de chat convencionales, lográndolo con éxito [3]. La última versión disponible, además de funciones como ICQPhone que incorpora telefonía IP para hacer llamadas entre computadores o de estos a teléfonos convencionales, tecnología SMS (Short Message Service) [5], integración con Outlook y más, ofrece una nueva colección de iconos (emoticons), que facilitan el envío de mensajes y las intenciones de comunicación. MSN Messenger: Pertenece a Microsoft Networks, es un sistema eficiente cuya principal ventaja, además de su sencillez de uso, es su integración con Hotmail y MSN, la red de contenido de Microsoft, con la estrategia. Net. [3]. El servicio de mensajería de Microsoft ofrece chat, video llamadas, conferencia, transferencia de archivos, iconos gestuales, pizarra, envío de mensajes SMS, entre otras funcionalidades.

38


Yahoo Messenger:

Es una de las alternativas de mensajería instantánea más fresca, y mejor integrada con la plataforma de servicios de la marca (Yahoo!) como el correo electrónico y geocities, de manera que su uso resulta transparente [3]. AIM (American-On-Line Instant Messenger): Sus prestaciones avanzadas

incluyen la comunicación entre computadores o de computadores a teléfonos convencionales; para hacerlo requiere un proveedor que soporte el servicio. También permite configurar alertas para correo electrónico y leer los mensajes de cualquiera de sus cuentas [3]. C. Protocolos abiertos de mensajería instantánea

Dentro de las iniciativas más importantes que se han propuesto para la normalización y estandarización del servicio de mensajería instantánea figuran los protocolos de la IETF SIMPLE (SIP for Instant Messaging and Presence Leverage) [6]-[7] y Jabber/XMPP (Extensible Messaging and Presence Protocol) [8]-[9] basado en XML. SIMPLE : Es un protocolo que permite el intercambio de mensajes y manejo de presencia [6]. Está basado en el protocolo SIP [10], es utilizado para establecer, administrar y finalizar sesiones con el objetivo principal de ayudar a los usuarios a enviar invitaciones hacia los posibles participantes de una sesión, dondequiera que se encuentren. Estas sesiones permiten establecer comunicación entre los usuarios para poder intercambiar distintas clases de información como voz, video, mensajes y datos.

Jabber: Es un conjunto de protocolos

hacer desde una cuenta del servidor Mobber [19].

XML de flujos de descarga (Streaming) y tecnologías que permiten que dos entidades en internet inter- III. JABER cambien mensajes, información de Jabber es un conjunto de protocolos presencia, y otra información estruc- de libre distribución, cuenta con una turada en tiempos cercanos al real comunidad de desarrollo muy grande [11]. Jabber se encuentra soportado y dentro de sus principios fundamenen miles de servidores de internet y tales está la interoperabilidad con es usado por más de seis millones de otros sistemas de mensajería[14], personas en todo el mundo; a pesar de razón por la cual ha sido elegido como esto, se encuentra menos difundido el stack de protocolos para la plataforque muchos sistemas propietarios. ma PAUMIM. Entre sus características más importantes, Jabber cuenta D. Mensajería móvil con un stack de protocolos basado JIMM : Jimm es un clon ICQ para en XML, lo cual hace posible su indispositivos móviles, específicamen- terpretación por diferentes sistemas te para teléfonos celulares, basado en Java 2 Micro Edition [12]. Jimm operativos y plataformas, no es cenno representa ningún producto de tralizado y es altamente extensible a ICQ, inc. La distribución de Jimm es través de la adición de componentes. pública con la licencia GNU General Por otro lado, Jabber brinda soporte SSL (Secure Socket Layer) para coPublic License (GPL) [15]. municaciones cliente/servidor y para JXME – JXTA for J2ME : El proyecto algunos clientes soporta la extensión JXTA es una plataforma abierta de GPG (GNU Privacy Guard) para programación para servicios y aplica- firmar información de presencia y ciones P2P (Peer to peer). El propósito cifrar las comunicaciones punto a del proyecto JXTA para J2ME es punto usando modelo asimétrico [20]. proveer funcionalidades compatibles A continuación se realiza una breve JXTA usando dispositivos que sopor- descripción del stack de protocolos ten Java [16]-[17]-[18]. de Jabber. Mobber: Es un sistema de mensajería A. Protocolo de mensajería instantánea propietario basado en el protocolo Jabber, orientado al acceso El protocolo de gestión de mensajes desde dispositivos móviles. En la ac- Jabber es simple pero poderoso. Por tualidad se encuentra en desarrollo, defecto, no se recibe confirmación no hay versiones con funcionalidad sobre la llegada de un mensaje a su estable y la documentación es muy destino para reducir el tráfico en el escasa. El sistema Mobber está com- servidor; por otro lado, si el receptor puesto por un servidor propietario y no se encuentra disponible el servidor una aplicación J2ME de libre distri- guardará el mensaje hasta que éste bución para el cliente móvil, desde se conecte [9]. la cual se puede establecer comunicación con contactos de diferentes B. Protocolo de presencia proveedores de mensajería, con la Una de las grandes diferencias que restricción de que el acceso se debe existen entre la mensajería instanSISTEMAS & TELEMÁTICA

39

tánea y el correo electrónico es que servidor. La mayoría de las peticiones los usuarios tienen la posibilidad IQ son entre un cliente y un servidor. de conocer el estado de otros usua- Sin embargo, hay algunos protocolos rios. Jabber ofrece la posibilidad de de IQ que van estrictamente de un establecer tantos estados diferentes cliente a otro, como el protocolo de como el usuario desee. Una de las petición de versión del cliente, en el prioridades más altas tenidas en cual un cliente le pide a otro su vercuenta en el protocolo Jabber 3 es sión del programa [11]. la intimidad de los usuarios. Por lo E. Protocolo de registro tanto, si un usuario quiere agregar a otro en su lista de contactos y recibir El primer paso para albergar usuarios su información de presencia, deberá en el servidor Jabber es la creación hacer una petición al servidor, y si de cuentas mediante una extensión el otro usuario acepta, entonces se del protocolo IQ. En los servidores públicos, y en su más pura esencia, podrá ver su estado [21]. las cuentas de usuario no son más que C. Protocolo de grupo de chat unos repositorios de credenciales que Gestiona la comunicación entre usua- los clientes usan para autenticarse rios de un grupo de chat [11]. Existen con el servidor. Además de estos cuatro acciones fundamentales: datos básicos, muchos servidores asocian otros a la cuenta de usuario. Unirse al grupo: Enviando un mensaje de presencia de tipo “disponible Aunque el manejo y almacenamiento (available)” al grupo. de las cuentas de usuario puede ser algo complicado, la implementación Enviar mensajes a todo el grupo: Enviando un mensaje al grupo deseado, del protocolo de registro no lo es. El al cual previamente el usuario ha protocolo de registro normalmente suele ser junto con el de autenticación debido unirse. el único protocolo que un usuario sin Enviar mensajes a un único miembro autenticar puede usar de un servidor del grupo: Enviando un mensaje a Jabber [11]. una persona específica del grupo. F. Protocolo de autenticación Abandonar el grupo: Enviando un mensaje “no disponible (unavailable)” El protocolo de autenticación de Jabber, al igual que el de registro, es una de presencia al grupo. extensión del protocolo IQ. Es uno de D. Protocolo de información-solicitud los protocolos dedicados únicamente (IQ- Inf o- Query) a la seguridad en Jabber basado en Es un protocolo sencillo y extensible SASL (Simple Authentication and Sede petición/respuesta que permite a curity Layer). Este protocolo permite los usuarios hacer peticiones y alma- a un usuario demostrar al servidor cenar o cambiar datos. IQ es simple- que realmente es quien dice ser. mente el conductor de esas peticiones El sistema de autenticación y acceso y respuestas, y gestiona los datos que a un servidor es simple: los clientes son necesarios de acuerdo con las no autenticados tienen una serie de conveniencias particulares de cada permisos restringidos, y los clientes

40


autenticados tienen un completo de suscripción de presencia. Como su acceso al uso de todos los protocolos nombre lo indica, la suscripción de Jabber que estén implementados en presencia determina los suscriptores el servidor del dominio al que perte- que recibirán las actualizaciones de necen. El protocolo de autenticación presencia de cada usuario. ofrece cuatro niveles diferentes de Los suscriptores piden una suscripautenticación: ción a un usuario, y el usuario acepta Anonymous: Si el servidor admite o deniega dicha suscripción. Cada usuarios anónimos basta con el envío usuario se suscribe a los usuarios de la petición IQ sin ningún otro tipo que desea y puede aceptar que dichos de dato y el usuario puede validar una usuarios u otros se suscriban a los sesión con el servidor. cambios de su presencia. Para realizar esta tarea, Jabber ha definido Plain: Funciona enviando dentro del mensaje de autenticación la contrase- unas estructuras de datos estándar ña sin codificar en formato de texto. conocidas como Jabber Roster, que no son más que una lista de otros Digest: Mediante este tipo de autenusuarios identificados por su Jabber ticación el servidor envía un identifi- ID [11]. cador de sesión junto con la etiqueta de inicio de sesión. Para generar la H. Transportes entre Jabber y otros autenticación, el cliente concatena servidores de mensajería instantáel identificador de la sesión con la nea contraseña del usuario. La cadena Debido a que Jabber es un protocolo resultante es codificada usando el libre basado en el intercambio de algoritmo SHA-1 (Secure Hash Stan- paquetes en formato XML, los sistedard - 1). mas Jabber están concebidos como un sistema genérico de transporte Zero-knowledge: Es el formato más seguro y más complicado soportado de mensajería instantánea. Su dipor los protocolos Jabber. Este méto- seño simple ha sido explotado por do de autenticación es complejo y su servidores Jabber para conectarse adopción tanto en servidores como en con otros sistemas de mensajería clientes ralentiza el proceso de auten- instantánea como MSN Messenger y ticación. Este tipo de autenticación ya Yahoo! Messenger. no guarda la contraseña del usuario El servidor Jabber de referencia en el servidor. De hecho, la informa- jabberd utiliza módulos llamados ción que el servidor guarda son las transportes (transport) que proveen credenciales que sólo sirven para una un puente entre Jabber y los demás única autenticación del cliente. El sistemas de Mensajería Instantánea. servidor irá creando nuevas creden- Los transportes tratan a cada sistema ciales de único uso [11]. de mensajería instantánea propietario como un dominio Jabber con sus G. Protocolo Roster propios clientes identificándolos por Para no enviar los cambios de pre- su “Jabber ID”. Al enviar un mensencia entre todos los usuarios del saje Jabber a uno de esos módulos, sistema, Jabber ha creado el concepto los Jabber IDs especiales hacen que


41

sean transportados por el módulo de IV. PLATAFORMA DE ACCESO transporte. Los módulos de transpor- UNIVERSAL A MENSAJERÍA te conectan con el sistema de mensa- INSTANTÁNEA MÓVIL jería 4 instantánea correspondiente y PAUMIM actúan como clientes de ese servidor A. Arquitectura para intercambiar mensajes y presencia entre los dos sistemas. Cada La Figura 1 ilustra la arquitectura de transporte debe hacer la traducción la Plataforma de Acceso Universal a de los mensajes Jabber al formato Mensajería Instantánea Móvil, PAUrespectivo del sistema de mensajería MIM, la cual consta de los siguientes módulos: instantánea correspondiente [11].

Figura 1. Arquitectura de la plataforma PAUMIM.

Permite realizar la administración y mantenimiento de la plataforma PAUMIM mediante acceso Web. Entre las funcionalidades que brinda se encuentra la capacidad de gestionar usuarios mediante su adición, edición y eliminación de la plataforma, y el establecimiento de comunicación directa entre el administrador de la plataforma y el usuario por medio de Módulo administrativo:

42


mensajes. El administrador tiene a su disposición información estadística con respecto al uso de la plataforma a través de gráficos que le permiten visualizar el número de usuarios conectados, tráfico cursado e información de tarificación. Módulo de conexión móvil: Permite a los clientes móviles acceder a los servicios de mensajería instantánea que ofrece PAUMIM. Este módulo

es el encargado de gestionar las conexiones y manejar la sesión de los clientes soportados (Clientes J2ME MIDP1.0 y MIDP2.0) [12]. Para realizar la gestión de conexiones, este módulo cuenta con dos submódulos. El primero se encarga de administrar las conexiones de los clientes MIDP1.0 a través de un componente de actualización de mensajes HTTP que mantiene en cola los mensajes de intercambio entre el servidor y los clientes, los cuales se encuentran en un proceso continuo de sondeo para actualizar su estado. El segundo se encarga de administrar las conexiones de los clientes MIDP2.0, recibiendo peticiones de conexión y realizando la asignación de las mismas a través de sockets TCP. Módulo de interoperabilidad: Es el encargado de llevar a cabo la implementación del protocolo de mensajería instantánea Jabber. Entre sus funciones más importantes se encuentran el registro de usuarios, la gestión de información de presencia, mensajería y contactos de los usuarios, y garantiza la interoperabilidad con proveedores de mensajería externos. Cuenta con dos submódulos descritos a continuación: Servicios Jabber : Encargado de prestar los servicios definidos por el protocolo Jabber, entre ellos la conexión, envío de mensajes y manejo de presencia. Se comunica con el módulo de control central para efectos de notificación, transporte de mensajes y presencia, y con el módulo transporte para establecer comunicación con los sistemas de mensajería instantánea MSN, AOL e ICQ. Módulo de transportes: Es una extensión del módulo de servicios Ja-

bber, la cual permite establecer una comunicación con otras redes IM. Este módulo desempeña el papel de representación de los clientes móviles ante los servidores de mensajería instantánea propietarios, con el fin de dar a la plataforma una de sus principales características, la interoperabilidad. Módulo de control central: Se encarga de coordinar toda la funcionalidad de la plataforma. Se compone de tres submódulos: Control: Encargado de implementar la lógica del negocio del sistema y llevar a cabo la coordinación de mensajes entre los módulos restantes. Tarificación: Lleva a cabo las tareas de registro de datos y generación de información de utilidad para la administración de la plataforma. La primera tarea consiste en registrar el uso de la plataforma por parte de los usuarios, en donde se tiene en cuenta el tráfico cursado y las horas pico de uso. La segunda es registrar el consumo por parte de los usuarios en donde se tiene en cuenta el número de sesiones iniciadas, mensajes enviados, mensajes recibidos y sesiones de chat establecidas. Gestión de usuarios: Encargado de gestionar la información de los usuarios. Provee las funcionalidades de registro, eliminación, edición y búsqueda de usuarios. Cliente móvil (CUMI): Es una aplicación J2ME que se ejecuta en el dispositivo móvil, la cual constituye la interfaz entre el usuario y el sistema. A través de un módulo de almacenamiento persistente, se guardan preferencias y datos del usuario. Para establecer la comunicación, el usuario SISTEMAS & TELEMÁTICA

43

no necesita crear una nueva cuenta quetes que contienen las clases que en el servidor PAUMIM, ya que pue- fueron implementadas por completo de iniciar una sesión a través de la durante el desarrollo de este proyeccuenta de su proveedor de mensajería to. La segunda corresponde a API tradicional. Existen dos versiones de (Application Program Interface) de CUMI , una para dispositivos móviles terceros adicionadas como librerías, de gama media (teléfonos celulares y y en la tercera se encuentran los paPDAs Palm, basado en la implemen- quetes que corresponden a módulos tación MIDP 1.0 [13]) y otra para dis- funcionales de la plataforma exterpositivos móviles de gama media-alta nos al ambiente de desarrollo Java (teléfonos celulares y smartphones, que fueron utilizados directamente basado en la implementación MIDP o con pequeñas adaptaciones. En 2.0 [13]). contravía, el diagrama de paquetes del cliente móvil muestra una arquiB. Diseño tectura mucho más simple. Las Figuras 2 y 3 muestran el diseño de la arquitectura del sistema. El A continuación se realiza una breve diagrama de paquetes del servidor descripción de cada uno de los pamuestra una arquitectura en tres quetes: capas. En la primera están los pa- Servidor PAUMIM python: Lenguaje interpretado utilizado para el desarrollo del módulo de transportes [22].

Figura 3. Diagrama de paquetes del cliente móvil PAUMIM .

pyOpenSSL:

Figura 2. Diagrama de paquetes del servidor PAUMIM.

44


Provee extensiones a Python para crear conexiones seguras. Conforma una capa de alto nivel alrededor de una configuración de la librería OpenSSL de Python [23]. pyCripto: Provee herramientas de cifrado de información a Python [24]. twisted: Es un framework de código abierto implementado en Python especializado para el desarrollo de aplicaciones basadas en red. Sirve de soporte al paquete python para establecer y administrar conexiones de red [25].

ejabberd:

Es un servidor Jabber multiplataforma. Desarrollado en el lenguaje Erlang, cuenta con un soporte total de las características del protocolo Jabber [26]. erlang : Lenguaje funcional utilizado especialmente para desarrollo de aplicaciones distribuidas. Tiene soporte para concurrencia, distribución y tolerancia de fallos. Utilizado para el desarrollo del servidor Ejabberd [27]. pyMSNt: Es un transporte desarrollado en Python. Provee una pasarela con la cual el servidor puede comunicarse con la red de MSN Messenger [28]. pyAOLt: Es un transporte desarrollado en Python. Provee una pasarela con la cual el servidor puede comunicarse con la red de AOL. El transporte debe estar instalado en el servidor Jabber, y su operación es transparente para el usuario [29]. pyICQt: Es un transporte desarrollado en Python. Provee una pasarela con la cual el servidor puede comunicarse con la red de ICQ Messenger. El transporte debe estar instalado en el servidor Jabber, y su operación es transparente para el usuario [30]. smack [31] : Es una API de código abierto para construir clientes de mensajería instantánea en Java. Puede ser embebida en aplicaciones para crear componentes de presencia y mensajería instantánea basados en el protocolo Jabber. De esta forma se logra la comunicación entre los paquetes implementados en Phyton y los creados en Java. postgreSQL: Este conjunto de librerías permite a los programas Java conectarse al motor de base de datos PostgreSQL [32].

view: En este paquete se encuentran

las páginas JSP, a través de las cuales se lleva a cabo la comunicación entre la plataforma y el administrador. Por medio de ellas, el administrador puede observar las variables de estado de la plataforma y así realizar funciones de administración. Todas las páginas JSP se comunican con el paquete de control. control: Contiene las clases que gestionan la lógica de la aplicación y la coordinación de la comunicación entre módulos y entre la plataforma y el administrador. components: Tiene inmersas las clases Java propietarias que implementan todas las funcionalidades de la plataforma. Cada una de ellas representa un componente encargado de llevar a cabo una funcionalidad específica. En este paquete se cuenta con componentes que llevan a cabo tareas de tarificación, gestión de usuarios, funcionalidades de administración y manejo de mensajería y presencia de usuarios. communication: Contiene las clases involucradas en la creación de un servicio que escucha peticiones concurrentes provenientes de clientes móviles, las cuales pueden utilizar HTTP (para clientes MIDP1.0) o Sockets TCP (para clientes MIDP2.0). Cliente Móvil PAUMIM view:

Contiene las clases necesarias para llevar a cabo la comunicación directa entre el sistema y el usuario a través de interfaces gráficas. control: Agrupa las clases que sirven para gestionar la lógica de la aplicación y la coordinación de la comunicación entre ésta, el usuario y el


45

servidor. Además, la clase principal El usuario puede iniciar una sesión de este paquete permite manejar el de mensajería instantánea móvil en ciclo de vida de la aplicación. cualquier terminal que cuente con el cliente móvil (CUMI) instalado communication: Contiene las clases involucradas en la comunicación mediante el uso de su login y conentre el cliente móvil y el servidor traseña. PAUMIM. Para establecer dicha co- Cuando el usuario inicia una sesión, municación se utilizan clases propie- el servidor de mensajería instantátarias para el establecimiento y man- nea se encarga de enviar al móvil tenimiento de la conexión y las clases toda la información pertinente entre definidas en JXME (JXTA for J2ME) la cual se tiene la lista de contactos, para la codificación y decodificación estado de los contactos y mensajes de de los mensajes de comunicación. entrada. De igual forma, el servidor se encarga de recibir los mensajes C. Funcionamiento de los móviles y encaminarlos ha A continuación se describe cada uno cia sus contactos si pertenecen al de los pasos involucrados en el uso de mismo sistema o a los proveedores la plataforma PAUMIM: propietarios a través del módulo de Inicialmente se descarga el cliente interoperabilidad. móvil (CUMI) al dispositivo, por meCuando el usuario realice la desdio de la interfaz OTA (Over The Air), conexión, PAUMIM se encarga de o a través de los diferentes medios de notificar a todos sus contactos y a los comunicación disponibles como cable servidores propietarios de mensajería de interfaz serial, USB, Bluetooth o instantánea del cambio de estado a IrDA. desconectado. Además, almacena toLa primera vez que el usuario inicia dos los mensajes que los contactos le la aplicación debe configurar su login envíen hasta que se puedan entregar y contraseña de ingreso, definida en el próximo inicio de sesión. para PAUMIM o para alguno de los sistemas propietarios de mensajería V. ENTORNO DE instantánea en los que tiene cuenta, EXPERIMENTACIÓN y establecer las direcciones de los La Figura 4 muestra el entorno de contactos con los que va a establecer experimentación utilizado para la la comunicación (opcional). Toda esta realización de las pruebas de PAUinformación es enviada al servidor MIM sobre ambientes inalámbricos. de mensajería instantánea que es el A. Cliente Móvil encargado de almacenarla. Una vez el servidor reciba la infor- En el cliente móvil se realizaron tres mación de los usuarios móviles se tipos de pruebas: encarga de establecer la comunica- La primera, en emuladores de Nokia, ción con los proveedores de servicio Sony Ericsson y el Wireless Toolkit de mensajería propietarios, para de Sun, cada uno equipado con hesolicitar el registro de los contactos y rramientas que permiten observar el la validación del usuario en ellos. consumo de memoria de la aplicación

46


Figura 4. Entorno de experimentación PAUMIM.

y la cantidad de datos enviados y recibidos por la red. La segunda, en una WLAN (Wireless Local Area Network), se utilizó un punto de acceso inalámbrico y PDAs Palm Drive y Tungsten T5. La tercera, a través de la infraestructura de datos GPRS de la red celular, instalando la aplicación servidora en una máquina con IP real y el acceso a través de teléfonos celulares Sony Ericsson T610 para el cliente MIDP 1.0 y Nokia 6230 para el cliente MIDP 2.0.

de la aplicación y actualización de presencia en cuatro ocasiones para los dos tipos de clientes. El principio de funcionamiento de los clientes MIDP 1.0 y 2.0 es distinto. Para los dos clientes hay un periodo de transición en el cual el dispositivo carga en memoria la aplicación y comienza el periodo de conexión y validación de sesión.

Consumo de memoria

A continuación se muestra el rendimiento experimental observado para los clientes MIDP 1.0 y 2.0. Figuras 5 y 6 presentan datos de consumo de memoria de la aplicación en tiempo de ejecución para las funcionalidades más relevantes. Las Figuras 7 y 8 muestran el consumo de memoria en el inicio de sesión

Figura 5. Consumo de memoria para el cliente MIDP 1.0.


47

35,121

20,596 22,312 23,461

Figura 6. Consumo de memoria para el cliente MIDP 2.0 .

Figura 7. Consumo de memoria para el inicio de sesión y actualización de presencia (cliente MIDP 1.0).

Figura 8. Consumo de memoria para el inicio de sesión y actualización de presencia (cliente MIDP 2.0).

Una vez finalizada esta primera parte, el consumo de memoria toma cierta estabilidad dependiendo del tipo de cliente. En el cliente móvil MIDP1.0 se genera periódicamente un mensaje de sondeo y se envía al servidor, en este momento se crean objetos y se hace uso de la red, por esta razón la gráfica muestra un comportamiento de diente de sierra ya que después de consumir recursos y enviar el mensaje al servidor, se limpia la memoria a través del recolector de basura (garbage collector). Para el cliente móvil MIDP 2.0 la gráfica de consumo de memoria es mucho más

48


estable debido a que la comunicación con el servidor se realiza mediante un socket TCP y no hay que crear objetos ni hacer uso de la red para conservar la conexión. En general el consumo de memoria para las dos aplicaciones es similar, teniendo mayor estabilidad y menor consumo el cliente MIDP2.0 por el principio de funcionamiento. Tiempo de respuesta

En las Figuras 9 y 10 se puede apreciar el tiempo de respuesta promedio de las aplicaciones para las funcionalidades más importantes en entorno de emulación.

Figura 9. Tiempo de respuesta para el cliente MIDP 1.0. B

1000

852

800 600 A 225

400 200 0

Tiempo de respuesta (ms) (A) (B)

Inicio de la aplicación Inicio de sesión

Figura 10. Tiempo de respuesta para el cliente MIDP 2.0.

El inicio de sesión consta del ensamble del mensaje con los datos de sesión para su envío al servidor, recepción de respuesta y actualización de la interfaz gráfica. El comienzo de la aplicación es más rápido para el cliente MIDP1.0 pero su tiempo de respuesta al principio de sesión es mucho más lento que para el cliente MIDP2.0. Lo anterior se debe a que el principio de funcionamiento para la recepción de conexiones por parte para los dos clientes es distinto. Para el cliente MIDP1.0 el servidor tiene que recibir y tratar información transportada en el protocolo HTTP, para lo cual debe empaquetar y desempaquetar la información según el stack de protocolos HTTP. Además de esto, el usuario debe descargar un

mensaje por petición, lo cual incrementa el tiempo de respuesta de la aplicación. Para el cliente MIDP2.0 el servidor recibe la conexión TCP/IP y trata la información directamente sin necesidad de realizar empaquetamiento y los mensajes se envían a medida que se vayan creando, por lo tanto no hay cola de espera y el tiempo de retardo presente es únicamente el de transporte por la red. Tamaño de los mensajes

La Figura 11 muestra el tamaño de los mensajes para cada una de las funcionalidades del cliente móvil. La diferencia entre el cliente MIDP1.0 y MIDP2.0 es que el primero debe realizar el sondeo al servidor y por esta razón consume más ancho de banda. 200

C

A 150

161 164

141 100

B

50

D E 108

62

F

G

I

124

H 114

72

73

0 Tamaño del mensaje (bytes) (A) (B) (C) (D) (E) (F) (G) (H) (I)

Inicio de sesión Actualización de presencia Descarga de lista de contactos Inicio de sesión de Chat Inicio de mensaje de Chat Finalización sesión de Chat Adición de Contacto Eliminación de Contacto Cerrar sesión

Figura 11. Tamaño de mensajes para el cliente móvil (MIDP 1.0 y 2.0).

B. Módulo de conexión móvil Consumo de memoria y uso de CPU de servicios Jabber

El servidor Ejabberd 1.0 se instaló en el sistema operativo Linux distribuSISTEMAS & TELEMÁTICA

49

ción Debian. El número de usuarios disposición del cluster, de máquinas. que soporta concurrentemente depen- En este proyecto se configuró el servide de la configuración y del hardware dor Ejabberd para correr en una sola en el cual se está ejecutando. Con res- máquina, y se estableció el número pecto a la configuración, es necesario máximo de puertos en 1000. definir el número máximo de puertos A través de una prueba de estrés, en habilitados por Erlang y la cantidad la cual a partir de una aplicación de máxima de conexiones. escritorio se iniciaron sesiones anóLa eficiencia del servicio tiene una nimas en el servidor hasta que éste dependencia directa con el ambiente cerró la recepción de nuevas conexiode ejecución del servidor, si corre en nes, se determinó que con el entorno una sola máquina o en un cluster de ejecución utilizado el servidor puede máquinas. Para ambos casos la de aceptar entre 720 y 770 usuarios memoria RAM y la CPU son factores dependiendo de la actividad de cada determinantes en el rendimiento. una de las sesiones de usuario. Las Cuando el servidor es configurado Figuras 12 y 13 muestran el uso de para correr en un cluster de máqui- la CPU y el consumo de memoria resnas, el rendimiento del sistema de- pectivamente, en los tres intervalos pende, además de la configuración y en las cuales se ejecutó la prueba.

Figura 12. Uso de CPU para el servidor Ejabberd.

Figura 13. Consumo de memoria para el servidor Ejabberd.

El primero corresponde al arranque del servidor Ejabberd. El segundo a la prueba de estrés, y el tercero, al momento de cierre de las sesiones de usuario iniciadas. Se puede observar que el uso de la CPU es máximo cuando se inicia el servidor, en el registro de las cuentas y al cerrar el servidor. El consumo de memoria aumenta en la medida en que se empiezan sesiones anónimas hasta el punto en el cual el servidor ya no tiene memoria suficiente,

suspendiendo en ese momento la recepción de nuevas conexiones y dejando de incrementar el consumo de memoria RAM.

50


Submódulo de transportes

Cada uno de los transportes se encuentra en un estado de desarrollo diferente y no tienen todas las funcionalidades implementadas. Sin embargo, el desempeño de cada uno de los transportes fue satisfactorio ya que permitieron llevar a cabo exitosamente la interoperabilidad

con los proveedores de mensajería instantánea externos. En la Tabla I se pueden observar las funcionalidades disponibles actualmente para cada uno de los transportes: Tabla I. Funcionalidades disponibles de los transportes Jabber. Funcionalidad

Mensajería Presencia Grupos de chat Soporte para Vcard Presencia invisible Notificaciones de escritura Mensajes HTML

pyMSN pyICQ pyAIM

X

X

X

X

X

El principal inconveniente presente en la comunicación de PAUMIM con otros proveedores de mensajería instantánea radica en la modificación regular del protocolo de comunicación que éstos realizan con el objeto de obstaculizar la interoperabilidad con sus competidores. La consecuencia directa es que los desarrolladores deben recurrir a un recurso de ingeniería inversa de los módulos de transporte de cada servidor, para adaptarlos a los cambios, de modo tal que sigan funcionando correctamente. VI. PAUMIM VS SMS

de un SMS es de 146 pesos, mientras que el precio del Kb equivale a 3.73 pesos. Con base en estos datos se puede decir que en promedio un mensaje por medio de PAUMIM cuesta 2.23 pesos. Con lo anterior se concluye que el precio por envío de mensajes en la plataforma PAUMIM es mucho más bajo con relación a SMS. Además, para el caso del Cliente Móvil MIDP 2.0 el tráfico a cursar es reducido, lo que también contribuye a disminuir costos, haciendo el servicio más atractivo para el usuario final. Acceso al servicio : El servicio de mensajería corta es prácticamente un servicio universal, soportado por todos los teléfonos que se conectan a la red celular. Para que los 9 dispositivos móviles soporten el cliente PAUMIM deben tener soporte para aplicaciones Java MIDP 1.0 o 2.0 y acceso a la red de datos GPRS. Interoperabilidad: El objetivo principal de PAUMIM es brindar interoperabilidad entre múltiples proveedores de mensajería instantánea, mediante la adición de módulos funcionales a la plataforma. Por otro lado, para lograr interoperabilidad entre proveedores de servicio de SMS es necesario llegar a acuerdos comerciales de interconexión de redes. Dichos acuerdos son dependientes de las políticas de cada operador y de la regulación de cada país, y son determinantes en el momento del establecimiento de dichos acuerdos.

Para realizar la comparación entre PAUMIM y el Servicio de Mensajería Corta (SMS) [5] se van a abordar tres aspectos fundamentales: precio, acceso al servicio e interoperabilidad. Precio: En términos generales, los mensajes de texto a través de SMS VII. CONCLUSIONES tienen un precio (para el usuario fi- A pesar de que J2ME es una espenal) superior al kilobyte de descarga cificación, la implementación de la a través de GPRS. Tomando como re- máquina virtual para cada gama de ferencia los precios de un operador de dispositivos tiene algunas variaciotelefonía móvil en Colombia, el precio nes y por tanto los desarrolladores


51

de aplicaciones móviles basadas en Java Micro Edition deben tenerlas en cuenta. Por medio de la construcción de un protocolo liviano de bajo consumo de ancho de banda se llevó a cabo la comunicación entre el cliente móvil y el servidor PAUMIM de forma eficiente. El uso de protocolos universales como TCP/IP en las comunicaciones entre los dispositivos móviles y el servidor PAUMIM hace que se puedan implementar y soportar diferentes tipos de clientes Web y de escritorio, en una gran variedad de tecnologías de desarrollo como Java, PHP, Perl, Python,. Net, C#, VisualBasic, entre otras. El perfil MIDP1.0 es muy restringido en cuanto al soporte de comunicaciones, debido a que cuenta únicamente con conexiones HTTP, que al ser un protocolo sin estado, obliga a un sondeo permanente del servidor lo cual incrementa el consumo de ancho de banda, disminuye el rendimiento de la aplicación e incrementa los costos de utilización. El soporte de conexiones MIDP 2.0 es mucho más completo que su antecesor, lo cual permite implementar comunicaciones a bajo nivel por medio de sockets TCP mediante el establecimiento de un circuito lógico entre el cliente móvil y el servidor, reduciendo costos e incrementando en gran medida la eficiencia de la aplicación, a costa de un incremento en la complejidad para el desarrollador. En cuanto a servidores, Ejabberd ofrece un soporte completo para el protocolo Jabber, proporciona una configuración robusta y adaptable a los diferentes transportes de comuni-

52


cación como PyMSN, PyICQ y PyAOL, los cuales fueron seleccionados para el desarrollo del proyecto por sus características de libre distribución, alto rendimiento, alta adaptabilidad y fácil configuración. BIBLIOGRAFÍA

[1] N. Flynn, Instant Messaging Rules: A Business Guide to Managing Policies, Security, and Legal Issues for Safe IM Communication, 1era. ed. Broadway, New

York: Amacon, 2004, p. 28-36. [2] J. Sabaté. (2002, Oct.). Mensajería Instantánea. Del placer a los negocios. Revista Consumer EROSKI. [Online]. Disponible: http://revista.consumer.es/web/ es/20021001/internet/. [3] E. Lopez. Mensajería instantánea. PC Magazine. [Online]. Disponible: http://www.x-extrainternet.com/messengers.asp [4] E. Shiu y A. Lenhart. (2004, Sep). How Americans use instant messaging. Pew Internet and American Life Project, Washington, D.C. [Online].Disponible: http://www.pewinternet.org/ pdfs/PIP_Instantmessa ge_Report.pdf [5] O. M. Caicedo, F. O. Martínez, M. J. Gómez and J.A. Hurtado, “Architectures for Web Services Access from Mobile Devices,” in

Proc. 2005 3rd Latin American Web Congress La-Web 2005 , pp.

93-97 [6] SIMPLE Working Group. (2006, Ene.). SIP for Instant Messaging and Presence Leveraging Extensions. IETF. [Online]. Disponible: http://www.ietf.org/

html.charters/simple-charter. html [7] J. Alan, SIP: Understanding the Session Initiation Protocol , 2da. ed. Norwood, MA: Artech House, 2004, p. 17-42. [8] Extensible Messaging and Presence Protocol (XMPP): Core, IETF Standard RFC 3920, Oct. 2004. [9] Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence, IETF

Standard RFC 3921, Oct. 2004.

[10] Session Initiation Protocol (SIP) Extension for Instant Messaging , IETF Standard RFC 3428,

Dec. 2002. [11] O. Lage. (2005, Jun.).Jabber/ XMPP. Facultad de Ingeniería, Universidad de Deusto. [Online]. Available: http://www. jabberes.org/node/529. [12] J. Muchow, Core J2ME technology & MIDP , 1era. ed. San Antonio Road, California: Prentice Hall, 2001, p. 1-26 [13] O. M. Caicedo, F. O. Martínez, J. A. Hurtado y G. A. Ramírez, “Wireless Trace Service for Latin American Craft Sector”, in Proc. 2006 Wireless Telecommunications Symposium, a ser publicado. [14] M. Misek, “Jabber: Communicating in Real Time”. EContent Wilton, vol. 28, pp. 44-45, Feb. 2005. [15] Jimm.org. (2006, Mar.). Jimm Mobile Messaging. SourceForge.net. [Online]. Disponible: http://www.jimm.org/

[16] JXTA.org. (2005, Dec.). JXTA for J2ME (CLDC/MIDP). JXTA. org. [Online]. Disponible: http:// jxme.jxta.org/ [17] L. García, R. Camacho y F. O. Martínez, “Desarrollo de Aplicaciones P2P para Dispositivos Móviles haciendo uso de los Protocolos JXTA (JXTA + J2ME) – El Punto de Encuentro Virtual P2P”, presentado en las V Jornadas de Investigación y Desarrollo en Informática (JIDI) en el marco del evento TECNOCOM 2005, Medellín, Colombia, 2005. [18] W. Yeager, J. Williams, “Secure peer-to-peer networking: the JXTA example”. IT Professional, vol. 4, pp. 53-57, Abr. 2002. [19] Mobber Project. (2005, Jun.). Mobber- mobile jabber communicator. SourceForge.net. [Online]. Disponible: http://mobber. gryf.info/en/ [20] Asociación ADITEL. (2003, Sep.). Introducción a Jabber. Universitat Jaume I de Castellón, España. [Online]. Disponible: http://www.jabberes.org/introduccion [21] Instant Messaging / Presence Protocol Requirementse, IETF Standard RFC 2779, Feb. 2000 [22] A. Downey, J. Elkner y C. Meyers. (2002, Ene.4). How to Think Like a Computer Scientist Learning with Python. (1era ed.)

[Online]. Available: http://www. ibiblio.org/obp/thinkCSpy/ [23] pyOpenSSL Project. (2004, Ago.). Python interface to the OpenSSL library. SourceForge. SISTEMAS & TELEMÁTICA

53

net. [Online]. Disponible: http:// Postgresql.org. [Online]. http:// pyopenssl.sourceforge.net/ jdbc.postgresql.org/ [24] Pycripto. (2005, Dec.). Python Óscar Caicedo recibió el título Cryptography Toolkit. Sourcede Ingeniero Forge.net. [Online]. Disponible: en Electrónica http://www.amk.ca/python/code/ y Telecomunicrypto.html caciones de la Universidad del [25] I. Shtull-Trauring. An IntroCauca, Colomduction to the Twisted Netbia, en 2001. working Framework. Presented En la misma at O’Reilly Emerging Techinstitución renology Conference. [Online]. cibió el título de http:/ nlamp.com/pub/a/pyEspecialista en thon/2004/01/15/twisted_intro. Redes y Servicios Telemáticos, html en 2003. Actualmente realiza su [26] Ejabberd Web site. (2005, Dec.) tesis de Maestría en Ingeniería Ejabberd server. Ejabberd projcon Énfasis en Telemática en ect. [Online]. http://ejabberd. la Universidad del Cauca y se jabber.ru/ desempeña como docente del Departamento de Telemática de [27] Erlang Web site. (2006, Mar.). la Facultad de Ingeniería ElecErlang Open source. Erlang.org. trónica y Telecomunicaciones [Online]. http://www.erlang.org de la misma universidad. Como [28] PyMSNt Web site. (2006, Feb.). miembro del Grupo de IngeniePython based MSN Transport ría Telemática (GIT), su área de for Jabber. Jabberstudio..org. investigación se centra en la In[Online]. http://msntransport. geniería del software aplicada a jabberstudio.org la construcción de arquitecturas y plataformas para el desarrollo [29] PyAIM-t Web site. (2005, Dec.). y despliegue de aplicaciones so AIM transport for Jabber. Blathbre dispositivos móviles, redes ersource.org. [Online]. http:// inalámbricas y redes móviles pyaim-t.blathersource.org/ celulares. [30] PyICQ-t Web site. (2005, Dec.). ICQ transport for Jabber. Blath- Andrés Caicedo recibió el título de Ingeniero ersource.org. [Online]. http://pyen Electrónica icq-t.blathersource.org/ 10 y Telecomuni[31] Smack API Web site. (2006, caciones de la Mar.). Simple and Powerful Java Universidad client API for XMPP. Jivesoftdel Cauca, ware.org. [Online]. http://www. Colombia, en jivesoftware.org/smack 2006. Actualmente realiza [32] PostgreSQL Web site. (2006, su primer año Feb.). PostgreSQL JDBC Driver.

54


de estudios de Maestría en Ingeniería con Énfasis en Telemática en la Universidad del Cauca. Además, es miembro del grupo de interés en desarrollo de aplicaciones móviles e inalámbricas w@pcolombia y director de proyectos de tecnología Topp Allians S.A.; donde centra su investigación en el desarrollo de servicios y aplicaciones para dispositivos móviles, desarrollo de aplicaciones empresariales, redes inalámbricas de transmisión de datos, redes globales de información y redes móviles celulares de 2.5G y 3G. Edwin Figueroa recibió el título de Ingeniero en Electrónica y Telecomunicaciones de la Universidad del Cauca, Colombia, en 2006. Actualmente es miembro del grupo de interés de desarrollo de aplicaciones móviles e inalámbricas w@pcolombia, donde centra su investigación en el desarrollo de servicios y aplicaciones para dispositivos móviles, redes inalámbricas de transmisión de datos, redes globales de información y redes móviles celulares de 2.5G y 3G. Francisco Martínez recibió el título de Ingeniero en Electrónica y Telecomunicaciones de la Universidad del Cauca, Colombia, en 2003. Actualmente cursa tercer semestre de Maestría en Ingeniería con Énfasis en Telemática

en la Universidad del Cauca y se desempeña como docente del Departamento de Telemática de la Facultad de Ingeniería Electrónica y Telecomunicaciones de la misma universidad. Como miembro del Grupo de Ingeniería Telemática (GIT), su área de investigación se centra en la Ingeniería del Software aplicada a la construcción de arquitecturas y plataformas para el desarrollo y despliegue de aplicaciones sobre dispositivos móviles. Javier Hurtado recibió el título de Ingeniero en Electrónica y Telecomunicaciones de la Universidad del Cauca, Colombia, en 2001. En la misma institución, recibió el título de Especialista en Redes y Servicios Telemáticos, en 2004. Actualmente cursa tercer semestre de Maestría en Ingeniería con Énfasis en Telemática en la Universidad del Cauca y se desempeña como docente del Departamento de Telemática de la Facultad de Ingeniería Electrónica y Telecomunicaciones de la misma universidad. Como miembro del Grupo de Ingeniería Telemática (GIT), su área de investigación se centra en el estudio de los protocolos de señalización en SISTEMAS & TELEMÁTICA

55

redes de nueva generación y la construcción de arquitecturas y plataformas para el desarrollo

56


y despliegue de aplicaciones de nueva generación sobre dispositivos móviles.

Modelo de simulación de la capa MAC IEEE 802.16-2004 para modo Mesh Javier Emilio Sierra

GIDATI, Escuela de Ingeniería, Facultad de Informática y Telecomunicaciones Universidad Pontificia Bolivariana, Medellín, Colombia [email protected]

Roberto Hincapié


Roberto Bustamante (†)

Departamento de Ingeniería Eléctrica y Electrónica Universidad de los Andes, Bogotá, Colombia [email protected]

Leonardo Betancur





ABSTRACT

RESUMEN

IEEE 802.16-2004 standard supports mesh networks topology and its important to realize the performance of such systems. Simulation of communication systems allows its optimization in performance measures. In this article we present a model developed over Network Simulator 2 to simulate data link layer operation in mesh topologies based on that standard. We present the results based on a link scheduler and the model developed, as the mean queue length, mean queue delay and the system capacity for different topologies.

El estándar IEEE 802.16-2004 soporta la creación de redes mesh. La simulación de sistemas de comunicación permite su optimización, sobre todo para la mejora de los parámetros de desempeño. En este artículo se presenta un modelo desarrollado e implementado en NS2 para la simulación de la capa de enlace de datos para topologías mesh basadas en el estándar mencionado. Se muestran resultados obtenidos con un planificador de enlace, así como longitudes promedio de las colas, retardo en cola, capacidad del sistema para diferentes topologías.

KEY WORDS

MAC, Wimax, Mesh, simulation models

PALABRAS CLAVE

MAC, Wimax, Mesh, simulación Clasificación Colciencias: A


57

I. INTRODUCCIÓN

así como el diagrama de eventos; por último, en la sección V se muestran los resultados de las simulaciones realizadas para el planificador y el modelo desarrollado e implementado en NS2.

El estándar IEEE 802.16-2004 define la interfaz física y la capa MAC para el acceso a sistemas de banda ancha que emplean topología mesh. Las redes mesh en los últimos años han sido de gran estudio por su facilidad de despliegue como redes emergentes. II. BACKGROUND Es sin duda un área de investigación A. Trabajos relacionados en la cual hay mucho por realizar. Las redes inalámbricas mesh son un Network Simulator 2 (NS2) es una tipo de redes de comunicación espeherramienta de simulación en even- ciales orientadas a proveer acceso tos discretos, la cual permite el remoto a usuarios en lugares donde desarrollo de entidades que puedan una red común (celdas) no es óptima. representar de una manera correcta La característica de estos lugares es tecnologías inalámbricas; es útil para que son sitios remotos con baja densisimular la capa de enlace para topo- dad de usuarios y de difícil acceso con logías mesh que emplean el estándar una simple estación base. En [1], [2] y en mención. [3] los autores presentan un escenario En este artículo se muestra un mo- más realista donde las redes mesh delo desarrollado de la entidad co- están constituidas por alrededor de rrespondiente a las funcionalidades 30 nodos y son orientadas a proveer de la capa de enlace de datos para servicios de última milla a usuarios el análisis de sistemas de acceso de remotos. Ejemplos de estos escenabanda ancha en topología mesh basa- rios son las comunicaciones rurales dos en el estándar IEEE 802.16-2004; [4] e internet banda ancha de acceso con el fin de facilitar por medio de la residencial. simulación, el diseño y análisis de El análisis de capacidad para redes redes que emplean esta tecnología, mesh ad hoc inició con [5], quien premejor conocida como WiMax (World- sentó un modelo de capacidad basado wide Interoperability for Microwave en la teoría de la información. Chang Access). [6] realizó un análisis orientado a gaEl artículo se encuentra organizado rantizar retardos para las redes mesh de la siguiente manera: inicialmente sin considerar redes inalámbricas. En se realiza un background de los tra- [7] los autores presentan el concepto bajos relacionados con el tema y sobre de servicios diferenciados, represenel estándar IEEE 802.16. En la sec- tados por diferentes colas en un nodo ción III se indican las características transmisor, cada una con una clase de dadas por el estándar referente a las servicio determinada. topologías mesh y los planificadores. Otros trabajos relacionados son [8] En la sección IV se muestra el mode- y [9], los cuales analizan la calidad lo de capacidad equivalente para la de servicio (QoS) de los sistemas. capa PHY en condiciones ideales, el Estos artículos proponen un modelo modelo desarrollado e implementado, para arquitecturas punto-multipunto

58


(PMP) similar al modelo propuesto en 1998, sin embargo, la primera vereste artículo, basado en una entidad sión del estándar fue completada en MAC con varias colas para diferentes octubre de 2000 (IEEE 802.16-2001) tipos de flujo y un control de acceso al y publicada el 8 de abril de 2002. ´ medio. En [10] los autores presentan Este define la interfase física y la un análisis de PMP y topologías mesh capa de enlace MAC (Medium Access empleando simulación. [9] y [11] Control) para redes inalámbricas de realizan y muestran un análisis para área metropolitanas (WirelessMAN), planificadores de redes mesh. con la intención de proveer banda La mayoría de los trabajos relaciona- ancha inalámbrica para servicios de dos con el estándar IEEE 802.16-2004 voz y datos con usos residenciales y están enfocados a arquitecturas PMP; empresariales. La primera versión sin embargo, se encuentra [12], donde solo fue considerada para usuarios filos autores simulan topologías mesh jos [17]. El estándar fue diseñado con pero no mencionan la herramienta capa MAC que soportará diferentes usada ni especifican los detalles del interfases de aire, pero con capa física que depende del uso del espectro y de modelo de simulación. las regulaciones existentes. Se conEn la literatura se encuentran enti- centró en las bandas de frecuencias dades para redes mesh basadas en de 10 a 66 GHz. IEEE 802.11 en el DCF incluyendo capas superiores como enrutamiento, Un nuevo proyecto de reforma deTCP, UDP y aplicaciones. Algunas nominado IEEE 802.16a aprobado simulaciones consideran movilidad antes de finalizar el 2002 extendió mientras que otras no lo hacen. Estas el rango de trabajo a las bandas de entidades no se pueden adaptar al frecuencia de 2 a 11 GHz, incluyendo modelo que se plantea en este trabajo, de esta forma bandas licenciadas y ya que estas son ranuradas (slotted) y no licenciadas en las diferentes resincronizadas, mientras que en IEEE gulaciones. 802.11 el método de acceso al medio En junio de 2004 fue aprobado el eses basado en contención. tándar actual para redes WiMAX fijas Sobre el proceso de planificación, en conocido como 802.16-2004 [18]. Los [13] los autores presentan un análisis trabajos actuales sobre el estándar de planificación de paquetes orienta- están concentrados en darle soporte do a topologías PMP; [12] analiza un de movilidad (entre 70 y 80 mph) para planificador distribuido para redes el empleo de dispositivos como PDA, mesh del tipo WiMAX . De una mane- teléfonos o computadores portátiles. ra general, es analizado el comporta- Este grupo es conocido como IEEE miento de las redes mesh WiMAX en 802.16e y aprobó el estándar el 7 de [14] y [15][16] presentan el problema diciembre de 2005. de los planificadores de enlace TDMA Entre las características principales para redes inalámbricas ad hoc. del estándar IEEE 802.16-2004 se tienen: B. Estándar IEEE 802.16 Las actividades de trabajo sobre el • La capa MAC soporta arquitecturas punto multipunto con estándar IEEE 802.16 iniciaron en SISTEMAS & TELEMÁTICA

59

topología opcional de redes enmalladas. • La capa MAC está estructurada para soportar múltiples capas físicas (PHY). • Para frecuencias entre 10-66 GHz la capa PHY emplea modulación Single Carrier. • Debajo de los 11 GHz donde no es requerida línea de vista, puede ser empleado: OFDM, OFDMA o Single Carrier.

• El estándar consolida IEEE std 802.16-2001, IEEE std 802.16aTM-2003 e IEEE std 802.16cTM-2002. • El estándar especifica la interfase de aire para el acceso banda ancha a redes inalámbricas fijas soportando diferentes servicios multimedia. III. MESH IEEE 802.16-2004

A. Características del estándar Las redes mesh son aquellas en las que la comunicación se puede hacer entre los diferentes nodos y no sólo entre nodo y estación base. Para este tipo de redes se pueden realizar las operaciones de dos maneras diferentes: distribuida o centralizada. Para la distribuida, todos los nodos deben coordinar con el vecindario extendido la manera de transmitir para evitar colisiones con los datos y realizar el control de tráfico, y además deben enviar por difusión ( Broadcast) su respectivo estado (recursos disponibles, peticiones y concesiones) a todos sus vecinos. Para la centralizada, los recursos se asignan de una manera agrupada, donde la Mesh BS, recopila varias peticiones de un determinado

60


sector y otorga los respectivos recursos para cada enlace, al mismo tiempo que comunica estas decisiones a las demás estaciones del sector. En la topología Mesh cada nodo tiene 48 bit de dirección MAC, la cual es utilizada durante el ingreso a la red y como parte del proceso de autorización. Cuando se autoriza al nodo candidato, este recibe un identificador de 16 bits (Node ID), empleado para identificar al nodo durante la operación. El Node ID es utilizado en el Mesh Subheader (en unicast y broadcast).

En el estándar define mensajes de control para el modo Mesh [18]: MSH-NCFG message: provee un nivel básico de comunicación entre los nodos en diferentes redes del mismo o diferentes proveedores de equipos. Todos los nodos, ya sean BS o SS (subscriber) en la red mesh transmiten este mensaje. MSH-NENT message: provee características para que un nuevo nodo gane sincronización e inicie Network Entry en la red mesh. MSH-DSCH message: se emplea en modo distribuido en la red mesh y se transmite en un intervalo regular para informar a los vecinos del scheduler de la estación de transmisión. El tiempo de transmisión es determinado por el mismo algoritmo de MSH NCFG. MSH-CSCH message: es creado por un Mesh BS y se emplea en modo centralizado. La BS envía en broadcast el mensaje a todos los vecinos indicando el tiempo de transmisión. También los nodos pueden emplear este mensaje para realizar peticiones

de ancho de banda al Mesh BS. Cada nodo reporta cuánto es su demanda de tráfico al Mesh BS, para que éste realice las tareas de scheduler. MSH-CSCF message: al igual que el mensaje anterior, se envía en broadcast cuando se emplea modo centralizado y es empleado para realizar la configuración necesaria de los nodos Mesh. B. Planificadores definidos en el estándar

El scheduling centralizado asegura comunicaciones libres de colisiones y trabaja de la siguiente forma: el control lo realiza la Mesh BS por medio de mensajes del tipo MSH-CSCH y MSH-CSCF. Los primeros se encargan de la coordinación de las estaciones y el segundo de la configuración. Los nodos se agregan a un árbol de enrutamiento, en el cual la Mesh BS corresponde a la raíz y se organizan por medio de su distancia en saltos hasta la base. En las peticiones los nodos más lejanos transmiten primero en orden de aparición en este árbol. En las concesiones, se transmite en orden creciente de distancia al Mesh BS, pero dentro de cada nivel en el orden de aparición en el árbol de enrutamiento.

Como se ha mencionado el estándar define dos tipos de algoritmos de planificación para topología mesh: Planificación distribuida: todas las estaciones (BS y SS) coordinan sus transmisiones en su vecindario extendido (hasta dos saltos). Todas las estaciones en la red emplean el mismo IV. MODELO canal para transmitir la información A. Modelo capacidad para capa PHY de planificación en un formato especí- en condiciones ideales fico. Cuando existe una Mesh BS ésta actúa como responsable de enviar el Luego de realizar un estudio al estánNetwork Descriptor con la informa- dar, se encontró que los parámetros ción necesaria de la red. Los nodos principales de OFDM son: deben transmitir el MSH-DSCH de • Nfft: longitud de la transformada la misma forma como coordinan los de Fourier desarrollada en el promensajes MSH-NCFG. Los nodos ceso (Nfft = 256). establecen los requerimientos de BW de una forma directa entre dos nodos • BW : es el ancho de banda de la señal a utilizar. Este valor puede sin la participación de una BS. Las ir hasta alrededor de 20 MHz. Peticiones/Concesiones se transmiten a los vecinos para que todos conozcan η factor de muestreo. Es claro que el algoritmo de planificación y eviten no se puede analizar exactamente colisiones. Toda la asignación se reauna señal que va hasta BW /2 liza en unidades de minislots. por medio de una frecuencia de muestreo de BW , por lo cual, la Planificación Centralizada: las cofrecuencia de muestreo es igual a nexiones y la topología de red son las BW *η. mismas que en distribuido, pero el scheduler de transmisión es definido • Guard Time CP : se da como una por una estación BS. La BS deterfracción del tiempo útil del símbomina la asignación de recursos que lo. Puede tomar valores de 1/4, 1/8, depende de las solicitudes de las SS. 1/16 o 1/32 según el estándar. SISTEMAS & TELEMÁTICA

61

•

N p :

corresponde al número de portadoras de datos. Según los procesos de subcanalización de OFDM, se pueden tener múltiplos enteros de 12 portadoras entre 12 y 192 portadoras.

• Finalmente un aspecto que depende del esquema de modulación y de codificación de la señal es la cantidad de bits codificados CB (Coded bits) por símbolo QAM y la rata de codificación CR (Coding rate).

Tabla I. Número de símbolos OFDM por trama. BW

5.00E+06

1.50E+07

2.00E+07

Tsym (µs)

56

28

18.667

14

Ttr=2.5 ms

44.6

89.3

133.9

178.6

Ttr=2 ms

71.4

142.9

214.3

285.7

Ttr=5 ms

89.3

178.6

267.9

357.1

Ttr=8 ms

142.9

285.7

428.6

571.4

Ttr=10 ms

178.6

357.1

535.7

714.3

Ttr=12.5 ms

223.2

446.4

669.6

892.9

Ttr=20 ms

357.1

714.3

1071.4

1428.6

Con los valores anteriores se deduce la rata de transmisión (bits):

El parámetro anterior (Ec. 1) es la capacidad del canal sin tener en cuenta tramas, encabezados, etc. Son solamente a nivel de bits sobre el canal. Las tramas del estándar tienen una duración que oscila entre 2.5, 4, 5, 8, 10, 12.5 y 20 mseg; sin embargo, para configuraciones mesh el tiempo de trama dispuesto por el estándar es de 4 mseg. Dentro de esta trama se encuentra un número de símbolos OFDM: (2) Con Ttr: tiempo de trama.

62

1.00E+07


Existen ciertas limitaciones sobre la utilización de la trama por parte de los usuarios. En primer lugar, aparece el concepto de la trama de control, la cual tiene una duración en términos de símbolos OFDM, dada por 7 x MCL (longitud de la subtrama de control). El valor de este parámetro es de 4 bits, con lo que puede oscilar entre 0 y 15. El resto de los símbolos de la trama están ocupados con datos del usuario. Con base en los valores de parámetros de OFDM, se encuentran diferentes números de símbolos por trama. Se observa en la Tabla I que cuando la trama dura el mayor tiempo posible y se tiene el mayor ancho de banda (equivalente a la menor duración de símbolo), se logra la mayor cantidad de símbolos OFDM por trama. Todos los datos de la subtrama de control deben ser transmitidos en

QPSK1/2, los símbolos restantes se asignan en conjuntos de minislots a los usuarios. El campo de asignación de minislots se compone de 8 bits, y el valor máximo a asignar en posición y tamaño es 255. Por lo tanto, la parte de la trama restante se divide en minislots de tamaño dado por: (3) Todos los minislots de la trama tienen este tamaño, con la posible excepción del último. Cabe anotar que los campos de la subtrama de control no tienen todos su duración como carga útil, ellos tienen un preámbulo largo y unos símbolos de guarda posteriores, con lo cual su duración efectiva se hace más corta. Antes de los datos de control se ubica un Long Preamble equivalente a 2 símbolos OFDM.

En la gráfica Mesh frame structure del estándar [18](p.459), se interpreta que luego de la trama de MSH NET ENTRY, aparecen tres símbolos OFDM de guarda. Luego de las tramas de SCHEDULING y de MSH NCFG aparece un símbolo de guarda antes de comenzar la nueva trama. Con esto se reduce aún más el tamaño de la carga útil de estas tramas. En el caso de la subtrama de entrada a la red, se reduce a dos símbolos OFDM o a un total de 384 bits o de 48 bytes únicamente. El tamaño del minislot es un indicativo de la cantidad de información que se puede transmitir para un determinado usuario en función de símbolos OFDM, no de bits, pues en cada rango de minislots se pueden tener diferentes opciones de configuración de modulación y codificación. El número de minislots estaría dado por: (4)

La asignación se realiza por medio de minislots (MS), indicando el MS de inicio y la duración en unidades también de MS. Teniendo en cuenta que para un enlace determinado el canal estaría

asignado durante un rango rang o de MS, se puede encontrar finalmente la rata de transmisión asignada de manera equivalente al usuario:

(5) La cantidad anterior indica que la percepción del canal por parte del usuario depende del ancho de banda, del porcentaje del canal asignado, de las portadoras y del esquema de

modulación elegido. La rata de transmisión equivalente es inversamente proporcional a la longitud de guarda elegida para proteger contra multitrayectoria.


63

B.

Modelo capa MAC mesh IEEE 802.16

El modelo desarrollado fue implementado en el simulador de eventos discretos Network Simulator 2. El diagrama general del modelo se

muestra en la Figura 1, con las entidades que permiten la simulación de la capa MAC del estándar IEEE 802.16-2004 para topología mesh. Se observan las siguientes entidades:

Figura 1. Diagrama general.

1) Link Scheduling: Es una entidad codificada en C++ externa a la Capa MAC Mesh 802.16-2004 encargada de la asignación de los parámetros de planificación del sistema. Link Scheduling se comunica con el Controlador MAC para indicarle los tiempos de trama y los tiempos en que cada Planificador debe habilitar su respectiva cola. La entidad posee dos estructuras de apuntadores, una de Controladores MAC y otra de Planificadores. Además, carga los datos de asignación de ranuras y tráfico (en unidades de minislot) de archivos generados por el programa realizado en Matlab que se mencionará en IV-D. 2) Capa MAC Mesh 802.16-2004 : Es una entidad TCL que contiene otras entidades C++ para su funcionamiento como se observa en 1. El modelo planteado en este trabajo no

64


tiene en cuenta las capas superiores, por lo tanto las fuentes de tráfico se encuentran dentro de la MAC; el scheduling se realiza de manera global y es centralizado; el planificador de paquetes tiene disciplina de cola FIFO y todos los paquetes son del mismo tipo; no se realizan peticiones de scheduling a la MAC y no se realiza el procedimiento de entrada a la red. Las entidades C++ que contiene son las siguientes: • Control de flujo: está compuesto por dos entidades desarrolladas en C++: ColaMesh y Planificador de paquetes. En el Control de Flujo la ColaMesh es la encargada de empaquetar los paquetes con el tamaño indicado y modificar el Header OFDM (ver subsección B4) para la transmisión del nuevo paquete del tipo

mesh. Al conectarse ColaMesh con el Planificador, este último recibe el paquete, que a su vez lo envía por su puerto de salida. – ColaMesh es es la entidad encarencargada de encolar los paquetes hasta que el planificador le indique que desencole. ColaMesh es una entidad realizada en C++, la cual hereda las propiedades y métodos de la clase pública Queue. Posee los siguientes métodos nuevos: a) resumepaq (desencola un determinado número de paquetes, uno por uno sin empaquetamiento; b) resumepaquetes (desencola un determinado número de paquetes, los empaqueta dependiendo del tamaño solicitado y le agrega la cabecera OFDM al nuevo paquete para luego ser enviado al puerto de salida); c) inicializa ofdm (esta función inicializa los valores del Header OFDM que se describirán más adelante). Al emplear resumepaquetes se emplea una función packing para unir n paquetes en uno solo dependiendo del tamaño de paquete solicitado por Planificador. – El planificador es la entidad encargada de realizar los cálculos que determinan el tamaño del paquete a transmitir (según el estándar); indica el valor del tamaño a ColaMesh. Es una entidad completamente desarrollada en C++ que hereda a la clase pública Connector; posee métodos que permiten

indicar a la cola que inicie desencolamiento o pare. Otra función de esta entidad es que dependiendo del paquete que le llegue o comando ejecutado decide la operación a realizar; si recibe un paquete del tipo control indica a la cola que inicie desencolamiento; si recibe un paquete del tipo OFDM lo envía al puerto de salida. • Controlador MAC : al igual que la entidad Planificador, también es desarrollada completamente en C++ y hereda a la clase Connector. El Controlador se comunica con la entidad Control de Flujo por medio de Planificador para ejecutarle métodos que inicien o paren solicitudes a la cola. Se crea un Control de Flujo para cada conexión y el controlador posee una lista de todos los planificadores. Además, en el controlador se inicializan los parámetros Header OFDM y se selecciona el esquema de modulación a emplear. El controlador MAC recibe de Link Scheduling los tiempos en que se programará cada control de flujo. El Controlador MAC al recibir datos los analiza para determinar si son dirigidos a él; si lo son, los envía a capas superiores. • Fuente de datos: es la encargada de generar los paquetes que serán enviados de un nodo a otro en cada conexión. Como se observa en la Figura 1, el modelo tiene en cuenta que las fuentes son internas en la capa MAC. Se desarrolló una nueva fuente con generación exponencial, tipo de paquete mesh y headers que se mencionarán en


65

IV-D. A la fuente exponencial se le configura la tasa de generación de paquetes por segundo (l) y el tamaño del paquete en bytes. Es de anotar, que la estructura Fuente-Agente Fuente-Agen te no se empleó en el modelo, ya que la nueva fuente se hizo de tal forma que se pudiera realizar la conexión Fuente-MAC mesh 802.16. 3) Trace, Trace in, Trace out: Como se sabe los traces son los encargados de medir las variables que se requieran, enviando a un archivo los datos de la simulación. Para analizar las variables y paquetes OFDM creados se desarrolló un nuevo trace: TraceMesh. TraceMesh es una entidad que hereda las propiedades y métodos de Connector y posee las mismas variables y propiedades de Trace. La diferencia con Trace es que guarda o imprime las propiedades de los nuevos paquetes creados en ColaMesh. Imprime los siguientes datos que se encuentran en el header OFDM: Tiempo, Nfft , Ttr, CP, CR, CB, η, duracionMS, numMS, Tamaño real paquete enviado, Tamaño paquete solicitado para enviar, CIDorigen, CIDdest. En caso de requerirse nueva información es posible agregarla. Para el correcto funcionamiento de la entidad TCL “TraceMesh” fue necesario realizar una súper clase en TCL, llamada “TraceMeshClass” en la cual se le indicaban los tipos de paquetes que podía soportar el trace y principalmente el formato OFDM. 4) Headers: Los siguientes headers fueron desarrollados para el funcionamiento del modelo de capa MAC realizado: • hdrofdm: este header es el principal. En él se guardan todas las

66


características de los paquetes empleados. Los parámetros que contiene son los siguientes: BW, Nused, n, CP, Nfft, FS, subcarrierspacing, Tsym , CP time, OFDMsymboltime, Tsampling, CR, CB, Ttr, durationMS, delayMS, MSo, MSSize, Nofdm symbol, MCL(MSH _CTRL_LEN), CID origen, CIDdest. • hdr-packing : este header es empleado en ColaMesh para determinar la longitud del nuevo paquete y almacenar en un buffer los paquetes que está empaquetando. • hdr-CtrlTRX: en este header se indica cuánto tiempo tiene el planificador para la ocupación del canal, el cual es igual a numMS x duracionMS . Este header también es empleado cuando se envía un paquete de control del controlador MAC al planificador, indicando este tipo de paquete que se debe solicitar a la cola que desencole. C. Diagrama de eventos, funcionamiento general

En la Figura 2 se observa el diagrama de eventos que representa el modelo implementado implementado con las características de la capa MAC dadas por el estándar. Los eventos fueron diseñados de tal forma que se pudieran agregar nuevas funciones o características, como por ejemplo el ingreso de nuevos nodos, elección del tipo de modulación dependiendo del canal, cambios de scheduler, entre otros. Como ya se mencionó el Link Scheduler es el encargado de inicializar los parámetros de las entidades Controlador MAC y Planificadores, con datos obtenidos de archivos de configuración. Como se observa el evento

Figura 2. Diagrama de evento del modelo implementado

inicializa enlaces y activa CMAC, puede generar dos eventos, uno para crear el mismo evento y otro para activar los controladores MAC, quienes a su vez inicializan los planificadores (SHC). El planificador (SCH) es el encargado de habilitar a la cola para que desencole determinada cantidad de bytes, los cuales fueron determinados con las ecuaciones mostradas en las sección de parámetros OFDM. Las demás características se observan en la Figura 2. D. Planificador El scheduling implementado es del tipo Pure greedy [19], [20]. Todos los algoritmos link scheduling son centralizados, trabajan fuera de línea y requieren conocimiento global de la red. El algoritmo busca garantizar que en un enlace (nodo A → nodo B) no resulte en colisión, ya sea en el nodo A o en el nodo B. Se tienen en cuenta dos tipos de colisiones:

•

Primary interference:

ocurren cuando una estación transmite y recibe la misma ranura. • Secondary interference: ocurren cuando una estación recibe dos o más transmisiones separadas en la misma ranura. En link scheduling no se presentan colisiones y consiste en una secuencia de ranuras fijas, donde a cada enlace se le asigna un determinado número de minislots (MS) y transmite cíclicamente. Para evitar las colisiones determina qué vecinos pueden transmitir en la misma ranura. El algoritmo también asume que la transmisión de una estación es recibida por todas las estaciones con una distancia Euclidiana R. El algoritmo fue implementado en Matlab. Este programa a partir de matriz de tráfico y vecinos, calcula y asigna las ranuras a cada conexión, de tal forma que se minimice en gran medida la duración del ciclo


67

de transmisión. Los resultados son exportados a archivos, los cuales a su vez son empleados en NS2 por la entidad Link Scheduler para la configuración de los nodos y entidades. En la Figura 3 se observa la asignación de ranuras de transmisión para

una configuración de diez nodos en configuración mesh y en la Figura 4 se muestran las ranuras en que recibe cada nodo, lo que depende de la respectiva asignación de ranuras de transmisión.

Figura. 3. Asignación de ranuras de transmisión

Figura 4. Ranuras de recepción.

68


V. RESULTADOS SIMULACIONES

A. Scheduler TDM Con el objetivo de analizar el comportamiento del Link Scheduler centralizado implementado, se realizaron diferentes pruebas para determinar distintos aspectos, tales como la duración del ciclo de transmisión y el número de nodos que transmiten y

reciben simultáneamente en función de la conectividad de la red. También se verificó la distribución del ciclo de transmisión y el efecto que ocasiona el orden de asignación de las ranuras en el porcentaje de disminución del ciclo de transmisión, medida como el porcentaje de disminución del ciclo obtenido en el reúso espacial respecto a cuando no se emplea reúso.

Figura 5. Percentage reduction and mean of the transmission cycle.

Se realizaron dos pruebas para topología mesh y dos para topología en relay, corriendo 1.000 veces el algoritmo de planificación para cada caso. La curva A muestra los resultados para topología mesh respecto al número de nodos y radio constante de transmisión R. El requerimiento de ranuras es aleatorio para cada enlace y el orden de asignación depende del índice en la tabla de enlaces. La curva B muestra resultados similares al caso A, pero en éste el orden de asignación en el ciclo de transmisión es aleatorio. Las curvas C y D muestran

los resultados para configuración en relay. En el caso C, el orden de asignación depende del índice en la tabla de enlace. En el caso D, el orden es aleatorio. La Figura 5 presenta los resultados para los casos mencionados anteriormente. Los resultados muestran que para topologías mesh no afecta si el orden de asignación es determinístico o aleatorio. El porcentaje de minimización del ciclo de transmisión (% M ) es cercano al 100% (%M ≈ 100%) cuando SISTEMAS & TELEMÁTICA

69

2 45 40 7 35

9

30

3 8

25 4

20 1 15

6 10

10 5 15

20

25

30

35

40

45

50

Figura 6. Ubicación de 10 nodos en configuración mesh.

n → ∞ o bajo (%M < 100%) cuando n es pequeño; estos casos son considerados para configuración en relay. El porcentaje de minimización (%M) se calculó con la ecuación 6. (6) Lmax es el máximo número de ranuras cuando se asigna secuencialmente (sin reúso). Lobt es el número de ranuras asignadas obtenidas con Link Scheduler. Se puede deducir que en configuración relay, el ciclo de transmisión no tiende a incrementar cuando el número de nodos aumenta. También en la ecuación 6 el límite tiende al 100%. En topología mesh, el ciclo de transmisión tiende a incrementar con el número de nodos, pero el porcentaje de minimización no tiende a 100% porque la cantidad en la ecuación 6 también tiende a incrementar. Con esto se puede decir que en configuración en relay es mejor que la asignación sea en un orden específico dado por el índice de la tabla de enlace. Esto también se puede observar

70


en la Figura 5, donde %M es alto para configuración en relay donde el reúso espacial aumenta con el aumento de la cantidad de nodos. B. Simulación topologías en NS2 Se emplearon 5 escenarios de simulación para obtener resultados de capacidad, retardo y longitud de las colas de sistemas wireless con capa MAC IEEE 802.16-2004. Los escenarios fueron los siguientes: • 3 nodos en mesh, tráfico idéntico para cada conexión. • 3 nodos en mesh, tráfico variable para cada conexión. • 10 nodos en mesh, tráfico variable para cada conexión. • 10 nodos en relay, tráfico idéntico para cada conexión. • 10 nodos en relay, con agregación de tráfico para cada conexión (T, 2T, 3T,..., nT). En la Figura 6 se muestra la ubicación de una de las topologías simuladas (10 nodos en configuración mesh); las líneas representan las conexiones con los otros nodos de la red, depen-

diendo de la distancia R. Para todas las simulaciones se emplearon los datos de configuración mostrados en la Tabla II. Tabla II. Datos de configuración de simulaciones. Esquema de modulación

BW (MHz) η

Nfft Np CP Ttr (ms) CB CR MCL l Fuente exponencial Tamaño paquete

64-QAM

3.5 8/7 256 192 1/4 4 6 0.75 1 100 x T 100 bytes

Tabla III. Ratas de transmisión para diferente tráfico. T (MS)

R(kbps)

1

216

2

432

3

648

4

864

5

1080

η

n X 216

Con estos datos se obtienen las ratas de transmisión teóricas mostradas en la Tabla III. En la Figura 7 se muestran las gráficas de comportamiento de una cola, curva de llegada y servicio para la red de la Figura 6. Se observa que la cola en un instante de tiempo posee máximo cinco paquetes y nunca pierde paquetes. Detalladamente en la Figura 8 se observa el comportamiento de la llegada de paquetes a la cola y cómo son servidos. La distribución que siguen los retardos en cola se observa en la Figura 9, y se nota que la media se encuentra alrededor del tiempo de trama (T tr). Los resultados obtenidos para todos los enlaces se muestra en las Figuras 10, 11 y 12. Se observa que la rata de transmisión lograda en promedio (para 1 MS) es muy parecida para todas las colas y que el valor es semejante al encontrado en los cálculos teóricos (Tabla III). Respecto a la longitud de la cola (Figura 11), es observable que es proporcional a la capacidad del enlace, es decir, a la cantidad de minislot asignados. Por

Figura 7. Cola 19 en el tiempo, curva de llegada y de servicio.


71

Figura 8. Acercamiento Cola 19 en el tiempo y curva de llegada y de servicio

Figura 9. Histograma de retardos en Cola 19 - 10 nodos en mesh.

Figura 10. Capacidad para 1 MS para cada cola - 10 nodos en mesh.

72


Figura 11. Longitud de la cola para cada cola - 10 nodos en mesh.

Figura 12. Retardo promedio para cada cola - 10 nodos en mesh.

Figura 13. Capacidad para cada cola - 10 nodos en relay.

Figura 14. Longitud de la cola para cada cola - 10 nodos en relay.


73

Figura 15 . Retardo promedio para cada cola - 10 nodos en relay.

último en la Figura 12 se muestra que el valor promedio de retardo se encuentra por debajo del valor de tiempo de trama (4 ms). Otros resultados obtenidos se muestran en las Figuras 13, 14 y 15. En éstas, se observan los resultados para una configuración de 10 nodos en relay con agregación de tráfico en una unidad cada salto, es decir, se simula el caso en que cada salto transmite sus propios datos y los anteriores (Tráfico: T, 2T, 3T,..., nT). Es observable en las gráficas que es posible que cada cola transmita la cantidad de datos exigida, sin embargo, el planificador no asignó recursos al último salto porque interfería con otras transmisiones, es decir, los paquetes que estaban dirigidos al último nodo nunca llegaron a él. VI. CONCLUSIONES

En este artículo se propone un modelo de capa MAC para el estándar IEEE 802.16, el cual sirve para simular redes inalámbricas mesh; brindando con esto herramientas que permitan el análisis de planificadores, longitud y retardo en las colas, modelos de propagación, capacidad, otros. Son posibles además modificaciones para hacer extensiones a PMP.

74


El modelo propuesto está compuesto por módulos que se pueden adaptar para agregar funciones y características del estándar tales como inicialización de nodos, entrada a la red, planificación, esquemas de modulación y esquemas de codificación adaptativa. Es necesario que la red disponga un buen algoritmo de planificación, capaz de asignar las ranuras de tiempo disponibles a la mayor cantidad de enlaces haciendo buen uso del reúso espacial. El motivo de esto es que para redes mesh el tiempo de trama dado por el estándar es muy corto, por lo cual la cantidad de minislot disponibles para asignar en el sistema son pocos y requiere una buena eficiencia en el ciclo de planificación. En caso de topología relay, el planificador de enlace posee mejores características en cuanto a la duración del ciclo de transmisión se refiere, ya que después de cierta asignación de ranuras, asigna los mismos tiempos de transmisión cada tres saltos, mejorando con esto el reúso espacial. Se puede observar que la capacidad de las redes mostradas (ranuradas) es muy similar a los valores teóricos. Los nodos que manejan tráfico de otros usuarios deben recibir mayor

asignación de recursos que los otros nodos que no lo hacen. Sin embargo, es necesario analizar estos sistemas en condiciones más reales con errores en el canal. El retardo promedio de un paquete en cola se mantiene por debajo del valor del tiempo de trama para casos donde la tasa de llegada a la cola es tal que se puedan transmitir en la trama siguiente. AGRADECIMIENTOS

Los autores agradecen a los evaluadores anónimos por sus sugerencias. BIBLIOGRAFÍA

[1] H. Bolcskel, A. J. Paulraj, K. V. S. Hari, R. U. Nabar, and W. W. Lu, “Fixed broadband wireless access: state of the art, challenges, and future directions,” Communications Magazine, IEEE , vol. 39, pp. 100– 108, 2001. [2] C. Tschudin, P. Gunningberg, H. Lundgren, and E. Nordström, “Lessons from experimental manet research,” Elsevier Ad Hoc Networks Journal, vol. 3, no. 2, pp. 221–233, March 2005. [3] R. Bruno, M. Conti, and E. Gregori, “Mesh networks: commodity multihop ad hoc networks,” Communications Magazine, IEEE , vol. 43, pp. 123–131,

2005. [4] K. Balaji, N. Hegde, B. V. Ramana, B. S. Manoj, and C. S. R. Murthy, “Performance evaluation of a hybrid wireless network architecture for rural communication,” in Personal Wireless Communications, 2005. ICPWC 2005. 2005 IEEE Inter-

national Conference on,

2005,

pp. 212– 216. [5] P. Gupta and P. Kumar, “The capacity of wireless networks,”

Information Theory, IEEE Transactions on, vol. 46, no. 2,

pp. 388–404, 2000. [6] C.-S. Chang, “Stability, queue length, and delay of deterministic and stochastic queueing networks,” Automatic Control, IEEE Transactions on, vol. 39, pp. 913–931, 1994. [7] A. W. Berger and W. Whitt, “Extending the effective bandwidth concept to networks with priority classes,” Communications Magazine, IEEE , vol. 36, pp. 78–83, 1998. [8] C. Cicconetti, L. Lenzini, E. Mingozzi, and C. Eklund, “Quality of service support in IEEE 802.16 networks,” IEEE Network, vol. 20, no. 2, pp. 50–55, 2006. [9] G. Chu, D. Wang, and S. Mei, “A qos architecture for the MAC protocol of IEEE 802.16 BWA system,” in Communications,

Circuits and Systems and West Sino Expositions, IEEE 2002 International Conference on,

vol. 1, 2002, pp. 435–439. [10] S. Naghian, “Mesh vs. point-tomultipoint topology: a coverage and spectrum efficiency comparison,” in Personal, Indoor and

Mobile Radio Communications, 2004. PIMRC 2004. 15th IEEE International Symposium on,

vol. 2, 2004, pp. 1048–1051. [11] H.-L. Chao andW. Liao, “Fair scheduling with qos support in wireless ad hoc networks,” SISTEMAS & TELEMÁTICA

75

IEEE Transactions on Wireless Communications, vol. 3, no. 6,

pp. 2119–2128, 2004. [12] M. Cao, W. Ma, Q. Zhang, X. Wang, and W. Zhu, “Modelling and performance analysis of the distributed scheduler in ieee 802.16 mesh mode,” in MobiHoc ’05: Proceedings of the 6th ACM international symposium on Mobile ad hoc networking and computing . New York, NY, USA:

ACM Press, 2005, pp. 78–89. [13] D.-H. Cho, J.-H. Song, M.S. Kim, and K.-J. Han, “Performance analysis of the ieee 802.16 wireless metropolitan area network,” in Distributed

Frameworks for Multimedia Applications, 2005. DFMA ’05. First International Conference on, 2005, pp. 130–136.

[14] S. Redana and M. Lott, “Performance analysis of ieee 802.16a in mesh operation mode,” in 1st mobile and wireless communications summit 2004, 2004.

[15] P. Bjoorklund, P. Varbrand, and D. Yuan, “A column generation method for spatial tdma scheduling in ad hoc networks,” Department of Science and Technology, Linkoping Institute of Technology, Tech. Rep. LiTHITN- R-2003-9, 2003. [16] S. Ramanathan and E. L. Lloyd, “Scheduling algorithms for multihop radio networks,” in SIGCOMM ’92: Conference proceedings on Communications architectures & protocols. New

York, NY, USA: ACM Press, 1992, pp. 211–222.

76


[17] I. W. 802.16, “The ieee 802.16 working group on broadband wireless access standards,” 1998. [18] I. S. 802.16, “IEEE standard for local and metropolitan area networks part 16: Air interface for fixed broadband wireless access systems,” in IEEE Std 802.16-2004 (Revision of IEEE Std 802.16-2001) , 2004, pp.

1–857. [19] R. L. Errol, “A distributed protocol for adaptive link scheduling in ad-hoc networks,” p. 11, 2000. [Online]. Available: citeseer.ist. psu.edu/578259.html [20] P. V. Patrik Bjorklund and D. Yuan, “A column generation method for spatial tdma scheduling in ad hoc networks,” in Elsevier Science, 2003. CURRÌCULOS Javier Sierra (Javier.sierra@upb.

edu.co) recibió su título de Ingeniero Electrónico en la Universidad Nacional de Colombia en el año 2003 y su magíster en Ingeniería área Telecomunicaciones en la Universidad Pontificia Bolivariana en el 2007, donde actualmente es estudiante del doctorado en Ingeniería con el soporte de Colciencias. Trabaja para el grupo de investigación GIDATI. Entre sus áreas de interés se encuentran las redes inalámbricas, redes mesh, redes híbridas óptico-inalámbricas, optimización de redes ópticas y técnicas de simulación. Leonardo Betancur (leonardo. [email protected]) recibió su

título de Ingeniero Electrónico en la Universidad Nacional de Colombia en 2003 y recibió su título de Magíster en Telecomunicaciones en la Universidad Pontificia Bolivariana en 2007, en donde actualmente realiza sus estudios de Doctorado en Telecomunicaciones con el apoyo de Colciencias. Pertenece al grupo de investigación GIDATI, y actualmente sus intereses en temas de investigación incluyen redes inalámbricas, redes de sensores, UWB y aplicaciones y tecnologías para ambientes indoor. R o b e r t o H i n c a pi e (roberto. [email protected] ) recibió su título de Ingeniero Electrónico en 1996 y su título de Magíster en Telecomunicaciones en 2006 en la Universidad Pontificia Bo-

livariana, en donde actualmente es estudiante del doctorado en Ingeniería con el apoyo de Colciencias, Es miembro del grupo de investigación GIDATI. Sus temas de interés abarcan Redes inalámbricas, redes enmalladas, algoritmos para planificadores con soporte de calidad de servicio y técnicas de simulación. Roberto Bustamante Millar ([email protected]) es Ingeniero Electrónico, graduado en la Universidad de Surrey, Inglaterra. PhD en Ingenierìa Electrónica (Antenas Adaptativas), Universidad de Surrey, Inglaterra. Actualmente es profesor Asociado de la Universidad de los Andes y director del Departamento de Ingeniería Eléctrica y Electrónica.


77

78


Evaluación del estimador de capacidad AdHoc Probe en redes MANET con tráfico cursado autosimilar María del Pilar Salamanca, Néstor Misael Peña

GEST, Grupo de Electrónica y Sistemas de Telecomunicaciones Universidad de los Andes, Bogotá, Colombia {m-salama,npena}@uniandes.edu.co




ABSTRACT

KEYWORDS

Due to the dynamic nature of ad hoc networks, the path capacity estimation process is much more complex than in wired networks. AdHoc Probe is a capacity estimator based on the packet-dispersion concept. To evaluate end-to-end path capacity, AdHoc Probe sends pairs of packets and takes into account only those pairs with minimum delay. It is widely known that traffic in current networks has self similar nature and recent works show that ad hoc networks exhibit this feature too. In this paper, using an implementation of AdHoc Probe in QualNet R, we evaluate the performance of AdHoc Probe when the network has self similar cross traffic and we validate the results of previous works with Poisson cross traffic.

Ad-Hoc networks, MANET, AdHoc Probe, traffic, simulation RESUMEN

Debido a la naturaleza dinámica de las redes ad-hoc, la estimación de la capacidad de una ruta es mucho más compleja que en una red cableada. AdHoc Probe es un algoritmo para estimar capacidad, basado en el concepto de dispersión de paquetes. Para evaluar la capacidad de un enlace extremo a extremo, AdHoc Probe envía pares de paquetes y analiza sólo aquellos que tienen el mínimo retardo. Es ampliamente conocido que el tráfico de datos tiene una naturaleza autosimilar y algunos estudios recientes indican que las redes adhoc tienen este comportamiento. En el presente artículo, utilizando una


79

implementación de AdHoc Probe en QualNet, se evalúa el rendimiento de AdHoc Probe cuando la red tiene tráfico cruzado autosimilar y se validan los resultados de trabajos previos con tráfico poisson.

80


PALABRAS CLAVE

redes Ad-Hoc, MANET, AdHoc Probe, tráfico, simulación Clasificación Colciencias: A

I. INTRODUCCIÓN

La estimación de capacidad en una red ha sido objeto de estudio en múltiples investigaciones [1], [2] y [3]. Sin embargo, la mayoría de dichos estudios han enfocado el problema a redes cableadas y muy poco existe acerca de la estimación en redes inalámbricas. Para el caso particular de las redes ad hoc, el proceso de estimación de capacidad se hace especialmente complicado debido a la naturaleza dinámica de las mismas. Entre las herramientas de estimación de capacidad para redes ad hoc propuestas con anterioridad a la estudiada en [4], se destaca la presentada en [5]. Allí se realiza la estimación inyectando en el canal tanto tráfico UDP como sea posible y la capacidad estará dada por el máximo caudal alcanzable por ese flujo. Sin embargo, es evidente que esta técnica afecta de forma dramática el tráfico cursado presente en la red. Tal como se plantea en [4], una herramienta de estimación de capacidad en redes ad hoc debe ser rápida, independiente del tráfico cursado, no intrusiva para que no afecte a las otras aplicaciones cuyo tráfico se encuentre en la red y debe, en lo posible, funcionar en redes donde existan trayectos cableados e inalámbricos. El estimador de capacidad propuesto en [4], denominado AdHoc Probe, de acuerdo con los resultados que se mostrarán más adelante, posee características muy interesantes que se ajustan a estos requerimientos. En [4], AdHoc Probe se evalúa mediante el simulador ns-2 en escenarios tanto estáticos como móviles, sin tráfico cursado y con tráfico cursado de

Poisson. Considerando que el tráfico de las redes actuales se ajusta mejor a un modelo de tráfico autosimilar, resulta imprescindible evaluar este estimador en redes con tráfico cursado de este tipo. En [6] se presenta un estudio de tráfico en redes ad hoc y, a partir de los resultados obtenidos en una red de prueba de 20 computadores, se concluye que el tráfico de esta clase de redes es altamente autosimilar. Mediante la implementación de AdHoc Probe en QualNet R y utilizando las características del tráfico autosimilar en redes ad hoc encontradas en [6], en este artículo se evalúa el desempeño de AdHoc Probe en presencia de tráfico autosimilar y en diferentes escenarios. A partir de los resultados obtenidos en los mismos escenarios reemplazando el tráfico autosimilar por tráfico de Poisson, se analizan las limitaciones encontradas y se delimita el alcance de este estimador. El artículo está organizado de la siguiente manera. En la sección II se describe el algoritmo de estimación de capacidad de AdHoc Probe. Con el fin de comparar los resultados obtenidos en [4] con los de este estudio, en la sección III se presenta la metodología utilizada para obtener un modelo de los nodos en QualNet R, de características similares al utilizado en ns-2. En la sección IV se muestran los resultados de las simulaciones para diferentes escenarios, con tráfico cursado de Poisson y sin él. En la sección V se presentan los resultados de los mismos escenarios con tráfico autosimilar. Finalmente, en la sección VI se extraen las conclusiones de este trabajo.


81

II. DESCRIPCIÓN DE ADHOC PROBE

AdHoc Probe es una herramienta que permite calcular la máxima tasa de transmisión alcanzable en un trayecto de una red ad hoc cuando no existe otro tráfico que compita por el uso de la misma. En una red ad hoc, la máxima tasa de transmisión usualmente es menor que la tasa de transmisión nominal, debido a factores como la interferencia ocasionada por nodos vecinos, el mecanismo de RTS/CTS, la movilidad de los nodos, la “autointerferencia” entre los paquetes de una misma sesión, etc. Estas características, propias de las redes inalámbricas, hacen que el proceso de estimación de ancho de banda sea mucho más complejo que en redes cableadas [4]. Para calcular la capacidad, el emisor, ubicado al comienzo del trayecto a evaluar, envía pares de paquetes de tamaño fijo, de extremo a extremo de la ruta, y marca cada uno de los paquetes con el tiempo de envío. El receptor, ubicado en el extremo opuesto, mide el retardo de cada paquete recibido (OWD o One Way Delay) como la diferencia entre el instante en el cual llegó el paquete y el tiempo de envío que se encuentra marcado en el encabezado del mismo. Luego, el receptor calcula el OWD de cada par, sumando el retardo de cada uno de los paquetes que lo componen. AdHoc Probe asume que, al menos, un par de paquetes no encontró tráfico cursado en la red y ese par de paquetes corresponde a aquel que obtuvo el menor OWD. La capacidad del trayecto se calcula como C=P/T, donde P es el tamaño de cada uno de los paquetes y T es la dispersión del par con menor OWD.

82


El concepto de dispersión proviene de una analogía con la teoría de fluidos y se explica en detalle en [7], [8] y [9]. La dispersión corresponde al tiempo que el receptor mide entre el último bit del primer paquete y el último bit del segundo paquete. Es una medida de la menor capacidad encontrada a lo largo de cada uno de los saltos del trayecto evaluado. Para efectuar la estimación, AdHoc Probe considera dos parámetros: la cantidad de pares de paquetes (N) y la tasa de envío de los mismos (R pares de paquetes/segundo). Así, la duración aproximada de una estimación es N/R segundos. Es claro que cuanto mayor sea R, el proceso de estimación será más rápido, pero si R es demasiado grande puede perturbar el tráfico cursado en la red o incluso congestionarla. Por otra parte, la precisión de la estimación aumenta cuando N crece, sin embargo, un valor de N grande no es adecuado para redes móviles pues el tiempo de estimación aumenta, lo cual no permitiría capturar las propiedades dinámicas de las redes inalámbricas. Los valores de los parámetros N y R deben ser determinados cuidadosamente. En [4] no se indica ningún procedimiento para hacerlo, pero se aclara que todas las simulaciones realizadas utilizaron N=200 pares y R=4 pares/segundo. Adicionalmente, en todas las simulaciones se emplea 802.11b a 2 Mbps. III. METODOLOGÍA PARA OBTENER EL MODELO DE LOS NODOS EN QUALNETR

Con el fin de validar los resultados de [4] obtenidos con ns-2, se implementaron los mismos escenarios de

[4] en el simulador QualNet R. Fue necesario encontrar un modelo de los nodos en QualNetR que estableciera un radio de transmisión de 250 m y un radio de interferencia de 550 m. Sólo utilizando modelos equivalentes de los nodos, sería posible comparar los resultados. En ns-2 los radios de interferencia y de transmisión se definen como distancias fijas. En QualNetR, dichos radios se deben inferir a partir de los parámetros de configuración de los nodos, específicamente la potencia de transmisión y la sensibilidad del receptor, para una distancia de separación fija entre el transmisor y el receptor, que para todos los escenarios simulados en [4] es de 200m. Tabla I. Configuraciones evaluadas cuyo radio de transmisión resultó más cercano a 250 m. Potencia de transmisión [dBm]

Sensibilidad de receptor [dBm]

Radio de transmisión [m]

10

-89

254

11

-85

252

12

-84

252

14

-82

252

El cálculo del radio de transmisión se realiza haciendo una búsqueda binaria, variando la distancia entre transmisor y receptor y evaluando en cada paso si la señal emitida por el transmisor es “alcanzable” para el receptor. En QualNetR [10] se considera que la señal es alcanzable si la potencia en el receptor es mayor o igual al umbral de recepción y, si esto se cumple, también se verifica que la tasa de error de paquetes (PER) sea menor al 10%. Este procedimiento se repite para diferentes combinaciones de potencia de transmisión y sensi-

bilidad del receptor, hasta encontrar aquellas en las cuales la máxima distancia entre transmisor y receptor que cumpla con las condiciones anteriores se aproxime a 250 m. En la Tabla I se presentan las cuatro combinaciones obtenidas. Estas mismas configuraciones se evaluaron, como se indica más adelante, para el cálculo del radio de interferencia.

Figura 1. Escenario implementado en QualNetR para determinar el radio de interferencia de un nodo.

El radio de interferencia se calcula mediante simulaciones, para lo cual se implementó el escenario de la Figura 1. Este es un escenario útil para determinar hasta qué distancia el tráfico entre dos nodos puede afectar a los flujos de nodos cercanos. El escenario consiste en dos flujos CBR basados en UDP, uno entre los nodos 1-2 y el otro entre los nodos 3-4. La distancia del nodo 1 al nodo 2 es de 200 m, permanece fija y es igual a la distancia entre el nodo 3 y el 4. Para verificar la influencia del radio de interferencia, se varía la distancia vertical entre los nodos 2 y 3. Aquella distancia vertical a partir de la cual los dos flujos alcanzan su máximo caudal será el radio de interferencia, cuyo centro se localiza en el nodo receptor. Este procedimiento fue tomado de [11], aunque en dicha referencia se utiliza con el fin de demostrar la degradación del desempeño de IEEE SISTEMAS & TELEMÁTICA

83

802.11 cuando los nodos tienen un radio de interferencia mayor que el radio de transmisión. Para este escenario el generador de tráfico CBR se modificó ligeramente. Dada una tasa de transmisión de n paquetes por segundo, se divide el tiempo de la simulación en intervalos de 1/n segundos. En cada intervalo se envía un paquete a la red y el tiempo de envío del paquete se distribuye uniformemente en el intervalo. Con esto se evita que los dos flujos CBR intenten transmitir al tiempo y se presente una sucesión de colisiones, lo cual produciría resultados incorrectos. Al igual que en [11], las métricas elegidas fueron el caudal agregado de los nodos 2 y 3 y la tasa de paquetes con error. Esta última es una medida porcentual que indica cuántos paquetes, del total de paquetes recibidos, llegaron mal.

Cada uno de los dos flujos CBR se configura para obtener un caudal de 819 kbps, enviando 100 paquetes de 1024 bytes por segundo, con el fin de utilizar la mayor parte del ancho de banda cuando los dos flujos comparten el canal. Es importante recordar que la capacidad efectiva de un canal IEEE 802.11 es menor que su capacidad nominal debido, entre otros factores, al “overhead” ocasionado por la función de coordinación. Al compartir el canal, el caudal agregado incluso resulta inferior que la magnitud de los dos flujos agregados, como se observará en los resultados. En todas las simulaciones se configura el modelo de propagación Two Ray Ground y se incluyen pérdidas por shadowing, las cuales se consideran de valor constante [12]. Los resultados se muestran en las Figuras 2 y 3.

Figura 2. Caudal agregado para el escenario de la Figura 1 a medida que varía la distancia entre los nodos 2 y 3. Nótese que la configuración que recupera el caudal máximo más cerca de 550m corresponde a la potencia de transmisión de 10 dBm y la sensibilidad del receptor de -89 dbm.

84


Figura 3. Tasa de paquetes con error para el escenario de la Figura 1 a medida que varía la distancia entre los nodos 2 y 3.

Intuitivamente se esperaría que al aumentar la distancia entre los nodos 2 y 3 también lo hiciera el caudal agregado; sin embargo, los resultados muestran un comportamiento muy diferente. Cuando la separación entre los nodos 2 y 3 es menor que el radio de transmisión, los nodos 3 y 4 pueden escuchar los CTS y ACK del nodo 2 (lo mismo sucede con los nodos 1 y 2 y el nodo 3), sin importar que los nodos 1 y 4 estén fuera de alcance uno del otro. En estas condiciones, los dos flujos comparten el canal y, en el mejor de los casos, el throughput agregado se aproxima a 1.5 Mbps, cuando se esperaba que fuera cercano a 1.6 Mbps dada la magnitud de cada uno de los flujos. La situación cambia completamente cuando la distancia entre los nodos 2 y 3 se aproxima y supera al radio de transmisión. Cuando los nodos 2 y 3 se encuentran fuera de sus respectivos radios de transmisión, se esperaría que pudieran reusar el canal; sin embargo, el caudal muestra una caída dramática y el error se

incrementa abruptamente. Esto se debe a que a esas distancias el nodo 2 se encuentra dentro del radio de interferencia del nodo 3 (y viceversa), y allí el “handshake” RTS/CTS no es efectivo. Solamente cuando los nodos 3 y 4 estén totalmente afuera del radio de interferencia del nodo 2, lo cual sucede simultáneamente cuando los nodos 1 y 2 se encuentren afuera del radio de interferencia del nodo 3, el caudal agregado es máximo. En particular, la configuración que alcanza el caudal máximo más cerca de los 550 m, que es el radio de interferencia que se desea obtener, es aquella en la cual la potencia de transmisión es de 10 dBm y la sensibilidad del receptor es de –89 dBm. Para esa misma distancia, la tasa de error de esa configuración es aproximadamente de 5%. Esta configuración se utilizó en todos los escenarios presentados en este artículo y demostró que modela de forma muy aproximada los radios de transmisión y de interferencia requeridos. Sin embargo, es importante destacar que en QualNetR ambos ra-


85

dios representan una aproximación, lo cual es más cercano a la realidad, y fueron obtenidos específicamente para una distancia entre transmisor y receptor de 200 m. IV. VALIDACIÓN DE RESULTADOS UTILIZANDO QUALNETR

A. Cadena de nodos Con el modelo de los nodos determinado según el procedimiento anterior, se validaron los resultados de [4]. El primer escenario es una cadena de nodos separados 200 m entre sí, como se muestra en la Figura 4. Los nodos se ubican a lo largo de una línea recta y el tráfico AdHoc Probe se origina en el nodo 1 y se dirige hacia el nodo del

extremo opuesto (nodo 6). La línea gruesa alrededor de cada nodo denota el radio de transmisión del mismo, la línea punteada es el radio 4 de interferencia. Según el estudio realizado en [5], si el radio de transmisión y de interferencia fueran iguales, la capacidad de la cadena sería 1/3 de su capacidad efectiva. En ese caso, los nodos 1 y 2 no pueden transmitir al tiempo pues el nodo 2 no puede transmitir y recibir simultáneamente. Los nodos 1 y 3 tampoco pueden transmitir a la vez porque el nodo 2 no puede escuchar correctamente si el nodo 3 está enviando. En cambio los nodos 1 y 4 sí podrían transmitir a la vez. Por lo tanto, la utilización de la cadena sería de 1/3.

Figura 4. Topología de cadena de nodos. El tráfico AdHoc Probe va desde el primer nodo de la cadena hacia el último nodo. La línea continua corresponde al radio de transmisión y la línea punteada alrededor del nodo 4 denota el radio de interferencia.

Cuando el radio de interferencia es mayor que el radio de transmisión, la situación empeora. Tal como se explica en [4], para un radio de transmisión de 250 m y un radio de inter-

86


ferencia de 550 m, la transmisión simultánea entre los nodos 1, 2, 3 y 4 no es posible, lo cual implica que la capacidad de la cadena de la Figura 4 es 1/4 de la capacidad efectiva.

Figura 5. Capacidad estimada por AdHoc Probe para cadenas de nodos de diferente longitud y tamaño de paquete. Se observa que existe una pequeña diferencia entre la capacidad estimada en [4] para paquetes de 1500 Bytes y la estimada mediante QualNetR.

Como se mencionaba anteriormente, la capacidad efectiva de un trayecto IEEE 802.11 está dada por la capacidad máxima (2 Mbps para este estudio) y una reducción debida al “overhead” RTS/CTS/ACK. De acuerdo con [4], si un paquete RTS es de 40 bytes, los CTS y ACK son de 39 bytes y el encabezado MAC es de 47 bytes, el caudal, para paquetes de 1500 bytes será

Adicionalmente, en [5] se menciona que si se consideran los tiempos entre tramas, la capacidad efectiva se reduce aproximadamente a 1.7 Mbps. En consecuencia, para la cadena de nodos de la Figura 4, la capacidad estará entre 400 y 500 kbps. Los resultados de las simulaciones de la cadena de nodos usando QualNet R, para diferentes tamaños de paquete y variando el número de saltos de la cadena, se muestran en la Figura 5. Al reducir el tamaño del paquete, los resultados demuestran que la capacidad estimada también decrece, lo cual es acorde con la relación C=P/T.

Por otra parte, la capacidad alcanza su máximo valor para un solo salto y se reduce a medida que crece la cadena, confirmándose la relación inversa que existe entre la capacidad de una cadena y su longitud [4]. Cuando la longitud de la cadena es de 4 nodos, su capacidad es cercana a 500 kbps, lo cual concuerda con la estimación teórica explicada anteriormente. Para 5 nodos o más, la capacidad de la cadena permanece constante y es de 400 kbps aproximadamente, también dentro del intervalo previsto. En la Figura 5 también se presenta la estimación calculada en [4] con ns-2 cuando el tamaño del paquete es de 1500 bytes. Aunque los resultados son muy parecidos, existe una ligera discrepancia cuando la longitud de la cadena es de 4 y 5 saltos, seguramente ocasionada por las diferencias entre el modelo de radio de interferencia y de transmisión fijos que utiliza ns-2 y el modelo aproximado, que se emplea en QualNetR. B. Nodos en un mismo dominio de interferencia

Cuando existen N nodos en un mismo dominio de interferencia, la capa-


87

cidad efectiva es C/N, debido a que solamente uno de los nodos puede transmitir a la vez. Esta capacidad

teórica es estimada apropiadamente por AdHoc Probe, como se muestra en la Figura 6.

Figura 6. Capacidad de una cadena de nodos en un mismo dominio de interferencia, calculada utilizando AdHoc Probe implementado en QualNetR con paquetes de 1500 bytes.

Este escenario consta de una cadena de nodos igual a la de la Figura 4, pero esta vez los nodos se encuentran separados 10 m entre sí. El tráfico AdHoc Probe también se dirige del primer nodo de la cadena hacia el último de la misma. En esas condiciones los paquetes llegarían en un solo salto hacia el receptor dado que éste se encuentra dentro del radio de transmisión del nodo de origen. Para evitarlo, se configuraron rutas estáticas en el simulador. C. Malla de nodos Este escenario está compuesto por una malla de nxn nodos, donde n toma valores entre 4 y 7. Las simulaciones de este escenario se dividen en dos partes: la primera corresponde a una malla con tráfico cursado horizontal y la segunda a una malla con tráfico cursado horizontal y vertical, como se observa en la Figura 7. Los nodos se encuentran separados 200 m entre sí tanto vertical como

88


Figura 7. Malla de nodos con tráfico horizontal y vertical. En el escenario con tráfico horizontal se eliminan los flujos verticales; para 5 nodos, correspondería a los flujos entre los nodos 1-21, 2- 22, 3-23, 4-24 y 5-25. La estimación de capacidad se hace en la fila central, en este caso es el trayecto indicado por la línea punteada.

horizontalmente. La estimación de capacidad se realiza en el trayecto central con paquetes de 1500 bytes; las otras filas llevan flujos de Poisson, cuya tasa varía entre 1 kbps y 100 kbps. El protocolo de enrutamiento

utilizado es AODV. La capacidad medida por AdHoc Probe debe coincidir con la capacidad de una cadena de nodos que tenga la misma cantidad

de saltos. En la Figura 8 se muestran los resultados de la malla con tráfico cursado horizontal y se comparan con los obtenidos en [4].

Figura 8. Capacidad estimada en una malla con tráfico cursado de Poisson en dirección horizontal, (a) mediante QualNetR y (b) según [4].

Para los flujos hasta de 10 kbps la cadenas resulta menor que la reporestimación coincide con la capacidad tada en [4]. de la cadena correspondiente, de acuerdo con la Figura 5. Al compa- A medida que el tráfico cursado aurar los resultados de QualNet R con menta, la estimación se dificulta pues los 6 obtenidos en [4], se evidencia se reduce la probabilidad de que uno la diferencia mostrada en la Figura de los 200 pares de paquetes que se 5 para las mallas de 5 y 6 nodos, en envían no encuentre tráfico cursado. QualNetR la capacidad de estas dos El tráfico cursado puede tener dos


89

efectos sobre la estimación, los cuales se tratan en detalle en [2], [7] y [9]. Se puede presentar una subestimación de la capacidad cuando el segundo paquete del par sufre un retraso en cola debido al tráfico cursado. En este caso la dispersión del par de paquetes se incrementa y, en consecuencia, la capacidad estimada resulta menor. El efecto contrario se denomina “compresión” y sucede cuando el tráfico cursado retarda al primer paquete del par pero no al segundo. Este fenómeno hace que la dispersión entre el par de paquetes sea más pequeña

Figura 9. Capacidad estimada en una malla con tráfico cursado de Poisson en dirección horizontal y vertical, (a) mediante QualNetR y (b) según [4]. Cuando el tráfico cursado satura la malla, puede suceder que la dispersión del par de paquetes se comprima o se expanda; el segundo caso resulta más frecuente y cuando sucede, AdHoc Probe subestima la capacidad del trayecto

90


que la creada por el enlace “cuello de botella”, produciendo una sobreestimación de la capacidad. Cuando el tráfico cursado empieza a saturar las mallas, en las Figuras 8 y 9 se observan los dos efectos anteriores, aunque la mediana indica que para los flujos de 60 y 100 kbps el efecto más frecuente es la subestimación de la capacidad. El único caso en el cual sucede lo contrario se obtuvo con QualNetR, en la malla de 4x4 con tráfico cursado horizontal y vertical, lo cual puede observarse en la Figura 9(a).

Los “box plot” de las Figuras 10 y 11 corresponden a las mallas de 6 y 7 nodos, donde se observa la mayor dispersión en las estimaciones. Para los flujos de 60 y 100 kbps y a medida que las mallas aumentan su tamaño, la capacidad calculada por AdHoc Probe se encuentra en un amplio margen. Cuando existe tráfico cursado horizontal y vertical, la situación es crítica. Para las cadenas de 6 y 7 nodos, la estimación podría resultar

en valores entre 0 y 1.6 Mbps, donde un valor de cero implica que no fue posible recibir al menos un par de paquetes durante el intervalo de prueba. Como se observa en las Figuras 8 y 9, en [4] no se muestran resultados para estas condiciones. AdHoc Probe, como cualquier otra herramienta que calcule la capacidad a partir de la dispersión, tiene dificultades para hacer la estimación cuando el tráfico cursado satura la red.

Figura 10. “Box plot” de las mallas con tráfico cursado de Poisson en dirección horizontal. La línea inferior de cada caja corresponde al valor del cuartil menor, la línea central es la mediana y la superior es el valor del cuartil mayor. Se presenta para (a)malla de 6x6, (b) malla de 7x7.


91

Figura 11. “Box plot” para las mallas con tráfico cursado de Poisson en dirección horizontal y vertical. La línea inferior de cada caja corresponde al valor del cuartil menor, la línea central es la mediana y la superior es el valor del cuartil mayor. Se presenta para (a)malla de 6x6, (b) malla de 7x7. La dispersión de los resultados es máxima para los flujos cursados de 60 y 100 kbps.

D. Nodo móvil Este escenario consiste en un nodo que se desplaza en una malla de 5x5 nodos estacionarios, separados 200 m entre sí, el cual se muestra en la Figura 12. El nodo 25 es el nodo móvil, el cual se desplaza a 1 m/s a lo largo del trayecto indicado por 7 la línea punteada. El tráfico AdHoc Probe se transmite del nodo 0 al 25 y se envían paquetes de 1500 bytes. Se simulan los casos con tráfico cursado y sin él. Los flujos cursados se establecen

92


entre los nodos 0-4, 5-9, 10-14, 15-19 y 20-24 y llevan tráfico de Poisson a una tasa de 5 kbps. Los resultados se presentan en la Figura 13 y el “box plot” en la Figura 14. En este escenario, a medida que el nodo se desplaza se establece una cadena de nodos de entre el nodo 0 y el 25 cuya longitud varía durante la simulación. La estimación de ancho de banda se realiza cada 50 segundos (el tiempo necesario para recibir los 200 pares de paquetes). En la Figura

Figura 12. Escenario con nodo móvil. El nodo 25 se desplaza con una velocidad de 1 m/s a lo largo de la ruta señalada con la línea punteada. AdHoc Probe estima la capacidad entre el nodo 0 y el nodo 25 a medida que éste se mueve.

Figura 13. Mediana de la capacidad estimada para el escenario de nodo móvil, con tráfico cursado de Poisson y sin él.

13 se observa que al completar los primeros 200 m del recorrido, la capacidad cae de 1.6 Mbps a 800 kbps, que corresponde a una cadena de dos saltos. Cuando alcanza 500 m desciende a 500 kbps pues existen tres

saltos y al llegar a 600 m baja a 400 kbps, correspondiente a 4 saltos, allí sucede el primer cambio de dirección. En general AdHoc Probe logra una buena estimación; sin embargo, entre 1000 y 1500 segundos de simulación,


93

Figura 14. “Box plot” para el escenario del nodo móvil mostrado en la Figura 12. El eje horizontal es el tiempo de la simulación. Se hicieron 20 corridas. La Figura 14(a) corresponde a la simulación sin tráfico cursado y la 14(b) a tráfico cursado de Poisson.

cuando el nodo 25 se aproxima a los nodos 18, 19, 23 y 24, aumenta la dispersión de la capacidad estimada. No se debe al tráfico cursado pues en el “box plot” de la Figura 14 se observa que sucede lo mismo sin éste y obedece a la pérdida de los paquetes de AdHoc Probe debido a que las rutas no se refrescan oportunamente. Incluso, en este mismo intervalo se puede notar que cuando existe tráfico cursado se reduce la dispersión de la capacidad estimada, pues los nodos que llevan dicho tráfico ya han noti-

94


ficado su presencia a la red y gracias a ello la ruta entre el nodo 0 y el 25 se establece más rápidamente. V. DESEMPEÑO DE ADHOC PROBE EN ESCENARIOS CON TRÁFICO AUTOSIMILAR

Ha sido ampliamente estudiado que los procesos de llegada de paquetes en una red se modelan con más precisión utilizando procesos autosimilares que procesos de Poisson [14]. Con el fin de completar la evaluación de AdHoc Probe, se ha reemplazado el tráfico de

Poisson por tráfico autosimilar en las mallas de nodos con tráfico cursado y en el escenario del nodo móvil. Las trazas de tráfico autosimilar se generaron utilizando el algoritmo desarrollado por Paxson en [12], el cual produce trazas aproximadas de procesos autosimilares conocidos como ruido gaussiano fraccional (FGN). El grado de autosimilaridad de una traza se determina a partir del parámetro de Hurst (H) que posea la misma. El parámetro H se encuentra entre 1/2 < H 8 < 1, donde valores cercanos a 1 denotan un alto nivel de autosimilaridad. En [6] se realizó un estudio para determinar si el tráfico en redes ad hoc es autosimilar, para lo cual se implementó una red de prueba con 20 computadores. De las trazas analizadas se calculó el parámetro de Hurst para diferentes niveles de agregación. Las trazas para la simulación se generaron con H=0.95 y nivel de agregación de

10 segundos, una vez obtenidas se verificó si en efecto correspondían a ese valor utilizando el estimador de Whittle [15]. Dado que las trazas sintetizadas a partir de [12] entregan el número de llegadas por intervalo (en este caso 10 segundos) y lo que se requiere para las simulaciones es el tiempo entre llegadas, se realizó el siguiente procedimiento: primero, el número de llegadas por intervalo se convirtió en un valor entero. Luego ese número de llegadas por intervalo se cambió a tiempos entre llegadas distribuyéndolas uniformemente en el intervalo. Tal como en [4], se utilizaron paquetes de 1500 bytes tanto para el tráfico cursado como para AdHoc Probe y el promedio de paquetes en cada intervalo se escogió de manera que se lograra en promedio el flujo requerido para la simulación (1, 6, 10, 60 y 100 kbps). Los resultados se muestran en las Figuras 15 a 20.

Figura 15. Capacidad estimada en una malla con tráfico cursado autosimilar de parámetro H=0.95 en dirección horizontal.


95

Figura 16. Capacidad estimada en una malla con tráfico cursado autosimilar de parámetro H=0.95 en dirección horizontal y vertical.

En general, las capacidades estimadas con flujos cursados autosimilares y de Poisson tienen un comportamiento muy parecido. Para las mallas con tráfico cursado horizontal y vertical las estimaciones pierden precisión a medida que la malla aumenta su tamaño, debido a la denominada “autointerferencia” entre paquetes de una misma sesión que se encuentran separados por unos pocos saltos. Los “box plot” de las mallas demuestran que el efecto del tráfico cursado autosimilar también es crítico cuando logra saturar la red, y en las Figuras 17 y 18 se observa que dicha saturación se manifiesta con la subestimación y la sobrestimación de la capacidad del trayecto. Esto sucede cuando el tráfico cursado es de 60 y 100 kbps y se acentúa en las mallas más grandes, de 6 y 7 nodos. Es interesante notar que en presencia de tráfico cursado autosimilar horizontal y vertical, la estimación mejora con respecto a los escenarios con tráfico de Poisson horizontal y vertical. En las Figuras 11 (a) y (b),

96


correspondientes a tráfico cursado de Poisson, para el caso de 100 kbps el primer cuartil es igual a cero, es decir, el 25% de las muestras entregaron ancho de banda cero, lo cual implica que no se recibió ni siquiera un par de paquetes para hacer la estimación. En las Figuras 18 (a) y (b), para tráfico cursado autosimilar, el primer cuartil es un valor superior a cero, lo cual demuestra que la probabilidad de recibir un par de paquetes aumenta con tráfico cursado autosimilar. El tráfico autosimilar, a diferencia del tráfico de Poisson, cuando es agregado en diferentes escalas de tiempo presenta un comportamiento caracterizado por la presencia de ráfagas. Según los resultados obtenidos, este comportamiento aumenta la probabilidad de que un par de 9 paquetes atraviese la red sin resultar afectado por el tráfico cursado y por ello mejora ligeramente el desempeño de AdHocProbe en condiciones de alto tráfico. Para el escenario del nodo móvil, aunque la mediana de las estimaciones también coincide con tráfico cursado y

Figura 17. “Box plot” para las mallas con tráfico cursado autosimilar de parámetro H=0.95 en dirección horizontal (a) malla de 6x6, (b) malla de 7x7.

Figura 18. “Box plot” para las mallas con tráfico cursado autosimilar de parámetro H=0.95 en dirección horizontal y vertical (a) malla de 6x6, (b) malla de 7x7.


97

Figura 19. Mediana de la capacidad para el escenario del nodo móvil con tráfico cursado autosimilar y sin él. El eje horizontal es el tiempo de simulación.

Figura 20. “Box plot” del escenario del nodo móvil con tráfico cursado autosimilar correspondiente a 20 corridas. El eje horizontal es el tiempo de la simulación

sin él, igualmente se manifiestan los VI. CONCLUSIONES problemas en la estimación cuando AdHoc Probe es una herramienta de hay tráfico cursado en la red y cambia estimación de capacidad que funciona la longitud de la cadena que separa efectivamente, siempre y cuando al al nodo 0 del nodo 25. Este efecto se menos un par de paquetes de la mediobserva en la Figura 19 y especial- ción no resulte afectado por el tráfico mente en la Figura 20, pues aumenta cursado. La fortaleza de AdHoc Probe la dispersión en los instantes donde radica en que combina el concepto cambia el número de saltos y, por de dispersión y del mínimo retardo, ende, el ancho de banda de la ruta. esto último le da mayor precisión en

98


comparación con otras técnicas que utilizan solamente la dispersión para hacer la estimación. Se comprobó que la estimación de AdHoc Probe es independiente del tipo de tráfico cursado que exista en la red, pero la calidad de los resultados depende de la intensidad del tráfico cursado presente. Si la red se encuentra saturada, AdHoc Probe puede sobre-estimar o sub-estimar la capacidad de la misma. En las condiciones de estimación recomendadas en [4], es decir, usando 200 pares de paquetes y 4 pares por segundo, la estimación tomaría alrededor de 50 segundos. Si la red cambia su topología en este lapso, debido a nodos que se desplazan rápidamente, AdHoc Probe entregaría una estimación equivocada. Cuando existen nodos en movimiento, AdHoc Probe puede estimar la capacidad con algunas limitaciones. Si existe tráfico cursado en la red, le tomará más tiempo estimar la capacidad cuando cambie la cantidad de saltos que separan al transmisor y al receptor. Desde luego, cuando el escenario es dinámico la rapidez con la cual el protocolo de enrutamiento encuentre las rutas afecta o favorece la estimación de capacidad. A partir de los resultados obtenidos en este artículo se continúa trabajando en evaluar el impacto del tráfico autosimilar sobre la red. Así mismo se está trabajando en encontrar un algoritmo que permita afinar los dos parámetros para la estimación, es decir, el número de pares de paquetes y el intervalo entre pares. Sin embargo, es claro que en una red saturada es muy poco probable que la estima-

ción entregue un resultado preciso. También se está trabajando en una implementación que permita obtener simultáneamente la estimación de la capacidad máxima y mínima de un trayecto en una red ad hoc. BIBLIOGRAFÍA

[1] S. Saroui, P. K. Gummadi, S. D. Gribble. (2002). A fast technique for measuring bottleneck bandwidth in uncooperative environments. Presentado en IEEE INFOCOM. [2] R. Kapoor, L. Chen, M. Y. Sanadidi y M. Gerla. (2004). Capprobe: A simple and accurate capacity estimation technique. Presentado en ACM SIGCOMM. [3] V. Jacobson. Patchar: a tool to infer characteristics of internet paths. Disponible: ftp://ftp. ee.lbl.gov/patchar. [4] L. Chen., T. Sun., G. Yang, M.Y. Sanadidi y M. Gerla. (2005) AdHoc Probe: Path capacity probing in wireless ad hoc networks. Presentado en The first IEEE International Conference on Wireless Internet WICON. [5] J. Li, C. Blake, D. Couto, H. I. Lee y R. Morris. (2001). Capacity of ad hoc wireless networks. Presentado en ACM MobiCom. [6] S. Yin y X. Lin. (Marzo, 2005). Traffic self-similarity in mobile ad hoc networks. Presentado en The Second IFIP International Conference on Wireless and Optical Communications Networks WOCN. [7] C. Dovrolis, P. Ramanathan y D. Moore. “Packetdispersion tech-


99

niques and a capacity-estima- CURRÍCULOS tion methodology”. IEEE ACM María del Pilar Salamanca Azula, candidata a título de Magíster Transactions on Networking , 12, en Ingeniería Eléctrica de la (6), Dic. 2004. Universidad de Los Andes. In[8] V. Jacobson y M. J. Karels. (Sept. geniera Electricista (1996) de la 1988). Congestion avoidance Universidad Nacional de Colomand control. Presentado en ACM bia Sede Bogotá. Su experiencia SIGCOMM. se centra en la administración de redes de computadores, don[9] C. Dovrolis, P. Ramanathan de ha diseñado e implementay D. Moore. (2001). What do do soluciones de telefonía IP, packet dispersion techniques mensajería unificada, gestión measure? Presentado en IEEE de redes y seguridad informáINFOCOM. tica. Actualmente se encuentra [10] Scalable Networks Technologies. vinculada al GEST (Grupo de Investigación en Electrónica y http://www.scalablenetworks. Sistemas de Telecomunicaciocom nes) como investigadora en el [11] K Xu, M. Gerla y S. Bae. (2002). tema de estimación de ancho de How effective is the IEEE 802.11 banda en redes ad hoc. RTS/CTS handshake in Ad Hoc networks? Presentado en IEEE Néstor Misael Peña Traslaviña, Profesor Asociado, DepartaGlobecom. mento de Ingeniería Eléctrica [12] V. Paxson. “Fast, approximate de la Universidad de Los Ansynthesis of fractional Gaussian des. Ingeniero Eléctrico (1987), noise for generating self-similar Magíster en Ingeniería Eléctrica network traffic”. Computer Com(1989) y Matemático (1991) de la munications Review, 27, pp. Universidad de Los Andes. DEA en Telecomunicaciones (1994) y 5-18, Oct. 1997. Doctor en Tratamiento de Señal [13] Scalable Networks Technoloy Telecomunicaciones (1997) de gies, Qualnet 3.9 User’s Guide, la Université de Rennes 1 en asoOctubre 2005 cio con la École Nationale Supérieure des Télécommunications [14] V. Paxson y S. Floyd. “Wide-area de Bretagne (ENST Bretagne), traffic: The failure of Poisson Francia. Actual director del modeling”. IEEE/ACM TransGEST (Grupo de Investigación actions on Networking , 3, (3), en Electrónica y Sistemas de pp. 226-244, Junio 1995. Telecomunicaciones) de la Uni[15] J. C. López. Contribución al versidad de Los Andes. Sus áreas análisis del impacto de la code interés son el modelamiento rrelación en las prestaciones de electromagnético y desarrollo de estructuras y circuitos a muy redes de alta velocidad. Tesis altas frecuencias, y la ingeniería doctoral, Universidad de Vigo, de tráfico en redes de telecomu1999. nicaciones.

100


Impacts of mobility on wireless access to IPv6 networks Christian Lazo R., Roland Glöckler

Universidad Austral de Chile, Instituto de Informática, General Lagos 2086, Casilla 567, Valdivia, Chile {clazo,rolandglockler}@uach.cl



ABSTRACT

The project “AIRE 6 - Wireless Access to IPv6 Networks” generated a hot spot of wireless Internet access using Wi-Fi (IEEE 802.11 b/g) in a native IPv6 environment. The setup of the project enables end-to-end connectivity using global public addresses. By incorporating mobility mechanisms of Mobile IPv6 (MIPv6), it allows scenarios always-on with mobility functions. Client connections are managed with efficient AAA (Authentication, Authorization and Accounting) mechanisms that had to be developed for the project due to the absence of adequate solutions. Within the project administrable APs were enhanced with native IPv6 support. Among the results of the project is an analysis of the impacts on delay and data rates caused by client mobility in best effort environments. The results


obtained will help to improve technical conditions for the use of mobile Internet with the full potential of IPv6. KEYWORDS IPv6, AAA, WiFi, Mobility, Route Optimization, Mipv6

RESUMEN

El proyecto “AIRE 6 – gíreles Access to IPv6 Networks” generó una serie de hot spots utilizando tecnología WiFi (IEEE 802.11b/g) en un ambiente IPv6 nativo. LA configuración del proyecto habilita la conectividad extremo a extremo utilizando direccionamiento público global. Con la incorporación de mecanismos de movilidad del IP móvil versión 6 (MIPv6), se pueden tener escenarios “always-on” con funciones de movilidad. Las conexiones de los clientes se manejan SISTEMAS & TELEMÁTICA

101

con mecanismos eficientes de AAA (Authentication, Authorization and Accounting) que han sido desarrollados en el marco del proyecto debido a la ausencia de soluciones adecuadas. Dentro del proyecto, se mejoraron APs administrables con soporte IPv6 nativo. Entre los resultados expuestos en este trabajo, se encuentran el

102


análisis del impacto en el retardo y las tasas de transmisión causados por la movilidad del cliente en ambientes de mejor esfuerzo (best effort). PALABRAS CLAVE

MIPv6, AAA, WiFi, Movilidad, optimización de rutas. Clasificación Colciencias: A

1. INTRODUCTION

In these days of ubiquitous wireless network access, various wireless technologies have reached great popularity, some even in spite of their maturity problems. The availability of this kind of technology is a great help in spreading Internet even more. Setting up an access point (AP) in order to provide wireless network access to multiple clients is very easy and cheap nowadays. However, providing a secure access with valueadding features and controlling a group of access points, requires much more effort. Service providers create ever adapting business models around these technologies, and one of them for the use in public spaces are the socalled hot spots, which are zones covered by wireless access using a group of APs within a common administrative domain. Many of the techniques developed for those also have found their application in corporational or private networks, such as the AAA (Authentication, Authorization and Accounting) mechanisms to protect network resources and manage client connections. Every innovation comes hand in hand with new challenges. Apart from the general limitations of any traffic concentrator, there are requirements from services, applications and end users that can hardly be fulfilled with the commonly used communication protocols. First of all, there are many new types of applications such as Voice over IP (VoIP) or file transfer functioning in peer-to-peer (P2P) manner, requiring end-to-end (E2E) connectivity. It is common knowledge that IP addresses

in the Internet Protocol version 4 (IPv4) are scarce and generally for public services dynamic addressing schemes or private addressing in combination with Network Address Translation (NAT) are used. The mixture of those methods with other features such as security leads to a lot of problems because of the multitude and complexity of protocols and systems that are needed to circumvent the limitations. The use of wireless technologies creates the freedom to move around. If a client wants to maintain connectivity beyond the cover area of an individual access point, handover and mobility methods are needed. In order to maintain open IP based communication sessions, this means to maintain the communication 4-tuple of IP addresses and ports of the end points. In “Always-on” scenarios there shall be no interruption of service and everything has to happen transparently to the end user. There exist mobility extensions for IPv4, but they are not very efficient. As can be seen, in such scenarios there is an agglomeration of difficulties mainly based on the shortcomings of IPv4. Examining the capabilities of IPv6 [1], the designated successor of IPv4, substantial progress in this area can be seen. Addresses are plenty in IPv6 and there is no need of dynamic assignment or private addressing. This way, everybody receives a globally unique address and features such as E2E connectivity are no problem. Mobility in IPv6 [2] is more efficient and less complex than in IPv4. In combination with the addressing advantage, “always-on” features can easily be provided. SISTEMAS & TELEMÁTICA

103

The goal of the project “AIRE 6” [3] IP resides in layer 3. However, any was to generate hot spots of wire- management and control of an access less Internet access using Wi-Fi point uses upper layer protocols and (IEEE 802.11 b/g) in a native IPv6 thus needs IPv6 support. Due to the environment, i.e., no IPv4 address absence of commercially available is used in the testbed. One of the APs with IPv6 support, it was also paradigms was to use free software necessary to generate an AP supwherever possible. The setup of the porting IPv6 management during project enables end-to-end connectiv- the project. ity using global public addresses. By incorporating mobility mechanisms 2. TESTBED of Mobile IPv6 (MIPv6), it allows 2.1 Network layout scenarios always-on with mobility functions. During the project, an AAA During the project, a complete native mechanism based on a web portal and IPv6 network infrastructure was generated offering network access, routpacket filtering was developed. ing, web, file transfer (FTP), mail, To provide wireless connectivity in an name resolution (DNS) and tunnelIPv6 only environment is basically no ing services. The also implemented different than in IPv4, since all the RADIUS server was not used in the wireless functionality resides in layer final solution. Figure 1 below shows 2 of the OSI Reference Model, while the network layout of the testbed.

Figure 1. Testbed network layout.

2.2 Main network components The following are the main components of the network: The Router Chile-6Bone provides connectivity for the project networks and all other IPv6 networks in Chile

104


to the IPv6 world. It is an integrated router with IPv6 functionality already incorporated. It provides the network prefix 3FFE:400F:E001::/64 to the network ipv6.cl in which reside the project servers.

The WiFi access points using the wireless technology IEEE 802.11b/g were required to support management functions. Since there were no commercially available IPv6 capable products at the time, the multifunctional Linksys WRT54G was chosen, because it allows installing a Linuxbased distribution. This way it gives the opportunity to add and modify modules such as IPv6 support. We chose the distribution OpenWRT for its modularity and flexibility. The wireless clients may belong to any of the subnetworks ALFA (network prefix 3FFE:400F:EEEE:A::/64), BETA (network prefix 3FFE:400F: EEEE:B::/64) or GAMMA (network prefix 3FFE:400F:EEEE:C::/64). For common network services, there are IPv6 native DNS and FTP servers. The Router AIRE6 plays a key role in the project networks. It was generated of a standard Linux PC (Fedora Core 2) and assumes various functionalities: • For all three subnetworks it plays the role of Home Agent (HA). • As a router it advertises the network prefixes, its own address and its capabilities, such as HA. • For all successfully authenticated users, the firewall (packet filter) is opened for navigation. Traffic of other sources is restricted. The web portal in combination with the user database manages the firewall. The mobile node (MN) is a client of one of the subnetworks ALFA, BETA or GAMMA and uses the MIPv6 ser-

vices offered by the HA while residing in other IPv6 networks. 2.3 MIPv6 When an IPv6 node connects to an IPv6 network, it receives a router advertisement (to accelerate the process, it also may request one). The information contained in that message allows the node to autoconfigure [4] a globally valid unicast address.

However, if that node has open connections in which it used a different address, upon changing the address it will lose connectivity in those sessions. The Mobile IPv6 (MIPv6) protocol offers a mechanism that enables to transparently maintain those sessions and to be reachable for peers using both the current address and the original, so called “home address”. This way, a user can move freely from network to network and doesn’t have to bother about being reachable or losing connectivity. For the operating system Linux there is an implementation called “Mobile IPv6 for Linux” [5], which was used in the project. In order to make the concept work, the node that is moving around needs that a router in its “home network”, i.e., in the link that it considers its original location, provides it with sort of a proxy support. That router is called “Home Agent” (HA) and it receives all packets destined to the mobile node’s (MN) “home address”. It forwards them to the current address of the mobile node, the so-called “care-of-address”, using a tunnel between the HA and the MN. Packets in backward direction also use the tunnel and they appear to come from the


105

home address of the MN. If the peer of the communication, the so called “Correspondent Node“ (CN), also supports MIPv6, a route optimization can be used to communicate directly bypassing the HA and reducing the delay of the communication. The activation of this direct communication path is realized in parallel to the data communication through a correspondent registration procedure and thus delays in being setup. The tunnel for indirect delivery has to be created and maintained using bidirectional communication between the HA and MN. The MN tells in a periodic manner in a message called “binding update” to the HA, to which network link it is attached currently. While this is outside the home network, the tunnel between home address and care-of-address has to be maintained active, otherwise it is not needed. The HA notifies in its answer “binding acknowledgement” of the update of its register. While offering added value of transparent mobility, there is a cost in the delay of realizing the change of link, address auto-configuration, binding update, and tunnel modification. If the route optimization is not used, also each packet transmission has an increased delay due to the indirect delivery through the HA. The route optimization, in contrast, does allow efficient communication by using direct delivery, but needs some time to become effective. 2.4 AAA In wireless networks, captive portals are the predominant implementation of Network Access Servers. However, at the time those functionalities were

106


needed, there was no captive portal available with IPv6 support, and a simplified alternative solution was developed in the course of the project. In the implemented solution, a noncaptive web portal offers a form to enter username and password of a user. Upon clicking the “submit” button, a PHP script runs the mechanisms necessary to decide if the user will be granted access. In order to make the decision, first the script controls if all necessary technical parameters are complied (access control). For instance, only clients using IPv6 may be granted access. The authentication is verified by comparing the values entered in the form to the values stored in the user database which contains the information of registered users. In case of successful comparison, the user database might indicate a certain level of access to resources (authorization). In our project networks, there is only one kind of access, navigation to any IPv6 address. In order to avoid duplicate session initiation, a final check verifies that the user has not an open session yet with the same address. If all steps are passed successfully, the firewall is opened for the IPv6 address of the client and the session parameters are stored in a register. A new web page is loaded to show the user that he is granted access now and to offer him a button for the termination of his session. If any of the described steps results in a denial of access, the user will be notified in a new web page that he was denied access indicating the reasons. In the case of wrong user cre-

dentials, he will be given the chance to try again. An open session may be terminated by two ways. If the user clicks on the “logout” button, his session is terminated immediately. If he passes the time limit for his session, he is disconnected automatically. In both cases, the session register and the firewall settings are modified accordingly. This authentication process is quite similar to the ones used nowadays in commercial hot spots of ISPs all around the world. The big difference is that it works with IPv6 addresses. 3. EXPERIMENTS

The goal of the experiments was to examine the impacts of the mobility mechanisms on the performance of user connections. The setup for the experiments as shown in the chapter 2 contemplated a remote mobile user located in Spain, which resulted in quite a distance and latency to the servers and testbed in Chile. The IPv6 native interconnection uses the advanced academic backbone networks of Chile and Spain. The QoS parameters of the connections were best effort, similar to standard Internet ISP politics, resulting obviously in variations of the measurement results. All experiments save the last set were realized in two scenarios. The first measurement was taken without mobility mechanisms (indicated in red color in the graphs), the second measurement used mobility mechanisms (indicated in blue color in the graphs). In the last set, a third scenario using route optimization capabilities of MIPv6 was added (indicated in black color in the corresponding graph).

In the scenario without mobility, the autoconfiguration of the IPv6 address was enough to start generating traffic, so everything was automatic and transparent. Before generating traffic in the mobility scenario, it was necessary to terminate the activation of MIPv6 capabilities, the autoconfiguration of a local address in the MN, its registration as CoA in the HA and the application of the AAA mechanisms of the testbed, since traffic was to be generated via the home network. In the first series of measurements, the roundtrip time (RTT) of a ping with 256 bytes of payload was taken to a peer host (FTP server 3FFE:400F: E001::D) residing within the home network in Chile. Figure 2 shows the results. The red points correspond to the non-mobility scenario, the blue line to the mobility scenario. As can be seen, there is only little difference in RTT between the direct delivery and the indirect one using the mobility tunneling via HA. The small delay comes from the encapsulation process necessary for the mobility application in the MN in order to use the tunnel and the stripping of the additional header in the HA. A traceroute to the router AIRE6 (HA) for both cases leads to a similar result, but illustrates more clearly the path difference. The direct scenario uses 15 hops while the mobility scenario uses only one hop. However, the RTT is almost the same. Figure 3. The next measurement consisted of an FTP file transfer between MN and the FTP server of the home network. The file size was 5 MB. In the results, shown in figure 4 and 5, the similariSISTEMAS & TELEMÁTICA

107

Figure 2. RTT measurements of ping to home network.

Figure 3. RTT measurements of traceroute to home network.

Figure 4. Transfer rate measurements of file transfer from home network.

108


Figure. 5. Transfer time measurements of file transfer from home network.

ties to the case of ping and traceroute difference between the scenarios is clearly visible. The explanation for become obvious. The transmission time and rate are the much longer duration of the mobility scenarios is the delay caused by quite constant and there is little dif- the necessity to pass twice through ference between the two scenarios. transatlantic connections. In a second set of measurements, the A similar result can be appreciated peer was located close to the current in the measurement of traceroute location of the MN, namely in Europe shown in Figure 6. The number of (www.euro6ix.com). The results are hops in the mobility case is much shown in Figure 6. In this case the higher.

Figure. 6. RTT measurements of ping to network close to current link.


109

A third set of measurements used a connection to Japan (www.kame.net), which in regard of transmission time should lie more or less equidistant from the actual location of the MN in Spain and the tunnel end (HA) in Chile. In Figure 7, showing the

corresponding ping results for this case, it can be appreciated that the RTT is relatively constant. The difference between the non-mobility and the mobility case is huge, as could be expected.

Figure 7. RTT measurements of ping to Japan.

In Figure 8, showing the corresponding traceroute results for this case, one can clearly identify the first hop

(the tunnel) causing a great difference in the RTT.

Figure 8. RTT measurements of traceroute to Japan.

110


The last set of measurements was realized with a peer that also supported the MIPv6 protocol and that was located close to the current network link. This way, the route optimization capabilities could be used. In Figure 9 we can see in red and blue the results of the RTT of a series of pings representing the scenarios non-mobility and mobility without

route optimization. Representing the third scenario, in which the route optimization capabilities were activated in both the MN and CN, the black points show that after some initial activation time the route optimization begins to work. The improvement is substantial; with route optimization one can obtain the same RTT results as in a direct connection.

Figure 9. RTT measurements of ping to network close to current link using route optimization.

4. CONCLUSIONS

Both the second and the third set of measurements illustrated in this paper show clearly that the mobility mechanisms introduce a significant delay in the traffic. This can be mitigated by using Route Optimization features, which are only available if the correspondent node (CN) also supports the protocol MIPv6 and the MN allows for their use. Their necessity and effectiveness can be shown in the last set of measurements. However, the efficiency for shorttime connections has to be evaluated separately. In any case, without using route optimization, the only difference of MIPv6 to a manually setup IPv6-IPv6 tunnel between MN and

HA is the automation and transparency of the process. In summary, the efficiency of mobility depends largely on the support of the MIPv6 protocol by all communication partners thus allowing for Route Optimization. Its absence is a barrier in the adoption of mobility mechanisms. On the other hand, the proposed user validation mechanism provides a simple and lightweight procedure that could be applied in commercial hot spots by ISP. It would allow them to implant IPv6 into their networks without having to change the external network architecture. The only changes necessary, as shown in SISTEMAS & TELEMÁTICA

111

the development of this project, are the setup of a couple of machines in the administration core, realizing the mobility functions and the AAA mechanisms. The scheme could also perfectly be coupled to existing servers and databases in current networks using IPv6-IPv4 adaptation mechanisms and tunnels. This way it would generate new services and new business models and allow the faster adoption of the protocol IPv6. Mobility is a hot theme nowadays and it causes a lot of discussion in scientific and engineering circles all around the world. It can be seen that still large discussion and testing procedures are necessary to mature the mechanisms and make them efficient. Maybe even political decisions could prove useful, for example to make mobility extensions obligatory, so one could rely on the optimization techniques available. ACKNOWLEDGEMENTS

The authors would like to thank FRIDA (Fondo Regional para la Innovación Digital en América Latina y el Caribe) who has sponsored this research. www.programafrida.net BIBLIOGRAPHY

[1] S. Deering and R. Hinden, Internet Protocol, Version 6 (IPv6 Specification), IETF Request for Comments RFC 2460, December 1998; http://www.ietf. org/rfc/rfc2460.txt [2] D. Johnson, C. Perkins and J. Arkko, Mobility Support in IPv6, IETF Request for Comments RFC 3775, June 2004;

112


http://www.ietf.org/rfc/rfc3775. txt [3] ProjectAIRE6; www.programafrida.net/sp/proyectos/arie6_acceso_i nalambrico_a_redes_ipv6. html [4] S. Thomson and T. Narten, IPv6 Stateless Address Autoconfiguration, IETF Request for Comments RFC2462, December 1998; http://www.ietf.org/rfc/ rfc2462.txt [5] Mobile IPv6 for Linux; http://www. mipl.mediapoli.com/ CURRÌCULOS Ing. Christian Lazo R. es profesor

del área de redes del Instituto de Informática en la Universidad Austral de Chile. actualmente es candidato a Doctor en Ingeniería Telemática por la Universidad de Vigo en España, país donde reside. Su área de trabajo e investigación gira en torno al protocolo IPv6, redes móviles y la problemática de optimización de rutas e integración en redes heterogéneas. Roland Glöckler es Ingeniero Electrónico Diplomado y Master of Science en Tecnología de Información. Actualmente trabaja en la Universidad Austral de Chile (UACh), donde su área de trabajo es la convergencia de redes de comunicaciones. Su actividad de investigación se concentra en el proyecto “VOI6E – Voz sobre IPv6 en entornos inalámbricos”. También participó como co-investigador en el proyecto predecesor “Acceso Inalámbrico con Redes IPv6 (AIRE6)”.

Desarrollo de un software Web y Móvil para la gestión de información de campo de cultivos agrícolas (AgrocomM) Juan Manuel Delgado, Christian Giraldo

Mobilex - Parquesoft [email protected]

Andrés F. Millán, Claudia Zúñiga, José Abadía

Grupo de Investigación COMBA I+D Universidad Santiago de Cali [email protected]



ABSTRACT

This paper presents the state of art on agriculture software, specially software that make use of wireless connectivity and mobility in order to provide some benefits to producers and farmers. We explain the development process for agriculture software, developed by the authors and funded by SENA.


de campo agrícola, en especial el software que utiliza la conectividad inalámbrica y la movilidad para ofrecer beneficios a los cultivadores y productores agrícolas. Además se detalla el desarrollo de un software para este sector construido por la empresa Mobilex y el grupo de investigación COMBA I+D de la Universidad Santiago de Cali con la financiación del SENA.

KEY WORDS

Mobile computing, Java, mobile soft- PALABRAS CLAVE Agricultura de precisión, Java, comware, precision agricultura putación móvil, software móvil. RESUMEN Clasificación Colciencias: A Este artículo presenta el estado del arte del software para la información


113

1. INTRODUCCIÓN

Colombia como un país primordialmente agrícola, se enfrenta a los retos de la globalización, en especial al firmar acuerdos comerciales internacionales que exigen un alto nivel de competitividad externa en los sectores tradicionalmente importantes comercialmente como es el caso del sector agrícola. Por tal razón, los cultivadores y productores agrícolas colombianos han detectado la necesidad de optimizar sus procesos de precosecha, cosecha, recolección y distribución de productos derivados del campo. El Gobierno colombiano en cabeza del Ministerio de Agricultura y Desarrollo Rural afirma que negociaciones internacionales como el Tratado de Libre Comercio con los Estados Unidos abrirán nuevos mercados para la agricultura colombiana [1], pero reconoce que la única manera de generar las condiciones para aprovechar los nuevos mercados es realizando importantes inversiones en ciencia y tecnología [2]. Por otro lado, en esta nueva era de la información, el desarrollo de las tecnologías de la información y las comunicaciones han favorecido el mejoramiento de los procesos agrícolas, por ejemplo al facilitar la recolección de información en campo y la disminución en los costos de personal. Estos beneficios se han hecho más notorios al utilizar tecnologías que permiten movilidad y adaptación, dos características propias del trabajo agrícola. En la última década la investigación en computación móvil ha propiciado el desarrollo de sistemas inalámbricos de comunicaciones con mejor rendimiento y calidad de servicio, así como la construcción de plataformas de software móvil más amigables,

114


económicas y adaptables. Por este motivo se plantea el desarrollo de un software que utilice los más recientes avances en tecnologías móviles y de internet, como herramienta para la gestión de información en campo de cultivos agrícolas, con la hipótesis de que se pueden optimizar el tiempo, la exactitud de la información y los costos del proceso de campo agrícola cuando apoyamos esa labor con una solución informática Web y móvil que ofrece las ventajas de la movilidad de los dispositivos de mano y la ubicuidad de las aplicaciones Web. En Colombia algunas casas de software en el ámbito nacional e internacional han promovido el desarrollo de proyectos informáticos que beneficien el proceso de campo agrícola como AgroWin de InSoft Ltda.[3]; sin embargo, la mayoría de estas soluciones se basan en el manejo de la información de fincas agrícolas pequeñas y de poca complejidad. Por otro lado, la investigación reciente desarrollada en el campo de las tecnologías informáticas (TI) aplicadas en la agricultura han demostrado que los sistemas de información agrícolas futuros destacarán tres líneas de profundización: TI aplicada al proceso de producción, TI para el soporte de obtención de información y TI para soportar la logística [4]. Por esta razón las más reconocidas empresas desarrolladoras de sistemas de información agrícolas como BIOSALC [5] o ISAGRI [6] están trabajando en plataformas informáticas que solucionen esos tres grandes problemas, pero con altos costos y soporte fuera del país, lo cual hace asequible estas plataformas solo para grandes productores agrícolas. Por esta razón el grupo de investigación se propuso

el desarrollo de un software que ofreciera soluciones en una de estas líneas de trabajo como es TI para el soporte de obtención de información utilizando dispositivos móviles de mano con conectividad a redes móviles como GPRS y Wi-Fi. En especial cuando el Ministerio de Agricultura y Desarrollo Rural de Colombia lanzó en meses pasados el Plan Nacional para la implementación de buenas prácticas agrícolas [7] en el cual se define como una estrategia para el logro de los objetivos del plan, el desarrollo de sistemas de información para los actores del sector agrícola, en el cual se faciliten los procesos para el control, manejo de documentación y registros requeridos. Este artículo está dividido en tres partes, la primera detalla el estado del arte actual de los sistemas informáticos utilizados en el proceso de campo agrícola, luego se plantea el análisis y el diseño del software propuesto. La siguiente parte explica el proceso de construcción de los módulos del software para cumplir los requerimientos propuestos. 2. ESTADO DEL ARTE DEL SOFTWARE PARA GESTIÓN DE INFORMACIÓN EN CAMPO

El desarrollo de software para la gestión de información agrícola en campo ha evolucionado a la par de los avances en tecnología informática, primero fueron los sistemas digitales de mano desconectados, luego el apoyo de los sistemas de información geográfica (GIS) y más recientemente las aplicaciones y servicios móviles están ofreciendo alternativas innovadoras para la problemática de la obtención de información agrícola en campo. El futuro en este sector es aún

más importante como lo demuestran los proyectos que han hecho uso en el campo agrícola de sensores inteligentes y arquitecturas de servicios Web en ambientes distribuidos [8]. Las soluciones móviles y Web agrícolas para el campo varían en su alcance, capacidad de interoperabilidad y complejidad, por eso encontramos soluciones para pequeños granjeros como PocketPAM [9] o LandMark Farm [10] o plataformas móviles que coexisten con soluciones agrícolas robustas como el producto SIAP de Biosalc [5] o Agri-pocket de Isagri [6]. Sin embargo, el uso de arquitecturas Web es relativamente reciente y la mayoría de soluciones encontradas son aplicaciones de escritorio que no hacen uso de servicios Web, ni de internet. La Tabla 1 resume algunas de las soluciones móviles agrícolas existentes para la gestión de información en campo en el ámbito mundial. En Colombia el desarrollo de soluciones agrícolas móviles que hacen uso de servicios Web para la gestión de información agrícola en campo es escaso. No se conoce de soluciones comerciales, pero sí de prototipos desarrollados por centros de investigación como el CIAT[14] o instituciones educativas como la Universidad Nacional de Colombia Sede Palmira [15]. La revisión realizada de las soluciones móviles y Web agrícolas en el nivel nacional e internacional recalca la necesidad de construir una aplicación móvil y Web que apoye la gestión de información agrícola en campo en Colombia que permita la comunicación con otras plataformas agrícolas de escritorio, igualmente se establecieron requerimientos importantes para el desarrollo de este proyecto. SISTEMAS & TELEMÁTICA

115

Tabla 1. Algunas soluciones móviles agrícolas existentes para la gestión de información en campo en el ámbito mundial Nombre del producto

Empresa desarrolladora

País de origen

SIAP

BIOSALC

Brasil

FarmKeeper Mobile

FarmKeeper

Australia

Agri-Pocket

ISAGRI

Sitio en internet

www.biosalc.com.br [5]

www.farmkeeper.com [11]

Francia

www.isagri.com [6]

SO móviles soportados

Palm OS

Comunicación con SIAGRI. Lectura usando código de barras e infrarrojo. Arquitectura móvil desconectada. Seguridad y privilegios. Palm OS Comunicación con FarmKeeper de escritorio. Especializado en granjas ganaderas. Apoyo con mapas Windows CE Comunicación con aplicaciones de Palm OS ISAGRI. Lectura usando código de barras. Localización con GPS. Utiliza pantallas TFT para adaptarse a la luz ambiente. Soporte e instalaciones en toda Europa. Windows CE Comunicación con aplicaciones de Farm Works. Opcionalmente Localización con GPS.

Trac Mate Site Mate Stock Mate Guide Mate LandMark PDA

Farm Works Software

Estados Unidos

www.123farmworks.com [12]

iAgri

Estados Unidos

www.iagri.com [10]

Pocket Crops

MapShots

Estados Unidos

www.mapshots.com [13]

Windows CE

PocketPAM

FairPort Farm Software

www.fairport.com.au [9]

PalmOS Windows CE

Australia

Características principales

Palm OS

Aplicación para gestión financiera y actividades en granjas. Comunicación con LandMark del escritorio Comunicación con EASi Suite. Manejo de las operaciones, detalle de las operaciones e insumos. Soporta estándares Web como XML y COM Desarrollado por módulos como Cosecha_Diaria, Soporte_GPS, Stock_Campo entre otros

Una de las conclusiones más impor- cultivos y las cosechas, es importante tantes de la revisión del estado del para los cultivadores y productores arte es la exigencia de diseñar una agrícolas. La falta de información solución de software modular que en oportuna y confiable genera sistemas la primera versión dará importancia manuales con controles inadecuados a la información requerida para las en las labores de campo, lo que afecta actividades agrícolas en campo, pero directamente en la producción y la luego se introducirán soluciones baja calidad de la materia prima. informáticas móviles y Web para los Actualmente las empresas agrícolas problemas de transporte, logística y con mayor nivel de inversión tienen sistemas informáticos robustos en sus localización. plantas de producción, pero tanto las 3. ANÁLISIS Y DISEÑO DE UN empresas grandes como las pequeñas SOFTWARE DE GESTIÓN DE tienen un problema en común y es INFORMACIÓN DE CAMPO que no cuentan con base tecnológica AGRÍCOLA instalada en las zonas rurales donde La captura y manipulación de infor- se realizan las labores de cosecha, mación asociada a la producción, los esto se debe a las condiciones propias

116


de los terrenos y a las restricciones en cuenta esto, el equipo investigador técnicas y tecnológicas que allí se pre- en su primera fase realizó un análisis sentan. En pocos casos se ha intenta- de requerimientos muy detallado de do implementar sistemas de cómputo la mano de expertos de la labor de usando comunicaciones inalámbricas campo agrícola en varias empresas instaladas por el cosechador o produc- importantes del sector como el Ingetor agrícola, debido a que esta solu- nio Mayagüez [16], posteriormente se ción presenta algunas desventajas aplicó una metodología para modelar como el poco conocimiento que tienen un sistema que fuera eficiente y óptilas personas que laboran en campo mo al usuario, además usable, práctisobre estas tecnologías, sumado a la co y que pudiera interactuar con las gran inversión que representa tener plataformas informáticas existentes computadores, antenas y servicios en la programación y control del camde conexión dedicados por cada finca po agrícola como SIAGRI. o hacienda donde se tienen cultivos. Por esta razón la mayoría de em- 3.1 Metodología utilizada presas del sector agrícola realizan La metodología que se empleó utila captura de información en campo lizó lo mejor de las técnicas de la de forma manual, esta información metodología clásica de software, recopilada semanal o quincenalmente realizando una mezcla entre RUP no es actualizada y generalmente se (Rational Unified Process) y XP (Expresenta en formatos poco legibles treme Programming). En la etapa que son digitados en un sistema de de análisis se emplearon diagramas cómputo ubicado a una larga distan- de casos de uso, diagramas de clases cia de las fincas donde se realiza el y distribución; en la etapa de diseño cultivo y la cosecha o viceversa cuan- se emplearon las historias de usuado la información debe ser enviada a rio, planes de pruebas de unidad, los dispositivos en campo, generando codificación y pruebas de aceptación, que los tiempos de respuesta sean estas últimas con la colaboración de muy extensos e inadecuados, causan- la empresa Green SQA para lograr do que los entes administrativos o de un aseguramiento de la calidad del campo no tomen decisiones oportunas software durante todas las etapas del que optimicen el desarrollo de las la- desarrollo del software. bores, afectando así los costos totales del proceso. 3.2 Arquitectura del software AgroComM no se concibió como un AgroComM es un software para la software a la medida sino como una gestión de información de campo plataforma informática flexible y agrícola, que permite la asignación adaptable a empresas agrícolas en y control de actividades a través de sectores diversos como el azucarero, valoraciones y registro de inconsispanelero, algodonero y de palma tencias. AgroComM está dividido africana, entre otros. El objetivo fue en tres módulos: uno de captura de satisfacer las necesidades de los dis- datos para dispositivos móviles, uno tintos clientes con la mínima canti- Web y uno de conexión, transferencia dad de cambios mediante un software y sincronización de datos. El módulo totalmente parametrizable. Teniendo de captura de datos permite ingreSISTEMAS & TELEMÁTICA

117

sar toda la información relacionada con evaluaciones de campo (cosecha, quema, corte, transporte, maleza, insumos, plaguicidas, fertilizantes, etc.) e inconsistencias haciendo uso de un dispositivo móvil. El módulo Web permitirá la gestión y asignación de las actividades de campo, así como las consultas necesarias sobre la información registrada desde una estación conectada a internet. El módulo de conexión, transferencia y

sincronización será el encargado de realizar la transmisión de los datos capturados en el dispositivo a un sistema de base de datos residente en una estación de trabajo. Esta transmisión se puede realizar conectando el dispositivo móvil directamente a la estación usando ActiveSync o conectándose a través de red inalámbrica IP como GPRS o Wi-Fi. La Figura 1 muestra en detalle la arquitectura del software.

Figura 1. Arquitectura AgroComM.

El patrón utilizado para la arquitectura del software es el denominado “Modelo, Vista, Control (MVC)” [17]. La arquitectura MVC (Model/ View/Controller) fue diseñada para reducir el esfuerzo de programación necesario en la implementación de sistemas múltiples y sincronizados de los mismos datos. Sus características principales son que el Modelo, las Vistas y los Controladores se tratan como entidades separadas; esto hace que cualquier cambio producido en el Modelo se refleje automáticamente en cada una de las Vistas. El Modelo es el objeto que representa los datos

118


del programa, los maneja y controla todas sus transformaciones, no tiene conocimiento específico de los Controladores o de las Vistas, ni siquiera contiene referencias a ellos. Es el propio sistema el que tiene encomendada la responsabilidad de mantener enlaces entre el Modelo y sus Vistas, y notificar a las Vistas cuando cambia el Modelo. La Vista es el objeto que maneja la presentación visual de los datos representados por el Modelo. El Controlador es el objeto que proporciona significado a las órdenes del usuario, actuando sobre los datos representados por el Modelo,

cuando se realiza algún cambio, entra en acción, bien sea por cambios en la información del Modelo o por alteraciones de la Vista, e interactúa con el Modelo a través de una referencia al propio Modelo. 4. DESARROLLO DE UN SOFTWARE WEB Y MÓVIL PARA LA GESTIÓN DE INFORMACIÓN DE CAMPO AGRÍCOLA

AgroComM cuenta con una plataforma móvil (Figura 2) desarrollada en C# con un sistema de bases de datos en SQL Server Mobile, también se usan esquemas XML para optimizar

Figura 2. Plataforma móvil de AgroComM.

el almacenamiento de datos entre el aplicativo móvil y la base de datos móvil. La plataforma Web (Figura 3) se desarrolló en ASP.NET con una base de datos SQL Server, el equipo desarrollador eligió esta base de datos para el sistema teniendo en cuenta que es adecuada en un entorno que requiere de un alto desempeño y permite actualizaciones constantes de registros sin que se sacrifiquen los recursos de la máquina. Una ventaja de utilizar la misma base de datos en su versión de escritorio y en la versión móvil es que se logra mayor integración, mejor rendimiento y confiabilidad en la aplicación web - móvil.

Figura 3. Plataforma Web de AgroComM.

La información capturada en la plataforma móvil, es transmitida a la plataforma web que usualmente estará ubicada físicamente en la planta o en las oficinas de la fábrica. Para la transmisión de datos, el sistema presenta al usuario dos opciones: off-line y on-line. La opción off-line implica almacenar la información en

la base de datos del dispositivo móvil hasta que ésta pueda ser transmitida a la base de datos central por medio inalámbrico o físico (USB), y esta es la alternativa más viable para la transmisión de información pues es de bajo costo y no requiere una conexión de comunicaciones permanente. La alternativa on-line permite


119

la transmisión de información de campo en línea, es decir, la actualización de la base de datos central de forma simultánea haciendo uso de una red celular GSM/GPRS o una red inalámbrica local. Una ventaja importante de la aplicación al usar GPRS es la tarificación por parte del operador de telefonía celular, donde sólo se factura por la información transmitida y no por el tiempo de conexión. Esto hace posible tener una aplicación en la que un dispositivo móvil se conecta a la red y permanece conectado durante un periodo prolongado, sin que ello afecte en gran medida el valor facturado; sin embargo, si no existe cobertura celular en algunas zonas rurales, AgroComM ofrece la alternativa off-line. Para ambos casos off-line y on-line siempre se deberá realizar un proceso de sincronización de datos. 4.1. Sincronización AgroComM Sincronizar datos entre un dispositivo móvil y una base de datos localizada remotamente demanda un análisis profundo sobre las diferentes técnicas de sincronización disponibles en una determinada plataforma de desarrollo, cuáles son las ventajas y desventajas que aportan cada una de estas técnicas al desarrollo de un proyecto y en qué aspecto resulta más óptimo utilizar una u otra. El desarrollo de AgroComM se basó en la plataforma de desarrollo de Microsoft.NET, la cual presenta dos alternativas al momento de efectuar una sincronización de datos: Merge Replication y Remote Data Access (RDA) [18]. El proceso de sincronización, cualquiera que sea el método utilizado, maneja la misma arquitectura, se requiere de una base de datos remota, una base de datos local y un canal de comunicación.

120


Revisando a grandes rasgos los métodos de sincronización, se observa que Merge Replication proporciona un gran mecanismo de resolución de conflictos, haciendo uso de Triggers, Store Procedures, etc., los cuales automatizan los procesos de sincronización; RDA por el contrario ofrece una mayor escalabilidad a los posibles cambios realizados en los clientes móviles. RDA permite mantener la sincronización entre una base de datos en un dispositivo móvil y una base de datos remota, sin necesitar una conexión constante (este tipo de conexiones se denominan Loosely coupled connection). Una vez que se han recuperado los datos del servidor remoto, éstos son almacenados y tratados en el dispositivo móvil mediante el motor de SQL CE. Los datos almacenados, así como sus cambios e inserciones, pueden ser llevados de nuevo al servidor remoto. Para mantener una base de datos del cliente actualizada, se realiza el proceso en tres pasos: • Pull

• Obtener datos del servidor (online). • Se obtienen los datos seleccionados mediante una consulta en SQL. • Crea una nueva tabla local. • Manipular los datos en el dispositivo (offline) • Agregar, modificar, borrar y consultar datos. • Push • Envía las modificaciones realizadas al servidor.

De otro lado Merge Replication es una técnica que aporta autonomía e independencia al dispositivo a la vez que facilita el sincronismo de los datos cuando desean ser volcados al servidor. Dentro de esta técnica se deben distinguir dos miembros: los Publicadores y los Subscriptores. Los Publicadores envían los datos y éstos son recibidos por los Subscriptores; en el caso de AgroComM, el Publicador es la base de datos remota, y el Subscriptor es la base de datos del dispositivo móvil. En un entorno real, los datos tanto en local como en la base de datos cambian con el tiempo; empleando este modelo, la sincronización de los datos se realiza tanto en el servidor remoto como en los clientes, recuperando datos nuevos o las modificaciones de los datos existentes. Dada la naturaleza del proyecto AgroComM, en el cual se hace uso de una red GPRS y de una conexión física del dispositivo con el servidor, se consideró la posibilidad de utilizar

ambas técnicas de sincronización, no simultáneamente, pero sí en los escenarios y momentos en donde cada una nos puede brindar su mejor desempeño. Cuando el usuario móvil realiza la primera sincronización o la reanudación de la misma por el cambio de usuario, se lleva a cabo una conexión de datos con el servidor, este proceso requiere la utilización de una técnica que garantice un óptimo desempeño además del control de conflictos, de igual manera las actualizaciones por vía GPRS necesitan un filtro de información que garantice la mayor optimización del canal. Es precisamente en este escenario donde la sincronización por Réplica o Merge Replication se ajusta idealmente. Sin embargo, parte del proceso inicial de sincronización incluye la validación de usuarios; esta es una consulta a la base de datos remota y se realiza en un solo sentido (PULL). En este proceso es muy importante la velocidad, y dado que es un solo sentido, RDA cumple cabalmente estas expectativas.

Tabla 2. Ventajas y desventajas en Merge Replication. Ventajas

Desventajas

La replicación posee características para resolver los conflictos de sincronización. Permite la sincronización de datos de múltiples tablas en ‘un tiempo’. En RDA esto no era posible, únicamente se hacía un Pull del conjunto de datos a traer. Permite el monitoreo de cada publicación. A diferencia de RDA, la replicación es bidireccional. Tanto el servidor como el cliente son sincronizados y actualizados. No es necesario borrar las tablas del cliente. Resolución de conflictos automática.

La replicación crea una cantidad de carga notable en el servidor. Cuando una base de datos se agrega como Publicador, la Metadata de dicha base de datos es modificada creando diversos Disparadores y Procedimientos almacenados para facilitar la sincronización y la resolución de conflictos. A todas las tablas replicadas se les añade un ROWDGUIDCOL con el fin de mantener las tablas sincronizadas y capacitar a las filas de un identificador único. Esta nueva columna en la tabla causa un aumento del tráfico y del tamaño de la memoria, por ejemplo en una tabla con únicamente 32 registros, el aumento al añadir el ROWDGUIDCOL es de 1kb = (16 bytes en el registro + 16 bytes en el índice) * 32.

5. CONCLUSIONES Y PROYECTOS FUTUROS

El presente proyecto permitió descubrir las grandes necesidades que

tienen los cultivadores y productores agrícolas en Colombia en cuanto a la gestión de información en campo, en especial al tener que afrontar en los SISTEMAS & TELEMÁTICA

121

próximos años los desafíos de la globalización y los acuerdos comerciales multilaterales que promueven una alta competitividad. Los altos costos de personal, la pérdida de calidad en la materia prima, los sobrecostos por retrasos en los procesos de cosecha y transporte y el mal manejo de la información disponible son razones de peso para que los cultivadores y productores agrícolas identifiquen cómo las tecnologías informáticas pueden contribuir a un proceso óptimo que los haga más competitivos en los mercados mundiales. El grupo de desarrollo pudo constatar las ventajas y desventajas que tiene la plataforma.NET en los ambientes móviles y Web considerando aspectos tan relevantes como la sincronización de datos, la transmisión de datos vía redes inalámbricas y el diseño arquitectónico de una solución Web-móvil. Dentro de los beneficios se destaca la rapidez en el proceso de desarrollo, el buen entorno de interface usuario y el rendimiento del sistema de sincronización, sin embargo aspectos claves como la interoperabilidad entre los sistemas operativos móviles de Microsoft con la plataforma de desarrollo.NET deben ser sujeto de revisión. El grupo de investigación compuesto por Mobilex como empresa desarrolladora y de COMBA como equipo consultor, demostraron que es factible la realización de proyectos comerciales en conjunto con grupos de investigación científica que desean promover la innovación tecnológica en Colombia. Estos proyectos fortalecen la capacidad investigativa de los grupos de investigación y permiten generar soluciones actualizadas e

122


innovadoras a los emprendedores de empresas de base tecnológica. COMBA en conjunto con MobilEx continuará desarrollando soluciones para el sector agrícola colombiano como son los módulos de transporte, logística y localización usando dispositivos móviles así como la realización de un proyecto piloto en Colombia que permita el uso de sensores inteligentes en campo cuya información pueda ser coleccionada automáticamente usando tecnologías inalámbricas y aplicaciones Web. BIBLIOGRAFÍA

[1] Arias, Andrés. “El TLC y nuestra agricultura”. Ministerio de Agricultura y Desarrollo Rural. Colombia. 2005. [2] Arias, Andrés. “Inversión en ciencia y tecnología en el campo”. Ministerio de Agricultura y Desarrollo Rural. Colombia. 2006. [3] Producto AgroWin. www.agrowin. com. 2006. [4] Kuhlman, Friedrich. “IT Applications in Agriculture: Some Developments and Perspectives”. Institute of Agricultural and Food Systems Management. 2006. [5] Página Principal de BIOSALC. www.biosalc.com.br [6] Página Principal de ISAGRI. www.isagri.com [7] “Plan Nacional para la implementación de buenas prácticas agrícolas”. Ministerio de Agricultura y Desarrollo Rural. Colombia. 2005. [8] Chaudhary Sanjay et al. “Architecture of Sensor based Agri-

cultural Information System for Christian Libaniel Giraldo es Effective Planning of Farm AcIngeniero de Sistemas y Telemátivities”. Proceedings of the 2004 tica de la Universidad Santiago IEEE International Conference de Cali. Director de Desarrollo on Services Computing. IEEE en Mobilex S.A. Investigador Computer Society. 2004. Asistente del Grupo de Investigación COMBA I+D. [9] Producto PocketPAM. Fairport Farm Software. www.fairport. Andrés Felipe Millán es Ingeniero com.au. 2006 de Sistemas de la Universidad Icesi de Cali. Máster en Siste[10] Producto LandMark Farm. iAgri mas de Redes y Comunicaciones Software. www.iagri.com. 2006 de la Universidad Politécnica de [11] Producto FarmKeeper Mobile. Madrid España. Actualmente se FarmKeeper. www.farmkeeepencuentra realizando el Doctoer.com. 2006 rado en Ingeniería Telemática en la Universidad de Vigo en [12] Farm Works Software. España. Profesor titular de la www.123farmworks.com. 2006. Universidad Santiago de Cali. [13] Pocket Crops. MapShots. www. Jefe del Área de Redes y Telemapshots.com. 2006. mática de la Facultad de Ingeniería de la Universidad Santia[14] Centro Internacional de Agriculgo de Cali, Director del Grupo tura Tropical. www.ciat.cgiar. de Investigación COMBA I+D. org. 2006. Presidente del Capítulo Valle [15] Universidad Nacional de Code la ACIS Colombia. Miemlombia – Sede Pamira. www. bro Fundador del Consorcio de palmira.unal.edu.co. 2006 [16] Investigación en Computación Ingenio Mayagüez. www.ingeMóvil - I2COMM. niomayaguez.com. 2006. Claudia Liliana Zúñiga es Ingenie[17] Burbeck, Steve. “Application ra de Sistemas y Telemática de programming in Smalltalk- 80: la Universidad Santiago de Cali. How to use Model-View-Con Actualmente se encuentra realitroller (MVC)”. University of zando el Doctorado en Ingeniería Illinois. 1992. Telemática en la Universidad de Vigo en España. Docente [18] Zorrilla, Unai. “RDA & Merge Investigadora de la Universidad Replication”. MSDN LatinoaSantiago de Cali. Investigadora mérica. Microsoft. Principal del Grupo de Investigación COMBA I+D. Coordinadora CURRÍCULOS del SIG de Desarrollo Móvil de Juan Manuel Delgado es Ingeniero COMBA I+ D de la Universidad de Sistemas de la Universidad Santiago de Cali. Miembro FunSan Martín. Gerente de Mobilex dador del Consorcio de InvestiS.A. Investigador Asistente del gación en Computación Móvil Grupo de Investigación COMBA - I2COMM. I+D. Docente SENA. SISTEMAS & TELEMÁTICA

123

José Lisandro Abadía es Estudiante de décimo semestre de Ingeniería de Sistemas y Telemática de la Universidad Santiago de Cali. Investigador Asistente del

124


Grupo de Investigación COMBA I+D. Vicepresidente de la Rama Estudiantil IEEE de la Universidad Santiago de Cali.

Evaluación experimental de la capacidad de IEEE 802.11b para soporte de VoIP* Guefry Leider Agredo Méndez

Miembro IEEE. Grupo I+D Nuevas Tecnologías en Telecomunicaciones

Jaime Andrés Gaviria Molano

Miembro IEEE. División de Tecnologías de Información y Comunicación Universidad del Cauca, Popayán – Colombia Universidad d el Cauca, Popayán – Colombia { gagredo,jgaviria}@unicauca.edu.co




ABSTRACT

KEYWORDS

Wireless LAN have been widely deployed worldwide using Technologies based on 802.11b/g standards mainly. But, those networks do not provide any support for QoS demanding services because the most of them were deployed before the 802.11e standard. However, in many places the need for QoS demanding services, like Voice over IP, has aroused and it is important to establish how those services will behave in Non QoS supporting WLAN’s. This papers shows experimental results for a testbed, intended to establish the capacity of a legacy 802.11 LAN to support VoIP services.

MAC, DCF, QoS, VoIP, Wireless LAN, 802.11, ITG, Asterisk

*

RESUMEN

A la fecha existe gran cantidad de redes inalámbricas de área local implementadas a nivel mundial sobre los estándares 802.11a/b/g pero que no proveen ningún tipo de control o acciones para ofrecer QoS puesto que son previas a la generación del actual 802.11e. Sin embargo, en varios de estos lugares se ha visto la necesidad de realizar la transmisión de VoIP sobre estas redes y es muy importante conocer los resultados que se obtienen al evaluarlo de forma experimental

Manuscrito presentado ante i2Comm 2006. Este trabajo fue financiado en parte por Unicauca en el marco de desarrollo de la Maestría en Ingeniería.


125

teniendo en cuenta una gran cantidad de factores que no se pueden tener en escenarios de simulación. En este artículo se presentan los resultados de evaluar de forma experimental la capacidad de 802.11b para soportar comunicaciones de VoIP; para tal efecto se realizó la verificación de dos formas, usando el generador de tráfico ITG y haciendo la generación de llamadas reales usando la PBX VoIP Asterisk. Como resultado, se encontró que lo obtenido por ambas vías fue en general coincidente y que en las redes inalámbricas sin ningún tipo de manejo de QoS el principal limitante en la capacidad y en el número de llamadas concurrentes es la contienda por el acceso al medio y no tanto el tipo de códec usado y/o el ancho de banda que consume cada llamada. Al final se pueden observar los resultados resumidos en tablas, que

126


muestran la máxima cantidad de llamadas sin degradación de la calidad para cada códec usado. Se concluye también que en una red 802.11b la capacidad de canales de VoIP no puede calcularse ni aproximarse con una simple división entre ancho de banda total y ancho de banda por canal, sino que deben considerarse más factores, pues, lo que se observa inicialmente es una degradación cuasi-exponencial al aumentar el número de comunicaciones hasta cierto punto y luego se tiene una degradación abrupta que incluso hace caer las demás comunicaciones de voz que se estén realizando en ese momento. PALABRAS CLAVE

MAC, DCF, QoS, VoIP, Wireless LAN, 802.11, códecs, ITG, Asterisk Clasificación Colciencias: A

I. INTRODUCCIÓN

Las redes inalámbricas IEEE 802.11[1], conocidas también con el nombre comercial de Wi-Fi[2], se han convertido en las redes de datos inalámbricas con mayor tasa de penetración a todos los niveles: público (Hotspots), empresarial, SoHo y en el hogar; inclusive y como aspecto relevante esta tecnología ha hecho viable la comunicación de datos y voz a zonas rurales [3] y el establecimiento de comunidades inalámbricas. Esta tendencia ha despertado el interés en la fabricación de dispositivos para redes inalámbricas, tales como televisores, DVD, consolas de videojuegos y otros. De esta forma se hace evidente la necesidad de contar con esquemas de calidad de servicio (QoS) que permitan que flujos de audio y video generados desde un DVD o computador puedan ser fácilmente distribuidos a televisores, equipos de sonido o parlantes en cualquier lugar del hogar. Así, la tecnología de las redes IEEE 802.11 se convierte en la tecnología inalámbrica de preferencia para el transporte de estos tipos de información debido principalmente a dos factores claves: sus relativas altas tasas de transferencia de datos y su carácter dominante en el mercado. Avances recientes en la familia IEEE 802.11, especialmente la finalización de la norma IEEE 802.11e, han generado el marco propicio para la consolidación del rol de 802.11 en las aplicaciones de Voz sobre IP. 802.11e; es una extensión a los estándares 802.11a/b/g para proporcionar soporte de calidad de servicio (QoS) a aplicaciones de tiempo real o de contenido sensible a retardo tales como voz y video. La norma IEEE 802.11e

introduce la función de coordinación híbrida (HCF, Hybrid Coordination Function) como el esquema de control de acceso al medio. Esta especificación es compatible con los sistemas tradicionales de las redes 802.11, esto es: la función de coordinación distribuida (DCF, Distributed Coordination Function) y la función de coordinación puntual (PCF, Point Coordination Function) A pesar de lo anterior, la norma IEEE 802.11e no se encuentra disponible en las instalaciones actuales de redes inalámbricas ni en los dispositivos móviles idóneos para la transmisión de VoWLAN como PocketPC y PALMS, por lo que resulta interesante evaluar la capacidad de estos sistemas, para soportar comunicaciones de voz con diferentes códecs usando redes inalámbricas 802.11b. Un paquete típico de VoIP consta de 40 Bytes conformados por los encabezados IP/UDP/RTP y una carga útil de entre 10 y 30 bytes, lo que depende del códec que se utilice. Por tanto, la eficiencia en el nivel IP para VoIP es menos del 50%. En el nivel físico y en el de enlace de 802.11, la pérdida de eficiencia aumenta, así por ejemplo, para el códec de GSM, con una carga útil de 33 bytes, el tiempo de transmisión a 11 Mbps es 33x8/11=24µs y el tiempo de transmisión para el encabezado IP/UDP/RTP de 40 bytes es 40x8/54=29µs. Sin embargo, estos niveles tienen una carga adicional de más de 800µs, atribuida al preámbulo de nivel físico, al encabezado MAC, al tiempo de contención, a la espera de ACK y al intercambio entre transmisión y recepción. Como resultado, la eficiencia general cae aproximadamente al 30%. SISTEMAS & TELEMÁTICA

127

En una WLAN empresarial o en Hots pots públicos, el soporte de VoIP se torna aún más complicado, dado que se requiere el soporte simultáneo de otras aplicaciones aparte de VoIP. La necesidad de atender este tipo de escenarios limita el número de sesiones de VoIP posibles. II. CALIDAD DE SERVICIO

“Calidad de Servicio (QoS, Quality of Service) se refiere a la capacidad de la red para proporcionar un mejor servicio a tráfico seleccionado de varias tecnologías de red. QoS procura que el tráfico de tiempo real de aplicaciones multimedia y de voz reciba la más alta prioridad, el mayor ancho de banda y el menor retardo en comparación con el tráfico de datos considerado como de ‘al mejor esfuerzo’ ”. [4] Las tecnologías de calidad de servicio proporcionan la base para el éxito de las aplicaciones multimedia y de voz y para el contexto de este trabajo especialmente en el escenario inalámbrico. Esta calidad está determinada por factores como: • Retardo (Latencia): cantidad de tiempo que le toma a un paquete alcanzar al receptor luego de ser enviado por el transmisor. También se conoce como retardo de extremo a extremo. • Jitter: diferencia en el retardo de extremo a extremo entre varios paquetes. • Pérdida de paquetes: medida comparativa de los paquetes transmitidos y recibidos exitosamente con respecto al total de paquetes transmitidos. Uno de los roles de la calidad de servicio es mantener el retardo, el jitter

128


y las pérdidas de paquetes para los tipos de tráfico seleccionados dentro de límites aceptables. Los requerimientos que se deben cumplir cuando se trabaja con voz sobre IP son: • Retardo máximo en un sentido no mayor de 150 ms (de acuerdo con la recomendación ITU-T G.114). Sin embargo, es importante considerar que los usuarios normalmente notarán los retardos de la voz si estos en viaje redondo sobrepasan los 250 ms [5]. • Pérdida de paquetes mínima: VoIP no es tolerante a las pérdidas de paquetes, aun con un 1% de paquetes perdidos se puede degradar enormemente una comunicación de voz así se esté utilizando el códec G.711, en caso de utilizar códecs con mayor tasa de compresión la pérdida es prácticamente intolerable [5] [6]. • El jitter promedio no debe ser mayor que 30 ms [5], aunque algunos autores hablan de hasta 50 ms [7][8]. Partiendo de lo anterior, para establecer la capacidad de la red inalámbrica para soportar llamadas de VoIP se tomaron los límites anteriores, y si al realizar una llamada adicional se sobrepasaba la pérdida de paquetes, el retardo o el jitter, se consideraba que se había logrado establecer la capacidad para cada códec. III. MECANISMOS DE ACCESO EN 802.11

802.11 trabaja dos mecanismos de acceso al medio, uno obligatorio conocido como DCF (Distributed Coordination Function) y otro opcional conocido como PCF (Point Coordina-

tion Function). El segundo método rara vez es implementado en equipos del mercado, y tampoco está presente en los equipos usados en este laboratorio. Por este motivo sólo se cuenta con el esquema DCF que se describe a continuación. DCF trabaja en un esquema “revisarantes_de-enviar”, basado en CSMA (Carrier Senses Multiple Access). Cualquier estación primero detecta si existe alguna transmisión en curso en el medio inalámbrico (revisa), y solamente cuando lo encuentra libre puede transmitir (envía). Sin embargo, si dos estaciones detectan libre el medio al mismo tiempo, podría ocurrir una colisión. Por esto, 802.11 define un mecanismo para “evitar la colisión”, por medio del cual todos deben esperar un tiempo aleatorio antes de enviar para evitar colisiones, de esta forma cada estación debe desarrollar un procedimiento de backoff antes de iniciar, así, cada estación debe permanecer escuchando el medio por un intervalo aleatorio con una duración mínima de un DIFS (DCF Inter Frame Space) luego que ha detectado el medio libre. El tiempo de backoff se escoge en el intervalo (0, CW-1) conocido como la ventana de contención ( Contention Window); ésta consta de dos parámetros CWmin y CWmax. Inicialmente el número aleatorio está entre 0 y CWmin. Si el backoff original expira antes de que pueda enviarse la trama, el contador se aumenta y el tamaño de la ventana de contención se dobla. Esta situación continúa hasta que se alcance el CWmax. Los reintentos continúan hasta que se venza el tiempo de vida de los paquetes (TTL). Luego de cada transmisión exitosa

de una trama, la estación receptora devuelve un reconocimiento (ACK) inmediatamente. Si luego del envío de una trama no se recibe el ACK se asume que la transmisión no ha sido exitosa. IV. MONTAJE DEL SISTEMA

Para el montaje del sistema y ante la necesidad de aproximarse a un entorno de operación real, se realizó el montaje tal como se indica en la Figura 1, en donde se contó con seis clientes conectados inalámbricamente a un punto de acceso y éste a su vez conectado por su interfaz ethernet a 100Mbps con el servidor de VoIP. Se trabajó en un ambiente heterogéneo en cuanto a modelos y marcas de equipos que trabajan con 802.11b, así mismo los computadores usados tuvieron diferentes características hardware y ubicación en el laboratorio. El sistema operativo usado fue GNU/Linux, en dos distribuciones: Ubuntu y RedHat. En las Figuras 2 y 3 se muestran fotografías de la infraestructura utilizada. La descripción de la infraestructura se resume en la Tabla I. Como se aprecia en la Figura 1, el servidor de VoIP se encuentra conectado por medio cableado al punto de acceso y no conectado inalámbricamente, pues es el caso típico de una implementación real, ya que es poco frecuente que dos estaciones asociadas al mismo punto de acceso requieran una comunicación de voz entre ellas. Las llamadas generalmente van hacia otra red, o a la misma red pero a un equipo asociado a otro punto de acceso. En cuanto a los dispositivos inalámbricos, se contó con equipos 802.11b y


129

Figura 1. Laboratorio montado.

Figura 2. Infraestructura de laboratorio utilizada.

Figura 3. Equipo cliente usando Softphone, Asterisk e Iptraf.

130


Tabla I. Descripción de la infraestructura utilizada. Equipo/ Características

CPU

Memoria

Red

Sistema operativo

Software

Dirección IP

Cliente1

Pentium M – 1.5Ghz

512MB

BroadCom Wireless

Debian GNU/Linux 3.1

Asterisk PBX 1.0.9 - ITG

192.16 8.1.100

Cliente2

Pentium 4 – 2.6Ghz

512MB

Dlink / Atheros Wireless

Ubuntu GNU/Linux 5.03


192.16 8.1.101

Cliente3


512MB

Dlink / Atheros Wireless



192.16 8.1.102

Cliente4

Pentium 3 – 800Mhz

128MB

3COM PCMCIA Wireless



192.16 8.1.103

Cliente5


128MB

DLINK AP2100 Wireless Client Mode

Linux RedHat 9.0


192.16 8.1.104

Cliente6


128MB

DLINK AP2100 Wireless Client Mode



192.16 8.1.105

Servidor VoIP


512MB

Atheros Wireless



192.16 8.1.2

Punto de Acceso Linksys WRT54G

BCM330 2 – 216 Mhz

16 MB

BCM330 2

Linux OpenWRT

wireless utils

192.16 8.1.1

802.11g pero se forzó la configuración el diagnóstico de interfaces de red, de los equipos 802.11g para que tra- ITG para la generación de Tráfico de bajaran exclusivamente con la norma Internet y Asterisk como Servidor de 802.11b. La conexión y ubicación de VoIP, los cuales se detallarán en la los equipos fue tal que todos trabaja- siguiente sección ran a 11Mbps durante el tiempo de las pruebas, sin posibilidad de que se V. METODOS DE EVALUACIÓN negociara a una velocidad menor. Los Para realizar el trabajo experimental dispositivos usados fueron tarjetas y establecer la capacidad se recurrió inalámbricas PCI, PCMCIA, miniPCI al uso de dos herramientas “open e incluso puntos de acceso configura- source” encargadas de generar las dos como wireless client, obteniendo llamadas. Una fue el Generador de un ambiente totalmente heterogéneo Tráfico de Internet – ITG [13] que con diferentes marcas y tipos de equi- tiene la capacidad de generar tráfico pos. En cuanto al sistema operativo, de VoIP con tres códecs: G.711, G.729 se instaló GNU/Linux en todos los y G.723, la otra fue el Servidor de equipos, tanto cliente como servidor, VoIP Asterisk® [10] con capacidad e incluso en uno de los puntos de acce- para soportar los mismo códecs y so, lo que dio una flexibilidad enorme algunos más, sin embargo para el en configuraciones, toma de datos y ejercicio comparativo se tomaron los permitió el uso de una gran cantidad mismos del ITG. Para verificar la de herramientas como Iptraf para ocupación del canal (ancho de banda)


131

y cantidad de paquetes por segundo, se probó con una llamada en ambas herramientas. Los resultados mostraron que para G.711 y G.729 las dos formas de generar llamadas eran equivalentes, pero para G.723 hubo cambios que claramente se dedujeron al revisar la diferencia en cuanto a características de este códec en ITG y en Asterisk, como se pueden apreciar en la Tabla II para ITG y en la Tabla III para Asterisk. Tabla II. Atributos de los códecs de ITG. Códec

G.711

G.723.1

G.729

Tasa de Bits (Kbps)

84

16.6

28

Paquetes /segundo

50

26

50.

Tabla III. Atributos de los códecs de Asterisk. Códec

G.711

G.723.1

G.729

Tasa de Bits (Kbps)

84

18.2

28

Paquetes /segundo

50

26

50

$unzip D-ITG-2.4.zip lo cual crea

directorios y descomprime archivos. Con lo anterior aparece un nuevo directorio que es el ITG y como se tiene el código fuente, éste debe compilarse para lo cual hay que cambiarse a ITG/src invitado@ryst15:~$ src/

cd

ITG/

invitado@ryst15:~/ITG/src$

Estando en el directorio se ejecuta el comando make que requiere tener instalado el compilador g++. En caso de no tenerlo aparece este mensaje: invitado@ryst15:~/ITG/src$ make g++ -DLINUX_OS -Wall -Wno-deprecated -c -o common/thread. o common/thread.cpp make: g++:

No se encontró el programa

make: *** [common/thread.o] Error 127

A.

Evaluación de la capacidad con ITG

Para realizar el proceso de evaluación por este camino, se descargó el paquete D-ITG, Distributed Internet Traffic Generator Versión 2.4 de la URL http://www.grid.unina.it/software/ ITG/download.php. Luego se copió a cada uno de los equipos clientes en sus respectivos directorios y también en el equipo central, tal como lo muestra el siguiente comando: # scp D-ITG-2.4.zip [email protected]:/root

132

Para el proceso de instalación se deben seguir estos pasos: Una vez se copia, se debe descomprimir


Si esta es la situación debe instalarse, por ejemplo para el caso de ubuntulinux que fue el sistema operativo utilizado, estando como superusuario se ejecuta apt-get install g++, es necesario tener el CD de instalación a mano, pues es solicitado. root@ryst15:~/ITG/src$ aptget install g++

Si es con Redhat se hace por medio de la instalación del RPM apropiado. Luego de tener instalado este paquete ya se puede compilar el D-ITG con el comando antedicho.

[root@ryst7 bin]# cd src [root@ryst7 src]# make

Con esto aparecen los binarios en el directorio ITG/bin. Para las estaciones clientes se trabaja el programa ITGSend y para el equipo central ITGRecv. El ITG permite dos formas de calcular el retardo de un paquete, si es en una vía se requiere un servidor NTP para sincronización de relojes y el receptor –ITGRecv– es el encargado de tomar los datos, si es el retardo de viaje redondo no se requiere el servidor NTP porque el transmisor –ITGSend– es el encargado de obtener los datos. Inicialmente se trató con NTP pero la sincronización se perdía rápidamente, además se consideró que la llamada sería en doble vía por lo que también era conveniente la segunda forma, por este motivo la toma de datos se tuvo en cada una de las seis estaciones generadoras, cada una de las cuales generó un archivo (log) que al pasarlo al ITGDec se decodifica y presenta en formato humanreadable. En este se encuentran los datos de retardo, jitter y pérdida de paquetes. La condición límite se estableció basándose en los parámetros definidos en la Sección II, de tal forma que la comunicación es inviable cuando se supere cualquiera de los límites de pérdidas, jitter o retardo mencionados. En cada una de las estaciones clientes se construyó un script para que el ITGSend generara las llamadas que contenían las tramas de VoIP enviadas al equipo central, con los parámetros requeridos tales como cantidad y códec.

La sintaxis fue: -a 192.168.1.2 -rp 10001 -t 60000 VoIP -x G.711.2 -h RTP Como se trabajó con 6 PC los puertos se escogieron colocando el primer número de acuerdo con el cuarto byte de la dirección IP tal como aparece a continuación: Cliente 1 - 192.168.1.101 -rp 10001-1000xx Cliente 2 - 192.168.1.102 -rp 20001-2000xx Cliente 3 - 192.168.1.103 -rp 30001-3000xx Cliente 4 - 192.168.1.104 -rp 40001-4000xx Cliente 5 - 192.168.1.105 -rp 50001-5000xx Cliente 6 - 192.168.1.106 -rp 60001-6000xx

Se comenzó en forma secuencial con una conexión de VoIP con el Cliente 1, luego una segunda con el Cliente 2 y así sucesivamente hasta llegar al Cliente 6, de esta manera seis llamadas activas significaban que los seis clientes estaban generando llamadas. Como no se disponía de más clientes inalámbricos para que hubiera más llamadas se aumentó a que cada cliente generara dos o más llamadas, de tal forma que 12 llamadas implican que cada uno de los seis está generando dos y que 18 están generando tres. El archivo de registro (log) que se obtuvo con cada uno se pasó al ITGDec para que lo decodificara y de esta forma conocer los datos de retardo, jitter y pérdida de paquetes. El límite se estableció por superar cualquiera de ellos, pero como se mencionó anteriormente fue interesante ver que cuando se sobrepasaba la capacidad, todos estos límites eran considerablemente rebasados. Se realizó primero con G.711, luego con G.729 y finalmente con G.723.


133

En el equipo central se ejecutó la aplicación Iptraf para establecer ancho de banda utilizado y paquetes por segundo tomando sreenshots que comprobaran la utilización del canal y revisando si la entrada y/o salida era n x [BWc] donde n era la cantidad de conexiones y BWc el ancho de banda utilizado por cada códec. Para G.711 BWc=64, para G.729 BWc=29 y para G.723 BWc=26.6. Siempre se utilizó un tipo de protocolo RTP y no se utilizó VAD (Voice Activity Detection). Antes de iniciar las pruebas se envió un archivo de 1.9 GB a cada cliente para ver si existía un promedio de velocidad relativo entre todos, con el fin de descartar problemas de desempeño en alguno de ellos, las velocidades relativamente fueron cercanas, razón por la cual se consideró que todos se podían utilizar. B. Evaluación de la capacidad con asterisk

Después de haber trabajado con el generador de tráfico, se decidió realizar el laboratorio con un servidor de VoIP generando llamadas reales entre los equipos y poder hacer una comparación y validación de resultados respecto al generador de tráfico D-ITG. Para llevar a cabo esta evaluación fue necesario instalar la PBX IP Asterisk, realizar la configuración de los clientes y escribir algunos scripts que permitieran la generación automática de llamadas desde los clientes hacia el servidor, la respuesta de las llamadas en el servidor, y la reproducción automática de lado y lado de mensajes de voz pregrabados, de modo que se obtuvieran datos totalmente reales en una conversación de VoIP. Se tuvo el problema que si

134


se usaban softphones como clientes, se tenía la limitación de tan solo una llamada por cliente incluso en los softphones que manejan llamadas simultáneas, pues estos realmente solo manejan una comunicación al tiempo y las demás llamadas las pone en espera, además de que cada llamada por softphone no se podría programar, ni ponerle a reproducir un mensaje automáticamente. Para solucionar este inconveniente se instaló el servidor de VoIP asterisk en todos los clientes, ya que asterisk también puede operar como cliente, de modo que todo el trabajo, configuración y escritura de scripts se hizo para manejar las llamadas en asterisk. Adicionalmente al realizar la evaluación, se buscó tener una verificación “audible” al ser humano de la calidad de la voz, que demostrara cómo el aumento en el jitter y retardo realmente afecta la percepción y la calidad de la comunicación. Para tal efecto, se instaló adicionalmente en uno de los clientes un softphone, con el cual se llamó al servidor cada vez que se quiso evaluar la calidad. Para más información sobre asterisk y su configuración se puede visitar la URL www.asterisk.org. A continuación se explican sólo las partes claves de la configuración, para facilitar la reproducción del experimento. 1. CONFIGURACIÓN DEL SERVIDOR

1.1. Sección de clientes SIP “sip. conf” En esta sección se declaró el abonado sip que se utilizó para monitorear la calidad de audio a través de parlantes

; Se declara la sección general; Se declara la sección de abonado sip con un nombre ; cualquiera, para este caso [softphone1] [softphone1] type=friend

;Permite hacer y recibir llamadas

context=ciclo

;Podrá llamar a los números que se ;incluyan en el contexto ciclo del ;plan de marcado

host=dynamic

;podra iniciar sesión desde cualquier ;equipo

secret=telefono1

;La contraseña

qualify=yes

;monitorea la conexión y el retardo

dtmfmode=rfc2833

;Detección de tonos estandar

relaxdtmf=yes

;Facilita la detección de tonos

1.2. Sección de plan de marcado “extensions.conf” En esta sección se declara la lógica y el flujo de la llamada ;Se declara la sección general ;Se declara el contexto que manejara las llamadas [ciclo]

;Contexto Ciclo

exten=s,1,BackGround,demo-instruct ;Reproduce el mensaje demo-instruct que esta ya grabado ;en el servidor exten=s,2,Goto(ciclo,s,1) ;Crea un ciclo para que se repita el mensaje ;indefinidamente exten=101,1,Goto(ciclo,s,1) ;cuando el softphone llama a 101 entra al ciclo


135

1.3. Sección de clientes IAX “iax.conf” ;Se declara la sección general ;Se declara uno por uno los clientes a los que se ;conectará [cliente1] type=friend

;Puede hacer y recibir llamadas

host=192.168.1.100 ;Se conectará desde esa IP context=ciclo

;Podrá llamar a los números que se ;declaren en ese contexto

qualify=yes

;Se monitorea la conexión ;y el retardo

disallow=all

;No permite un códec diferente a

allow=ulaw

;g711u

[cliente2] type=friend

;Puede hacer y recibir llamadas

host=192.168.1.101 ;Se conectará desde esa IP context=ciclo

;Podrá llamar a los números que se ;declaren en ese contexto

qualify=yes

;Se monitorea la conexión y el retardo

disallow=all

;No permite un códec diferente a

allow=ulaw

;g711u

;Se continúa con los demás clientes

Para cambiar de códec se puede modificar el allow por: alaw Códec G.711a ulaw Códec G.711u g729 Códec G.729 g723 Códec G.723 gsm Códec GSM ilbc Códec ilbc Es de anotar que los códecs g729 y g723 no son libres y en ciertos

136


ambientes debe pagarse por ellos, asterisk los incluye solo en modo passthrough, de modo que para poder generar las llamadas y recibirlas, se debió compilar los códecs gratuitos para uso académico disponibles en la página de intel www.intel.com e incluirlos en los módulos de asterisk. 2. CONFIGURACIÓN DEL CLIENTE

En los clientes solo fue necesario realizar una configuración en los

clientes IAX, pues todas las llamadas se harían manejando este protocolo,

solo se debe declarar el servidor al que irán conectados.

Sección IAX iax.conf ;Se declara la sección general ;Se declara el servidor que le llamaremos ap [ap] type=friend host=192.168.1.2 context=ciclo qualify=yes disallow=all allow=ulaw trunk=no ;Para que cada llamada se haga como una ;llamada independiente. Si se coloca ;trunk=yes, se meten varias llamadas por una ;“conexión” que ahorra ancho de banda pero ;no es el caso real.

Una vez se haya iniciado asterisk en los clientes como en el servidor, y se haya hecho la configuración correcta, en la interfaz de línea de comandos

CLI de asterisk, se pueden observar las conexiones de los clientes tal como aparece en la Figura 4.

Figura 4. Estado de conexión en el servidor.


137

Asterisk chequea constantemente Una vez los clientes se encuentran un directorio en donde se pueden conectados con el servidor, es nece- colocar scripts de llamadas para que sario que se inicien las llamadas. él ejecute inmediatamente. 3. GENERACIÓN DE LLAMADAS

El script se detalla a continuación. ;Script para generar llamadas debe ubicarse en / ;var/spool/asterisk/outgoing, tan pronto script ;en este directorio, se hará la ejecución.

se

copie

el

;Archivo sample.call Channel: IAX2/ap

; llama al servidor ‘ap’

MaxRetries: 2

; hasta dos reintentos

RetryTime: 60

;Reintento cada 60 segundos

WaitTime: 30

;Esperara 30 segundos la respuesta

Context: ciclo

;La llamada llegará al contexto ciclo,

Extension: s

;extension s y

Priority: 1

;prioridad 1

Si se observa en las configuraciones anteriores, este script lleva la llamada a la ejecución del archivo pregrabado, que se ejecuta tanto en el servidor como en los clientes.

Para generar las llamadas se puede hacer un script que copie el archivo anterior las veces necesarias con diferente nombre cada vez, asi:

#!/bin/bash #mpstat -P 0 1 1 adiciona un retardo de un segundo entre #llamada y llamada generada además de mostrar el consumo #de CPU cp/tmp/sample.call /var/spool/asterisk/outgoing/sample1. call mpstat -P 0 1 1 cp/tmp/sample.call /var/spool/asterisk/outgoing/sample2. call mpstat -P 0 1 1 cp/tmp/sample.call /var/spool/asterisk/outgoing/sample3. call mpstat -P 0 1 1

138


De esta forma se generan tres llamadas. En la Figura 5 puede observarse el momento en que se realizan varias llamadas desde un cliente. Es de anotar también que este script debe ejecutarse en cada cliente, pues es cada cliente quien genera la(s)

llamada(s), en cuanto al servidor también es importante aclarar que para generar una llamada con diferentes características como cambio de códec, debe modificarse el archivo iax.conf tanto en los clientes como en el servidor cambiando allow=ulaw por otro códec.

Figura 5. Estado de cada llamada desde cada uno de los seis clientes.

En la Figura 6 se muestra el estado de seis llamadas generadas hacia el

servidor, una desde cada cliente

Figura 6. Generación de llamadas desde un cliente.

VI. RESULTADOS

A.

Resultados obtenidos del trabajo con ITG

En primer lugar se tomó el dato de utilización de ancho de banda y canti-

dad de paquetes por segundo de cada códec por medio de IPtraf. Los resultados coincidieron exactamente con los que muestra la Tabla II, como se puede verificar en las Figuras 7-9.


139

Figura 7. Datos de Iptraf de una llamada con G.711.

Figura 8. Datos de Iptraf de una llamada con G.729 .

Luego de esto se inició la generación de llamadas en la forma explicada anteriormente; con G.711 se lograron realizar hasta 11 llamadas, con G.729 hasta 14 y con G.723 hasta 28.

140


Luego se procedió a decodificar los archivos de registro (Logs) obtenidos con cada uno de los códecs: G.711, G.729 y G.723.

Figura 9. Datos de Iptraf de una llamada con G.723.

Para esto se utiliza el Decoficador del ITG, la sintaxis es: ./ITGDec [log]

En este caso los logs siguieron la siguiente convención de nombrado: Log-[cantidad de llamadas]-[códec]. log. Por ejemplo, para el caso de la decodificación de 11 llamadas realizadas con G.711 este comando quedaría: ./ITGDec Log-11-G711.log

Los siguientes pares de figuras muestran los resultados obtenidos sobre la base de los cuales se estableció el límite de capacidad de acuerdo con cada códec. En la figura que aparece primero las condiciones de retardo jitter y pérdida de paquetes no superan los límites para una óptima comunicación de VoIP pero en la segunda (que es cuando se aumenta una llamada más) los supera considerablemente. En la parte inferior

de cada una aparece el comando utilizado para la decodificación de los resultados. Estos resultados son los que dan soporte a las capacidades encontradas, esto es: para G.711 hasta 11 llamadas, para G.729 hasta 14 llamadas y para G.723 hasta 28 llamadas, lo anterior en razón de que siempre que se aumentaba una sola llamada, los límites de retardo (retardo) y pérdida de paquetes (packets dropped) eran sobrepasados “notoriamente”, lo cual se aprecia en las Figuras 11, 13 y 15 para G.711, G.729 y G.723 respectivamente, especialmente para la pérdida de paquetes ( Packets dropped). B. Resultados obtenidos del trabajo con asterisk

Inicialmente se tomaron los datos de consumo de ancho de banda para una sola llamada con cada uno de los tres códecs, obteniendo resultados similares a los obtenidos con ITG: SISTEMAS & TELEMÁTICA

141

Figura 10. Decodificación de 11 llamadas con G.711.



142






143

G.711 82.4 Kbits/sg G.729 27.8Kbits/sg G.723 18.3Kbits/sg Es importante anotar también que se tomaron medidas para varias llamadas y el consumo de ancho de banda fue exactamente el consumo

de una sola llamada multiplicado por el número de llamadas, tal como se observa en las Figuras 16 y 17; además, se consumió el mismo ancho de banda cuando se hicieron llamadas desde diferentes clientes que cuando se hicieron llamadas desde un solo cliente.

Figura 16. Datos de Iptraf con una llamada G.711.

Figura 17. Datos de Iptraf con diez llamadas G.711.

144


Para hacer una evaluación de los resultados obtenidos se tomaron datos empezando por una llamada y terminando en el momento en que la cantidad de llamadas no permitieran una comunicación fluida.

1. RESUL RE SULT TADOS CON G.711 G.71 1

El tipo de medidas que se tomaron se pueden observar en la Figura 18 que muestra los resultados tabulados a medida que se iban generando nuevas llamadas.

Figura 18. Conexiones, Retardo, Jitter y Códec de 10 llamadas en curso sobre el servidor de VoIP.

Como sólo se contó con seis clientes, a partir de la séptima llamada fue necesario generar más llamadas por cada cliente. Para el códec G711 se tuvo un comportamiento adecuado y se obtuvieron buenos resultados hasta la llamada

número 12. Con la llamada número trece el retardo y el jitter aumentaron drásticamente drásticament e y se pudo percibir una degradación en la calidad. En la Figura 19 se observa la degradación del jitter a medida que se aumentan las llamadas.

Figura 19. Observación del Jitter a medida que las llamadas aumentan.

En la Figura 20 se observa la degradación del retardo a medida que se aumentan las llamadas. Como se ve en las Figuras 19 y 20 y en la Tabla IV, el Jitter y Retardo son

muy buenos (están dentro de los límites) hasta la llamada 12, pero en el momento en que se realiza la llamada siguiente el retardo aumenta dramáticamente a pesar de que el jitter se


145

Figura 20. Observación del Retardo a medida que las llamadas aumentan. Tabla IV. Resumen de resultados G711. No Llamadas

1

2

3

4

5

6

7

8

Jitter

1

1,5

1,33

2,5

2,6

2,5

2,71

4,5

Delay

3

2

2,67

3

3,8

4,67

4,57

5,13

No Llamadas

9

10

11

12

13

14

15

16

Jitter

4

3,7

4

6,75

6,62

9,36

14,26

14,87

Delay

4,5

4,5

5,64

9,17

2130

2751

2734

4588

mantiene aún apto para una comunicación adecuada de voz. Para verificar lo anterior, se puso un softphone con parlantes para apreciar la calidad de la comunicación y se obtuvieron las siguientes anotaciones: Llamada 11: El sonido es de excelente calidad, no se aprecian entrecortes o chasquidos. Llamada 12: El sonido continúa siendo excelente, aunque se alcanzan a apreciar algunos pequeños chasquidos muy esporádicos, pero nada que degrade la comunicación. Llamada 13: La calidad se degradó apreciablemente, se aprecian fácilmente chasquidos y algunos entrecortes, toma mucho tiempo el

146


establecimiento de una nueva conversación. Llamada 14: Se hace más evidente la pérdida de calidad, se aprecian muchos entrecortes y se dificulta el inicio de nuevas sesiones. Llamada 15: No se entienden muchas partes de la conversación, se entrecorta constantemente y por largos periodos. Llamada 16: Después de muchos intentos, se logra establecer la comunicación, pero no es entendible. Llamada 17: Cada vez que se intentó iniciar la llamada 17, se cayó la llamada, y “tumbó” más de la mitad de las que se estaban cursando.

Es importante anotar que se repitió el experimento para verificar que la información obtenida es correcta, y que se obtuvieron los mismos datos en las dos ocasiones.

El proceso para obtener los resultados con los códecs G.729 y G.723, fue el mismo que se siguió para G.711. Los resultados obtenidos se muestran en las gráficas de las Figuras 21 y 22:

Figura 21. Observación del Jitter a medida que las llamadas aumentan con G729.

Figura 22. Observación del Retardo a medida que las llamadas aumentan con G729.

2. RESULTADOS CON G.729

Como se observa en las gráficas, el comportamiento es similar al que tienen las llamadas con G711, pero con una capacidad mayor de llamadas. Como se observa, hasta la llamada 14 el funcionamiento es estable y con buena calidad, pero en la llamada

15 el retardo aumenta a tal punto, que se afecta la calidad de todas las llamadas y se empiezan a sentir entrecortes en la comunicación. A partir de este punto y hasta la llamada 17 se degrada más y más la calidad de la llamada hasta no ser entendible y/o estable. Cuando se intenta generar la


147

llamada 18 no se puede establecer, e incluso tumba la mayoría de las llamadas que se están cursando. Este resultado muestra que a pesar de que el ancho de banda que consume G729 es la tercera parte de G711, la capacidad de llamadas sólo aumentó en un 14%, lo que permite ver que la mayor limitante en las comunicaciones es la

contienda por el medio antes que el consumo de ancho de banda. 3. RESULTADOS CON G.723

Como se observa en las Figuras 23 y 24, con el códec G.723, se tiene un comportamiento similar a los dos anteriores casos, pero con una capacidad de llamadas bastante superior.

Figura 23. Observación del Jitter a medida que las llamadas aumentan con G723.

Figura 24. Observación del Retardo a medida que las llamadas aumentan con G723.

Con el códec G723 se logran cursar 21 llamadas antes que empiecen a presentarse pérdidas considerables en la calidad. A partir de la llamada

148


22 se empieza a degradar la calidad y en llamada 24 la comunicación es bastante difícil; al tratar de establecer la llamada 25 se desconectan muchas

de las llamadas que se estuvieran ma de VoWLAN son el retardo y la cursando. pérdida de paquetes que tiene un Se deben observar dos comportamien- cambio abrupto cuando se supera tos recurrentes en las pruebas hechas una determinada cantidad de llamadas. En cambio el jitter presenta un con los tres códecs: comportamiento lineal, con pequeña 1. El aumento de jitter se hace de pendiente, que se mantiene fácilmenun modo casi lineal, tiene una te dentro de los límites permitidos pendiente pequeña y no sobrepasa para una buena conversación. los límites para una buena conversación de voz, el retardo es Es muy importante en un sistema de muy pequeño y cercano a cero VoWLAN poner un límite en el númehasta cierto punto, pero después ro de llamadas que puedan establede éste tiene un cambio abrupto cerse por cada punto de acceso, pues que pasa de alrededor de 5 ms a si se supera este límite se ocasionará no sólo una pérdida de calidad, sino varios segundos. la desconexión de las llamadas que 2. Cuando se trató de generar nue- se estén cursando a través del punto vas llamadas en el momento en de acceso. que se contaba con un retardo excesivo, se ocasionó la pérdida Debe tenerse en cuenta también el consumo de máquina que puede de conexión. tenerse con la codificación de voz al usar G.729 o G.723, ya que en dispoVII. CONCLUSIONES El desarrollo de este estudio de ca- sitivos móviles con poca capacidad de pacidad por métodos experimentales procesamiento puede no ser posible arroja una serie de aspectos impor- usar un códec diferente de G.711. tantes para el trabajo con VoIP en El deterioro en la calidad cuando el redes inalámbricas que se anotan a retardo aumenta abruptamente es continuación: fácilmente comprobable. Cada vez Las comunicaciones de VoIP en las que se superaba el umbral de llamaredes inalámbricas tienen límites das encontrado para cada códec, se abruptos, esto quiere decir que luego escuchaba una notoria disminución que se supera el límite de capacidad, de la calidad en la comunicación a una comunicación siguiente queda través de los parlantes conectados al sin ninguna probabilidad de ser softphone, en donde se escuchaban soportada por razón del retardo y entrecortes y múltiples ruidos. pérdida de paquetes tan significativo Mientras en las redes cableadas el que se presenta. Por este motivo es tipo de códec que se utiliza determina necesario establecer nuevos criterios casi linealmente la capacidad (cantide diseño con VoIP pues los tradicio- dad de llamadas) que puede tener el nalmente utilizados para Ethernet sistema, en las redes inalámbricas cableada no son convenientes. aunque un códec con menor consumo Los parámetros que más incidencia de ancho de banda permite un mayor tienen en el límite del número de número de llamadas, este efecto no es llamadas concurrentes en un siste- tan significativo como se notó en los SISTEMAS & TELEMÁTICA

149

experimentos donde se comprobó que lo más crítico venía a ser la contienda por el medio. Los resultados obtenidos de llevar a cabo las pruebas con ITG y Asterisk sirven para un proceso de validación implícita del laboratorio realizado. La única diferencia se obtuvo con el códec G.723, lo cual fue consecuencia directa de tener características diferentes para las dos aplicaciones. Pero fue muy interesante ver que tanto para G.711 como para G.729 los resultados fueron los mismos. Con las implementaciones futuras de los sistemas de calidad de servicio, es probable que al ser la voz el servicio privilegiado, lo que se verá afectado será el desempeño en cuanto a la transferencia de datos tipo best effort, sobre todo si los fabricantes hacen como con 802.11 donde solamente implementaron el esquema DCF, y no se tenía un elemento central que controlara el acceso. Sumando el conocimiento generado por estos experimentos con el conocimiento previo de los autores sobre las redes inalámbricas, se plantea la siguiente discusión: la congestión en este tipo de redes se ve que es proporcional al número de paquetes por segundo más que por el ancho de banda que consumen los paquetes (entre otras los paquetes de voz son pequeños pero requieren ser despachados inmediatamente). Esto indica que sería interesante estudiar el impacto de diferentes tamaños de paquetes. Por ejemplo, colocar dos tramas en un paquete y por tanto bajar la tasa de paquetes a la mitad (reduciendo por tanto el overhead del paquete también a la

150


mitad) lo que sin duda reducirá la congestión y se podría esperar mejor desempeño de la red. Sin embargo, el inconveniente es que el retardo por procesamiento aumentaría y la sensibilidad a la pérdida de paquetes también, luego vendrían algunas preguntas inmediatas para resolver en trabajos futuros: ¿La disminución de paquetes perdidos debido al mejor desempeño de la red compensará el aumento en la sensibilidad a los paquetes que se puedan perder? ¿Qué es más conveniente optimizar en la práctica? AGRADECIMIENTOS

Los autores agradecen al Departamento de Telecomunicaciones de la Universidad del Cauca por la colaboración para el acceso a la infraestructura. BIBLIOGRAFÍA

[1] IEEE Std 802.11b, IEEE Standard forWireless LAN Medium Access Control (MAC) and Physical Layer Specifications: Higherspeed physical layer extension in the 2.4GHz band, 1999. [2] Wi-Fi.org. Alianza Wi-Fi. Disponible en http://www.wi-fi.org [3] Agredo G, López G. Redes Inalámbricas y Celulares como soporte a las aplicaciones de Telemedicina. Telecomunicaciones & Sociedad. Ago 2004: Volumen 2: 55 – 60. [4] Cisco Systems. Wireless qualityof-service deployment guide. Technical report, Cisco, 2003. [5] Szigeti T, Hattingh C. Quality of Service Design Overview. Disponible en http://www.

informit.com/articles/article. asp?p=357102&rl=1 [6] Intel. Overcoming Barriers to High-Quality Voice over IP Deployments. Disponible en http://www.intel.com/network/ csp/pdf/8539.pdf [7] J. Chou. “Design a successful VoWLAN system”. Wireless Net DesignLine. Sep. 2005. Disponible en http://www.wirelessnetdesignline.com/howto/170101775 [8] F. Mlinarsky. “Metrics and Methods Bring VoWLAN Success”. Wireless Systms Design. Mar. 2005. Disponible en http://www. wsdmag.com/Articles/ArticleID/10003/10003.html. [9] Distributed Internet Traffic Generator. Universita’ degli Studi di Napoli ‘’Federico II’’ (Italia) Disponible en http://www.grid. unina.it/software/ITG/ [10] Asterisk “The Open Source PBX” Disponible en http://www.asterisk.org/

AUTORES Guefry Leider Agredo Méndez.

Docente de la facultad de Ingeniería Electrónica y de Telecomunicaciones de la Universidad del Cauca. Estudiante de la maestría en Electrónica y Telecomunicaciones de la Universidad del Cauca. Investigador del Grupo de I+D en Nuevas Tecnologías en Telecomunicaciones (GNTT). Áreas de interés: Comunicaciones Inalámbricas, Voz sobre IP, Servicios de Internet. e-mail: [email protected] Jaime Andrés Gaviria Molano. Ingeniero Jefe de Servidores y Servicios de Internet de la Universidad del Cauca. Estudiante de la maestría en Electrónica y Telecomunicaciones de la Universidad del Cauca. Áreas de interés: Voz sobre IP, Reconocimiento de Voz. e-mail: [email protected].


151

telematica

Recommend Documents