IMPLEMENTACÍON DE UN PROTOTIPO DE RED WMAN UTILIZANDO TOPOLOGÍA MESH PARA EL INTERCAMBIO DE CONTENIDO E

INFORMACIÓN CON EL PROTOCOLO NTK

HOLLMAN EDUARDO ENCISO ROCHA RICARDO LANZIANO MENESES

CARLOS ÁLVARO RICO POVEDA

UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS BOGOTÁ DC

2008

IMPLEMENTACÍON DE UN PROTOTIPO DE RED WMAN UTILIZANDO TOPOLOGÍA MESH PARA EL INTERCAMBIO DE CONTENIDO E

INFORMACIÓN CON EL PROTOCOLO NTK

HOLLMAN EDUARDO ENCISO ROCHA RICARDO LANZIANO MENESES

CARLOS ÁLVARO RICO POVEDA

Trabajo de tesis

Director Ingeniero Carlos Andrés Lozano Garzón

UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS BOGOTÁ DC

2008

iii

AGRADECIMIENTOS Desde el inicio del proyecto, se han vinculado de manera directa e indirecta una gran cantidad de personas las cuales han brindado su apoyo al proyecto de diferentes maneras. A todas esas personas, les agradecemos enormemente su colaboración para la realización de este proyecto. Queremos agradecer principalmente la Universidad de San Buenaventura por su apoyo y facilidad con los respectivos tutores de área y laboratorios capacitados para poder realizar algunas de las pruebas que el proyecto necesito. Al profesor Gustavo Quiroga, que en su momento nos brindó su apoyo, tiempo, dedicación y conocimientos referentes al tema de comunicación inalámbrica y teoría general de antenas. A la profesora Claudia Rodríguez, por las tutorías y gran apoyo en las clases de anteproyecto de grado. Su colaboración referente a los temas legislativos y regulatorios con referente a las telecomunicaciones nos brindaron un enfoque más claro con lo referente al ámbito legal Colombiano. Al ingeniero Carlos Lozano, por sus tutorías y acompañamientos a lo largo de este ultimo semestre de proyecto de grado. Su colaboración y dedicación fueron pilar de apoyo a lo largo del desarrollo ingenieril del proyecto. Un saludo especial a Ferney en los laboratorios del hangar de la Universidad, por su apoyo, conocimiento y acompañamiento en la construcción de los soportes para las antenas. A Mariana en el laboratorio de redes inalámbricas por su acompañamiento y tiempo que nos dedicó explicándonos y ayudando con las pruebas de equipos inalámbricos implementados junto con la utilización de los diferentes elementos del laboratorio. A todos los integrantes de la comunidad CogitoWireless que han venido trabajando con nosotros desde los inicios de este proyecto y que han colaborado

iv

en trabajos de montaje y adecuación de nodos, junto con la difícil labor de evangelización y concientización por parte de las diferentes comunidades de software libre existentes en Colombia. A la comunidad de Torre Campo por su acogida y fácil acceso a los interiores de los conjuntos facilitándonos trabajo de campo, igualmente a todos aquellos que nos acompañaron y nos facilitaron acceso a sus equipos de computo para la realización de pruebas y usuarios de las mismas. Deseamos agradecer enormemente a Mariana Barreto, por su apoyo incondicional y su constante soporte durante los momentos más cruciales del desarrollo de este proyecto. Queremos expresar lo importante que fue su compañía durante la realización del mismo, y esperamos contar con su participación en proyectos futuros. El equipo de trabajo desea agradecer a Tania Carolina Londoño, por su constante apoyo moral y su ayuda incondicional con todos los pequeños y grandes detalles que alguna vez necesitamos.

v

CONTENIDO

Pág.

INTRODUCCIÓN 11 1. PLANTEAMIENTO DEL PROBLEMA 12 1.1 ANTECEDENTES 12 1.2 DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA 17 1.3 JUSTIFICACIÓN 18 1.4 OBJETIVOS DE LA INVESTIGACIÓN 19 1.4.1. Objetivo general 19 1.4.2. Objetivos específicos 20 1.5 ALCANCES Y LIMITACIONES 20 2. MARCO DE REFERENCIA 21 2.1 MARCO TEÓRICO - CONCEPTUAL 21 2.1.1. WiFi. 22 2.1.2. 802.11. 22 2.1.3. Topología de la red. 23 2.1.4. DTN (Delay Tolerant Networking). 24 2.1.5. Ad-Hoc. 24 2.1.6. Protocolo de enrutamiento. 25 2.1.7. GNU/Linux. 25 2.1.8. Sistemas embebidos. 26 2.1.9. Creative commons. 27 2.1.10. Potencia de Transmisión. 27 2.1.11. Mínimo nivel de señal Recibida. 27 2.1.12. Pérdida en los cables. 27 2.1.13. Pérdida en el espacio libre. 28 2.1.14. Servidor Icecast. 28 2.1.15. Servidor Web. 29 2.1.16. Servidor FTP. 30 2.1.17. Servidor IRC. 30 2.1.18. Extreme Programming. 31 2.1.19. Redes Mesh. 32 2.1.20. NTK (Netsukuku) . 33 2.1.21. WMAN. 34 2.2 MARCO LEGAL O NORMATIVO 35 3. METODOLOGÍA 38 3.1 ENFOQUE DE LA INVESTIGACIóN 38 3.2 LÍNEA DE INVESTIGACIÓN DE USB / SUB-LÍNEA DE FACULTAD / CAMPO

TEMÁTICO DEL PROGRAMA 38 3.3 TÉCNICAS DE RECOLECCIÓN DE INFORMACIÓN 38 3.4 HIPÓTESIS 39

vi

3.5 VARIABLES 39 3.5.1. Variables independientes. 39 3.5.2. Variables dependientes. 40 4. DESARROLLO INGENIERIL 41 4.1 METODOLOGÍAS DE DESARROLLO 41 4.1.1. Fases del Proyecto. 41 4.2 PLANEACIÓN 45 4.2.1. Recolección de Información. 45 4.3 DISEÑO 52 4.3.1. Especificación de los servicios de red a implementar. 52 4.3.2. Selección de hardware de la red. 53 4.3.3. Diseño de la topología de red mesh. 63 4.4 IMPLEMENTACIÓN DE LA ARQUITECTURA DE RED 79 4.4.1. Adecuación de equipos. 79 4.4.2. Montaje de los equipos de comunicación. 97 4.5. VALIDACIÓN DE LA RED MESH 107 4.5.1 Rendimiento de los nodos. 108 4.5.2 Pruebas de disponibilidad de servicio. 110 4.5.3 Pruebas de Cambios de Estados. 111 4.5.4 Pruebas de Envio y Recibo de Paquetes. 113 4.5.5 Pruebas de Tráfico de Servicios Combinados. 115 4.5.6 Pruebas de Latencia. 117 4.5.7 Pruebas de Entrada y Salida de Bits. 118 4.5.8 Calidad de servicio perceptual. 120 5 CONCLUSIONES 121 6 RECOMENDACIONES 122 BIBLIOGRAFÍA 125 WEBLIOGRAFÍA 127 GLOSARIO 129

vii

LISTA DE FIGURAS

Pág. Figura 1. Servidor Icecast 28 Figura 2 Modelo FTP 30 Figura 3 Resultados de popularidad de la comunidad en países latinoamericanos 42 Figura 4 Recorrido realizado por el barrio la Florida 45 Figura 5 Ciudades con mayor actividad en redes Wi-Fi y Wireless 47 Figura 6 Búsqueda sobre redes inalámbricas en toda Colombia. 48 Figura 7 Popularidad según ciudades principales de Latinoamérica 49 Figura 8 Antena Omnidireccional 54 Figura 9 Patrones de radiación antena Omnidireccional 55 Figura 10. Antena Panel 55 Figura 11 Patrones de radiación antena Panel 56 Figura 12 Pigtail 58 Figura 13 Router WRT54GL 59 Figura 14 Placa puertos seriales del Router Linksys WRT54GL 60 Figura 15 Placa JTAG del Router Linksys Wrt54GL 60 Figura 16 Caja Nema 62 Figura 17 Enlaces puntos de acceso 64 Figura 18 Tipos de topologías 70 Figura 19 Diseño lógico de la red propuesta 70 Figura 20. Ejemplo de bnode. 75 Figura 21 Ejemplo de topología jerárquica de NTK 76 Figura 22 Diagrama de negociación por colisión en NTK 77 Figura 23 Diseño de red final 79 Figura 24 Modelo conceptual del sistema en OpenWRT. 80 Figura 25 Actualización del Firmware en la pestaña Administración 88 Figura 26 Firmware Actualizado 88 Figura 27 Instalación de los nodos de la red 100 Figura 28 Confirmación de directorio de acceso a la wiki 102 Figura 29 Selección de servidor web para instalar dokuwiki 102 Figura 30 Control de acceso dokuwiki 103 Figura 31 Confirmación de purga de la base de datos 103 Figura 32 DokuWiki 104 Figura 33 Enlaces realizados para las pruebas de stress 108 Figura 34 Monitoreo de procesadores 109 Figura 35 Utilización de la CPU después de 16 horas 109 Figura 36 Procesadores después de 2 días 110 Figura 37 Cambios de estados en los paquetes después de 4 horas 111 Figura 38 Cambios de estados en los paquetes después de 16 horas 112

viii

Figura 39 Cambios de estados en los paquetes después de 2 días 113 Figura 40 Paquetes enviados y recibidos por la interfaz Web después de 4 horas 113 Figura 41 Paquetes enviados y recibidos por la interfaz Web después de 16 horas 114 Figura 42 Paquetes enviados y recibidos por la interfaz Web después de 2 días 115 Figura 43 Tráfico de servicios combinados después de 4 horas 115 Figura 44 Tráfico de servicios combinados después de 16 horas 116 Figura 45 Tráfico de servicios combinados después de 2 días 116 Figura 46 Latencia después de 4 horas 117 Figura 47 Latencia después de 16 horas 118 Figura 48 Entrada y salida de bits después de 4 horas 118 Figura 49 Entrada y salida de bits sobre los servicios después de 16 horas 119 Figura 50 Entrada y salida de bits sobre los servicios después de 2 días 119

ix

LISTA DE TABLAS

Pág.

Tabla 1 Canales en 802.11g y su asignación en el espectro 23 Tabla 2 Licencias de servidores Web 29 Tabla 3 Características de servidores Web 29 Tabla 4 Plataformas operativas soportadas 29 Tabla 5 Servidores IRC 31 Tabla 6 Plataformas operativas 31 Tabla 7 Tecnologías servidores IRC 31 Tabla 8 Análisis pasivo del espectro en la zona piloto 46 Tabla 9 Estimador de ancho de banda necesario según servicios 49 Tabla 10 Ancho de banda disponible según el estándar 802.11 51 Tabla 11 Especificaciones eléctricas antena Omnidireccional 54 Tabla 12 Especificaciones mecánicas antena Omnidireccional 54 Tabla 13 Especificaciones eléctricas de la antena panel Hyperlink 56 Tabla 14 Especificaciones mecánicas de la antena panel Hyperlink 56 Tabla 15 Características técnicas del cable LMR 200 58 Tabla 16 Características eléctricas del cable LMR 200 58 Tabla 17 Puertos Seriales del Router Linksys WRT54GL 59 Tabla 18 JTAG del Router Linksys WRT54GL 60 Tabla 19 Especificaciones técnicas del Router Linksys Wrt54GL 61 Tabla 20 Interfaces del Router Linksys Wrt54GL 61 Tabla 21 Puertos del Router Linksys Wrt54GL 62 Tabla 22 Especificaciones mecánicas del Router Linksys Wrt54GL 62 Tabla 23 Distancia entre nodos 64 Tabla 24 Latitud y longitud de cada nodo 64 Tabla 25 Comparativo de las tecnologías de red inalámbricas 72 Tabla 26 Comparativo entre protocolos 74 Tabla 27 Posibles errores en el servidor FTP 86 Tabla 28 Configuración recomendada 87 Tabla 29 Tabla de direcciones IP asignadas por NTK a los nodos 90 Tabla 30 Tabla de direcciones IP asignadas por NTK a los clientes 96

x

LISTA DE ANEXOS

PÁG.

Anexo A. Programa en PHP para leer archivos XML obtenidos en Kismet 132 Anexo B. Ecuación para obtener pérdida en cable LMR 200 133 Anexo C. Encuenta realizada a los usuarios de la red 134 Anexo D. Reglas de configuración de iptables para abrir los puertos que necesita NTK 136 Anexo E. Configuración de sysctl para linux en OpenWRT 137 Anexo F. Archivo de configuración del nombre de maquina 138 Anexo G. Configuración básica de OpenWRT en modo ad-hoc utilizando el driver B43 con MAC802.11 en WRT54GL v1.1 139 Anexo H. Parámetros para compilar e instalar NTK en los nodos 140 Anexo I. Archivo de configuración de variables UCI para NTK 141 Anexo J. Script de inicio y parada del demonio NTK para los nodos 142

- 11 -

INTRODUCCIÓN

La comunicación ha sido siempre un factor determinante en el crecimiento de la información y el conocimiento interdisciplinario en la sociedad. El conocimiento no es una medida estándar, ni mucho menos algo que exista en esta realidad, “es una función de las organizaciones y sistemas sociales”1. Sin embargo, el conocimiento oculto o no difundido, no es siempre un acto en contra de la comunidad; también es producto de la falta de canales de comunicación. El conocimiento crece y se expande gracias a la recepción y envío de información, la capacidad de recibir mensajes y poder reorganizarlos de manera que modifique o aumente la información del receptor. Sin embargo, a medida que crece el conocimiento, el individuo se estanca por su limitado acceso a la información y no logra crecer al mismo ritmo, por lo cual se dice que la brecha digital va aumentando. Por los motivos anteriores, se puede ver la necesidad de construir una plataforma para la creación de una verdadera red comunitaria (WMAN), donde los proyectos educativos, culturales, políticos y sociales tengan acogida y se puedan difundir de manera libre por la red, sin restricciones de ningún tipo, pero respetando los derechos de autor. El proyecto cogito pretende ser una plataforma de comunicación comunitaria, expandible (se puede alcanzar hasta 2128 nodos en la red utilizando IPv6) en usuarios, separada de Internet, sin necesidad de backbones comerciales que contribuyan a la reducción de la brecha digital del individuo en el barrio la florida ubicado en la localidad de Engativa en Bogotá, mediante el intercambio de información y contenido libre.

1 BERTOGLIO, Oscar Johansen. Introducción a la teoría general de sistemas. Editorial Limusa, p. 22, 2002

- 12 -

1. PLANTEAMIENTO DEL PROBLEMA

1.1 ANTECEDENTES La invención de la tecnología inalámbrica revolucionó la comunicación cuando surgieron las estaciones de radio. Para el año de 1920, muchos operadores de radio amateur en Estados Unidos instalaban sus propias estaciones de radio para transmitir música y noticias. Estas estaciones podían ser detectadas dentro de una distancia de 30/Km. a 50/Km. y las señales podían ser recogidas con cualquier radio disponible en el mercado, o inclusive ensamblado en casa. Luego surgieron las LAN inalámbricas (WLAN) y su nacimiento se remonta a la publicación en 1979 de los resultados de un experimento realizado por ingenieros de IBM en Suiza. El experimento consistía en utilizar enlaces infrarrojos para crear una red local en una fábrica. Estos resultados, publicados en el volumen 67 de los Proceeding del IEEE, pueden considerarse como el punto de partida en la línea evolutiva de esta tecnología. Las investigaciones siguieron adelante tanto con infrarrojos como con microondas, donde se utilizaba el esquema del spread spectrum (espectro ensanchado), siempre a nivel de laboratorio. En mayo de 1985, y tras cuatro años de estudios, la FCC (Federal Communications Commission), la agencia federal del Gobierno de Estados Unidos encargada de regular y administrar en materia de telecomunicaciones, asignó las bandas IMS2 902-928 MHz, 2,400-2,4835 GHz, 5,725-5,850 GHz a las redes inalámbricas basadas en spread-spectrum. IMS es una banda para uso comercial sin licencia: es decir, el FCC asigna la banda y establece las directrices de utilización, pero no se involucra ni decide sobre quién debe transmitir en esa banda. La asignación de una banda de frecuencias propició una mayor actividad en el seno de la industria: ese respaldo hizo que las WLAN empezaran a dejar ya el laboratorio para iniciar el camino hacia el mercado. Desde 1985 hasta 1990 se siguió trabajando más en la fase de desarrollo, hasta que en mayo de 1991 se publicaron varios trabajos referentes a WLAN operativas que superaban la velocidad de 1 Mbps, el mínimo establecido por el IEEE 802 para que la red sea considerada realmente una LAN

2 Industrial, Scientific and Medical. Es la banda libre de dominio público para aplicaciones industriales, científicas y medicas.

- 13 -

Paralelamente las redes ad-hoc, también conocidas como modo IBBS (Independent Basic Service Set) en la terminología usada en la especificación 802.11, se estaban implementando en todo el mundo. Estas son redes de datos en donde sus enlaces son inalámbricos y sus nodos deben interactuar entre ellos sin necesidad de una autoridad centralizada3. Las redes ad-hoc son redes inalámbricas multi-salto porque todos los nodos están dispuestos a reenviar datos a los nodos vecinos y así la determinación de cuales nodos reenvían datos es hecha dinámicamente basándose en algunas métricas. Esta funcionalidad es diferente a la de las tecnologías viejas de redes en donde algunos nodos designados, usualmente con hardware (routers, hubs, switches) y software especializado (firewalls, filtros Web, etc.), realizan la función de reenvío de datos. Su mínima configuración y rápida instalación, hacen de las redes ad-hoc una solución muy confiable para situaciones de emergencia como desastres naturales o conflictos militares. Las redes mesh inalámbricas usan el espectro como medio de conectividad y su topología es en malla. El término mesh es sinónimo de redes ad-hoc multi-punto4. Este tipo de redes ha tenido tres generaciones de tecnología, cada una incorporando mejoras y permitiendo mayor rango, confiabilidad y eficiencia. En la primera generación de redes mesh inalámbricas (one-radio ad-hoc wireless mesh), una sola radio proporcionó el servicio (conexión a los dispositivos individuales del usuario) y el backhaul (enlaces a través de la mesh a la conexión alámbrica); así, la congestión y la contención inalámbrica ocurrían en cada nodo. Los usuarios pronto descubrieron que solamente uno o dos saltos de radios eran posibles entre las conexiones a la red enlazados con el mundo alámbrico. También se presentaban problemas para el vídeo y los usos de la voz debido a la latencia excesiva y el retraso a través de la red. Para resolver estos problemas de congestión y contención, la segunda generación de redes mesh fue desarrollada colocando dos radios en cada nodo, combinando los servicios de 802.11b/g con un backhaul 802.11a. Aunque esto ofreció un incremento en el desempeño en términos de ancho de banda con respecto a la primera generación, algunos problemas siguieron existiendo. Con una alta demanda de usuarios, contención y congestión seguían siendo las fallas más significativas en los enlaces backhaul. La tercera generación añade múltiples entradas y múltiples salidas (MIMO, Multiple Input Multiple Output) a los nodos para poder aprovechar mejor el

3 I. F. Akyildiz, W. Su, Y. Sankarasubramaniam y E. Caryrci, A survey on sensor networks, IEEE Commun. Mag., vol. 40, no. 8, p. 102-114, Agosto 2002. 4 SEBASTIAN Büttrich, Capacity Building for Community Wireless Connectivity in Africa, APC, http://www.apc.com/wireless/, Traducción por parte de TRICALCAR.

- 14 -

espectro, usando diferentes canales de comunicación entre los nodos más cercanos. Las redes mesh se subdividen en tres arquitecturas de red diferentes: Redes mesh inalámbricas de infraestructura: enrutadores mesh crean una infraestructura para los clientes. Redes mesh inalámbricas de clientes: nodos cliente constituyen la red actual para desempeñar funcionalidades de enrutamiento y configuración. Redes mesh inalámbricas híbridas: clientes mesh desempeñan funciones mesh con otros clientes al igual que acceder a la red a través de enrutadores mesh. Las redes de tipo mesh se han utilizado desde su invención gracias a su capacidad de auto regenerarse. La red puede operar de manera óptima aunque cualquier nodo se desconecte o la conexión sufra de mucha interferencia y como resultado se forma una red sólida y muy confiable excelente para áreas rurales5 y/o metropolitanas donde no hay servicios de conectividad (o son muy costosos de adquirir). Gracias a la portabilidad, economía6 y la autonomía de dichas redes, muchos hobbistas empezaron a diseñar e implementar comunidades de redes inalámbricas utilizando tecnologías inalámbricas LAN aprovechando la ventaja del desarrollo de productos baratos y estandarizados (utilizando protocolos IEEE 802.11a/b/g) para construir clusters de redes enlazadas y comunitarias. La mayoría de proyectos de esta índole empezaron a evolucionar en 1998 con la masificación de productos 802.11 y lentamente se esparcieron a nivel global. Sin embargo, a mediados del 2002 muchos de los proyectos seguían en estado embrionario con grupos pequeños de personas experimentando con la tecnología y enlazándose unos con otros expandiendo la cobertura. A mediados del 2005 las comunidades inalámbricas se volvieron un fenómeno muy popular y muchos proyectos de conectividad fueron surgiendo en diferentes ciudades a nivel mundial. Estas redes por naturaleza tienen una topología distribuida, en vez de la clásica topología jerárquica y esta característica hace de estas redes la mejor alternativa para reemplazar los ya congestionados y vulnerables backbones de la Internet cableada.

5 Wifi over 500km? Impossible? http://wiki.whatthehack.org/index.php/Wifi_over_500_km?_Impossible?, Agosto 30, 2007. 6 Is multi-radio Wi-Fi mesh worthwhile? http://www.muniwireless.com/article/articleview/5768/1/2/, Agosto 30, 2007.

- 15 -

Estos proyectos han sido la evolución del amateur radio, específicamente packet radio en conjunto con el crecimiento de la comunidad del software libre, quien se retroalimenta también del packet radio y comparte su cultura. Redes de este tipo se han venido implementando en Europa desde hace ya algunos años y algunos de esos proyectos han tenido resultados muy satisfactorios.7 En Alemania, la agrupación de usuarios sin ánimo de lucro ''freifunk'' tiene como interés común las comunicaciones informáticas por medios inalámbricos y ha venido trabajando en su infraestructura física y lógica desde hace ya algunos años. También han impulsado el desarrollo de OLSR (Optimized Link State Routing) ya que lo integra un firmware personalizado basado en OpenWRT (distribución de GNU/Linux para dispositivos embebidos). En África, diferentes proyectos para enlazar diferentes poblaciones mediante tecnologías Wireless se han venido desarrollando con la colaboración de los diferentes gobiernos. En la provincia de Mpumalanga (África), se implementan este tipo de redes para enlazar la clínica de la provincia con el fin de descubrir aplicaciones y usos que funcionen para el staff. La clínica es una organización sin ánimo de lucro establecida para proveer atención contra las víctimas del SIDA en el área de Masoyi. CIUEM (Center of Informatics of Eduardo Mondlane Universit) ha establecido dos tele-centros en Maputo, la capital de Mozambique, aunque ahora se ha expandido a ocho tele-centros en todo el país y muchos de ellos ubicados en áreas rurales. Otros tipos de proyectos de redes inalámbricas se desarrollan en Mozambique como es el proyecto Schoolnet Mozambique, el cual intenta interconectar cuatro escuelas con el doctorado provincial de educación en la provincia de Inhambane. El proyecto Meraka Telehealth busca interconectar las clínicas rurales en el sur de África ya que el gobierno no puede proveer la infraestructura necesaria para un sistema de comunicación efectivo. Este proyecto se está desarrollando usando infraestructura de muy bajo costo. RedLibre es otra iniciativa para la construcción de redes inalámbricas comunitarias en España. Trabajan en conjunto con el proyecto guifi.net y tienen alrededor de 2.734 nodos en funcionamiento, 141 nodos en pruebas, 1.109 nodos planeados y 93 nodos en construcción.8 7 Grupo de usuarios de Freifunk, http://www.freifunk.net/ , Octubre, 2007 8 Página oficial de guifi, http://www.guifi.net, Septiembre 28, 2007.

- 16 -

EsLaRed es la fundación Escuela Latinoamericana de Redes es una institución sin fines de lucro dedicada a promover las tecnologías de información en América Latina y el Caribe. Los objetivos de EsLaRed son desarrollar, promover y divulgar en el ámbito de América Latina y el Caribe, actividades de formación de recursos humanos e investigación en las áreas de telecomunicaciones, computación, redes de computadores e informática en general y sus aplicaciones. En Colombia, también existen algunos proyectos de esta índole. Altred es un proyecto en pro de las redes libres en Colombia y se inició en Medellín a mediados de diciembre del 2003. Los fundadores de Altred son las mismas personas que iniciaron el proyecto de MedellinWireless y siguen activos. Otros proyectos similares empezaron a nacer en diferentes ciudades de Colombia como BogotaWireless, IbagueWireless, PopayanWireless, SutatenzaSinCables, Inalámbrica DC, pero muchos de ellos se encuentran inactivos y/o abandonados. Los proyectos más destacados son MedellinWireless y SutatenzaSinCables ya que estos tienen algunos nodos enlazados utilizando OLSR como protocolo de enlace. SutatenzaSinCables hizo sus pruebas de streaming de vídeo recientemente, sin embargo, no tuvieron éxito en la transmisión. Inalámbrica D.C. es otro proyecto de redes comunitarias tipo mesh en la ciudad de Bogotá que tienen algunos nodos enlazados y es liderado por Gabriel Zea (Artista y profesor de las universidades Jorge Tadeo Lozano y Universidad Nacional de Colombia) y Camilo Andrés Lizarazo (Estudiante de Ciencias Computacionales 4-5 Semestre). En la universidad Católica en Bogotá se ha venido trabajando en un proyecto de grado para el diseño e implementación de una red mesh en zonas rurales para la difusión libre de contenido mediante servidores Web u otro tipo de tecnologías libres utilizando OLSR como protocolo de enrutamiento. Actualmente existen pocos proyectos para la construcción de redes WMAN utilizando NTK9. Uno de ellos es Meganetwork, el cual intenta unificar varios protocolos para redes mesh incluyendo NTK en un firmware personalizado basado en OpenWRT. La red está planeada para ser construida en la ciudad de Roma, Italia.

9 Pagina Oficial Netsukuku, http://netsukuku.feaknet.org

- 17 -

1.2 DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA En Colombia y en la mayor parte de Latinoamérica, la brecha digital es un término que hace referencia a las diferencias socioeconómicas entre las comunidades e individuos que tienen o no acceso a Internet y a la información. El término no solamente indica el acceso a Internet, sino también las diferencias de las comunidades al utilizar las diferentes redes de información y la utilización de otras TIC’s (Tecnologías de Información y Comunicación) de forma eficaz. También se utiliza en ocasiones para señalar las diferencias entre aquellos grupos que tienen acceso a contenidos digitales de calidad y aquellos que no. Para cerrar la brecha digital es necesario el uso de un medio de comunicaciones libre, donde el acceso no sea restringido y donde todos los pertenecientes a la red puedan beneficiarse del contenido de los demás participantes con el uso de licencias libres. Sin embargo, el país todavía no ha examinado las diferentes alternativas libres que existen para la comunicación inalámbrica. Una prueba de esto es el otorgamiento de licencias para utilizar la banda 3.5GHz para el uso de WiMAX y su creciente auge por parte de diferentes ISP’s. Se cree que esta solución aunque es viable técnicamente, es descartable del proyecto por su alto costo y especialmente por el licenciamiento de su banda. La tecnología ha avanzado mucho desde que se empezó a regular las telecomunicaciones, en especial el espectro10. Cali es una de las ciudades con más porcentaje de distribución de subscriptores WiMAX ocupando el 34,27% de la población con acceso a Internet en Colombia. Bogotá se encuentra en el penúltimo puesto de la lista con un 2,87% de subscriptores. Esta cifra es muy baja ya que Bogotá tiene el 52% de usuarios de Internet en Colombia11. La mayoría de protocolos para redes ad-hoc no tienen en cuenta muchos factores inherentes a las características innatas de un enlace inalámbrico, de hecho es imposible encontrar un protocolo que pueda cubrir y satisfacer todos los posibles escenarios de un problema12. Un caso particular es el de OLSR. Este protocolo está diseñado para redes de tipo ad-hoc y su funcionamiento es estable. Es utilizado en la mayoría de comunidades

10 “¿Que es el 'Espectro Abierto'?, ”http://www.volweb.cz/horvitz/os-info/whatis-OS-spanish.html, Septiembre 8, 2007. 11 Informe Sectorial de Telecomunicaciones #9, Pagina 13, Agosto 2007. 12 OZAN K., Gianluigi Ferrari. AD-HOC Wireless Networks: A communication-theoretic perspectiva., 1 ed., Wiley, 2006.

- 18 -

wireless. Este protocolo sufre de problemas de escalabilidad ya que nunca se diseñó con los retos que una ciudad ofrece. Siendo así, OLSR ha pasado por una serie de cambios en sus especificaciones y se ha probado que existen componentes que no son eficientes en la práctica (MPR, Hysterese, etc.). Sin embargo, dado el crecimiento constante de las redes comunitarias mesh y gracias al requerimiento inherente de los algoritmos de estado de enlace, de volver a calcular13 toda la gráfica de la topología, los límites de este algoritmo se han convertido en un reto. Volver a calcular toda la gráfica de la topología en una red mesh con 450 nodos tomará bastantes segundos en una pequeña CPU. También existen otros protocolos para implementar en la misma plataforma (OpenWRT) pero se considera que el acercamiento que toma NTK para la filosofía y topología de la red es la más adecuada, porque estructura la red de manera jerárquica utilizando recurso mínimos de CPU y memoria en los enrutadores y ofrece además un auto-control y descentralización de toda la red (Esta incluye manejo de nombre de domino distribuido, auto-reparación de rutas y descubrimiento de nuevos enlaces físicos) Se pretende contribuir al cierre de la brecha digital del individuo en Bogotá creando una red comunitaria de libre acceso y libre contenido, utilizando tecnologías y frecuencias de acceso público. Con esta plataforma de comunicaciones se podrá acercar más a las personas que no tienen recursos para acceder a la información, brindarles un enlace para que estos accedan a ella y ayudarlos a informarse y mantenerse en contacto con los diferentes eventos locales y toda la información que se encuentra en la red. ¿Cómo diseñar e implementar una red comunitaria WMAN utilizando licencias y tecnologías libres? 1.3 JUSTIFICACIÓN Las ciudades y sus instituciones cada vez muestran más interés en proyectos que tengan un impacto social alto y que permitan cerrar cada vez más la brecha digital. Proyectos de tipo E-government ayudan a que esto se logre y es por eso que tienen gran acogida dentro de un sistema, como es la ciudad de Bogotá. El beneficio de una plataforma que permita el intercambio de información y contenido, es de gran interés para muchos campos sociales, relacionado con:

13 Una tarea bastante retadora para las capacidades limitadas de un enrutador embebido. Quantitive analysis of the OLSR-NG project, http://global.freifunk.net/node/16015, Noviembre 2, 2007.

- 19 -

• Actividades académicas (programas educacionales y culturales, desarrollo de nuevas tecnologías, unión de semilleros de investigación.)

• Contenido (estaciones de radio, noticias, eventos culturales, televisión, arte.)

• Información comunitaria (guías de exposiciones, mapas locales.) • Foros de discusión (políticos, sociales, culturales, científicos.)

Todo esto se logra con el beneficio de licencias y software libres. Gracias a esta combinación, se ha visto un gran avance en los campos de la ciencia y la tecnología y muchas personas en el círculo de la academia14 ven estos acercamientos de licenciamiento los más viables para asegurar el futuro de la investigación y el desarrollo. Sin embargo, los canales donde se transmite esta información son muy limitados y no son accesibles a toda la comunidad, e inclusive en algunos casos se tiene que pagar una suma elevada de dinero para poder acceder a la información. La mayoría de nodos en las redes comunitarias inalámbricas son implementados usando enrutadores WiFi cuyos recursos de almacenamiento y capacidad de procesamiento son limitados. Teniendo esto en cuenta, se necesita un protocolo que no consuma muchos recursos a la hora de tomar decisiones y calcular las rutas. Los protocolos de enrutamiento comunes utilizan algoritmos clásicos de grafos, los cuales son capaces de encontrar la mejor ruta para alcanzar un nodo en un determinado grafo, a cambio de muchos ciclos de procesamiento y mucha memoria de los equipos. El proyecto CogitoWireless es la plataforma de comunicación donde la gente podrá contribuir con contenido libre, ayudando al crecimiento de la red y disminuyendo así la brecha digital existente. No requerirá de ningún costo de afiliación y ningún tipo de restricción en cuanto ha contenido; esto es responsabilidad del dueño del nodo. 1.4 OBJETIVOS DE LA INVESTIGACIÓN 1.4.1. Objetivo general Implementar un prototipo funcional de una red WMAN utilizando topología mesh para el intercambio de contenido e información utilizando el protocolo NTK (Netsukuku). 14 ScienceCommons es un movimiento académico y científico que busca promover el uso de licencias libres en la ciencia para ayudar a acelerar el desarrollo tecnológico y científico.

- 20 -

1.4.2. Objetivos específicos • Analizar los requerimientos técnicos y funcionales de los elementos activos y

pasivos necesarios para la red. • Diseñar la infraestructura de comunicación de la red. • Configurar y adecuar los nodos para la interconexión entre los mismos. • Implantar el prototipo de comunicación de la red. • Realizar pruebas del prototipo de red. 1.5 ALCANCES Y LIMITACIONES El proyecto culmina con el montaje del prototipo de red WMAN en una zona de la ciudad de Bogotá, Colombia. Se tendrá en cuenta la posibilidad de realizar el enlace a Internet sin ser este un requerimiento necesario para el prototipo funcional. De igual manera se considera que no debe ser esta una prioridad ya que se busca difundir contenido libre y generar nuevos lugares de discusión e información libres y locales. También existen regulaciones legales con respecto a la prestación de servicio y depende mucho del tipo de contrato que se tenga con un proveedor de un canal de acceso a Internet. El radio de cobertura de la WMAN no se puede estimar ni delimitar ya que a medida que nuevos nodos entren a la red, mayor va a ser su cobertura y su ancho de banda y por la naturaleza de la red los nodos son completamente libres de enlazarse a un nodo vecino. Una red completamente dinámica requeriría de actualizaciones muy frecuentes de las rutas, afectando los requerimientos de estabilidad y escalabilidad de NTK (Netsukuku). Por esa razón se restringe el protocolo al caso donde un nodo no cambie de ubicación física de manera rápida o frecuente. Esta restricción es completamente válida, ya que la ubicación de un nodo instalado en la azotea de un edificio, no cambiará de lugar y los únicos eventos dinámicos son la asociación/desconexión de la red junto con los cambios en la calidad de los enlaces.

- 21 -

2. MARCO DE REFERENCIA 2.1 MARCO TEÓRICO - CONCEPTUAL Existen muchos métodos de conectividad inalámbrica, sin embargo, la mayor parte de la tecnología utilizada para dichos enlaces utiliza partes del espectro electromagnético que requieren de licencia según los diferentes gobiernos (dependiendo el país donde se implemente). Es por esto que la solución debe ser de dominio y uso público, sin importar las diferencias técnicas entre las distintas tecnologías (WiFi vs. WiMAX), ya que la única manera de brindarle a la comunidad contenido libre es construyendo una infraestructura libre. Para lograr la conectividad de los nodos en la red utilizando un medio inalámbrico evitando las colisiones15 dentro de una zona urbana, donde existe mucha interferencia por parte de diferentes fuentes tales como teléfonos inalámbricos, hornos microondas, árboles y edificios, se debe tener en cuenta muchos conceptos antes de cualquier análisis y diseño. Uno de ellos es WiFi, ya que estas certificaciones garantizan una interoperabilidad entre los equipos evaluados, independiente del fabricante. Así como la certificación de interoperabilidad es de vital importancia, otro de los factores fundamentales es la plataforma operativa. La plataforma operativa (SO)16 es la encargada de gestionar el hardware y software de los diferentes nodos de la red. Por los motivos anteriores, se debe elegir una plataforma operativa abierta y libre. Sin embargo, la conectividad física es sólo uno de los factores a tener en cuenta en la construcción de una plataforma de comunicaciones comunitaria, ya que se deben utilizar otros mecanismos para descubrir los nodos y enlazarlos lógicamente y de esto se encarga la topología de la red y el protocolo de enrutamiento. Al final, se debe asegurar que el servicio es de la comunidad y para la comunidad y la única manera de garantizarlo es mediante el uso de licencias y acuerdos libres. Las licencias libres son una serie de cláusulas legales para poder compartir contenido de cualquier tipo (imágenes, videos, sonido, texto, software, etc.) para ser modificado, sin perder los derechos de autor de la obra original y bajo una

15 IEEE Std 802.11g™-2003, Amendment to IEEE Std 802.11TM, 1999 Edition (Reaff 2003) 16 Sistema operativo, de sus siglas en ingles OS “Operating System”

- 22 -

serie de condiciones especificadas por el autor (dependiendo de la licencia que se utilice).

2.1.1. WiFi. WiFi (Wireless Fidelity) es un conjunto de certificaciones17 de hardware basadas en las especificaciones IEEE 802.11. Es una marca de WiFi Alliance y es la entidad comercial que prueba y certifica que los diferentes equipos de hardware son compatibles con los estándares. 2.1.2. 802.11. Es un estándar de protocolo de comunicaciones de la IEEE que define el uso de los dos niveles más bajos de la arquitectura OSI (capas física y de enlace de datos), especificando sus normas de funcionamiento en una WLAN. La familia 802.11 actualmente incluye seis técnicas de transmisión por modulación que utilizan todos los mismos protocolos, estos son especificados en las diferentes enmiendas de los protocolos, i.e: 802.11g usa OFDM (Orthogonal Frequency-Division Multiplexing) como técnica de multicanalización del espectro.

Como conceptos generales se tienen:

Estaciones o nodos: computadores o dispositivos con interfaz inalámbrica Medio: se pueden definir dos, la radiofrecuencia y los infrarrojos. Punto de acceso (AP): tiene las funciones de un puente (conecta dos redes

con niveles de enlace parecido o distinto), y realiza por tanto las conversiones de trama pertinente.

Sistema de distribución: proporcionan movilidad entre AP, para tramas entre distintos puntos de acceso o con los terminales.

Conjunto de servicio básico (BSS) grupo de estaciones que se intercomunican entre ellas. Se define dos tipos: 1) Independientes: cuando las estaciones, se intercomunican directamente. 2) infraestructura: cuando se comunican todas a través de un punto de acceso.

Conjunto de servicio extendido (ESS) es la unión de varios BSS. Área de servicio básico (BSA) es la zona donde se comunican las

estaciones de una misma BSS, se definen dependiendo del medio Movilidad este es un concepto importante en las redes 802.11, ya que lo

que indica es la capacidad de cambiar la ubicación de los terminales, variando la BSS. La transición será correcta si se realiza dentro del mismo ESS en otro caso no se podrá realizar.

Límites de la red los límites de las redes 802.11 son difusos ya que pueden solaparse diferentes BSS.

17 WiFi Alliance website, http://wi-fi.org/, Octubre 11, 2007.

- 23 -

Tabla 1 Canales en 802.11g y su asignación en el espectro18 Canal Frecuencia central (GHz)

1 2,412 GHz 2 2,417 GHz 3 2,422 GHz 4 2,427 GHz 5 2,432 GHz 6 2,437 GHz 7 2,442 GHz 8 2,447 GHz 9 2,452 GHz

10 2,457 GHz 11 2,462 GHz 12 2,467 GHz 13 2,472 GHz 14 2,484 GHz

2.1.3. Topología de la red. La topología de red es la constitución física de los nodos en la red y como se interconectan entre ellos. Para construir la topología es necesario trabajar con protocolos y estándares que reúnan las características necesarias para armar toda la estructura de conectividad física. La topología define las reglas que deben seguir todos los nodos que hagan parte de la red, junto con una serie de casos en los cuales se establece cómo se debe interactuar con los componentes. En una topología de red se deben tener en cuenta los siguientes elementos:

• Hardware • Software • Operabilidad • Escenarios • Interconexión • Compatibilidad • Análisis y diseño

18 AICHELE, Corinna., FLICKENGEN, Rob., FORSTER, Jim. Redes inalámbricas en los países en desarrollo, 2 ed., Limehouse book sprint team, 2007 p. 331.

- 24 -

Existen diferentes tipos de arquitecturas: • Centralizadas

• Estrella • Árbol

• Descentralizadas

• Malla

• Híbridas 2.1.4. DTN (Delay Tolerant Networking). DTN es un paradigma o aproximación a las arquitecturas de redes de computadores que busca solucionar los problemas técnicos en ambientes de conectividad móvil y extremos, que no poseen una conectividad de red constante19. En un esquema DTN, mensajes de longitud variable asíncronos son enrutados de manera store-and-forward (guardar y reenviar) entre los nodos participantes sobre diferentes tecnologías de transporte de red (sea IP u cualquier otro mecanismo). Por estas razones, esta arquitectura funciona como una red overlay20. DTN nació del esfuerzo de investigación realizado para solucionar problemas en enlaces de Internet interplanetarios21, pero se ha ido adecuando para redes móviles terrestres. Actualmente se prefiere el término Distruption-Tolerant Networking, ya que este último aplica en muchos más casos gracias a que la interrupción del servicio puede ocurrir por los límites del alcance de radio del nodo o, fuente de energía o, distribución de nodos o, ruido, etc. 2.1.5. Ad-Hoc. Una red ad-hoc es definida como una red multi-salto donde sus nodos son capaces de interactuar entre sí sin necesidad de alguna autoridad centralizada. Las restricciones implícitas de las redes ad-hoc tales como el mismo nivel de jerarquía de los nodos y su energía finita hacen del diseño de este tipo de redes una tarea bastante complicada. En la literatura se ha prestado mucha atención al campo de las redes ad-hoc desde hace unos años22 gracias a los nuevos escenarios de comunicación tales como las redes de sensores. A la par se ha venido trabajando en el campo de 19 IPN RESEARCH GROUP. Delay-Tolerant Network Architecture: The Evolving Planetary Internet. Agosto 2002. http://www.ipnsig.org/reports/draft-irtf-ipnrg-arch-01.txt 20 BURLEIGH, Scott, HOOKE, Adrian, FALL, Kevin. Vint Cerf. Delay-Tolerant Networking: An Approach to Interplanetary Internet. EEE Communications Magazine, Junio 2003. 21 InterPlanetary Internet website, http://www.ipnsig.org/ 22 C. Schurgers, V. Tsiatsis, S. Ganeriwal y M. Srivastava, Topology management for sensors networks: exploiting latency and density, Lausanne, Suecia, Junio 2002

- 25 -

investigación de nuevos protocolos de enrutamiento para este tipo de redes, apoyándose en la experiencia y conocimiento adquirido de las redes cableadas, donde los enlaces de comunicación entre nodos eran bastante confiables y el enrutamiento podía ser estudiado y diseñado independiente de las características del medio físico.

En las redes ad-hoc inalámbricas se tienen otro tipo de consideraciones los cuales no se han definido por completo en la actualidad, sin embargo, la necesidad de conexión en cualquier lugar bajo cualquier condición ha impulsado el desarrollo y la investigación en estas áreas.

Una de estas consideraciones es la movilidad; sin embargo, esta variable no es actualmente un factor crítico definitivo en el impacto de las redes WiFi, ya que la movilidad voluntaria de un nodo junto con su antena es nula, disminuyendo el número de escenarios a considerar en el diseño de los protocolos de enrutamiento y de enlace de datos.

2.1.6. Protocolo de enrutamiento. Un protocolo de enrutamiento especifica cómo encontrar la mejor ruta entre los nodos, dadas unas métricas y condiciones determinadas. Existen dos tipos de enrutamiento; el estático y el dinámico. El enrutamiento estático es utilizado cuando la tabla del nodo tiene que ser configurada de manera manual, es decir, no aprende por sí mismo la mejor ruta, simplemente reenvía el tráfico al vecino cercano configurado en la tabla de enrutamiento. Este acercamiento es válido en las redes cableadas, donde se asume que los enlaces físicos no son dinámicos y que por la confiabilidad de las transmisiones cableadas, donde no hay preocupaciones por el estado de los enlaces.

El otro acercamiento es el del enrutamiento dinámico, el cual es usado por los nodos para transmitir información a otros nodos para que estos puedan calcular la distancia más corta o más óptima (depende del tipo de protocolo). La gran ventaja del enrutamiento dinámico es que la red es consciente de sus cambios y se adapta a las nuevas condiciones.

2.1.7. GNU/Linux. Existen muchas definiciones de GNU/Linux, sin embargo considerando que esta definición es la más simple, aunque es un poco vieja. Fue extraída de la página de GRULIC (Grupo de Usuarios de Software Libre en Córdoba, http://www.grulic.org.ar). “Es una implementación de libre distribución UNIX para computadores personales (PC), servidores y estaciones de trabajo. Fue desarrollado para el i386 y ahora es el sistema operativo más portable del mundo.

- 26 -

Como sistema operativo, GNU/Linux es muy eficiente y tiene un excelente diseño. Es multitarea, multiusuario, multiplataforma y multiprocesador; en las plataformas Intel corre en modo protegido; protege la memoria para que un programa no pueda hacer caer al resto del sistema; carga sólo las partes de un programa que se usan; comparte la memoria entre programas aumentando la velocidad y disminuyendo el uso de memoria; usa un sistema de memoria virtual por páginas; utiliza toda la memoria libre para cache; permite usar bibliotecas enlazadas tanto estática como dinámicamente; se distribuye con código fuente; usa hasta 64 consolas virtuales; tiene un sistema de archivos avanzado pero puede usar los de los otros sistemas; y soporta redes tanto en TCP/IP como en otros protocolos.” 2.1.8. Sistemas embebidos. Los sistemas embebidos o empotrados son sistemas de uso específico construidos sobre un dispositivo mayor. Generalmente los dispositivos embebidos tienen finalidades muy diferentes a los computadores personales. Las principales características que lo diferencian de los demás sistemas son el precio y el consumo, ya que los dispositivos embebidos se pueden producir en masa, teniendo siempre en cuenta la manera de disminuir costos sin parar la producción de hardware. Estos dispositivos por lo general tienen requerimientos de hardware muy específicos, como un procesador lo suficientemente pequeño y memoria limitada para disminuir costos. Los primeros dispositivos embebidos se desarrollaron en 1980 en los laboratorios de IBM y han venido evolucionando para poder combatir el problema del procesamiento en tiempo real. El corazón principal de un sistema embebido es su microprocesador, que es una implementación en forma de circuito integrado (IC) de la Unidad Central de Proceso CPU de un computador. Frecuentemente se hace referencia a un microprocesador como simplemente “CPU” y la parte de un sistema que contiene al microprocesador se denomina subsistema de CPU. Los microprocesadores varían en consumo de potencia, complejidad y costo. Los hay de unos pocos miles de transistores y con costo inferior a $6.000 pesos (en producción masiva) hasta de más de cinco millones de transistores que cuestan más de $1’700.000 de pesos. Estos sistemas tienen varias ventajas sobre las soluciones industriales tradicionales entre las más representativas se encuentran: • Reducción en el precio de los componentes hardware y software debido a la

gran cantidad de PC’s en el mundo. • Al utilizar dichos sistemas operativos se pueden encontrar fácilmente

herramientas de desarrollo software potentes así como numerosos programadores que las dominan, dada la extensión mundial de las aplicaciones para PC’s compatibles.

- 27 -

2.1.9. Creative commons. Es una organización no gubernamental, sin ánimo de lucro, que fue fundada y actualmente es presidida por Lawrence Lessig (Profesor de derecho de la Universidad de Standford, especialista en ciberderechos). Esta organización desarrolla planes para ayudar a reducir las barreras legales de la creatividad por medio de nueva legislación y de las nuevas tecnologías. Creative Commons está inspirada en la licencia GPL (General Public License) de la Free Software Foundation (Sin embargo no es un tipo de licenciamiento de software libre). La idea principal es posibilitar un modelo legal y ayudado de herramientas para facilitar la distribución y uso de contenidos para el dominio público. Ofrece una serie de licencias, cada una con diferentes configuraciones o principios como el derecho del autor original, a dar libertad para citar su obra, reproducirla, crear obras derivadas, ofrecerlo públicamente y con diferentes restricciones como no permitir el uso comercial o respetar la autoría original.

Una de las licencias ofrecidas por Creative Commons es la licencia que lleva por nombre "Developing Nations" (Naciones en Desarrollo). Esta licencia permite que los derechos de autor y regalías por las obras, se cobren solo en los países desarrollados del primer mundo, mientras que las mismas se ofrecen de forma abierta en los países en vías de desarrollo.

Las licencias han sido traducidas al castellano, portugués y catalán a través del proyecto Creative Commons International. Existen varios países que están involucrados en el proceso: Brasil, España, Chile, Argentina, México, Perú y Colombia, que ya tienen las licencias traducidas y en funcionamiento. Entre tanto, Venezuela y Puerto Rico (entre otros) se encuentran en proceso de traducción e implementación de las mismas. 2.1.10. Potencia de Transmisión. Se expresa en mili-vatios o en dBm. La potencia de transmisión tiene rango de 30mW a 200mW o más. La potencia TX a menudo depende de la tasa de transmisión23. 2.1.11. Mínimo nivel de señal Recibida. En otras palabras es la sensibilidad del dispositivo receptor es siempre expresado como dBm negativos y es el nivel mas bajo de señal que la red inalámbrica puede distinguir24. 2.1.12. Pérdida en los cables. Parte de la energía de la señal se pierde en los cables, conectores y otros dispositivos, la perdida depende del tipo de cable

23 AICHELE, Corinna., FLICKENGEN, Rob., FORSTER, Jim. Redes inalámbricas en los países en desarrollo, 2 ed., Limehouse book sprint team, 2007. p. 55 24 Ibid., p. 56

- 28 -

utilizado y de su longitud. La perdida de señal para cables coaxiales lmr200 que son los que se utilizaron es de 2 a 3 dB25. 2.1.13. Pérdida en el espacio libre. Cuanto más lejanos los radios más pequeña será la señal recibida por el otro radio, este tipo de perdida se da ya que la energía de la señal se expande en función de la distancia del transmisor26. 2.1.14. Servidor Icecast. Es un sistema de difusión de audio en Internet basado en la tecnología de flujo MPEG. Permite enviar sonido a todos los oyentes que soporten este formato universal. El servidor Icecast en un servidor de archivos de medios que soporta los formatos de compresión de audio Ogg Vorbis y MP3. Icecast puede ser usado para crear una estación de radio o televisión por Internet. Es muy versátil en cuanto a su capacidad para adicionar soporte a nuevos formatos, también soporta estándares abiertos de comunicación e interacción; Icecast es también multiplataforma, la versión 2.3 soporta plataformas UNIX: Linux, FreeBSD, OpenBSD y Solaris. Icecast es distribuido bajo licencia GNU GPL, se puede usar sin restricciones mientras se respeten los términos y condiciones de licencia27. Figura 1. Servidor Icecast

Fuente: http://www.apertus.es/productos/icecast.html Gracias a este servicio se tendrá disponibilidad de una cantidad limitada de usuarios, gracias a ello se podrían producir cuellos de botella debido a el ancho de banda. Para solucionar esto se cuenta con diferentes soluciones: • Reducción de la calidad de emisión: Icecast permite variar la calidad de

25 Ibid., p. 56 26 Ibid., p. 56 27 http: //www.icecast.org, Abril 2008

- 29 -

transmisión en la que se emite la señal tanto del audio como la del vídeo. Gracias a la reducción de la calidad de emisión se podrá aumentar la cantidad de oyentes, esto sucede porque se reduce el ancho de banda consumido en el canal por cada oyente.

• Límite en el número de oyentes: Es posible configurar en el servidor Icecast la cantidad máxima de clientes asociados a la emisora, de esta manera se podrá garantizar la calidad del servicio a costo de un número limitado de clientes.

2.1.15. Servidor Web. Es un programa que implementa el protocolo HTTP (hypertext transfer protocol). Este programa se ejecuta continuamente en un computador, manteniéndose a la espera de peticiones por parte de un cliente (un navegador de Internet) y que responde a estas peticiones adecuadamente, mediante una página Web que se exhibirá en el navegador o mostrando el respectivo mensaje si se detectó algún error28. Tabla 2 Licencias de servidores Web

Servidor Licencia AOLServer AOLserver Public License Apache HTTP Server Licencia Apache Cherokee HTTP Server GPL

Tabla 3 Características de servidores Web

Servidor Acceso básico

de autenticación

Recopilación de acceso de

autenticación Https CGI

AOL Server SI NO SI SI

Apache HTTP Server

SI SI SI SI

Cherokee HTTP Server

SI SI SI SI

Tabla 4 Plataformas operativas soportadas

Servidor Windows Mac OS X Linux BSD Solaris AOLServer SI SI SI SI SI Apache http SI SI SI SI SI Cherokee SI SI SI SI SI

28 http://es.wikipedia.org/wiki/Servidor_web, Abril , 2008

- 30 -

2.1.16. Servidor FTP. Es un protocolo de transferencia de archivos entre sistemas conectados a una red TCP basado en la arquitectura cliente-servidor, de manera que desde un equipo cliente se puede conectar a un servidor para descargar archivos desde él o para enviar archivos independientemente del sistema operativo utilizado en cada equipo.29

Figura 2 Modelo FTP

Fuente: http://upload.wikimedia.org/wikipedia/commons/c/c5/Modelo_ftp.jpg Las aplicaciones más comunes de los servidores FTP suelen ser el alojamiento Web, en el que sus clientes utilizan el servicio para subir sus páginas Web y sus archivos correspondientes; o como servidor de backup (copia de seguridad) de los archivos importantes que pueda tener una empresa. 2.1.17. Servidor IRC. Es un protocolo de comunicación en tiempo real basado en texto, que permite debates en grupo o entre dos personas y que está clasificado dentro de la mensajería instantánea. Las conversaciones se desarrollan en los canales de IRC, designados por nombres que habitualmente comienzan con el carácter #. Los usuarios del IRC utilizan una aplicación cliente para conectarse con un servidor, en el que funciona una aplicación IRCd (IRC Daemon) el cual es el servidor de IRC, que gestiona los canales y las conversaciones. Un cliente IRC es una aplicación informática programada para acceder a redes de comunicación en tiempo real mediante el protocolo IRC. El IRC es popularmente utilizado para hablar y reunir grupos de gente con los mismos gustos, para ello cualquier persona puede iniciar el canal específico 29 http://es.wikipedia.org/wiki/Ftp Abril , 2008

- 31 -

además es gratis, es por estas razones que se eligió IRC para la comunicación en la red.30 Tabla 5 Servidores IRC

Servidor IRC Lenguaje de programación

Primera Publicación Licencia

Bahamut C 1999 GPL IRCD-Hybrid C 2002 GPL Ircu C 1991 GPL

Tabla 6 Plataformas operativas

Servidor IRC Windows Mac OS X Lunix BSD SolarisBahamut NO SI SI SI SI IRCD-Hybrid SI SI SI SI SI Ircu NO SI SI SI SI

Tabla 7 Tecnologías servidores IRC Servidor

IRC Modularidad Remoto Incluido IPv6 Cliente

SSL SSL

Linking ZIP

Linking Bahamut NO NO NO NO NO SI IRCD-Hybrid

SI SI SI SI SI SI

Ircu NO NO SI NO NO NO

2.1.18. Extreme Programming. o Programación extrema es un enfoque de la ingeniería de software. La programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Se puede adaptar a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos. Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida.

30 http://es.wikipedia.org/wiki/Irc Abril , 2008

- 32 -

Las características fundamentales del método son:

• Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras. • Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,

incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación.

• Programación en parejas: se recomienda que las tareas de desarrollo se

lleven a cabo por dos personas en un mismo puesto, para una mayor calidad del código escrito, de esta manera, el código es revisado y discutido mientras se escribe.

• Frecuente integración del equipo de programación con el cliente o

usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.

• Corrección de todos los errores antes de añadir nueva funcionalidad.

Hacer entregas frecuentes.

• Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.

• Propiedad del código compartida: en vez de dividir la responsabilidad

en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.

• Simplicidad en el código: es la mejor manera de que las cosas

funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

2.1.19. Redes Mesh. Es una red de comunicaciones hecha con nodos de radio organizados en una topología malla. El área de cobertura de los nodos de radio que trabaja como una red sencilla es llamada algunas veces una nube mesh. El acceso a esta nube mesh depende del radio de trabajo en armonía entre los nodos para crear una red. Cuando un nodo no puede operar mas, el resto de

- 33 -

nodos pueden seguir comunicándose entre ellos, directamente o a través de uno o mas nodos intermediarios.31

2.1.20. NTK (Netsukuku) . Es una red punto a punto, o red mallada, construida utilizando su propio protocolo de enrutamiento dinámico. Existen otro tipo de protocolos de enrutamiento dinámico y topologías de red, sin embargo, ninguna de estas es capaz de organizar y mantener un número de redes de tamaños significativos. Los protocolos de enrutamiento comunes como OSPF, RIP y BGP utilizan algoritmos clásicos diseñados para encontrar la mejor ruta para alcanzar a un nodo en una imagen de red dada. Estos protocolos requieren de un consumo masivo de recursos computacionales para poder funcionar de manera optima en una red de la misma escala que la Internet, y es por esta razón que deben ser operados en maquinas especiales dedicadas. El protocolo de Netsukuku estructura la red en diferentes capas de jerarquías compactadas. El algoritmo de QSPN, diseñado para esta situación en particular, es usado para determinar las rutas. Ya que la topología se caracteriza por un alto grado de similaridad, solo un patrón básico debe ser almacenado. Este nivel de compresión garantiza la habilidad de almacenar la red entera en un mapa de unos cuantos kilobytes (dependiendo del número de niveles, que son a su ves determinados por la versión IP a utilizar) Por otro lado, el algoritmo de QSPN debe ser ejecutado por la misma red, al contrario de los acercamientos clásicos en donde solo las maquinas especializadas y dedicadas podían ofrecer la función de enrutamiento hacia las demás redes. La meta principal de Netsukuku es ser una red mesh escalable, completamente distribuida y descentralizada, en donde sus participantes actúan de manera anónima y autónoma. Este protocolo corre en cada uno de los nodos que hacen parte de la red, utilizando recursos mínimos de CPU y memoria gracias a las particularidades de su topología jerárquica, haciendo posible la adecuación de maquinas con muy bajos recursos (enrutadores inalámbricos, dispositivos embebidos) para así construir una red global, anónima y no controlada, separada de la Internet sin el soporte de ningún prestador de servicios de telecomunicaciones o autoridades de control y regulación. La topología de Netsukuku tiene requerimientos especiales. Una topología simple (plana), en donde no se imponga ninguna estructura en la red, puede ser memorizada en un solo mapa. Este mapa debe contener toda la información referente a los nodos que hacen parte de la red, excediendo los límites físicos de los enrutadores inalámbricos disponibles en el mercado. Al organizar la red de

31 HowStuffWorks: http://communication.howstuffworks.com/how-wireless-mesh-networks-work.htm Noviembre , 2008

- 34 -

manera jerárquica bajo los requerimientos teóricos de Netsukuku32 se puede almacenar toda la información referente a la red y sus nodos utilizando un mínimo de recursos de hardware, ideal para la adecuación de dispositivos embebidos de bajos recursos y la utilización de los mismos para la construcción de una plataforma de comunicaciones inalámbrica. El algoritmo utilizado para determinar las rutas se conoce como QSPN. Este algoritmo cumple con los mismos requerimientos que la topología (utilización mínima de recursos) y esta diseñado para operar entre los diferentes niveles que existan según la versión de IP a utilizar. QSPN se divide en varios componentes híbridos y un solo concepto universal; el Tracer Packet. El TP (Tracer Packet) es la unidad de información básica en QSPN ya que contiene toda la información necesaria para determinar las rutas que componen la red mesh. El TP es un paquete que lleva en su cuerpo el ID de los nodos por donde este atraviesa, dando a conocer a todos los nodos de la red quienes son los nodos que componen la mesh y sus vecinos. Existen variaciones del TP, que añaden algunas características ampliadas para operar en diferentes circunstancias especiales, por ejemplo, la sincronización constante de las tablas de enrutamiento, el descubrimiento de nuevas rutas y la reparación de enlaces rotos y redundantes 2.1.21. WMAN. Una WMAN hace referencia a las redes inalámbricas de área metropolitana, que también se conocen como bucle local inalámbrico (WLL, Wireless Local Loop). Las WMAN se basan en el estándar IEEE 802.16.en implementaciones masivas metropolitanas, sin embargo, su concepto también aplica para las diferentes arquitecturas de red que alcancen a dar cobertura de conectividad al rededor del perímetro urbano. Los bucles locales inalámbricos ofrecen una velocidad total efectiva de 1 a 10 Mbps, con un alcance de 4 a 10 kilómetros, algo muy útil para compañías de telecomunicaciones. Las tecnologías utilizadas para la creación de WMANs actualmente se limitan a WiMAX y a otro tipo de tecnologías propietarias, que por cuestiones de licenciamiento de espectro y costo de los equipos necesarios no son viables en la implementación del proyecto

32 Netsukuku Topology, http://netsukuku.freaknet.org/doc/main_doc/topology.pdf, Noviembre, 2008

- 35 -

2.2 MARCO LEGAL O NORMATIVO De acuerdo con el Plan Nacional de Asignación de Frecuencias, emitido por el Ministro de Comunicaciones de la República de Colombia, actualizado a Enero de 2007 emitido en el 2004, comunican que: De acuerdo con la Resolución 000689 de 21 de abril de 2004, se atribuyen dentro del territorio nacional, a título secundario, para operación sobre una base de no-interferencia y no protección de interferencia, los siguientes rangos de frecuencias radioeléctricas (2400-2483,5 MHz; 5150-5250 MHz; 5250-5350 MHz; 5470-5725 MHz; 5725-5850 MHz), para su libre utilización por sistemas de acceso inalámbrico y redes inalámbricas de área local, en las siguientes condiciones operativas:23) • Los sistemas de salto de frecuencia tendrán frecuencias portadoras por canal de inter-calamiento separadas como mínimo por el mayor valor entre 25 Khz. y el ancho de banda del canal a 20 dB. • El sistema saltará a los canales de frecuencias que son seleccionados, a la rata de salto del sistema, de una lista de frecuencias de salto ordenada pseudoaleatoriamente. Cada frecuencia se debe utilizar igualmente en promedio, por cada transmisor. Los receptores del sistema harán coincidir sus anchos de banda de entrada con los anchos de banda del canal de salto de sus transmisores correspondientes y cambiarán frecuencias en sincronización con las señales transmitidas. • Los sistemas de salto de frecuencia que operan en la banda de 5725-5850 MHz, deben usar por lo menos 75 frecuencias de inter-calamiento. El ancho de banda máximo permitido a 20 dB. del canal de inter-calamiento corresponde a 1 MHz. • El tiempo promedio de ocupación de cualquier frecuencia no deberá ser mayor que 0.4 segundos dentro de un período de 30 segundos. • Los sistemas de salto de frecuencia en la banda de 2400-2483,5 MHz deberán utilizar al menos 15 canales no sobrepuesto. • El tiempo promedio de ocupación de cualquier canal no deberá ser mayor a 0.4 segundos dentro de un período de 0.4 segundos multiplicado por el número de canales de salto empleados. • Los sistemas de salto de frecuencia que utilicen menos de 75 frecuencias de salto pueden emplear técnicas inteligentes de salto para evitar interferencias a otras transmisiones. Los sistemas de salto de frecuencia pueden evitar o suprimir transmisiones en una frecuencia particular de salto siempre y cuando se emplee

- 36 -

un mínimo de 15 canales no sobrepuesto. • Los sistemas que utilizan técnicas de modulación digital pueden operar en las bandas de 2400-2483,5 MHz y de 5725-5850 MHz. El ancho de banda mínimo a 6 dB. debe ser de por lo menos 500 kHz. • En la banda de 2400-2483,5 MHz la potencia de salida máxima del transmisor no excederá 1 vatio, para los sistemas que empleen al menos 75 canales de salto (tanto para los que usen salto de frecuencia como los que utilicen modulación digital). Para los demás sistemas de salto de frecuencia en esta banda la potencia máxima será de 0.125 Vatios. • En la banda 5725-5850 MHz la potencia de salida máxima del transmisor no excederá 1 vatio (tanto para los que usen salto de frecuencia como los que utilicen modulación digital). • Para antenas de transmisión de ganancia direccional mayor a 6 dBi, la potencia pico de salida de un transmisor debe ser reducida por debajo de los valores establecidos por la cantidad en dB. que la ganancia direccional de la antena exceda los 6 dBi. • Los sistemas que operen en la banda de 2.400 a 2.483,5 MHz que sean utilizados exclusivamente para operaciones fijas punto a punto, pueden emplear antenas de transmisión con ganancia direccional mayor a 6 dBi siempre y cuando la máxima potencia pico de salida del transmisor sea reducida en un 1 dB. por cada 3 dB. que la ganancia direccional de la antena exceda los 6 dBi. • Los sistemas que operen en la banda de 5 725 a 5850 MHz que sean utilizados exclusivamente para operaciones fijas punto a punto, pueden emplear antenas de transmisión con ganancia direccional mayor a 6 dBi sin la correspondiente reducción en la potencia pico de salida del transmisor. • La operación fija punto a punto, excluye el uso de sistemas punto a multipunto, aplicaciones omnidireccionales y emisores ubicados transmitiendo la misma información. • Los sistemas deben ser operados de tal forma que aseguren que el público no sea expuesto a niveles de energía de radiofrecuencia que exceda las normas que expida el organismo estatal pertinente. • En cualquier ancho de banda de 100 Khz. fuera de la banda de frecuencias en la cual está operando el transmisor de espectro ensanchado o de modulación digital, la potencia de radiofrecuencia que es producida por el transmisor deberá ser al menos 20 dB. menor que en los 100 Khz. de ancho de banda dentro de la

- 37 -

banda que contiene el más alto nivel de la potencia deseada, basado en una medición de RF bien sea conducida o radiada. • Para sistemas modulados digitalmente, la densidad espectral de potencia conducida desde el transmisor a la antena no debe ser mayor a 8 dBm en cualquier segmento de 3 Khz. durante cualquier intervalo de tiempo de transmisión continua. • En sistemas híbridos (emplean una combinación de técnicas de salto de frecuencia y de modulación digital), deberá tener un tiempo promedio de ocupación de cualquier frecuencia que no exceda 0.4 segundos dentro de un período de tiempo en segundos igual al número de frecuencias de salto empleadas multiplicado por 0.4. • Debe cumplir con los requisitos de densidad de potencia. • Los sistemas del espectro ensanchado por saltos de frecuencia no necesitan emplear todos los canales disponibles durante cada transmisión. Sin embargo, el sistema debe diseñarse conforme las normas de la actual resolución si el transmisor se presenta como una corriente continúa de datos o información. Además, un sistema que emplee cortas ráfagas de transmisión, debe cumplir con la definición de un sistema de saltos de frecuencia y debe distribuir sus transmisión es sobre el número mínimo de canales de salto especificado en esta resolución. • Es permitida la incorporación de inteligencia dentro de un sistema de espectro ensanchado por saltos de frecuencia que posibilite al sistema reconocer a otros usuarios dentro de la banda del espectro, de modo que elija y adapte individual e independientemente sus puntos de salto para evitar caer en los canales ocupados. La coordinación de sistemas de salto de frecuencia de cualquier otra forma, con el propósito expreso de evitar que múltiples transmisores ocupen simultáneamente frecuencias individuales de salto, no es permitida. • A los sistemas que utilicen tecnologías de espectro ensanchado por secuencia directa les serán aplicadas las disposiciones y condiciones operativas establecidas para los sistemas de modulación digital.

- 38 -

3. METODOLOGÍA

3.1 ENFOQUE DE LA INVESTIGACIÓN El enfoque que emplea este proyecto de acuerdo a las políticas de la Universidad es el empírico-analítico, por su interés técnico y su confrontación entre teoría y práctica mediante la investigación experimental e ingenieril. 3.2 LÍNEA DE INVESTIGACIÓN DE USB / SUB-LÍNEA DE FACULTAD /

CAMPO TEMÁTICO DEL PROGRAMA Línea de investigación tecnologías actuales y sociedad Sub-línea Sistemas de información y comunicaciones Campo temático Redes de comunicación

3.3 TÉCNICAS DE RECOLECCIÓN DE INFORMACIÓN Se realizaron varias prácticas de recolección de información tanto al inicio del proyecto como al momento de culminar el piloto de la red. Una de las prácticas que se realizaron para recolectar información se basó en el análisis pasivo del espectro electromagnético sobre las bandas de 2.400 – 2.484 MHz, dando importancia al análisis de utilización de los diferentes canales (14 canales disponibles técnicamente). Se realizaron además encuestas en el sector donde se implementó el piloto de la red, el cual sirvió para identificar los servicios que actualmente los usuarios demandan en una red como es Internet, considerándolas para ser implementarlas en lo posible dentro de la red mesh. Igualmente se realizaron encuestas al finalizar la implementación de la red piloto para poder evaluar la estabilidad y calidad de servicio de la misma.

- 39 -

3.4 HIPÓTESIS

El proyecto CogitoWireless permitirá el acceso a la información de manera libre e inalámbrica mediante un prototipo funcional, para ayudar así a disminuir la brecha digital del individuo en cierta zona de la ciudad de Bogotá mediante el uso de tecnologías y licencias libres y con ellas poder crear de todo tipo de contenido(Literatura, Música, Video, Fotografía y Software) local de interés comunitario para acercar a la gente con los mismos intereses de la comunidad, los cuales probablemente eran desconocidos por la falta de comunicación igualitaria entre personas. Con la infraestructura en línea, las personas podrán construir contenido y hacerlo publico y libre en la red, para que todos los demás puedan aprovechar estos recursos, construyendo así nuevos contenidos enriqueciendo cada vez mas la red. 3.5 VARIABLES

3.5.1. Variables independientes. En el análisis realizado se ha encontrado que para poder realizar este tipo de infraestructura se debe tener en cuenta la utilización de canales disponibles para 802.11g en Bogotá. Para poder medir el uso de este rango de frecuencias es necesario escuchar el área geográfica metropolitana de Bogotá y decodificar las tramas 802.11 para luego analizar los datos y determinar los canales más utilizados en las zonas recorridas. Otra variable independiente que se debe tener muy en cuenta es el factor climático de la ciudad. Hoy en día es muy difícil poder modelar un sistema tan complejo como el clima, más aún cuando las condiciones climáticas están siendo constantemente alteradas por la contaminación ambiental y el calentamiento global; sin embargo, estos cambios no afectan por completo la conectividad de los nodos y en caso tal de alguna pérdida de un enlace por condiciones climáticas severas, nuevas rutas pueden reemplazar los enlaces rotos reparando así la red mesh. También los dispositivos electrónicos son variables independientes ya que existen muchas alternativas baratas en el mercado y todas soportan los estándares IEEE 802.11 facilitando su implantación dentro de la red mesh. La diferencia de implementación en hardware es la potencia de transmisión de su dispositivo WiFi la cual determina junto con otros factores el alcance en el rango de conectividad inalámbrica.

- 40 -

Otra de las variables es la decisión sobre el sistema operativo a utilizar en la red y de éste dependen muchos factores técnicos y legales (con respecto al licenciamiento del software) en la implementación de los nodos. 3.5.2. Variables dependientes. El protocolo de enrutamiento es considerado como una variable dependiente dentro de la red WMAN ya que este toma la decisión y le da forma a la red para combatir mejor el problema a solucionar. No existe un protocolo que cubra todos los posibles escenarios de solución y existen diferentes acercamientos para atacar un problema. El protocolo de acceso al medio también es un factor importante para la implementación del prototipo, ya que determina cómo los nodos van a competir por el espectro y cómo van a conectarse físicamente unos con otros. En la solución propuesta el protocolo de enlace físico y de enlace de datos es IEEE 802.11g.

- 41 -

4. DESARROLLO INGENIERIL

Los siguientes ítems hacen referencia a todo el resultado del desarrollo ingenieril incluyendo sus fases y subfases, junto con la metodología empleada para la implementación del prototipo de red WMAN en el barrio la Florida ubicado en la localidad de Engativa.

4.1 METODOLOGÍAS DE DESARROLLO A continuación se mostrara las diferentes fases en las que se divide la metodología de desarrollo de este proyecto. Se comenzará explicando las actividades realizadas en cada una de las fases y los resultados obtenidos. 4.1.1. Fases del Proyecto. A lo largo de las diferentes fases, y adaptando las mejores prácticas de la metodología de desarrollo XP, se implementó un modelo de desarrollo iterativo e incremental para el desarrollo del proyecto, ya que se considera que los cambios de requisitos sobre el transcurso del mismo es un aspecto natural, inevitable e incluso deseable en todas las fases que componen el proyecto. La metodología de desarrollo XP ha sido concebida específicamente para el desarrollo de proyectos de software, sin embargo ofrece una serie de parámetros y guías base junto con algunas recomendaciones para la realización de proyectos cuyos requerimientos son muy cambiantes. La recolección de información tuvo tres enfoques principales; el desarrollo de las personalizaciones de software e implementación del protocolo, la adecuación de los dispositivos embebidos para suplir las necesidades y los requerimientos del diseño de red y el grado de penetración de los diferentes tópicos sociales que se intentan solventar. El levantamiento de información referente al impacto social de las tecnologías utilizadas se realizó comparando algunos patrones de búsquedas realizadas en el país y sus diferentes regiones utilizando palabras clave referentes al ámbito global del uso de las TICs y su relación con el software libre y las redes inalámbricas comunitarias, correlacionando los resultados para así poder determinar el estado actual de las tecnologías utilizadas y su acogida en el sector colombiano utilizando como métrica la popularidad de búsqueda de información y publicación de artículos en línea.

- 42 -

Se seleccionó la región de Latinoamérica ya que es la región con uno de los mayores índices de analfabetización digital en el mundo, ya que la brecha digital está muy marcada en todo su territorio. A continuación se muestra la relación entre los diferentes temas relacionados con la libre cultura y redes inalámbricas en los países latinoamericanos. Figura 3 Resultados de popularidad de los temas relacionados con software libre y redes inalámbricas en países latinoamericanos.

Análisis según el país

Siguiendo con el levantamiento de información, dado que los dispositivos embebidos son un elemento de vital importancia durante el desarrollo del proyecto por ser los elementos que toman las decisiones durante la operación lógica y física del sistema a implementar, esta actividad fue revisada de manera constante durante el desarrollo del proyecto. La solución final en dispositivos embebidos fue sesgada por algunos factores que a su vez eran requerimientos funcionales del mismo sistema. Gracias a esto, la selección en dispositivos embebidos fue la gama media de los enrutadores Linksys WRT54GL33 ya que no solo satisfacía los requerimientos funcionales, también estaba disponible en el mercado local lo cual reducía los costos de implementación de la prueba piloto. Dada la naturaleza del desarrollo del sistema a implementar y las aplicaciones que se debían integrar, la solución que se presenta no esta limitada a la familia de dispositivos Linksys WRT54GL y es de fácil implementación en otras arquitecturas de procesadores incluyendo x86, MIPS, ATMEL, AR91, ARM, entre otros, y un amplio rango 34 de hardware de producción, dispositivos embebidos de desarrollo y enrutadores inalámbricos. El desarrollo de las aplicaciones y las modificaciones de los diferentes componentes se realizó utilizando los mismos parámetros recomendados en las metodologías de XP ya que esto brinda los mismos beneficios mencionados

33 http://wiki.openwrt.org/TableOfHardware Abril , 2008 34 http://wiki.openwrt.org/TableOfHardware Abril , 2008

- 43 -

anteriormente referidos a dicha metodología. Las diferentes actividades de desarrollo se realizaron teniendo en cuenta el estado actual de implementaciones con algunas características a fines a lo largo del desarrollo del proyecto. Esto impactó en los requerimientos descubiertos a lo largo de las diferentes iteraciones del proyecto y facilito la realización del mismo en su totalidad. Durante el desarrollo e implementación del proyecto se trabajo en las siguientes etapas: Planeación. Las historias de los usuarios fueron escritas por los mismos diseñadores del sistema y presentan todas las necesidades que se deben cumplir para un acoplamiento exitoso de los diferentes componentes que hacen parte del núcleo del diseño propuesto. Esto permitió un desarrollo a la medida que satisfacía las soluciones del proyecto. La implantación se baso estrictamente en la aplicabilidad de la teoría de NTK y su integración con las distribuciones actuales de GNU/Linux para dispositivos embebidos junto con las personalizaciones recomendadas por el equipo de ingeniería. También se tuvo en cuenta el estado actual de las posibles mejoras en los dispositivos que se utilizaran en el prototipo funcional, como lo son las antenas disponibles en el mercado local, equipo de protección de hardware para exteriores, nuevas tecnologías de alimentación eléctrica de fácil implementación y bajo costo, y diferentes alternativas de enrutamiento para redes mesh. Diseño. El diseño de red propuesto intenta solventar algunos de los problemas que se considera de mayor importancia en la construcción de una red inalámbrica administrada por una comunidad, en donde el concepto principal es la autogestión y auto reparación de la infraestructura de comunicaciones que brindará la base para la construcción y montaje de servicios de diferentes características, todos ellos con el fin de hacer de la información un recurso de fácil acceso. Estos requerimientos son difíciles de conseguir porque proporcionan un desafío en cuanto a diseños de red basados en el direccionamiento IP y la construcción de la red WLAN. No se puede garantizar la anonimidad en la red ya que el direccionamiento sigue un patrón reconstruible en su diseño. La autogestión es otra característica de suma importancia en la construcción de una red inalámbrica, ya que el enlace con nuevos nodos debe ser una operación trivial y automática, en donde no exista necesidad de la intervención de un tercero no autómata que pudiera tener la oportunidad de sesgar la información de manera extenuante, degradando el servicio por el posible aumento de nuevas rutas en las tablas de enrutamiento de cada uno de los nodos que componen la red. NTK resuelve los problemas anteriormente mencionados estructurando la red en una topología jerárquica cuya implementación lógica es similar a los principios conceptuales de un fractal, en donde un patrón geométrico itera de manera casi infinita dentro de ella misma. Este concepto se utiliza de manera similar para

- 44 -

implementar una estructura de red conveniente para ser utilizada con un algoritmo de enrutamiento óptimo diseñado para iterar en este tipo de estructuras. El diseño propuesto toma en cuenta las consideraciones de este protocolo y plantea una situación real en la cual se intenta combatir el problema de la autogestión mediante escenarios de prueba limitados a un número pequeño de nodos. Codificación. La integración de las aplicaciones en el sistema embebido se debe realizar al mismo tiempo que se ejecutan las pruebas de diseño ya que esta es la mejor manera de resolver los conflictos y errores de empaquetado de software mediante la retro alimentación entre versiones candidatas e iteración en la generación de la imagen de firmware. La generación de reglas de empaquetado sigue un patrón similar, aunque con una complejidad un poco mayor que permite la integración de diferentes subsistemas de manera eficaz y con un margen muy pequeño de errores. El desarrollo de la imagen de firmware utilizado para la implementación de la prueba piloto involucro la programación, la personalización y las pruebas de funcionamiento de dispositivos embebidos. Las herramientas que se integraron y los scripts de automatización de empaquetado para el firmware desarrollado se convirtieron en uno de los esfuerzos más significativos durante el desarrollo del proyecto, y ahora reside activo bajo la tutela de la comunidad de CogitoWireless, quienes contribuyeron al levantamiento de información y al desarrollo de las pruebas piloto. Pruebas. Tanto la implementación física como lógica de la red mesh deben estar en constante monitoreo y evaluación para poder identificar los puntos débiles en las diferentes rutas de interconexión y los posibles cuellos de botella ocasionados por el medio físico o los errores de filtrado y enrutamiento de paquetes. Se hizo un seguimiento detallado de los aspectos fundamentales en la estructura de red, como lo son el ancho de banda disponible, las capacidades físicas de los dispositivos embebidos, la estabilidad de los drivers y dispositivos de radio utilizados para la conexión vía 802.11g. También es fundamental determinar la estabilidad del protocolo y su comportamiento bajo condiciones de estrés y variables desconocidas. Por eso es necesario llevar un control directo referente NTK con los desarrolladores del protocolo y así llegar a solucionar los posibles problemas de una manera mucho más rápida. Gracias a los requerimientos del proyecto, la licencia del protocolo de enrutamiento permite modificar el comportamiento total del mismo sin ningún inconveniente ni problemas legales de ningún tipo, siempre y cuando se cumplan

- 45 -

las condiciones impuestas por la licencia GPL-235. Esto permite una reacción más rápida ante los incidentes encontrados al integrar la suite de protocolos a los dispositivos embebidos mediante el firmware personalizado. 4.2 PLANEACIÓN En esta fase se analizarán los requerimientos funcionales de los servicios a implementar para la red piloto, junto con las características que debe tener el canal de comunicaciones para soportar el ancho de banda que requieren dichos servicios. Los servicios que se implementarán obedecen a la popularidad de dichos servicios en Internet y en las demás comunidades de redes inalámbricas que se encuentran en estado activo. 4.2.1. Recolección de Información. La recolección de la información se realizó mediante un recorrido alrededor de la zona piloto utilizando la herramienta de análisis de radio 802.11 llamada kismet. De los datos obtenidos se hizo una recopilación de información mediante un programa escrito en PHP con el fin de obtener algunos datos sobre la cantidad de puntos de acceso inalámbricos con sus respectivos canales y el porcentaje de utilización de cada uno de ellos y de esta manera poder identificar los posibles canales de interferencia aledaños. En el siguiente gráfico se observa el recorrido que se realizó por el barrio la Florida en la localidad de Engativa. El barrido de frecuencias en búsqueda de redes inalámbricas activas se realizo una vez por todo el barro la Florida. A continuación se muestra el recorrido realizado el 18 de Mayo del 2008. Figura 4 Recorrido realizado por el barrio la Florida

35 http://www.gnu.org/licenses/gpl-2.0.html, Noviembre 04, 2008

- 46 -

De los datos obtenidos se analizaron un total de 173 redes aledañas al sector. De las diferentes redes se estimó el porcentaje de utilización de los canales según las redes que los utilizan. Los resultados se muestran a continuación. Tabla 8 Análisis pasivo del espectro en la zona piloto

Canal Elementos Porcentaje 0 26 14.2076502732% 1 33 18.0327868852% 2 1 0.546448087432% 3 0 0% 4 0 0% 5 0 0% 6 70 38.2513661202% 7 12 6.55737704918% 8 2 0.945355191357 9 3 1.6393442623% 10 2 1.09289617486% 11 26 14.2076502732% 12 0 0% 13 0 0% 14 0 0% Total 173 100%

- 47 -

Gracias a este wardriving 36se pudo determinar que el canal más óptimo para la implementación es el canal 2 debido a que este canal es el que menos se sobrepone con los demás canales, reduciendo el nivel de interferencia de manera drástica. Debido a que este canal es el que cuenta con menos redes activas y es uno de los canales que menos se sobrepones sobre los canales 1 y 6, se considera que es este es el canal más adecuado para la red piloto. Además de esta prueba, se realizaron búsquedas para determinar el nivel de penetración de tecnología y el crecimiento de las comunidades del software libre en América latina, las cuales arrojaron resultados interesantes ya que se logro determinar de manera estimada el índice de adaptación de los países latinoamericanos referente a los temas de libertad de acceso a la información y a la difusión de contenidos de libre licencia. Utilizando las herramientas de búsqueda de Google Trends y Google Insight, se determinó el número de visitas por países según los distintos patrones de búsqueda en periodos de tiempo determinado. Todas las búsquedas de información se realizaron a partir del primero (1) de enero del 2004. También se realizaron diferentes búsquedas referentes a la región de Colombia para determinar el porcentaje de ciudades y territorios más activos en el país referente a los temas clave mencionados en este proyecto. Figura 5 Ciudades con mayor actividad en redes WiFi.

http://google.com/trends, Agosto 2008

En la figura anterior se puede observar que Cali es la ciudad con más búsquedas referentes a redes WiFi seguida muy de cerca por las ciudades de Bogotá y Medellín. Esto da como resultado que las principales ciudades en Colombia son las más activas en lo referente a consultas sobre estos temas. Las métricas 36 Wardriving: Se llama wardriving a la búsqueda de redes inalámbricas Wi-Fi desde un vehículo en movimiento.

- 48 -

utilizadas en la grafica anterior hacen referencia al número de hits (visitas) que han hecho las diferentes ciudades referentes a la búsqueda de información en redes WiFi. Figura 6 Búsqueda sobre redes inalámbricas en toda Colombia.

Interés en redes inalámbricas

En la figura anterior se puede observar la cantidad de búsquedas que se han realizado en Colombia respecto a las redes inalámbricas en un periodo de 4 años. Los números de hit hacen referencia a las visitas que se generaron por las consultas alrededor del termino “redes inalámbricas” según la fecha de búsqueda en el sector Colombiano.

- 49 -

Figura 7 Popularidad según ciudades principales de Latinoamérica

Análisis según la ciudad

La figura anterior muestra la popularidad de diferentes factores de diseño del prototipo a implementar (redes inalámbricas, tics, brecha digital, entre otros), respecto a algunas ciudades principales de América latina. Siguiendo con el análisis de los servicios que se implementarán en la red, se ha obtenido una tabla de estimación de ancho de banda por cada uno de ellos, con el fin de conocer la cantidad de usuarios soportados consumiendo el mismo servicio. Los servicios que se seleccionaron gracias a la popularidad de estos en Internet y en las demás comunidades de redes inalámbricas que se encuentran en estado activo. Tabla 9 Estimador de ancho de banda necesario según servicios37

Aplicación Ancho de

banda/ Usuario

Notas

Mensajería de texto / IM

< 1 Kbps Como el tráfico es infrecuente y asincrónico, IM es capaz de tolerar mucha latencia.

37 AICHELE, Corinna., FLICKENGEN, Rob., FORSTER, Jim. Redes inalámbricas en los países en desarrollo, 2 ed., Limehouse book sprint team, 2007 p. 53, 54.

- 50 -

Aplicación Ancho de

banda/ Usuario

Notas

Navegadores Web 50 – 100 + Kbps

Los navegadores Web sólo utilizan la red cuando se solicitan datos. La comunicación es asincrónica, por lo que se puede tolerar una buena cantidad de latencia. Cuando los navegadores Web buscan datos voluminosos (imágenes pesadas, descargas largas, etc.) la utilización del ancho de banda aumenta significativamente.

Flujo de audio (streaming)

96 – 160 Kbps

Cada usuario de un servicio de flujo de audio va a utilizar una cantidad constante de una relativamente gran cantidad de ancho de banda durante el tiempo que está activo. Puede tolerar algo de latencia pasajera mediante la utilización de mucha memoria de almacenamiento temporal en el cliente (buffer), sin embargo extensos períodos de espera van a hacer que el audio se sobreponga o que se den fallos en la sesión.

Compartición de archivos (FTP)

0 – Máximo de ancho de banda disponible en el canal.

La compartición de archivos es síncrona,por tal motivo no tolera una gran demora es por ello que la compartición de archivos requiere de poca latencia y un alto rendimiento.

De acuerdo a los servicios que se implementarán en la red se realizó un cálculo para estimar el consumo de ancho de banda por un (1) usuario haciendo uso de estos servicios.

Aplicación Consumo estimado Mensajería Instantánea 1 Kbps

HTTP 100 Kbps Streaming 160 Kbps

FTP 1 Mbps TOTAL 1.261 Mbps

- 51 -

Tabla 10 Ancho de banda disponible según el estándar 802.11 Con este resultado se podrá estimar cuál es el consumo de ancho de banda aproximado por un (1) usuario que se conecte a la red. Como se sabe que el ancho de banda máximo obtenido en el estándar 802.11 es de 11 Mbps en modo ad-hoc, se podrá conocer un estimado de la cantidad de usuarios que se podrían conectar a un punto de acceso haciendo uso de todos los servicios de forma simultánea. Para ello se dividió el máximo ancho de banda y el consumo estimado por un (1) usuario.

11 Mbps / 1.261 Mbps = 8,72323

Los 11mbps que están disponibles para transportar datos en la red son nominales, e incluyen el tráfico de retorno y de control. Por consiguiente la cantidad de usuarios estimados que se podrán conectar a un punto de acceso es de ocho (8) clientes para un solo canal de 11 Mbps utilizando todos los servicios de manera simultánea. Los servicios que se decidieron implementar en el piloto de red tuvieron una valoración perceptual mediante una entrevista realizada a los usuarios con acceso a Internet del barrio La Florida pertenecientes a la prueba piloto de la red mesh (Ver anexo C) en donde se logró calificar de cada uno de ellos por los residentes de la comunidad. A continuación se presenta una solución para dar respuesta a la pregunta de investigación anteriormente planteada. Se aplicarán las mejores técnicas de diseño y plantación de redes mesh y se utilizará la gran experiencia de numerosas comunidades y proyectos diferentes que han sido de gran éxito a nivel mundial.

Estándar Max Downlink

Max Uplink Rango Downlink típico

802.16e

(WiMax)

70.000kb/seg 70.000kb/seg ~4 mi. > 10

802.11a 54.000kb/seg 54.000kb/seg

802.11b 11.000kb/seg 11.000kb/seg ~30 mts. 2

802.11g 54.000kb/seg 54.000kb/seg ~30 mts. 10

802.11n 200.00kb/seg 200.00kb/seg ~50 mts. 40

- 52 -

4.3 DISEÑO En esta fase se pondrá en práctica todos los factores que influyen de manera directa en el desarrollo de los diseños pertinentes para la implementación del prototipo de red mesh. Se tendrán en cuenta los factores físicos y lógicos necesarios para brindar una plataforma de conectividad a los servicios que se implementaran. 4.3.1. Especificación de los servicios de red a implementar. Algunos de los servicios implementados en la red se tomaron como referencia los medios de difusión más implementados en los usuarios de software libre en Colombia, como lo son los trabajos colaborativos en Wikis, FTP's de contenido público y canales de comunicación comunitaria como IRC. 4.3.1.1 HTTP. Se ha decidido Apache como servidor Web por su estabilidad, robustez, licencia libre, facilidad de instalación y configuración, además este servidor presta el servicio Wiki el cual consiste en páginas Web que pueden ser creadas, borradas y editadas por cualquier usuario de la red, de esta manera permitir a cada usuario enlazarse a nuevos servidores y/o subir sus contenidos. Dicho servidor necesita como requerimientos mínimos de hardware los siguientes:

Sistema Operativo GNU/Linux Ubuntu 8.04.1 Kernel 2.6.24-19-generic Memoria DDR 256Mb Disco Duro 20 Gb (para garantizar el

alojamiento de los diferentes contenidos que se podrían albergar en la red mesh)

Tarjeta de red 802.3u Procesador Intel Pentium 200 Mx MHz

4.3.1.2 FTP. El servidor FTP que se instalará será VSFTP por la facilidad de instalación, configuración y licenciamiento libre, este servidor se montará con el fin de compartir los diferentes tipos de archivos libres que los usuarios quieran, dentro de este servidor se ha categorizado el contenido por música, OS (sistemas operativos), fotografía y literatura para su fácil navegación.

- 53 -

4.3.1.3 Streaming de Audio. Se instalara servidor Icecast para contar con la oportunidad de un canal de audio dentro de la red. Este servidor será montado en la red sólo para una prueba de funcionamiento y se publicará la guía de ejecución dentro de la Wiki para que los interesados puedan transmitir audio dentro de la red. Con este servicio, la comunidad podrá contar con una plataforma de difusión de audio, con posibilidades de construir una estación radial comunitaria de interés publico.

Dicho servidor tiene como requerimientos mínimos de hardware los siguientes:

Sistema Operativo GNU/Linux Ubuntu 8.04.1 Kernel 2.6.24-19-generic Memoria DDR 512Mb Disco Duro 40 Gb (se necesita de

gran capacidad de almacenamiento para hospedar el contenido de audio)

Tarjeta de red 802.3 u Procesador Intel Sempron 2800 MHz

4.3.1.4 Mensajería instantánea. Será implementado un servidor IRC por su fácil instalación, configuración, robustez y libre licencia para que todos los usuarios de la red puedan ingresar a los diferentes canales de Chat, igualmente todos los clientes cuentan con privilegios para crear salas y se puedan conectar libremente en los diferentes canales creados por los mismos. De la misma manera, un servicio de mensajería instantánea es un servicio de alta importancia para la comunidad de la Florida, ya que muchas de las personas que actualmente residen en el barrio que se ofrecieron a hospedar un nodo en sus casas usan IRC de manera frecuente para todas las actividades de comunicación diarias. 4.3.2. Selección de hardware de la red. Selección de hardware de la red. Para poder hacer el diseño de la red se realizó el estudio de todos los equipos activos y pasivos (descritos en detalle a continuación) requeridos para la instalación de la red, como lo son las diferentes tipos de antenas, enrutadores inalámbricos, pigtails y cajas para exteriores.

- 54 -

4.3.2.1 Antena omnidireccional QPCOM QP-AO24015. Las antenas omnidireccionales de 15 dbi, para poder dar cobertura al sector donde se va a implementar el piloto de red mesh. Figura 8 Antena Omnidireccional

Mediante estas antenas que irradian sus ondas electromagnéticas en sus 360º se lograra dar una cobertura de manera horizontal, consiguiendo así cubrir gran parte del sector donde se ubique la misma y permitir que los habitantes en este rango de cobertura puedan conectarse, acceder a la red y todos los servicios prestados. Este tipo de antenas poseen ciertas especificaciones eléctricas y mecánicas las cuales permiten trabajar y respetar para su óptimo funcionamiento, las cuales se citan a continuación: Tabla 11 Especificaciones eléctricas antena Omnidireccional

Especificaciones eléctricas Frecuencia 2400 – 2500 MHz

Ganancia 15 dBi

Polarización Vertical

Impedancia 50 ohmios

VSWR38 < 1.5:1 promedio

Entrada Máxima 100 watts Fuente: http://qpcom.com/Default.aspx?tabid=1807 Tabla 12 Especificaciones mecánicas antena Omnidireccional

Especificaciones mecánicas Conector N-Hembra

Peso 3.3 lbs (1.5kg)

Longitud 1.03m

Diámetro base 42.9mm

Diámetro radomo39 38.6mm

38 Relación de Onda Estacionaria de Voltaje

- 55 -

Especificaciones mecánicas Material radomo Fibra de vidrio gris

Montaje 2.0” máx. de diámetro del mástil

Resistencia a vientos hasta 150 MPH

Temperatura operativa -40° C hasta 85° C Fuente: http://qpcom.com/Default.aspx?tabid=1807 Figura 9 Patrones de radiación antena Omnidireccional

Fuente: http://qpcom.com/Default.aspx?tabid=1807

4.3.2.2 Antena panel Hyperlink HG2414P. Se instalaran este tipo de antenas para poder lograr el enlace de nodos a distancias superiores de la zona de cobertura de los nodos mesh, gracias a estas antenas se lograrán hacer enlaces de largo alcance que cuenten con línea de vista 40 y permitir el uso de los servicios de la misma. Figura 10. Antena Panel

Este tipo de antenas poseen ciertas especificaciones eléctricas y mecánicas las cuales permiten trabajar y respetar para su óptimo funcionamiento, las cuales se citan a continuación: 39 Recubrimiento de una antena, utilizado con el fin de protegerla sin que ello afecte a sus propiedades electromagnéticas, siendo transparente a las ondas de radio 40 http://es.wikipedia.org/wiki/LOS

- 56 -

Tabla 13 Especificaciones eléctricas de la antena panel Hyperlink

Especificaciones eléctricas Frecuencia 2400 – 2500 MHz Ganancia 14 dBi

Apertura del ángulo horizontal 30 grados Apertura del ángulo vertical 30 grados

Impedancia 50 Ohm VSWR < 1.5:1 promedio

Fuente: http://www.hyperlinktech.com/item.aspx?id=1827 Tabla 14 Especificaciones mecánicas de la antena panel Hyperlink

Especificaciones Mecánicas

Peso 0.43 Kg

Dimensiones 216 x 216 x 26 (mm)

Material UV-Polímero inhibido

Temperatura de Operación -40° C to 85° C Fuente: http://www.hyperlinktech.com/item.aspx?id=1827

Figura 11 Patrones de radiación antena Panel

Fuente: http://www.hyperlinktech.com/item.aspx?id=1827

4.3.2.3 Pigtail cable LMR 200. Para lograr conectar las antenas a los enrutadores inalámbricos que se implementaran en la red, es necesario contar con el tipo de cable adecuado.

- 57 -

Figura 12 Pigtail

Se escogió este tipo de cable por su flexibilidad, fácil manejo, baja atenuación y bajas perdidas por metro de cable, en comparación de otro tipo de cable con los que se puede implementar como lo es el RG-58. El cable LMR 200 posee una camisa protectora de polietileno que la protege contra los rayos UV y diseñada para un uso mínimo de vida de 20 años de servicio a la intemperie. Es un cable de buena flexibilidad y soporte a grandes torceduras sin romper el conductor, adicionalmente es uno de los tipos de cable de mayor flexibilidad y menor perdida. Cuenta con gran variedad de tipos de conectores, aumentando la posibilidad de adecuarlos a los diferentes tipos conectores de los enrutadores soportados. En el anexo B se encuentran los cálculos realizados para hallar la perdida en el cable Tabla 15 Características técnicas del cable LMR 200

Características Técnicas Núcleo 1,12 mm Dieléctrico 2,95 mm Pantalla 8,13 mm Recubrimiento 10,29 mm

Fuente: http://www.timesmicrowave.com/content/pdf/lmr/12-15.pdf

Tabla 16 Características eléctricas del cable LMR 200

Características Eléctricas Impedancia 50 Ohms

Potencia máxima 2,5 Kw.

Tensión máxima tolerada 1000 (DC) Fuente: http://www.timesmicrowave.com/content/pdf/lmr/12-15.pdf

- 58 -

4.3.2.4 Router WRT54GL. Enrutador encargado de transmitir las ondas electromagnéticas en el estándar 802,11 b/g bajo las frecuencias deseadas y permitidas por la comisión regulatoria de telecomunicaciones de bogotá. Figura 13 Router WRT54GL

Los siguientes modelos del fabricante de equipos de internetworking Linksys son los enrutadores compatibles con GNU/Linux y por consiguiente los únicos modelos que se utilizaron en la implementación de la red mesh piloto.

• WRT54GL v1 (Numero serial: CL7A) • WRT54GL v1.1 (Numero serial: CL7B) • WRT54GL v1.1 (Numero serial: CL7C)

El WRT54GL tiene 10 pines ranura en la placa llamada JP1 (JP2 en algunas placas v1.1). Esta ranura proporciona dos puertos seriales TTL a 3.3V. Ninguno de los puertos usa control de flujo por hardware, es necesario utilizar el software de control de flujo. Otros routers pueden tener conexiones similares. Estos dos puertos seriales TTL en el router WRT54GL pueden ser utilizados como puertos seriales estándar, similares a los puertos seriales que tiene el PC. Con el fin de hacer esto se necesita una línea chip controlador que puede elevar el nivel de señal de RS-232. No se puede conectar directamente a un puerto serial de cabecera a una board y esperar que funcione. Este método sólo funcionará con los dispositivos que pueden conectarse a puertos de serie TTL a 3.3V. Al conectar dos que posean 3.3V directamente trabajaran (TX - RX, RX - TX, GND - GND). Tabla 17 Puertos Seriales del Router Linksys WRT54GL Pin 2 3.3V Pin 4 TX_0 Pin 6 RX_0 Pin 8 No Conectado Pin 10 GND

Pin 1 3.3V Pin 3 TX_1 Pin 5 RX_1 Pin 7 No Conectado Pin 9 GND

Fuente: http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/WRT54GL?highlight=(OpenWrtDocs/Hardware)

- 59 -

Figura 14 Placa puertos seriales del Router Linksys WRT54GL

Fuente: http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/ WRT54GL?highlight=(OpenWrtDocs/Hardware) El puerto JTAG es un encabezado de 12 pines y está ubicado al lado del encabezado del puerto serial. Tabla 18 JTAG del Router Linksys WRT54GL Pin 2 GND Pin 4 GND Pin 6 GND Pin 8 GND Pin 10 GND Pin 12 GND

Pin 1 nTRST* Pin 3 TDI Pin 5 TDO Pin 7 TMS Pin 9 TDK Pin 11 nSRST*

Fuente: http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/ WRT54GL?highlight=(OpenWrtDocs/Hardware) Los que poseen * son los pines que no se usan en un cable JTAG sin buffer Figura 15 Placa JTAG del Router Linksys Wrt54GL

Fuente: http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/ WRT54GL?highlight=(OpenWrtDocs/Hardware)

- 60 -

Tabla 19 Especificaciones técnicas del Router Linksys Wrt54GL Especificaciones Técnicas

Estándar IEEE 802 .3, IEEE 802 .3u, IEEE 802 .11g, IEEE 802 .11b

Canales 11 Canales (2,412 – 2,472)

Puertos WAN: Uno 10/100 RJ-45 LAN: Cuatro 10/100 RJ-45

Tipo de cableado CAT5

Potencia de salida RF 18 dBm

Arquitectura MIPS

Fabricante Broadcom

Bootloader CFE

SOC(System On Chip) Broadcom 5352EKPB

Velocidad CPU 200MHz (183-250)

Tamaño flash 4Mb

RAM 16Mb

Tarjeta inalámbrica Broadcom BCM43xx 802.11b/g

JTAG Si Fuente: http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/ WRT54GL?highlight=(OpenWrtDocs/Hardware)

Tabla 20 Interfaces del Router Linksys Wrt54GL

Interfaces

Br-lan LAN t WiFi

vlan0 Puertos 1 – 4

vlan1 Puerto WAN

wl0 WiFi Fuente: http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/ WRT54GL?highlight=(OpenWrtDocs/Hardware)

- 61 -

Tabla 21 Puertos del Router Linksys Wrt54GL Puertos

WAN 4 LAN1 3 LAN2 2 LAN3 1 LAN4 0

Fuente: http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/ WRT54GL?highlight=(OpenWrtDocs/Hardware)

Tabla 22 Especificaciones mecánicas del Router Linksys Wrt54GL

Fuente: http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/ WRT54GL?highlight=(OpenWrtDocs/Hardware) 4.3.2.5 Cajas NEMA (para exteriores). Caja marca Scame fabricada de en termoplástico que no deja pasar el calor ni la humedad del ambiente. Figura 16 Caja Nema

Tabla 23 Comparativo de diferentes tipos de cajas para exteriores

Tipo Caja Material Medidas Peso Certificado Protección WRAP MINI-BOX 2A

Aluminio 180x125mm x 46mm

1.25kg IP-67 Agua y polvo y formación de hielo.

Especificaciones Mecánicas Dimensiones 7 .32" x 1 .89" x 6 .06"

(186 x 48 x 154 mm)

Peso 13 .8 oz. (391 g) Poder 12V DC, 0 .5ª Certificaciones FCC, IC-03, CE, Wi-Fi (802 .11b,

802 .11g), WPA2, WMM Temperatura en funcionamiento 32 a 104oF (0 a 40oC)

- 62 -

Tipo Caja Material Medidas Peso Certificado Protección Caja Hyperlink

Fiberglass 40x34x16 cms

2.0kg NEMA Intemperie, humedad y polvo

Caja Scame

Termoplástico 200X255X80 MM.

1.0kg NEMA Agua, Intemperie, humedad y polvo

Caja Exterior Aluminio IP67

Aluminio 181 x 156 x 51mm

1.13kg IP67 Agua y polvo y formación de hielo.

Fuente:http://www.comprawifi.com/kits-comprawifi/crea-tu-ap/cajas-ap/cat_118.html Se escogieron estas cajas principalmente porque son un producto certificado NEMA41 los cuales garantizan un uso de vida mínimo de 10 años a intemperie sin filtración de agua ni humedad, a comparación de las cajas metálicas que pueden afectar los radios del los routers, se oxidan al poco tiempo de estar a la intemperie y pesan casi el doble de las cajas con certificación NEMA. Estas cajas se encuentran disponibles en el mercado local nacional y son requeridas para poder empotrar los nodos en los exteriores de las casas. Los requerimientos de dichas cajas se satisfacen en su totalidad por las dimensiones de las mismas, ya que permiten encajar un enrutador Linksys WRT54g en su interior sin dificultad. 4.3.3. Diseño de la topología de red mesh. A continuación se presenta todo el diseño lógico y físico realizado para el montaje del prototipo de red mesh parcial en la localidad de Engativá, en el barrio La Florida. 4.3.3.1 Diseño geográfico. Los nodos se instalarán en el barrio la Florida, ubicado en la localidad de Engativa, barrio de estrato 3 que cuenta con alrededor de 5.000 habitantes. Se decidió montar la red piloto en este barrio de la ciudad debido a la colaboración de algunas personas interesadas en la implementación de la red inalámbrica ya que la mayoría de ellas se encuentran trabajando con la comunidad local, el movimiento del software libre y las redes inalámbricas.

41 http://www.nema.org/, Junio, 2008

- 63 -

Figura 17 Enlaces puntos de acceso

La ubicación exacta de cada nodo se escogió a medida que la comunidad se vinculaba a través del desarrollo del proyecto, todos los nodos se encuentran ubicados en los últimos pisos de los conjuntos, garantizando línea de vista entre ellos y acceso a los clientes. Tabla 24 Distancia entre nodos

Nodos Distancia (Metros)

nodomesh4 y nodomesh3 236

nodomesh3 y nodomesh1 210

nodomesh3 y nodomesh2 128

nodomesh2 y nodomesh1 89

Tabla 25 Latitud y longitud de cada nodo Nodo Latitud y Longitud

nodomesh1 4.691°N 74.1126°W

nodomesh2 4.6916°N 74.1132°W

nodomesh3 4.6904°N 74.1117°W

nodomesh4 4.6883°N 74.1111°W

- 64 -

4.3.3.2 Diseño Físico. Para poder determinar un óptimo rendimiento en los enlaces se vio la necesidad de realizar algunos cálculos para evaluar la viabilidad de cada uno de ellos. Para poder evaluar si un enlaces es viable es necesario contar con las características de los equipos que se van a implementar. La ecuación para hallar la perdida en el espacio libre es:

lfsl = 32.4 + 20Log(d/Km.) + 20Log(f/MHz.)42

Donde lfsl (perdida de señal en espacio abierto) esta expresada en dB, 32.4 es la constante, d es la distancia en kilómetros desde el transmisor y el receptor y f es la frecuencia en Megahertz dada por el canal seleccionado (se selecciono el canal 2 para el montaje de los nodos). Para evaluar si un enlace es viable, se debe conocer las características de los equipos que se van a utilizar y evaluar la perdida en el trayecto. Antes de empezar con las tablas se despeja la ecuación de perdida en el espacio libre en cada uno de los enlaces. Dado que la potencia de los radios esta dada en mili watts, se realizó la conversión a dB.

• Presupuesto de enlace entre los nodos NodoMesh4 y NodoMesh3 d = 0.236 Km. f = 2417 MHz

lfsl = 32.4 + 20Log(d/Km.) + 20Log(f/MHz.) lfsl = 32.4 + 20Log(0,236) + 20Log(2417) lfsl = 32.4 + (-12.541759) + 67.665533 lfsl = 87.523770 dB

• Ganancia de las antenas

Antena Radio 1

dBi Antena Radio 2

dBi Ganancia Total de la

Antena

14 dBi 15 dBi 29 dBi

42 http://www.it46.se/downloads/courses/wireless/es/06_Calculo-Radioenlace/06_es_calculo-de-radioenlace_guia_v01.pdf . Agosto. 2008

- 65 -

• Perdidas

Perdida en el cable (radio 1) dB.

Perdida en el cable (radio 2) dB.

Perdida en el espacio libre dB.

Perdida Total

0.5 dB. 0.5 dB. 87.523770 dB 88. 523770 dB

• Presupuesto para el enlace entre los radios 4 y 3:

Potencia TX de

radios 1 + Ganancia Total

de Antena - Perdida Total = Señal Sensibilidad en

los radios 1

20.8 dB. 29 dBi 88. 523770 dB - 38.72377 - 83dBm

Potencia TX de

radios 2 + Ganancia Total

de Antena - Perdida Total = Señal Sensibilidad en

los radios 2

20.8 dB. 29 dBi 88. 523770 dB - 38.72377 - 83dBm

Para saber si el enlace es viable restamos la perdida en el trayecto de la ganancia total

49.8 – 87.523770 = - 37.72377 dBm Ya que - 37.72377 dBm es mayor a la sensibilidad del receptor (-83dBm) el nivel de señal es más que suficiente para que los nodos nodomesh4 y nodomesh3 puedan oírse y el enlace sea viable.

• Presupuesto de enlace entre los nodos NodoMesh3 y NodoMesh1 d = 0.210 Km. f = 2417 MHz

lfsl = 32.4 + 20Log(d/Km.) + 20Log(f/MHz.) lfsl = 32.4 + 20Log(0,210) + 20Log(2417) lfsl = 32.4 + (-13.555614) + 67.665533 lfsl = 86.509918 dB

- 66 -

• Ganancia de las antenas

Antena Radio 1 dBi

Antena Radio 2 dBi

Ganancia Total de la Antena

15 dBi 7dBi 22dBi

• Perdidas

Perdida en el cable

(radio 1) dB. Perdida en el cable

(radio 2) dB. Perdida en el espacio

libre dB. Pérdida Total

0.5 dB. 0.5 dB. 86.509918 dB 87. 509918 dB

• Presupuesto para el enlace entre los radios 3 y 1:

Potencia TX de

radios 1 + Ganancia Total

de Antena - Perdida Total = Señal Sensibilidad en

los radios 1

20.8 dB. 22 dBi 87. 509918 dB - 44.709918 - 83dBm

Potencia TX de

radios 2 + Ganancia Total

de Antena - Perdida Total = Señal Sensibilidad

en los radios 2

20.8 dB. 22 dBi 87. 509918 dB - 44. 709918 - 83dBm

Para saber si el enlace es viable restamos la perdida en el trayecto de la ganancia total.

42.8 - 86, 509918 = - 43.709918 dBm Ya que - 43.709918 dBm es mayor a la sensibilidad del receptor (-83dBm) el nivel de señal es más que suficiente para que los nodos NodoMesh3 y NodoMesh1 puedan oírse y el enlace sea viable.

• Presupuesto de enlace entre los nodos NodoMesh3 y NodoMesh2 d = 0.128 Km. f = 2417 MHz

lfsl = 32.4 + 20Log(d/Km.) + 20Log(f/MHz.) lfsl = 32.4 + 20Log(0,128) + 20Log(2417) lfsl = 32.4 + (-17.855800) + 67.665533 lfsl = 82.209732 dB

- 67 -

• Ganancia de las antenas

Antena Radio 1 dBi

Antena Radio 2 dBi

Ganancia Total de la Antena

15 dBi 7dBi 22dBi

• Perdidas

Perdida en el cable

(radio 1) dB. Perdida en el cable

(radio 2) dB. Perdida en el espacio

libre dB. Pérdida Total

0.5 dB. 0.5 dB. 82.209732 dB 83.209732 dB

• Presupuesto para el enlace entre los radios 3 y 2:

Potencia TX de

radios 1 + Ganancia Total

de Antena - Perdida Total = Señal Sensibilidad en

los radios 1

20.8 dB. 22 dBi 83.209732 dB - 40.409732 - 83dBm

Potencia TX de

radios 2 + Ganancia Total

de Antena - Perdida Total = Señal Sensibilidad

en los radios 2

20.8 dB. 22 dBi 83.209732 dB - 40. 409732 - 83dBm

Para saber si el enlace es viable restamos la perdida en el trayecto de la ganancia total 42.8 - 82.209732 = - 39.409732 dBm Ya que – 39.409732 dBm es mayor a la sensibilidad del receptor (-83dBm) el nivel de señal es más que suficiente para que los nodos nodomesh3 y nodomesh2 puedan oírse y el enlace sea viable.

• Presupuesto de enlace entre los nodos NodoMesh2 y NodoMesh1 d = 0.089 Km. f = 2417 MHz

lfsl = 32.4 + 20Log(d/Km.) + 20Log(f/MHz.) lfsl = 32.4 + 20Log(0,089) + 20Log(2417) lfsl = 32.4 + (-21.012199) + 67.665533 lfsl = 79.053333 dB

- 68 -

• Ganancia de las antenas

Antena Radio 1 dBi

Antena Radio 2 dBi

Ganancia Total de la Antena

7 dBi 7dBi 14dBi

• Perdidas

Perdida en el cable

(radio 1) dB. Perdida en el cable

(radio 2) dB. Perdida en el espacio

libre dB. Perdida Total

0.5 dB. 0.5 dB. 79.053333 dB 80.053333 dB

• Presupuesto para el enlace entre los radios 2 y 1:

Potencia TX de

radios 1 + Ganancia Total

de Antena - Perdida Total = Señal Sensibilidad en

los radios 1 20.8 dB. 14 dBi 80.053333 dB - 45.253333 - 83dBm

Potencia TX de

radios 2 + Ganancia Total

de Antena - Perdida Total = Señal Sensibilidad en

los radios 2

20.8 dB. 14 dBi 80.053333 dB - 45.253333 - 83dBm

Para saber si el enlace es viable restamos la perdida en el trayecto de la ganancia total 34.8 – 79.053333 = - 44.253333 dBm Ya que – 44.253333 dBm es mayor a la sensibilidad del receptor (-83dBm) el nivel de señal es más que suficiente para que los nodos nodomesh2 y nodomesh1 puedan oírse y el enlace sea viable. • Topología. Existen otras clasificaciones según la naturaleza del diseño del protocolo, pero no aplican para la implementación de redes mesh autogestionadas. Una topología mesh no es aquella en donde todos sus nodos se encuentran completamente conectados. Es por eso que una topología mesh es la adecuada en este tipo de redes inalámbricas ya que nunca se va a lograr una conectividad total en toda la ciudad de Bogotá, y la única forma de cubrirla de manera total es enlazando diferentes nodos ubicados de manera uniforme alrededor del perímetro urbano de la ciudad.

- 69 -

Figura 18 Tipos de topologías

Fuente: upload.wikimedia.org/wikipedia/commons/9/96/NetworkTopologies.png 4.3.3.3 Diseño Lógico. Para poder tener un canal de comunicaciones confiable, se debe construir una columna vertebral. La red se diseño para contar con cuatro nodos principales, que conforman la columna vertebral de comunicaciones para empezar a construir la red mesh. Los nodos principales se adecuaron para su funcionamiento en exteriores y utilizan equipo especializado junto con un software personalizado que permite la interconexión de los equipos. Figura 19 Diseño lógico de la red propuesta

Una vez construida la columna vertebral y sus enlaces físicos se podrá enlazar un número mayor de nodos quienes actuaran como extensiones de la columna vertebral, facilitando la expansión no controlada de la red mesh. • Topología de la red inalámbrica. El estándar 802.11 define diferentes modos

de operación según las necesidades de conectividad. Según el escenario propuesto y el diseño de red a implementar, el estándar 802.11 define una serie de parámetros y servicios básicos de conectividad que

- 70 -

proporcionan una infraestructura de comunicaciones inalámbricas para todos los equipos que cumplan con las recomendaciones de WiFi. La arquitectura que define 802.11 define los siguientes parámetros:

o Estaciones: Las estaciones son todos los componentes que se pueden conectar de manera inalámbrica a la red. Dichas estaciones deben incorporar una interfaz de comunicación inalámbrica (WNIC) para poder acceder al medio. Las estaciones se dividen en dos categorías; los puntos de acceso y los clientes. Los puntos de acceso son estaciones base que proveen cobertura de conectividad inalámbrica y administración centralizada para la red. Estos puntos de acceso pueden enviar y recibir información de todos los dispositivos que posean una interfaz de comunicación inalámbrica.

o Conjunto de servicios básicos (BSS): El conjunto de servicios

básicos (BSS, Basic Service Set) es una modalidad de infraestructura en donde todas las estaciones se pueden comunicar unas con otras. Existen dos tipos de BSS; IBSS (Independent Basic Service Set) y BSS de infraestructura (Infrastructure BSS). Cada BSS tiene un ID único llamado BSSID (Basic Service Set Identifier) que se compone de la dirección MAC del punto de acceso que sirve el BSS. Una IBSS es una modalidad de infraestructura comúnmente llamada ad-hoc, en donde no existen puntos de acceso lo cual significa que este tipo de redes no es capaz de conectarse a otros BSS. La modalidad de BSS de infraestructura consiste en un punto de acceso que brinda la cobertura y la conectividad a las diferentes estaciones, ofreciendo conectividad a otros BSS a través del punto de acceso.

o Conjunto de servicios extendidos (ESS): Esta modalidad de

infraestructura consiste en un conjunto de BSS interconectados mediante un sistema de distribución. Cada ESS tiene un ID llamado SSID (Service Set Identifier) que está compuesto por una cadena de caracteres de 32bytes de longitud.

Teniendo en cuenta lo anterior, se seleccionó la modalidad IBSS para conectividad inalámbrica tipo ad-hoc ya que este esquema permite la adición de nodos sin necesidad de reestructurar toda la conectividad física ni la forma centralizada de administración de la red.

- 71 -

Tabla 26 Comparativo de las tecnologías de red inalámbricas43 Estándar Frecuencias Tipo de espectro

UMTS sobre W-CDMA 850Mhz, 1.9, 1.9/2.1 y

1.7/2.1 GHz

Licenciado (Celular, PCS, 3G, AWS)

UMTS-TDD 450, 850 MHz, 1.9, 2, 2.5, y

3.4 GHz

Licenciado (Celular, 3G TDD,

BRS/IMT-ext, FWA)

CDMA2000 (inc. EV-DO 1xRTT) 450, 850, 900 MHz, 1.7, 1.8,

1.9 y 2.1 GHz

Licenciado (Celular, PCS, 3G, AWS)

EDGE/GPRS 850, 900 MHz, 1.8, 1.9 GHz Licenciado (Celular, PCS, PCN)

Iburst 1.8, 1.9 y 2.1 GHz Licenciado

Flash-OFDM 450, 870 MHz Licenciado

802.16e 2.3, 2.5, 3.5, 3.7 y 5.8 GHz Licenciado

802.11ª 5.25, 5.6, y 5.8 GHz Sin licencia, ISM

802.11b/g/n/s 2.4 GHz Sin licencia, ISM

Bluetooth 2.4 GHz Sin licencia, ISM

Wibree 2.4 GHz Sin licencia, ISM

ZigBee 868, 915 y 2.4 GHz Sin licencia, ISM

UWB 3.1 a 10.6 GHz Sin licencia, Ultrawideband

EnOcean 868.3 MHz Sin licencia, ISM

La tabla anterior muestra un comparativo de las diferentes tecnologías de conectividad inalámbrica disponibles actualmente en el mercado internacional. Por razones de licencia, disponibilidad y compatibilidad con GNU/Linux, se implementará la tecnología 802.11 en sus variantes 802.11b y 802.11g. • Evaluación de protocolos de enrutamiento. Existen diferentes protocolos de enrutamiento para organizar la red lógica utilizando diferentes métricas y algoritmos para encontrar las rutas más óptimas en las redes malladas. Ya que no todos los protocolos a mencionar disponen de una implementación en software para GNU/Linux, es imposible hacer una comparativa práctica entre los diferentes protocolos, sin embargo, estudios anteriores44 han medido el desempeño de protocolos de enrutamiento para redes ad-hoc multisalto. 43 http://en.wikipedia.org/wiki/Comparison_of_wireless_data_standards, Octubre 2008 44 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.27.7219 , Noviembre 04, 2008

- 72 -

Los algoritmos de enrutamiento disponibles en la actualidad corresponden a los siguientes:

o Algoritmo de búsqueda A* o Distancia administrativa o Enrutamiento Arc o ATR (Augmented Tree-based Routing) o Algoritmo de búsqueda B* o Sistema justo de colas basadas en créditos o Algoritmo de Dijkstra o Algoritmo de enrutamiento vector-distancia o Algoritmo EDSP (Edge disjoint shortest pair) o ETX (Expected Transmission Count) o Sistema de créditos justos o Algoritmo de Floyd-Warshall (WFI) o Enrutamiento geográfico

No todos estos algoritmos han sido implementados por protocolos de enrutamiento, y muchos de ellos han servido de base para la generación de nuevos diseños de protocolos y principios de enrutamiento. Los algoritmos de enrutamiento obedecen a diferentes constantes y paradigmas de conectividad que no aplican en su totalidad para su implementación sobre diferentes medios. Algunos algoritmos suponen de conectividad sin interrupciones para su optimo funcionamiento, mientras que otros se basan en el estado del enlace antes y no en la selección de la mejor ruta vía análisis de vector - distancia. Teniendo en cuenta lo anterior, los protocolos que mejor se ajustan a los requerimientos físicos de las redes mesh inalámbricas se clasifican bajo las siguientes categorías:

o Enrutamiento pro-activo (mediante tablas de enrutamiento) o Enrutamiento reactivo (bajo demanda) o Enrutamiento adaptativo (consiente de la situación) o Enrutamiento hibrido (pro-activo/reactivo) o Enrutamiento jerárquico o Enrutamiento geográfico

No todos los protocolos cuentan con una implementación vía software así que la selección del protocolo a implementar depende no solo de los requerimientos del proyecto sino también de la disponibilidad de este para GNU/Linux. Los protocolos que cuentan con una implementación funcional en sistemas GNU/Linux son los siguientes:

- 73 -

• Enrutamiento pro-activo o OLSR o AWDS o Babel

• Enrutamiento reactivo

o AODV • Enrutamiento hibrido

o B.A.T.M.A.N • Enrutamiento jerárquico

o NTK En la actualidad, los únicos protocolos de los anteriormente mencionados que se encuentran en estado de desarrollo activo son B.A.T.M.A.N, NTK, OLSR y Babel. Las características de cada uno de ellos se muestran a continuación: Tabla 27 Comparativo entre protocolos

Protocolo NTK Babel B.A.T.M.A.N OLSR Tipo de enrutamiento Proactivo Proactivo Hibrido Proactivo Implementación activa Si Si Si Si Versión IP IPv4 / IPv6 IPv4 / IPv6 IPv4 / IPv6 IPv4 / IPv6Auto asignación de IPs Si No No No IEEE 802.3ad Si No No No Soporta API Si No No Si Lenguaje Desarrollado C/ Python C C C Topología Soportada Jerarquía Plana Plana Plana Rutas redundantes No No Si No

Debido a los requerimientos de autogestión y descentralización del manejo de la red se selecciono el protocolo NTK como protocolo de enrutamiento por omisión en la implementación de la red piloto. Las demás implementaciones actuales de protocolos de enrutamiento disponibles para GNU/Linux, no cumplen con los requerimientos de autogestión y descentralización. • Características NTK. La red mesh propuesta debe ser autogestionada. Esto

significa que no importa el número de nodos por los cuales la red está compuesta, esta siempre debe gestionar de manera automática la asignación de direcciones y la selección de las mejores rutas para construir las tablas de enrutamiento.

- 74 -

Una topología simple, en donde no se imponga ninguna estructura de red puede ser memorizada en un solo mapa en donde la información referente a los nodos que componen la red se debe memorizar en su totalidad. La creación de dicho mapa y su constante actualización representa una alta sobrecarga de recursos de hardware para los nodos. Dicha topología requeriría de aproximadamente 1GB de memoria si la red está compuesta por 109 nodos (el tamaño actual de la Internet), asumiendo que el espacio necesario para almacenar una ruta hacia un solo nodo ocupa 1B. Debido a los recursos limitados de los nodos a utilizar en el prototipo de red piloto, se debe estructurar la red en una topología conveniente. La topología lógica a utilizar se denomina topología jerárquica y obedece a una serie de reglas y características que estructuran la red lógica bajo el mismo principio de un fractal. Un fractal generalmente se define como una figura geométrica que se puede dividir en muchas partes, en donde cada parte contiene una copia reducida de la figura original. Esta propiedad es llamada auto similaridad, y tiene consecuencias importantes en el diseño de redes de computadores que tengan las mismas características. El concepto de topología jerárquica en NTK obedece a los siguientes conceptos. La red se debe subdividir en grupos de 256 nodos utilizando las siguientes definiciones:

o gnode: Un grupo de nodos G es una serie de nodos interconectados. Cada nodo de la red debe pertenecer a un gnode. Todos los gnodes contienen un máximo de 256 nodos.

o bnode: Un bnode hace referencia a un nodo ubicado en la frontera

de la topología. Es un nodo que pertenece a un gnode determinado, pero que a su vez esta enlazado con al menos un nodo perteneciente a otro gnode.

Figura 20. Ejemplo de bnode.

Fuente: http://netsukuku.freaknet.org/2html/documentation/main_documentation/totpology.pdf

- 75 -

La topología de red se divide en n niveles, n siendo determinado según el espacio de direcciones a utilizar. En IPv4 están disponibles cuatro (4) niveles para organizar la topología de red ya que el espacio de direcciones disponibles es 232. En IPv6 están disponibles 16 niveles diferentes para organizar la topología de red ya que el espacio de direcciones disponibles es 2128. Las divisiones de los niveles también obedecen a la misma constante de número máximo de nodos, 256. La red se debe segmentar en grupos de 256 grupos de nodos (gnodes) y se sigue aplicando la terminología de gnode para hacer referencia a los niveles segmentados. Estas divisiones se repiten de manera recursiva hasta que se pueda agrupar todos los nodos de la red dentro de un solo gnode. Dicha estructura organiza la red en n + 1 niveles (desde 0 hasta n).

• En el nivel base (nivel 0) se tiene un máximo de 256 nodos individuales • En el primer nivel (nivel 1) se tiene un máximo de 256 gnodes normales.

Cada gnode contiene 256 nodos individuales. • En el segundo nivel (nivel 2) se tiene un número máximo de 256 gnodes

compuestos por 256 gnodes. • En el tercer nivel (nivel 3) se tiene un número máximo de 256 grupos de

256 grupos de 256 grupos de 256 grupos de nodos. Figura 21 Ejemplo de topología jerárquica de NTK

Fuente: http://netsukuku.freaknet.org/2html/documentation/main_documentation/totpology.pdf Los grupos de nodos de color rojo en la gráfica anterior representan el nivel 0 de la topología. Los grupos de nodos de color verde representan el nivel 1, de manera consecutiva hasta llegar al nivel n con un solo gnode.

- 76 -

De esta manera se logra obtener una topología estructurada de manera jerárquica en donde un solo gnode contiene la información de todos los nodos que componen la red utilizando IPv4. En IPv4 se tendría los IDs correspondientes a los nodos con la misma notación IP (0..255-0..255-0..255-0..255). En caso de que más de un gnode se enlace con otro ggnode cuyas direcciones IP sean igual, ambos entraran en una fase de negociación para volver a generar las direcciones de cada uno de los grupos. Si esto llegase a ocurrir, el esquema de negociación obedece al siguiente diagrama. Figura 22 Diagrama de negociación por colisión en NTK

Fuente: http://netsukuku.freaknet.org/2html/documentation/main_documentation/totpology.pdf Para evitar las colisiones entre gnodes, se una huella definida por: fg(G) = (uptime(G),rid(G)), en donde rid(G) es un ID creado de manera aleatoria cuando se inicializa como gnode. El intercambio de información referente a las rutas disponibles se realiza mediante la difusión de listas denominadas TP. Los TP (Tracer Packet) contienen el ID de cada nodo por donde este cruza, difundiendo así los IDs de los nodos que están disponibles y las rutas para llegar a ellos. El nodo que inicio la difusión de TP fue el NodoMesh3 con las siguientes características. El TP recibido por el NodoMesh4 debe contener la siguiente información.

- 77 -

{NodoMesh3,NodoMesh4} El TP recibido por el NodoMesh1 debe contener la siguiente información. {NodoMesh1,NodoMesh2,NodoMesh3} El bouquet de TP hace referencia a la colección de TP’s individuales que serán enviados cuando ocurra una difusión de TP’s. [{NodoMesh3,NodoMesh4}, {NodoMesh1,NodoMesh2,NodoMesh3}] Para poder garantizar que las rutas se mantendrán en constante actualización, existe otro tipo de TP diseñado para dichas ocasiones. El ETP (Extended Tracer Packet) es un tipo de TP que borra los ID’s de todas las rutas contenidas dentro del paquete una vez que este llegue a un nodo de frontera (nodo ubicado al final de la red) y se devuelve insertando los ID’s de los nodos que atraviesa de vuelta, actualizando las tablas de enrutamiento de todos los nodos por donde se enruta. El ETP reconstruye las rutas en los siguientes casos de cambios de enlace: • Enlace modificado • Nuevo Enlace • Enlace roto • Nuevo nodo ingresa a la red • Muerte de un nodo Los mapas de la topología de la red almacenados en las estaciones ocupan 1Kb para IPv4, ya que para 256 gnodes con un uso de 1 byte por nivel (IPv4 contiene 4 niveles jerárquicos de 255 gnodes cada uno) mientras que utilizando una topología plana los mapas de la topología ocuparían 4Gb por 232 posibles espacios de direcciones disponibles. En la topología jerárquica se necesitarían solamente 256 posibles espacios de direcciones disponibles, pero iterando en 4 niveles diferentes. Como esquema final del prototipo de red mesh parcial tenemos el siguiente diagrama:

- 78 -

Figura 23 Diseño de red final

El diagrama anterior hace referencia al diseño final de la red mesh parcial a implementar en la localidad de la Florida, en la localidad de Engativa. 4.4 IMPLEMENTACIÓN DE LA ARQUITECTURA DE RED A continuación se muestra el resultado de las investigaciones referentes a la configuración de nodos y clientes, para que estos puedan inter-operar y organizar lógica y físicamente una red mesh parcial utilizando NTK como protocolo de enrutamiento. 4.4.1. Adecuación de equipos. La adecuación de las estaciones (Nodos y Clientes) está sujeta a la instalación de NTK, ya que sin este protocolo de enrutamiento no existe forma de que las estaciones que carezcan de NTK puedan enlazarse de manera correcta y hacer parte de la red mesh. A continuación se muestra los procedimientos necesarios para la instalación y configuración de NTK en las estaciones junto con sus respectivos requerimientos de Software. Ya que los nodos no incorporan todas las aplicaciones y herramientas básicas necesarias para la interconexión de estaciones utilizando NTK, fue necesario embeber diferentes suites de enrutamiento junto con herramientas de diagnostico y las personalizaciones necesarias para el funcionamiento optimo de la red mesh piloto en una imagen binaria de OpenWRT.

- 79 -

El sistema de OpenWRT personalizado cuenta con algunos componentes básicos que permiten su total integración con las herramientas empotradas: • Interfaz UCI. • Scripts de arranque del sistema. • Configuración UCI por omisión. • Integración de protocolos de enrutamiento. • Integración de herramientas para diagnostico de la red. Figura 24 Modelo conceptual del sistema en OpenWRT.

El lenguaje utilizado para desarrollar las modificaciones de los diferentes aplicativos fueron shell script (ASH) y C. Ya que embeber las aplicaciones en los enrutadores que se utilizaron en la implementación de la red piloto necesita de otras plataformas de desarrollo, se utilizaron las siguientes herramientas: • OpenWRT • SVN • GNU toolchain (gcc, binutils, coreutils, libc, kernel-headers) Los archivos de configuración e instrucciones para la compilación y la instalación de NTK se encuentran disponibles en los anexos. 4.4.1.1 Requerimientos de Software y del Kernel de Linux: Antes de proceder con la compilación del código se deberá asegurar que las dependencias están instaladas de manera correcta en el sistema huésped. Estas dependencias son

- 80 -

librerías y herramientas de compilación que en algunas ocasiones no vienen por omisión instaladas en el sistema. Si este es el caso, debe asegurarse de poder instalar dichas dependencias mediante el manejador de paquetes de software de la distribución GNU/Linux del sistema huésped. Las dependencias que deben estar instaladas son:

• aclocal • autoconf • libtoolize • automake • libgmp • libgmp3-dev • openssl • libssl-dev • iptables-dev

Estas dependencias se pueden instalar por su nombre si la distribución de Linux que se está utilizando soporta un gestor de paquetes de software tipo APT. Para poder compilar el código fuente es necesario tener instalado toda la suite de herramientas de desarrollo. Estas herramientas incluyen el compilador gcc, las herramientas base binutils, las cabeceras del kernel de Linux y un enlazador de binarios ldd incluido en binutils. Estas herramientas se instalan bajo el nombre del meta paquete build-essentials bajo sistemas APT. Los usuarios de meta distribuciones como Gentoo GNU/Linux no tienen necesidad de instalar las herramientas de desarrollo ya que estas son el núcleo de esta distribución y no requiere de afinamientos post instalatórios. Las características de software de los sistemas en donde se desarrollo el montaje de la red mesh especificada en este manual de usuario obedecen a los siguientes:

• Ubuntu Linux 8.04.1, kernel 2.6.24-19, GCC 4.2.3, binutils 2.18.1 • Gentoo Linux 2008.0, kernel 2.6.25-hardened-r5, GCC 4.1.2, binutils 2.18-r3

Existen algunos requerimientos que debe proporcionar el kernel de Linux para que el sistema funcione en su totalidad. Dichos requerimientos hacen referencia a las habilidades que tiene el sistema de filtrado de GNU/Linux para actuar como enrutador y filtrador de paquetes. Algunos de estos módulos son fundamentales ya que proporcionan funcionalidades de vital importancia y sin dichas funcionalidades no es posible asegurar una conectividad entre nodos.

- 81 -

Los módulos que se deben cargar antes de arrancar el demonio de NTK son:

• ipt_REJECT • iptable_filter • ip_tables • ipt_CONNMARK • ipt_conntrack • ipt_MASQUERADE • iptable_nat

Para cargar los módulos se debe ejecutar los siguientes comandos: % sudo modprobe ipt_REJECT % sudo modprobe iptable_filter % sudo modprobe ip_tables % sudo modprobe ipt_CONNMARK % sudo modprobe ipt_conntrack % sudo modprobe ipt_MASQUERADE % sudo modprobe iptable_nat Los módulos se deben cargar con permisos de súper usuario. Esto se logra mediante la utilidad sudo o mediante una consola con permisos suficientes. Si se desea cargar los módulos de manera permanente cada vez que el sistema inicie se puede agregar los módulos en el archivo /etc/modules si se trabaja sobre sistemas basados en Debian GNU/Linux: % sudo vim /etc/modules En este archivo deben ir todos los módulos del kernel que se iniciarán una vez el sistema haya cargado. • Instalación del firmware en los nodos: Existen diferentes maneras de

instalar la imagen funcional que contiene el sistema operativo GNU/Linux junto con las herramientas básicas para manejo de configuración y paquetería de software. A esta colección de herramientas listas para grabar en el dispositivo embebido se le denomina firmware.

El proceso de instalación del firmware es conocido como flashing. Los diferentes métodos dependen de la configuración actual del dispositivo embebido, en este caso el enrutador inalámbrico. Una vez estén solventadas las diferentes dependencias y luego de una verificación de hardware se procede a descargar la imagen del firmware para la

- 82 -

instalación. Para descargar la imagen recomendada para este manual se deberá dirigir al sitio web de desarrollo del proyecto CogitoWireless especificado en la sesión de enlaces. • Mediante MTD: Las MTD (Memory Technology Devices) son memorias flash, RAM y chips similares, utilizados para almacenar sistemas de archivos en dispositivos embebidos. En la configuración del kernel de GNU/Linux por omisión existe una opción que provee soporte genérico para drivers MTD.45 Este método es extremadamente útil si ya se dispone de un sistema GNU/Linux previamente instalado en el enrutador. Los datos de conexión y autenticación serán los mismos del actual sistema vigente. El primer paso es obtener la imagen de firmware en formato TRX y configurar la interfaz de red para poder transferir la imagen al enrutador. La imagen en formato TRX es la imagen cruda del sistema completo sin cabeceras especiales. Generalmente los firmwares de terceros están empaquetados en formato BIN que consiste en una imagen TRX con una cabecera de más en la cual se especifica la versión del enrutador y el modelo. Luego de la configuración de la red local, se procede a enviar la imagen a un directorio temporal que reside en el enrutador mediante scp. Es importante notar que el nombre de usuario por omisión es root y que la dirección IP del enrutador es 192.168.1.1 % scp /home/hollman/Escritorio/cogito_RC.trx root@192.168.1.1:/tmp Se debe especificar la ruta donde se encuentra el firmware en el equipo local seguido del usuario y la estación de destino seguido de dos puntos y la ruta remota a donde se va a copiar el archivo. El sistema solicitará una contraseña para poder autenticar al usuario. Esta contraseña se configura luego de una instalación exitosa mediante telnet. Una vez se complete la transferencia de la imagen, lo siguiente es proceder a instalarlo en la memoria flash del enrutador. Para ello se debe ingresar al enrutador desde una terminal virtual vía SSH y ejecutar el siguiente comando: root@OpenWrt:~# mtd -r write /tmp/cogito_RC.trx linux El programa mtd sobrescribirá la memoria flash del enrutador, específicamente en las particiones donde se aloja el sistema base e instalara la nueva imagen junto 45 http://linuxemb.wikidot.com/diccionario

- 83 -

con sus herramientas y realizara las modificaciones pertinentes. Esta partición esta marca como linux. Una vez finalizado el proceso, el enrutador se reiniciara para cargar la nueva imagen. Este proceso sobrescribe las configuraciones del anterior sistema anfitrión, así que las llaves SSH generadas anteriormente por el enrutador serán inválidas. Es necesario que las llaves SSH almacenadas en el cache sean actualizadas. Para ello, se debe verificar que la huella digital de la llave generada coincida con la entrada en el archivo ~/.ssh/known_hosts. % ssh root@192.168.1.1 The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established. RSA key fingerprint is fe:10:97:34:fb:71:39:f1:d4:fb:35:91:33:f2:6c:af. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.1.1' (RSA) to the list of known hosts. root@192.168.1.1's password: BusyBox v1.4.2 (2008-06-10 07:23:18 CDT) Built-in shell (ash) Enter 'help' for a list of built-in commands. root@OpenWrt:~# Luego de la verificación de las llaves y una autenticación exitosa, el sistema se encuentra a disposición de comandos.

• Mediante TFTP: Otro método para instalar el firmware en los enrutadores es mediante TFTP. Este método es el recomendado para usuarios que buscan instalar imágenes de firmware compiladas a la medida ya este método se puede utilizar para recuperar un sistema mal configurado o para actualizar de sistema. Esto sólo es pertinente en el caso de que algo llegase a pasar con el enrutador; la instalación se interrumpe o la configuración hace que el enrutador se bloquee y permanezca inutilizado. A continuación, puede utilizar TFTP para reinstalar el enrutador con otro firmware. Para este procedimiento se debe tener conectado el enrutador utilizando uno de sus cuatro puertos Ethernet a la tarjeta de red del computador. Una vez este conectado, se procede escribiendo el siguiente comando en una terminal teniendo precaución de no ejecutar el comando de manera inmediata ya que debemos preparar previamente el enrutador para que entre en modo de escucha por TFTP. % atftp --trace --option "timeout 1" --option "mode octet" --put --local-file cogito_RC.bin 192.168.1.1 Luego de ejecutar el comando anterior, se procede a verificar la conectividad con el enrutador mediante la utilidad ping. Para ello, se debe ejecutar la utilidad ping

- 84 -

de manera constante verificando los tiempos de respuesta del enrutador mediante su IP. % ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.75 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.998 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.01 ms Esto es necesario ya que se debe saber en qué momento el enrutador vuelve a responder en la red para poder enviar el firmware por medio de TFTP. Para el siguiente paso es muy importante que se tenga las dos terminales a la vista, un terminal donde esté escrito el comando del atftp y otra terminal donde se pueda ver la respuesta del ping una vez el enrutador vuelva a responder mensajes ICMP. Cuando las terminales estén listas, se procede a suspender la corriente eléctrica del enrutador desconectándolo de la toma corriente hasta que el enrutador deje de responder al ping. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.17 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.03 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.01 ms ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable

El mensaje de error sobre la disponibilidad de la red significa que el enrutador no esta respondiendo. En ese preciso momento se debe conectar el enrutador de nuevo a la toma de corriente hasta el que el dispositivo vuelva a responder. ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.01 ms Tan pronto el enrutador responda se debe ejecutar el comando atftp para poder enviar la imagen del firmware a la memoria temporal del enrutador. En este momento, el enrutador todavía no ha iniciado el sistema. Es el trabajo del gestor de arranque verificar si una nueva imagen es cargada mediante TFTP e instalarla en la memoria flash. Ya que la ventana de tiempo es muy corta, se deben ejecutar los comandos anteriores con precisión.

- 85 -

Para verificar el estado de la reprogramación del enrutador, se puede observar el comportamiento de sus diferentes LEDs mientras el gestor de arranque instala la imagen en la memoria flash. Los enrutadores Linksys cuentan con un LED para la DMZ. OpenWRT prenderá el LED mientras inicia y antes de que el script de inicio finalice se apagara el LED de DMZ. Algunas veces el arranque automático no funciona, por lo tanto se tendrá que hacer de manera manual tras esperar 6 minutos. Este procedimiento es totalmente seguro si la ventana de tiempo de 6 minutos se cumple. No se debe obviar la configuración del firewall en caso de importar una configuración existente ya que es muy común que las reglas de filtrado puedan dejar al enrutador sin conectividad si estas interfieren con la configuración de las interfaces de red. Es mejor ejecutar el comando put del cliente TFTP, e inmediatamente conectar el enrutador a la corriente ya que la ventana de tiempo para subir el archivo es extremadamente corta y solo sucede en las primeras etapas de carga del sistema.

Tabla 28 Posibles errores en el servidor FTP Error TFTP Razón

Code pattern is incorrect

La imagen del firmware que se ha cargado esta diseñadapara un modelo de enrutador diferente. Se debe verificar que la imagen del firmware que se instalara coincida con el modelo del hardware.

Invalid password El firmware ha arrancado y usted se ha conectado a un servidor TFTP protegido por contraseña que esta corriendo en el firmware. El servidor TFTP al que usted se debe conectar no es el que viene por omisión en el firmware sino el que esta embebido en el gestor de arranque del enrutador.

Timeout Hacer ping para verificar si el enrutador esta en línea. Pruebe un cliente TFTP diferente.

Algunas máquinas deshabilitan la conectividad vía Ethernet cuando el enrutador se encuentra apagado y no restablecerá la conectividad hasta que este ha sido encendido por unos pocos segundos. Si se recibe fallas referentes a “Invalid password” (password invalido) se debe intentar conectar el computador junto con el enrutador a un concentrador o switch. Esto mantendrá el enlace arriba y evitará que el computador desactive su interfase mientras el enrutador se encuentre apagado.

- 86 -

Antes de probar con un hub o switch, se debe probar ajustando la configuración TCP/IP estática en vez de una configuración automática mediante DHCP. Para la configuración estática se deben tener en cuenta las siguientes recomendaciones.

Tabla 29 Configuración recomendada Dirección IP 192.168.1.10

Dirección Gateway 192.168.1.1

Netmask 255.255.255.0

• Mediante interfaz Web: Este procedimiento es el indicado es cuando el enrutador viene con el firmware por omisión de fábrica instalado. También es la manera indicada si el equipo es nuevo y no se ha hecho ninguna modificación.

Primero se debe ingresar a un navegador web y en la barra de dirección se ingresa la dirección IP del enrutador. Por lo general, los enrutadores tienen la dirección IP 192.168.1.1 asignada por omisión. Una vez se ingrese al enrutador vía web, este solicitará el usuario y contraseña del firmware. Se debe saber cual es el que se tiene por omisión de fábrica, en caso de ser alguna marca Linksys el usuario y contraseña es admin. Una vez se obtenga acceso a la configuración del enrutador se busca la sección administrativa, pestaña “firmware upgrade” y posteriormente la imagen del firmware en el disco local y se confirma con el botón de upgrade.

- 87 -

Figura 25 Actualización del Firmware en la pestaña Administración

Cuando termina de hacer la actualización la interfaz web se refresca de manera automática mostrando como pantalla inicial la interfaz web que provee el firmware OpenWRT con sus extensiones x-wrt.

Figura 26 Firmware Actualizado

Es importante que se modifiquen algunos parámetros después de la instalación del firmware o de lo contrario se correría el riesgo de que la actualización o modificación de la memoria del enrutador sea mucho mas complicada y requiera de interacción directa con el hardware.

- 88 -

root@OpenWrt:~# nvram set boot_wait=on root@OpenWrt:~# nvram set boot_time=10 root@OpenWrt:~# nvram commit && reboot

Fallar en ejecutar los pasos anteriores puede afectar el comportamiento del cargador de arranque del enrutador deshabilitando muchas de las funcionalidades de instalación vía TFTP. 4.4.1.2. Configuración de nodos. A continuación se explica con detalle todo el proceso de adecuación de nodos para luego ser enlazados en la red mesh parcial a implementar. • Configuración de arranque. Los scripts de arranque del sistema se encuentran en la carpeta /etc/init.d y determinan los servicios que se iniciaran una vez el sistema se encuentre disponible. Estos scripts de inicio proveerá de una manera flexible y sencilla de controlar los programas, demonios y servicios que se necesitan para un óptimo funcionamiento del enrutador. root@OpenWrt:~# ls -alh /etc/init.d drwxr-xr-x 2 root root 308 Jun 18 2008 . drwxr-xr-x 1 root root 0 Jan 1 00:02 .. -rwxr-xr-x 1 root root 1.3k Jun 6 2008 batman -rwxr-xr-x 1 root root 1.4k Jun 6 2008 boot -rwxr-xr-x 1 root root 242 Jun 10 2008 cron -rwxr-xr-x 1 root root 397 Jun 10 2008 custom-user-startup -rwxr-xr-x 1 root root 605 Jun 10 2008 dmesgbackup -rwxr-xr-x 1 root root 5.2k Jun 10 2008 dnsmasq -rwxr-xr-x 1 root root 243 Jun 6 2008 done -rwxr-xr-x 1 root root 1.1k Jun 10 2008 dropbear -rwxr-xr-x 1 root root 3.8k Jun 10 2008 firewall -rwxr-xr-x 1 root root 245 Jun 10 2008 httpd -rwxr-xr-x 1 root root 447 Jun 18 2008 l2tpns -rwxr-xr-x 1 root root 3.8k Jun 6 2008 netconfig -rwxr-xr-x 1 root root 346 Jun 6 2008 network -rwxr-xr-x 1 root root 2.4k Jun 6 2008 ntk -rwxr-xr-x 1 root root 1.8k Jun 10 2008 nvram -rwxr-xr-x 1 root root 121 Jun 6 2008 rcS -rwxr-xr-x 1 root root 123 Jun 6 2008 sysctl -rwxr-xr-x 1 root root 2.0k Jun 18 2008 syslog -rwxr-xr-x 1 root root 297 Jun 10 2008 telnet -rwxr-xr-x 1 root root 380 Jun 10 2008 timezone -rwxr-xr-x 1 root root 99 Jun 6 2008 umount -rwxr-xr-x 1 root root 154 Jun 6 2008 usb -rwxr-xr-x 1 root root 3.6k Jun 18 2008 webif -rwxr-xr-x 1 root root 601 Jun 10 2008 webiffirewalllog -rwxr-xr-x 1 root root 1.6k Jun 18 2008 webifopenvpn -rwxr-xr-x 1 root root 4.6k Jun 10 2008 webifssl root@OpenWrt:~#

- 89 -

Los scripts de vital importancia son los que controlan los servicios de netconfig, ntk, firewall y dropbear respectivamente. Estos servicios son fundamentales para el correcto funcionamiento del sistema ya que controlan los diferentes protocolos y servicios de enrutamiento y reglas de filtrado de paquetes. El filtrado de paquetes es vital ya que no solo filtra toda la información que viaja a través de las diferentes interfaces de red del enrutador sino que también es el subsistema encargado de establecer las diferentes VLANs y dispositivos virtuales junto con su asignación según la interfaz física. • Configuración de Interfaces. La configuración de la interfaz inalámbrica se controla mediante UCI, que es el subsistema encargado de administrar las variables de configuración del firmware. Los valores a modificar son los siguientes. config wifi-device wlan0

option type mac80211 option channel 2 option disabled 0

config wifi-iface

option device wlan0 option mode ad-hoc option ssid CogitoWireless option hidden 0 option encryption none

Una vez alterados los parámetros mediante UCI, se debe reiniciar el servicio de wireless del enrutador mediante /etc/init.d/wireless. • Configuración de networking. La imagen del firmware esta preconfigurado con toda una serie de valores por omisión que son los apropiados para la solución propuesta ya que contemplan todas las variables de configuración posibles para el acople de los nodos en una red ad-hoc utilizando NTK como protocolo de enrutamiento. Sin embargo, estos valores no son estáticos y pueden ser alterados según la necesidad del usuario. Tabla 30 Tabla de direcciones IP asignadas por NTK a los nodos

Nodos IP ID Nivel NodoMesh1 160.21.1.123 123 0 NodoMesh2 160.21.1.23 23 0 NodoMesh3 160.21.1.12 12 0 NodoMesh4 160.21.1.95 95 0

- 90 -

Para poder configurar todos los aspectos de networking se debe utilizar la interfaz de configuración UCI. La configuración pertinente a networking consiste de los siguientes valores: network.eth0=switch network.eth0.vlan0=0 1 2 3 5* network.eth0.vlan1=4 5 network.loopback=interface network.loopback.ifname=lo network.loopback.proto=static network.loopback.ipaddr=127.0.0.1 network.loopback.netmask=255.0.0.0 network.lan=interface network.lan.type=bridge network.lan.ifname=eth0.0 network.lan.proto=static network.lan.ipaddr=192.168.1.1 network.lan.netmask=255.255.255.0 network.wan=interface network.wan.ifname=eth0.1 wireless.cfg2.network=lan Por lo general, los valores anteriores están lo suficientemente estandarizados para proveer una conectividad básica vía alámbrica e inalámbrica. Es de suma importancia aclarar, que el único parámetro que se debe modificar cuando se efectúan implementaciones masivas es la dirección IP de la LAN para instalaciones en masa. La configuración IP no es necesaria una vez el nodo empiece a funcionar en mesh ya que la asignación y actualización de direccionamiento es realizada por el demonio de NTK. Para ello, el comando UCI es el adecuado ya que este se encarga de que la configuración persista sin importar que el sistema se reinicie. root@OpenWrt:~# uci get network.lan.ipaddr 192.168.1.1 root@OpenWrt:~# uci set network.lan.ipaddr=10.0.0.1 root@OpenWrt:~# uci get network.lan.ipaddr 10.0.0.1 root@OpenWrt:~# Para más información acerca de UCI, se recomienda visitar la sesión de enlaces de este manual.

- 91 -

• Configuración de NTK. NTK también se puede configurar mediante UCI en el enrutador. La configuración se divide en tres categorías; general, ANDNA y SNDS. Cada categoría controla opciones independientes que afectan el comportamiento de NTK de manera global. Los siguientes valores son las variables a configurar por un óptimo desempeño de NTK en los enrutadores mediante UCI. config netsukuku general

option interface wlan0 option restricted_mode 0 option restricted_class 0 option internet_connection 0 option internet_gateway 192.168.1.1:eth0 option internet_download_rate 640 option internet_upload_rate 30 option internet_ping_hosts google.com:cisco.com option share_internet 0 option shape_internet 0 option use_shared_internet 0 option max_connections 512 option max_accepts_per_host 16 option max_accepts_per_host_time 4 option pid_file /var/run/ntkd.pid option tc_shaper_script /etc/netsukuku/ip_masquerade.sh

config netsukuku maps

option ext_map_file /usr/share/netsukuku/ext_map option int_map_file /usr/share/netsukuku/int_map option bnode_map_file /usr/share/netsukuku/bnode_map

config netsukuku andna

option disable_andna 1 option disable_resolvconf 1 option andna_cache_file /etc/netsukuku/andna_cache option andna_lclkey_file

/etc/netsukuku/andna_lcl_keyring option andna_rhc_file /etc/netsukuku/andna_rhc_cache option andna_counter_c_file

/etc/netsukuku/andna_counter_cache config netsukuku snsd

option snsd_nodes_file /etc/netsukuku/snsd_nodes

- 92 -

4.4.1.3 Adecuación de estaciones de trabajo. Existen dos maneras de conseguir la suite de protocolos de NTK. La manera recomendada es descargar los binarios precompilados del sitio oficial de NTK (ver enlaces) y descomprimirlo en sus respectivas rutas.

Binario precompilado. Para descargar el paquete de manera directa del sitio web: % wget http://netsukuku.freaknet.org/packages/netsukuku-0.0.8b-i486-9.tgz Luego de terminar la descarga, la forma correcta de descomprimir el paquete es: % mkdir ./netsukuku-bin % gzip -d netsukuku-0.0.8b-i486-9.tgz && tar xvf netsukuku-0.0.8b-i486-9.tar -C ./netsukuku-bin Los binarios deben ir en /usr/local/bin y las paginas man deben ir en /usr/local/share/man. Los archivos de configuración deben ir en /etc/netsukuku. % cp -R ~/netsukuku-bin/usr/share/man/* /usr/local/share/man % cp -R ~/netsukuku-bin/usr/bin/* /usr/local/bin % cp -R ~/netsukuku-bin/etc/* /etc/netsukuku/ Una vez copiados los archivos a sus respectivas rutas, se procede a configurar el demonio vía el archivo de configuración. • Configuración de Arranque. Algunos de estos módulos son fundamentales ya que proporcionan funcionalidades de vital importancia y sin dichas funcionalidades no es posible asegurar una conectividad entre nodos. Los módulos que se deben cargar antes de arrancar el demonio de NTK son:

• ipt_REJECT • iptable_filter • ip_tables • ipt_CONNMARK • ipt_conntrack • ipt_MASQUERADE • iptable_nat

Para cargar los módulos se debe ejecutar los siguientes comandos:

- 93 -

% sudo modprobe ipt_REJECT % sudo modprobe iptable_filter % sudo modprobe ip_tables % sudo modprobe ipt_CONNMARK % sudo modprobe ipt_conntrack % sudo modprobe ipt_MASQUERADE % sudo modprobe iptable_nat Los módulos se deben cargar con permisos de súper usuario. Esto se logra mediante la utilidad sudo o mediante una consola con permisos suficientes. Si se desea cargar los módulos de manera permanente cada vez que el sistema inicie se puede agregar los módulos en el archivo /etc/modules si se trabaja sobre sistemas basados en Debian GNU/Linux: % sudo vim /etc/modules En este archivo deben ir todos los módulos del kernel que se iniciarán una vez el sistema haya cargado. Es importante tener en cuenta la configuración del firewall local del equipo. La suite de filtrado de paquetes de GNU/Linux se llama netfilter, y su interfaz con el usuario se llama iptables. La configuración de iptables es fundamental ya que es la encargada de redirigir paquetes según reglas predefinidas y mantener las conexiones según se desee. Esto es vital para algunas de las funcionalidades de NTK y demás protocolos y servicios de red, pero también es indispensable para la comunicación del radar de UDP que escucha por peticiones de nuevos nodos, nuevas rutas disponibles para el enrutamiento del tráfico y demás. Para verificar el estado actual de la lista de reglas de iptables se debe ejecutar el siguiente comando: % sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination

- 94 -

Esta es la salida por omisión que debe mostrar su terminal. Actualmente no existe ninguna regla de redirección de tráfico ya que no se necesita la conectividad a Internet. Además, dichas interconexiones son realizadas en los enrutadores y equipos dedicados a internetworking. • Configuración de Interfaces. Existen diferentes implementaciones de drivers y stack de protocolos de 802.11 para GNU/Linux. Para efectos de compatibilidad los recomendados para este manual están especificados en la sesión de “Requisitos de hardware”. Antes de iniciar el demonio de NTK se debe configurar las tarjetas de red inalámbrica en modo ad-hoc y especificar el identificador de la red vía ESSID junto con el canal a utilizar. Existen diferentes métodos de implementar dicha configuración, pero ya que la forma de configuración depende de la tarjeta de red inalámbrica y los drivers que se utilicen, no es posible disponer de un método unificado en su totalidad para facilitar dicha configuración. Sin embargo, la sintaxis es sencilla. A continuación se muestra un ejemplo de configuración utilizando una tarjeta inalámbrica con chipset Atheros utilizando los drivers madwifi-ng. % sudo wlanconfig ath0 destroy % sudo wlanconfig ath0 create wlandev wifi0 wlanmode adhoc % sudo iwconfig ath0 channel 2 essid cogito Las tarjetas inalámbricas que se basan en el nuevo stack mac80211 de Linux se pueden configurar de la siguiente manera: % ifconfig wlan0 down % iwconfig wlan0 mode ad-hoc essid cogito channel 2 % ifconfig wlan0 up • Configuración de networking. Antes de ejecutar el demonio de NTK, se debe asegurar de que no exista actualmente ningún otro servicio que interfiera con el dispositivo inalámbrico que se utilizara en la conexión. Verifique por la existencia de servicios como DHCP u algún otro que interactué con la interfaz de red ya que esto hará que el enlace inalámbrico se rompa luego de un tiempo de operación.

- 95 -

Tabla 31 Tabla de direcciones IP asignadas por NTK a los clientes Clientes IP ID Nivel

ClienteMesh1 160.21.1.56 56 0 ClienteMesh2 160.21.1.69 69 0 ClienteMesh3 160.21.1.39 39 0 ClienteMesh4 160.21.1.9 9 0 ClienteMesh5 160.21.1.245 245 0

• Configuración de NTK. Luego de asegurar que todos los programas y dependencias han sido instaladas de manera satisfactoria, se procede con la configuración de NTK. Configuración de archivos de configuración NTK: % vim /etc/netsukuku/netsukuku.conf Se debe asegurar que las siguientes opciones se encuentren como se muestra a continuación o de lo contrario no funcionará el protocolo de enrutamiento. ntk_restricted_mode = 0 ntk_restricted_class = 0 internet_connection = 0 disable_andna = 0 disable_resolvconf = 0 pid_file = /var/run/ntkd.pid Esta configuración permite tener conectividad entre nodos independiente de Internet. También controlan el uso de direcciones IP que se asignaran de manera automática a las interfaces que se utiliza para los enlaces inalámbricos. Para configurar los nombres de dominio que tendrán los nodos se debe especificar en el archivo /etc/netsukuku/andna_hostnames. En caso de asignar más de un nombre por nodo, se especifica el nombre línea por línea. La longitud de los nombres no debe exceder de los 512 caracteres y puede contener cualquier carácter unicode. % vim /etc/netsukuku/andna_hostnames El nombre puede tener el siguiente formato, aunque la implementación del esquema de nombres es de libre elección. saboteur.cogito.nodo saboteur.cogito.ftp saboteur.cogito.web saboteur.cogito.irc

- 96 -

laptop.saboteur.cogitowireless.staff Luego de haber configurado lo pertinente a conectividad y configuración de NTK, se procede con ejecutar el demonio que enlazara los nodos que encuentre disponibles en el mismo canal (frecuencia) y ESSID de la red ad-hoc. % /usr/local/bin/ntkd -i wlan0 -dddddd -D # Internal map loaded # External map loaded + Setting the 10.0.0.232 ip to all the interfaces # Activating ip_forward and disabling rp_filter # Activating all daemons # Evoking the netsukuku udp daemon. # Preparing the udp listening socket on port 269 # Udp daemon on port 269 up & running # Evoking the netsukuku udp radar daemon. # Preparing the udp listening socket on port 271 # Udp daemon on port 271 up & running # Evoking the netsukuku tcp daemon. # Preparing the tcp listening socket on port 269 # Tcp daemon on port 269 up & running + The hook begins. Starting to scan the area + Launching radar_scan 1 of 1 # Radar scan 0x306b2faf activated + No nodes found! This is a black zone. Creating a new_gnode. + Setting the 160.21.1.123 ip to all the interfaces + Now we are in a brand new gnode. The ip 160.21.1.9 is now used. + Starting the second radar scan before sending our first tracer_pkt + Filling the kernel routing table + Hook completed # Evoking radar daemon. # Radar daemon up & running 4.4.2. Montaje de los equipos de comunicación. Antes de la montura de los nodos se debe tener en cuenta algunas recomendaciones para garantizar un óptimo enlace y rendimiento entre los puntos de acceso. Incremento de potencia: Gracias la facilidad de manipulación de los enrutadores desde el firmware, se realizaron algunos incrementos de potencia en las antenas, esta práctica permite cumplir satisfactoriamente los enlaces entre nodo y nodo, sin embargo no es recomendable subir el máximo de potencia soportada en enlaces con antenas omnidireccionales, debido a que estas reciben ruido en todas las

- 97 -

direcciones y aumenta el ruido en el enlace y a los demás usuarios que comparten la banda. Amplificadores: Se estudió la posibilidad de implementar amplificadores para un mayor aumento de potencia en las antenas, pero fue descartada cuando se realizó el incremento de potencia en los routers, además como es recomendado en el libro de redes inalámbricas en los países en desarrollo, no es recomendable debido a que generan mucha interferencia con las demás redes de la banda y ruido en los enlaces. El mejor canal disponible: Se debe realizar una prospección del sitio donde se implementará la red, con el fin de implementar uno de los 14 canales disponibles con menos interferencia, ya que en el estándar 802,11b/g los canales tiene un ancho de 22MHz, separados por 5MHz. Lo cual nos indica que se sobreponen algunos de los canales disponibles. 4.4.2.1 Instalación de nodos • NodoMesh1: Este Nodo no fue instalado por nosotros, debido a que ya se encontraba montado por Fredy Pulido, uno de los integrantes del proyecto CogitoWireless, el nodo se encuentra ubicado en el soporte del tejado de la casa en un tercer piso, el nodo costa de un enrutador Linksys WRT54gl v1.1, una antena omnidireccional de 7dbi y otra de 5dbi, está instalada en una caja certificada NEMA para intemperie. Este nodo de esta alimentando eléctricamente por cable Ethernet vía PoE46. • NodoMesh2: Nodo instalado en el soporte del tejado de la casa de un participante en un tercer piso, se monto con la facilidad de la participación de un habitante del barrio La Florida. Este nodo consta de una caja para exteriores certificada NEMA, un enrutador Linksys WRT54gl v1.1, una antena omnidireccional de 5 dBi y otra de 7dBi, actualmente se encuentra alimentado eléctricamente gracias a la tecnología PoE.

o Notas de montaje: Para la instalación de este nodo fue necesario contar con taladro y broca de ¼ de pulgada para abrir los orificios en el soporte en cemento del tejado donde se anclo la caja para exteriores con el enrutador; chazos y tornillos de ¼ de pulgada para lograr ajustar la caja a la pared. A la caja fue necesario abrirle 2 orificios para lograr sacar al exterior las antenas omnidireccionales. Una vez hecho esto se ajusto la caja para exteriores a la pared del soporte del tejado y finalmente se aplico silicona fría para cellar los orificios de acceso a el exterior de las antenas de el enrutador que

46 Tecnología que permite la alimentación eléctrica de dispositivos de red a través de un cable UTP en una red - http://es.wikipedia.org/wiki/PoE

- 98 -

posteriormente se ingresó en la caja, garantizando que no exista filtración del agua.

• NodoMesh3: Nodo instalado en último balcón de un edificio de 5 pisos, ubicado en el apartamento de un habitante de la comunidad de La Florida, este nodo consta de un enrutador Linksys WRT54gl ver 1.1, dos antenas omnidireccionales, una Qpcom QP-AO24015 de 15 dBi, y otra de 5dbi, una caja para exteriores certificada NEMA, un pigtail con cable LMR 200 para lograr la conexión del enrutador a la antena.

o Notas de montaje: Para montar este nodo fue necesario mandar a construir un soporte para la antena, debido a que esta antena se iba a instalar contra la pared de un balcón en cemento y los soportes con los que viene de fábrica, no permitían empotrar esta antena a el, este soporte se mando a hacer con material metálico con abrazadera alrededor de la antena para lograr que la sujete fijamente. Se necesito taladro y broca de ½ pulgada, chazos de expansión de ½ pulgada para ajustar la antena fijamente a la pared y garantizar que no se caiga. Adicional de la broca y los chazos de ½ pulgada también se necesitaron de ¼ de pulgada para ajustar la caja para intemperie con el enrutador; a esta caja se tuvieron que abrir dos orificios, tanto para lograr sacar a el exterior la antena de 5 dBi como el cable del pigtail que conecta el router a la antena y finalmente se aplico silicona fría alrededor de los orificios hechos para garantizar que no exista filtración de agua.

• NodoMesh4: Nodo instalado en la azotea de un edificio de 7 pisos sobre un mástil que se ya encontraba instalado, este nodo se ha montado gracias a la colaboración de otro de los integrantes del proyecto CogitoWireless, consta de un enrutador Linksys WRT54gl ver 1.1, una antena panel Hyperlink HG2414P de 14 dBi implementada para lograr establecer el enlace con los otros 3 nodos que se encuentran en malla, y otra antena omnidireccional de 5dbi implementada para brindar acceso a el sector de ubicación del nodo de aproximados 30 m, un pigtail con cable LMR200 y una caja para exteriores certificada NEMA. Este nodo se encuentra alimentado eléctricamente por PoE.

o Notas de Montaje: Notas de montaje: Para lograr la instalación de este nodo fue necesario construir el soporte de la antena panel, debido a que esta antena no contaba con el soporte de fabrica, además de que se iba a montar sobre un mástil que ya existía sobre la azotea del edificio, dicho soporte se realizó en el hangar de la Universidad de San Buenaventura en colaboración de Ferney, este soporte se construyo con lamina metálica con las medidas precisas para que ajustara en el

- 99 -

mástil y recubierta con pintura inoxidable para evitar la corrección con el agua. Para la sujeción de la caja para intemperie con el enrutador se tuvo que comprar abrazaderas metalizas que nos permitieron ajustar firmemente la caja con el router a el mismo mástil donde se ha instalado la antena, a esta caja se le tuvieron que abrir 2 orificios para lograr sacar a la superficie la antena de 5dbi y el cable del pigtail para poder conectar la antena a él enrutador.

Figura 27 Instalación de los nodos de la red

4.4.2.2. Montaje Servidores A continuación se explicará detalladamente la instalación de cada uno de los servidores que serán implementados en la red mesh. • HTTP. Se ha implementado Apache como servidor Web por su estabilidad, robustez, licencia libre, facilidad de instalación y configuración, gracias a este servidor se prestar el servicio Wiki el cual consiste en páginas Web que pueden ser creadas, borradas y editadas por cualquier usuario de la red, de esta manera permitir que cada usuario pueda enlazar a nuevos servidores y/o subir sus contenidos.

- 100 -

Dicho servidor se ha instalado en el siguiente computador:

Sistema Operativo GNU/Linux Ubuntu 8.04.1

Kernel 2.6.24-19-generic

Memoria DDR 1Gb

Disco Duro 80 Gb SATA

Tarjeta inalámbrica Atheros AR242x

Procesador Intel Celeron 900 MHz A continuación se ilustra el procedimiento de instalación y configuración tanto del servidor apache como de la wiki en GNU/Linux Ubuntu 8.04.1 • Instalación Apache: Es sistemas Debian/Ubuntu y derivados desde la terminal se ejecuta el siguiente comando para la descarga y configuración del servidor apache: hollman@saboteur:~$ sudo apt-get install apache2 Se debe esperar mientras el gestor de paquetes apt descarga e instala el servidor apache2 y algunas de las dependencias necesarias para el correcto funcionamiento, una vez el sistema haya terminado el procedimiento, se podrá probar ingresando en el navegador de Internet en la ruta de direcciones http://localhost/ si el navegador visualiza el mensaje (It works!!!) es porque ya se cuenta con el servidor apache ejecutándose. • Instalación sistema de Wiki. DokuWiki es un gestor de paginas tipo wiki colaborativas, distribuido en código abierto bajo la licencia libre GPL, este software está enfocado para grupos de personas que trabajan en conjunto, una de las ventajas de DokuWiki es que la información no se almacena en bases de datos convencionales sino en un archivo de texto plano, permitiéndonos su fácil instalación y manipulación en los futuros usuarios de la red. En sistemas Debian/Ubuntu y derivados desde la terminal se ejecuta el siguiente comando para la descarga y configuración de DokuWiki: hollman@saboteur:~$ sudo apt-get install dokuwiki Se debe esperar un tiempo mientras el gestor de paquetes descarga DokuWiki y posteriormente el sistema preguntará la confirmación de algunos parámetros de configuración como vemos a continuación:

- 101 -

Figura 28 Confirmación de directorio de acceso a la wiki

En este primer paso de confirmación se ingresa el directorio que deseamos para poder acceder a la wiki, en caso de que se desee acceder de forma local se debe ingresar al navegador web http://localhost/dokuwiki. Si se desea ingresar desde cualquier otro equipo de la red, se debe ingresar el nombre de dominio del servidor como por ejemplo: http://saboteur.cogito.nodo/dokuwiki Figura 29 Selección de servidor web para instalar dokuwiki

Se procede seleccionando el o los servidores donde se desea que se instale y configure la wiki, en este caso se debe seleccionar apache2, puesto que es el que se ha instalado anteriormente.

- 102 -

Figura 30 Control de acceso dokuwiki

Posterior a la selección de los servidores web de instalación se procede con la configuración de control de acceso donde se requiere seleccionar global para que esté a disposición tanto de manera local como en toda la red.

Figura 31 Confirmación de purga de la base de datos

Finalmente se confirma si se desea que se elimine la base de datos al eliminar el paquete de DokuWiki almacenada por omisión en /var/lib/dokuwiki. Con esta ultima confirmación se termina la configuración de DokuWiki, para probar que todo ha quedado bien instalado y configurado es necesario ingresar a el navegador de Internet, ingresando la dirección http://localhost/dokuwiki. Se obtendrá algo como lo siguiente:

- 103 -

Figura 32 DokuWiki

• FTP. Se ha instalado VSFTP como servidor FTP por la facilidad de instalación, configuración y licenciamiento libre, este servidor se ha montado con el fin de compartir los diferentes tipos de archivos libres que queramos, dentro de este servidor se ha categorizado el contenido por música, OS (sistemas operativos), fotografía y literatura para su fácil navegación. Este servidor se ha montado en el mismo servidor web (Apache). • Instalación. Es sistemas Debian/Ubuntu y derivados, desde la terminal se ejecuta el siguiente comando para la descarga y configuración del servidor ftp, que en este caso es vsftp: hollman@saboteur:$ sudo apt-get install vsftpd Se debe esperar mientras el gestor de paquetes apt descarga e instala el paquete de vsftpd y algunas de sus dependencias necesarias para su correcto funcionamiento. Una vez el sistema halla terminado el procedimiento se podrá probar su correcto funcionamiento ingresando en el navegador web ftp://localhost .Si el navegador visualiza Index of ftp://localhost/ es por que ya se cuenta con el servidor FTP ejecutándose. Ahora es necesario ajustar algunos parámetros de configuración del vsftpd, para ello desde una terminal se ejecuta: hollman@saboteur:~$ sudo vim /etc/vsftpd.conf Y se deben cambiar las siguientes variables: # Si se desea permitir el acceso a usuarios anónimos

- 104 -

anonymous_enable=YES # Si se desea que se pueda escribir sobre el servidor nuevos archivos write_enable=YES Para finalizar solo se debe subir el contenido que se desea compartir con todos los usuarios de la red moviéndolos a el directorio /home/ftp. Una vez se hayan realizado los cambios y movido los archivos a compartir, es necesario reiniciar el demonio vsftp para que los cambios surjan efecto, así que desde una terminal: hollman@saboteur:~$ sudo /etc/init.d/vsftpd restart • Icecast. Se ha instalado un servidor Icecast para contar con la oportunidad de un canal de vídeo dentro de la red. Este servidor se ha montado en la red solo para una prueba de funcionamiento y se ha publicado la guía de ejecución dentro de la wiki para que los interesados puedan transmitir audio o vídeo dentro de la red.

Dicho servidor se ha instalado en el siguiente equipo:

Sistema Operativo GNU/Linux Debian Etch Kernel 2.6.24-19-generic Memoria DDR2 2Gb Disco Duro 120 Gb SATA Tarjeta inalámbrica Intel Pro/Wireless 3945 Procesador Intel Core Duo 2.0Ghz Cámara Web v4l

• Instalación. Se descarga mediante el gestor de paquetes apt tanto el Icecast como algunas librerías necesarias. digitalfredy@laptop:~$sudo apt-get install ffmpeg2theora oggfwd dvgrab icecast2 Una vez el sistema termine de descargar los paquetes es necesario configurar algunos parámetros del servidor, para ellos se modifica el archivo /etc/icecast2/icecast.xml

- 105 -

Algunos de los más importantes y necesarios se citan a continuación: # Número máximo de usuarios conectados al tiempo <clients>10</clients> # Número máximo de fuentes conectas al server <sources>1</sources> # Contraseña que se le pide a la fuente <source-password>hackme</source-password>

# Nombre del administrador <admin-user>admin</admin-user> # Contraseña del administrador <admin-password>hackme</admin-password>

# IP o dominio <hostname>fredy.cogito.nodo</hostname> • Servidor de mensajería instantánea. Se ha implementado un servidor IRC por su fácil instalación, configuración, robustez y libre licencia para que todos los usuarios de la red puedan ingresar a los diferentes canales de chat, igualmente todos los clientes cuentan con privilegios para crear salas y se puedan conectar libremente en los diferentes canales creados por los mismos. • Instalación. En sistemas Debian/Ubuntu y derivados ejecutamos desde una terminal el siguiente comando para descargarlo e instalarlo. % sudo apt-get install ircd-hybrid Una vez se halla terminado de descargar el paquete es necesario configurar algunos parámetros de configuración para que posterior a ello se pueda lanzar el demonio, para esto debemos editar el archivo de configuración ircd-hybrid que se encuentra en /etc/ircd-hybrid/ircd.conf Dentro de los cambios que se deben realizar están los siguientes: # Descripción del servidor description = "Canal General Cogito"; # Nombre de la Red network_name = "CogitoWireless";

- 106 -

# Descripción de la red network_desc = "Canal IRC Cogito"; # IP o nombre de dominio del servidor host = "arpunk.cogito.nodo"; Cuando se realicen los cambios necesarios es necesario reiniciar el demonio para que los cambios tomen efecto, lo anterior lo hacemos desde una terminal ejecutando el siguiente comando % sudo /etc/init.d/ircd-hybrid restart Cuando se reinicie el demonio ya contaremos con el servidor IRC dentro de la red. 4.5. VALIDACIÓN DE LA RED MESH Una de las mejores maneras de verificar la conectividad entre diferentes puntos es mediante el uso de la herramienta ping junto con la lista de estaciones a probar. NTK no incorpora herramientas nativas para realizar pruebas de comportamiento ni de desempeño, así que las herramientas de depuración de red a utilizar son:

• wireshark • tcpdump • ping • scapy • hping3

Se debe tener a la mano una lista correspondiente de estaciones y direcciones IP para su fácil verificación. Dicha lista se puede obtener utilizando la herramienta ntk-resolv incluida en la suite de NTK. También es importante tener a la mano la tabla de enrutamiento actual del kernel. Esto se logra mediante el comando route disponible por omisión en todas las distribuciones de GNU/Linux. La grafica a continuación muestra los cuatro nodos principales y los nodos secundarios que se componen de equipos portátiles y demás dispositivos inalámbricos 803.11 compatibles con GNU/Linux que se utilizaron para realizar las pruebas.

- 107 -

Figura 33 Enlaces realizados para las pruebas de stress

Las diferentes visitas de campo también hacen parte de las herramientas y técnicas para poder obtener información acerca de la distribución geográfica de los nodos. Esta técnica también es muy valiosa ya que permite el descubrimiento de diferentes alternativas donde no exista línea de vista (NLOS). 4.5.1 Rendimiento de los nodos. Los diferentes nodos que hacen parte del prototipo funcional de la red mesh fueron monitoreados de manera constante para poder detectar en tiempo real los momentos en los cuales el procesador de los nodos estuviera ocupado y en qué porcentaje. El monitoreo de los procesadores tuvo una duración de dos días. A continuación se presentan los resultados.

- 108 -

Figura 34 Monitoreo de procesadores

El sistema no presentó ninguna utilización drástica de la CPU de los nodos durante la transmisión de datos. Esto indica que las operaciones de cómputo necesarias para mantener las tablas de enrutamiento y redirigir el tráfico entre diferentes nodos no impactan de manera drástica los recursos de CPU de los nodos. Luego de 16 horas se observa lo siguiente.

Figura 35 Utilización de la CPU después de 16 horas

Luego de 16 horas de monitoreo se puede observar que se tuvo un pico alto durante algunos segundos. Ese pico corresponde a la actividad del sistema núcleo, que en este caso corresponde al núcleo de Linux. Se dejó de analizar el

- 109 -

estado de los procesadores de los nodos luego de dos días de monitoreo. A continuación se muestra el consolidado de los dos días de muestreo. Figura 36 Procesadores después de 2 días

4.5.2 Pruebas de disponibilidad de servicio. Se realizó un barrido por toda la subnet utilizando la herramienta de generación de tráfico scapy en donde se encontraba el gnode del barrio la Florida con los siguientes resultados: >>> ans,unans = sr(IP(dst=["160.21.1.1/24"])/TCP(dport=[21,22,80,6667,8000],flags="S")) Begin emission: .....................................................................................................................................*.................*..............................................................*.....................................***........................................***..........................................................**.*....*....*..................**.*............*.**.........*.*............*.........................................*....*....................***.......*......................*........*.....***....*......*.............*.**......................***.**.*....*.**...........***.....*.................................*******...........*.***................................................****...............................****....................*..***..........................................****.............................*.**..........................................................*.....................................*...******.*.*..*.......................................****..............

- 110 -

............*.......*....*.......................***..............*...............................................*.......................*.*.................................................Finished to send 4096 packets. >>> ans.filter(lambda (s,r):TCP in r and r[TCP].flags&2).make_table(lambda (s,r): (s.dst, s.dport, "X")) 160.21.1.123 160.21.1.23 160.21.1.12 160.21.1.95 21 X - - - 22 X X X X 80 X - - - 6667 - - X - 8000 - - X - >>> 4.5.3 Pruebas de Cambios de Estados. Otro factor importante para la realización de las pruebas fueron los cambios de estados de los paquetes. Para poder verificar dichos cambios se realizaron algunas configuraciones base en el sistema de filtrado de paquetes y se catalogaron los diferentes estados de los paquetes según su destino. Dichos destinos se asignaron de manera genérica teniendo en cuenta el estado actual de los métodos de categorización de tráfico en una red LAN convencional. Figura 37 Cambios de estados en los paquetes después de 4 horas

Los diferentes estados se explican a continuación:

- 111 -

• System-pfrate: estado que hace referencia a la tasa de transferencia en las tablas internas de filtrado.

• System-pfstates: estado que hace referencia a los cambios de contexto en las tablas internas de filtrado.

• System-srcip: estado que hace referencia a las direcciones IP de origen entrantes en el cambio de contexto de las tablas internas de filtrado.

• System-dstip: estado que hace referencia a las direcciones IP de destino entrantes en el cambio de contexto de las tablas internas de filtrado.

En la gráfica anterior se muestra el cambio de estados y el número de ciclos por Segundo, que determina el total de cada estado que ha sido procesado por la CPU.

Figura 38 Cambios de estados en los paquetes después de 16 horas

Luego de 16 horas se puede observar que hubo un pico de actividad relativamente alto referente a los estados de filtrado de direcciones IP de destino. Este pico fue relacionado con algunas aplicaciones que usaron el servicio de DNS de manera constante. Se determinó que la causa era una instancia de Mozilla Firefox que seguía ejecutándose en segundo plano. Luego de 2 días, los resultados fueron los siguientes.

- 112 -

Figura 39 Cambios de estados en los paquetes después de 2 días

Gracias a que se determino la causa del salto de los estados de IP de destino, IP origen y NAT, se logró desactivar los servicios que utilizaban recursos tradicionales como DNS y se hizo la anotación en el manual correspondiente. 4.5.4 Pruebas de Envio y Recibo de Paquetes. Otro de los factores clave para la realización de las pruebas fueron el número de paquetes enviados y recibidos por la interfaz de red. Estos determinan la relación entre el tráfico saliente y entrante, ayudando a resolver problemas de pérdida de paquetes según el estado de la conexión. Luego de 4 horas de análisis de tráfico se obtuvo lo siguiente. Figura 40 Paquetes enviados y recibidos por la interfaz Web después de 4 horas

- 113 -

Según la captura de tráfico se pudo observar que la relación entre los paquetes entrantes y salientes corresponden a las trasmisiones de datos y su confirmación, a excepción del trafico capturado entre las 8:00pm y 9:20pm. Durante dicho lapso de tiempo se sufrió una gran pérdida de paquetes debido a fallas en uno de los enlaces. El problema radicó en que en el NodoMesh2 se había configurado de manera errónea el puente entre la interfaz WAN y la interfaz LAN, causando retransmisiones de tipo multidifusión.

Figura 41 Paquetes enviados y recibidos por la interfaz Web después de 16 horas

Luego de 16 horas de monitoreo, se sufrió de las mismas retransmisiones por parte de un cliente conectado a la red. El causante fue el ClienteMesh3 que sufría de los mismos síntomas del NodoMesh2. Una vez desactivados los programas en ejecución en segundo plano y luego de dos días de monitoreo se obtuvo lo siguiente.

- 114 -

Figura 42 Paquetes enviados y recibidos por la interfaz Web después de 2 días

4.5.5 Pruebas de Tráfico de Servicios Combinados. Para las pruebas de tráfico también se pusieron en marcha los diferentes servicios implementados en el prototipo de red funcional para luego acceder a estos servicios de manera corriente y así poder medir la actividad en tráfico dentro de la red. Los servicios combinados de FTP, streaming y HTTP generaron el siguiente tráfico con un total de 4 clientes conectados de manera simultánea. Figura 43 Tráfico de servicios combinados después de 4 horas

El servicio que más demandó ancho de banda fue el envío de archivos FTP, ya que los clientes que utilizaron este servicio empezaron la descarga del archivo de manera inmediata mientras que el servicio de streaming almacenaba en buffer los

- 115 -

datos para mantener una utilización baja pero constante del ancho de banda disponible. También hay que tener en cuenta que no se utilizaron los codecs de audio de mayor calidad.

Figura 44 Tráfico de servicios combinados después de 16 horas

Luego de 16 horas de monitoreo, se repitió la prueba de descarga de FTP para verificar la disponibilidad del ancho de banda entre los extremos de la red. Sorprendentemente la prueba de tráfico volvió a generar los mismos resultados y el mismo consumo de ancho de banda. Esto significa que no importó la degradación del servicio de conectividad inalámbrica inherente en 802.11, se tuvo el mismo rendimiento que el obtenido en la prueba anterior. Figura 45 Tráfico de servicios combinados después de 2 días

- 116 -

Este es el resultado de la captura de tráfico en la LAN luego de dos días de monitoreo. Los diferentes picos de tráfico reflejan el consumo de ancho de banda y el total de kilobytes enviados y recibidos por la interfaz de red utilizando FTP y HTTP. 4.5.6 Pruebas de Latencia. Y como última prueba se tuvo en cuenta el monitoreo de paquetes para determinar la latencia en la red. La latencia es fundamental cuando se está implementando un servidor Icecast, ya que esta es la que determina la calidad del servicio y la experiencia del usuario final al utilizar este tipo de servicios. La latencia se analizó de la misma manera que las pruebas anteriores. Las primeras 4 horas, la latencia se comporto de la siguiente manera. Figura 46 Latencia después de 4 horas

La latencia ideal es aquella menor a los 20ms, y es la latencia que generalmente se encuentra en ambientes LAN alámbricos. Sin embargo, gracias a la falta de conectividad física guiada de las redes inalámbricas, existen momentos en donde la latencia puede exceder los 420ms. Esta latencia ocurre por diversos motivos, sin embargo en la grafica anterior la latencia ocurrió por la desconexión de uno de los nodos de la red.

- 117 -

Figura 47 Latencia después de 16 horas

Se pudo observar que el nivel de latencia de la red tuvo picos altos por algunas desconexiones de los nodos y por la naturaleza inalámbrica de la red. Sin embargo, el 86% del tiempo medido (16 horas máximo) la latencia fue menor a los 30ms, lo cual es aceptable para el estándar 802.11 en modo IBSS ya que este modo de infraestructura reduce el ancho de banda a la mitad. 4.5.7 Pruebas de Entrada y Salida de Bits. Como último ítem en las pruebas, se analizó el rendimiento del número de bits que entran y salen de las interfaces. Este ítem tuvo un comportamiento muy similar ya que por lo general el mismo número de bits que entraron fueron los mismos que se difundieron por la red.

Figura 48 Entrada y salida de bits después de 4 horas

- 118 -

También se diagnosticó el rendimiento luego de probar los diferentes servicios de red. Figura 49 Entrada y salida de bits sobre los servicios después de 16 horas

Luego de 16 horas se puede observar que el mismo número de bits que entran por lo general es el mismo número de salida. El último muestreo indica que el patrón no cambia con el tiempo. Figura 50 Entrada y salida de bits sobre los servicios después de 2 días

- 119 -

4.5.8 Calidad de servicio perceptual. Las encuestas realizadas para valorar la calidad de servicio de los diferentes servidores a través de la red mesh tuvieron lugar en dos lugares diferentes de la red el día 27 de Septiembre del 2008. El ClienteMesh5 tuvo alrededor de 7 personas observando el proceso. El ClienteMesh3 tuvo alrededor de 4 personas observando la ejecución de los servicios y lo que estos ofrecían y otras cuatro personas estaban ubicadas en el NodoMesh2. Esto da un total de 15 personas encuestadas. Una vez finalizadas las pruebas, se solicitó a los participantes llenar un formulario de calificación del estado de los servicios. Los resultados de las encuestas se pueden observar en el anexo C.

- 120 -

5 CONCLUSIONES

• Los requerimientos técnicos necesarios para la implementación del prototipo funcional de la red mesh fueron analizados utilizando diferentes métricas para evaluar su viabilidad técnica y comercial. Todos los enrutadores y el software seleccionado fueron embebidos logrando cumplir con las metas propuestas para el empaquetamiento de los protocolos y herramientas necesarias para el enlace de los enrutadores con los clientes de prueba.

• Otro factor fundamental en la construcción de la red piloto fue la disponibilidad

local de todo el hardware utilizado. Aunque construir antenas para transmisión de datos en 802.11 es posible utilizando materiales de muy bajo presupuesto, la disponibilidad local de las antenas y los enrutadores utilizados en la implementación fue el enfoque que tuvo el proyecto. Se puede concluir que el acceso al hardware necesario para la construcción de redes inalámbricas de características similares es viable y se puede obtener en el mercado local. El prototipo de red mesh fue diseñado según los requerimientos técnicos que proporciona NTK y la modalidad de infraestructura IBSS, logrando así una comunicación entre los diferentes nodos y clientes.

• La configuración y adecuación de los nodos se logró en su totalidad, dando

como frutos de dicho esfuerzo un proyecto voluntario enfocado en la manutención de dichas personalizaciones bajo el cargo de algunos desarrolladores pertenecientes al proyecto CogitoWireless. Todas las modificaciones que se realizaron se encuentran disponibles en la sesión de anexos junto con su respectiva licencia.

• La interconexión de los nodos y su estabilidad en la prestación de los servicios

de enrutamiento e interconectividad física no han mostrado una degradación del servicio y se ha verificado de manera satisfactoria la inclusión de nuevos clientes a la red mesh y su interoperabilidad con los servicios ofrecidos. Se puede concluir que la integración del firmware y NTK funciona de manera eficiente junto con el hardware seleccionado

• Los resultados obtenidos durante la implementación del diseño de la red piloto

han demostrado que el funcionamiento de la red mesh ofrece un rendimiento operativo óptimo y sus servicios no han mostrado hasta el momento ningún tipo de error de funcionamiento que pueda deteriorar la calidad de servicio. Una vez verificado los resultados de las pruebas de funcionamiento de los diferentes servicios implementados se llega a la conclusión de que la selección de servidores fue la más adecuada y cumple con los requerimientos de ancho de banda disponibles en la red piloto.

- 121 -

• Como conclusión general del proyecto, se puede afirmar que es posible diseñar e implementar una WMAN utilizando únicamente licencias y tecnologías libres y lograr un nivel de aceptación de alto impacto en la comunidad, complementando las actividades de desarrollo e implementación del sistema con actividades de concientización y talleres de aprendizaje en conjunto con la comunidad.

- 122 -

6 RECOMENDACIONES • Una vez se puso en marcha el sistema y se hizo la demostración pública del

funcionamiento de los servicios, se realizaron una serie de actividades de concientización acerca de las ventajas de la tecnología en la sociedad y como estas pueden ayudar en las actividades diarias de la comunidad local en donde se implemento la red piloto. Dichas actividades se realizaron en conjunto con la comunidad de CogitoWireless en el barrio La Florida. Dichas actividades son necesarias para poder lograr un nivel de penetración mucho más alto en la comunidad y lograr así un empoderamiento de la plataforma de comunicaciones por parte de las personas de la localidad en donde se implementa la red.

• Se recomienda realizar las pruebas con un mayor número de nodos y clientes,

para así poder determinar el crecimiento y el rendimiento de la red mesh parcial con más equipos y más carga de tráfico transitando la red. Es necesario volver a realizar las pruebas de comportamiento y rendimiento si se realizan nuevos enlaces ya que estos deben cumplir con un ancho de banda optimo para poder convertirse en nodos estables dentro de la topología lógica de la red mesh.

• Para poder obtener un funcionamiento total de las capacidades de QSPNv2 y la

topología jerárquica, se deben efectuar pruebas con una mayor cantidad de nodos para lograr interconectar dos ggnodes y así observar el impacto y la reorganización entre dos islas independientes parcialmente malladas. Así mismo se recomienda estudiar la viabilidad para que las futuras implementaciones utilicen IPv6 en lugar de IPv4. En la implementación piloto se decidió adoptar IPv4 ya que no se necesitaba de una alta demanda en asignación de direcciones.

• Existen algunos riesgos que hay que tener en consideración antes de utilizar la

red mesh parcial con total seguridad. Ya que no existen mecanismos para cifrar el tráfico en la red, toda la información que es transmitida por el medio inalámbrico es susceptible de ser espiado por otros nodos que físicamente se encuentren conectados a la misma red. Es por esto que se recomienda el uso de aplicaciones que brinden capacidad de cifrado de datos, ya que este nivel de seguridad no debe ser inherente al medio físico sino a las aplicaciones que el usuario utilice. Las contramedidas para garantizar un nivel más alto de seguridad son las siguientes:

- 123 -

o Utilizar criptografía fuerte y de dominio público en las aplicaciones. o Utilizar protocolos de comunicación cifrados. o Implementar diferentes caminos alternos en las rutas para asegurar

la continuidad del servicio de enrutamiento. • Se recomienda en lo posible seguir con las actividades de concientización con

el fin de ayudar en la disminución de la brecha digital en el sector de Torrecampo, ya que si los servicios de red ofrecieran una mayor cantidad de información el nivel de penetración de las tecnologías en las personas seria mayor. Las personas que asistieron a las actividades coincidieron en la importancia de poder compartir su información mediante servicios que estén disponibles en la red.

- 124 -

BIBLIOGRAFÍA

• ABEDELLATIF, Mohammed Hussein. Flooding Control in Route Discovery for Reactive Routing in Mobile Ad-Hoc Networks, Instituto de tecnología de Rochester, 2007.

• AICHELE, Corinna., FLICKENGEN, Rob., FORSTER, Jim. Redes inalámbricas en los países en desarrollo, 2 ed., Limehouse book sprint team, 2007.

• ARTUNDUAGA, Jaime, Antenas. Conceptos básicos simplificados de funcionamiento y diseño. 1 ed., editorial bonaventuriana, 2007.

• GAST, Matthew. 802.11 Wireless Networks: The Definitive Guide. O'Reilly, 2002, ISBN 0596001835, 9780596001834, p. 443.

• GRUPO DE TRABAJO IEEE 802.11, IEEE 802.11-2007: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE, 2003.

• JOHANSEN, Oscar Bertoglio. Introducción a la teoría general de sistemas, Editorial Limusa, 2002.

• MURTHY ,C. Siva Ram, B. S Manoj. Ad Hoc Wireless Networks: Architectures and Protocols. Safari Tech Books Online. Prentice Hall PTR, 2004 ISBN 013147023X, 9780131470231 p. 857.

• O'HARA, Bob, PETRICK, Al. The Ieee 802.11 Handbook: A Designer's Companion. IEEE Standards Association, 2004 ISBN 0738144495, 9780738144498 p. 364.

• OZAN K., Gianluigi Ferrari, AD-HOC Wireless Networks: A communication-theoretic perspective, 1 ed., Wiley, 2006.

• PRASAD, Neeli., PRASAD, Anand., WLAN Systems and Wireless IP for Next Generation Communications, 1 ed., British Library Cataloguing in Publication Data, 2002.

• SEBASTIAN, Buettrich Cálculo de Radioenlace. En: Materiales de capacitación técnica. Versión Final. Alberto Escudero Pascual, 2007. Capitulo 6.

- 125 -

• SPORTACK, Mark A. Fundamentos de enrutamiento IP, 1 ed., Cisco press, 2003.

- 126 -

WEBLIOGRAFÍA

• Airserv-ng - http://www.aircrack-ng.org/doku.php?id=airserv-ng (Agosto 28, 2008)

• Altred - http://www.altred.net/ (Julio 30, 2008) • Atheros - http://madwifi.org/wiki/Compatibility/Atheros (Agosto 25, 2008) • A Performance Comparision of Multi-Hop Wireless Ad Hpc Network

Routing Protocols 1998 - http://citeseer.ist.psu.edu/broch98performance.html, (Octubre 4, 2008)

• An Efficient Network Routing Algorithm http://www.cs.ucsd.edu/~savage/papers/Sigcomm08.pdf,(Agosto 18 2008)

• Comisión de regulación de Telecomunicaciones, Informe Sectorial de Telecomunicaciones No. 9, http://www.crt.gov.co, 2007.

• Creative Commons - http://www.creativecommons.org (Febrero 18, 2008) • Creative Commons España - es.creativecommons.org/ (Septiembre 4, 2008) • Detailed analysis of the QSPN v2 - http://netsukuku.freaknet.org/2html/documentation/main_documentation/qspn.pdf, (Agosto 15, 2007)

• FairuzaWRT... Potente Firmware De Hacking Para Tu WRT54GL – http://www.zero13wireless.net/foro/showthread.php?t=910 (Agosto 28,

2008) • http://homepages.tu-darmstadt.de/~p_larbig/wlan/ (Agosto 29, 2008) • Information Security News: OpenWRT Firmware for Wireless APs - http://seclists.org/isn/2006/Oct/0021.html (Agosto 28, 2008) • Licencia GNU Licencia Publica General - Proyecto GNU - Free Software- www.gnu.org (Agosto 4, 2008)

- 127 -

• Lo Pumo, Andrea, Abnormal Netsukuku Domain Name Anarchy, http://netsukuku.freaknet.org, 2007.

• Lo Pumo, Andrea, Netsukuku Topology, http://netsukuku.freaknet.org, 2007. • Lo Pumo, Andrea, Quantum Shortest Path Netsukuku, http://netsukuku.freaknet.org, 2007.

• [Lug-wireless] antena omnidireccional – http://www.lugmen.org.ar/pipermail/ lug-wireless/2003-April/003808.html (Agosto 28, 2008)

• Música libre Oggs: Legal para compartir - oggfrog.com ( Octubre 7, 2008) • Netsukuku the Anarchical Parallel Internet - http://www.kuro5hin.org/story/2005/10/6/101832/209 (Agosto 13, 2008) • Netsukuku Detailed Description of ANDNA- http://netsukuku.freaknet.org/2html/documentation/main_documentation/andna.pdf, (Agosto 15, 2007)

• Netsukuku Documentation - http://netsukuku.freaknet.org/2html/ documentation/main_documentation/netsukuku.pdf, (Agosto 15, 2007)

• Netsukuku Issues about Netsukuku compability with the internet - http://netsukuku.freaknet.org/2html/documentation/main_documentation/inetntk.pdf, (Agosto 15, 2007)

• Netsukuku Network Topology - http://netsukuku.freaknet.org/2html/ documentation/main_documentation/topology.pdf, (Agosto 15, 2007)

• Redes Inalámbricas en los Países en Desarrollo - http://blog.pucp.edu.pe/item/3056 (Agosto 28, 2008) • Terms of use for IEEE standars publication delivered in electric form - http://standards.ieee.org/getieee802/download/802.11-2007.pdf, (Diciembre 25, 2008)

• http://www.the-mesh.org/tiki- view_forum_thread.php?forumId=1&comments_parentId=2696 (Septiembre 18, 2008)

- 128 -

GLOSARIO

802.11: protocolo de la IEEE 802.11 o WiFi, es un estándar de protocolo de comunicaciones del IEEE que define el uso de los dos niveles más bajos de la arquitectura OSI (capas física y de enlace de datos), especificando sus normas de funcionamiento en una WLAN. 802.11b: la revisión 802.11b del estándar original fue ratificada en 1999. 802.11b tiene una velocidad máxima de transmisión de 11 Mbit/s y utiliza el mismo método de acceso CSMA/CA definido en el estándar original. El estándar 802.11b funciona en la banda de 2.4 Ghz. 802.11g: estándar que utiliza la banda de 2.4 Ghz (al igual que el estándar 802.11b) pero opera a una velocidad teórica máxima de 54 Mbit/s, o cerca de 24.7 Mbit/s de velocidad real de transferencia, similar a la del estándar 802.11a. Es compatible con el estándar b y utiliza las mismas frecuencias. ACCESS POINT: punto de acceso inalámbrico (WAP o AP por sus siglas en inglés: Wireless Access Point) en redes de computadores es un dispositivo que interconecta dispositivos de comunicación inalámbrica para formar una red inalámbrica. AD-HOC: método para que los dispositivos inalámbricos se comuniquen directamente unos con otros. Operar en modo ad-hoc le otorga a los dispositivos inalámbricos la habilidad de descubrir y comunicarse de manera peer-to-peer dentro de un rango determinado con otros dispositivos sin necesidad de un punto central de acceso ANDNA (Abnormal Netsukuku Domain Name Anarchy): sistema distribuido, no-jerárquico y descentralizado del manejo de nombres en Netsukuku. Substituye el DNS. La base de datos de ANDNA se dispersa dentro de toda la red de Netsukuku y ocupa pocos cientos de kilobytes de memoria en cada nodo. B.A.T.M.A.N (Better Approach to Mobile Ad-hoc Networking): nuevo protocolo de enrutamiento para redes mesh multi-salto. CRT: entidad gubernamental reguladora del mercado de las telecomunicaciones en Colombia, encargada de promover la competencia y la inversión así como proteger los derechos de los usuarios y acorde con los lineamientos del estado. “crt.gov.co”

- 129 -

DTN: tipo de red el cual es descentralizada por naturaleza y consiste principalmente de nodos que no son constantemente parte de la red y que son capaces de entrar y salir de la red en cualquier momento y en cualquier lugar. FIRMWARE: bloque de instrucciones de software para propósitos específicos, grabado en una memoria tipo ROM, que establece la lógica de más bajo nivel que controla los circuitos electrónicos de un dispositivo de cualquier tipo. IBBS (Independent Basic Service Set): en la terminología utilizada en la especificación del protocolo 802.11, se dice que es el modo ad-hoc para enlace directo entre nodos. ISP: proveedor de servicios de Internet (o ISP por la sigla en idioma inglés de Internet Service Provider) es una empresa dedicada a conectar a Internet a los usuarios o las distintas redes que tengan, y dar el mantenimiento necesario para que el acceso funcione correctamente. También ofrecen servicios relacionados, como alojamiento web o registro de dominios entre otros. LOS (Line Of Sight): línea de vista entre un punto A y un punto B. MESH: topología de red malla en la que cada nodo está conectado a uno o más de los otros nodos. De esta manera es posible llevar los mensajes de un nodo a otro por diferentes caminos. Si la red de malla está completamente conectada no puede existir absolutamente ninguna interrupción en las comunicaciones. Cada servidor tiene sus propias conexiones con todos los demás servidores. NETSUKUKU (NTK): nombre de un sistema de routing experimental de tipo peer-to-peer, desarrollado por el laboratorio FreakNet, diseñado para construir una red distribuida, anónima y anárquica, no necesariamente separada de Internet, sin el auxilio de algún servidor central, ISP y de alguna autoridad central. OLSR (Optimized Link State Routing): protocolo pro-activo que trabaja en forma distribuida para establecer las conexiones entre los nodos en una red inalámbrica ad-hoc. La ventaja de los protocolos pro-activos consiste en que es posible mantener tablas actualizadas de enrutamiento en todo momento. OPENWRT: distribución de GNU/Linux para los dispositivos embebidos. Provee un completo sistema de archivos y manejo de paquetes de software, además es un framework para desarrollar aplicaciones para dispositivos embebidos sin necesidad de volver a construir el firmware por completo. P2P: red informática entre iguales (en inglés peer-to-peer y más conocida como P2P) se refiere a una red que no tiene clientes y servidores fijos, sino una serie de nodos que se comportan a la vez como clientes y como servidores de los demás nodos de la red.

- 130 -

QSPN (Quantum Shortest Path Netsukuku): algoritmo de enrutamiento usado por Netsukuku para encontrar la ruta óptima de la red. Su nombre se deriva de la manera como trabaja el TP, el cual es un paquete que gana un quantum de información en cada salto. SSID (Service Set IDentifier): código incluido en todos los paquetes de una WLAN para identificarlos como parte de esa red. El código consiste en un máximo de 32 caracteres alfanuméricos. WiFi (Wireless Fidelity): certificación para equipos que cumplan con los estándares para redes inalámbricas basados en las especificaciones IEEE 802.11. WiMAX (Worldwide Interoperability for Microwave Access): estándar de transmisión inalámbrica de datos (802.16 MAN) que proporciona accesos concurrentes en áreas de hasta 48 kilómetros de radio y a velocidades de hasta 70 Mbps, utilizando tecnología que no requiere visión directa con las estaciones base.

- 131 -

Anexo A PROGRAMA EN PHP PARA LEER ARCHIVOS XML OBTENIDOS EN KISMET

<?php function analizar($xml, $ruta, $nombre){ $lista=$xml->xpath($ruta."/".$nombre); $elementos=array(); foreach($lista as $i => $a){ if(isset($elementos["$a"])){ $elementos["$a"]++; }else{ $elementos["$a"]=0; } } echo "<table border=1 cellpadding=0 cellspacing=0>"; $t=(count($lista)>5014?5014:count($lista)); echo "<tr><td><strong>".$nombre."</strong></td><td><strong>Elementos</strong></td><td><strong>Porcentaje</strong></td></tr>"; $suma=0; foreach($elementos as $i => $a){ $r=$a/$t*100; echo "<tr><td>".$i."</td><td>".$a."</td><td>".$r."%</td></tr>"; $suma+=$a; } echo "<tr><td><strong>total</strong></td><td>".$suma."</td><td>".$suma/$t."%</td></tr>"; echo "</table>"; } $archivo="Kismet-Aug-07-2008-1.xml"; if (file_exists($archivo)) { $xml = simplexml_load_file($archivo); $lista=$xml->xpath("/detection-run/wireless-network"); echo "<strong>Total Redes =".count($lista)."</strong>"; analizar($xml, "/detection-run/wireless-network", "channel"); analizar($xml, "/detection-run/wireless-network", "encryption"); } else { exit('Error al abrir '.$archivo); } ?>

- 132 -

Anexo B ECUACIÓN PARA OBTENER PÉRDIDA EN EL CABLE LMR 200

(0.320900) • sqrt 2422 + (0.000330) • 24222 = 16,59197428

Este resultado es obtenido en dB. /pies por lo cual es necesario convertirlo a dB. /m para ello lo multiplicamos por 3.28m que es el equivalente a 1 pie.

16,59197428 * 3.28 = 54,42167662 dB. /100m Como los cables con los que se implemento la red son de de 1 metro de largos, se realizó una regla de 3 para poder saber la perdida en nuestros cables implementados.

100 m 54,42167662 1m ?

(1 * 54,42167662) / 100 = 0,544216766 dB./m

Lo cual nos deduce que por cada metro de cable LMR200 implementado para el pigtail obtendremos una perdida aproximada de 0,5 dB.

- 133 -

Anexo C ENCUESTA REALIZADA A LOS USUARIOS DE LA RED

- 134 -

- 135 -

Anexo D REGLAS DE CONFIGURACIÓN DE IPTABLES PARA ABRIR LOS PUERTOS

QUE NECESITA NTK

#!/bin/sh # Copyright (C) 2006 OpenWrt.org # Copyright (C) 2008 CogitoWireless.org iptables -F input_rule iptables -F output_rule iptables -F forwarding_rule iptables -t nat -F prerouting_rule iptables -t nat -F postrouting_rule # The following chains are for traffic directed at the IP of the # WAN interface iptables -F input_wan iptables -F forwarding_wan iptables -t nat -F prerouting_wan # The following rules are for the Netsukuku daemon. iptables -t nat -A prerouting_wan -p udp --dport 269 -j ACCEPT iptables -A input_wan -p udp --dport 269 -j ACCEPT iptables -t nat -A prerouting_wan -p tcp --dport 269 -j ACCEPT iptables -A input_wan -p tcp --dport 269 -j ACCEPT iptables -t nat -A prerouting_wan -p tcp --dport 271 -j ACCEPT iptables -A input_wan -p tcp --dport 271 -j ACCEPT iptables -t nat -A prerouting_wan -p udp --dport 277 -j ACCEPT iptables -A input_wan -p udp --dport 277 -j ACCEPT iptables -t nat -A prerouting_wan -p tcp --dport 277 -j ACCEPT iptables -A input_wan -p tcp --dport 277 -j ACCEPT

- 136 -

Anexo E CONFIGURACIÓN DE SYSCTL PARA LINUX EN OPENWRT

# Configuracion de sysctl para Linux en OpenWRT. kernel.panic=3 net.ipv4.conf.default.arp_ignore=1 net.ipv4.conf.all.arp_ignore=1 net.ipv4.ip_forward=1 net.ipv4.icmp_echo_ignore_broadcasts=1 net.ipv4.icmp_ignore_bogus_error_responses=1 net.ipv4.tcp_fin_timeout=30 net.ipv4.tcp_keepalive_time=120 net.ipv4.tcp_syncookies=1 net.ipv4.tcp_timestamps=0 net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=3600 net.ipv4.netfilter.ip_conntrack_udp_timeout=60 net.ipv4.netfilter.ip_conntrack_udp_timeout_stream=180

- 137 -

Anexo F ARCHIVO DE CONFIGURACIÓN DEL NOMBRE DE MAQUINA

config system option hostname Actium

- 138 -

Anexo G CONFIGURACIÓN BÁSICA DE OPENWRT EN MODO AD-HOC UTILIZANDO

EL DRIVER B43 CON MAC80211 EN WRT54GL V1.1.

# Copyright (C) 2008 CogitoWireless.net # # Configuracion basica de OpenWRT en modo Ad-Hoc utilizando # b43 con mac80211 en WRT54GL v1.1 config wifi-device wlan0 option type broadcom option channel 2 option disabled 1 option distance 250 config wifi-iface option device wlan0 option mode adhoc option ssid CogitoWireless option hidden 0 option encryption none

- 139 -

Anexo H PARÁMETROS PARA COMPILAR E INSTALAR NTK EN LOS NODOS

# # Copyright (C) 2008 CogitoWireless.net <info@cogitowireless.net> # # This is free software, licenced under the GNU General Public Licence v2. # See /LICENCE for more information. include $(TOPDIR)/rules.mk PKG_NAME:=netsukuku PKG_VERSION:=0.0.9b PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:=http://netsukuku.freaknet.org/ PKG_MD5SUM:=5cfc4c1a4a49d63f5a93f987b90043ae PKG_CAT:=cogito include $(INCLUDE_DIR)/package.mk define Package/netsukuku SECTION:=cogito CATEGORY:=mesh SUBMENU:= DEPENDS:= URL:=http://netsukuku.freaknet.org/ TITLE:=Netsukuku DESCRIPTION:=Netsukuku is mesh networking routing suite designed for descentralized networks endef define Build/Compile endef define Package/netsukuku/install $(CP) -a ./files/* $(1)/ chmod -R 755 $(1)/* endef $(eval $(call BuildPackage, netsukuku))

- 140 -

Anexo I ARCHIVO DE CONFIGURACIÓN DE VARIABLES UCI PARA NTK

# Copyright (C) 2008 CogitoWireless.net config netsukuku general option interface wlan0 option restricted_mode 0 option restricted_class 0 option internet_connection 0 option internet_gateway 192.168.1.1:eth0 option internet_download_rate 640 option internet_upload_rate 30 option internet_ping_hosts google.com:cisco.com option share_internet 0 option shape_internet 0 option use_shared_internet 0 option max_connections 512 option max_accepts_per_host 16 option max_accepts_per_host_time 4 option tc_shaper_script /etc/netsukuku/ip_masquerade.sh config netsukuku maps option ext_map_file /usr/share/netsukuku/ext_map option int_map_file /usr/share/netsukuku/int_map option bnode_map_file /usr/share/netsukuku/bnode_map config netsukuku andna option disable_andna 1 option disable_resolvconf 1 option andna_cache_file /etc/netsukuku/andna_cache option andna_lclkey_file /etc/netsukuku/andna_lcl_keyring option andna_rhc_file /etc/netsukuku/andna_rhc_cache option andna_counter_c_file /etc/netsukuku/andna_counter_cache config netsukuku snsd option snsd_nodes_file /etc/netsukuku/etc/snsd_nodes

- 141 -

Anexo J SCRIPT DE INICIO Y PARADA DEL DEMONIO DE NTK PARA LOS NODOS

# Copyright (C) CogitoWireless.net #!/bin/sh /etc/rc.common START=46 . /lib/config/uci.sh uci_load netsukuku start() { interface=$(uci get netsukuku.general.interface) if [ "$interface" = ""]; then echo $1 Error, you must specify at least one network interface exit fi ip_version=$(uci get netsukuku.general.ip_version) restricted_mode=$(uci get netsukuku.general.restricted_mode) restricted_class=$(uci get netsukuku.general.restricted_class) internet_connection=$(uci get netsukuku.general.internet_connection) internet_gateway=$(uci get netsukuku.general.internet_gateway) internet_download_rate=$(uci get netsukuku.general.internet_download_rate) internet_upload_rate=$(uci get netsukuku.general.internet_upload_rate) internet_ping_hosts=$(uci get netsukuku.general.internet_ping_hosts) share_internet=$(uci get netsukuku.general.share_internet) shape_internet=$(uci get netsukuku.general.shape_internet) use_shared_internet=$(uci get netsukuku.general.use_shared_internet) max_connections=$(uci get netsukuku.general.max_connections) max_accepts_per_host=$(uci get netsukuku.general.max_accepts_per_host) max_accepts_per_host_time=$(uci get netsukuku.general.max_accepts_per_host_time) tc_shaper_script=$(uci get netsukuku.general.tc_shaper_script)

- 142 -

ntk_args="" if [ $restricted_mode ]; then ntk_args=${ntk_args}'-r' fi if [ $ip_version = 4 ]; then ntk_args=${ntk_args}'-4' fi if [ $share_internet ]; then ntk_args=${ntk_args}'-m' fi ntk_args=${ntk_args}'-i '$interface' ' ntkd $ntk_args >/dev/null 2>&1 } restart() { $0 stop sleep 3 $0 start } stop() { killall ntkd }