Telematica

Edicin Monogrfica i2 ComM 2006
Modelos de canal inalmbricos y su aplicacin al diseo de redes WiMAX. Alexander Galvis Quintero Cristina Gmez Santamara Roberto Carlos Hincapi Reyes 13
Plataforma de acceso universal a mensajera instantnea mvil 35 O. M. Caicedo D. A. Caicedo E. Figueroa F. O. Martnez J. A. Hurtado Modelo de simulacin de la capa MAC IEEE 802.16-2004 para modo Mesh Javier Emilio Sierra Roberto Hincapi Roberto Bustamante () Leonardo Betancur Evaluacin del estimador de capacidad AdHoc Probe en redes MANET con trco cursado autosimilar Mara del Pilar Salamanca Nstor Misael Pea Impacts of mobility on wireless access to IPv6 networks Christian Lazo R. Roland Glckler Desarrollo de un software Web y Mvil para la gestin de informacin de campo de cultivos agrcolas (AgrocomM) Juan Manuel Delgado Christian Giraldo Andrs F. Milln Claudia Ziga Jos Abada Evaluacin experimental de la capacidad de IEEE 802.11b para soporte de VoIP Guefry Agredo Mndez Jaime Gaviria Molano 57
79
101
113
125
SISTEMAS & TELEMTICA
Revista de la facultad de ingeniera

INGENIERA DE SISTEMAS E INGENIERA TELEMTICA UNIVERSIDAD ICESI COMIT EDITORIAL DE LA UNIVERSIDAD Francisco Piedrahta Plata
Rector
Jos Hernando Bahamn

Director Acadmico
Hctor Ochoa Daz

Decano de la Facultad de Ciencias Administrativas y Econmicas
Gonzalo Ulloa
Decano de la Facultad de Ingenieras
Lelio Fernndez Druetta

Decano de Derecho y Humanidades
COMIT EDITORIAL DE LA REVISTA Guillermo Londoo Acosta

Director del Programa de Ingeniera de Sistemas
Juan Manuel Madrid Molina

Director del Programa de Ingeniera Telemtica
lvaro Pachn de la Cruz

Jefe del Departamento de Tecnologas de Informacin y Comunicaciones
Narcs Cardona
Profesor de la Universidad Politcnica de Valencia, Espaa
Andrs Navarro Cadavid

Profesor de la Universidad Icesi
Joaqun Restrepo
Profesor de la Ponticia Universidad Bolivariana de Medelln
Gonzalo Ulloa
Decano de la Facultad de Ingenieras
Edwin Montoya
Profesor de la Universidad EAFIT, Medelln
Luis Eduardo Mnera

Profesor de la Universidad Icesi
David Fernndez McCaan

Profesor de la Universidad de Antioquia, Medelln
Andrs Navarro Newball

Profesor de la Ponticia Universidad Javeriana, Cali
Homero Ortega
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 artculos de esta publicacin son responsables de los mismos. El material de esta publicacin puede ser reproducido sin autorizacin, mencionando ttulo, autor y, como fuente, S & T. Revista de Ingeniera de Sistemas e Ingeniera Telemtica, Universidad Icesi. Http://www.icesi.edu.co Informes: Tel.: 555 2334. Ext. 377 Fax: 555 1706 - 555 1745 Editor. e-mail:lemunera@icesi.edu.co Canje: e-mail: lemunera@icesi.edu.co Cali, Valle, Colombia, Sudamrica
GUA PARA LOS AUTORES DE ARTCULOS
Para los autores de los artculos de la Revista S & T Ingeniera de Sistemas e Ingeniera Telemtica de la Universidad Icesi. El autor debe garantizar que su artculo no ha sido publicado en ningn medio. Los autores de artculos sern responsables de los mismos, y por tanto no comprometen ni los principios o polticas de la Universidad, ni los del Comit Editorial. El Comit Editorial se reserva el derecho de publicar o no los artculos que no cumplan con los criterios de publicacin por parte de la Universidad Icesi. La temtica de los artculos debe ser de las diferentes reas de Ingeniera de Sistemas, Informtica y Telemtica, resultado de investigacin propiamente dicha, aplicaciones reales, productos de investigacin formativa, procesos sistmicos de anlisis de problemas y propuestas de solucin. Los artculos deben contener: Ttulo (claro y preciso) Breve resea del autor.
Abstract o resumen ejecutivo del artculo (mximo doce renglones a doble espacio). Palabras claves. Clasicacin Colciencias*. Introduccin. Desarrollo. Referencias y notas de pie de pgina. Conclusiones. Bibliografa o fuentes de informacin. Extensin: No exceder de 25 pginas 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 prrafos u oraciones ms signicativos del contenido del artculo y todo aquello que d signicado a la estructura del mismo.
Los artculos se deben redactar en tercera persona del singular, impersonal, contar con adecuada puntuacin y redaccin, carecer de errores ortogrcos. Conservar equilibrio en la estructura de sus prrafos. * Clasicacin Colciencias para artculos cientcos y tecnolgicos: a) Artculos de investigacin cientca y de desarrollo tecnolgico: documentos que presentan resultados derivados de proyectos de investigacin cientca y/o desarrollo tecnolgico.
b) Artculos de reexiones originales sobre un problema o tpico particular: documentos que corresponden a resultados de estudios realizados por el o los autores sobre un problema terico o prctico. c) Artculos de revisin: estudios hechos por el o los autores con el fin de dar una perspectiva general del estado de un dominio especco de la ciencia y la tecnologa, de sus evoluciones durante un perodo y donde se sealan las perspectivas de su desarrollo y evolucin futuros.
GUA PARA LAS RESEAS BIBLIOGRFICAS
Tipo de libro reseado: Debe ser de tipo ejecutivo, no un texto acadmico. Ttulo del libro: Tomado de la cartula. Autor del libro: Apellidos, Nombre (persona del autor, lo relevante). Nombre del traductor (si lo tuviere). ISBN Editorial, ciudad y fecha. Tamao: 16.5 cm x 23.5 cm. Nmero de pginas.
Fortalezas (puntos del porqu el ejecutivo debe leerlo, cmo est estructurado el libro: partes, captulos) etc. Debilidades (puntos no tan atractivos del libro). Extensin entre 700 a 800 palabras (equivalente a pgina y media, a doble espacio). Lenguaje ejecutivo (breve, no acadmico, darle ayuda / consejo prctico para hoy, con ejemplos del texto).
10
La Revista S & T Ingeniera de Sistemas e Ingeniera Telemtica, est dirigida a ingenieros de sistemas, ingenieros electrnicos, ingenieros telemticos y anes; profesores universitarios y estudiantes en las diferentes reas de la ingeniera; profesionales especializados en estas reas. La Revista S & T Ingeniera de Sistemas est indexada por Colciencias en el ndice Nacional de Publicaciones Seriadas Cientcas y Tecnolgicas (categora C). Usted puede acceder a ella entrando en nuestra pgina Web en internet y bajar en formato PDF el artculo de su inters o la totalidad del nmero que desee, slo debe entrar a la direccin: http://www.icesi.edu.co/es/publicaciones y seleccionar la edicin correspondiente. Cualquier duda o comentario dirigirlo a la cuenta de correo lemunera@icesi.edu.co El presente nmero es monogrco y contiene una seleccin de artculos publicados en el Proceedings del i2ComM 206, Tecnologas convergentes aplicadas a la computacin mvil realizado el 21 y 22 de septiembre de 2006 en la Universidad Icesi.
EL EDITOR
11
12
Modelos de canal inalmbricos y su aplicacin al diseo de redes WiMAX.

Ingeniero Alexnder Galvis Quintero Cristina Gmez Santamara, MSc. Roberto Carlos Hincapi Reyes, MSc.
Grupo de Investigacin, Desarrollo y Aplicacin en Telecomunicaciones e Informtica (GIDATI). Universidad Ponticia Bolivariana - Medelln.
Fecha de recepcin: 30-05-06
Fecha de seleccin: 30-10-06
Fecha de aceptacin: 30-08-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 classication of wireless channel models and the identication 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
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 artculo detalla de manera general el avance actual de un proyecto de maestra desarrollado en el marco de trabajo del Grupo de Investigacin, Desarrollo y Aplicacin en Telecomunicaciones e Informtica (GIDATI) de la Universidad Ponticia Bolivariana. La primera fase del proyecto consiste en la clasicacin de los modelos de canal inalmbricos y la identificacin de aquellos que aplican a las condiciones de trabajo de los sistemas denidos por
13
el estndar IEEE 802.16-2004. La segunda fase corresponde al anlisis comparativo de estos modelos y a su implementacin en el software ICS Telecom de la empresa francesa ATDI con el objetivo de optimizar algunos procesos relacionados con el diseo de estas redes. Los resultados han permitido hasta la fecha sacar
algunas conclusiones importantes y aportar realimentacin a otras actividades de investigacin y desarrollo en ejecucin. PALABRAS CLAVE Modelo de canal, WiMAX, radio propagacin, 802.16, FWA. Clasicacin Colciencias: A
14
I. INTRODUCCIN Las actividades de planeacin, diseo, despliegue y mantenimiento de redes inalmbricas 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 aplicacin. Uno de los aspectos ms complejos relacionados con los sistemas inalmbricos es la manera como se modela el medio de propagacin de las seales, 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 aplicacin especco; y aunque en general las soluciones planteadas han ofrecido hasta el momento buenos resultados, existe una notable dicultad relacionada con la eleccin del modelo ptimo para la situacin en estudio, lo que le resta considerable exibilidad a los procesos mencionados anteriormente. Debido a la importancia misma de las tecnologas involucradas, es necesario desarrollar herramientas que mejoren signicativamente los procesos de anlisis, diseo e implementacin de redes inalmbricas de telecomunicaciones, a la vez que permitan optimizar los procesos de aprendizaje y las actividades de entrenamiento de personal tcnico y cientco al interior de las empresas, universidades y centros de investigacin. Considerando lo anterior, dentro del Grupo de Investigacin, Desarrollo y Aplicacin en Telecomunicaciones e Informtica (GIDATI) de la Uni-
versidad Ponticia Bolivariana est en actual desarrollo un proyecto de Maestra en Ingeniera, el cual se concentra en la denicin del estado del arte en modelamiento de canales de radio, y en la clasicacin de los modelos ms representativos con el objetivo de apoyar y optimizar las actividades acadmicas y aquellas tcnicas relacionadas con los procesos mencionados inicialmente. Partiendo de esta clasicacin general, se ha dirigido la atencin a la particularizacin de los modelos aplicables al estndar IEEE 802.16-2004 [1] y a su implementacin en una herramienta de simulacin para conformar un modelo general de capas inferiores para estos sistemas. Inicialmente se est realizando una revisin de los modelos de canal existentes que aplican a esta tecnologa, extrayendo un subconjunto de ellos de acuerdo con ciertos criterios como el grado de aproximacin, la correspondencia con los casos particulares a analizar, el nivel de complejidad previsto para su implementacin, entre otros. Los modelos seleccionados son adaptados a los sistemas y ambientes particulares, tarea que implica el esfuerzo ms signicativo considerando la topografa colombiana. Seguidamente se realizar la simplicacin de los mismos para su escritura en lenguaje C++ y generar nalmente las libreras (DLL) que los implementen como modelos de canal denidos/desarrollados por el usuario en el interior del software de planeacin, diseo y simulacin de redes inalmbricas ICS Telecom de la empresa francesa ATDI. Las campaas de simulacin se encuentran en fase de diseo para obtener resultados que permitan realizar anlisis comparativos entre
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 pas. Finalmente se concluir y se presentarn 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 ms crticos a considerar en la construccin de herramientas software que apoyen los procesos de planeacin y diseo de redes inalmbricas. Para el caso particular de WiMAX es de especial inters el modelo de canal utilizado para la prediccin del comportamiento del sistema, tanto en la estimacin de los niveles de cobertura como de las tasas de transmisin alcanzables, ms aun teniendo en cuenta que el sistema se ha denido para condiciones de LOS, nLOS y NLOS 2 [2]. Como se expone en [3], la prctica ms desarrollada y la que mejores resultados ha ofrecido es la de inicialmente describir el canal de forma matemtica (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 simulacin que apoyen las actividades
de diseo de redes. El reto siempre es lograr modelos lo sucientemente completos, descriptivos y simples que permitan desarrollar simulaciones ecientes en todos los sentidos. En trminos generales, los modelos de canal buscan predecir el nivel de prdida de potencia que una seal de ciertas caractersticas sufre cuando se propaga por un ambiente geogrco determinado. Como se observa en la Figura 1, el comportamiento de la variable potencia en recepcin es
Figura 1. Comportamiento de la potencia recibida en funcin de la frecuencia de operacin y la distancia entre transmisor y receptor.
inversamente proporcional tanto a la distancia de separacin entre transmisor y receptor como a la frecuencia de operacin, y adems, se presentan otros fenmenos (ensombrecimiento, desvanecimiento por multitrayectoria, desvanecimiento por efectos atmosfricos, difraccin y refraccin, centelleo, cell breathing, retardos,
1 2
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 ruido) que cada modelo considera de forma distinta. El tipo de ambiente y los fenmenos mencionados hacen que la superficie mostrada en la Figura 1 cambie signicativamente volvindola no determinstica, as que el desarrollo de un modelo matemtico del canal de comunicaciones y su posterior implementacin software debe considerar tanto los medios de propagacin y las frecuencias utilizadas para la radiacin de seales como el ambiente geogrco en el cual se va a desplegar el sistema y el tipo de sistema (servicios y aplicaciones). En [4] y [5] se realiza una clasicacin general de radio canales, diferenciando aquellos que han sido formulados empricamente (basados en mediciones) de otros cuya formulacin obedece a la fsica propiamente dicha relacionada con los fenmenos de propagacin de seales. No obstante, con el advenimiento de la informtica se han dado otras orientaciones en lo que a modelamiento matemtico se refiere, las cuales incluyen anlisis geomtricos como el ray tracing, y el anlisis espaciotemporal que actualmente se encuentra en pleno desarrollo con el objetivo de impulsar nuevas tecnologas de comunicaciones. Una de estas tecnologas novedosas es WiMAX, que opera en bandas de frecuencia y en condiciones para las cuales pocos modelos de canal desarrollados hasta el momento aplican de manera eciente, debido a que aquellos que ofrecen resultados ms aproximados a la realidad han sido construidos empricamente y su extrapolacin a otras bandas de trabajo y condiciones de operacin es compleja si se quie-
re garantizar exactitud razonable. Adicionalmente, gran cantidad de modelos consideran solo algunos fenmenos y en consecuencia deben aplicarse varios de ellos antes de obtener un resultado prctico. Es esto precisamente lo que hacen herramientas como ICS Telecom, que utiliza una interfaz para congurar los parmetros de simulacin en lo referente a los modelos de canal a utilizar y fenmenos a considerar; cada fenmeno se simula virtualmente por separado y luego se integran los resultados para entregar una respuesta nica. En cuanto a la clasicacin de los fenmenos de propagacin, independientemente de cul sea el fenmeno, el efecto total sobre la seal normalmente es una atenuacin o desvanecimiento (fading), por lo que dichos fenmenos tradicionalmente se han clasificado como se muestra en la Figura 2. Con esta gura se puede explicar por qu algunos modelos aplican slo a sistemas banda angosta, o por qu en ciertos ambientes es ms determinante un efecto que otro. De los fenmenos presentes, aquel que ha sido ms analizado en lo que va ejecutado del proyecto son las prdidas de trayecto o path losses, pues comprenden un alto porcentaje de las prdidas totales que experimenta la seal WiMAX al propagarse, incidiendo fuertemente en la cobertura del sistema y en las tasas de transmisin alcanzables. Los otros fenmenos como la multitrayectoria se describen/analizan generalmente con modelos basados en taps y las prdidas estimadas se adicionan a aquellas sucedidas en el trayecto de propagacin. No obstante, antes de entrar
17
Manifestaciones del desvanecimiento en el canal
Desvanecimiento de gran escala debido a movimientos sobre reas grandes Duales Atenuacin medio de la seal Vs. distancia Variaciones alrededor de la media Dispersin temporal de la seal
Desvanecimiento de pequea escala debido a pequeos cambios en la posicin
Variacin temporal del canal
Descripcin en el dominio del tiempo (retardo)
Transformada de Fourier
Descripcin en el dominio de la frecuencia
Descripcin en el dominio del tiempo
Transformada de Fourier
Descripcin en el dominio de la frecuencia (corrimiento Doppler)
Desvanecimiento selectivo en frecuencia
Desvanecimiento plano
Desvanecimiento selectivo en frecuencia
Desvanecimiento plano
Desvanecimiento rpido
Desvanecimiento lento
Desvanecimiento rpido
Desvanecimiento lento
Duales
Figura 2. Diferentes tipos de desvanecimiento [7].
en la descripcin de estos anlisis se presentarn en seguida algunos de los resultados de la primera fase del proyecto, consistente en la clasicacin general de los modelos de canal aplicados en radiocomunicaciones. III. CLASIFICACIN GENERAL Durante la revisin bibliogrfica 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 clasicaciones, como las presentadas en [5], [6] y [7], se concentran casi exclusivamente en la descripcin supercial de los modelos revisados, mas no en la generacin de una herramienta que permita escoger un modelo determinado para que sea aplicado en el diseo o estudio de un sistema particular. Por tal motivo se j desde el principio que uno de los objetivos del proyecto sera el desarrollo de una tabla general de clasicacin para los modelos de ca-
nal ms importantes con los cuales se cuenta en la actualidad. Para la clasicacin se tuvieron en cuenta inicialmente aspectos como la banda y los ambientes de aplicacin, al igual que las aplicaciones propiamente dichas (ver Figura 3), para posteriormente pasar a detallar un amplio conjunto de aspectos que se encuentran identicados en la Tabla I.
Tabla I. Aspectos considerados en la clasicacin de los modelos de canal inalmbricos. Tipo Tipo de zona de aplicacin Ambiente de aplicacin Clutter general Banda(s) de aplicacin Selectividad en frecuencia (WB o NB) rea de prediccin Exactitud Generalidad Implementado en software Edad [En desarrollo?] Proponentes Aplicacin (Tecnologas) Otras consideraciones para su aplicacin Formulacin matemtica Descripcin de parmetros Variables de entrada Variables de salida Complejidad computacional Formulacin lgica Referencias Enlaces y referencias
En total, se clasicaron 50 modelos de canal inalmbricos de acuerdo con los aspectos y parmetros mencionados (ver Tabla II), y se cuenta con des-
18
Figura 3. Descripcin de la tabla de clasicacin de modelos de canal.
cripciones breves de la formulacin matemtica y lgica, adems de las referencias completas para cada uno
Tabla II. Modelos de canal clasicados. Fiss model 2-ray model (ground reection) Knife-edge difraction model Multiple knife-edge difraction model Longley-Rice model Durkins model Okumura-hata model COST231 - Okumura-Hata model COST231 - Walsch-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 Walsch-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 Clarkes model for at 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
de ellos en caso de que quien utilice la tabla necesite profundizar ms en un modelo particular.
Algunos de los modelos estudiados ya han sido implementados en MatLab para realizar anlisis comparativos, y un subconjunto de ellos especficamente los macrocelulares fue implementado en el software de simulacin JavaDES desarrollado por el MSc. Roberto Hincapi, del GIDATI. En dicha implementacin no solo fueron considerados los efectos de propagacin sino que tambin se incluyeron aspectos relacionados con los modelos de movilidad y las distribuciones de trco en sistemas predominantemente celulares. La Figura 4 muestra una captura de la interfaz de simulacin del JavaDES. No obstante, la tabla general de clasicacin an se encuentra en proceso de revisin y depuracin para incrementar la utilidad de la herramienta que constituye dicha clasicacin.
19
Figura 4. Ambiente de simulacin del JavaDES [11].
IV. MODELOS APLICADOS A WiMAX Como se mencion anteriormente, la segunda fase del proyecto consiste en estudiar de manera ms profunda un subconjunto de los canales clasicados en la fase inicial, centrando el inters en aquellos que aplican particularmente al estndar 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 simulacin de los sistemas FWA.3 Para el caso particular de inters es importante tener en cuenta que la condicin en la cual operarn normalmente las redes WiMAX ser una condicin de NLOS, por lo que los modelos que asumen LOS deben ser desde ya obviados en el anlisis a realizar. Para el canal en condiciones de NLOS la seal puede
3 4 FWA: Fixed Wireless Access. RF: Radio Frequency.
experimentar dispersin, difraccin, cambios de polarizacin y reexin, factores que afectan la intensidad de la seal recibida. Se han desarrollado varios modelos que procuran caracterizar este ambiente de RF4 y permitir la prediccin de la intensidad de la seal de RF en recepcin, los cuales en su mayora estn basados en medidas empricas y son utilizados actualmente para predecir la cobertura a gran escala en sistemas celulares. Estos modelos proporcionan estimaciones de las prdidas de trayecto considerando la distancia entre el transmisor y el receptor, factores del terreno, altura de las antenas y frecuencias de operacin. Desafortunadamente ninguno de estos acercamientos trata adecuadamente las necesidades y las condiciones de los sistemas FWA.
20
En [2] se arma que AT&T ha realizado una gran cantidad de mediciones en varias reas a travs de los Estados Unidos para modelar con mayor exactitud el ambiente jo inalmbrico de RF. El modelo emprico de AT&T ya ha sido validado contra el despliegue de sistemas de acceso jo inalmbrico y ha arrojado resultados comparables. Este modelo es la base de un modelo aceptado en la industria y es utilizado por los grupos de estandarizacin como el IEEE 802.16 WG. El modelo de prdidas de trayecto de AT&T incluye parmetros 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 aos un conjunto de modelos de canal para la simulacin del fenmeno de multitrayectoria en sistemas LMDS.5 Estos modelos se denominan Stanford University Interim Models (comnmente abreviados SUI models). Los seis modelos SUI son una extensin del trabajo de AT&T y aplican para tres categoras de terreno: Tipo A: Colinas pequeas 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 categoras de terreno proporcionan un mtodo simple ms exacto para la estimacin de las prdidas de trayecto sobre el canal de RF en condiciones de NLOS. Al ser estadstica su naturaleza [9], el modelo puede
5 LMDS: Local Multipoint Distribution System.
representar una gran gama de las prdidas de trayecto experimentadas dentro de una comunicacin real en la banda de RF. Los modelos SUI fueron seleccionados para el diseo, el desarrollo y la prueba de las tecnologas 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 ms exactamente la cobertura que se puede alcanzar con una estacin base congurada de una manera determinada, lo que claramente es un apoyo a las actividades de planeacin y diseo de redes WiMAX. No obstante, existe un inconveniente prctico con los modelos SUI, y est relacionado precisamente con la clasicacin 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 clasicados existe una gran variedad de ellos que han sido obtenidos empricamente 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 recepcin estimada con varios modelos de prdidas de trayecto en condiciones equivalentes, donde es notable que en trminos generales la diferencia entre sus predicciones es de varios dB. Por este motivo es de gran importancia la seleccin del modelo de prdidas de trayecto a la hora de simular sistemas WiMAX y realizar
21
-60 -80 -100 -120 -140 -160 -180 -200 400

Friss Plane eart loss Path loss Clutter factor Okumura-Hata Walfisch-Ikegami
Potencia recibida dB
500
600
700
800
900
1000
1100
1200
1300
Frecuencia MHz
Figura 5. Curvas comparativas de Prx Vs. Frecuencia de operacin para varios modelos de path loss macrocelulares [11].
las labores de diseo de la red, pues algunos son ms optimistas que otros, y no todos aplican igual en las mismas condiciones topogrcas. En [8] se describe uno de los modelos de path loss adoptado por el IEEE 802.16 WG, el cual da las prdidas de trayecto segn la Ec. 1.
cual se asume una distribucin normal con desviacin estndar entre 8 y 10 dB.
Donde: A=20Log10(4 do/ ), con dada en metros. es el exponente de path loss dado por =(a-b*hb+c/hb), con la altura de la antena de estacin base 10m<hb<80m, y a,b y c son constantes dependientes del tipo de terreno. do es una distancia de referencia escogida de 100m. s representa el efecto del ensombrecimiento o shadowing, para el
Adicionalmente, en [8] se describen algunos factores de correccin necesarios para ajustar los modelos a las bandas cercanas a los 2GHz. Debido al ambiente dispersivo, el canal tiene un perl de retardos por el fenmeno de multitrayectoria. Este modelo de canal dispersivo en tiempo, tambin presentado en [8], es un tpico modelo de multitrayectoria basado en taps, y su parametrizacin conduce a los seis modelos SUI mencionados anteriormente. Para el caso de antenas directivas, el perl de retardo puede ser representado por una curva caracterizada por el retardo RMS del perl completo de retardos, el cual est dado por la Ec. 2.
22
La curva utilizada para el modelamiento del perl de retardo est dada por la Ec. 3, y los valores tpicos del retardo RMS en el canal inalmbrico estn en el rango de 0,1 a 5 s. Adi-
cionalmente se considera el efecto Doppler y un factor de correccin K para incluir las caractersticas que el canal presenta en condiciones de NLOS, es decir, denirlo como tipo Rice o tipo Rayleigh [8].
En trminos generales, para el diseo y optimizacin de redes FWA, los modelos utilizados son de tipo emprico, tanto para los clculos de path loss (modelos empricos no dispersivos en el tiempo) como para los anlisis de multitrayectoria (modelos empricos dispersivos en el tiempo). En [12] son presentados varios modelos empricos no dispersivos en tiempo, los cuales permiten calcular path loss de manera aproximada en la mayora de los casos. De todos los clasicados, son raros los modelos empricos que proporcionan informacin sobre dispersin en el tiempo, y los pocos que existen son muy similares. Al predecir las prdidas medias en el trayecto basndose en un conjunto de mediciones, podra utilizarse un modelo correspondiente de dispersin temporal para obtener el perl de retardo temporal de cada curva derivada estadsticamente, o mediante tabulacin de datos, siendo sta una forma de predecir la dispersin en el tiempo causada por algunos ambientes basndose en sus caractersticas [12]. Un ejemplo de este tipo de modelos son los SUI descritos anteriormente. Tambin existe la alternativa de aplicar o desarrollar modelos fsicos basados en los principios fsicos de la radiopropagacin (normalmente
en la ptica geomtrica) ms que en estadsticas obtenidas de conjuntos de mediciones. Se encuentran muchos modelos de este tipo descritos en la mayora de la bibliografa existente sobre el tema, pero son modelos cuya exactitud, capacidad y xito en las predicciones depende de la informacin que se tenga acerca del ambiente geogrco de operacin del sistema en estudio. Estos modelos pueden estar o no orientados a un sitio especco, y no solo deben aplicar las leyes fsicas del electromagnetismo sino que deben incluir tambin una tcnica sistemtica para mapear el ambiente real de propagacin dentro del modelo mismo [12]. No obstante, existen modelos fsicos no dispersivos en tiempo y orientados a sitio especco, como por ejemplo el modelo geomtrico de trazado de rayos en dos dimensiones (2D Ray Tracing model), mejor conocido como el modelo de Anderson. Otro ejemplo posiblemente ms conocido es el modelo Longley-Rice, que ha sido implementado en la mayora de las herramientas computacionales para diseo de redes inalmbricas y radioenlaces. Este tipo de modelos aplica muy bien para el diseo de redes de acceso jo inalmbrico; pero hay un tercer grupo de modelos fsicos que estn orientados a sitio especco y adems son dispersivos en tiempo.
23
Estos modelos aplican las leyes fsicas de manera muy precisa sobre cartografa detallada del ambiente real de operacin; rastrean la trayectoria de las ondas electromagnticas cuando dejan el transmisor e interactan con objetos en el ambiente. Esto no solo proporciona informacin sobre la dispersin en el tiempo sino tambin informacin sobre el ngulo de llegada que es de gran inters para sistemas que utilizan antenas adaptativas, por ejemplo. Es claro entonces que para la adecuada planeacin y diseo de redes WiMAX se necesita la combinacin de modelos predictivos tanto de prdidas medias en el trayecto como de fenmenos de multitrayectoria. En cuanto a los modelos de path loss, hasta el momento se han estudiado los mencionados anteriormente ms algunas modicaciones realizadas al modelo de Hata descritas brevemente en [10]. Y en lo referente a los modelos de multipath y consideracin de otros fenmenos, se han revisado los modelos propuestos por Stanford y sus variantes para la banda de 3,5GHz descritas en [8] y [10]. En trminos generales, todas las propuestas para el modelamiento de canales aplicable a WiMAX giran en torno a estos modelos y sus variantes. Algunos modelos de path loss, como el de Walsh-Ikegami por ejemplo, tienden a ser demasiado optimistas para zonas urbanas, las cuales son de principal inters para los operadores WiMAX, y adems tienen el inconveniente de ser aplicables slo dentro de ciertas bandas de trabajo que no sern de implementacin comercial inmediata. El modelo de COST-231 Hata tiene la misma limitacin, pero
por ser el modelo tradicionalmente aplicado para el clculo de path loss y para la prediccin de niveles de recepcin, ha sido extrapolado hasta la banda de 4GHz. El modelo resultante es descrito en [10] de manera comparativa con otros dos modelos: el ECC-33 [13] y el modelo de path loss tomado para SUI y adaptado a FWA, como se describi anteriormente. El modelo de path loss de Hata, ajustado y extrapolado hasta 4GHz, muestra que la atenuacin en dB tiene una funcin de distribucin de probabilidad gaussiana con media A50 (ver Ec. 4) y determinada desviacin estndar (ver Ec. 4). El IEEE 802.16 WG ha adoptado tambin este modelo como el modelo de path loss para el diseo de redes WiMAX, y es ms conocido como el modelo ECC-33 [13]. Dicho modelo de propagacin es path loss con atenuacin aleatoria, teniendo en cuenta difraccin sobre tejados y mltiples reexiones para media/alta cantidad de edicaciones, muy tpico de Japn, al igual que sus versiones anteriores. Aplica a ciudades grandes y medianas, e indica adems correcciones para reas suburbanas y reas abiertas. Las distancias lmite son menores a 10 km y las alturas de antena oscilan entre 20 y 200 metros. El resultado de la extrapolacin es que la seal recibida est dada por:
Donde: Afs=92,4+20Log(D)+20log(RF), son las prdidas espacio libre. A bm=20,41+9,83Log(D)+7,894Log(RF)+ 9,56[log(RF)]2, prdida media bsica de trayecto. GC=Log(hc/200){13,958+5.8[Log(D)]2}, ganancia en BS.
24
G T=[42,57+13,7Log(RF)][Log(h t)0,585] para ciudades medianas y GT=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 dispersin temporal que tambin son empricos 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 denen dos modelos para cada uno de los tipos de terreno (clutter) y hacen un total de seis clasicaciones. En [14] los autores exponen algunos aspectos encontrados inconsistentes en los modelos SUI, relacionados con el corrimiento Doppler en multitrayectoria, el perl potenciaretardo, los patrones de radiacin considerados, los valores asumidos para el factor K, y la funcin de correlacin de frecuencia. De cualquier manera, los modelos SUI fueron desarrollados especcamente para uso en la 6 banda de frecuencias de MMDS en Norteamrica. En [8] se arma que el modelo podra desempearse 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 operacin comercial de WiMAX. La ecuacin de path loss en los modelos SUI fue derivada bsicamente de mediciones en reas suburbanas, y hasta el momento no se han incluido factores de correccin para zonas urbanas o de alta densidad de edicios, ni para zonas rurales. Adems, tampoco hay manera de relacionar los tres tipos
o categoras de terreno a los clutters comnmente disponibles o a bases de datos de terreno, as que el mtodo para seleccionar la categora a aplicar en algn escenario de despliegue de un sistema particular no es sistemtico. Las medidas fueron tomadas a distancias cercanas a los 7 km, las cuales son adecuadas para la evaluacin de cobertura y servicio; sin embargo, para redes FWA multicelda en las cuales se necesita la reutilizacin de frecuencias, se requieren los niveles de interferencia de la seal desde celdas que pueden estar alejadas varios radios de celda. Los modelos SUI no ofrecen orientacin sobre path loss a estas distancias, y como se arma en [12] se puede esperar que los valores de path loss arrojados por los SUI extrapolados a estas distancias pudieran casi ciertamente ser ms grandes que aquellos experimentados en los sistemas reales. Por otro lado, hay gran variedad de modelos basados en la tcnica de ray-tracing. Dichos modelos fsicos que pueden ser bidimensionales o tridimensionales han demostrado tener los niveles de exactitud ms altos en las pruebas comparativas, como se muestra en [12], limitados casi exclusivamente por el nivel de detalle de la informacin cartogrca proporcionada. Adicionalmente estos modelos realizan clculos de reflexin, difraccin, 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, prdidas 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 tcnicas de raytracing cuando se utiliza cartografa de alta denicin.
Figura 6. Comparacin de modelos predictivos aplicables a diseo de rdes WiMAX [12].
V. SIMULACIONES E IMPLEMENTACIONES Hace un par de aos el requerimiento de algunos modelos a los que se les proporcion informacin muy detallada del sitio especco en el cual se va a desplegar la red era visto como una desventaja porque se dispona de pocas bases de datos con informacin de ese tipo. No obstante, en la actualidad existe cartografa de alta resolucin de muchas zonas de inters para el despliegue de infraestructura y para el ofrecimiento de servicios, lo que convierte a los modelos fsicos especialmente los geomtricos en muy buenos candidatos para apoyar las actividades de planeacin y diseo de redes WiMAX. No obstante, aunque el GIDATI cuenta con cartografa de alta resolucin de Medelln, no se ha profundizado an en el estudio
de este tipo de modelos y hasta el momento se han aplicado las conguraciones que por defecto permite el software ICS Telecom, concentrando la atencin por el momento en las implicaciones que tiene la seleccin de modelo de path loss en la exactitud de los resultados. Para la planeacin de redes WiMAX, es entonces de gran inters que los modelos utilizados proporcionen exibilidad a los procesos y los doten de gran exactitud. Por este motivo, para la investigacin actual se han seleccionado cinco modelos para su implementacin y para la realizacin de comparaciones mediante los resultados de simulacin: Modelo ECC-33: Es una modicacin del conocido modelo de Okumura-Hata, que permite
26
ajustarlo a condiciones de operacin banda ancha y ambientes de alta inuencia multitrayectoria. Modelos SUI: Son los Stanford University Interim, que en total son seis y actualmente los ms aplicados en el estudio de la tecnologa WiMAX. 3D Intelligent Ray Tracing: Desarrollado principalmente en Stuttgart University. Es un modelo geomtrico algo complejo, pero considerando que se cuenta con informacin cartogrfica detallada, su implementacin deber ofrecer buenos resultados. Urban Dominant Path Model: Tambin desarrollado en Stuttgart University, es una modicacin del anterior que identica
los trayectos dominantes en la comunicacin y considera slo las seales relacionadas con esos trayectos reduciendo as el volumen de clculos a realizar. Walden-Rowsell model: Es un modelo emprico 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 creacin de un modelo genrico de la capa fsica de sistemas WiMAX sobre Network Simulator 2, debido a que es el que mejor aproximacin a datos reales presenta. En la Tabla III se realiza una comparacin de cuatro de los cinco modelos seleccionados.
Tabla III. Comparacin de modelos predictivos aplicables a diseo de redes WiMAX. Modelos empricos (SUI y ECC-33) X X X X DPM 3DRT
Rural X Urbano X X Interiores X X Intensidad del campo, Prdidas de trayecto, Potencia X X Delay Spread X Resultados Angular Spread X LOS/NLOS X X X Respuesta impulsiva del canal X Rayo directo X X X Reexiones Incluido Ilimitado Difracciones Ilimitado 2 Clculos Reexiones y difracciones XX Reexin, difraccin y transmisin X X Multitrayectoria X Respuesta impulsiva del canal X reas grandes X rea de prediccin reas medianas X X reas pequeas X X X Cerca del transmisor Satisface Muy alta Muy alta* Exactitud Lejos del transmisor Limitada Muy alta Media* Prediccin Muy baja Corta Corta* Tiempo de clculo Preprocesamiento Ninguno Ninguno Medio* * dependiendo de la conguracin del modelo (ej. Nmero de interacciones) Escenario
27
En la actualidad, la mayora de las herramientas software que asisten actividades de diseo de redes incluida ICS Telecom de ATDI , aplican los tres tipos de orientaciones de manera individual. Por ejemplo, como se describe en [16] y [17], es comn aplicar modelos de path loss como el ITU-R P.525/526 junto con un modelo geomtrico de difraccin como el de Deygout, una integracin media para atenuaciones en subtrayectos, y un modelo geomtrico reectivo 2D o 3D para anlisis de multitrayectoria y efecto can. La intencin entonces de combinar estos diferentes tipos de modelos es la validacin de los 7 SUI en actividades de diseo real, y la aplicacin de conceptos de raytracing en un modelo completo sobre la herramienta ICS Telecom, para lo cual se cuenta con cartografa de alta resolucin de la zona metropolitana de Medelln. Como ya se mencion, con SUI se tiene el inconveniente de que los modelos no aplican a zonas urbanas ni rurales; con el modelo ECC- 33 se tiene el problema de que es el resultado de una extrapolacin de un modelo que desde antes se presentaba como demasiado optimista en las predicciones para zonas rurales; y con ray-tracing existe un requerimiento en procesamiento que no se tiene con los dos modelos anteriores. La implementacin de estos cinco modelos permitir determinar cul es la combinacin adecuada de orientaciones en modelamiento de canales para el diseo de redes WiMAX.
VI. RESULTADOS OBTENIDOS Y PROYECTADOS Varios investigadores ya han realizado comparaciones entre los modelos seleccionados y han sacado conclusiones importantes. En [10], los autores analizan brevemente el modelo COST-231 Hata, el modelo ECC- 33 y los modelos SUI aplicados al clculo de path loss y comparan los resultados con mediciones reales. La Figura 7 muestra el resultado grco de la comparacin para una zona urbana, que como ya se ha dicho es de especial inters para los operadores de redes WiMAX. No obstante, una vez que estos modelos sean implementados en ICS Telecom, se espera que los resultados varen un poco considerando la topografa colombiana, y precisamente determinar esas variaciones y los factores ms inuyentes es otro de los objetivos del proyecto. Actualmente se lleva a cabo una campaa de simulacin que utiliza la cartografa de alta resolucin y la herramienta ICS Telecom con diversas conguraciones de los parmetros del modelo de propagacin aplicado, con el objetivo de comparar la incidencia de stos en las predicciones y determinar posteriormente el grado de aproximacin de cada conguracin a los datos reales obtenidos mediante pruebas de drive test. En la Figura 8 se muestra la prediccin de cobertura para la zona suburbana de la Universidad Ponticia Bolivariana, realizada aplicando el modelo COST-231 Hata, con alturas
Las simulaciones actuales se estn realizando con ICS Telecom nG versin 7. La nueva versin del software cuenta ya con implementaciones de los modelos SUI, lo que proporciona otra alternativa para validacin de resultados.
28
Figura 7. Comparacin de modelos empricos con mediciones en un ambiente tpico urbano [10].
de antena de estacin base y estacin suscriptora iguales a 12m y 4m respectivamente, potencia de transmisin 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 codicacin/modulacin 3/4 64-QAM (aunque el valor de estos dos ltimos parmetros es indiferente).
Figura 8. Prediccin 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 ms optimista que COST231 Hata. En general, los modelos de Hata se comportan ms pesimistas
que otros modelos en zonas distintas a Japn, y de hecho, ese fue motivo por el cual se seleccion el modelo de Walden-Rowsell para el otro proyecto mencionado.
Figura. 9. Prediccin de cobertura para WiMAX a 3,5 GHz usando el modelo ITU-R 525.
Las campaas de simulacin incluyen una amplia variacin de los parmetros de conguracin de los modelos, y estn llevndose a cabo mientras se termina la construccin de las DLL que permitan realizar simulaciones adicionales de los modelos seleccionados. Los resultados sern utilizados en el presente proyecto y en otros que se ejecutan de forma paralela al interior del GIDATI, y permiten la validacin de resultados y la formulacin de propuestas para futuros proyectos.
VII. CONCLUSIONES Y RECOMENDACIONES Como se describi a lo largo del artculo, debido a las limitaciones citadas los modelos SUI son ms apropiados para propsitos de dimensionamiento o de desarrollo de equipos que para la planeacin y diseo detallados de la red WiMAX en locaciones especcas. Para propsitos de planeacin son ms apropiados los modelos fsicos que puedan explotar la informacin detallada que se tenga del terreno, del clutter, y de las edicaciones circundantes.
30
Las simulaciones realizadas han proporcionado informacin suciente para empezar a determinar qu factores son los que mayormente impactan en la seleccin del modelo de canal a utilizar, y cmo esto afecta las actividades de planeacin y diseo. De esta manera se presenta la tabla de clasicacin de canales como una herramienta propiamente dicha diseada para asistir en las labores de ingeniera 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 probabilsticos, pues los resultados siempre son los mismos con las mismas condiciones generales, pero se ha asumido en las campaas que los datos corresponden a valores medios estimados en cada punto de la cartografa. 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 clasicar los modelos existentes/disponibles estudiados ha facilitado el desarrollo de las actividades acadmicas y tambin de las ingenieriles como la planeacin y el diseo de redes inalmbricas. El desarrollo de cuadros clasicatorios y comparativos para los diferentes modelos de canal aplicables, permite que la creacin y/u optimizacin de herramientas software para planeacin, diseo
y simulacin de redes sea ms eciente. Los resultados son en s mismos un instrumento de estudio e ingeniera. AGRADECIMIENTOS Los autores expresan sus agradecimientos a la empresa TES Amrica Andina Ltda. por facilitar la cartografa sobre la cual se estn desarrollando las campaas de simulacin. Tambin al ingeniero Nstor 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 ejecucin del proyecto. BIBLIOGRAFA [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. WiMAXs technology for LOS and NLOS environments. WiMAX Forum. Mountain View. 2003. 10p
[3] A. Aguiar y J. Gross. Wireless channels models. Technical University Berlin. Berln. Telecommunications Networks Group. 2003. 54p. [4] S. Saunders. Antenas and propagation for wireless communication systems. Londres. John Wiley & Sons. 1999. T. Rappaport. Wireless communications: Principles and practice. Indianapolis. Prentice Hall. 2002. 736p. P. Smulders, et al. State of the art channel modeling. Broadband Radio@Hand. 2002. 45p.
[5]
[6]
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. IEEE 802.16.3c00/47. Channel Models for Broadband Fixed Wireless Systems. IEEE 802.16 Working Group. Nueva York. 2000. 7p. IEEE 802.16.3c00/49r2. Interim Channel Models for G2 MMDS Fixed Wireless Applications. IEEE 802.16 Working Group. Nueva York. 2000. 13p.
[15] E. Grenier. Signal propagation modeling in urban environment. ATDI. Pars. 2005. 18p. [16] Radio propagation in ICS Telecom: Training resources. ATDI; Pars. 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. CURRCULOS Alexnder Galvis Quintero {alexander.galvis@upb.edu.co} es ingeniero en Electrnica y Telecomunicaciones de la Universidad del Cauca (Popayn, 2005) y candidato a Magster en Ingeniera con nfasis en Telecomunicaciones en la Universidad Ponticia Bolivariana. Actualmente se desempea como investigador y docente en dicha institucin, adems de coordinar el Semillero de Tecnologas Inalmbricas (STI). Temas de inters: Radiocomunicaciones, modelamiento de canales, Software Dened Radio, coexistencia e interoperabilidad inalmbrica, simulacin. Cristina Gmez Santamara {cristina.gomez@upb.edu.co} recibi sus ttulos de Ingeniera Electrnica y de Magster en Ingeniera con nfasis en Telecomunicaciones de la Universidad Ponticia Bolivariana (Medelln, 2002 y 2005 respectivamente). Actualmente es candidata a
[8]
[9]
[10] V.S. Abhayawardhana, et al. Comparison of empirical propagation path loss models for Fixed Wireless Access systems. BT Mobility Research Unit. Ipswich. 2004. 5p. [11] A. Galvis, C. Gmez, R. Hincapi y N. Bayona. Modelamiento de canales inalmbricos: Estado del arte, clasicacin y simulacin. Memorias JIDTEL/5 Congreso Nacional ETI TECNOCOM2005. Medelln. 2005. 10p. [12] H.R. Anderson. Fixed broadband wireless systems design. John Willey & Sons Ltd. Surrey. 2003. 526p. [13] ECC Report 33. The analysis of the coexistence of FWA cells in the 3,4 3,8 GHz band. ECC/ CEPT. Cavtat. 2003. 72p. [14] A. Sarajedini, et al. Issues with the interim broadband xed wireless channel model. IEEE 802.16 WG y BeamReach Networks. Mountain View. 2001. 7p.
32
Doctora en Ingeniera en la misma institucin, y su trabajo est relacionado con el modelamiento de canales espacio-temporales. Temas de inters: Radiocomunicaciones, modelamiento de canales, MIMO, WiMAX. Roberto Carlos Hincapi Reyes {roberto.hincapie@upb.edu.co} recibi sus ttulos de Ingeniero Electrnica y de Magster en Ingeniera con nfasis en Telecomunicaciones de la Universidad
Ponticia Bolivariana (Medelln, 1996 y 2004 respectivamente). Actualmente es candidato a Doctor en Ingeniera en la misma institucin, y su trabajo est relacionado con el modelamiento de capas superiores de sistemas inalmbricos. Temas de inters: Radiocomunicaciones, planicadores, QoS en sistemas inalmbricos, redes mesh y ad hoc, simulacin, WiMAX.
33
34
Plataforma de acceso universal a mensajera instantnea mvil

Miembro del Grupo de Ingeniera Telemtica (GIT), Universidad del Cauca
O. M. Caicedo* D. A. Caicedo* E. Figueroa*
F. O. Martnez,* J. A. Hurtado*
Miembro del Grupo de Ingeniera Telemtica (GIT), Universidad del Cauca Fecha de recepcin: 30-05-06 Fecha de seleccin: 30-10-06
ABSTRACT 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.
KEYWORDS Interoperability, Instant Messaging, Mobility, Jabber, Transport RESUMEN En la actualidad uno de los servicios ms exitosos es la mensajera instantnea, gracias a la versatilidad y simplicidad de comunicacin que ofrece a los usuarios, una caracterstica clave en el exigente entorno de conectividad y movilidad que demanda la sociedad. Con el xito de la telefona mvil, nuevos horizontes hicieron su aparicin para este tipo de servicios; sin embargo, la diversidad de protocolos y tecnologas de transporte tambin se hizo ms diversa y
O. M. Caicedo, E. Figueroa, D. A. Caicedo, F. O. Martnez y J. A. Hurtado son miembros del grupo de inters en Desarrollo de Aplicaciones Mviles e Inalmbricas W@PColombia perteneciente al Grupo de Ingeniera Telemtica (GIT), Universidad del Cauca, Calle 5 No. 4-70 Popayn, Colombia. (e-mail: {omcaicedo, dacaicedo, egueroa, fomarti, javhur}@unicauca.edu.co).
35
dio origen a un ambiente de baja y compleja interoperabilidad. El presente artculo describe la plataforma PAUMIM (Plataforma de Acceso Universal a Mensajera Instantnea Mvil), propuesta por el grupo de inters en Desarrollo de Aplicaciones Inalmbricas Mviles e Inalmbricas (W@PColombia) del Grupo de Ingeniera Telemtica
(GIT) de la Universidad del Cauca, para la comunicacin entre distintos proveedores de este servicio, a travs del uso de dispositivos mviles. PALABRAS CLAVE Interoperabilidad, Mensajera Instantnea, Movilidad, Transportes, Jabber. Clasicacin Colciencias: A
36
I. INTRODUCCIN En la actualidad el continuo crecimiento de internet brinda a los usuarios nuevos servicios soportados sobre tecnologas de banda ancha, los cuales les ofrecen alternativas para agilizar su trabajo, incursionar en el mundo de la informacin y el entretenimiento. Para llevar a cabo comunicaciones simples y de forma inmediata, uno de los servicios ms utilizados es el de Mensajera Instantnea caracterizado por su amplia acogida y rpida expansin alrededor del mundo. Las ventajas del servicio de mensajera instantnea 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 comunicacin interactiva entre los trabajadores, y compartir recursos y conocimientos, como una alternativa a los servicios de comunicacin actuales como la telefona ja o mvil. En el campo del entretenimiento, en los ltimos aos el uso de este servicio ha cobrado mucha importancia y ofrece a los usuarios un medio inmediato para comunicarse con la familia, compaeros y amigos [1]. El principal problema que presenta la mensajera instantnea mvil y ja es la coexistencia de varias redes [2], cada una de ellas con aplicaciones y protocolos distintos que dicultan la interoperabilidad entre los diferentes proveedores, imposibilitando una verdadera comunicacin universal entre los usuarios a cualquier hora y lugar. Surge entonces la necesidad de garantizar la interoperabilidad entre los diferentes proveedores de mensajera
instantnea y proveer movilidad a los usuarios del servicio. El grupo de inters en el desarrollo de aplicaciones mviles e inalmbricas w@pcolombia del Grupo de Ingeniera Telemtica (GIT) plantea la creacin de una plataforma de acceso universal a mensajera instantnea mvil (PAUMIM), que ser descrita de la siguiente forma: en la seccin II se presentan los conceptos asociados a la mensajera instantnea tanto ja como mvil; en la seccin III se describe con ms detalle el protocolo de mensajera instantnea Jabber, como ncleo de la plataforma construida; en la seccin IV se describe la plataforma en s; en la seccin V, el entorno de experimentacin y pruebas; y nalmente en la seccin VI se presentan las conclusiones del trabajo realizado. II. MENSAJERA INSTANTNEA A. Denicin El trmino mensajera instantnea hace referencia en internet a la posibilidad de establecer conversaciones de texto en directo entre individuos [3]. Pero a diferencia de los chat, esta comunicacin no se establece en una sala en la que hay ms personas, sino de forma exclusiva entre los dos individuos involucrados, por lo tanto se considera como un punto intermedio entre los sistemas de chat y los mensajes de correo electrnico. Las herramientas de mensajera instantnea son programas regularmente gratuitos y verstiles, de fcil instalacin y uso, que requieren una conexin a Internet para su activacin. Dichos programas permiten realizar conversaciones de texto,
37
envo de archivos y videoconferencia entre otros servicios [3]. B. Proveedores de mensajera instantnea La mensajera instantnea ha ganado popularidad en forma abrumadora. En los ltimos aos el nmero 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 nmero total de usuarios de Internet [4]. A continuacin se identican las herramientas de mensajera instantnea ms importantes. ICQ: Fue el primer sistema de mensajera instantnea que sali al mercado y proporcion una nueva alternativa a los sistemas de chat convencionales, logrndolo con xito [3]. La ltima versin disponible, adems de funciones como ICQPhone que incorpora telefona IP para hacer llamadas entre computadores o de estos a telfonos convencionales, tecnologa SMS (Short Message Service) [5], integracin con Outlook y ms, ofrece una nueva coleccin de iconos (emoticons), que facilitan el envo de mensajes y las intenciones de comunicacin. MSN Messenger: Pertenece a Microsoft Networks, es un sistema eciente cuya principal ventaja, adems de su sencillez de uso, es su integracin con Hotmail y MSN, la red de contenido de Microsoft, con la estrategia. Net. [3]. El servicio de mensajera de Microsoft ofrece chat, video llamadas, conferencia, transferencia de archivos, iconos gestuales, pizarra, envo de mensajes SMS, entre otras funcionalidades.
Yahoo Messenger: Es una de las alternativas de mensajera instantnea ms fresca, y mejor integrada con la plataforma de servicios de la marca (Yahoo!) como el correo electrnico y geocities, de manera que su uso resulta transparente [3]. AIM (American-On-Line Instant Messenger): Sus prestaciones avanzadas incluyen la comunicacin entre computadores o de computadores a telfonos convencionales; para hacerlo requiere un proveedor que soporte el servicio. Tambin permite congurar alertas para correo electrnico y leer los mensajes de cualquiera de sus cuentas [3]. C. Protocolos abiertos de mensajera instantnea Dentro de las iniciativas ms importantes que se han propuesto para la normalizacin y estandarizacin del servicio de mensajera instantnea 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 sesin, dondequiera que se encuentren. Estas sesiones permiten establecer comunicacin entre los usuarios para poder intercambiar distintas clases de informacin como voz, video, mensajes y datos.
38
Jabber: Es un conjunto de protocolos XML de ujos de descarga (Streaming) y tecnologas que permiten que dos entidades en internet intercambien mensajes, informacin de presencia, y otra informacin estructurada en tiempos cercanos al real [11]. Jabber se encuentra soportado en miles de servidores de internet y es usado por ms de seis millones de personas en todo el mundo; a pesar de esto, se encuentra menos difundido que muchos sistemas propietarios. D. Mensajera mvil JIMM: Jimm es un clon ICQ para dispositivos mviles, especcamente para telfonos celulares, basado en Java 2 Micro Edition [12]. Jimm no representa ningn producto de ICQ, inc. La distribucin de Jimm es pblica con la licencia GNU General Public License (GPL) [15]. JXME JXTA for J2ME: El proyecto JXTA es una plataforma abierta de programacin para servicios y aplicaciones P2P (Peer to peer). El propsito del proyecto JXTA para J2ME es proveer funcionalidades compatibles JXTA usando dispositivos que soporten Java [16]-[17]-[18]. Mobber: Es un sistema de mensajera instantnea propietario basado en el protocolo Jabber, orientado al acceso desde dispositivos mviles. En la actualidad se encuentra en desarrollo, no hay versiones con funcionalidad estable y la documentacin es muy escasa. El sistema Mobber est compuesto por un servidor propietario y una aplicacin J2ME de libre distribucin para el cliente mvil, desde la cual se puede establecer comunicacin con contactos de diferentes proveedores de mensajera, con la restriccin de que el acceso se debe
hacer desde una cuenta del servidor Mobber [19]. III. JABER Jabber es un conjunto de protocolos de libre distribucin, cuenta con una comunidad de desarrollo muy grande y dentro de sus principios fundamentales est la interoperabilidad con otros sistemas de mensajera[14], razn por la cual ha sido elegido como el stack de protocolos para la plataforma PAUMIM. Entre sus caractersticas ms importantes, Jabber cuenta con un stack de protocolos basado en XML, lo cual hace posible su interpretacin por diferentes sistemas operativos y plataformas, no es centralizado y es altamente extensible a travs de la adicin de componentes. Por otro lado, Jabber brinda soporte SSL (Secure Socket Layer) para comunicaciones cliente/servidor y para algunos clientes soporta la extensin GPG (GNU Privacy Guard) para rmar informacin de presencia y cifrar las comunicaciones punto a punto usando modelo asimtrico [20]. A continuacin se realiza una breve descripcin del stack de protocolos de Jabber. A. Protocolo de mensajera El protocolo de gestin de mensajes Jabber es simple pero poderoso. Por defecto, no se recibe confirmacin sobre la llegada de un mensaje a su destino para reducir el trco en el servidor; por otro lado, si el receptor no se encuentra disponible el servidor guardar el mensaje hasta que ste se conecte [9]. B. Protocolo de presencia Una de las grandes diferencias que existen entre la mensajera instan-
39
tnea y el correo electrnico es que los usuarios tienen la posibilidad de conocer el estado de otros usuarios. Jabber ofrece la posibilidad de establecer tantos estados diferentes como el usuario desee. Una de las prioridades ms altas tenidas en cuenta en el protocolo Jabber 3 es la intimidad de los usuarios. Por lo tanto, si un usuario quiere agregar a otro en su lista de contactos y recibir su informacin de presencia, deber hacer una peticin al servidor, y si el otro usuario acepta, entonces se podr ver su estado [21]. C. Protocolo de grupo de chat Gestiona la comunicacin entre usuarios de un grupo de chat [11]. Existen cuatro acciones fundamentales: Unirse al grupo: Enviando un mensaje de presencia de tipo disponible (available) al grupo. Enviar mensajes a todo el grupo: Enviando un mensaje al grupo deseado, al cual previamente el usuario ha debido unirse. Enviar mensajes a un nico miembro del grupo: Enviando un mensaje a una persona especca del grupo. Abandonar el grupo: Enviando un mensaje no disponible (unavailable) de presencia al grupo. D. Protocolo de informacin-solicitud (IQ- Inf o- Query) Es un protocolo sencillo y extensible de peticin/respuesta que permite a los usuarios hacer peticiones y almacenar o cambiar datos. IQ es simplemente el conductor de esas peticiones y respuestas, y gestiona los datos que son necesarios de acuerdo con las conveniencias particulares de cada
servidor. La mayora de las peticiones IQ son entre un cliente y un servidor. Sin embargo, hay algunos protocolos de IQ que van estrictamente de un cliente a otro, como el protocolo de peticin de versin del cliente, en el cual un cliente le pide a otro su versin del programa [11]. E. Protocolo de registro El primer paso para albergar usuarios en el servidor Jabber es la creacin de cuentas mediante una extensin del protocolo IQ. En los servidores pblicos, y en su ms pura esencia, las cuentas de usuario no son ms que unos repositorios de credenciales que los clientes usan para autenticarse con el servidor. Adems de estos datos bsicos, muchos servidores asocian otros a la cuenta de usuario. Aunque el manejo y almacenamiento de las cuentas de usuario puede ser algo complicado, la implementacin del protocolo de registro no lo es. El protocolo de registro normalmente suele ser junto con el de autenticacin el nico protocolo que un usuario sin autenticar puede usar de un servidor Jabber [11]. F. Protocolo de autenticacin El protocolo de autenticacin de Jabber, al igual que el de registro, es una extensin del protocolo IQ. Es uno de los protocolos dedicados nicamente a la seguridad en Jabber basado en SASL (Simple Authentication and Security Layer). Este protocolo permite a un usuario demostrar al servidor que realmente es quien dice ser. El sistema de autenticacin y acceso a un servidor es simple: los clientes no autenticados tienen una serie de permisos restringidos, y los clientes
40
autenticados tienen un completo acceso al uso de todos los protocolos Jabber que estn implementados en el servidor del dominio al que pertenecen. El protocolo de autenticacin ofrece cuatro niveles diferentes de autenticacin: Anonymous: Si el servidor admite usuarios annimos basta con el envo de la peticin IQ sin ningn otro tipo de dato y el usuario puede validar una sesin con el servidor. Plain: Funciona enviando dentro del mensaje de autenticacin la contrasea sin codicar en formato de texto. Digest: Mediante este tipo de autenticacin el servidor enva un identicador de sesin junto con la etiqueta de inicio de sesin. Para generar la autenticacin, el cliente concatena el identicador de la sesin con la contrasea del usuario. La cadena resultante es codicada usando el algoritmo SHA-1 (Secure Hash Standard - 1). Zero-knowledge: Es el formato ms seguro y ms complicado soportado por los protocolos Jabber. Este mtodo de autenticacin es complejo y su adopcin tanto en servidores como en clientes ralentiza el proceso de autenticacin. Este tipo de autenticacin ya no guarda la contrasea del usuario en el servidor. De hecho, la informacin que el servidor guarda son las credenciales que slo sirven para una nica autenticacin del cliente. El servidor ir creando nuevas credenciales de nico uso [11]. G. Protocolo Roster Para no enviar los cambios de presencia entre todos los usuarios del sistema, Jabber ha creado el concepto
de suscripcin de presencia. Como su nombre lo indica, la suscripcin de presencia determina los suscriptores que recibirn las actualizaciones de presencia de cada usuario. Los suscriptores piden una suscripcin a un usuario, y el usuario acepta o deniega dicha suscripcin. Cada usuario se suscribe a los usuarios que desea y puede aceptar que dichos usuarios u otros se suscriban a los cambios de su presencia. Para realizar esta tarea, Jabber ha denido unas estructuras de datos estndar conocidas como Jabber Roster, que no son ms que una lista de otros usuarios identicados por su Jabber ID [11]. H. Transportes entre Jabber y otros servidores de mensajera instantnea Debido a que Jabber es un protocolo libre basado en el intercambio de paquetes en formato XML, los sistemas Jabber estn concebidos como un sistema genrico de transporte de mensajera instantnea. Su diseo simple ha sido explotado por servidores Jabber para conectarse con otros sistemas de mensajera instantnea como MSN Messenger y Yahoo! Messenger. El servidor Jabber de referencia jabberd utiliza mdulos llamados transportes (transport) que proveen un puente entre Jabber y los dems sistemas de Mensajera Instantnea. Los transportes tratan a cada sistema de mensajera instantnea propietario como un dominio Jabber con sus propios clientes identicndolos por su Jabber ID. Al enviar un mensaje Jabber a uno de esos mdulos, los Jabber IDs especiales hacen que
41
sean transportados por el mdulo de transporte. Los mdulos de transporte conectan con el sistema de mensajera 4 instantnea correspondiente y actan como clientes de ese servidor para intercambiar mensajes y presencia entre los dos sistemas. Cada transporte debe hacer la traduccin de los mensajes Jabber al formato respectivo del sistema de mensajera instantnea correspondiente [11].
IV. PLATAFORMA DE ACCESO UNIVERSAL A MENSAJERA INSTANTNEA MVIL PAUMIM A. Arquitectura La Figura 1 ilustra la arquitectura de la Plataforma de Acceso Universal a Mensajera Instantnea Mvil, PAUMIM, la cual consta de los siguientes mdulos:
Figura 1. Arquitectura de la plataforma PAUMIM.
Mdulo administrativo: Permite realizar la administracin y mantenimiento de la plataforma PAUMIM mediante acceso Web. Entre las funcionalidades que brinda se encuentra la capacidad de gestionar usuarios mediante su adicin, edicin y eliminacin de la plataforma, y el establecimiento de comunicacin directa entre el administrador de la plataforma y el usuario por medio de
mensajes. El administrador tiene a su disposicin informacin estadstica con respecto al uso de la plataforma a travs de grcos que le permiten visualizar el nmero de usuarios conectados, trco cursado e informacin de taricacin. Mdulo de conexin mvil: Permite a los clientes mviles acceder a los servicios de mensajera instantnea que ofrece PAUMIM. Este mdulo
42
es el encargado de gestionar las conexiones y manejar la sesin de los clientes soportados (Clientes J2ME MIDP1.0 y MIDP2.0) [12]. Para realizar la gestin de conexiones, este mdulo cuenta con dos submdulos. El primero se encarga de administrar las conexiones de los clientes MIDP1.0 a travs de un componente de actualizacin 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 conexin y realizando la asignacin de las mismas a travs de sockets TCP. Mdulo de interoperabilidad: Es el encargado de llevar a cabo la implementacin del protocolo de mensajera instantnea Jabber. Entre sus funciones ms importantes se encuentran el registro de usuarios, la gestin de informacin de presencia, mensajera y contactos de los usuarios, y garantiza la interoperabilidad con proveedores de mensajera externos. Cuenta con dos submdulos descritos a continuacin: Servicios Jabber: Encargado de prestar los servicios denidos por el protocolo Jabber, entre ellos la conexin, envo de mensajes y manejo de presencia. Se comunica con el mdulo de control central para efectos de noticacin, transporte de mensajes y presencia, y con el mdulo transporte para establecer comunicacin con los sistemas de mensajera instantnea MSN, AOL e ICQ. Mdulo de transportes: Es una extensin del mdulo de servicios Ja-
bber, la cual permite establecer una comunicacin con otras redes IM. Este mdulo desempea el papel de representacin de los clientes mviles ante los servidores de mensajera instantnea propietarios, con el n de dar a la plataforma una de sus principales caractersticas, la interoperabilidad. Mdulo de control central: Se encarga de coordinar toda la funcionalidad de la plataforma. Se compone de tres submdulos: Control: Encargado de implementar la lgica del negocio del sistema y llevar a cabo la coordinacin de mensajes entre los mdulos restantes. Taricacin: Lleva a cabo las tareas de registro de datos y generacin de informacin de utilidad para la administracin 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 trco 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 nmero de sesiones iniciadas, mensajes enviados, mensajes recibidos y sesiones de chat establecidas. Gestin de usuarios: Encargado de gestionar la informacin de los usuarios. Provee las funcionalidades de registro, eliminacin, edicin y bsqueda de usuarios. Cliente mvil (CUMI): Es una aplicacin J2ME que se ejecuta en el dispositivo mvil, la cual constituye la interfaz entre el usuario y el sistema. A travs de un mdulo de almacenamiento persistente, se guardan preferencias y datos del usuario. Para establecer la comunicacin, el usuario
43
no necesita crear una nueva cuenta en el servidor PAUMIM, ya que puede iniciar una sesin a travs de la cuenta de su proveedor de mensajera tradicional. Existen dos versiones de CUMI, una para dispositivos mviles de gama media (telfonos celulares y PDAs Palm, basado en la implementacin MIDP 1.0 [13]) y otra para dispositivos mviles de gama media-alta (telfonos celulares y smartphones, basado en la implementacin MIDP 2.0 [13]). B. Diseo Las Figuras 2 y 3 muestran el diseo de la arquitectura del sistema. El diagrama de paquetes del servidor muestra una arquitectura en tres capas. En la primera estn los pa-
quetes que contienen las clases que fueron implementadas por completo durante el desarrollo de este proyecto. La segunda corresponde a API (Application Program Interface) de terceros adicionadas como libreras, y en la tercera se encuentran los paquetes que corresponden a mdulos funcionales de la plataforma externos al ambiente de desarrollo Java que fueron utilizados directamente o con pequeas adaptaciones. En contrava, el diagrama de paquetes del cliente mvil muestra una arquitectura mucho ms simple. A continuacin se realiza una breve descripcin de cada uno de los paquetes: Servidor PAUMIM python: Lenguaje interpretado utilizado para el desarrollo del mdulo de transportes [22].
Figura 3. Diagrama de paquetes del cliente mvil PAUMIM .
pyOpenSSL: Provee extensiones a Python para crear conexiones seguras. Conforma una capa de alto nivel alrededor de una conguracin de la librera OpenSSL de Python [23]. pyCripto: Provee herramientas de cifrado de informacin a Python [24]. twisted: Es un framework de cdigo 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].
Figura 2. Diagrama de paquetes del servidor PAUMIM.
44
ejabberd: Es un servidor Jabber multiplataforma. Desarrollado en el lenguaje Erlang, cuenta con un soporte total de las caractersticas del protocolo Jabber [26]. erlang: Lenguaje funcional utilizado especialmente para desarrollo de aplicaciones distribuidas. Tiene soporte para concurrencia, distribucin 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 operacin 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 operacin es transparente para el usuario [30]. smack [31]: Es una API de cdigo abierto para construir clientes de mensajera instantnea en Java. Puede ser embebida en aplicaciones para crear componentes de presencia y mensajera instantnea basados en el protocolo Jabber. De esta forma se logra la comunicacin entre los paquetes implementados en Phyton y los creados en Java. postgreSQL: Este conjunto de libreras permite a los programas Java conectarse al motor de base de datos PostgreSQL [32].
view: En este paquete se encuentran las pginas JSP, a travs de las cuales se lleva a cabo la comunicacin 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 administracin. Todas las pginas JSP se comunican con el paquete de control. control: Contiene las clases que gestionan la lgica de la aplicacin y la coordinacin de la comunicacin entre mdulos 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 especca. En este paquete se cuenta con componentes que llevan a cabo tareas de tarificacin, gestin de usuarios, funcionalidades de administracin y manejo de mensajera y presencia de usuarios. communication: Contiene las clases involucradas en la creacin de un servicio que escucha peticiones concurrentes provenientes de clientes mviles, las cuales pueden utilizar HTTP (para clientes MIDP1.0) o Sockets TCP (para clientes MIDP2.0). Cliente Mvil PAUMIM view: Contiene las clases necesarias para llevar a cabo la comunicacin directa entre el sistema y el usuario a travs de interfaces grcas. control: Agrupa las clases que sirven para gestionar la lgica de la aplicacin y la coordinacin de la comunicacin entre sta, el usuario y el
45
servidor. Adems, la clase principal de este paquete permite manejar el ciclo de vida de la aplicacin. communication: Contiene las clases involucradas en la comunicacin entre el cliente mvil y el servidor PAUMIM. Para establecer dicha comunicacin se utilizan clases propietarias para el establecimiento y mantenimiento de la conexin y las clases denidas en JXME (JXTA for J2ME) para la codicacin y decodicacin de los mensajes de comunicacin. C. Funcionamiento A continuacin se describe cada uno de los pasos involucrados en el uso de la plataforma PAUMIM: Inicialmente se descarga el cliente mvil (CUMI) al dispositivo, por medio de la interfaz OTA (Over The Air), o a travs de los diferentes medios de comunicacin disponibles como cable de interfaz serial, USB, Bluetooth o IrDA. La primera vez que el usuario inicia la aplicacin debe congurar su login y contrasea de ingreso, definida para PAUMIM o para alguno de los sistemas propietarios de mensajera instantnea en los que tiene cuenta, y establecer las direcciones de los contactos con los que va a establecer la comunicacin (opcional). Toda esta informacin es enviada al servidor de mensajera instantnea que es el encargado de almacenarla. Una vez el servidor reciba la informacin de los usuarios mviles se encarga de establecer la comunicacin con los proveedores de servicio de mensajera propietarios, para solicitar el registro de los contactos y la validacin del usuario en ellos.
El usuario puede iniciar una sesin de mensajera instantnea mvil en cualquier terminal que cuente con el cliente mvil (CUMI) instalado mediante el uso de su login y contrasea. Cuando el usuario inicia una sesin, el servidor de mensajera instantnea se encarga de enviar al mvil toda la informacin pertinente entre la cual se tiene la lista de contactos, estado de los contactos y mensajes de entrada. De igual forma, el servidor se encarga de recibir los mensajes de los mviles y encaminarlos hacia sus contactos si pertenecen al mismo sistema o a los proveedores propietarios a travs del mdulo de interoperabilidad. Cuando el usuario realice la desconexin, PAUMIM se encarga de noticar a todos sus contactos y a los servidores propietarios de mensajera instantnea del cambio de estado a desconectado. Adems, almacena todos los mensajes que los contactos le enven hasta que se puedan entregar en el prximo inicio de sesin. V. ENTORNO DE EXPERIMENTACIN La Figura 4 muestra el entorno de experimentacin utilizado para la realizacin de las pruebas de PAUMIM sobre ambientes inalmbricos. A. Cliente Mvil En el cliente mvil se realizaron tres tipos de pruebas: La primera, en emuladores de Nokia, Sony Ericsson y el Wireless Toolkit de Sun, cada uno equipado con herramientas que permiten observar el consumo de memoria de la aplicacin
46
Figura 4. Entorno de experimentacin 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 inalmbrico y PDAs Palm Drive y Tungsten T5. La tercera, a travs de la infraestructura de datos GPRS de la red celular, instalando la aplicacin servidora en una mquina con IP real y el acceso a travs de telfonos celulares Sony Ericsson T610 para el cliente MIDP 1.0 y Nokia 6230 para el cliente MIDP 2.0. Consumo de memoria A continuacin 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 aplicacin en tiempo de ejecucin para las funcionalidades ms relevantes. Las Figuras 7 y 8 muestran el consumo de memoria en el inicio de sesin
de la aplicacin y actualizacin 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 transicin en el cual el dispositivo carga en memoria la aplicacin y comienza el periodo de conexin y validacin de sesin.
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 sesin y actualizacin de presencia (cliente MIDP 1.0).
Figura 8. Consumo de memoria para el inicio de sesin y actualizacin 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 mvil MIDP1.0 se genera peridicamente un mensaje de sondeo y se enva al servidor, en este momento se crean objetos y se hace uso de la red, por esta razn la grca muestra un comportamiento de diente de sierra ya que despus de consumir recursos y enviar el mensaje al servidor, se limpia la memoria a travs del recolector de basura (garbage collector). Para el cliente mvil MIDP 2.0 la grca de consumo de memoria es mucho ms
estable debido a que la comunicacin con el servidor se realiza mediante un socket TCP y no hay que crear objetos ni hacer uso de la red para conservar la conexin. 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 ms importantes en entorno de emulacin.
48
Figura 9. Tiempo de respuesta para el cliente MIDP 1.0.
mensaje por peticin, lo cual incrementa el tiempo de respuesta de la aplicacin. Para el cliente MIDP2.0 el servidor recibe la conexin TCP/IP y trata la informacin directamente sin necesidad de realizar empaquetamiento y los mensajes se envan 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. Tamao de los mensajes La Figura 11 muestra el tamao de los mensajes para cada una de las funcionalidades del cliente mvil. La diferencia entre el cliente MIDP1.0 y MIDP2.0 es que el primero debe realizar el sondeo al servidor y por esta razn consume ms ancho de banda.
200 150 100 50 0 (A) (B) (C) (D) (E) (F) (G) (H) (I) A 141 B 62 C D E 108 F 72 G 124 I H 114 73
1000 800 600 400 200 0 A 225
B 852
Tiempo de respuesta (ms) (A) (B) Inicio de la aplicacin Inicio de sesin
Figura 10. Tiempo de respuesta para el cliente MIDP 2.0.
161 164
El inicio de sesin consta del ensamble del mensaje con los datos de sesin para su envo al servidor, recepcin de respuesta y actualizacin de la interfaz grca. El comienzo de la aplicacin es ms rpido para el cliente MIDP1.0 pero su tiempo de respuesta al principio de sesin es mucho ms lento que para el cliente MIDP2.0. Lo anterior se debe a que el principio de funcionamiento para la recepcin de conexiones por parte para los dos clientes es distinto. Para el cliente MIDP1.0 el servidor tiene que recibir y tratar informacin transportada en el protocolo HTTP, para lo cual debe empaquetar y desempaquetar la informacin segn el stack de protocolos HTTP. Adems de esto, el usuario debe descargar un
Tamao del mensaje (bytes) Inicio de sesin Actualizacin de presencia
Descarga de lista de contactos Inicio de sesin de Chat Inicio de mensaje de Chat Finalizacin sesin de Chat Adicin de Contacto Eliminacin de Contacto Cerrar sesin
Figura 11. Tamao de mensajes para el cliente mvil (MIDP 1.0 y 2.0).
B. Mdulo de conexin mvil Consumo de memoria y uso de CPU de servicios Jabber El servidor Ejabberd 1.0 se instal en el sistema operativo Linux distribu-
49
cin Debian. El nmero de usuarios que soporta concurrentemente depende de la conguracin y del hardware en el cual se est ejecutando. Con respecto a la conguracin, es necesario denir el nmero mximo de puertos habilitados por Erlang y la cantidad mxima de conexiones. La eciencia del servicio tiene una dependencia directa con el ambiente de ejecucin del servidor, si corre en una sola mquina o en un cluster de mquinas. Para ambos casos la memoria RAM y la CPU son factores determinantes en el rendimiento. Cuando el servidor es congurado para correr en un cluster de mquinas, el rendimiento del sistema depende, adems de la conguracin y
disposicin del cluster, de mquinas. En este proyecto se congur el servidor Ejabberd para correr en una sola mquina, y se estableci el nmero mximo de puertos en 1000. A travs de una prueba de estrs, en la cual a partir de una aplicacin de escritorio se iniciaron sesiones annimas en el servidor hasta que ste cerr la recepcin de nuevas conexiones, se determin que con el entorno de ejecucin utilizado el servidor puede aceptar entre 720 y 770 usuarios dependiendo de la actividad de cada una de las sesiones de usuario. Las Figuras 12 y 13 muestran el uso de la CPU y el consumo de memoria respectivamente, en los tres intervalos 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 estrs, y el tercero, al momento de cierre de las sesiones de usuario iniciadas. Se puede observar que el uso de la CPU es mximo 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 annimas hasta el punto en el cual el servidor ya no tiene memoria suciente,
suspendiendo en ese momento la recepcin de nuevas conexiones y dejando de incrementar el consumo de memoria RAM. Submdulo 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 desempeo de cada uno de los transportes fue satisfactorio ya que permitieron llevar a cabo exitosamente la interoperabilidad
50
con los proveedores de mensajera instantnea 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 Mensajera Presencia Grupos de chat Soporte para Vcard Presencia invisible Noticaciones de escritura Mensajes HTML pyMSN pyICQ pyAIM
X X
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 envo de mensajes en la plataforma PAUMIM es mucho ms bajo con relacin a SMS. Adems, para el caso del Cliente Mvil MIDP 2.0 el trco a cursar es reducido, lo que tambin contribuye a disminuir costos, haciendo el servicio ms atractivo para el usuario nal. Acceso al servicio: El servicio de mensajera corta es prcticamente un servicio universal, soportado por todos los telfonos que se conectan a la red celular. Para que los 9 dispositivos mviles 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 mltiples proveedores de mensajera instantnea, mediante la adicin de mdulos funcionales a la plataforma. Por otro lado, para lograr interoperabilidad entre proveedores de servicio de SMS es necesario llegar a acuerdos comerciales de interconexin de redes. Dichos acuerdos son dependientes de las polticas de cada operador y de la regulacin de cada pas, y son determinantes en el momento del establecimiento de dichos acuerdos. VII. CONCLUSIONES A pesar de que J2ME es una especicacin, la implementacin de la mquina virtual para cada gama de dispositivos tiene algunas variaciones y por tanto los desarrolladores
El principal inconveniente presente en la comunicacin de PAUMIM con otros proveedores de mensajera instantnea radica en la modicacin regular del protocolo de comunicacin 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 ingeniera inversa de los mdulos de transporte de cada servidor, para adaptarlos a los cambios, de modo tal que sigan funcionando correctamente. VI. PAUMIM VS SMS Para realizar la comparacin entre PAUMIM y el Servicio de Mensajera Corta (SMS) [5] se van a abordar tres aspectos fundamentales: precio, acceso al servicio e interoperabilidad. Precio: En trminos generales, los mensajes de texto a travs de SMS tienen un precio (para el usuario nal) superior al kilobyte de descarga a travs de GPRS. Tomando como referencia los precios de un operador de telefona mvil en Colombia, el precio
51
de aplicaciones mviles basadas en Java Micro Edition deben tenerlas en cuenta. Por medio de la construccin de un protocolo liviano de bajo consumo de ancho de banda se llev a cabo la comunicacin entre el cliente mvil y el servidor PAUMIM de forma eciente. El uso de protocolos universales como TCP/IP en las comunicaciones entre los dispositivos mviles y el servidor PAUMIM hace que se puedan implementar y soportar diferentes tipos de clientes Web y de escritorio, en una gran variedad de tecnologas de desarrollo como Java, PHP, Perl, Python,. Net, C#, VisualBasic, entre otras. El perl 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 aplicacin e incrementa los costos de utilizacin. El soporte de conexiones MIDP 2.0 es mucho ms completo que su antecesor, lo cual permite implementar comunicaciones a bajo nivel por medio de sockets TCP mediante el establecimiento de un circuito lgico entre el cliente mvil y el servidor, reduciendo costos e incrementando en gran medida la eciencia de la aplicacin, 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 conguracin robusta y adaptable a los diferentes transportes de comuni-
cacin como PyMSN, PyICQ y PyAOL, los cuales fueron seleccionados para el desarrollo del proyecto por sus caractersticas de libre distribucin, alto rendimiento, alta adaptabilidad y fcil conguracin. BIBLIOGRAFA [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.). Mensajera Instantnea. Del placer a los negocios. Revista Consumer EROSKI. [Online]. Disponible: http://revista.consumer.es/web/ es/20021001/internet/. [3] E. Lopez. Mensajera instantnea. 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. Martnez, M. J. Gmez 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/
52
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 Ingeniera, 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. Martnez, J. A. Hurtado y G. A. Ramrez, 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. Garca, R. Camacho y F. O. Martnez, Desarrollo de Aplicaciones P2P para Dispositivos Mviles haciendo uso de los Protocolos JXTA (JXTA + J2ME) El Punto de Encuentro Virtual P2P, presentado en las V Jornadas de Investigacin y Desarrollo en Informtica (JIDI) en el marco del evento TECNOCOM 2005, Medelln, 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] Asociacin ADITEL. (2003, Sep.). Introduccin a Jabber. Universitat Jaume I de Castelln, Espaa. [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.
53
net. [Online]. Disponible: http:// pyopenssl.sourceforge.net/ [24] Pycripto. (2005, Dec.). Python Cryptography Toolkit. SourceForge.net. [Online]. Disponible: http://www.amk.ca/python/code/ crypto.html [25] I. Shtull-Trauring. An Introduction to the Twisted Networking Framework. Presented at OReilly Emerging Technology Conference. [Online]. http:/ nlamp.com/pub/a/python/2004/01/15/twisted_intro. html [26] Ejabberd Web site. (2005, Dec.) Ejabberd server. Ejabberd project. [Online]. http://ejabberd. jabber.ru/ [27] Erlang Web site. (2006, Mar.). Erlang Open source. Erlang.org. [Online]. http://www.erlang.org [28] PyMSNt Web site. (2006, Feb.). Python based MSN Transport for Jabber. Jabberstudio..org. [Online]. http://msntransport. jabberstudio.org [29] PyAIM-t Web site. (2005, Dec.). AIM transport for Jabber. Blathersource.org. [Online]. http:// pyaim-t.blathersource.org/ [30] PyICQ-t Web site. (2005, Dec.). ICQ transport for Jabber. Blathersource.org. [Online]. http://pyicq-t.blathersource.org/ 10 [31] Smack API Web site. (2006, Mar.). Simple and Powerful Java client API for XMPP. Jivesoftware.org. [Online]. http://www. jivesoftware.org/smack [32] PostgreSQL Web site. (2006, Feb.). PostgreSQL JDBC Driver.
Postgresql.org. [Online]. http:// jdbc.postgresql.org/ scar Caicedo recibi el ttulo de Ingeniero en Electrnica y Telecomunicaciones de la Universidad del Cauca, Colombia, en 2001. En la misma institucin recibi el ttulo de Especialista en Redes y Servicios Telemticos, en 2003. Actualmente realiza su tesis de Maestra en Ingeniera con nfasis en Telemtica en la Universidad del Cauca y se desempea como docente del Departamento de Telemtica de la Facultad de Ingeniera Electrnica y Telecomunicaciones de la misma universidad. Como miembro del Grupo de Ingeniera Telemtica (GIT), su rea de investigacin se centra en la Ingeniera del software aplicada a la construccin de arquitecturas y plataformas para el desarrollo y despliegue de aplicaciones sobre dispositivos mviles, redes inalmbricas y redes mviles celulares. Andrs Caicedo recibi el ttulo de Ingeniero en Electrnica y Telecomunicaciones de la Universidad del Cauca, Colombia, en 2006. Actualmente realiza su primer ao
54
de estudios de Maestra en Ingeniera con nfasis en Telemtica en la Universidad del Cauca. Adems, es miembro del grupo de inters en desarrollo de aplicaciones mviles e inalmbricas w@pcolombia y director de proyectos de tecnologa Topp Allians S.A.; donde centra su investigacin en el desarrollo de servicios y aplicaciones para dispositivos mviles, desarrollo de aplicaciones empresariales, redes inalmbricas de transmisin de datos, redes globales de informacin y redes mviles celulares de 2.5G y 3G. Edwin Figueroa recibi el ttulo de Ingeniero en Electrnica y Telecomunicaciones de la Universidad del Cauca, Colombia, en 2006. Actualmente es miembro del grupo de inters de desarrollo de aplicaciones mviles e inalmbricas w@pcolombia, donde centra su investigacin en el desarrollo de servicios y aplicaciones para dispositivos mviles, redes inalmbricas de transmisin de datos, redes globales de informacin y redes mviles celulares de 2.5G y 3G. Francisco Martnez recibi el ttulo de Ingeniero en Electrnica y Telecomunicaciones de la Universidad del Cauca, Colombia, en 2003. Actualmente cursa tercer semestre de Maestra en Ingeniera con nfasis en Telemtica
en la Universidad del Cauca y se desempea como docente del Departamento de Telemtica de la Facultad de Ingeniera Electrnica y Telecomunicaciones de la misma universidad. Como miembro del Grupo de Ingeniera Telemtica (GIT), su rea de investigacin se centra en la Ingeniera del Software aplicada a la construccin de arquitecturas y plataformas para el desarrollo y despliegue de aplicaciones sobre dispositivos mviles. Javier Hurtado recibi el ttulo de Ingeniero en Electrnica y Telecomunicaciones de la Universidad del Cauca, Colombia, en 2001. En la misma institucin, recibi el ttulo de Especialista en Redes y Servicios Telemticos, en 2004. Actualmente cursa tercer semestre de Maestra en Ingeniera con nfasis en Telemtica en la Universidad del Cauca y se desempea como docente del Departamento de Telemtica de la Facultad de Ingeniera Electrnica y Telecomunicaciones de la misma universidad. Como miembro del Grupo de Ingeniera Telemtica (GIT), su rea de investigacin se centra en el estudio de los protocolos de sealizacin en
55
redes de nueva generacin y la construccin de arquitecturas y plataformas para el desarrollo
y despliegue de aplicaciones de nueva generacin sobre dispositivos mviles.
56
Modelo de simulacin de la capa MAC IEEE 802.16-2004 para modo Mesh

GIDATI, Escuela de Ingeniera, Facultad de Informtica y Telecomunicaciones Universidad Ponticia Bolivariana, Medelln, Colombia jsierrac@ieee.org
Javier Emilio Sierra Roberto Hincapi
GIDATI, Escuela de Ingeniera, Facultad de Informtica y Telecomunicaciones Universidad Ponticia Bolivariana, Medelln, Colombia rhincapie@ieee.org
Departamento de Ingeniera Elctrica y Electrnica Universidad de los Andes, Bogot, Colombia rbustama@uniandes.edu.co
Roberto Bustamante () Leonardo Betancur
GIDATI, Escuela de Ingeniera, Facultad de Informtica y Telecomunicaciones Universidad Ponticia Bolivariana, Medelln, Colombia leonardobetancur@ieee.org Fecha de recepcin: 30-05-06 Fecha de seleccin: 30-10-06
ABSTRACT 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. KEY WORDS MAC, Wimax, Mesh, simulation models
RESUMEN El estndar IEEE 802.16-2004 soporta la creacin de redes mesh. La simulacin de sistemas de comunicacin permite su optimizacin, sobre todo para la mejora de los parmetros de desempeo. En este artculo se presenta un modelo desarrollado e implementado en NS2 para la simulacin de la capa de enlace de datos para topologas mesh basadas en el estndar mencionado. Se muestran resultados obtenidos con un planicador de enlace, as como longitudes promedio de las colas, retardo en cola, capacidad del sistema para diferentes topologas. PALABRAS CLAVE MAC, Wimax, Mesh, simulacin Clasicacin Colciencias: A
57
I. INTRODUCCIN El estndar IEEE 802.16-2004 dene la interfaz fsica y la capa MAC para el acceso a sistemas de banda ancha que emplean topologa mesh. Las redes mesh en los ltimos aos han sido de gran estudio por su facilidad de despliegue como redes emergentes. Es sin duda un rea de investigacin en la cual hay mucho por realizar. Network Simulator 2 (NS2) es una herramienta de simulacin en eventos discretos, la cual permite el desarrollo de entidades que puedan representar de una manera correcta tecnologas inalmbricas; es til para simular la capa de enlace para topologas mesh que emplean el estndar en mencin. En este artculo se muestra un modelo desarrollado de la entidad correspondiente a las funcionalidades de la capa de enlace de datos para el anlisis de sistemas de acceso de banda ancha en topologa mesh basados en el estndar IEEE 802.16-2004; con el n de facilitar por medio de la simulacin, el diseo y anlisis de redes que emplean esta tecnologa, mejor conocida como WiMax (Worldwide Interoperability for Microwave Access). El artculo se encuentra organizado de la siguiente manera: inicialmente se realiza un background de los trabajos relacionados con el tema y sobre el estndar IEEE 802.16. En la seccin III se indican las caractersticas dadas por el estndar referente a las topologas mesh y los planicadores. En la seccin IV se muestra el modelo de capacidad equivalente para la capa PHY en condiciones ideales, el modelo desarrollado e implementado,
as como el diagrama de eventos; por ltimo, en la seccin V se muestran los resultados de las simulaciones realizadas para el planicador y el modelo desarrollado e implementado en NS2. II. BACKGROUND A. Trabajos relacionados Las redes inalmbricas mesh son un tipo de redes de comunicacin especiales orientadas a proveer acceso remoto a usuarios en lugares donde una red comn (celdas) no es ptima. La caracterstica de estos lugares es que son sitios remotos con baja densidad de usuarios y de difcil acceso con una simple estacin base. En [1], [2] y [3] los autores presentan un escenario ms realista donde las redes mesh estn constituidas por alrededor de 30 nodos y son orientadas a proveer servicios de ltima milla a usuarios remotos. Ejemplos de estos escenarios son las comunicaciones rurales [4] e internet banda ancha de acceso residencial. El anlisis de capacidad para redes mesh ad hoc inici con [5], quien present un modelo de capacidad basado en la teora de la informacin. Chang [6] realiz un anlisis orientado a garantizar retardos para las redes mesh sin considerar redes inalmbricas. En [7] los autores presentan el concepto de servicios diferenciados, representados por diferentes colas en un nodo transmisor, cada una con una clase de servicio determinada. Otros trabajos relacionados son [8] y [9], los cuales analizan la calidad de servicio (QoS) de los sistemas. Estos artculos proponen un modelo para arquitecturas punto-multipunto
58
(PMP) similar al modelo propuesto en este artculo, basado en una entidad MAC con varias colas para diferentes tipos de ujo y un control de acceso al medio. En [10] los autores presentan un anlisis de PMP y topologas mesh empleando simulacin. [9] y [11] realizan y muestran un anlisis para planicadores de redes mesh. La mayora de los trabajos relacionados con el estndar IEEE 802.16-2004 estn enfocados a arquitecturas PMP; sin embargo, se encuentra [12], donde los autores simulan topologas mesh pero no mencionan la herramienta usada ni especican los detalles del modelo de simulacin. En la literatura se encuentran entidades para redes mesh basadas en IEEE 802.11 en el DCF incluyendo capas superiores como enrutamiento, TCP, UDP y aplicaciones. Algunas simulaciones consideran movilidad mientras que otras no lo hacen. Estas entidades no se pueden adaptar al modelo que se plantea en este trabajo, ya que estas son ranuradas (slotted) y sincronizadas, mientras que en IEEE 802.11 el mtodo de acceso al medio es basado en contencin. Sobre el proceso de planicacin, en [13] los autores presentan un anlisis de planicacin de paquetes orientado a topologas PMP; [12] analiza un planicador distribuido para redes mesh del tipo WiMAX. De una manera general, es analizado el comportamiento de las redes mesh WiMAX en [14] y [15][16] presentan el problema de los planicadores de enlace TDMA para redes inalmbricas ad hoc. B. Estndar IEEE 802.16 Las actividades de trabajo sobre el estndar IEEE 802.16 iniciaron en
1998, sin embargo, la primera versin del estndar fue completada en octubre de 2000 (IEEE 802.16-2001) y publicada el 8 de abril de 2002. Este dene la interfase fsica y la capa de enlace MAC (Medium Access Control) para redes inalmbricas de rea metropolitanas (WirelessMAN), con la intencin de proveer banda ancha inalmbrica para servicios de voz y datos con usos residenciales y empresariales. La primera versin solo fue considerada para usuarios jos [17]. El estndar fue diseado con capa MAC que soportar diferentes interfases de aire, pero con capa fsica que depende del uso del espectro y de las regulaciones existentes. Se concentr en las bandas de frecuencias de 10 a 66 GHz. Un nuevo proyecto de reforma denominado IEEE 802.16a aprobado antes de nalizar el 2002 extendi el rango de trabajo a las bandas de frecuencia de 2 a 11 GHz, incluyendo de esta forma bandas licenciadas y no licenciadas en las diferentes regulaciones. En junio de 2004 fue aprobado el estndar actual para redes WiMAX jas conocido como 802.16-2004 [18]. Los trabajos actuales sobre el estndar estn concentrados en darle soporte de movilidad (entre 70 y 80 mph) para el empleo de dispositivos como PDA, telfonos o computadores porttiles. Este grupo es conocido como IEEE 802.16e y aprob el estndar el 7 de diciembre de 2005. Entre las caractersticas principales del estndar IEEE 802.16-2004 se tienen: La capa MAC soporta arquitecturas punto multipunto con
59
topologa opcional de redes enmalladas. La capa MAC est estructurada para soportar mltiples capas fsicas (PHY). Para frecuencias entre 10-66 GHz la capa PHY emplea modulacin Single Carrier. Debajo de los 11 GHz donde no es requerida lnea de vista, puede ser empleado: OFDM, OFDMA o Single Carrier. El estndar consolida IEEE st d 8 0 2 .1 6 - 2 0 0 1 , I E E E st d 802.16aTM-2003 e IEEE std 802.16cTM-2002. El estndar especica la interfase de aire para el acceso banda ancha a redes inalmbricas jas soportando diferentes servicios multimedia. III. MESH IEEE 802.16-2004 A. Caractersticas del estndar Las redes mesh son aquellas en las que la comunicacin se puede hacer entre los diferentes nodos y no slo entre nodo y estacin 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 trco, y adems deben enviar por difusin (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
sector y otorga los respectivos recursos para cada enlace, al mismo tiempo que comunica estas decisiones a las dems estaciones del sector. En la topologa Mesh cada nodo tiene 48 bit de direccin MAC, la cual es utilizada durante el ingreso a la red y como parte del proceso de autorizacin. Cuando se autoriza al nodo candidato, este recibe un identicador de 16 bits (Node ID), empleado para identicar al nodo durante la operacin. El Node ID es utilizado en el Mesh Subheader (en unicast y broadcast). En el estndar dene mensajes de control para el modo Mesh [18]: MSH-NCFG message: provee un nivel bsico de comunicacin 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 caractersticas para que un nuevo nodo gane sincronizacin 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 estacin de transmisin. El tiempo de transmisin 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 enva en broadcast el mensaje a todos los vecinos indicando el tiempo de transmisin. Tambin los nodos pueden emplear este mensaje para realizar peticiones
60
de ancho de banda al Mesh BS. Cada nodo reporta cunto es su demanda de trco al Mesh BS, para que ste realice las tareas de scheduler. MSH-CSCF message: al igual que el mensaje anterior, se enva en broadcast cuando se emplea modo centralizado y es empleado para realizar la conguracin necesaria de los nodos Mesh. B. Planificadores definidos en el estndar Como se ha mencionado el estndar dene dos tipos de algoritmos de planicacin para topologa mesh: Planicacin 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 canal para transmitir la informacin de planicacin en un formato especco. Cuando existe una Mesh BS sta acta como responsable de enviar el Network Descriptor con la informacin necesaria de la red. Los nodos deben transmitir el MSH-DSCH de la misma forma como coordinan los mensajes MSH-NCFG. Los nodos establecen los requerimientos de BW de una forma directa entre dos nodos sin la participacin de una BS. Las Peticiones/Concesiones se transmiten a los vecinos para que todos conozcan el algoritmo de planicacin y eviten colisiones. Toda la asignacin se realiza en unidades de minislots. Planicacin Centralizada: las conexiones y la topologa de red son las mismas que en distribuido, pero el scheduler de transmisin es denido por una estacin BS. La BS determina la asignacin de recursos que depende de las solicitudes de las SS.
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 coordinacin de las estaciones y el segundo de la conguracin. Los nodos se agregan a un rbol de enrutamiento, en el cual la Mesh BS corresponde a la raz y se organizan por medio de su distancia en saltos hasta la base. En las peticiones los nodos ms lejanos transmiten primero en orden de aparicin 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 aparicin en el rbol de enrutamiento. IV. MODELO A. Modelo capacidad para capa PHY en condiciones ideales Luego de realizar un estudio al estndar, se encontr que los parmetros principales de OFDM son: Nfft: longitud de la transformada de Fourier desarrollada en el proceso (Nfft = 256). BW: es el ancho de banda de la seal a utilizar. Este valor puede ir hasta alrededor de 20MHz. factor de muestreo. Es claro que no se puede analizar exactamente una seal que va hasta BW/2 por medio de una frecuencia de muestreo de BW, por lo cual, la frecuencia de muestreo es igual a BW*. Guard Time CP: se da como una fraccin del tiempo til del smbolo. Puede tomar valores de 1/4, 1/8, 1/16 o 1/32 segn el estndar.
61
N p : corresponde al nmero de portadoras de datos. Segn los procesos de subcanalizacin de OFDM, se pueden tener mltiplos enteros de 12 portadoras entre 12 y 192 portadoras.
Finalmente un aspecto que depende del esquema de modulacin y de codicacin de la seal es la cantidad de bits codicados CB (Coded bits) por smbolo QAM y la rata de codicacin CR (Coding rate).
Tabla I. Nmero de smbolos OFDM por trama. BW Tsym (s) Ttr=2.5 ms Ttr=2 ms Ttr=5 ms Ttr=8 ms Ttr=10 ms Ttr=12.5 ms Ttr=20 ms 5.00E+06 56 44.6 71.4 89.3 142.9 178.6 223.2 357.1 1.00E+07 28 89.3 142.9 178.6 285.7 357.1 446.4 714.3 1.50E+07 18.667 133.9 214.3 267.9 428.6 535.7 669.6 1071.4 2.00E+07 14 178.6 285.7 357.1 571.4 714.3 892.9 1428.6
Con los valores anteriores se deduce la rata de transmisin (bits):
El parmetro 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 estndar tienen una duracin que oscila entre 2.5, 4, 5, 8, 10, 12.5 y 20 mseg; sin embargo, para conguraciones mesh el tiempo de trama dispuesto por el estndar es de 4 mseg. Dentro de esta trama se encuentra un nmero de smbolos OFDM: (2) Con Ttr: tiempo de trama.
Existen ciertas limitaciones sobre la utilizacin de la trama por parte de los usuarios. En primer lugar, aparece el concepto de la trama de control, la cual tiene una duracin en trminos de smbolos OFDM, dada por 7 x MCL (longitud de la subtrama de control). El valor de este parmetro es de 4 bits, con lo que puede oscilar entre 0 y 15. El resto de los smbolos de la trama estn ocupados con datos del usuario. Con base en los valores de parmetros de OFDM, se encuentran diferentes nmeros de smbolos 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 duracin de smbolo), se logra la mayor cantidad de smbolos OFDM por trama. Todos los datos de la subtrama de control deben ser transmitidos en
62
QPSK1/2, los smbolos restantes se asignan en conjuntos de minislots a los usuarios. El campo de asignacin de minislots se compone de 8 bits, y el valor mximo a asignar en posicin y tamao es 255. Por lo tanto, la parte de la trama restante se divide en minislots de tamao dado por: (3) Todos los minislots de la trama tienen este tamao, con la posible excepcin del ltimo. Cabe anotar que los campos de la subtrama de control no tienen todos su duracin como carga til, ellos tienen un prembulo largo y unos smbolos de guarda posteriores, con lo cual su duracin efectiva se hace ms corta. Antes de los datos de control se ubica un Long Preamble equivalente a 2 smbolos OFDM.
En la grca Mesh frame structure del estndar [18](p.459), se interpreta que luego de la trama de MSH NET ENTRY, aparecen tres smbolos OFDM de guarda. Luego de las tramas de SCHEDULING y de MSH NCFG aparece un smbolo de guarda antes de comenzar la nueva trama. Con esto se reduce an ms el tamao de la carga til de estas tramas. En el caso de la subtrama de entrada a la red, se reduce a dos smbolos OFDM o a un total de 384 bits o de 48 bytes nicamente. El tamao del minislot es un indicativo de la cantidad de informacin que se puede transmitir para un determinado usuario en funcin de smbolos OFDM, no de bits, pues en cada rango de minislots se pueden tener diferentes opciones de conguracin de modulacin y codicacin. El nmero de minislots estara dado por:
(4)
La asignacin se realiza por medio de minislots (MS), indicando el MS de inicio y la duracin en unidades tambin de MS. Teniendo en cuenta que para un enlace determinado el canal estara
asignado durante un rango de MS, se puede encontrar nalmente la rata de transmisin asignada de manera equivalente al usuario:
(5) La cantidad anterior indica que la percepcin del canal por parte del usuario depende del ancho de banda, del porcentaje del canal asignado, de las portadoras y del esquema de modulacin elegido. La rata de transmisin 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 simulacin de la capa MAC del estndar IEEE 802.16-2004 para topologa mesh. Se observan las siguientes entidades:
Figura 1. Diagrama general.
1) Link Scheduling: Es una entidad codicada en C++ externa a la Capa MAC Mesh 802.16-2004 encargada de la asignacin de los parmetros de planicacin del sistema. Link Scheduling se comunica con el Controlador MAC para indicarle los tiempos de trama y los tiempos en que cada Planicador debe habilitar su respectiva cola. La entidad posee dos estructuras de apuntadores, una de Controladores MAC y otra de Planicadores. Adems, carga los datos de asignacin de ranuras y trco (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
tiene en cuenta las capas superiores, por lo tanto las fuentes de trco se encuentran dentro de la MAC; el scheduling se realiza de manera global y es centralizado; el planicador 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 ujo: est compuesto por dos entidades desarrolladas en C++: ColaMesh y Planicador de paquetes. En el Control de Flujo la ColaMesh es la encargada de empaquetar los paquetes con el tamao indicado y modicar el Header OFDM (ver subseccin B4) para la transmisin del nuevo paquete del tipo
64
mesh. Al conectarse ColaMesh con el Planicador, este ltimo recibe el paquete, que a su vez lo enva por su puerto de salida. ColaMesh es la entidad encargada de encolar los paquetes hasta que el planicador le indique que desencole. ColaMesh es una entidad realizada en C++, la cual hereda las propiedades y mtodos de la clase pblica Queue. Posee los siguientes mtodos nuevos: a) resumepaq (desencola un determinado nmero de paquetes, uno por uno sin empaquetamiento; b) resumepaquetes (desencola un determinado nmero de paquetes, los empaqueta dependiendo del tamao solicitado y le agrega la cabecera OFDM al nuevo paquete para luego ser enviado al puerto de salida); c) inicializa ofdm (esta funcin inicializa los valores del Header OFDM que se describirn ms adelante). Al emplear resumepaquetes se emplea una funcin packing para unir n paquetes en uno solo dependiendo del tamao de paquete solicitado por Planicador. El planicador es la entidad encargada de realizar los clculos que determinan el tamao del paquete a transmitir (segn el estndar); indica el valor del tamao a ColaMesh. Es una entidad completamente desarrollada en C++ que hereda a la clase pblica Connector; posee mtodos que permiten
indicar a la cola que inicie desencolamiento o pare. Otra funcin de esta entidad es que dependiendo del paquete que le llegue o comando ejecutado decide la operacin a realizar; si recibe un paquete del tipo control indica a la cola que inicie desencolamiento; si recibe un paquete del tipo OFDM lo enva al puerto de salida. Controlador MAC: al igual que la entidad Planicador, tambin es desarrollada completamente en C++ y hereda a la clase Connector. El Controlador se comunica con la entidad Control de Flujo por medio de Planicador para ejecutarle mtodos que inicien o paren solicitudes a la cola. Se crea un Control de Flujo para cada conexin y el controlador posee una lista de todos los planicadores. Adems, en el controlador se inicializan los parmetros Header OFDM y se selecciona el esquema de modulacin a emplear. El controlador MAC recibe de Link Scheduling los tiempos en que se programar cada control de ujo. El Controlador MAC al recibir datos los analiza para determinar si son dirigidos a l; si lo son, los enva a capas superiores. Fuente de datos: es la encargada de generar los paquetes que sern enviados de un nodo a otro en cada conexin. 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 generacin exponencial, tipo de paquete mesh y headers que se mencionarn en
65
IV-D. A la fuente exponencial se le congura la tasa de generacin de paquetes por segundo (l) y el tamao del paquete en bytes. Es de anotar, que la estructura Fuente-Agente no se emple en el modelo, ya que la nueva fuente se hizo de tal forma que se pudiera realizar la conexin 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 simulacin. Para analizar las variables y paquetes OFDM creados se desarroll un nuevo trace: TraceMesh. TraceMesh es una entidad que hereda las propiedades y mtodos 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, Tamao real paquete enviado, Tamao paquete solicitado para enviar, CIDorigen, CIDdest. En caso de requerirse nueva informacin es posible agregarla. Para el correcto funcionamiento de la entidad TCL TraceMesh fue necesario realizar una sper clase en TCL, llamada TraceMeshClass en la cual se le indicaban los tipos de paquetes que poda 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
caractersticas de los paquetes empleados. Los parmetros que contiene son los siguientes: BW, , Nused n, CP, N fft, FS, subcarrierspacing, Tsym, CP time, OFDM symboltime, T sampling, CR, CB, Ttr, durationMS, delayMS, MSo, MSSize, Nofdm symbol, MCL(MSH _CTRL_LEN), CIDorigen, 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 cunto tiempo tiene el planicador para la ocupacin del canal, el cual es igual a numMS x duracionMS. Este header tambin es empleado cuando se enva un paquete de control del controlador MAC al planicador, 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 con las caractersticas de la capa MAC dadas por el estndar. Los eventos fueron diseados de tal forma que se pudieran agregar nuevas funciones o caractersticas, como por ejemplo el ingreso de nuevos nodos, eleccin del tipo de modulacin dependiendo del canal, cambios de scheduler, entre otros. Como ya se mencion el Link Scheduler es el encargado de inicializar los parmetros de las entidades Controlador MAC y Planicadores, con datos obtenidos de archivos de conguracin. Como se observa el evento
66
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 planicadores (SHC). El planicador (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 seccin de parmetros OFDM. Las dems caractersticas se observan en la Figura 2. D. Planicador El scheduling implementado es del tipo Pure greedy [19], [20]. Todos los algoritmos link scheduling son centralizados, trabajan fuera de lnea y requieren conocimiento global de la red. El algoritmo busca garantizar que en un enlace (nodo A nodo B) no resulte en colisin, ya sea en el nodo A o en el nodo B. Se tienen en cuenta dos tipos de colisiones:
Primary interference: ocurren cuando una estacin transmite y recibe la misma ranura. Secondary interference: ocurren cuando una estacin recibe dos o ms transmisiones separadas en la misma ranura. En link scheduling no se presentan colisiones y consiste en una secuencia de ranuras jas, donde a cada enlace se le asigna un determinado nmero de minislots (MS) y transmite cclicamente. Para evitar las colisiones determina qu vecinos pueden transmitir en la misma ranura. El algoritmo tambin asume que la transmisin de una estacin es recibida por todas las estaciones con una distancia Euclidiana R. El algoritmo fue implementado en Matlab. Este programa a partir de matriz de trco y vecinos, calcula y asigna las ranuras a cada conexin, de tal forma que se minimice en gran medida la duracin del ciclo
67
de transmisin. Los resultados son exportados a archivos, los cuales a su vez son empleados en NS2 por la entidad Link Scheduler para la conguracin de los nodos y entidades. En la Figura 3 se observa la asignacin de ranuras de transmisin para
una conguracin de diez nodos en conguracin mesh y en la Figura 4 se muestran las ranuras en que recibe cada nodo, lo que depende de la respectiva asignacin de ranuras de transmisin.
Figura. 3. Asignacin de ranuras de transmisin
Figura 4. Ranuras de recepcin.
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 duracin del ciclo de transmisin y el nmero de nodos que transmiten y
reciben simultneamente en funcin de la conectividad de la red. Tambin se veric la distribucin del ciclo de transmisin y el efecto que ocasiona el orden de asignacin de las ranuras en el porcentaje de disminucin del ciclo de transmisin, medida como el porcentaje de disminucin del ciclo obtenido en el reso espacial respecto a cuando no se emplea reso.
Figura 5. Percentage reduction and mean of the transmission cycle.
Se realizaron dos pruebas para topologa mesh y dos para topologa en relay, corriendo 1.000 veces el algoritmo de planicacin para cada caso. La curva A muestra los resultados para topologa mesh respecto al nmero de nodos y radio constante de transmisin R. El requerimiento de ranuras es aleatorio para cada enlace y el orden de asignacin depende del ndice en la tabla de enlaces. La curva B muestra resultados similares al caso A, pero en ste el orden de asignacin en el ciclo de transmisin es aleatorio. Las curvas C y D muestran
los resultados para conguracin en relay. En el caso C, el orden de asignacin 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 topologas mesh no afecta si el orden de asignacin es determinstico o aleatorio. El porcentaje de minimizacin del ciclo de transmisin (%M) es cercano al 100% (%M 100%) cuando
69
2 45 40 35 30 25 20 15 10 5 15 20 25 30 35 40 1 6 10 45 50 4 3 8 9 7
Figura 6. Ubicacin de 10 nodos en conguracin mesh.
n o bajo (%M < 100%) cuando n es pequeo; estos casos son considerados para conguracin en relay. El porcentaje de minimizacin (%M) se calcul con la ecuacin 6. (6) Lmax es el mximo nmero de ranuras cuando se asigna secuencialmente (sin reso). Lobt es el nmero de ranuras asignadas obtenidas con Link Scheduler. Se puede deducir que en conguracin relay, el ciclo de transmisin no tiende a incrementar cuando el nmero de nodos aumenta. Tambin en la ecuacin 6 el lmite tiende al 100%. En topologa mesh, el ciclo de transmisin tiende a incrementar con el nmero de nodos, pero el porcentaje de minimizacin no tiende a 100% porque la cantidad en la ecuacin 6 tambin tiende a incrementar. Con esto se puede decir que en conguracin en relay es mejor que la asignacin sea en un orden especco dado por el ndice de la tabla de enlace. Esto tambin se puede observar
en la Figura 5, donde %M es alto para conguracin en relay donde el reso espacial aumenta con el aumento de la cantidad de nodos. B. Simulacin topologas en NS2 Se emplearon 5 escenarios de simulacin 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, trco idntico para cada conexin. 3 nodos en mesh, trco variable para cada conexin. 10 nodos en mesh, trco variable para cada conexin. 10 nodos en relay, trco idntico para cada conexin. 10 nodos en relay, con agregacin de trco para cada conexin (T, 2T, 3T,..., nT). En la Figura 6 se muestra la ubicacin de una de las topologas simuladas (10 nodos en conguracin mesh); las lneas representan las conexiones con los otros nodos de la red, depen-
70
diendo de la distancia R. Para todas las simulaciones se emplearon los datos de conguracin mostrados en la Tabla II.
Tabla II. Datos de conguracin de simulaciones. Esquema de modulacin BW (MHz) Nfft Np CP Ttr (ms) CB CR MCL l Fuente exponencial Tamao paquete 64-QAM 3.5 8/7 256 192 1/4 4 6 0.75 1 100 x T 100 bytes
Con estos datos se obtienen las ratas de transmisin tericas mostradas en la Tabla III. En la Figura 7 se muestran las grcas 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 mximo cinco paquetes y nunca pierde paquetes. Detalladamente en la Figura 8 se observa el comportamiento de la llegada de paquetes a la cola y cmo son servidos. La distribucin 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 (Ttr). Los resultados obtenidos para todos los enlaces se muestra en las Figuras 10, 11 y 12. Se observa que la rata de transmisin lograda en promedio (para 1 MS) es muy parecida para todas las colas y que el valor es semejante al encontrado en los clculos tericos (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
Tabla III. Ratas de transmisin para diferente trco. T (MS) 1 2 3 4 5 R(kbps) 216 432 648 864 1080 n X 216
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 conguracin de 10 nodos en relay con agregacin de trco en una unidad cada salto, es decir, se simula el caso en que cada salto transmite sus propios datos y los anteriores (Trco: T, 2T, 3T,..., nT). Es observable en las grcas que es posible que cada cola transmita la cantidad de datos exigida, sin embargo, el planicador no asign recursos al ltimo salto porque interfera con otras transmisiones, es decir, los paquetes que estaban dirigidos al ltimo nodo nunca llegaron a l. VI. CONCLUSIONES En este artculo se propone un modelo de capa MAC para el estndar IEEE 802.16, el cual sirve para simular redes inalmbricas mesh; brindando con esto herramientas que permitan el anlisis de planicadores, longitud y retardo en las colas, modelos de propagacin, capacidad, otros. Son posibles adems modicaciones para hacer extensiones a PMP.
El modelo propuesto est compuesto por mdulos que se pueden adaptar para agregar funciones y caractersticas del estndar tales como inicializacin de nodos, entrada a la red, planicacin, esquemas de modulacin y esquemas de codicacin adaptativa. Es necesario que la red disponga un buen algoritmo de planicacin, capaz de asignar las ranuras de tiempo disponibles a la mayor cantidad de enlaces haciendo buen uso del reso espacial. El motivo de esto es que para redes mesh el tiempo de trama dado por el estndar es muy corto, por lo cual la cantidad de minislot disponibles para asignar en el sistema son pocos y requiere una buena eciencia en el ciclo de planicacin. En caso de topologa relay, el planicador de enlace posee mejores caractersticas en cuanto a la duracin del ciclo de transmisin se reere, ya que despus de cierta asignacin de ranuras, asigna los mismos tiempos de transmisin cada tres saltos, mejorando con esto el reso espacial. Se puede observar que la capacidad de las redes mostradas (ranuradas) es muy similar a los valores tericos. Los nodos que manejan trco de otros usuarios deben recibir mayor
74
asignacin de recursos que los otros nodos que no lo hacen. Sin embargo, es necesario analizar estos sistemas en condiciones ms 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 annimos por sus sugerencias. BIBLIOGRAFA [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. Nordstrom, Lessons from experimental manet research, Elsevier Ad Hoc Networks Journal, vol. 3, no. 2, pp. 221233, March 2005. [3] R. Bruno, M. Conti, and E. Gregori, Mesh networks: commodity multihop ad hoc networks, Communications Magazine, IEEE, vol. 43, pp. 123131, 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. 388404, 2000. [6] C.-S. Chang, Stability, queue length, and delay of deterministic and stochastic queueing networks, Automatic Control, IEEE Transactions on, vol. 39, pp. 913931, 1994. [7] A. W. Berger and W. Whitt, Extending the effective bandwidth concept to networks with priority classes, Communications Magazine, IEEE, vol. 36, pp. 7883, 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. 5055, 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. 435439. [10] S. Naghian, Mesh vs. point-tomultipoint topology: a coverage and spectrum efciency comparison, in Personal, Indoor and Mobile Radio Communications, 2004. PIMRC 2004. 15th IEEE International Symposium on, vol. 2, 2004, pp. 10481051. [11] H.-L. Chao andW. Liao, Fair scheduling with qos support in wireless ad hoc networks,
75
IEEE Transactions on Wireless Communications, vol. 3, no. 6, pp. 21192128, 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. 7889. [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. 130136. [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. 211222.
[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. 1857. [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. CURRCULOS Javier Sierra (Javier.sierra@upb. edu.co) recibi su ttulo de Ingeniero Electrnico en la Universidad Nacional de Colombia en el ao 2003 y su magster en Ingeniera rea Telecomunicaciones en la Universidad Pontificia Bolivariana en el 2007, donde actualmente es estudiante del doctorado en Ingeniera con el soporte de Colciencias. Trabaja para el grupo de investigacin GIDATI. Entre sus reas de inters se encuentran las redes inalmbricas, redes mesh, redes hbridas ptico-inalmbricas, optimizacin de redes pticas y tcnicas de simulacin. Leonardo Betancur (leonardo. betancur@upb.edu.co) recibi su
76
ttulo de Ingeniero Electrnico en la Universidad Nacional de Colombia en 2003 y recibi su ttulo de Magster en Telecomunicaciones en la Universidad Ponticia Bolivariana en 2007, en donde actualmente realiza sus estudios de Doctorado en Telecomunicaciones con el apoyo de Colciencias. Pertenece al grupo de investigacin GIDATI, y actualmente sus intereses en temas de investigacin incluyen redes inalmbricas, redes de sensores, UWB y aplicaciones y tecnologas para ambientes indoor. Roberto Hincapie (roberto. hincapie@upb.edu.co ) recibi su ttulo de Ingeniero Electrnico en 1996 y su ttulo de Magster en Telecomunicaciones en 2006 en la Universidad Ponticia Bo-
livariana, en donde actualmente es estudiante del doctorado en Ingeniera con el apoyo de Colciencias, Es miembro del grupo de investigacin GIDATI. Sus temas de inters abarcan Redes inalmbricas, redes enmalladas, algoritmos para planicadores con soporte de calidad de servicio y tcnicas de simulacin. Roberto Bustamante Millar (rbustama@uniandes.edu.co) es Ingeniero Electrnico, graduado en la Universidad de Surrey, Inglaterra. PhD en Ingeniera Electrnica (Antenas Adaptativas), Universidad de Surrey, Inglaterra. Actualmente es profesor Asociado de la Universidad de los Andes y director del Departamento de Ingeniera Elctrica y Electrnica.
77
78
Evaluacin del estimador de capacidad AdHoc Probe en redes MANET con trco cursado autosimilar
Mara del Pilar Salamanca, Nstor Misael Pea
GEST, Grupo de Electrnica y Sistemas de Telecomunicaciones Universidad de los Andes, Bogot, Colombia {m-salama,npena}@uniandes.edu.co
ABSTRACT 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 trafc 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 QualNetR, we evaluate the performance of AdHoc Probe when the network has self similar cross trafc and we validate the results of previous works with Poisson cross trafc.
KEYWORDS Ad-Hoc networks, MANET, AdHoc Probe, trafc, simulation RESUMEN Debido a la naturaleza dinmica de las redes ad-hoc, la estimacin de la capacidad de una ruta es mucho ms compleja que en una red cableada. AdHoc Probe es un algoritmo para estimar capacidad, basado en el concepto de dispersin de paquetes. Para evaluar la capacidad de un enlace extremo a extremo, AdHoc Probe enva pares de paquetes y analiza slo aquellos que tienen el mnimo retardo. Es ampliamente conocido que el trco de datos tiene una naturaleza autosimilar y algunos estudios recientes indican que las redes adhoc tienen este comportamiento. En el presente artculo, utilizando una
79
implementacin de AdHoc Probe en QualNet, se evala el rendimiento de AdHoc Probe cuando la red tiene trco cruzado autosimilar y se validan los resultados de trabajos previos con trco poisson.
PALABRAS CLAVE redes Ad-Hoc, MANET, AdHoc Probe, trco, simulacin Clasicacin Colciencias: A
80
I. INTRODUCCIN La estimacin de capacidad en una red ha sido objeto de estudio en mltiples investigaciones [1], [2] y [3]. Sin embargo, la mayora de dichos estudios han enfocado el problema a redes cableadas y muy poco existe acerca de la estimacin en redes inalmbricas. Para el caso particular de las redes ad hoc, el proceso de estimacin de capacidad se hace especialmente complicado debido a la naturaleza dinmica de las mismas. Entre las herramientas de estimacin de capacidad para redes ad hoc propuestas con anterioridad a la estudiada en [4], se destaca la presentada en [5]. All se realiza la estimacin inyectando en el canal tanto trco UDP como sea posible y la capacidad estar dada por el mximo caudal alcanzable por ese ujo. Sin embargo, es evidente que esta tcnica afecta de forma dramtica el trco cursado presente en la red. Tal como se plantea en [4], una herramienta de estimacin de capacidad en redes ad hoc debe ser rpida, independiente del trco cursado, no intrusiva para que no afecte a las otras aplicaciones cuyo trco se encuentre en la red y debe, en lo posible, funcionar en redes donde existan trayectos cableados e inalmbricos. El estimador de capacidad propuesto en [4], denominado AdHoc Probe, de acuerdo con los resultados que se mostrarn ms adelante, posee caractersticas muy interesantes que se ajustan a estos requerimientos. En [4], AdHoc Probe se evala mediante el simulador ns-2 en escenarios tanto estticos como mviles, sin trco cursado y con trfico cursado de
Poisson. Considerando que el trco de las redes actuales se ajusta mejor a un modelo de trco autosimilar, resulta imprescindible evaluar este estimador en redes con trco cursado de este tipo. En [6] se presenta un estudio de trco en redes ad hoc y, a partir de los resultados obtenidos en una red de prueba de 20 computadores, se concluye que el trco de esta clase de redes es altamente autosimilar. Mediante la implementacin de AdHoc Probe en QualNetR y utilizando las caractersticas del trco autosimilar en redes ad hoc encontradas en [6], en este artculo se evala el desempeo de AdHoc Probe en presencia de trco autosimilar y en diferentes escenarios. A partir de los resultados obtenidos en los mismos escenarios reemplazando el trco autosimilar por trco de Poisson, se analizan las limitaciones encontradas y se delimita el alcance de este estimador. El artculo est organizado de la siguiente manera. En la seccin II se describe el algoritmo de estimacin de capacidad de AdHoc Probe. Con el n de comparar los resultados obtenidos en [4] con los de este estudio, en la seccin III se presenta la metodologa utilizada para obtener un modelo de los nodos en QualNetR, de caractersticas similares al utilizado en ns-2. En la seccin IV se muestran los resultados de las simulaciones para diferentes escenarios, con trco cursado de Poisson y sin l. En la seccin V se presentan los resultados de los mismos escenarios con trco autosimilar. Finalmente, en la seccin VI se extraen las conclusiones de este trabajo.
81
II. DESCRIPCIN DE ADHOC PROBE AdHoc Probe es una herramienta que permite calcular la mxima tasa de transmisin alcanzable en un trayecto de una red ad hoc cuando no existe otro trco que compita por el uso de la misma. En una red ad hoc, la mxima tasa de transmisin usualmente es menor que la tasa de transmisin 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 sesin, etc. Estas caractersticas, propias de las redes inalmbricas, hacen que el proceso de estimacin de ancho de banda sea mucho ms complejo que en redes cableadas [4]. Para calcular la capacidad, el emisor, ubicado al comienzo del trayecto a evaluar, enva pares de paquetes de tamao jo, de extremo a extremo de la ruta, y marca cada uno de los paquetes con el tiempo de envo. 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 envo 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 trco 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 tamao de cada uno de los paquetes y T es la dispersin del par con menor OWD.
El concepto de dispersin proviene de una analoga con la teora de uidos y se explica en detalle en [7], [8] y [9]. La dispersin 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 estimacin, AdHoc Probe considera dos parmetros: la cantidad de pares de paquetes (N) y la tasa de envo de los mismos (R pares de paquetes/segundo). As, la duracin aproximada de una estimacin es N/R segundos. Es claro que cuanto mayor sea R, el proceso de estimacin ser ms rpido, pero si R es demasiado grande puede perturbar el trco cursado en la red o incluso congestionarla. Por otra parte, la precisin de la estimacin aumenta cuando N crece, sin embargo, un valor de N grande no es adecuado para redes mviles pues el tiempo de estimacin aumenta, lo cual no permitira capturar las propiedades dinmicas de las redes inalmbricas. Los valores de los parmetros N y R deben ser determinados cuidadosamente. En [4] no se indica ningn 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. METODOLOGA PARA OBTENER EL MODELO DE LOS NODOS EN QUALNETR Con el n de validar los resultados de [4] obtenidos con ns-2, se implementaron los mismos escenarios de
82
[4] en el simulador QualNetR. Fue necesario encontrar un modelo de los nodos en QualNetR que estableciera un radio de transmisin de 250 m y un radio de interferencia de 550 m. Slo utilizando modelos equivalentes de los nodos, sera posible comparar los resultados. En ns-2 los radios de interferencia y de transmisin se definen como distancias jas. En QualNetR, dichos radios se deben inferir a partir de los parmetros de conguracin de los nodos, especcamente la potencia de transmisin y la sensibilidad del receptor, para una distancia de separacin ja entre el transmisor y el receptor, que para todos los escenarios simulados en [4] es de 200m.
Tabla I. Conguraciones evaluadas cuyo radio de transmisin result ms cercano a 250 m. Potencia de transmisin [dBm] 10 11 12 14 Sensibilidad de receptor [dBm] -89 -85 -84 -82 Radio de transmisin [m] 254 252 252 252
bilidad del receptor, hasta encontrar aquellas en las cuales la mxima 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 conguraciones se evaluaron, como se indica ms adelante, para el clculo del radio de interferencia.
Figura 1. Escenario implementado en QualNetR para determinar el radio de interferencia de un nodo.
El clculo del radio de transmisin se realiza haciendo una bsqueda binaria, variando la distancia entre transmisor y receptor y evaluando en cada paso si la seal emitida por el transmisor es alcanzable para el receptor. En QualNetR [10] se considera que la seal es alcanzable si la potencia en el receptor es mayor o igual al umbral de recepcin y, si esto se cumple, tambin se verica que la tasa de error de paquetes (PER) sea menor al 10%. Este procedimiento se repite para diferentes combinaciones de potencia de transmisin y sensi-
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 trco entre dos nodos puede afectar a los ujos de nodos cercanos. El escenario consiste en dos ujos 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 ja y es igual a la distancia entre el nodo 3 y el 4. Para vericar la inuencia del radio de interferencia, se vara la distancia vertical entre los nodos 2 y 3. Aquella distancia vertical a partir de la cual los dos ujos alcanzan su mximo 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 n de demostrar la degradacin del desempeo de IEEE
83
802.11 cuando los nodos tienen un radio de interferencia mayor que el radio de transmisin. Para este escenario el generador de trco CBR se modic ligeramente. Dada una tasa de transmisin de n paquetes por segundo, se divide el tiempo de la simulacin en intervalos de 1/n segundos. En cada intervalo se enva un paquete a la red y el tiempo de envo del paquete se distribuye uniformemente en el intervalo. Con esto se evita que los dos ujos CBR intenten transmitir al tiempo y se presente una sucesin de colisiones, lo cual producira resultados incorrectos. Al igual que en [11], las mtricas 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 cuntos paquetes, del total de paquetes recibidos, llegaron mal.
Cada uno de los dos ujos CBR se congura para obtener un caudal de 819 kbps, enviando 100 paquetes de 1024 bytes por segundo, con el n de utilizar la mayor parte del ancho de banda cuando los dos ujos 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 funcin de coordinacin. Al compartir el canal, el caudal agregado incluso resulta inferior que la magnitud de los dos ujos agregados, como se observar en los resultados. En todas las simulaciones se congura el modelo de propagacin Two Ray Ground y se incluyen prdidas 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 vara la distancia entre los nodos 2 y 3. Ntese que la conguracin que recupera el caudal mximo ms cerca de 550m corresponde a la potencia de transmisin 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 vara la distancia entre los nodos 2 y 3.
Intuitivamente se esperara que al aumentar la distancia entre los nodos 2 y 3 tambin lo hiciera el caudal agregado; sin embargo, los resultados muestran un comportamiento muy diferente. Cuando la separacin entre los nodos 2 y 3 es menor que el radio de transmisin, 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 estn fuera de alcance uno del otro. En estas condiciones, los dos ujos 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 ujos. La situacin cambia completamente cuando la distancia entre los nodos 2 y 3 se aproxima y supera al radio de transmisin. Cuando los nodos 2 y 3 se encuentran fuera de sus respectivos radios de transmisin, se esperara que pudieran reusar el canal; sin embargo, el caudal muestra una cada dramtica 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 estn totalmente afuera del radio de interferencia del nodo 2, lo cual sucede simultneamente cuando los nodos 1 y 2 se encuentren afuera del radio de interferencia del nodo 3, el caudal agregado es mximo. En particular, la conguracin que alcanza el caudal mximo ms cerca de los 550 m, que es el radio de interferencia que se desea obtener, es aquella en la cual la potencia de transmisin es de 10 dBm y la sensibilidad del receptor es de 89 dBm. Para esa misma distancia, la tasa de error de esa conguracin es aproximadamente de 5%. Esta conguracin se utiliz en todos los escenarios presentados en este artculo y demostr que modela de forma muy aproximada los radios de transmisin y de interferencia requeridos. Sin embargo, es importante destacar que en QualNetR ambos ra-
85
dios representan una aproximacin, lo cual es ms cercano a la realidad, y fueron obtenidos especcamente para una distancia entre transmisor y receptor de 200 m. IV. VALIDACIN DE RESULTADOS UTILIZANDO QUALNETR A. Cadena de nodos Con el modelo de los nodos determinado segn 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 lnea recta y el trco AdHoc Probe se origina en el nodo 1 y se dirige hacia el nodo del
extremo opuesto (nodo 6). La lnea gruesa alrededor de cada nodo denota el radio de transmisin del mismo, la lnea punteada es el radio 4 de interferencia. Segn el estudio realizado en [5], si el radio de transmisin y de interferencia fueran iguales, la capacidad de la cadena sera 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 simultneamente. 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 podran transmitir a la vez. Por lo tanto, la utilizacin de la cadena sera de 1/3.
Figura 4. Topologa de cadena de nodos. El trco AdHoc Probe va desde el primer nodo de la cadena hacia el ltimo nodo. La lnea continua corresponde al radio de transmisin y la lnea punteada alrededor del nodo 4 denota el radio de interferencia.
Cuando el radio de interferencia es mayor que el radio de transmisin, la situacin empeora. Tal como se explica en [4], para un radio de transmisin de 250 m y un radio de inter-
ferencia de 550 m, la transmisin simultnea 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.
86
Figura 5. Capacidad estimada por AdHoc Probe para cadenas de nodos de diferente longitud y tamao de paquete. Se observa que existe una pequea 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 mxima (2 Mbps para este estudio) y una reduccin 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
Por otra parte, la capacidad alcanza su mximo valor para un solo salto y se reduce a medida que crece la cadena, conrmndose la relacin 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 estimacin terica explicada anteriormente. Para 5 nodos o ms, la capacidad de la cadena permanece constante y es de 400 kbps aproximadamente, tambin dentro del intervalo previsto. En la Figura 5 tambin se presenta la estimacin calculada en [4] con ns-2 cuando el tamao 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 transmisin jos 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-
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 QualNetR, para diferentes tamaos de paquete y variando el nmero de saltos de la cadena, se muestran en la Figura 5. Al reducir el tamao del paquete, los resultados demuestran que la capacidad estimada tambin decrece, lo cual es acorde con la relacin C=P/T.
87
cidad efectiva es C/N, debido a que solamente uno de los nodos puede transmitir a la vez. Esta capacidad
terica 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 trco AdHoc Probe tambin se dirige del primer nodo de la cadena hacia el ltimo de la misma. En esas condiciones los paquetes llegaran en un solo salto hacia el receptor dado que ste se encuentra dentro del radio de transmisin del nodo de origen. Para evitarlo, se conguraron rutas estticas 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 trco cursado horizontal y la segunda a una malla con trco cursado horizontal y vertical, como se observa en la Figura 7. Los nodos se encuentran separados 200 m entre s tanto vertical como
Figura 7. Malla de nodos con trco horizontal y vertical. En el escenario con trco horizontal se eliminan los ujos verticales; para 5 nodos, correspondera a los ujos entre los nodos 1-21, 2- 22, 3-23, 4-24 y 5-25. La estimacin de capacidad se hace en la la central, en este caso es el trayecto indicado por la lnea punteada.
horizontalmente. La estimacin de capacidad se realiza en el trayecto central con paquetes de 1500 bytes; las otras las llevan ujos de Poisson, cuya tasa vara entre 1 kbps y 100 kbps. El protocolo de enrutamiento
88
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 trco cursado horizontal y se comparan con los obtenidos en [4].
Figura 8. Capacidad estimada en una malla con trco cursado de Poisson en direccin horizontal, (a) mediante QualNetR y (b) segn [4].
Para los ujos hasta de 10 kbps la estimacin coincide con la capacidad de la cadena correspondiente, de acuerdo con la Figura 5. Al comparar los resultados de QualNetR con los 6 obtenidos en [4], se evidencia la diferencia mostrada en la Figura 5 para las mallas de 5 y 6 nodos, en QualNetR la capacidad de estas dos
cadenas resulta menor que la reportada en [4]. A medida que el trco cursado aumenta, la estimacin se diculta pues se reduce la probabilidad de que uno de los 200 pares de paquetes que se envan no encuentre trco cursado. El trco cursado puede tener dos
89
efectos sobre la estimacin, los cuales se tratan en detalle en [2], [7] y [9]. Se puede presentar una subestimacin de la capacidad cuando el segundo paquete del par sufre un retraso en cola debido al trco cursado. En este caso la dispersin del par de paquetes se incrementa y, en consecuencia, la capacidad estimada resulta menor. El efecto contrario se denomina compresin y sucede cuando el trco cursado retarda al primer paquete del par pero no al segundo. Este fenmeno hace que la dispersin entre el par de paquetes sea ms pequea
que la creada por el enlace cuello de botella, produciendo una sobreestimacin de la capacidad. Cuando el trco 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 ujos de 60 y 100 kbps el efecto ms frecuente es la subestimacin de la capacidad. El nico caso en el cual sucede lo contrario se obtuvo con QualNetR, en la malla de 4x4 con trco cursado horizontal y vertical, lo cual puede observarse en la Figura 9(a).
Figura 9. Capacidad estimada en una malla con trco cursado de Poisson en direccin horizontal y vertical, (a) mediante QualNetR y (b) segn [4]. Cuando el trco cursado satura la malla, puede suceder que la dispersin del par de paquetes se comprima o se expanda; el segundo caso resulta ms frecuente y cuando sucede, AdHoc Probe subestima la capacidad del trayecto
90
Los box plot de las Figuras 10 y 11 corresponden a las mallas de 6 y 7 nodos, donde se observa la mayor dispersin en las estimaciones. Para los ujos de 60 y 100 kbps y a medida que las mallas aumentan su tamao, la capacidad calculada por AdHoc Probe se encuentra en un amplio margen. Cuando existe trco cursado horizontal y vertical, la situacin es crtica. Para las cadenas de 6 y 7 nodos, la estimacin podra 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 dispersin, tiene dicultades para hacer la estimacin cuando el trco cursado satura la red.
Figura 10. Box plot de las mallas con trco cursado de Poisson en direccin horizontal. La lnea inferior de cada caja corresponde al valor del cuartil menor, la lnea 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 trfico cursado de Poisson en direccin horizontal y vertical. La lnea inferior de cada caja corresponde al valor del cuartil menor, la lnea 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 dispersin de los resultados es mxima para los ujos cursados de 60 y 100 kbps.
D. Nodo mvil 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 mvil, el cual se desplaza a 1 m/s a lo largo del trayecto indicado por 7 la lnea punteada. El trco AdHoc Probe se transmite del nodo 0 al 25 y se envan paquetes de 1500 bytes. Se simulan los casos con trco cursado y sin l. Los ujos cursados se establecen
entre los nodos 0-4, 5-9, 10-14, 15-19 y 20-24 y llevan trco 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 vara durante la simulacin. La estimacin de ancho de banda se realiza cada 50 segundos (el tiempo necesario para recibir los 200 pares de paquetes). En la Figura
92
Figura 12. Escenario con nodo mvil. El nodo 25 se desplaza con una velocidad de 1 m/s a lo largo de la ruta sealada con la lnea 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 mvil, con trco 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 direccin. En general AdHoc Probe logra una buena estimacin; sin embargo, entre 1000 y 1500 segundos de simulacin,
93
Figura 14. Box plot para el escenario del nodo mvil mostrado en la Figura 12. El eje horizontal es el tiempo de la simulacin. Se hicieron 20 corridas. La Figura 14(a) corresponde a la simulacin sin trco cursado y la 14(b) a trco cursado de Poisson.
cuando el nodo 25 se aproxima a los nodos 18, 19, 23 y 24, aumenta la dispersin de la capacidad estimada. No se debe al trco cursado pues en el box plot de la Figura 14 se observa que sucede lo mismo sin ste y obedece a la prdida 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 trco cursado se reduce la dispersin de la capacidad estimada, pues los nodos que llevan dicho trco ya han noti-
cado su presencia a la red y gracias a ello la ruta entre el nodo 0 y el 25 se establece ms rpidamente. V. DESEMPEO DE ADHOC PROBE EN ESCENARIOS CON TRFICO AUTOSIMILAR Ha sido ampliamente estudiado que los procesos de llegada de paquetes en una red se modelan con ms precisin utilizando procesos autosimilares que procesos de Poisson [14]. Con el n de completar la evaluacin de AdHoc Probe, se ha reemplazado el trco de
94
Poisson por trco autosimilar en las mallas de nodos con trco cursado y en el escenario del nodo mvil. Las trazas de trco 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 parmetro de Hurst (H) que posea la misma. El parmetro 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 trco 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 parmetro de Hurst para diferentes niveles de agregacin. Las trazas para la simulacin se generaron con H=0.95 y nivel de agregacin de
10 segundos, una vez obtenidas se veric si en efecto correspondan a ese valor utilizando el estimador de Whittle [15]. Dado que las trazas sintetizadas a partir de [12] entregan el nmero 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 nmero de llegadas por intervalo se convirti en un valor entero. Luego ese nmero de llegadas por intervalo se cambi a tiempos entre llegadas distribuyndolas uniformemente en el intervalo. Tal como en [4], se utilizaron paquetes de 1500 bytes tanto para el trco cursado como para AdHoc Probe y el promedio de paquetes en cada intervalo se escogi de manera que se lograra en promedio el ujo requerido para la simulacin (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 trco cursado autosimilar de parmetro H=0.95 en direccin horizontal.
95
Figura 16. Capacidad estimada en una malla con trco cursado autosimilar de parmetro H=0.95 en direccin horizontal y vertical.
En general, las capacidades estimadas con ujos cursados autosimilares y de Poisson tienen un comportamiento muy parecido. Para las mallas con trco cursado horizontal y vertical las estimaciones pierden precisin a medida que la malla aumenta su tamao, debido a la denominada autointerferencia entre paquetes de una misma sesin que se encuentran separados por unos pocos saltos. Los box plot de las mallas demuestran que el efecto del trco cursado autosimilar tambin es crtico cuando logra saturar la red, y en las Figuras 17 y 18 se observa que dicha saturacin se maniesta con la subestimacin y la sobrestimacin de la capacidad del trayecto. Esto sucede cuando el trco cursado es de 60 y 100 kbps y se acenta en las mallas ms grandes, de 6 y 7 nodos. Es interesante notar que en presencia de trfico cursado autosimilar horizontal y vertical, la estimacin mejora con respecto a los escenarios con trco de Poisson horizontal y vertical. En las Figuras 11 (a) y (b),
correspondientes a trco 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 estimacin. En las Figuras 18 (a) y (b), para trco 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 trco cursado autosimilar. El trco autosimilar, a diferencia del trco de Poisson, cuando es agregado en diferentes escalas de tiempo presenta un comportamiento caracterizado por la presencia de rfagas. Segn los resultados obtenidos, este comportamiento aumenta la probabilidad de que un par de 9 paquetes atraviese la red sin resultar afectado por el trco cursado y por ello mejora ligeramente el desempeo de AdHocProbe en condiciones de alto trco. Para el escenario del nodo mvil, aunque la mediana de las estimaciones tambin coincide con trco cursado y
96
Figura 17. Box plot para las mallas con trco cursado autosimilar de parmetro H=0.95 en direccin horizontal (a) malla de 6x6, (b) malla de 7x7.
Figura 18. Box plot para las mallas con trfico cursado autosimilar de parmetro H=0.95 en direccin horizontal y vertical (a) malla de 6x6, (b) malla de 7x7.
97
Figura 19. Mediana de la capacidad para el escenario del nodo mvil con trco cursado autosimilar y sin l. El eje horizontal es el tiempo de simulacin.
Figura 20. Box plot del escenario del nodo mvil con trco cursado autosimilar correspondiente a 20 corridas. El eje horizontal es el tiempo de la simulacin
sin l, igualmente se maniestan los problemas en la estimacin cuando hay trco cursado en la red y cambia la longitud de la cadena que separa al nodo 0 del nodo 25. Este efecto se observa en la Figura 19 y especialmente en la Figura 20, pues aumenta la dispersin en los instantes donde cambia el nmero de saltos y, por ende, el ancho de banda de la ruta.
VI. CONCLUSIONES AdHoc Probe es una herramienta de estimacin de capacidad que funciona efectivamente, siempre y cuando al menos un par de paquetes de la medicin no resulte afectado por el trco cursado. La fortaleza de AdHoc Probe radica en que combina el concepto de dispersin y del mnimo retardo, esto ltimo le da mayor precisin en
98
comparacin con otras tcnicas que utilizan solamente la dispersin para hacer la estimacin. Se comprob que la estimacin de AdHoc Probe es independiente del tipo de trco cursado que exista en la red, pero la calidad de los resultados depende de la intensidad del trco 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 estimacin recomendadas en [4], es decir, usando 200 pares de paquetes y 4 pares por segundo, la estimacin tomara alrededor de 50 segundos. Si la red cambia su topologa en este lapso, debido a nodos que se desplazan rpidamente, AdHoc Probe entregara una estimacin equivocada. Cuando existen nodos en movimiento, AdHoc Probe puede estimar la capacidad con algunas limitaciones. Si existe trco cursado en la red, le tomar ms tiempo estimar la capacidad cuando cambie la cantidad de saltos que separan al transmisor y al receptor. Desde luego, cuando el escenario es dinmico la rapidez con la cual el protocolo de enrutamiento encuentre las rutas afecta o favorece la estimacin de capacidad. A partir de los resultados obtenidos en este artculo se contina trabajando en evaluar el impacto del trco autosimilar sobre la red. As mismo se est trabajando en encontrar un algoritmo que permita anar los dos parmetros para la estimacin, es decir, el nmero 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-
cin entregue un resultado preciso. Tambin se est trabajando en una implementacin que permita obtener simultneamente la estimacin de la capacidad mxima y mnima de un trayecto en una red ad hoc. BIBLIOGRAFA [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 rst 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). Trafc 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-estimation methodology. IEEE ACM Transactions on Networking, 12, (6), Dic. 2004. [8] V. Jacobson y M. J. Karels. (Sept. 1988). Congestion avoidance and control. Presentado en ACM SIGCOMM. [9] C. Dovrolis, P. Ramanathan y D. Moore. (2001). What do packet dispersion techniques measure? Presentado en IEEE INFOCOM. [10] Scalable Networks Technologies. http://www.scalablenetworks. com [11] K Xu, M. Gerla y S. Bae. (2002). How effective is the IEEE 802.11 RTS/CTS handshake in Ad Hoc networks? Presentado en IEEE Globecom. [12] V. Paxson. Fast, approximate synthesis of fractional Gaussian noise for generating self-similar network trafc. Computer Communications Review, 27, pp. 5-18, Oct. 1997. [13] Scalable Networks Technologies, Qualnet 3.9 Users Guide, Octubre 2005 [14] V. Paxson y S. Floyd. Wide-area trafc: The failure of Poisson modeling. IEEE/ACM Transactions on Networking, 3, (3), pp. 226-244, Junio 1995. [15] J. C. Lpez. Contribucin al anlisis del impacto de la correlacin en las prestaciones de redes de alta velocidad. Tesis doctoral, Universidad de Vigo, 1999.
CURRCULOS Mara del Pilar Salamanca Azula, candidata a ttulo de Magster en Ingeniera Elctrica de la Universidad de Los Andes. Ingeniera Electricista (1996) de la Universidad Nacional de Colombia Sede Bogot. Su experiencia se centra en la administracin de redes de computadores, donde ha diseado e implementado soluciones de telefona IP, mensajera unificada, gestin de redes y seguridad informtica. Actualmente se encuentra vinculada al GEST (Grupo de Investigacin en Electrnica y Sistemas de Telecomunicaciones) como investigadora en el tema de estimacin de ancho de banda en redes ad hoc. Nstor Misael Pea Traslavia, Profesor Asociado, Departamento de Ingeniera Elctrica de la Universidad de Los Andes. Ingeniero Elctrico (1987), Magster en Ingeniera Elctrica (1989) y Matemtico (1991) de la Universidad de Los Andes. DEA en Telecomunicaciones (1994) y Doctor en Tratamiento de Seal y Telecomunicaciones (1997) de la Universit de Rennes 1 en asocio con la cole Nationale Suprieure des Tlcommunications de Bretagne (ENST Bretagne), Francia. Actual director del GEST (Grupo de Investigacin en Electrnica y Sistemas de Telecomunicaciones) de la Universidad de Los Andes. Sus reas de inters son el modelamiento electromagntico y desarrollo de estructuras y circuitos a muy altas frecuencias, y la ingeniera de trco en redes de telecomunicaciones.
100
Impacts of mobility on wireless access to IPv6 networks

Universidad Austral de Chile, Instituto de Informtica, General Lagos 2086, Casilla 567,Valdivia, Chile {clazo,rolandglockler}@uach.cl
Christian Lazo R., Roland Glckler
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 efcient 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 greles Access to IPv6 Networks gener una serie de hot spots utilizando tecnologa WiFi (IEEE 802.11b/g) en un ambiente IPv6 nativo. LA conguracin del proyecto habilita la conectividad extremo a extremo utilizando direccionamiento pblico global. Con la incorporacin de mecanismos de movilidad del IP mvil versin 6 (MIPv6), se pueden tener escenarios always-on con funciones de movilidad. Las conexiones de los clientes se manejan
101
con mecanismos ecientes 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
anlisis del impacto en el retardo y las tasas de transmisin causados por la movilidad del cliente en ambientes de mejor esfuerzo (best effort). PALABRAS CLAVE MIPv6, AAA, WiFi, Movilidad, optimizacin de rutas. Clasicacin Colciencias: A
102
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 trafc concentrator, there are requirements from services, applications and end users that can hardly be fullled with the commonly used communication protocols. First of all, there are many new types of applications such as Voice over IP (VoIP) or le 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 efcient. As can be seen, in such scenarios there is an agglomeration of difculties 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 efcient and less complex than in IPv4. In combination with the addressing advantage, always-on features can easily be provided.
103
The goal of the project AIRE 6 [3] was to generate hot spots of wireless Internet access using Wi-Fi (IEEE 802.11 b/g) in a native IPv6 environment, i.e., no IPv4 address is used in the testbed. One of the paradigms was to use free software wherever possible. 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. During the project, an AAA mechanism based on a web portal and packet ltering was developed. To provide wireless connectivity in an IPv6 only environment is basically no different than in IPv4, since all the wireless functionality resides in layer 2 of the OSI Reference Model, while
IP resides in layer 3. However, any management and control of an access point uses upper layer protocols and thus needs IPv6 support. Due to the absence of commercially available APs with IPv6 support, it was also necessary to generate an AP supporting IPv6 management during the project. 2. TESTBED 2.1 Network layout During the project, a complete native IPv6 network infrastructure was generated offering network access, routing, web, le transfer (FTP), mail, name resolution (DNS) and tunneling services. The also implemented RADIUS server was not used in the nal solution. Figure 1 below shows 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
to the IPv6 world. It is an integrated router with IPv6 functionality already incorporated. It provides the network prex 3FFE:400F:E001::/64 to the network ipv6.cl in which reside the project servers.
104
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 exibility. The wireless clients may belong to any of the subnetworks ALFA (network prex 3FFE:400F:EEEE:A::/64), BETA (network prex 3FFE:400F: EEEE:B::/64) or GAMMA (network prex 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 prexes, its own address and its capabilities, such as HA. For all successfully authenticated users, the rewall (packet lter) is opened for navigation. Trafc of other sources is restricted. The web portal in combination with the user database manages the rewall. 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 autocongure [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 doesnt 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 nodes (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 noties 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-conguration, binding update, and tunnel modication. 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
needed, there was no captive portal available with IPv6 support, and a simplied 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, rst 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 veried 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 nal check veries that the user has not an open session yet with the same address. If all steps are passed successfully, the rewall 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 notied in a new web page that he was denied access indicating the reasons. In the case of wrong user cre-
106
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 rewall settings are modied 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 rst 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 autoconguration of the IPv6 address was enough to start generating trafc, so everything was automatic and transparent. Before generating trafc in the mobility scenario, it was necessary to terminate the activation of MIPv6 capabilities, the autoconguration 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 trafc was to be generated via the home network. In the rst 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 le transfer between MN and the FTP server of the home network. The le size was 5 MB. In the results, shown in gure 4 and 5, the similari-
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 le transfer from home network.
108
Figure. 5. Transfer time measurements of le transfer from home network.
ties to the case of ping and traceroute become obvious. The transmission time and rate are quite constant and there is little difference between the two scenarios. In a second set of measurements, the peer was located close to the current location of the MN, namely in Europe (www.euro6ix.com). The results are shown in Figure 6. In this case the
difference between the scenarios is clearly visible. The explanation for the much longer duration of the mobility scenarios is the delay caused by the necessity to pass twice through transatlantic connections. A similar result can be appreciated in the measurement of traceroute shown in Figure 6. The number of hops in the mobility case is much 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 rst 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 signicant delay in the trafc. 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 efciency 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 efciency 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
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 scientic 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 efcient. 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 Innovacin Digital en Amrica 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;
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/ CURRCULOS Ing. Christian Lazo R. es profesor del rea de redes del Instituto de Informtica en la Universidad Austral de Chile. actualmente es candidato a Doctor en Ingeniera Telemtica por la Universidad de Vigo en Espaa, pas donde reside. Su rea de trabajo e investigacin gira en torno al protocolo IPv6, redes mviles y la problemtica de optimizacin de rutas e integracin en redes heterogneas. Roland Glckler es Ingeniero Electrnico Diplomado y Master of Science en Tecnologa de Informacin. Actualmente trabaja en la Universidad Austral de Chile (UACh), donde su rea de trabajo es la convergencia de redes de comunicaciones. Su actividad de investigacin se concentra en el proyecto VOI6E Voz sobre IPv6 en entornos inalmbricos. Tambin particip como co-investigador en el proyecto predecesor Acceso Inalmbrico con Redes IPv6 (AIRE6).
112
Desarrollo de un software Web y Mvil para la gestin de informacin de campo de cultivos agrcolas (AgrocomM)
Juan Manuel Delgado, Christian Giraldo
Mobilex - Parquesoft mobilex@parquesoft.com
Andrs F. Milln, Claudia Ziga, Jos Abada

Grupo de Investigacin COMBA I+D Universidad Santiago de Cali comba@usc.edu.co
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 benets to producers and farmers. We explain the development process for agriculture software, developed by the authors and funded by SENA. KEY WORDS Mobile computing, Java, mobile software, precision agricultura RESUMEN Este artculo presenta el estado del arte del software para la informacin
de campo agrcola, en especial el software que utiliza la conectividad inalmbrica y la movilidad para ofrecer benecios a los cultivadores y productores agrcolas. Adems se detalla el desarrollo de un software para este sector construido por la empresa Mobilex y el grupo de investigacin COMBA I+D de la Universidad Santiago de Cali con la nanciacin del SENA. PALABRAS CLAVE Agricultura de precisin, Java, computacin mvil, software mvil. Clasicacin Colciencias: A
113
1. INTRODUCCIN Colombia como un pas primordialmente agrcola, se enfrenta a los retos de la globalizacin, en especial al rmar acuerdos comerciales internacionales que exigen un alto nivel de competitividad externa en los sectores tradicionalmente importantes comercialmente como es el caso del sector agrcola. Por tal razn, los cultivadores y productores agrcolas colombianos han detectado la necesidad de optimizar sus procesos de precosecha, cosecha, recoleccin y distribucin de productos derivados del campo. El Gobierno colombiano en cabeza del Ministerio de Agricultura y Desarrollo Rural arma que negociaciones internacionales como el Tratado de Libre Comercio con los Estados Unidos abrirn 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 tecnologa [2]. Por otro lado, en esta nueva era de la informacin, el desarrollo de las tecnologas de la informacin y las comunicaciones han favorecido el mejoramiento de los procesos agrcolas, por ejemplo al facilitar la recoleccin de informacin en campo y la disminucin en los costos de personal. Estos benecios se han hecho ms notorios al utilizar tecnologas que permiten movilidad y adaptacin, dos caractersticas propias del trabajo agrcola. En la ltima dcada la investigacin en computacin mvil ha propiciado el desarrollo de sistemas inalmbricos de comunicaciones con mejor rendimiento y calidad de servicio, as como la construccin de plataformas de software mvil ms amigables,
econmicas y adaptables. Por este motivo se plantea el desarrollo de un software que utilice los ms recientes avances en tecnologas mviles y de internet, como herramienta para la gestin de informacin en campo de cultivos agrcolas, con la hiptesis de que se pueden optimizar el tiempo, la exactitud de la informacin y los costos del proceso de campo agrcola cuando apoyamos esa labor con una solucin informtica Web y mvil 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 informticos que benecien el proceso de campo agrcola como AgroWin de InSoft Ltda.[3]; sin embargo, la mayora de estas soluciones se basan en el manejo de la informacin de fincas agrcolas pequeas y de poca complejidad. Por otro lado, la investigacin reciente desarrollada en el campo de las tecnologas informticas (TI) aplicadas en la agricultura han demostrado que los sistemas de informacin agrcolas futuros destacarn tres lneas de profundizacin: TI aplicada al proceso de produccin, TI para el soporte de obtencin de informacin y TI para soportar la logstica [4]. Por esta razn las ms reconocidas empresas desarrolladoras de sistemas de informacin agrcolas como BIOSALC [5] o ISAGRI [6] estn trabajando en plataformas informticas que solucionen esos tres grandes problemas, pero con altos costos y soporte fuera del pas, lo cual hace asequible estas plataformas solo para grandes productores agrcolas. Por esta razn el grupo de investigacin se propuso
114
el desarrollo de un software que ofreciera soluciones en una de estas lneas de trabajo como es TI para el soporte de obtencin de informacin utilizando dispositivos mviles de mano con conectividad a redes mviles 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 implementacin de buenas prcticas agrcolas [7] en el cual se dene como una estrategia para el logro de los objetivos del plan, el desarrollo de sistemas de informacin para los actores del sector agrcola, en el cual se faciliten los procesos para el control, manejo de documentacin y registros requeridos. Este artculo est dividido en tres partes, la primera detalla el estado del arte actual de los sistemas informticos utilizados en el proceso de campo agrcola, luego se plantea el anlisis y el diseo del software propuesto. La siguiente parte explica el proceso de construccin de los mdulos del software para cumplir los requerimientos propuestos. 2. ESTADO DEL ARTE DEL SOFTWARE PARA GESTIN DE INFORMACIN EN CAMPO El desarrollo de software para la gestin de informacin agrcola en campo ha evolucionado a la par de los avances en tecnologa informtica, primero fueron los sistemas digitales de mano desconectados, luego el apoyo de los sistemas de informacin geogrca (GIS) y ms recientemente las aplicaciones y servicios mviles estn ofreciendo alternativas innovadoras para la problemtica de la obtencin de informacin agrcola en campo. El futuro en este sector es an
ms importante como lo demuestran los proyectos que han hecho uso en el campo agrcola de sensores inteligentes y arquitecturas de servicios Web en ambientes distribuidos [8]. Las soluciones mviles y Web agrcolas para el campo varan en su alcance, capacidad de interoperabilidad y complejidad, por eso encontramos soluciones para pequeos granjeros como PocketPAM [9] o LandMark Farm [10] o plataformas mviles que coexisten con soluciones agrcolas 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 mayora 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 mviles agrcolas existentes para la gestin de informacin en campo en el mbito mundial. En Colombia el desarrollo de soluciones agrcolas mviles que hacen uso de servicios Web para la gestin de informacin agrcola en campo es escaso. No se conoce de soluciones comerciales, pero s de prototipos desarrollados por centros de investigacin como el CIAT[14] o instituciones educativas como la Universidad Nacional de Colombia Sede Palmira [15]. La revisin realizada de las soluciones mviles y Web agrcolas en el nivel nacional e internacional recalca la necesidad de construir una aplicacin mvil y Web que apoye la gestin de informacin agrcola en campo en Colombia que permita la comunicacin con otras plataformas agrcolas de escritorio, igualmente se establecieron requerimientos importantes para el desarrollo de este proyecto.
115
Tabla 1. Algunas soluciones mviles agrcolas existentes para la gestin de informacin en campo en el mbito mundial Nombre del producto SIAP Empresa desarrolladora BIOSALC Pas de origen Brasil SO mviles soportados Palm OS
Sitio en internet www.biosalc.com.br [5]
FarmKeeper Mobile Agri-Pocket
FarmKeeper
Australia
www.farmkeeper.com [11]
Palm OS
ISAGRI
Francia
www.isagri.com [6]
Windows CE Palm OS
Trac Mate Site Mate Stock Mate Guide Mate LandMark PDA Pocket Crops
Farm Works Software
Estados Unidos
www.123farmworks.com [12]
Windows CE
Caractersticas principales Comunicacin con SIAGRI. Lectura usando cdigo de barras e infrarrojo. Arquitectura mvil desconectada. Seguridad y privilegios. Comunicacin con FarmKeeper de escritorio. Especializado en granjas ganaderas. Apoyo con mapas Comunicacin con aplicaciones de ISAGRI. Lectura usando cdigo de barras. Localizacin con GPS. Utiliza pantallas TFT para adaptarse a la luz ambiente. Soporte e instalaciones en toda Europa. Comunicacin con aplicaciones de Farm Works. Opcionalmente Localizacin con GPS. Aplicacin para gestin nanciera y actividades en granjas. Comunicacin con LandMark del escritorio Comunicacin con EASi Suite. Manejo de las operaciones, detalle de las operaciones e insumos. Soporta estndares Web como XML y COM Desarrollado por mdulos como Cosecha_Diaria, Soporte_GPS, Stock_Campo entre otros
iAgri
Estados Unidos Estados Unidos
www.iagri.com [10]
Palm OS
MapShots
www.mapshots.com [13]
Windows CE
PocketPAM
FairPort Farm Software
Australia
www.fairport.com.au [9]
PalmOS Windows CE
Una de las conclusiones ms importantes de la revisin del estado del arte es la exigencia de disear una solucin de software modular que en la primera versin dar importancia a la informacin requerida para las actividades agrcolas en campo, pero luego se introducirn soluciones informticas mviles y Web para los problemas de transporte, logstica y localizacin. 3. ANLISIS Y DISEO DE UN SOFTWARE DE GESTIN DE INFORMACIN DE CAMPO AGRCOLA La captura y manipulacin de informacin asociada a la produccin, los
cultivos y las cosechas, es importante para los cultivadores y productores agrcolas. La falta de informacin oportuna y conable genera sistemas manuales con controles inadecuados en las labores de campo, lo que afecta directamente en la produccin y la baja calidad de la materia prima. Actualmente las empresas agrcolas con mayor nivel de inversin tienen sistemas informticos robustos en sus plantas de produccin, pero tanto las empresas grandes como las pequeas tienen un problema en comn y es que no cuentan con base tecnolgica instalada en las zonas rurales donde se realizan las labores de cosecha, esto se debe a las condiciones propias
116
de los terrenos y a las restricciones tcnicas y tecnolgicas que all se presentan. En pocos casos se ha intentado implementar sistemas de cmputo usando comunicaciones inalmbricas instaladas por el cosechador o productor agrcola, debido a que esta solucin presenta algunas desventajas como el poco conocimiento que tienen las personas que laboran en campo sobre estas tecnologas, sumado a la gran inversin que representa tener computadores, antenas y servicios de conexin dedicados por cada nca o hacienda donde se tienen cultivos. Por esta razn la mayora de empresas del sector agrcola realizan la captura de informacin en campo de forma manual, esta informacin recopilada semanal o quincenalmente no es actualizada y generalmente se presenta en formatos poco legibles que son digitados en un sistema de cmputo ubicado a una larga distancia de las ncas donde se realiza el cultivo y la cosecha o viceversa cuando la informacin debe ser enviada a los dispositivos en campo, generando que los tiempos de respuesta sean muy extensos e inadecuados, causando que los entes administrativos o de campo no tomen decisiones oportunas que optimicen el desarrollo de las labores, afectando as los costos totales del proceso. AgroComM no se concibi como un software a la medida sino como una plataforma informtica flexible y adaptable a empresas agrcolas en sectores diversos como el azucarero, panelero, algodonero y de palma africana, entre otros. El objetivo fue satisfacer las necesidades de los distintos clientes con la mnima cantidad de cambios mediante un software totalmente parametrizable. Teniendo
en cuenta esto, el equipo investigador en su primera fase realiz un anlisis de requerimientos muy detallado de la mano de expertos de la labor de campo agrcola en varias empresas importantes del sector como el Ingenio Mayagez [16], posteriormente se aplic una metodologa para modelar un sistema que fuera eciente y ptimo al usuario, adems usable, prctico y que pudiera interactuar con las plataformas informticas existentes en la programacin y control del campo agrcola como SIAGRI. 3.1 Metodologa utilizada La metodologa que se emple utiliz lo mejor de las tcnicas de la metodologa clsica de software, realizando una mezcla entre RUP (Rational Unied Process) y XP (Extreme Programming). En la etapa de anlisis se emplearon diagramas de casos de uso, diagramas de clases y distribucin; en la etapa de diseo se emplearon las historias de usuario, planes de pruebas de unidad, codicacin y pruebas de aceptacin, estas ltimas con la colaboracin de la empresa Green SQA para lograr un aseguramiento de la calidad del software durante todas las etapas del desarrollo del software. 3.2 Arquitectura del software AgroComM es un software para la gestin de informacin de campo agrcola, que permite la asignacin y control de actividades a travs de valoraciones y registro de inconsistencias. AgroComM est dividido en tres mdulos: uno de captura de datos para dispositivos mviles, uno Web y uno de conexin, transferencia y sincronizacin de datos. El mdulo de captura de datos permite ingre-
117
sar toda la informacin relacionada con evaluaciones de campo (cosecha, quema, corte, transporte, maleza, insumos, plaguicidas, fertilizantes, etc.) e inconsistencias haciendo uso de un dispositivo mvil. El mdulo Web permitir la gestin y asignacin de las actividades de campo, as como las consultas necesarias sobre la informacin registrada desde una estacin conectada a internet. El mdulo de conexin, transferencia y
sincronizacin ser el encargado de realizar la transmisin de los datos capturados en el dispositivo a un sistema de base de datos residente en una estacin de trabajo. Esta transmisin se puede realizar conectando el dispositivo mvil directamente a la estacin usando ActiveSync o conectndose a travs de red inalmbrica IP como GPRS o Wi-Fi. La Figura 1 muestra en detalle la arquitectura del software.
Figura 1. Arquitectura AgroComM.
El patrn utilizado para la arquitectura del software es el denominado Modelo, Vista, Control (MVC) [17]. La arquitectura MVC (Model/ View/Controller) fue diseada para reducir el esfuerzo de programacin necesario en la implementacin de sistemas mltiples y sincronizados de los mismos datos. Sus caractersticas 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 reeje automticamente en cada una de las Vistas. El Modelo es el objeto que representa los datos
del programa, los maneja y controla todas sus transformaciones, no tiene conocimiento especco 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 noticar a las Vistas cuando cambia el Modelo. La Vista es el objeto que maneja la presentacin visual de los datos representados por el Modelo. El Controlador es el objeto que proporciona signicado a las rdenes del usuario, actuando sobre los datos representados por el Modelo,
118
cuando se realiza algn cambio, entra en accin, bien sea por cambios en la informacin del Modelo o por alteraciones de la Vista, e interacta con el Modelo a travs de una referencia al propio Modelo. 4. DESARROLLO DE UN SOFTWARE WEB Y MVIL PARA LA GESTIN DE INFORMACIN DE CAMPO AGRCOLA AgroComM cuenta con una plataforma mvil (Figura 2) desarrollada en C# con un sistema de bases de datos en SQL Server Mobile, tambin se usan esquemas XML para optimizar
el almacenamiento de datos entre el aplicativo mvil y la base de datos mvil. 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 desempeo y permite actualizaciones constantes de registros sin que se sacriquen los recursos de la mquina. Una ventaja de utilizar la misma base de datos en su versin de escritorio y en la versin mvil es que se logra mayor integracin, mejor rendimiento y conabilidad en la aplicacin web - mvil.
Figura 2. Plataforma mvil de AgroComM.
Figura 3. Plataforma Web de AgroComM.
La informacin capturada en la plataforma mvil, es transmitida a la plataforma web que usualmente estar ubicada fsicamente en la planta o en las ocinas de la fbrica. Para la transmisin de datos, el sistema presenta al usuario dos opciones: off-line y on-line. La opcin off-line implica almacenar la informacin en
la base de datos del dispositivo mvil hasta que sta pueda ser transmitida a la base de datos central por medio inalmbrico o fsico (USB), y esta es la alternativa ms viable para la transmisin de informacin pues es de bajo costo y no requiere una conexin de comunicaciones permanente. La alternativa on-line permite
119
la transmisin de informacin de campo en lnea, es decir, la actualizacin de la base de datos central de forma simultnea haciendo uso de una red celular GSM/GPRS o una red inalmbrica local. Una ventaja importante de la aplicacin al usar GPRS es la taricacin por parte del operador de telefona celular, donde slo se factura por la informacin transmitida y no por el tiempo de conexin. Esto hace posible tener una aplicacin en la que un dispositivo mvil 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 sincronizacin de datos. 4.1. Sincronizacin AgroComM Sincronizar datos entre un dispositivo mvil y una base de datos localizada remotamente demanda un anlisis profundo sobre las diferentes tcnicas de sincronizacin disponibles en una determinada plataforma de desarrollo, cules son las ventajas y desventajas que aportan cada una de estas tcnicas al desarrollo de un proyecto y en qu aspecto resulta ms 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 sincronizacin de datos: Merge Replication y Remote Data Access (RDA) [18]. El proceso de sincronizacin, cualquiera que sea el mtodo utilizado, maneja la misma arquitectura, se requiere de una base de datos remota, una base de datos local y un canal de comunicacin.
Revisando a grandes rasgos los mtodos de sincronizacin, se observa que Merge Replication proporciona un gran mecanismo de resolucin de conictos, haciendo uso de Triggers, Store Procedures, etc., los cuales automatizan los procesos de sincronizacin; RDA por el contrario ofrece una mayor escalabilidad a los posibles cambios realizados en los clientes mviles. RDA permite mantener la sincronizacin entre una base de datos en un dispositivo mvil y una base de datos remota, sin necesitar una conexin 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 mvil 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 (ofine) Agregar, modicar, borrar y consultar datos. Push Enva las modicaciones realizadas al servidor.
120
De otro lado Merge Replication es una tcnica que aporta autonoma e independencia al dispositivo a la vez que facilita el sincronismo de los datos cuando desean ser volcados al servidor. Dentro de esta tcnica se deben distinguir dos miembros: los Publicadores y los Subscriptores. Los Publicadores envan 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 mvil. En un entorno real, los datos tanto en local como en la base de datos cambian con el tiempo; empleando este modelo, la sincronizacin de los datos se realiza tanto en el servidor remoto como en los clientes, recuperando datos nuevos o las modicaciones de los datos existentes. Dada la naturaleza del proyecto AgroComM, en el cual se hace uso de una red GPRS y de una conexin fsica del dispositivo con el servidor, se consider la posibilidad de utilizar
ambas tcnicas de sincronizacin, no simultneamente, pero s en los escenarios y momentos en donde cada una nos puede brindar su mejor desempeo. Cuando el usuario mvil realiza la primera sincronizacin o la reanudacin de la misma por el cambio de usuario, se lleva a cabo una conexin de datos con el servidor, este proceso requiere la utilizacin de una tcnica que garantice un ptimo desempeo adems del control de conictos, de igual manera las actualizaciones por va GPRS necesitan un ltro de informacin que garantice la mayor optimizacin del canal. Es precisamente en este escenario donde la sincronizacin por Rplica o Merge Replication se ajusta idealmente. Sin embargo, parte del proceso inicial de sincronizacin incluye la validacin 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 La replicacin posee caractersticas para resolver los conictos de sincronizacin. Permite la sincronizacin de datos de mltiples tablas en un tiempo. En RDA esto no era posible, nicamente se haca un Pull del conjunto de datos a traer. Permite el monitoreo de cada publicacin. A diferencia de RDA, la replicacin es bidireccional. Tanto el servidor como el cliente son sincronizados y actualizados. No es necesario borrar las tablas del cliente. Resolucin de conictos automtica. Desventajas La replicacin 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 modicada creando diversos Disparadores y Procedimientos almacenados para facilitar la sincronizacin y la resolucin de conictos. A todas las tablas replicadas se les aade un ROWDGUIDCOL con el n de mantener las tablas sincronizadas y capacitar a las las de un identicador nico. Esta nueva columna en la tabla causa un aumento del trco y del tamao de la memoria, por ejemplo en una tabla con nicamente 32 registros, el aumento al aadir 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 agrcolas en Colombia en cuanto a la gestin de informacin en campo, en especial al tener que afrontar en los
121
prximos aos los desafos de la globalizacin y los acuerdos comerciales multilaterales que promueven una alta competitividad. Los altos costos de personal, la prdida de calidad en la materia prima, los sobrecostos por retrasos en los procesos de cosecha y transporte y el mal manejo de la informacin disponible son razones de peso para que los cultivadores y productores agrcolas identifiquen cmo las tecnologas informticas pueden contribuir a un proceso ptimo que los haga ms competitivos en los mercados mundiales. El grupo de desarrollo pudo constatar las ventajas y desventajas que tiene la plataforma.NET en los ambientes mviles y Web considerando aspectos tan relevantes como la sincronizacin de datos, la transmisin de datos va redes inalmbricas y el diseo arquitectnico de una solucin Web-mvil. Dentro de los benecios se destaca la rapidez en el proceso de desarrollo, el buen entorno de interface usuario y el rendimiento del sistema de sincronizacin, sin embargo aspectos claves como la interoperabilidad entre los sistemas operativos mviles de Microsoft con la plataforma de desarrollo.NET deben ser sujeto de revisin. El grupo de investigacin compuesto por Mobilex como empresa desarrolladora y de COMBA como equipo consultor, demostraron que es factible la realizacin de proyectos comerciales en conjunto con grupos de investigacin cientca que desean promover la innovacin tecnolgica en Colombia. Estos proyectos fortalecen la capacidad investigativa de los grupos de investigacin y permiten generar soluciones actualizadas e
innovadoras a los emprendedores de empresas de base tecnolgica. COMBA en conjunto con MobilEx continuar desarrollando soluciones para el sector agrcola colombiano como son los mdulos de transporte, logstica y localizacin usando dispositivos mviles as como la realizacin de un proyecto piloto en Colombia que permita el uso de sensores inteligentes en campo cuya informacin pueda ser coleccionada automticamente usando tecnologas inalmbricas y aplicaciones Web. BIBLIOGRAFA [1] Arias, Andrs. El TLC y nuestra agricultura. Ministerio de Agricultura y Desarrollo Rural. Colombia. 2005. [2] Arias, Andrs. Inversin en ciencia y tecnologa 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] Pgina Principal de BIOSALC. www.biosalc.com.br [6] Pgina Principal de ISAGRI. www.isagri.com [7] Plan Nacional para la implementacin de buenas prcticas agrcolas. Ministerio de Agricultura y Desarrollo Rural. Colombia. 2005. [8] Chaudhary Sanjay et al. Architecture of Sensor based Agri-
122
cultural Information System for Effective Planning of Farm Activities. Proceedings of the 2004 IEEE International Conference on Services Computing. IEEE Computer Society. 2004. [9] Producto PocketPAM. Fairport Farm Software. www.fairport. com.au. 2006 [10] Producto LandMark Farm. iAgri Software. www.iagri.com. 2006 [11] Producto FarmKeeper Mobile. FarmKeeper. www.farmkeeeper.com. 2006 [12] Farm Works Software. www.123farmworks.com. 2006. [13] Pocket Crops. MapShots. www. mapshots.com. 2006. [14] Centro Internacional de Agricultura Tropical. www.ciat.cgiar. org. 2006. [15] Universidad Nacional de Colombia Sede Pamira. www. palmira.unal.edu.co. 2006 [16] Ingenio Mayagez. www.ingeniomayaguez.com. 2006. [17] Burbeck, Steve. Application programming in Smalltalk- 80: How to use Model-View-Controller (MVC). University of Illinois. 1992. [18] Zorrilla, Unai. RDA & Merge Replication. MSDN Latinoamrica. Microsoft. CURRCULOS Juan Manuel Delgado es Ingeniero de Sistemas de la Universidad San Martn. Gerente de Mobilex S.A. Investigador Asistente del Grupo de Investigacin COMBA I+D. Docente SENA.
Christian Libaniel Giraldo es Ingeniero de Sistemas y Telemtica de la Universidad Santiago de Cali. Director de Desarrollo en Mobilex S.A. Investigador Asistente del Grupo de Investigacin COMBA I+D. Andrs Felipe Milln es Ingeniero de Sistemas de la Universidad Icesi de Cali. Mster en Sistemas de Redes y Comunicaciones de la Universidad Politcnica de Madrid Espaa. Actualmente se encuentra realizando el Doctorado en Ingeniera Telemtica en la Universidad de Vigo en Espaa. Profesor titular de la Universidad Santiago de Cali. Jefe del rea de Redes y Telemtica de la Facultad de Ingeniera de la Universidad Santiago de Cali, Director del Grupo de Investigacin COMBA I+D. Presidente del Captulo Valle de la ACIS Colombia. Miembro Fundador del Consorcio de Investigacin en Computacin Mvil - I2COMM. Claudia Liliana Ziga es Ingeniera de Sistemas y Telemtica de la Universidad Santiago de Cali. Actualmente se encuentra realizando el Doctorado en Ingeniera Telemtica en la Universidad de Vigo en Espaa. Docente Investigadora de la Universidad Santiago de Cali. Investigadora Principal del Grupo de Investigacin COMBA I+D. Coordinadora del SIG de Desarrollo Mvil de COMBA I+ D de la Universidad Santiago de Cali. Miembro Fundador del Consorcio de Investigacin en Computacin Mvil - I2COMM.
123
Jos Lisandro Abada es Estudiante de dcimo semestre de Ingeniera de Sistemas y Telemtica de la Universidad Santiago de Cali. Investigador Asistente del
Grupo de Investigacin COMBA I+D. Vicepresidente de la Rama Estudiantil IEEE de la Universidad Santiago de Cali.
124
Evaluacin experimental de la capacidad de IEEE 802.11b para soporte de VoIP*

Miembro IEEE. Grupo I+D Nuevas Tecnologas en Telecomunicaciones
Guefry Leider Agredo Mndez Jaime Andrs Gaviria Molano
Miembro IEEE. Divisin de Tecnologas de Informacin y Comunicacin Universidad del Cauca, Popayn Colombia Universidad del Cauca, Popayn Colombia { gagredo,jgaviria}@unicauca.edu.co
ABSTRACT 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 WLANs. This papers shows experimental results for a testbed, intended to establish the capacity of a legacy 802.11 LAN to support VoIP services.
KEYWORDS MAC, DCF, QoS, VoIP, Wireless LAN, 802.11, ITG, Asterisk RESUMEN A la fecha existe gran cantidad de redes inalmbricas de rea local implementadas a nivel mundial sobre los estndares 802.11a/b/g pero que no proveen ningn tipo de control o acciones para ofrecer QoS puesto que son previas a la generacin del actual 802.11e. Sin embargo, en varios de estos lugares se ha visto la necesidad de realizar la transmisin 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 nanciado en parte por Unicauca en el marco de desarrollo de la Maestra en Ingeniera.
125
teniendo en cuenta una gran cantidad de factores que no se pueden tener en escenarios de simulacin. En este artculo 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 vericacin de dos formas, usando el generador de trco ITG y haciendo la generacin de llamadas reales usando la PBXVoIP Asterisk. Como resultado, se encontr que lo obtenido por ambas vas fue en general coincidente y que en las redes inalmbricas sin ningn tipo de manejo de QoS el principal limitante en la capacidad y en el nmero de llamadas concurrentes es la contienda por el acceso al medio y no tanto el tipo de cdec usado y/o el ancho de banda que consume cada llamada. Al nal se pueden observar los resultados resumidos en tablas, que
muestran la mxima cantidad de llamadas sin degradacin de la calidad para cada cdec usado. Se concluye tambin que en una red 802.11b la capacidad de canales de VoIP no puede calcularse ni aproximarse con una simple divisin entre ancho de banda total y ancho de banda por canal, sino que deben considerarse ms factores, pues, lo que se observa inicialmente es una degradacin cuasi-exponencial al aumentar el nmero de comunicaciones hasta cierto punto y luego se tiene una degradacin abrupta que incluso hace caer las dems comunicaciones de voz que se estn realizando en ese momento. PALABRAS CLAVE MAC, DCF, QoS, VoIP, Wireless LAN, 802.11, cdecs, ITG, Asterisk Clasicacin Colciencias: A
126
I. INTRODUCCIN Las redes inalmbricas IEEE 802.11[1], conocidas tambin con el nombre comercial de Wi-Fi[2], se han convertido en las redes de datos inalmbricas con mayor tasa de penetracin a todos los niveles: pblico (Hotspots), empresarial, SoHo y en el hogar; inclusive y como aspecto relevante esta tecnologa ha hecho viable la comunicacin de datos y voz a zonas rurales [3] y el establecimiento de comunidades inalmbricas. Esta tendencia ha despertado el inters en la fabricacin de dispositivos para redes inalmbricas, 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 ujos de audio y video generados desde un DVD o computador puedan ser fcilmente distribuidos a televisores, equipos de sonido o parlantes en cualquier lugar del hogar. As, la tecnologa de las redes IEEE 802.11 se convierte en la tecnologa inalmbrica de preferencia para el transporte de estos tipos de informacin debido principalmente a dos factores claves: sus relativas altas tasas de transferencia de datos y su carcter dominante en el mercado. Avances recientes en la familia IEEE 802.11, especialmente la nalizacin de la norma IEEE 802.11e, han generado el marco propicio para la consolidacin del rol de 802.11 en las aplicaciones de Voz sobre IP. 802.11e; es una extensin a los estndares 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 funcin de coordinacin hbrida (HCF, Hybrid Coordination Function) como el esquema de control de acceso al medio. Esta especicacin es compatible con los sistemas tradicionales de las redes 802.11, esto es: la funcin de coordinacin distribuida (DCF, Distributed Coordination Function) y la funcin de coordinacin 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 inalmbricas ni en los dispositivos mviles idneos para la transmisin de VoWLAN como PocketPC y PALMS, por lo que resulta interesante evaluar la capacidad de estos sistemas, para soportar comunicaciones de voz con diferentes cdecs usando redes inalmbricas 802.11b. Un paquete tpico 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 cdec que se utilice. Por tanto, la eciencia en el nivel IP para VoIP es menos del 50%. En el nivel fsico y en el de enlace de 802.11, la prdida de eciencia aumenta, as por ejemplo, para el cdec de GSM, con una carga til de 33 bytes, el tiempo de transmisin a 11 Mbps es 33x8/11=24s y el tiempo de transmisin para el encabezado IP/UDP/RTP de 40 bytes es 40x8/54=29s. Sin embargo, estos niveles tienen una carga adicional de ms de 800s, atribuida al prembulo de nivel fsico, al encabezado MAC, al tiempo de contencin, a la espera de ACK y al intercambio entre transmisin y recepcin. Como resultado, la eciencia general cae aproximadamente al 30%.
127
En una WLAN empresarial o en Hotspots pblicos, el soporte de VoIP se torna an ms complicado, dado que se requiere el soporte simultneo de otras aplicaciones aparte de VoIP. La necesidad de atender este tipo de escenarios limita el nmero de sesiones de VoIP posibles. II. CALIDAD DE SERVICIO Calidad de Servicio (QoS, Quality of Service) se reere a la capacidad de la red para proporcionar un mejor servicio a trco seleccionado de varias tecnologas de red. QoS procura que el trco de tiempo real de aplicaciones multimedia y de voz reciba la ms alta prioridad, el mayor ancho de banda y el menor retardo en comparacin con el trco de datos considerado como de al mejor esfuerzo . [4] Las tecnologas 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 inalmbrico. 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. Tambin se conoce como retardo de extremo a extremo. Jitter: diferencia en el retardo de extremo a extremo entre varios paquetes. Prdida 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
y las prdidas de paquetes para los tipos de trco seleccionados dentro de lmites aceptables. Los requerimientos que se deben cumplir cuando se trabaja con voz sobre IP son: Retardo mximo en un sentido no mayor de 150 ms (de acuerdo con la recomendacin ITU-T G.114). Sin embargo, es importante considerar que los usuarios normalmente notarn los retardos de la voz si estos en viaje redondo sobrepasan los 250 ms [5]. Prdida de paquetes mnima: VoIP no es tolerante a las prdidas de paquetes, aun con un 1% de paquetes perdidos se puede degradar enormemente una comunicacin de voz as se est utilizando el cdec G.711, en caso de utilizar cdecs con mayor tasa de compresin la prdida es prcticamente 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 inalmbrica para soportar llamadas de VoIP se tomaron los lmites anteriores, y si al realizar una llamada adicional se sobrepasaba la prdida de paquetes, el retardo o el jitter, se consideraba que se haba logrado establecer la capacidad para cada cdec. 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-
128
tion Function). El segundo mtodo rara vez es implementado en equipos del mercado, y tampoco est presente en los equipos usados en este laboratorio. Por este motivo slo se cuenta con el esquema DCF que se describe a continuacin. DCF trabaja en un esquema revisarantes_de-enviar, basado en CSMA (Carrier Senses Multiple Access). Cualquier estacin primero detecta si existe alguna transmisin en curso en el medio inalmbrico (revisa), y solamente cuando lo encuentra libre puede transmitir (enva). Sin embargo, si dos estaciones detectan libre el medio al mismo tiempo, podra ocurrir una colisin. Por esto, 802.11 dene un mecanismo para evitar la colisin, por medio del cual todos deben esperar un tiempo aleatorio antes de enviar para evitar colisiones, de esta forma cada estacin debe desarrollar un procedimiento de backoff antes de iniciar, as, cada estacin debe permanecer escuchando el medio por un intervalo aleatorio con una duracin mnima 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 contencin (Contention Window); sta consta de dos parmetros CWmin y CWmax. Inicialmente el nmero aleatorio est entre 0 y CWmin. Si el backoff original expira antes de que pueda enviarse la trama, el contador se aumenta y el tamao de la ventana de contencin se dobla. Esta situacin contina hasta que se alcance el CWmax. Los reintentos continan hasta que se venza el tiempo de vida de los paquetes (TTL). Luego de cada transmisin exitosa
de una trama, la estacin receptora devuelve un reconocimiento (ACK) inmediatamente. Si luego del envo de una trama no se recibe el ACK se asume que la transmisin no ha sido exitosa. IV. MONTAJE DEL SISTEMA Para el montaje del sistema y ante la necesidad de aproximarse a un entorno de operacin real, se realiz el montaje tal como se indica en la Figura 1, en donde se cont con seis clientes conectados inalmbricamente 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 heterogneo en cuanto a modelos y marcas de equipos que trabajan con 802.11b, as mismo los computadores usados tuvieron diferentes caractersticas hardware y ubicacin en el laboratorio. El sistema operativo usado fue GNU/Linux, en dos distribuciones: Ubuntu y RedHat. En las Figuras 2 y 3 se muestran fotografas de la infraestructura utilizada. La descripcin 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 inalmbricamente, pues es el caso tpico de una implementacin real, ya que es poco frecuente que dos estaciones asociadas al mismo punto de acceso requieran una comunicacin 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 inalmbricos, 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. Descripcin de la infraestructura utilizada. Equipo/ Caractersticas Cliente1 Cliente2 Cliente3 CPU Pentium M 1.5Ghz Pentium 4 2.6Ghz Pentium 4 2.6Ghz Pentium 3 800Mhz Memoria 512MB 512MB 512MB Red BroadCom Wireless Dlink / Atheros Wireless Dlink / Atheros Wireless 3COM PCMCIA Wireless DLINK AP2100 Wireless Client Mode DLINK AP2100 Wireless Client Mode Atheros Wireless BCM330 2 Sistema operativo Debian GNU/Linux 3.1 Ubuntu GNU/Linux 5.03 Ubuntu GNU/Linux 5.03 Ubuntu GNU/Linux 5.03 Software Asterisk PBX 1.0.9 - ITG Asterisk PBX 1.0.6 - ITG Asterisk PBX 1.0.6 - ITG Asterisk PBX 1.0.6 - ITG Direccin IP 192.16 8.1.100 192.16 8.1.101 192.16 8.1.102
Cliente4
128MB
192.16 8.1.103
Cliente5
Pentium 3 800Mhz Pentium 3 500Mhz Pentium 4 2.6Ghz BCM330 2 216 Mhz
128MB
Linux RedHat 9.0 Ubuntu GNU/Linux 5.03 Ubuntu GNU/Linux 5.03 Linux OpenWRT
Asterisk PBX 1.0.7 - ITG Asterisk PBX 1.0.6 - ITG Asterisk PBX 1.0.6 - ITG wireless utils
192.16 8.1.104
Cliente6 Servidor VoIP Punto de Acceso Linksys WRT54G
128MB 512MB 16 MB
192.16 8.1.105 192.16 8.1.2 192.16 8.1.1
802.11g pero se forz la conguracin de los equipos 802.11g para que trabajaran exclusivamente con la norma 802.11b. La conexin y ubicacin de los equipos fue tal que todos trabajaran a 11Mbps durante el tiempo de las pruebas, sin posibilidad de que se negociara a una velocidad menor. Los dispositivos usados fueron tarjetas inalmbricas PCI, PCMCIA, miniPCI e incluso puntos de acceso congurados como wireless client, obteniendo un ambiente totalmente heterogneo con diferentes marcas y tipos de equipos. En cuanto al sistema operativo, se instal GNU/Linux en todos los equipos, tanto cliente como servidor, e incluso en uno de los puntos de acceso, lo que dio una exibilidad enorme en conguraciones, toma de datos y permiti el uso de una gran cantidad de herramientas como Iptraf para
el diagnstico de interfaces de red, ITG para la generacin de Trco de Internet y Asterisk como Servidor de VoIP, los cuales se detallarn en la siguiente seccin V. METODOS DE EVALUACIN Para realizar el trabajo experimental y establecer la capacidad se recurri al uso de dos herramientas open source encargadas de generar las llamadas. Una fue el Generador de Trco de Internet ITG [13] que tiene la capacidad de generar trco de VoIP con tres cdecs: G.711, G.729 y G.723, la otra fue el Servidor de VoIP Asterisk [10] con capacidad para soportar los mismo cdecs y algunos ms, sin embargo para el ejercicio comparativo se tomaron los mismos del ITG. Para vericar la ocupacin 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 caractersticas de este cdec 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 cdecs de ITG. Cdec Tasa de Bits (Kbps) Paquetes /segundo G.711 84 50 G.723.1 16.6 26 G.729 28 50.
Para el proceso de instalacin se deben seguir estos pasos: Una vez se copia, se debe descomprimir $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 cdigo 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 Si esta es la situacin 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 instalacin a mano, pues es solicitado. root@ryst15:~/ITG/src$ aptget install g++ Si es con Redhat se hace por medio de la instalacin del RPM apropiado. Luego de tener instalado este paquete ya se puede compilar el D-ITG con el comando antedicho.
Tabla III. Atributos de los cdecs de Asterisk. Cdec Tasa de Bits (Kbps) Paquetes /segundo G.711 84 50 G.723.1 18.2 26 G.729 28 50
A. Evaluacin de la capacidad con ITG Para realizar el proceso de evaluacin por este camino, se descarg el paquete D-ITG, Distributed Internet Trafc Generator Versin 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 tambin en el equipo central, tal como lo muestra el siguiente comando: # scp D-ITG-2.4.zip root@192.168.1.104:/root
132
[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 va se requiere un servidor NTP para sincronizacin 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 sincronizacin se perda rpidamente, adems se consider que la llamada sera en doble va por lo que tambin 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 decodica y presenta en formato humanreadable. En este se encuentran los datos de retardo, jitter y prdida de paquetes. La condicin lmite se estableci basndose en los parmetros denidos en la Seccin II, de tal forma que la comunicacin es inviable cuando se supere cualquiera de los lmites de prdidas, jitter o retardo mencionados. En cada una de las estaciones clientes se construy un script para que el ITGSend generara las llamadas que contenan las tramas de VoIP enviadas al equipo central, con los parmetros requeridos tales como cantidad y cdec.
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 nmero de acuerdo con el cuarto byte de la direccin IP tal como aparece a continuacin:
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 conexin 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 dispona de ms clientes inalmbricos para que hubiera ms llamadas se aument a que cada cliente generara dos o ms llamadas, de tal forma que 12 llamadas implican que cada uno de los seis est generando dos y que 18 estn generando tres. El archivo de registro (log) que se obtuvo con cada uno se pas al ITGDec para que lo decodicara y de esta forma conocer los datos de retardo, jitter y prdida de paquetes. El lmite se estableci por superar cualquiera de ellos, pero como se mencion anteriormente fue interesante ver que cuando se sobrepasaba la capacidad, todos estos lmites eran considerablemente rebasados. Se realiz primero con G.711, luego con G.729 y nalmente con G.723.
133
En el equipo central se ejecut la aplicacin Iptraf para establecer ancho de banda utilizado y paquetes por segundo tomando sreenshots que comprobaran la utilizacin 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 cdec. 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 exista un promedio de velocidad relativo entre todos, con el n de descartar problemas de desempeo en alguno de ellos, las velocidades relativamente fueron cercanas, razn por la cual se consider que todos se podan utilizar. B. Evaluacin de la capacidad con asterisk Despus de haber trabajado con el generador de trco, se decidi realizar el laboratorio con un servidor de VoIP generando llamadas reales entre los equipos y poder hacer una comparacin y validacin de resultados respecto al generador de trco D-ITG. Para llevar a cabo esta evaluacin fue necesario instalar la PBX IP Asterisk, realizar la conguracin de los clientes y escribir algunos scripts que permitieran la generacin automtica de llamadas desde los clientes hacia el servidor, la respuesta de las llamadas en el servidor, y la reproduccin automtica de lado y lado de mensajes de voz pregrabados, de modo que se obtuvieran datos totalmente reales en una conversacin de VoIP. Se tuvo el problema que si
se usaban softphones como clientes, se tena la limitacin de tan solo una llamada por cliente incluso en los softphones que manejan llamadas simultneas, pues estos realmente solo manejan una comunicacin al tiempo y las dems llamadas las pone en espera, adems de que cada llamada por softphone no se podra programar, ni ponerle a reproducir un mensaje automticamente. Para solucionar este inconveniente se instal el servidor de VoIP asterisk en todos los clientes, ya que asterisk tambin puede operar como cliente, de modo que todo el trabajo, conguracin y escritura de scripts se hizo para manejar las llamadas en asterisk. Adicionalmente al realizar la evaluacin, se busc tener una vericacin audible al ser humano de la calidad de la voz, que demostrara cmo el aumento en el jitter y retardo realmente afecta la percepcin y la calidad de la comunicacin. 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 ms informacin sobre asterisk y su conguracin se puede visitar la URL www.asterisk.org. A continuacin se explican slo las partes claves de la configuracin, para facilitar la reproduccin del experimento. 1. CONFIGURACIN DEL SERVIDOR 1.1. Seccin de clientes SIP sip. conf En esta seccin se declar el abonado sip que se utiliz para monitorear la calidad de audio a travs de parlantes
134
; Se declara la seccin general; Se declara la seccin de abonado sip con un nombre ; cualquiera, para este caso [softphone1] [softphone1] type=friend context=ciclo ;Permite hacer y recibir llamadas ;Podr llamar a los nmeros que se ;incluyan en el contexto ciclo del ;plan de marcado host=dynamic ;podra iniciar sesin desde cualquier ;equipo secret=telefono1 qualify=yes dtmfmode=rfc2833 relaxdtmf=yes ;La contrasea ;monitorea la conexin y el retardo ;Deteccin de tonos estandar ;Facilita la deteccin de tonos
1.2. Seccin de plan de marcado extensions.conf En esta seccin se declara la lgica y el ujo de la llamada ;Se declara la seccin 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 ;indenidamente exten=101,1,Goto(ciclo,s,1) ;cuando el softphone llama a 101 entra al ciclo
135
1.3. Seccin de clientes IAX iax.conf ;Se declara la seccin general ;Se declara uno por uno los clientes a los que se ;conectar [cliente1] type=friend context=ciclo qualify=yes disallow=all allow=ulaw [cliente2] type=friend context=ciclo qualify=yes ;Puede hacer y recibir llamadas ;Podr llamar a los nmeros que se ;declaren en ese contexto ;Se monitorea la conexin y el retardo ;No permite un cdec diferente a ;g711u host=192.168.1.101 ;Se conectar desde esa IP ;Puede hacer y recibir llamadas ;Podr llamar a los nmeros que se ;declaren en ese contexto ;Se monitorea la conexin ;y el retardo ;No permite un cdec diferente a ;g711u host=192.168.1.100 ;Se conectar desde esa IP
disallow=all allow=ulaw
;Se contina con los dems clientes Para cambiar de cdec se puede modicar el allow por: alaw ulaw g729 g723 gsm ilbc Cdec G.711a Cdec G.711u Cdec G.729 Cdec G.723 Cdec GSM Cdec ilbc
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 cdecs gratuitos para uso acadmico disponibles en la pgina de intel www.intel.com e incluirlos en los mdulos de asterisk. 2. CONFIGURACIN DEL CLIENTE En los clientes solo fue necesario realizar una configuracin en los
Es de anotar que los cdecs g729 y g723 no son libres y en ciertos
136
clientes IAX, pues todas las llamadas se haran manejando este protocolo, Seccin IAX iax.conf
solo se debe declarar el servidor al que irn conectados.
;Se declara la seccin 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 ;conexin 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 conguracin correcta, en la interfaz de lnea de comandos CLI de asterisk, se pueden observar las conexiones de los clientes tal como aparece en la Figura 4.
Figura 4. Estado de conexin en el servidor.
137
3. GENERACIN DE LLAMADAS Una vez los clientes se encuentran conectados con el servidor, es necesario que se inicien las llamadas. El script se detalla a continuacin.
Asterisk chequea constantemente un directorio en donde se pueden colocar scripts de llamadas para que l ejecute inmediatamente.
;Script para generar llamadas debe ubicarse en / ;var/spool/asterisk/outgoing, tan pronto se copie el script ;en este directorio, se har la ejecucin. ;Archivo sample.call Channel: IAX2/ap MaxRetries: 2 RetryTime: 60 WaitTime: 30 Context: ciclo Extension: s Priority: 1 ; llama al servidor ap ; hasta dos reintentos ;Reintento cada 60 segundos ;Esperara 30 segundos la respuesta ;La llamada llegar al contexto ciclo, ;extension s y ;prioridad 1 Para generar las llamadas se puede hacer un script que copie el archivo anterior las veces necesarias con diferente nombre cada vez, asi:
Si se observa en las configuraciones anteriores, este script lleva la llamada a la ejecucin del archivo pregrabado, que se ejecuta tanto en el servidor como en los clientes. #!/bin/bash
#mpstat -P 0 1 1 adiciona un retardo de un segundo entre #llamada y llamada generada adems 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 tambin que este script debe ejecutarse en cada cliente, pues es cada cliente quien genera la(s)
llamada(s), en cuanto al servidor tambin es importante aclarar que para generar una llamada con diferentes caractersticas como cambio de cdec, debe modicarse el archivo iax.conf tanto en los clientes como en el servidor cambiando allow=ulaw por otro cdec.
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. Generacin de llamadas desde un cliente.
VI. RESULTADOS A. Resultados obtenidos del trabajo con ITG En primer lugar se tom el dato de utilizacin de ancho de banda y canti-
dad de paquetes por segundo de cada cdec por medio de IPtraf. Los resultados coincidieron exactamente con los que muestra la Tabla II, como se puede vericar en las Figuras 7-9.
139
Figura 7. Datos de Iptraf de una llamada con G.711.
Luego de esto se inici la generacin 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.
Luego se procedi a decodicar los archivos de registro (Logs) obtenidos con cada uno de los cdecs: G.711, G.729 y G.723.
140
Para esto se utiliza el Decocador del ITG, la sintaxis es: ./ITGDec [log] En este caso los logs siguieron la siguiente convencin de nombrado: Log-[cantidad de llamadas]-[cdec]. log. Por ejemplo, para el caso de la decodificacin de 11 llamadas realizadas con G.711 este comando quedara: ./ITGDec Log-11-G711.log Los siguientes pares de guras muestran los resultados obtenidos sobre la base de los cuales se estableci el lmite de capacidad de acuerdo con cada cdec. En la gura que aparece primero las condiciones de retardo jitter y prdida de paquetes no superan los lmites para una ptima comunicacin de VoIP pero en la segunda (que es cuando se aumenta una llamada ms) los supera considerablemente. En la parte inferior
de cada una aparece el comando utilizado para la decodicacin 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 razn de que siempre que se aumentaba una sola llamada, los lmites de retardo (retardo) y prdida 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 prdida 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 cdecs, obteniendo resultados similares a los obtenidos con ITG:
141
Figura 10. Decodicacin 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 tambin 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 nmero de llamadas, tal como se observa en las Figuras 16 y 17; adems, 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 evaluacin 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 comunicacin uida.
1. RESULTADOS CON G.711 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 Cdec de 10 llamadas en curso sobre el servidor de VoIP.
Como slo se cont con seis clientes, a partir de la sptima llamada fue necesario generar ms llamadas por cada cliente. Para el cdec G711 se tuvo un comportamiento adecuado y se obtuvieron buenos resultados hasta la llamada
nmero 12. Con la llamada nmero trece el retardo y el jitter aumentaron drsticamente y se pudo percibir una degradacin en la calidad. En la Figura 19 se observa la degradacin del jitter a medida que se aumentan las llamadas.
Figura 19. Observacin del Jitter a medida que las llamadas aumentan.
En la Figura 20 se observa la degradacin 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 (estn dentro de los lmites) hasta la llamada 12, pero en el momento en que se realiza la llamada siguiente el retardo aumenta dramticamente a pesar de que el jitter se
145
Figura 20. Observacin del Retardo a medida que las llamadas aumentan. Tabla IV. Resumen de resultados G711. No Llamadas Jitter Delay No Llamadas Jitter Delay 1 1 3 9 4 4,5 2 1,5 2 10 3,7 4,5 3 1,33 2,67 11 4 5,64 4 2,5 3 12 6,75 9,17 5 2,6 3,8 13 6,62 2130 6 2,5 4,67 14 9,36 2751 7 2,71 4,57 15 14,26 2734 8 4,5 5,13 16 14,87 4588
mantiene an apto para una comunicacin adecuada de voz. Para vericar lo anterior, se puso un softphone con parlantes para apreciar la calidad de la comunicacin y se obtuvieron las siguientes anotaciones: Llamada 11: El sonido es de excelente calidad, no se aprecian entrecortes o chasquidos. Llamada 12: El sonido contina siendo excelente, aunque se alcanzan a apreciar algunos pequeos chasquidos muy espordicos, pero nada que degrade la comunicacin. Llamada 13: La calidad se degrad apreciablemente, se aprecian fcilmente chasquidos y algunos entrecortes, toma mucho tiempo el
establecimiento de una nueva conversacin. Llamada 14: Se hace ms evidente la prdida de calidad, se aprecian muchos entrecortes y se diculta el inicio de nuevas sesiones. Llamada 15: No se entienden muchas partes de la conversacin, se entrecorta constantemente y por largos periodos. Llamada 16: Despus de muchos intentos, se logra establecer la comunicacin, pero no es entendible. Llamada 17: Cada vez que se intent iniciar la llamada 17, se cay la llamada, y tumb ms de la mitad de las que se estaban cursando.
146
Es importante anotar que se repiti el experimento para vericar que la informacin obtenida es correcta, y que se obtuvieron los mismos datos en las dos ocasiones.
El proceso para obtener los resultados con los cdecs G.729 y G.723, fue el mismo que se sigui para G.711. Los resultados obtenidos se muestran en las grcas de las Figuras 21 y 22:
Figura 21. Observacin del Jitter a medida que las llamadas aumentan con G729.
Figura 22. Observacin del Retardo a medida que las llamadas aumentan con G729.
2. RESULTADOS CON G.729 Como se observa en las grcas, 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 comunicacin. A partir de este punto y hasta la llamada 17 se degrada ms y ms 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 mayora de las llamadas que se estn 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 slo 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 cdec G.723, se tiene un comportamiento similar a los dos anteriores casos, pero con una capacidad de llamadas bastante superior.
Figura 23. Observacin del Jitter a medida que las llamadas aumentan con G723.
Figura 24. Observacin del Retardo a medida que las llamadas aumentan con G723.
Con el cdec G723 se logran cursar 21 llamadas antes que empiecen a presentarse prdidas considerables en la calidad. A partir de la llamada
22 se empieza a degradar la calidad y en llamada 24 la comunicacin es bastante difcil; al tratar de establecer la llamada 25 se desconectan muchas
148
de las llamadas que se estuvieran cursando. Se deben observar dos comportamientos recurrentes en las pruebas hechas con los tres cdecs: 1. El aumento de jitter se hace de un modo casi lineal, tiene una pendiente pequea y no sobrepasa los lmites para una buena conversacin de voz, el retardo es muy pequeo y cercano a cero hasta cierto punto, pero despus de ste tiene un cambio abrupto que pasa de alrededor de 5 ms a varios segundos. 2. Cuando se trat de generar nuevas llamadas en el momento en que se contaba con un retardo excesivo, se ocasion la prdida de conexin. VII. CONCLUSIONES El desarrollo de este estudio de capacidad por mtodos experimentales arroja una serie de aspectos importantes para el trabajo con VoIP en redes inalmbricas que se anotan a continuacin: Las comunicaciones de VoIP en las redes inalmbricas tienen lmites abruptos, esto quiere decir que luego que se supera el lmite de capacidad, una comunicacin siguiente queda sin ninguna probabilidad de ser soportada por razn del retardo y prdida de paquetes tan signicativo que se presenta. Por este motivo es necesario establecer nuevos criterios de diseo con VoIP pues los tradicionalmente utilizados para Ethernet cableada no son convenientes. Los parmetros que ms incidencia tienen en el lmite del nmero de llamadas concurrentes en un siste-
ma de VoWLAN son el retardo y la prdida de paquetes que tiene un cambio abrupto cuando se supera una determinada cantidad de llamadas. En cambio el jitter presenta un comportamiento lineal, con pequea pendiente, que se mantiene fcilmente dentro de los lmites permitidos para una buena conversacin. Es muy importante en un sistema de VoWLAN poner un lmite en el nmero de llamadas que puedan establecerse por cada punto de acceso, pues si se supera este lmite se ocasionar no slo una prdida de calidad, sino la desconexin de las llamadas que se estn cursando a travs del punto de acceso. Debe tenerse en cuenta tambin el consumo de mquina que puede tenerse con la codicacin de voz al usar G.729 o G.723, ya que en dispositivos mviles con poca capacidad de procesamiento puede no ser posible usar un cdec diferente de G.711. El deterioro en la calidad cuando el retardo aumenta abruptamente es fcilmente comprobable. Cada vez que se superaba el umbral de llamadas encontrado para cada cdec, se escuchaba una notoria disminucin de la calidad en la comunicacin a travs de los parlantes conectados al softphone, en donde se escuchaban entrecortes y mltiples ruidos. Mientras en las redes cableadas el tipo de cdec que se utiliza determina casi linealmente la capacidad (cantidad de llamadas) que puede tener el sistema, en las redes inalmbricas aunque un cdec con menor consumo de ancho de banda permite un mayor nmero de llamadas, este efecto no es tan signicativo como se not en los
149
experimentos donde se comprob que lo ms crtico vena 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 validacin implcita del laboratorio realizado. La nica diferencia se obtuvo con el cdec G.723, lo cual fue consecuencia directa de tener caractersticas 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 desempeo 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 tena un elemento central que controlara el acceso. Sumando el conocimiento generado por estos experimentos con el conocimiento previo de los autores sobre las redes inalmbricas, se plantea la siguiente discusin: la congestin en este tipo de redes se ve que es proporcional al nmero de paquetes por segundo ms que por el ancho de banda que consumen los paquetes (entre otras los paquetes de voz son pequeos pero requieren ser despachados inmediatamente). Esto indica que sera interesante estudiar el impacto de diferentes tamaos 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 tambin a la
mitad) lo que sin duda reducir la congestin y se podra esperar mejor desempeo de la red. Sin embargo, el inconveniente es que el retardo por procesamiento aumentara y la sensibilidad a la prdida de paquetes tambin, luego vendran algunas preguntas inmediatas para resolver en trabajos futuros: La disminucin de paquetes perdidos debido al mejor desempeo de la red compensar el aumento en la sensibilidad a los paquetes que se puedan perder? Qu es ms conveniente optimizar en la prctica? AGRADECIMIENTOS Los autores agradecen al Departamento de Telecomunicaciones de la Universidad del Cauca por la colaboracin para el acceso a la infraestructura. BIBLIOGRAFA [1] IEEE Std 802.11b, IEEE Standard forWireless LAN Medium Access Control (MAC) and Physical Layer Specications: Higherspeed physical layer extension in the 2.4GHz band, 1999. [2] Wi-Fi.org. Alianza Wi-Fi. Disponible en http://www.wi-.org [3] Agredo G, Lpez G. Redes Inalmbricas 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.
150
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 Trafc 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 Mndez. Docente de la facultad de Ingeniera Electrnica y de Telecomunicaciones de la Universidad del Cauca. Estudiante de la maestra en Electrnica y Telecomunicaciones de la Universidad del Cauca. Investigador del Grupo de I+D en Nuevas Tecnologas en Telecomunicaciones (GNTT). reas de inters: Comunicaciones Inalmbricas, Voz sobre IP, Servicios de Internet. e-mail: gagredo@unicauca.edu.co Jaime Andrs Gaviria Molano. Ingeniero Jefe de Servidores y Servicios de Internet de la Universidad del Cauca. Estudiante de la maestra en Electrnica y Telecomunicaciones de la Universidad del Cauca. reas de inters: Voz sobre IP, Reconocimiento de Voz. e-mail: jgaviria@unicauca.edu.co.
151
152

Telematica

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Telematica

Uploaded by

Copyright:

Available Formats

Edicin Monogrfica i2 ComM 2006

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

Revista de la facultad de ingeniera

Jos Hernando Bahamn

Hctor Ochoa Daz

Lelio Fernndez Druetta

COMIT EDITORIAL DE LA REVISTA Guillermo Londoo Acosta

Juan Manuel Madrid Molina

lvaro Pachn de la Cruz

Andrs Navarro Cadavid

Luis Eduardo Mnera

David Fernndez McCaan

Andrs Navarro Newball

SISTEMAS & TELEMTICA

GUA PARA LOS AUTORES DE ARTCULOS

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

GUA PARA LAS RESEAS BIBLIOGRFICAS

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

Modelos de canal inalmbricos y su aplicacin al diseo de redes WiMAX.

Fecha de recepcin: 30-05-06

Fecha de seleccin: 30-10-06

Fecha de aceptacin: 30-08-06

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

Manifestaciones del desvanecimiento en el canal

Desvanecimiento de pequea escala debido a pequeos cambios en la posicin

Variacin temporal del canal

Descripcin en el dominio del tiempo (retardo)

Descripcin en el dominio de la frecuencia

Descripcin en el dominio del tiempo

Descripcin en el dominio de la frecuencia (corrimiento Doppler)

Desvanecimiento selectivo en frecuencia

Desvanecimiento selectivo en frecuencia

Figura 2. Diferentes tipos de desvanecimiento [7].

SISTEMAS & TELEMTICA

Figura 3. Descripcin de la tabla de clasicacin de modelos de canal.

SISTEMAS & TELEMTICA

Figura 4. Ambiente de simulacin del JavaDES [11].

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

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

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

6 MMDS: Multichannel Multipoint Distribution System.

SISTEMAS & TELEMTICA

Figura 6. Comparacin de modelos predictivos aplicables a diseo de rdes WiMAX [12].

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA

SISTEMAS & TELEMTICA