PROTOTIPO DE UNA ESTACIÓN CELULAR PORTÁTIL PARA ATENCIÓN DE

EMERGENCIAS

JULIÁN DAVID VÁSQUEZ GUTIÉRREZ

juvasquez88@gmail.com

IVÁN FERNADO SANTA RAMÍREZ

ivanfernandosanta@gmail.com

JOSÉ VALENTÍN RESTREPO LAVERDE

vatin@une.net.co

MEDELLÍN - COLOMBIA

Noviembre 18 de 2012

AGRADECIMIENTOS

A mi familia por el apoyo incondicional y la tolerancia infinita. A mi compañero de trabajo de grado, pues sin su paciencia y esmero este proyecto no hubiera tenido éxito. Al director del trabajo de grado por la confianza que tuvo en el proyecto.

Iván Fernando Santa Ramírez

Al constante apoyo de mi familia que hacen que cada día se convierta en un pequeño universo donde las cosas se pueden lograr. A mi compañero de trabajo de grado por su labor y tener siempre un consejo de amigo. Al director del trabajo de grado por creer y apoyar este proyecto.

Julián David Vásquez Gutiérrez

CONTENIDO

LISTA DE FIGURAS ................................................................................................ 5

LISTA DE CUADROS .............................................................................................. 6

GLOSARIO .............................................................................................................. 7

RESUMEN ............................................................................................................. 10

INTRODUCCIÓN ................................................................................................... 12

1. CONCEPTOS GENERALES ............................................................................. 14

1.1 TELECOMUNICACIONES EN DESASTRES. .............................................. 14

1.2 TELEFONÍA MÓVIL COMO SOLUCIÓN ...................................................... 17

1.3 MARCO REGULATORIO DE LAS COMUNICACIONES MÓVILES EN COLOMBIA ......................................................................................................... 20

2. DESARROLLO E IMPLEMENTACIÓN DE UNA BTS GSM ............................. 25

2.1 COMPONENTES DEL SISTEMA ................................................................. 25

2.1.1 Asterisk. ................................................................................................ 25

2.1.1.1 Arquitectura de Asterisk .................................................................. 25

2.1.1.2 Estructura de Archivos. ................................................................... 27

2.1.1.3 Tipos de módulos. ........................................................................... 27

2.1.2 GNU Radio. .......................................................................................... 28

2.1.3 Universal Software Radio Peripheral (USRP)....................................... 33

2.1.4 Sistema Global para las Comunicaciones Móviles (GSM). .................. 36

2.1.4.1 Canales de tráfico ........................................................................... 43

2.1.4.2 Canales de control dedicados ......................................................... 43

2.1.4.3 Canales de control no dedicados .................................................... 44

2.1.5. OpenBTS. ............................................................................................ 44

2.2 ANÁLISIS Y DISEÑO DE LA SOLUCIÓN .................................................... 49

2.3 IMPLEMENTACIÓN DE LA SOLUCIÓN ...................................................... 50

2.3.1 Requerimientos de software ................................................................. 51

2.3.2 Requerimientos de Hardware ............................................................... 51

2.3.2.1 Proceso de ensamblaje de USRP (Ver Anexo A) ........................... 53

2.3.3 Proceso de adecuación del hardware. ................................................. 53

2.3.4 Proceso de instalación. ........................................................................ 55

2.3.4.1 Instalación de GNU Radio. .............................................................. 55

2.3.4.2 Instalación de OpenBTS. ................................................................ 59

2.3.4.3 Instalación de Asterisk. ................................................................... 60

2.3.5 Configuración para la puesta en funcionamiento de la microcelda. ...... 69

2.3.5.1 Configuración de OpenBTS. ........................................................... 69

2.3.5.2 Configuración de Asterisk ............................................................... 71

2.4 PRUEBAS, AJUSTES Y RESULTADOS FINALES ...................................... 80

3. DIFICULTADES, BENEFICIOS Y RECOMENDACIONES ................................ 84

3.1 Dificultades en la instalación. ....................................................................... 84

3.2 Dificultades en la operación. ......................................................................... 85

4. POSIBLES MEJORAS AL PROTOTIPO ........................................................... 87

4.1 MEJORA EN ALCANCE Y POTENCIA. ....................................................... 87

4.2 ANÁLISIS ENERGÉTICO DEL PROTOTIPO Y SUGERENCIA DEL SISTEMA DE POTENCIA AUTÓNOMO. ............................................................ 94

4.2.1 Acercamiento al sistema de potencia autónomo .................................. 95

CONCLUSIONES .................................................................................................. 99

BIBLIOGRAFÍA .................................................................................................... 101

LISTA DE FIGURAS

Figura 1. Diagrama de conexión de Asterisk ......................................................... 26

Figura 2. Modelo de grafo. “Hola Mundo de GNU Radio” ...................................... 30

Figura 3. Diagrama de la arquitectura de un SDR ................................................. 32

Figura 4. Diagrama de bloques del USRP1 ........................................................... 36

Figura 5. Arquitectura básica de la red GSM ......................................................... 38

Figura 6. Esquema de frecuencia para la banda GSM900 .................................... 42

Figura 7. Combinación de las técnicas FDMA/TDMA ............................................ 43

Figura 8. Arquitectura de OpenBTS ....................................................................... 47

Figura 9. Kit USRP PKG ........................................................................................ 53

Figura 10. Modificaciones del USRP ..................................................................... 54

Figura 11. Instalación de Ubuntu 10.04 LTS con usuario emergencybts ............... 55

Figura 12. Interfaz web Asterisk GUI ..................................................................... 68

Figura 13. Relación entre los archivos sip.conf y extensions.conf ......................... 73

Figura 14. Relación de extensiones dentro de los archivos de configuración. ...... 79

Figura 15. Diagrama de bloques de la distribución de los componentes ............... 94

Figura 16. Diagrama de bloques simplificado del sistema de potencia autónomo . 96

Figura 17. Aplicación Típica del LM317: Regulador de voltaje .............................. 97

Figura 18. Circuito de potencia básico. ................................................................. 98

LISTA DE CUADROS

Cuadro 1. Series y temas de la especificación GSM ............................................. 40

Cuadro 2. Rangos de frecuencia, offset y ARFCN ................................................. 41

Cuadro 3. Características de frecuencia y potencia de las tarjetas hijas ............... 52

Cuadro 4. Conformación del IMSI .......................................................................... 69

Cuadro 5. Operadores que prestan servicios en Colombia ................................... 70

Cuadro 6. Comandos relevantes desde el prompt CLI de OpenBTS ..................... 80

Cuadro 7. Comandos relevantes desde el prompt CLI de Asterisk........................ 80

Cuadro 8. Máxima potencia de salida para una MS GSM modulación GMSK ...... 89

GLOSARIO

BTS: Estación Base, es un punto de acceso que permite la radio comunicación entre la estación móvil y la red, brindando también cobertura a un área detemrinada. El termino BTS es asociado con comunicaciones móviles GSM o CDMA recibiendo y transmitiendo información entre el celular y la red.

Cobertura: Es el área geográfica en la cual los usuarios disponen de un servicio.

Códec: Es la abreviatura de codificador-decodificador. Es un algoritmo capaz de traducir señales análogas a flujo de datos digitales y visceversa, para la transmisión o almacenamiento cifrado y de igual forma decifrado y obtención de la señal adecuada para la reproducción o visualización.

Demonio: Es un proceso especial que difiere de una aplicación porque se ejecuta en segundo plano, con lo que no es directamente controlado por el usuario.

Diafonía: Fenómeno en el cual parte de la señal sobre un circuito o canal aparece en otro causando una perturbación.

Figura de ruido: Es una medida de cuanto se degrada la relación señal a ruido mientras la señal está pasando por un dispositivo electrónico. La figura de ruido especifica el ruido generado por un dispositivo electrónico.

Framework: Es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos de software concretos. El propósito de un framework es mejorar la eficiencia de la creación y desarrollo de un nuevo proyecto de software.

Gateway: Es una puerta de enlace y su propósito es traducir la información del protocolo utilizado en una red, al protocolo usado en la red de destino.

Grafo: Es un conjunto de objetos llamados vértices o nodos unidos por enlaces llamados aristas o arcos, que permiten representar relaciones binarias (pares de objetos). Prácticamente cualquier problema puede representarse mediante un grafo.

Microcelda: Es el área de cobertura geográfica proporcionada por una estación base, comúnmente cubre distancias de 200 a 400 metros y hasta un máximo de 2 kilómetros desde la antena.

NGN: Red de nueva generación, es un término que hace referencia a un modelo de arquitectura de redes de comunicaciones con el fin de lograr la convergencia

de los servicios IP multimedia (comunicaciones VoIP, video conferencia, integración con servicios IPTV, domótica, entre otros).

Piso de ruido: Es la mínima señal para la que es útil el circuito o dispositivo. La cantidad de señal mínima capaz de distinguirse del ruido generado por el dispositivo.

Protocol stack: Una pila de protocolos es una arquitectura conceptual de protocolos de comunicación. Los protocolos individuales son definidos en capas, donde cada capa realiza una tarea específica. El término stack se refiere a la implementación por software de los protocolos.

RF front end: Consiste en todos los componentes que procesan la señal en la frecuencia original de llegada RF (Radio Frequency, Radio Frecuencia), antes de que esta sea convertida en una de baja frecuencia intermedia IF (Intermediate Frequency, Frecuencia Intermedia). Convertirte la señal de RF a la frecuencia intermedia IF y visceversa.

Roaming: Conocido en español como itinerancia, es una de las funcionalidades básicas de los sistemas de comunicaciones móviles, que permite a los usuarios acceder a los servicios, aún si se encuentran fuera del área de cobertura de un operador, usando redes de otros operadores o proveedores de servicios, siempre que exista un acuerdo comercial previo con estos operadores.

SDR: Radio definido por software, es un sistema de radio comunicación donde los componentes que normalmente se realizaban con hardware (filtros, divisores, moduladores, demoduladores) son implementados por software haciendo uso de un computador o un sistema embebido.

SMS: Es un servicio que permite el envío de mensajes de texto desde la web o desde un dispositivo de comunicaciones móviles.

SIP: Es un protocolo de señalización a nivel de capa de aplicación encargado de la iniciación, modificación y terminación de sesiones multimedia como voz, video conferencias, mensajería instantánea. SIP es uno de los protocolos de señalización para VoIP (Voice over IP, Voz sobre Protocolo de Internet).

Softphone: Es un programa que permite realizar y recibir llamadas telefónicas VoIP, se instala en dispositivos con capacidad de procesamiento.

Transceptor (Transceiver): Transmisor-Receptor, es un dispositivo que realiza funciones de transmisión y recepción de señales análogas y digitales empleando elementos comunes del circuito.

Throughput: Es la tasa promedio de información exitosa entregada sobre un canal de comunicaciones.

Trunking: Es un servicio de radiocomunicaciones privado que se ofrece en un área de cobertura determinada y que permite la difusión de información o el establecimiento de comunicaciones entre dos o más usuarios.

Última milla: La última milla se refiere al último tramo de conexión entre el operador que brinda el servicio y el usuario final, independientemente de la tecnología empleada.

USRP: Es un dispositivo de Hardware libre, que en conjunto con un computador permite implementar y diseñar sistemas de radiocomunicaciones potentes, flexibles a muy bajo costo y mínimo esfuerzo.

Vocoder: Es un analizador y sintetizador usado para reproducir voz humana.

RESUMEN

En casos de desastres como terremotos, tsunamis, inundaciones, incendios; o en casos de emergencias como apagones, fallas de la red o atentados terroristas, las redes de telecomunicaciones tienen una alta probabilidad de colapsar. Para hacerle frente a esta dificultad, los sistemas y organismos de emergencia no cuentan con celdas celulares móviles de respaldo para su uso inmediato, lo cual hace evidente la necesidad de disponer servicios de telecomunicaciones que faciliten las labores de rescate aprovechando el uso masivo de teléfonos celulares entre la población. Se requiere una solución que incorpore los teléfonos celulares, que sea poco exigente en inversión y que tenga la posibilidad de operar sin costo para facilitar la comunicación entre los afectados por una calamidad y los organismos de rescate. Adicionalmente debe ser portátil y de rápida instalación.

La solución que cubre estas demandas técnicas fue el desarrollo e implementación de un prototipo de estación celular portátil con gestión de usuarios, control de llamadas, cobertura limitada y sin interfaz para conexión de usuarios entre la micorcelda y las redes públicas de comunicación. Se acudió al proyecto OpenBTS que genera una interfaz de aire GSM (Global System for Mobile Communications, Sistema Global para las Comunicaciones Móviles) “Um”, usada para establecer la comunicación entre la MS (Mobile Station, Estación Móvil) y la BTS (Base Transceiver Station, Estación Base Transceptora) en una arquitectura de red GSM convencional. OpenBTS hace uso del hardware USRP (Universal Software Radio Peripheral, Periférico Universal de Radio por Software) y el software GNU Radio corriendo sobre un computador. Además utiliza el software Asterisk que, a través de un controlador de canal, verifica el plan de marcado para realizar el control y conmutación de las llamadas.

La base del hardware fue el paquete USRP-PKG, dos tarjetas hijas (daughterboards) RFX900, cada una con su antena VERT900 que cubren las bandas GSM 850/900; un computador con puerto USB-2.0, procesador Intel Atom de 1.5 GHz con 2GB de memoria RAM; reloj de referencia de 52MHz, Fairwaves СlockTamer, especialmente diseñado para usarse con el USRP.

El sistema operativo fue el Ubuntu 10.04 LTS Desktop sobre el cual se instaló el software GNU Radio en su versión 3.4.2, que cuenta con el soporte para el USRP1. Igualmente se instaló el software OpenBTS P2.6 Mamou que brinda la implementación de la pila de protocoles GSM y el software Asterisk 1.6.2.22. Se inició el estudio de la configuración para funcionamiento de Asterisk.

Se comprobó el correcto funcionamiento de la microcelda utilizando el softphone Zoiper y celulares Samsung GT-E1086L, Alcatel OT-203 y Huawei. Estas pruebas se realizaron en un sótano sin la señal de operadores públicos comerciales, para evitar que la señal que genera OpenBTS sea enmascarada por la señal de los

operadores. La cobertura fue de 10 metros y se probaron los mensajes enviados desde la terminal donde corre OpenBTS con el comando sendsms.

INTRODUCCIÓN

Las redes de telecomunicaciones son un elemento de gran importancia para las sociedades. Desafortunadamente en situaciones de emergencia las redes tienen una alta probabilidad de colapsar o carecen de la cobertura necesaria para ser utilizadas en el lugar del suceso. En casos de desastres como terremotos, tsunamis, inundaciones, incendios, o emergencias como apagones, fallas de la red o atentados terroristas, no se cuenta con celdas celulares móviles de respaldo para su uso inmediato.

Luego del terremoto de Haití, por ejemplo, se evidenció la necesidad de disponer rápidamente de los servicios de telecomunicaciones para facilitar las labores de rescate. Además, se observó que la alta disponibilidad y uso de teléfonos celulares entre la población, incluso en países subdesarrollados, los hace un instrumento fácil y práctico para la ubicación de personas atrapadas bajo estructuras colapsadas.

Por otra parte, hay que tener en cuenta que los operadores de telefonía celular funcionan bajo un modelo de oferta-demanda que los imposibilita financieramente para dar cobertura en lugares con poca población o prestar servicios gratuitos en casos de emergencia, razón por la cual se considera necesario que los entes gubernamentales y de atención a desastres dispongan de una red de telefonía celular autónoma, portátil, de corto alcance y sin tarificación, que brinde servicios en lugares donde sea necesario por razones de emergencia o por inaccesibilidad a la red pública comercial.

En tal caso, se requiere un recurso que incorpore los teléfonos celulares, haga uso de la red móvil de telefonía celular, requiera baja inversión y tenga la posibilidad de operar sin costo para que permita la comunicación entre los afectados por una calamidad y los organismos de rescate. La solución que se propone en el presente trabajo es el desarrollo e implementación de un prototipo de Estación Celular Portátil con gestión de usuarios, control de llamadas y cobertura limitada. No se implementa un sistema de facturación pues su único fin es el uso en algún evento donde sea requerida una comunicación gratuita por entes de prevención y atención a desastres o emergencias. Tampoco se desarrolla una interfaz que permita conectar llamadas de los usuarios de la microcelda con otros situados en redes públicas de comunicación. El número de llamadas simultáneas es limitado.

Para el desarrollo e implementación de la Estación Celular Portátil se acude al proyecto OpenBTS que genera una interfaz de aire GSM “Um”, que es la interfaz que se usa para establecer la comunicación entre la MS y la BTS en una arquitectura de red GSM convencional. OpenBTS hace uso del hardware USRP y el software GNU Radio corriendo sobre un computador para construir una

completa aplicación de software radio. Además utiliza el software Asterisk para realizar el control y conmutación de las llamadas.

1. CONCEPTOS GENERALES

1.1 TELECOMUNICACIONES EN DESASTRES.

Entre las consecuencias más típicas de los desastres es el parcial o completo colapso de las infraestructuras de las telecomunicaciones terrestres (especialmente en la red de distribución, “la última milla”). Aun cuando tales daños no se lleven a cabo, las comunicaciones se sobrecargan como resultado del tráfico significativamente elevado, generado por los residentes afectados.

Es preciso ofrecer soluciones que permitan superar las dificultades de las telecomunicaciones en las regiones afectadas por desastres. Las soluciones requeridas son operaciones de redes centrales que puedan ser empleadas en el manejo de desastres de cualquier magnitud1.

El aumento poblacional, la creciente urbanización, la expansión industrial y los sistemas de transporte incrementan el riesgo de mayores desastres causados por la actividad humana. Las inundaciones, terremotos y huracanes hoy causan mayor daño del que hubieran hecho hace apenas un siglo.

El manejo de cada desastre, sin importar su tamaño, requiere de la coordinación de un gran número de agencias nacionales e internacionales con muchos perfiles diferentes (culturales, políticos y religiosos) que demandan medios mejorados de información para atender un amplio rango de demandas conflictivas. Las comunicaciones deben facilitar la coordinación entre las agencias nacionales e internacionales que están en colaboración con los esfuerzos de rescate y la oportuna y relevante guía a la población afectada.

La convergencia de los servicios de telefonía está basada en la separación funcional de tres componentes principales: La transmisión de información, servicio lógico y definición de contenido que puede ser provisionado por un actor único o por actores diferentes2.

El concepto de NGN (Next Generation Network, Red de Nueva Generación) funciona a través de la conexión de redes y los servicios de información tradicionalmente provenientes de una conmutación de paquetes. La transformación resultó en una infraestructura basada en el protocolo IP, que es capaz de proveer una multimedia combinada, servicios de voz e información.

1 PATRICELLI, F.; BEAKLEY. J; CARNEVALE, A. Disaster management and mitigation: the telecommunications infrastructure. EN: Disasters. Enero. 2009. 33, p. 23. 2 Ibid. p. 24.

Desde un punto de vista de su arquitectura, una de las principales características del NGN es la aguda separación de las funcionalidades de la red. Las redes vitales de telecomunicaciones a su vez están compuestas por diferentes redes asociadas a la prestación de múltiples servicios de telecomunicaciones, cuya importancia relativa depende de la penetración o uso que de un servicio específico haga una sociedad en sus diferentes sectores sociales y económicos y, del momento histórico en el que se realice su análisis.

Actualmente, en Colombia y a nivel internacional, sin lugar a dudas, los servicios de telefonía móvil celular, trunking y los servicios de acceso a INTERNET se constituyen en servicios vitales para la totalidad de los sectores sociales y económicos del país.

Se observa que la penetración del servicio de Telefonía Pública Básica Conmutada Local (TPBCL) del año 2000 a 2009, tiene una pérdida de 1,2%, mientras que los servicios de telefonía celular pasaron de una penetración de 5,6% a 91,5 %3.

De manera análoga, las redes de servicios de telefonía celular, adicional a la importancia vital en función de la penetración anotada, son soporte a los accesos móviles de INTERNET, que como ya se mencionó han tenido en los últimos años un aumento evidente en su penetración.

En la sociedad moderna, las Tecnologías de la Información y las Comunicaciones (TIC), dentro de las cuales lógicamente están comprendidas los servicios mencionados, se constituyen en una línea vital básica para mantener y mejorar el bienestar de la sociedad. Las TIC son totalmente transversales a los demás sectores de la sociedad, actualmente no se podría concebir básicamente ninguna actividad del ser humano ajena a la influencia o dependencia de las TIC.

Específicamente, en la administración de desastres las TIC juegan un papel fundamental en sus diferentes etapas, así:

Prevención y preparación. En esta etapa, los servicios de comunicación masiva, tales como radiodifusión sonora, televisión e INTERNET, se constituyen en los medios obligados, dada su penetración, para capacitar y preparar en forma masiva y coherente a la población en general y a las entidades y organizaciones en todos los temas relacionados con las cuatro fases de la administración de desastres.

3 MINISTERO DE TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIÓNES. Estudio vulnerabilidad y riesgo de redes e infraestructura de telecomunicaciones en zonas vulnerables expuestas a eventos desastrosos. Bogotá, 2010. p. 129

En esta etapa adicionalmente, las TIC están incorporadas en las redes y sistemas de telemetría y alertas tempranas, tanto a nivel de las redes satelitales, de microondas y transmisión de datos a través de las redes de telefonía móvil celular y en los sistemas de tratamiento de datos de éstas4.

Respuesta. En esta etapa de la administración de desastres, las TIC son fundamentales, ya que a través de las redes de radiodifusión sonora, televisión e INTERNET, se mantiene informada a la población y se apoyan las actividades de salvamento, búsqueda y rescate.

En esta fase, entran a jugar un papel decisivo las comunicaciones de las redes de Telefonía Pública Básica Conmutada Local (TPBCL) y telefonía móvil celular con relación al acceso de la población a los organismos de emergencia directamente o a través de los números únicos previstos para estos eventos, al igual que como apoyo a las actividades de estos, permitiendo su intercomunicación. Sin embargo, es de anotar que estas redes históricamente han colapsado por la congestión en su acceso, limitando de esta manera su utilidad en esta fase.

Finalmente, en las actividades de salvamento, búsqueda y rescate, el papel preponderante lo tienen las redes de emergencia, que permiten coordinar a través de redes de radio que normalmente operan en VHF (Very High Frequency, Frecuencia Muy Alta), las actividades de organismos tales como: cruz roja, defensa civil, bomberos, entidades de salud, autoridades municipales, policía y ejército nacional. Los radioaficionados juegan un papel muy importante en el apoyo de estas actividades, debido a que su infraestructura de comunicaciones a nivel de radios, sistema radiante y energía, no representa mayores complejidades para su operación y/o restauración en caso de destrucción.

En la etapa de respuesta, se deberá priorizar la restauración de los servicios de telecomunicaciones, aún por encima de los de energía eléctrica, ya que mediante éstos y dadas las múltiples relaciones que existen entre las TIC y los demás sectores, se facilitará la restauración de otros servicios vitales cuya rápida restauración es fundamental en la etapa de respuesta al desastre5.

Reparación y construcción: como ya se mencionó, la restauración de las telecomunicaciones es prioritaria y debe comenzar desde la fase de respuesta, ya que esta facilitará que las demás líneas vitales sean reparadas y construidas nuevamente, permitiendo que se recupere rápidamente el estándar de bienestar de la sociedad afectada.

4 Ibid. p. 133. 5 Ibid. p. 134

Re-desarrollo: en esta etapa y ya recobrado el bienestar mínimo aceptable de la sociedad, se realiza el redesarrollo de los diferentes sectores afectados, repensando, rediseñando y construyendo con base en las lecciones aprendidas y creando infraestructura más resistente, menos expuesta y en fin menos vulnerable a los eventos desastrosos, de tal manera que se evite la recurrencia. En el redesarrollo, las TIC son protagonistas, ya que son fundamentales para el análisis, planeación, diseño y construcción de nueva infraestructura, para la modernización y disminución de la vulnerabilidad mediante la incorporación de TIC en los diferentes procesos de todos los sectores de la sociedad6.

1.2 TELEFONÍA MÓVIL COMO SOLUCIÓN

Los teléfonos móviles pueden desempeñar un papel importante en las alertas tempranas y el período inmediatamente posterior, al igual que otros medios de comunicación. Sin embargo, los móviles hacen su contribución específica y más valiosa en el socorro y recuperación. Una de las razones es la velocidad con que las redes móviles se pueden recuperar en relación con otras formas de comunicación. La otra es la capacidad única de los móviles para descentralizar la información y mejorar el proceso de obtener los recursos adecuados para las personas y los lugares donde son más necesarios después de un desastre. Los desastres naturales y otras emergencias tales como atentados terroristas traen a su paso situaciones caóticas y complicadas en las que la gente está asustada e insegura. La información precisa es importante en cada etapa para hacer frente a las consecuencias inmediatas a través de socorro y recuperación.

En el informe mundial sobre desastres del 2005 publicado por la IFRC (International Federation of Red Cross and Red Crescent Societies, Federación Internacional de La Cruz Roja y la Media Luna Roja), se destaca que muchos de los desastres del año podrían haberse evitado con una mejor información y comunicación. Aunque no se detalla el papel de los teléfonos móviles, señala que en el caso del Tsunami el uso personal de ellos ayudó a compensar la ausencia de información oficial significando además que el tsunami marca un "punto de inflexión" en términos de la eficacia de la comunicación persona a persona en respuesta a los desastres.

En algunos desastres, sobre todo en países en desarrollo, los móviles han superado a las líneas fijas y en ciertos casos son más frecuentes que las comunicaciones de difusión como televisión o radio. Dada la velocidad relativa con la que se puede instalar una red de emergencia y redes preexistentes restauradas, los móviles pueden desempeñar un papel distintivo logrando que la información fluya hacia donde se necesita.

6 Ibid. p. 135.

En muchas partes del mundo ya existen sistemas de alerta, por lo general basados en la difusión por radio y televisión como los esquemas de advertencia de huracanes en el Caribe. La clave para la alerta temprana eficaz es la transmisión de información autorizada a tantas personas como sea posible. Aunque los medios de comunicación son los más eficaces en estos casos, ha habido un interés en el uso de métodos adicionales de comunicación para suplementar los sistemas existentes. Aunque son incapaces de igualar el alcance de los medios audiovisuales, estos pueden ampliar la cobertura de las advertencias en algún grado. Una de estas nuevas tecnologías es la provisión de información detallada en los sitios web.

Otro es el uso de redes de telefonía móvil si se dirigen a ciertos lugares o grupos de suscriptores y, adicionalmente, tiene la ventaja de involucrar múltiples operadores que colaboran entre ellos y con las entidades gubernamentales. Los enfoques tecnológicos principales son el de Difusión Celular (Cell Broadcast) y mensajes SMS (Short Message Service, Servicio de Mensajes Cortos). La difusión celular enfoca alertas a cada una de las celdas y puede ir desde una celda individual a todo el país, pero requiere preconfiguración. La Mensajería SMS va dirigida a las categorías de individuos, incluidos los usuarios de roaming; es ubicuo, muy familiar para los usuarios y tiene un impacto demostrado en las respuestas de la gente.

Estados Unidos está considerando la adición de tecnologías inalámbricas para el actual Plan de Alerta de Emergencia en todo el país; es probable la participación de todos los operadores de telefonía móvil y el uso de Mensajes SMS. India está considerando un sistema de aviso de ciclones en los estados costeros, en la que los operadores de GSM usarán tanto la difusión celular como SMS. Las autoridades nacionales, por supuesto, deben mantenerse a la vanguardia de las iniciativas para preparar a sus propios ciudadanos en caso de emergencia.

Otro ejemplo es el sistema de alerta temprana geo referenciado que se usará en Chile, en el que se puede marcar un sector de la ciudad o de la costa y automáticamente todas las antenas que están bajo esa ubicación geográfica reciben los mensajes. Por tanto los celulares de todas las personas que estén bajo esa ubicación, estén o no hablando por teléfono, reciben el mensaje de alerta.7 Un ejemplo destacado de sinergia entre los operadores locales, las organizaciones especializadas de socorro y las autoridades gubernamentales se encuentra en el terremoto ocurrido en el año 2003 en la ciudad de Bam, ubicada al sureste de Teherán. Mediante esta acción colaborativa fue posible restablecer los servicios

7 KREBS, Antonia. La segunda On line. Sistema de alerta temprana estará operativo en Chile a comienzos del 2012. [en línea]. 2011. <Disponible en: http://www.lasegunda.com/Noticias/Economia/2011/03/633291/Sistema-de-alerta-temprana-estara-operativo-en-Chile-a-comienzos-del-2012>

de telecomunicaciones dentro de las 24 horas siguientes al desastre. Los voluntarios de Ericsson Response y sus colegas en Ericsson Turquía y Ericsson Irán, fueron enviados a instalar un sistema de emergencia GSM, que fue conectado vía satélite a la red de Turkcell. Este proyecto que inició a partir de 1999 cuando el terremoto de Izmit, en la región de Mármara, con el auspicio de Turkcell y se denominó Sistema Único de Comunicación de Emergencia que ha sido diseñado para resolver los problemas de comunicación que los equipos de rescate tienen que enfrentar después de los desastres naturales. El desarrollo del sistema se completó en 2002 y fue puesto a prueba en Bam, un año después, cuando la red instalada estuvo en funcionamiento durante 10 días hasta que las redes locales fueron reparadas. Además de la red móvil, Turkcell y Ericsson, siempre cuentan con una estación base de radio, tres estaciones base móviles, diez generadores y equipos de satélite.

TSF (Télécoms Sans Frontières, Telecoms Sin Fronteras) también respondió al terremoto de Bam mediante la creación de un centro para ayudar a otras organizaciones no gubernamentales en la coordinación de sus esfuerzos de socorro. El grupo estableció una conexión satelital a internet para la transmisión de datos que incorpora al operador mini-M de Inmarsat, unidades para comunicaciones de voz y las terminales BGAN para las comunicaciones de datos de alta velocidad. El centro se orienta a permitir que organizaciones locales e internacionales puedan comunicarse con sus oficinas centrales y les ha permitido coordinar sus actividades con mayor facilidad, al tiempo que los afectados pueden comunicarse con sus familiares y amigos.

Como demuestra este ejemplo, las telecomunicaciones móviles realizan una importante contribución inmediatamente después de un desastre, pero el rápido restablecimiento de la red es esencial para aprovechar las ventajas de la telefonía móvil. Proyectos como el Sistema Turkcell de Comunicación de Emergencia y las organizaciones tales como Ericsson Response y TSF tienen como su función central la restauración rápida de la red. Tan importante es la restauración de las telecomunicaciones en respuesta a los desastres que Ericsson Response ocupa el cuarto lugar en la cadena de respuesta de emergencia internacional, después de la Oficina de las Naciones Unidas para la Coordinación de Asuntos Humanitarios (OCHA), el Programa Mundial de Alimentos y la Cruz Roja Internacional.

En colaboración con el Programa Mundial de Alimentos, la Oficina para la Coordinación de Asuntos Humanitarios y la Federación Internacional de la Cruz Roja y la Media Luna Roja, Ericsson Response ofrece equipos móviles y personal para operar en las zonas afectadas por los desastres naturales y los desastres complejos.

Está visto que los móviles pueden ofrecer el primer canal de comunicación operativa con el mundo exterior, y sin duda el primer canal para las comunidades y las personas que requieren transmitir información sobre sus necesidades

específicas y coordinar entre sí y con otros que les puedan ayudar. Si bien el acceso a móviles ha crecido a pasos agigantados, todavía hay límites en muchos países de bajos y medianos ingresos donde la penetración móvil sigue siendo muy baja. Ampliar el acceso móvil en las regiones que son vulnerables a los desastres naturales y aún tienen una baja penetración móvil sería de gran ayuda a su capacidad de recuperación en caso de desastre. El valor de las comunicaciones móviles en los desastres, además de las bondades descritas anteriormente, se ve reforzado por dos tendencias: Una es la difusión extraordinariamente rápida de los móviles en los países en desarrollo que generalmente son muy vulnerables a los desastres y su capacidad de respuesta frente a las emergencias se ve limitada por su infraestructura. La otra tendencia es establecer el contexto de la telefonía móvil por el número cada vez mayor de desastres que ocurren en el mundo8.

En resumen, el uso de telefonía móvil en casos de desastres tiene como ventajas que sus redes se pueden restaurar rápidamente, permiten el flujo descentralizado de las comunicaciones que son tan importantes para el proceso de recuperación, hay interconectividad entre todos los operadores, juegan un papel importante en el aumento de la financiación privada de alivio y coadyuvan con los sistemas de alertas tempranas.

1.3 MARCO REGULATORIO DE LAS COMUNICACIONES MÓVILES EN COLOMBIA

Las regulaciones sobre comunicaciones móviles tienen su máxima directriz internacional en la Conferencia Mundial de Radiocomunicaciones que se reúne cada cinco años con la participación de todos los países de mundo. Allí se aprueba el Cuadro de Atribuciones de Bandas de Frecuencia Global (CABFB) que establece las bandas obligatorias para un servicio en particular y las bandas sobre las que el país tiene autonomía. A nivel nacional es el Cuadro Nacional de Atribución de Bandas de Frecuencias (CNABF) quien detallada la división del espectro radioeléctrico y sus diversos usos asignando a cada servicio una o más bandas de frecuencia.

El espectro radioeléctrico es “un bien público inenajenable e imprescriptible, sujeto a la gestión y control del Estado” de conformidad con el artículo 75 de la Constitución Política de Colombia9 y los artículos 101 y 102 que establecen que se trata de un “bien público que pertenece a la Nación”.

8 GSMA. The role of mobiles in disasters and emergencies. [en línea]. 2005. <disponible en: http://www.enlightenmenteconomics.com/about-diane/assets/disasterreport.pdf> p. 16-33 9 COLOMBIA, CONGRESO DE LA REPÚBLICA. Constitución Política de Colombia. (20, julio, 1991). Gaceta Constitucional. Bogotá, 1991. No. 116.

El Ministerio de Tecnologías de la Información y las Comunicaciones es la máxima autoridad de las telecomunicaciones en Colombia, encargado entre otras responsabilidades, de planear, asignar, gestionar el espectro radioeléctrico y otorgar los permisos para su uso. Mantiene actualizado el CNABF y coordina el sector de las comunicaciones ante el Sistema Nacional para la Prevención y Atención de Desastres (SNPAD).

Con la Ley 1341 de 200910 se creó la Agencia Nacional del Espectro (ANE) como una Unidad Administrativa Especial cuyo objetivo es brindar el soporte técnico para la gestión y la planeación del espectro radioeléctrico. Adicionalmente le corresponde la vigilancia y control en coordinación con las diferentes autoridades que tengan funciones o actividades relacionadas con el espectro radioeléctrico. Para el cumplimiento de su misión, la ANE realiza actividades de monitoreo del espectro radioeléctrico y tiene funciones sancionatorias por vía administrativas en los casos de infracción al régimen del espectro definido por el Ministerio de Tecnologías de la Información y las Comunicaciones.

Algunas frecuencias o bandas de frecuencias del espectro radioeléctrico son de uso libre por parte del público en general y le corresponde autorizarlas al Ministerio de Tecnologías de la Información y las Comunicaciones sin contraprestación o pago por esa utilización. El uso de estas frecuencias o bandas de frecuencias ha sido regulado mediante las resoluciones No. 797 de 2001, 2190 de 2003, 689 de 2004, 1201 de 2004, 1713 de 2004, 2544 de 2009 del Ministerio de Tecnologías de la Información y las Comunicaciones.

Usar el espectro radioeléctrico sin permiso previo y expreso otorgado por el Ministerio de Tecnologías de la Información y las Comunicaciones acarrea sanciones de carácter administrativo, sin perjuicio de las condenas penales a que haya lugar.

En lo penal, el artículo 10 del Código Penal Colombiano establece lo siguiente:

ARTÍCULO 1O. El artículo 257 del Código Penal quedará así:

Artículo 257. De la prestación, acceso o uso ilegales de los servicios de telecomunicaciones. El que, sin la correspondiente autorización de la autoridad competente, preste, acceda o use servicio de telefonía móvil, con ánimo de lucro, mediante copia o reproducción de señales de identificación de equipos terminales de estos servicios, o sus derivaciones, incurrirá en prisión

10 COLOMBIA, CONGRESO DE LA REPÚBLICA. Ley 1341. (30, julio, 2009). Por la cual se definen principios y conceptos sobre la sociedad de la información y la organización de las TIC, se crea la ANE y se dictan otras disposiciones. Diario Oficial. Bogotá, 2009. No. 47426.

de cuatro (4) a diez (10) años y en multa de quinientos (500) a mil (1.000) salarios mínimos legales mensuales vigentes. En las mismas penas incurrirá el que, sin la correspondiente autorización, preste, comercialice, acceda o use el servicio de telefonía pública básica local, local extendida, o de larga distancia, con ánimo de lucro. Iguales penas se impondrán a quien, sin la correspondiente autorización, acceda, preste, comercialice, acceda o use red, o cualquiera de los servicios de telecomunicaciones definidos en las normas vigentes. PARÁGRAFO 1º. No incurrirán en las conductas tipificadas en el presente artículo quienes en virtud de un contrato con un operador autorizado comercialicen servicios de telecomunicaciones. PARÁGRAFO 2º. Las conductas señaladas en el presente artículo, serán

investigables de oficio11

.

En lo administrativo, la ANE está autorizada legalmente para suspender las emisiones clandestinas y el decomiso provisional de los equipos mientras se adelantan las investigaciones pertinentes y se aplican las sanciones a que haya lugar.

A continuación se presenta la legislación vigente sobre el tema de desastres y telecomunicaciones móviles en Colombia:

Ley 46 De 198812. Por la cual se crea y organiza el Sistema Nacional para la Prevención y Atención de Desastres, se otorga facultades extraordinarias al Presidente de la República, y se dictan otras disposiciones.

El Decreto Ley 919 de 1989. Por el cual se organiza el Sistema Nacional para la Prevención y Atención de Desastres y se dictan otras disposiciones. Este decreto establece entre otros:

“ARTÍCULO 15O SISTEMAS DE ALARMA Y DE COMUNICACIONES. Los sistemas de alarma que se utilicen como mecanismos de información para desastres y calamidades, cumplirán las orientaciones sobre normas y requisitos que decida impartir la Oficina Nacional para la Atención de Desastres.

11 COLOMBIA, CONGRESO DE LA REPÚBLICA. Ley 1032. (22, junio, 2006). Por la cual se modifican los artículos 257, 271, 272 y 306 del Código Penal. Diario Oficial. Bogotá, 2006. No. 46307. 12 COLOMBIA, CONGRESO DE LA REPÚBLICA. Ley 46. (2, noviembre, 1988). Por la cual se crea y organiza el Sistema Nacional para la Prevención y Atención de Desastres, se otorga facultades extraordinarias al Presidente de la República, y se dictan otras disposiciones. Diario Oficial. Bogotá, 1988. No. 38559.

ARTÍCULO 65O REDES NACIONALES. La Oficina Nacional para la Atención de Desastres promoverá la organización y funcionamiento de la red nacional de comunicaciones en situaciones de desastre o calamidad, de la red sísmica y vulcanológica Nacional, de la red de alertas hidrometeorológicas, de la red nacional de centros de reserva, de la red nacional de información y de las demás redes que técnicamente se consideren necesarias13”

Decreto 93 de 199814. Por el cual se adopta el Plan Nacional para la Prevención y Atención de Desastres PNPAD, y la Directiva Presidencial No. 05 de 2001 que dicta “las Guías o Protocolos de Actuación del Alto Gobierno para los casos de emergencias y desastres”.

Este Decreto determina las orientaciones, acciones, programas y proyectos, tanto de carácter sectorial como de orden nacional, regional y local, en las fases de prevención, atención inmediata y reconstrucción, y los temas de orden técnico, científico, jurídico, comunitario, económico, financiero, y de coordinación interinstitucional e intersectorial que deben ser tratados en desarrollo del Plan Nacional para la Prevención y Atención de Desastres. Entre otros, se encarga del diseño y mantenimiento de un Sistema Integrado de Información SII, para la prevención y atención de desastres, que contenga la información acerca de las acciones y la gestión de las entidades nacionales, regionales y locales del Sistema Nacional. Y, especialmente, en el numeral 3 del artículo 7º, promueve el mejoramiento de las redes y sistemas de comunicaciones para fortalecer la capacidad de operación y respuesta de la red de urgencias en caso de desastre.

Bajo el ordenamiento del Decreto 93 de 1998, el “Plan Nacional para la Prevención y Atención de Desastres”, crea 10 Áreas o Grupos Sectoriales, entre estos, el Grupo Sectorial # 2 para la “Coordinación de Telecomunicaciones” siendo la entidad responsable de la coordinación el Ministerio de Tecnologías de la Información y las Comunicaciones.

Existen importantes avances en tecnologías de información y comunicación TIC, además de una política nacional en la materia, sin embargo, son insuficientes para generar programas permanentes de uso de estas tecnologías y servicios en la

13 COLOMBIA. PRESIDENCIA DE LA REPÚBLICA DE COLOMBIA. Decreto Ley 919. (1, mayo, 1989). Por el cual se organiza el Sistema Nacional para la Prevención y Atención de Desastres y se dictan otras disposiciones. Diario Oficial. Bogotá, 1989. No. 38799. 14 COLOMBIA. PRESIDENCIA DE LA REPÚBLICA DE COLOMBIA. Decreto 93. (13, enero, 1998). Por el cual se adopta el Plan Nacional para la Prevención y Atención de Desastres. Diario Oficial. Bogotá, 1998. No. 43217.

divulgación del conocimiento para capacitación, toma de decisiones y concientización ciudadana15.

Ley 1341 de 200916 Por la cual se definen principios y conceptos sobre la sociedad de la información y la organización de las TIC, se crea la ANE y se dictan otras disposiciones, en su artículo 8º establece que:

En casos de atención de emergencia, conmoción interna y externa, desastres, o calamidad pública, los proveedores de redes y servicios de telecomunicaciones deberán poner a disposición de las autoridades de manera gratuita y oportuna, las redes y servicios y darán prelación a dichas autoridades en la transmisión de las comunicaciones que aquellas requieran. En cualquier caso se dará prelación absoluta a las transmisiones relacionadas con la protección de la vida humana. Igualmente darán prelación a las autoridades en la transmisión de comunicaciones gratuitas y oportunas para efectos de prevención de desastres, cuando aquellas se consideren indispensables.

Los proveedores de redes y servicios de telecomunicaciones deberán suministrar a las autoridades competentes, sin costo alguno, la información disponible de identificación y de localización del usuario que la entidad solicitante considere útil y relevante para garantizar la atención eficiente en los eventos descritos en el presente artículo17.

15 COLOMBIA. DEPARTAMENTO NACIONAL DE PLANEACIÓN. CONPES 3146. (20, diciembre, 2001). Estrategia para Consolidar la Ejecución del Plan Nacional para la Prevención y Atención de Desastres – PNPAD - en el Corto y Mediano Plazo. Bogotá, 2001. 16 COLOMBIA, CONGRESO DE LA REPÚBLICA. Ley 1341. (30, julio, 2009). Por la cual se definen principios y conceptos sobre la sociedad de la información y la organización de las TIC, se crea la ANE y se dictan otras disposiciones. Diario Oficial. Bogotá, 2009. No. 47426 17 Ibid. Artículo 8.

2. DESARROLLO E IMPLEMENTACIÓN DE UNA BTS GSM

2.1 COMPONENTES DEL SISTEMA

2.1.1 Asterisk. Para Bryant18, Asterisk es una plataforma de telefonía de código abierto distribuida bajo la licencia GPLv2 (General Public License version 2, Licencia Pública General en su segunda versión). En pocas palabras, Asterisk puede ser visto como un servidor de comunicaciones que permite realizar un procesamiento personalizado de llamadas telefónicas y que incluye una variedad de aplicaciones y servicios que pueden usarse libremente de acuerdo a la necesidad.

Asterisk soporta una variedad de tecnologías para hacer y recibir llamadas telefónicas, muchos protocolos VoIP, así como también conectividad analógica y digital a la red telefónica tradicional, o la PSTN (Public Switched Telephone Network, Red Telefónica Pública Conmutada). Asterisk al ser de código abierto tiene muchas características adicionales que pueden ser usadas para personalizar el procesamiento de llamadas telefónicas. También Bryant19 sostiene que algunas características de Asterisk son las aplicaciones comunes preconstruidas como el correo de voz y la respuesta de voz interactiva. Hay otras características que pueden ser combinadas para crear aplicaciones personalizas de voz, tales como la reproducción de un archivo de sonido, la lectura de dígitos y el reconocimiento de voz.

2.1.1.1 Arquitectura de Asterisk. Bryant20 afirma que Asterisk está construido sobre módulos. Un módulo es un componente cargable que proporciona una función específica, lo que hace que la principal característica de la arquitectura de Asterisk sea la flexibilidad, permitiendo que cada usuario pueda seleccionar qué módulos desea utilizar. Asterisk puede iniciar sin ningún módulo cargado, pero no podrá cumplir ninguna función puesto que los módulos son los que le dan a Asterisk su poder y utilidad. Hablar de la arquitectura de Asterisk, es enumerar la cantidad de posibilidades que podrían existir, de acuerdo a los módulos utilizados, sin embargo hay unos conceptos básicos que describen la arquitectura fundamental de Asterisk.

Canales. Un canal en Asterisk representa una conexión entre el sistema Asterisk y los dispositivos de telefonía (p. ej., teléfono IP, teléfono analógico, softphones). El ejemplo más común es cuando se realiza una llamada de un teléfono a un sistema Asterisk. Esta conexión está representada por un solo

18 BRYANT, Russell. Asterisk. EN: The Architecture of Open Source Applications: Elegance, Evolution, and a Few Fearless Hacks. 2011. p. 1. 19 Ibid. p. 1. 20 Ibid. p. 1-14.

canal. Un canal es específico para el tipo de protocolo que este soporta (SIP, IAX2, H.323 etc.).

Figura 1. Diagrama de conexión de Asterisk

Fuente: SOKOL, Steve Presentación Say Hello To Asterisk, Asterisk. En: https://www.brainshark.com/digium/hello?&r3f1=83b9c79498dcd8dfd7c5a69d819b929282c9c1ba9d8f9a81d883d5c2a1dc929c

Channel Bridging – Puenteo de Canal. El escenario más común es una conexión entre dos teléfonos; si una persona llama de un teléfono a otro se presentan dos conexiones al sistema Asterisk, por lo que existen dos canales. Para que pueda existir una comunicación entre los dos teléfonos se hace necesario el uso de un canal puente, el cual actúa como un canal de conexión entre los dos canales establecidos por los dos teléfonos, con el fin de transmitir datos entre ellos.

Frames – Marcos. La comunicación dentro del código Asterisk de una llamada es hecha usando marcos, los cuales son una instancia de la estructura de datos ast_frame. Los marcos pueden ser marcos de datos o marcos de señalización.

Durante una llamada telefónica básica, el flujo de marcos de datos contiene el audio de la comunicación, en cambio, los marcos de señalización son usados para enviar mensajes de eventos, como un digito que ha sido presionado, una llamada que ha sido puesta en espera, o una llamada que ha sido colgada.

2.1.1.2 Estructura de Archivos. Asterisk está compuesto de muchos recursos. Estos recursos usan muchos directorios sobre el sistema de archivos de Linux para almacenar y administrar varias funcionalidades, tales como grabaciones de voz, música en espera y archivos de configuración.

Archivos de configuración. Según Madsen et al21, el directorio /etc/asterisk contiene los archivos de configuración. Algunos archivos de configuración de Asterisk son extensions.conf, sip.conf, manager.conf, además de decenas de otros archivos que definen parámetros para una funcionalidad especifica.

Librería de recursos. Hay muchas aplicaciones que requieren de datos que provengan de fuentes externas. Por ejemplo, es necesario tener almacenada música en alguna parte del disco duro para poder utilizar la aplicación de música en espera. En el directorio /var/lib/asterisk es donde recursos como AGI scripts, música en espera, entre otros, son almacenados.

Almacenamiento temporal. Asterisk usa el almacenamiento temporal para guardar una información transitoria, como mensajes de voz, grabaciones de llamadas generadas por algunas aplicaciones. Para este fin Asterisk utiliza el directorio /var/spool/asterisk.

Módulos. Los módulos cargables de Asterisk son usualmente instalados en el directorio /usr/lib/asterisk/modules. Conocer donde están instalados los módulos puede ser importante en el momento de actualizar la versión de Asterisk, porque los módulos viejos o incompatibles generan un error en la actualización, por lo que los módulos viejos deberán ser borrados del directorio.

2.1.1.3 Tipos de módulos. Asterisk puede ser visto como una aplicación modular. Por defecto, todos los módulos instalados en el directorio predefinido serán cargados cuando Asterisk inicie, esto se hizo por simplicidad. Sin embargo, Existe un archivo de configuración llamado modules.conf que puede ser modificado para especificar exactamente cuáles módulos cargar y en qué orden, con esto se reduce carga en memoria y se obtienen beneficios de seguridad. Algunos módulos son:

Channel Drivers – controladores de canal. Los módulos controladores de canal -Channel Drivers- son los más importantes en Asterisk. Sin estos módulos, Asterisk no tendría forma de realizar llamadas. Cada llamada entra a

21 MADSEN, Leif; VAN MEGGELEN, Jim y BRYANT, Russell. Asterisk : The Definitive Guide. 3 ed. Sebastopol, CA: O’Reilly Media, 2011. ISBN 978-0-596-51734-2. p. 24.

Asterisk a través de un controlador de canal, el cual verifica el plan de marcado y asigna un canal de Asterisk a la llamada.

Aplicaciones de plan de marcado. Son usadas en el archivo extensions.conf para definir varias acciones que pueden ser aplicadas a una llamada. El plan de marcado está compuesto por una serie de reglas llamadas extensiones. Cuando una llamada entra al sistema, el número marcado es usado para encontrar la extensión en el plan de marcado que se usará para procesar la llamada. Las extensiones incluyen una lista de aplicaciones de plan de marcado las cuales serán ejecutadas sobre el canal.

Funciones de plan de marcado. Complementan las aplicaciones de plan de marcado, proporcionando muchas mejoras útiles como el manejo de cadenas de caracteres o la conectividad ODBC (Open DataBase Connectivity, Conectividad Abierta de Bases de Datos), haciendo que las aplicaciones de plan de marcado sean más dinámicas. Las funciones no pueden ser llamadas directamente en el plan de marcado, estas son llamadas dentro de las aplicaciones y con letras mayúsculas.

Traductor de códec. Asterisk soporta muchos codecs diferentes y sabe cómo traducirlos cuando sea necesario. Esto le permite a Asterisk convertir formatos de audio entre llamadas. Por ejemplo, si una llamada se establece desde un circuito PRI (Primary Rate Interface, Interfaz de Tasa Primaria) usando G.711 y necesita ser pasada a un canal SIP (Session Initiation Protocol, Protocolo de Inicio de Sesión) usando por ejemplo G.729, el pertinente traductor de códec debería realizar la conversión.

2.1.2 GNU Radio. GNU Radio es un completo software de código abierto distribuido bajo la licencia GPLv3 (General Public License version 3, Licencia Pública General en su tercera versión), que proporciona un conjunto de librerías de desarrollo para crear sistemas SDR (Software-Defined Radio, Radio Definido por Software).

GNU Radio fue desarrollado por Eric Blossom fundador de la compañía de consultoría internacional llamada Blossom Research LLC y en la actualidad es mantenido por un pequeño grupo de personas22. “De acuerdo con Blossom, la meta de GNU Radio es la de poner el software tan cerca de la antena como sea

22 RUOLIN, Z; et al. A software-defined radio based cognitive radio demonstration over FM band. EN: Wireless Communications and Mobile Computing. Enero 2010. 10(s.n) Año 2009. <Disponible en: http://onlinelibrary.wiley.com/doi/10.1002/wcm.903/abstract> [consulta: 5 Nov. 2011]. p. 5.

posible"23. Al ser software libre se tiene acceso al código fuente, además cuenta con soporte disponible a través de foros y listas de correos que lo convierte en una elección ideal para trabajos de investigación dentro de aplicaciones de radio.

Muchas de las aplicaciones que se pueden realizar con GNU Radio son simplificadas debido a que cuenta con un framework con muchos bloques que incluyen filtros, demoduladores, vocoders y otros elementos de manipulación de señales, permitiendo la simple implementación de un procesamiento digital de señales por medio de grafos (teoría de grafos)24.

El framework de GNU Radio está diseñado con una arquitectura de dos capas. La capa de diseño y la capa de procesamiento de señal. En la capa superior (capa de diseño) se usa el lenguaje de programación Python para construir y correr un grafo. En la capa inferior (capa de procesamiento) los bloques de DSP (Digital Signal Processing, Procesamiento Digital de Señal) son implementados en el lenguaje de programación C++. En el grafo realizado en Python los nodos son los bloques de DSP y las aristas los enlaces del flujo de datos25.

Cada uno de los bloques de procesamiento es definido para tener puertos de entrada y de salida. Algunos bloques tienen únicamente puertos de salida o puertos de entrada. Estos sirven como fuente de datos (sources) y sumideros (sinks) en el grafo. Existen fuentes que leen datos de un archivo o del ADC (Analog-to-Digital Converter, Conversor Análogo a Digital), y sumideros que escriben datos a un archivo, al DAC (Digital-to-Analog converter, Conversor Digital a Análogo) o a un display gráfico26.

Un ejemplo de un grafo se muestra en la Figura 2. Este ejemplo genera un tono de marcado y es un ejemplo simple, comúnmente llamado el “Hola Mundo de GNU Radio”.

23 BLOSSOM, Eric. GNU Radio: Tools for Exploring the Radio Frequency Spectrum. [en línea]. Jun 01, 2004. <Disponible en: http://www.linuxjournal.com/article/7319> [consulta: 10 Ene. 2012]. 24 WATERMEYER, Kalen. Design of a hardware platform for narrow-band Software Defined Radio applications. Ene. 2007. [en línea]. <Disponible en: http://www.rrsg.uct.ac.za/theses/msc_theses/kwatermeyer_thesis.pdf > [consulta: 2 Feb. 2012]. p. 18. 25 MEŠKOVIĆ, Saša. Implementation of Uncoordinated Direct Sequence Spread Spectrum (U-DSSS) using Software Defined Radios. Abril. 2008. [en línea]. <Disponible en: http://e-collection.library.ethz.ch/eserv/eth:30545/eth-30545-01.pdf> [consulta: 2 Feb. 2012]. p. 9. 26 BLOSSOM, Eric. Op. cit. p. 2.

Como se puede ver en la figura 2 esta tiene dos fuentes de datos (sources) con dos salidas que representan dos señales senoidales y un sumidero (sink) con dos entradas para los canales izquierdo y derecho de la tarjeta de sonido. Más adelante se ejecutará este ejemplo para probar que la instalación de GNU Radio fue exitosa.

GNU Radio es el principal software utilizado en una estructura de trasmisión y recepción de un completo SDR. Un SDR, también conocido como "software Radio" se refiere a la clase de radios reconfigurable en la cual el comportamiento de la capa física puede ser significativamente alterado haciendo un cambio en el software sin tener que realizar cambios en el hardware27.

Figura 2. Modelo de grafo. “Hola Mundo de GNU Radio”

Fuente: Autores

El término "software Radio" tiene origen en las aplicaciones hechas en el sector militar y de defensa, con el proyecto SpeakEasy siendo uno de los primeros en desarrollarse. SpeakEasy estableció un sistema para comunicarse con 10 diferentes sistemas de radio desde un simple dispositivo. Este fue un sistema basado en hardware que carecía de la flexibilidad que brinda el software. Mientras el proyecto seguía avanzando, en el año 1991 Joseph Mitola III acuñó el término "Software Radio" para definir el cambio de un 80% de las funcionalidades

27 SHAJEDUL HASAN, S.M.; Balister, P. Prototyping a Software Defined Radio Receiver Based on USRP and OSSIE. Dic 14, 2005. [en línea]. <Disponible en: http://www.ece.vt.edu/swe/chamrad/crdocs/CRTM01_051214_USRP.pdf> [consulta: 11 Ene. 2012]. p. 1.

implementadas por hardware, a un 80% de las funcionalidades siendo implementadas en software28.

Con GNU Radio el mismo hardware puede ser reprogramado para soportar diferentes bandas de frecuencia, diferentes tipos de modulación y diferentes anchos de banda resultando significativa la reducción del tiempo de desarrollo y, al mismo tiempo, ofreciendo mayor eficiencia y velocidad de operación29. Idealmente la digitalización de la señal recibida es hecha cerca a la antena y todos los requerimientos de procesamiento son realizados por software presentando las siguientes ventajas30,31

Multifuncionalidad: Por las capacidades de reconfiguración.

Movilidad global: Tiene compatibilidad con la mayoría de los estándares de comunicaciones populares del mundo.

Compacto y eficiente: Al igual que el hardware puede ser reusado para implementar varios sistemas.

Un simple dispositivo SDR puede realizar múltiples funciones simplemente cambiando módulos de software.

Actualizaciones del sistema pueden ser implementadas en software por medio de descargas de Internet. Esto incluye actualizaciones del software que inciden en las configuraciones del hardware.

Sistemas de procesamiento de señal altamente configurables y flexibles, más fáciles de modificar.

Pueden ser desarrollados protocolos de comunicación más flexibles que se adapten a su entorno y transparentes para el usuario.

Con el fin de soportar los desarrollos adicionales y añadir un flexible RF front end de código abierto a GNU Radio, Matt Ettus, un miembro de GNU Radio Team,

28 CASEY, Douglas. gnu radio and the usrp as a solution for remote emergency monitoring. Año 2004. [en línea]. <Disponible en: http://www.csb.uncw.edu/mscsis/complete/pdf/TuckerCasey_Final.pdf> [consulta: 10 Ene. 2012]. p. 19. 29 SHAJEDUL HASAN, S.M. Op. cit. p. 1. 30 WATERMEYER, Kalen. Op. cit. p.14. 31 SHAJEDUL HASAN, S.M. Op. cit. p. 1.

fundó la ETTUS RESEARCH LLC e inició a construir el USRP32. Con este desarrollo, la estructura de un SDR completo tenía a GNU Radio en el mundo del software y el USRP en el mundo del hardware, con lo que el USRP fue el puente entre el mundo de señales análogas de RF y el mundo digital manipulado por software.

Como muestra la figura 3, un software radio transceiver (transmisor/receptor) consiste de tres principales bloques funcionales: la sección RF, la sección IF y el código del usuario.

Figura 3. Diagrama de la arquitectura de un SDR

Fuente: Autores

La sección de RF también llamada RF front end, en el lado del receptor tiene como función trasladar un rango de frecuencias altas en su entrada a un rango de frecuencias más bajo en su salida. La frecuencia central del rango de salida es llamada Frecuencia Intermedia o IF. Lo anterior se hace para que los ADC’s puedan procesar la señal de radio frecuencia.

En la sección de IF es donde los ADC’s digitalizan la señal y envían los datos a los DDC’s (Digital Down Converters, Conversores Digitales de Bajada). Los DDC’s

32 MEŠKOVIĆ, Saša. Implementation of Uncoordinated Direct Sequence Spread Spectrum (U-DSSS) using Software Defined Radios. Abr. 2008. [en línea]. <Disponible en: http://e-collection.library.ethz.ch/eserv/eth:30545/eth-30545-01.pdf> [consulta: 2 Feb. 2012]. p. 6.

diezman la señal y trasladan la señal a banda base antes de ser enviada por el cable USB al mundo del software.

La parte de la trasmisión es muy similar. La señal banda base debe ser llevada a la frecuencia intermedia; se realiza por medio de los DUC’s (Digital Up Converters, Conversores Digitales de Subida), luego se pasa a través de los DAC’s para pasar al mundo análogo y por último por el RF front end del lado del trasmisor para obtener la señal en la frecuencia deseada.

En la sección del código del usuario es donde juega un papel importante GNU Radio para implementar los bloques de procesamiento de señal en banda base.

Después de conocer la estructura de un SDR y la de GNU Radio, es importante comprender qué es y cuál es la función del USRP como base del hardware para el proyecto OpenBTS.

2.1.3 Universal Software Radio Peripheral (USRP). USRP es un dispositivo de Hardware libre, que en conjunto con un computador permite implementar y diseñar sistemas de radiocomunicaciones potentes, flexibles a muy bajo costo y mínimo esfuerzo. Para probar su completo valor simplemente es necesario descargar e instalar GNU Radio33.

La potente combinación de Hardware y Software libre se convierte en la plataforma ideal para que un computador convencional funcione como un software radio de alto ancho de banda. La gran comunidad de desarrolladores y usuarios han contribuido a la filosofía de diseño básico detrás del USRP que tiene como objetivo realizar todo el procesamiento de señales específicas como modulación, demodulación, interpolación. Todo lo anterior en un computador sin tener que comprar ningún software o pagar una licencia34.

GNU Radio no es la única opción, USRP presenta un enorme nivel de flexibilidad que se ajusta a las opciones de los usuarios. Algunos de ellos han creado su

33 ETTUS RESEARCH LLC. USRP motherboard datasheet. [en línea]. Actualizado, año 2010. <Disponible en: http://www.olifantasia.com/gnuradio/usrp/files/datasheets/er_ds_usrp_v5b.pdf> [consulta: 10 Oct. 2011]. p. 1. 34 HAMZA, Firas. The USRP under 1.5X Magnifying Lens!. [en línea]. Actualizado 12 de junio de 2008. <Disponible en: http://gnuradio.org/redmine/attachments/download/129> [consulta: 5 Octubre 2011]. p. 5.

propio ambiente SDR para correr sobre USRP, mientras otros han usado USRP integrado con software como LabVIEW® o MATLAB®/Simulink®35.

A medida del crecimiento en el uso del USRP se ha ido creando un conjunto de productos que han sido agrupados dentro de lo que la ETTUS RESEARCH LLC ha denominado la familia de productos USRP. El USRP1 es el hardware original de la familia de productos USRP; está conformado por unos componentes necesarios para el procesamiento de señales y la implementación de aplicaciones de radio.

El montaje completo del USRP1 cuenta con 2 niveles de tarjetas: el primero es la tarjeta madre (motherboard) en donde se puede identificar la FPGA, la alimentación, la conexión vía USB y los 4 slots para conectar el segundo nivel conformado por las tarjetas hijas (daughterboards), que proporcionan flexibilidad, integrando completamente un RF front end que es implementado por medio de estas tarjetas hijas añadidas a el USRP1.

El USRP1 tiene cuatro ADC’s de alta velocidad, cada uno a 12 bits por muestra, con una tasa de 64 millones de muestras por segundo (64 MSPS); en teoría se podría muestrear una señal de hasta 32 MHz. Cuenta con un PGA (Programmable Gain Amplifier, Amplificador de Potencia Programable) antes de los ADC’s para amplificar la señal de entrada y utilizar el rango completo en caso de que la señal sea débil. También tiene 4 DAC’s de alta velocidad para trasmisión, cada uno a 14 bits por muestra y una tasa de 128 millones de muestras por segundo (128 MSPS), contando de igual forma con un PGA después de los DAC’s que proporcionan hasta 20 dB de ganancia. Estos 4 canales de entrada y 4 canales de salida son conectados a una FPGA (Field-Programmable Gate Array, Matriz de Compuertas Programables en Campo) Altera Cyclone EP1C12, la cual se conecta a un chip de interfaz USB2.0 (Universal Serial Bus versión 2, Bus Serial Universal versión 2), el Cypress FX2, y luego al computador. Hay que aclarar que la conexión del USRP1 al computador se realiza con una interfaz USB2.0, no trabaja con USB1.1. La FPGA es la parte más importante en el sistema del USRP1. Básicamente lo que hace es realizar operaciones matemáticas de alto ancho de banda y reducir la tasa de datos para que puedan ser enviados a través de la interfaz USB2.0 al computador. En el USRP1, el procesamiento con alta frecuencia de muestreo se realiza en la FPGA, mientras el procesamiento con baja frecuencia de muestreo se realiza en el computador.

La configuración básica de la FPGA incluye dos DDC’s completos, pero también es posible la implementación de 4 DDC’s sin filtros de media banda. Esto permite tener 1, 2 o 4 canales de recepción separados. Las salidas de los ADC’s van conectadas a las entradas de los DDC’s. Los DDC’s mezclan, filtran y diezman (desde 64 MHz) señales de entrada en la FPGA. Se utilizan en la recepción, 35 ETTUS RESEARCH LLC. Op. cit. p. 2.

esencialmente por dos razones: primero, para convertir la señal de banda de frecuencia intermedia a una señal en banda base y, segundo, para diezmar la señal, logrando que la tasa de datos pueda ser adaptada a la interfaz USB2.0 y que sea razonable a la capacidad de procesamiento de los computadores. En la trasmisión se realiza el proceso inverso: se necesita convertir una señal banda base a una señal de frecuencia intermedia, y enviarla a través los DAC’s. Esto se hace a través de los dos DUC’s. En el lado de la trasmisión también se usan filtros interpoladores CIC (Cascaded Integrator-Comb, Peine Integrador en Cascada) que interpolan las muestras antes de trasladar la señal digital a la frecuencia intermedia por los DUC’s. Los DDC’s y DUC’s combinados con las altas tasas de muestreo simplifican en gran medida los requerimientos de filtrado analógico.

La FPGA está programada con el lenguaje de descripción de hardware Verilog y sintetizada con la edición web libre de Altera, Quartus II. El PCB que viene diseñado con la herramienta PADS. Los esquemáticos están hechos en gEDA (GPL Electronic Design Automation, GPL Automatización de Diseño Electrónico).

En la Figura 4 se puede ver el diagrama de bloques del USRP1 incluyendo las tarjetas hijas que forman el RF front end.

El USRP está en uso en todo el mundo en una amplia variedad de aplicaciones36. El USRP con frecuencia es usado para aplicaciones de investigación, sin embargo, también ha sido desplegado en muchos sistemas comerciales y de defensa. Las principales aplicaciones son las siguientes:

Aplicaciones comerciales. Hay muchas aplicaciones para la USRP en los sistemas comerciales. Un ejemplo, Path Intelligence Ltd., usa la familia de productos USRP para rastrear el tráfico de los peatones en los centros comerciales. La capacidad de antenas en fase de la USRP permite a Path Intelligence Ltd. determinar las localizaciones de los compradores recibiendo las transmisiones del canal de control de los celulares.

Aplicaciones de defensa y seguridad nacional. Las redes de campo de batalla, las redes de supervivencia, puentes de comunicación para la seguridad pública.

Investigaciones en redes inalámbricas. Sistemas MIMO, análisis espectral, transmisores y receptores de FM, radio cognitiva.

Aplicaciones pedagógicas. Implementación de software radio, estudio de sistemas y señales, procesamiento digital de señales, sistemas de

36 ETTUS RESEARCH LLC. Op. cit. p.1.

comunicaciones. Radioastronomía, rastreo de fauna y flora, RFID, equipos de prueba personalizados.

Figura 4. Diagrama de bloques del USRP1

Fuente: https://www.ettus.com/content/files/Ettus_USRP1_DS_FINAL_1.27.12.pdf

2.1.4 Sistema Global para las Comunicaciones Móviles (GSM). En los años ochenta existían en Europa diferentes sistemas celulares analógicos, pero sus ventajas se veían opacadas por la incompatibilidad entre ellos y su baja capacidad. Esto, más la necesidad de establecer compatibilidad con la digitalización que estaba viviendo la red telefónica pública alámbrica, conllevó a que la CEPT (Conférence européenne des administrations des postes et des télécommunications, Conferencia Europea de Administraciones de Correos y Telecomunicaciones) estableciera en 1982 un grupo especial móvil para la creación de un estándar celular europeo único que se encargó de la estandarización de las interfaces entre subsistemas, la arquitectura de protocolos y servicios, basándose en los estándares mundiales de la CCITT (Consultative Committee for International Telegraphy and Telephony, Comité Consultivo Internacional Telegráfico y Telefónico) y el CCIR (Comité Consultatif International des Radiocommunications, Comité Consultivo Internacional de Radiocomunicaciones).

En 1989 la responsabilidad de la estandarización pasó de manos del CEPT al ETSI (European Telecommunications Standards Institute, Instituto Europeo de Normas de Telecomunicaciones), el cual se planteó como objetivos: proveer mejor calidad de servicio que los sistemas analógicos, ofrecer servicios telefónicos en toda Europa (roaming), y permitir trasmisión de datos; todo esto de manera económica, eficiente con el espectro, flexible y que aprovechara las ventajas de los sistemas digitales37. Luego, debido a su gran crecimiento, se reservaron las siglas obteniendo como resultado el sistema GSM.

GSM fue introducido en Europa en 1992, y fue el sistema de telefonía móvil de segunda generación más exitoso, extendiéndose en gran parte del mundo. Basados en GSM han surgido otros sistemas y sus mejoras le han llevado a introducirse en la tercera generación de la telefonía móvil celular, cuya extensión se denomina UMTS (Universal Mobile Telecommunications System, Sistema Universal de Telecomunicaciones Móviles).

Como se puede observar en la Figura 5, la arquitectura de la red GSM se divide en varios niveles jerárquicos denominados subsistemas. Empezando por la MS, que consiste en dos elementos: el ME (Mobile Equipment, Equipo Móvil) y una tarjeta SIM (Subscriber Identity Module, Módulo de Identidad de Usuario). El equipo móvil además cuenta con un número de identificación internacional IMEI (International Mobile Equipment Identity, Identidad Internacional de Equipo Móvil). Este número está grabado en el teléfono por el fabricante y es único. La SIM es una tarjeta que personaliza una terminal móvil, permite que un usuario pueda acceder a la red y obtener los servicios a los que está inscrito desde cualquier equipo de usuario.

La estación móvil se conecta por medio de una interfaz de aire “Um” a la BTS más próxima, la cual dispone de los dispositivos para la trasmisión y recepción de señales de radio, incluyendo las antenas para establecer la comunicación entre la estación móvil y la red GSM. Varias BTS’s hacen parte del Subsistema BSS (Base Station Subsystem, Subsistema de Estación Base) que consta además de un BSC (Base Station Controller, Controlador de Estación Base). El BSC administra y asigna los canales de radio de las BTS’s; y es el encargado de controlar los saltos de frecuencia y la transferencia de llamadas entre BTS’s cuando el usuario está en movimiento. El BSC representa la conexión entre la MS y el MSC (Mobile Switching Center, Centro de Conmutación Móvil), que hace parte del siguiente subsistema, llamado NSS (Network Switching Subsystem, Subsistema de Red Conmutada). El MSC es el corazón de la red GSM. Este, une grupos vecinos de BSS’s por medio de enlaces terrestres de microondas, controla la señalización, el procesamiento de señales, la transferencia de llamadas entre células, el ruteo de llamadas, las funciones básicas de conmutación y maneja interfaces con otros

37 RODRIGUEZ MUÑOZ, David. Sistemas inalámbricos de comunicación personal: El sistema panaeuropeo: GSM. 1 ed. México, D.F.: Alfaomega, 2001. p. 227.

MSC’s. Hay otro tipo de MSC llamado GMSC (Gateway Mobile Switching Center, Gateway Centro de Conmutación Móvil) que proporciona el enlace a la red telefónica pública. El NSS también consta de varias bases de datos para llevar a cabo las funciones del registro del movimiento de usuarios y del control de llamadas dentro de la PLMN (Public Land Mobile Network, Red Móvil Terrestre Pública). Dichas bases de datos permiten itinerancia (roaming), contienen información de seguridad de los equipos, como copia de los códigos PIN (Personal Identification Number, Número de Identificación Personal), para evitar que se registren usuarios no permitidos. Estas bases de datos, HLR (Home Location Register, Registro de Ubicación Base), VLR (Visitor Location Register, Registro de Ubicación de Visitante) y AUC (Authentication User Center, Centro de Autenticación del Usuario) son una aplicación del concepto de red inteligente, aplicado a GSM. En GSM se aplica el proceso de transferencia de llamada, el cual permite cambiar la conexión existente entre la estación base y el móvil a una nueva estación base. Esto se hace por asistencia de la estación móvil, la cual monitorea los niveles de la señal recibida y la tasa de error de las estaciones bases que la rodean.

Figura 5. Arquitectura básica de la red GSM

Fuente: MUÑOZ, David. Sistemas inalámbricos de comunicación personal. México: Alfaomega, 2002.

En la red GSM se define también un sistema específico de numeración que identifica a una estación móvil. Dentro de este sistema se encuentra el MSISDN (Mobile Subscriber ISDN, Suscriptor Móvil ISDN), el cual es un número de identificación único de teléfono compuesto por el CC (Country Code, Código del País) más el NDC (National Destination Code, Código de Destino Nacional) que es asignado a cada operador, seguido por el SN (Subscriber Number, Número del

Suscriptor). El LAC (Location Area Code, Código de localización de área), es un número de tamaño fijo usado para identificar la ubicación de un área dentro de la red. El IMSI (International Mobile Subscriber Identity, Identidad Internacional del Suscriptor Móvil) es un número único que permite la identificación única de una MS dentro de la red GSM. El número máximo de dígitos del IMSI es 15 y está compuesto de tres partes, el MCC (Mobile Country Code, Código del País), el MNC (Mobile Network Code, Código de la Red) y el MSIN (Mobile Subscriber Identification Number, Número de Identificación del Suscriptor). El MCC identifica en qué país está la MS, el MNC identifica en qué operador de telefonía móvil está registrada la MS y el MSIN es un número único que identifica a la MS dentro de la red GSM. El TMSI (Temporary Mobile Subscriber Identity, Identidad Temporal del Suscriptor Móvil) es un número temporal usado para identificar una MS en un área local específica. El TMSI es asignado por la red a la MS durante su registro inicial y es renovado cada vez que se produce una nueva interacción con la red, como una actualización de posición donde se cambia de BTS. El CI (Cell Identity, Identidad de Celda) es un número único usado para identificar cada celda.

Los componentes de los diferentes subsistemas de la red GSM se interconectan por medio de interfaces como se aprecia en la Figura 5. Las interfaces más relevantes son la interfaz Um, la interfaz A-bis y la interfaz A38. Entre la MS y la BTS está la interfaz Um. La interfaz A-bis se encuentra entre la BTS y el BSC. La interfaz A está entre el BSC y el MSC. Estás interfaces establecen la comunicación entre los elementos de la red GSM.

Para poder entender el funcionamiento de OpenBTS que se verá más adelante, es necesario tener un conocimiento práctico de cómo las redes GSM y los celulares interactúan. GSM como un sistema de telecomunicaciones requiere de protocolos de señalización para coordinar las funcionalidades distribuidas. Estos protocolos de señalización son especificados usando el concepto del modelo de referencia OSI (Open System Interconection, Interconexión de Sistemas Abiertos), por capas. GSM está estructurado en tres capas generales que conforman la pila de protocolos GSM (GSM protocol stack) dependiendo de la interfaz39. De acuerdo con Hernando40, la especificación del protocolo GSM es muy extensa y cubre en detalle todo el funcionamiento de la red. Estas especificaciones se dividen en series que tratan temas específicos tal como muestra el Cuadro 141. El presente

38 GORRICHO, Mónica y GORRICHO, Juan. Comunicaciones móviles. Barcelona: UPC, 2002. P. 79. 39 HAMDI, Fatma. GSM/GPRS Evaluation and optimization tool. Año 2006. [en línea]. <Disponible en: http://es.scribd.com/doc/49823859/18/Figure-1-2-Signalling-protocol-structure-in-GSM> [consulta: 2 feb. 2012]. p. 10. 40 HERNANDO RÁBANOS, José María. Comunicaciones móviles. 2 ed. Madrid: Centro de Estudios Ramón Areces, 2004. p. 344. 41 Pueden ser descargadas de http://webapp.etsi.org/key/queryform.asp

trabajo se centró en la interfaz de aire Um que describe la forma como la MS se comunica con la BTS.

Cuadro 1. Series y temas de la especificación GSM

Serie Tema

01.xx Cuestiones generales

02.xx Aspectos de servicio

03.xx Aspectos de red

04.xx Interfaz y protocoles MS-BS

05.xx Capa física de radio

06.xx Codificación de la voz

07.xx Adaptadores de terminales para MS

08.xx Interfaces BS-MSC

09.xx Interfuncionamiento de redes

10.xx Interfuncionamiento de servicios

11.xx Especificaciones y homologación

12.xx Operación y mantenimiento

Fuente: GORRICHO, Mónica y GORRICHO, Juan. p. 23.

La interfaz Um está definida en las series GSM 04.xx y 05.xx de la especificación. Lo primero que hay que mencionar es la frecuencia de operación de GSM. Actualmente hay muchas bandas para el uso de GSM; las más comunes son 450 MHz, 850 MHz, 900 MHz, 1800 MHz, y 1900 MHz. GSM utiliza la técnica de acceso FDD/FDMA/TDMA lo que significa que el duplexado se hace en frecuencia FDD (Frequency Division Duplex, Dúplex por División en Frecuencia), y el multiplexado de las comunicaciones es una combinación de multiplexación en frecuencia FDMA (Frequency Division Multiple Access, Acceso Múltiple por División en Frecuencia) y en tiempo TDMA (Time Division Multiple Access, Acceso Múltiple por División en el Tiempo), combinado con saltos de frecuencia (Frecuency Hopping)42. El uso de FDD divide la banda de operación de GSM en dos, definiendo una banda de frecuencia usada para la trasmisión de la MS a la BTS, conocida como uplink (enlace de subida) y otra banda de frecuencia usada para la trasmisión de la BTS a la MS, conocida como downlink (enlace de bajada).

42 GORRICHO, Mónica y GORRICHO, Juan. Op. cit. p. 23.

Al usar la técnica FDMA las bandas de uplink y downlink son separadas en canales de radio con un ancho de banda de 200 KHz. Los canales de uplink y downlink son separados por una frecuencia de offset que depende de la banda de operación de GSM y son identificados por un número llamado ARFCN (Absolute Radio Frequency Channel Number, Número de Canal de Radio Frecuencia Absoluto). El ARFCN describe un par de frecuencias: una para uplink y otra para downlink. En general el ARFCN determina los canales de trasmisión y recepción que se van a usar.

En el Cuadro 2 se muestran los rangos de frecuencia, offset, y ARFCN para las bandas más comunes de GSM.

Cuadro 2. Rangos de frecuencia, offset y ARFCN

GSM450 GSM850 GSM900 GSM1800 GSM1900

Rango frecuencia uplink

450 a 458 MHz

824 a 849 MHz

890 a 915 MHz

1710 a 1785 MHz

1850 a 1910 MHz

Rango frecuencia downlink

460 a 468 MHz

869 a 894 MHz

935 a 960 MHz

1805 a 1880 MHz

1930 a 1990 MHz

ARFCN 259 a 293 128 a 251 1 a 124 512 a 885 512 a 810

Offset 10 MHz 45 MHz 45 MHz 95 MHz 80 MHz

Fuente: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSIntroduction_To_GSM

La Figura 6 muestra un esquema en frecuencia para la banda GSM900. Se puede observar la combinación de las técnicas FDD/FDMA. GSM usa TDMA como el esquema de acceso al medio sobre la interfaz de aire Um. Cada canal de radio es dividido en 8 intervalos de tiempo (time slots) numerados de TS0 a TS7.

El uso de TDMA permite que un grupo de usuarios simultáneos compartan un simple canal de radio utilizando diferentes intervalos de tiempo. Cada intervalo de tiempo tiene una duración de 576.9 µs y es usado para facilitar la comunicación entre la MS y la BTS. El método de modulación usado en GSM es GMSK (Gaussian Minimum-Shift Keying, Desplazamiento Mínimo Gausiano) el cual proporciona una tasa de trasmisión de 270.833 Kbps, con lo cual un máximo de 156.25 bits son trasmitidos en cada intervalo de tiempo. Los 8 intervalos de tiempo forman un frame TDMA de 1250 bits con una duración de 4.615 ms. Los datos trasmitidos durante un intervalo de tiempo definen la unidad de trasmisión de GSM que es conocida como ráfaga (burst), por lo que cada ráfaga se compone de 156.25 bits. La trasmisión en GSM se realiza en secuencias de ráfagas. Hay cuatro tipos de ráfagas: NB (Normal Burst, Ráfaga Normal), FB (Frequency Correction Burst, Ráfaga de Corrección de Frecuencia), SB (Synchronization

Burst, Ráfaga de Sincronización) y AB (Access Burst, Ráfaga de Acceso). La que más se usa es la ráfaga normal que contiene 114 bits disponibles para información. El formato de las ráfagas es descrito en la especificación GSM 05.02 sección 5.243.

Figura 6. Esquema de frecuencia para la banda GSM900

Fuente: http://www2.informatik.hu-berlin.de/~goeller/isdn/GSMDmChannels.pdf

La Figura 7 muestra la combinación de las técnicas FDMA/TDMA.

El multiplexado en el tiempo origina canales lógicos que se subdividen en canales de control y canales de tráfico. Los canales de control se utilizan en la administración del funcionamiento de la red GSM. Por su parte, los canales de tráfico son utilizados para el transporte de voz o datos de usuario. Los canales lógicos son utilizados para propósitos específicos de la comunicación entre la BTS y la MS y pueden ser divididos en tres categorías: canales de tráfico, canales de control dedicados y canales de control no dedicados. Para la trasmisión por estos canales se definen los multiframes de canales de control y los multiframes de canales de tráfico. Los multiframes de canales de control se componen de 51 frames TDMA y los multiframes de canales de tráfico se componen de 26 frames TDMA.

43

RANGE NETWORKS. OpenBTS P2.8 Users’ Manual. Año 2011. [en línea]. <Disponible en: https://wush.net/trac/rangepublic/attachment/wiki/WikiStart/SoftwareP2.8Manual.pdf> [consulta: 11 Ene. 2012]. P.19.

Figura 7. Combinación de las técnicas FDMA/TDMA

Fuente: http://www.aws.cit.ie/personnel/dpesch/notes/msc_sw/gsm_radio_interface.pdf

2.1.4.1 Canales de tráfico

TCH/F (Traffic Channel Full Rate, Canal de Tráfico de Tasa Completa): utilizado para trasmitir información a y desde el usuario. La información puede ser voz codificada y comprimida o datos como mensajes de texto. Para la trasmisión de voz por este canal la velocidad es de 13 Kbps y las velocidades para la trasmisión de datos son 14.4 Kbps, 9.6 Kbps, 4.8 Kbps y menor o igual a 2.4 Kbps.

TCH/H (Traffic Channel Half Rate, Canal de Tráfico de Tasa Media): utilizado para trasmitir información a y desde el usuario ocupando la mitad del ancho de banda que el TCH/F, la velocidad para la trasmisión de voz codificada y comprimida es de 5.6 Kbps y las velocidades para la trasmisión de datos son 4.8 Kbps y menor o igual a 2.4 Kbps.

2.1.4.2 Canales de control dedicados

SDCCH (Standalone Dedicated Control Channel, Canal de Control Dedicado Independiente): Es un canal de señalización usado para la configuración inicial de una llamada, registro, envío y recepción de mensajes cortos SMS y actualización de la posición entre la MS y la BTS.

FACCH (Fast Associated Control Channel, Canal de Control Asociado Rápido): Es un canal de señalización asociado al canal de tráfico, trasmite señalización de manera inmediata o urgente como por ejemplo la petición de un traspaso.

SACCH (Slow Associated Control Channel, Canal de Control Asociado Lento): Es un canal de señalización asociado al canal de tráfico o a un SDCCH, usado para controlar y supervisar la comunicación entre la MS y la BTS. Por este canal se envía Información sobre la potencia trasmitida y recibida e instrucciones de temporización.

2.1.4.3 Canales de control no dedicados

BCCH (Broadcast Control Channel, Canal de Control de Difusión): Este canal es usado para trasmitir información de los parámetros de identificación del sistema necesarios para el acceso a la red. Los parámetros incluyen el LAC, el MCC/MNC, las frecuencias de las celdas vecinas y parámetros de acceso.

SCH (Synchronization Channel, Canal de Sincronización): En este canal se trasmite información de sincronización e identificación de la BTS. Es usado por la MS en la recepción para la sincronización de los frames y de esta forma conocer el tipo de información trasmitida en cada intervalo de tiempo.

FCCH (Frequency Correction Channel, Canal Corrección de Frecuencia): Por este canal se trasmite le señal portadora sin modular. Es usado por la MS para sincronizar su frecuencia interna con la frecuencia exacta de la BTS.

CCCH (Common Control Channels, Canales de Control Común): sirven para regular el acceso de la MS a la red. Se utilizan para la búsqueda y asignación de canales de señalización a la MS.

RACH (Random Access Channel, Canal de Acceso Aleatorio): Canal utilizado por la MS para intentar acceder a la red solicitando un canal SDCCH de la BTS. Esta es la primera petición hecha por la MS para acceder a la red.

2.1.5. OpenBTS. Según Burgess44, a mediados del 2007, Kestrel Signal Processing, Inc., una pequeña empresa consultora de software radio al norte de California, inició a escribir una implementación de una estación base GSM. El proyecto fue liberado a la comunidad y conocido como OpenBTS.

44

BURGESS, David A. Low Cost Cellular Networks with OpenBTS. Año 2010. <Disponible en: http://www.osbr.ca/ojs/index.php/osbr/article/view/1052/1011> [consulta: 15 Feb. 2012].

OpenBTS es una aplicación Unix que usa un software radio para generar una interfaz de aire GSM "Um" que permite operar con cualquier teléfono celular GSM estándar. Para conectar las llamadas usa un software VoIP PBX (Private Branch Exchange, Ramal privado de conmutación), llamado Asterisk45.

El proyecto OpenBTS permite que los celulares vean una completa red GSM a través de su interfaz de aire "Um", donde ellos a su vez son vistos como terminales VoIP utilizando el protocolo SIP, es decir, como un cliente SIP dentro de Asterisk, permitiendo de esta forma hacer llamadas telefónicas sin usar las redes de los operadores convencionales. El proyecto OpenBTS forma la base de un nuevo tipo de red celular que puede ser desarrollada y operada a un costo más bajo que las tecnologías existentes en muchas aplicaciones, incluyendo zonas rurales y redes privadas de celular en áreas remotas46.

Actualmente el proyecto OpenBTS es mantenido por la compañía Range Networks, fundada por David Burgess y Harvind Samra, los desarrolladores originales y arquitectos del software detrás de OpenBTS.

OpenBTS está basado en hardware y software libre y está distribuido en dos formas:

Forma de release público ("P"): Es distribuido bajo la licencia AGPLv3 (Affero General Public License, version 3, licencia pública general de Affero, tercera versión) con los copyrights asignados a la FSF (Free Software Foundation, Fundación para el software libre). El release público es para propósitos de experimentación, educación, evaluación y prueba de conceptos para proyectos de investigación. OpenBTS está construido en el lenguaje de programación orientado a objetos C++. Además de un manejo de programación, se requiere tener un buen entendimiento de la especificación GSM.

Forma de release comercial ("C"): El release comercial es instalado en los productos de Range Networks bajo una mezcla de licencias de GPL y otras que no son GPL. El código fuente de los componentes de la instalación de OpenBTS licenciados bajo la licencia GPL está disponible para los clientes comerciales. El

45 BURGESS, David A. y SAMRA, Harvind S. The Open BTS Project. [en línea]. 3 Ago. 2008. <Disponible en: http://www.ahzf.de/itstuff/papers/OpenBTSProject.pdf> [consulta: 2 Feb. 2012]. p. 3. 46 GNU Radio Project. The OpenBTS Wiki Subspace. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTS> [consulta: 9 Oct. 2011].

release comercial "C" proporciona características adicionales de seguridad, escalabilidad y la operación de redes multi-BTS47.

Este release comercial es destinado a usuarios quienes:

Necesiten proporcionar un servicio celular en la industria, gobierno o aplicaciones comerciales.

El modelo de negocio es incompatible con la licencia GPLv3, o

Requieren soporte comercial, monitoreo de redes u otros servicios profesionales.

La arquitectura de OpenBTS es diferente de la arquitectura jerárquica GSM convencional, donde la BTS GSM es manejada externamente por la BSC y la conexión de las llamadas se realiza en un remoto MSC. Debido a la diferencia en la arquitectura se hace referencia al producto final del proyecto OpenBTS con el nombre de access point GSM (punto de acceso GSM).48,49

OpenBTS hace uso del hardware USRP y el software GNU Radio corriendo sobre un computador para construir una completa aplicación de software radio. Además utiliza el software Asterisk para realizar el control y conmutación de las llamadas. La Figura 8 muestra la arquitectura de Open BTS en la que se observa un servidor Asterisk conectado a través de una red IP privada. Sin embargo, Asterisk puede ser instalado en el mismo computador corriendo localmente junto a GNU Radio y OpenBTS. De esta forma se realizó en el presente trabajo de grado.

Los datos enviados por la MS a la BTS (uplink) son capturados por la antena receptora conectada a la tarjeta hija de recepción. Esta última traslada la señal a una frecuencia intermedia para que el USRP pueda digitalizar los datos por medio de los ADC’s, lo cual permite que los DDC’s realicen el diezmado para enviarlos por medio de la interfaz USB 2.0 al computador.

Al llegar los datos al computador se entra al mundo del software, donde la implementación de OpenBTS está estructurada al igual que la pila de protocolos GSM, por capas, siguiendo el modelo de referencia OSI. La estructura general está compuesta por tres capas que son:

47 RANGE NETWORKS. OpenBTS Public Release. [en línea]. Año 2011. <Disponible en: https://wush.net/trac/rangepublic> [consulta: 9 Feb. 2012]. 48 BURGESS, David A. y SAMRA, Harvind S. Op. cit. p. 3. 49 STEIL, Andreas. OpenBTS. [en línea]. Actualizado, año 2010. <Disponible en:http://www.fh-kl.de/~andreas.steil/Projekte/OpenBTS/index.html> [consulta: 11 Oct. 2011].

L1, PHYSICAL LAYER (CAPA FÍSICA). El radiomodem, TDM (Time Division Multiplexing, Multiplexación por División de Tiempo), codificación y corrección de errores. GSM 04.04 y GSM 05.xx series.

L2, DATA LINK LAYER (CAPA DE ENLACE). Direccionamiento, segmentación y retrasmisión (LAPDm), GSM 04.05 y 04.06, ITU-T Q.921.

L3, "Layer 3". Administración de la conexión y señalización, GSM 04.07, 04.08, 04.10, 04.11, 04.12 y ITU-T Q.93150.

Figura 8. Arquitectura de OpenBTS

Fuente: Autores.

El objetivo y enfoque del diseño general de OpenBTS fue desde el principio realizar la mayoría de las funciones de la red en las capas L1 y L2, evitando la implementación de cualquier función por encima de L3. Es por esto que en L3 cada subprotocolo de GSM es terminado localmente o trasladado a través de una puerta de enlace (gateway) a algún otro protocolo para ser manejado por una aplicación externa como Asterisk51. Con este concepto claro, a medida que el

50 BURGESS, David A. y SAMRA, Harvind S. Op. cit. p. 15. 51 RANGE NETWORKS. OpenBTS P2.8 Users’ Manual. Año 2011. [en línea]. <Disponible en: https://wush.net/trac/rangepublic/attachment/wiki/WikiStart/SoftwareP2.8Manual.pdf> [consulta: 11 Ene. 2012]. p. 15.

proyecto fue creciendo se realizó la implementación de la capa L4, la cual es una puerta de enlace a una aplicación que maneja los mensajes de texto.

Además de estas capas, también se realiza la implementación de una “capa cero” L0 implementada por el software transceiver. El software transceiver realiza las funciones de radiomodem de la especificación GSM 05.05 y maneja la interfaz USB con el USRP152. El software transceiver consiste de tres módulos: transceiver, radioInterface y USRPDevice.

El módulo USRPDevice es básicamente un controlador (driver) que lee y escribe paquetes al USRP con dos tarjetas hijas, donde el lado “A” del USRP1 es usado para la trasmisión y lado “B” para la recepción.

El módulo radioInterface es básicamente una interfaz entre el transceiver y el USRP1. Este opera el reloj de la BTS basado en el conteo de las muestras recibidas del USRP1. Los paquetes desde el USRP1 son puestos en una cola y segmentados dentro de ráfagas GSM que son pasadas al módulo transceiver en la dirección de subida (uplink) y viceversa. Las ráfagas del módulo transceiver son pasadas al USRP1 en la dirección de bajada (downlink).

El módulo transceiver realiza la modulación, detección y demodulación de ráfagas GSM. Este se comunica con la pila de protocolos GSM por medio de tres sockets UDP: uno para los datos, uno para mensajes de control, y uno para pasar información del clock. El transceiver contiene una cola de prioridad para ordenar las ráfagas a ser trasmitidas y una tabla de relleno para llenar intervalos de tiempo que no tienen una ráfaga en la cola de prioridad. El transceiver intenta mantenerse por delante del reloj de la BTS, adaptando su latencia cuando una insuficiencia de datos son reportados por el módulo radioInterface/USRP1.

En la pila del protocolo GSM, la subcapa TDM de L1 desmultiplexa cada ráfaga y la envía al canal lógico apropiado. El canal lógico pasa cada ráfaga dentro de su procesador FEC de L1 (de acuerdo con las reglas de GSM 05.02), el cual realiza la decodificación FEC (descrita en GSM 05.03). La salida es una secuencia de frames L2 tomados por el canal lógico y enviados al procesador L2.

El procesador L2 corre la máquina de estado LAPDm que realiza acuse de recibo (Acknowledgement), retrasmisión y segmentación. Esta máquina de estado es definida implícitamente en GSM 04.06 y dada explícitamente en ITU-T Q.921. Cuando un frame L3 entrante ha sido verificado y armado, se coloca en una cola para su uso por L3. En el curso de la operación, LAPDm también inyecta frames L2 dentro del flujo de bajada (downstream) para el acuso de recibo y las peticiones de retrasmisión.

52 Ibid. p. 15

En L3, una función de envío determina el protocolo y tipo de mensaje y llama a la apropiada función de control para deserializar el mensaje y actuar sobre su contenido, generalmente produciendo una respuesta L3 sobre el downlink. Estas funciones de control también interactúan con el mundo de afuera a través de protocolos como SIP u otros.

En la dirección de bajada (downlink) en la capa L3, una función de control genera un mensaje L3, serializa los mensajes dentro de un frame L3 y envía este dentro del canal lógico, que lo pasa a la capa L2. El procesador L2 transforma los frames en segmentos y envuelve cada segmento en un frame L2. Cada frame L2 es enviado a L1 de acuerdo a la máquina de estado LAPDm. LAPDm también puede generar frames L2 adicionales por su propia cuenta de acuerdo a sus reglas de acuse de recibo y retrasmisión. Ya en la capa L1 el procesador FEC codifica cada frame L2 de acuerdo a las reglas de GSM 05.03, generando cuatro ráfagas de salida. A cada ráfaga se le pone una marca de tiempo con su tiempo de trasmisión establecido de acuerdo a las reglas TDM de GSM 05.02. Estas ráfagas son pasadas a la subcapa de L1 TDM. Aquí las ráfagas son reformateadas dentro de mensajes sobre la interfaz datagrama del módulo transceiver. Al llegar al módulo transceiver, las ráfagas de salida son clasificadas dentro de una cola de prioridad de acuerdo al tiempo de trasmisión. Las ráfagas son haladas desde la cola en la medida en que estén listas para la trasmisión y la modulación de acuerdo a GSM 05.04. Las formas de onda de las muestras moduladas son enviadas al USRP1 sobre el estándar timetagged USB interface (Interfaz USB con marcas de tiempo). Si las ráfagas no están listas para la trasmisión en un tiempo dado el transceiver genera una apropiada secuencia de relleno. Finalmente en el USRP1 las muestras son convertidas a una forma de onda análoga para la trasmisión sobre el canal de radio.

2.2 ANÁLISIS Y DISEÑO DE LA SOLUCIÓN

Para el análisis y diseño de la solución el punto de partida fue darle utilidad a la integración del software y hardware libre con el fin de facilitar las comunicaciones de las personas, incluyendo los organismos de socorro en un escenario donde las redes de telecomunicaciones colapsen e incluso se presente una deficiencia en la red de energía eléctrica. Como solución se trabajó en la implementación de un prototipo de Estación Celular Portátil GSM con la cual la comunicación al momento de un desastre pueda ser brindada a cada persona utilizando su celular registrado en la microcelda.

Para iniciar la implementación se consideró prioritaria la instalación del software y el estudio de su funcionamiento, por lo que se necesitó de un computador portátil. Se tomó la decisión de montar el software en el sistema GNU/Linux por cuanto se conocía cómo realizar el proceso de instalación y, adicionalmente, se contaba con experticia en el manejo de Ubuntu.

Siguiendo la recomendación de Flores53, se utilizó Ubuntu 10.04 LTS Desktop. Paso siguiente se realizó la instalación del software GNU Radio en su versión 3.4.2, que cuenta con el soporte para el USRP1. Posteriormente se procedió a instalar el software OpenBTS que brinda la implementación de la pila de protocoles GSM. La versión de OpenBTS utilizada fue la versión P2.6 Mamou. Por último, se instaló el software Asterisk, en la versión 1.6.2.22. Se inició el estudio de la configuración para funcionamiento de Asterisk. Básicamente los archivos de configuración extensions.conf y sip.conf, como también, las funciones y aplicaciones del plan de marcado (dialplan).

El hardware USRP1 fue adquirido a la firma ETTUS RESEARCH LLC en California, Estados Unidos. En la primera compra se adquirió el USRP-PKG, que consta de los componentes para el ensamble, la carcasa y la tarjeta madre. Cuando llegó el USRP-PKG se procedió al ensamble, se conectó al puerto USB2.0 del computador y se realizó la prueba de conexión USB entre el computador y la tarjeta madre.

Verificada la prueba de conexión entre el computador y la tarjeta madre, se trabajó sobre el archivo de configuración de OpenBTS. Para ello fue necesario tener claro el sistema numérico de identificación de GSM; básicamente el IMSI, el MCC, el MNC y el ARFCN relacionado con la banda de operación de GSM. Se decidió por la banda de operación GSM850 por lo que se adquirieron dos tarjetas hijas y dos antenas para la operación en dicha banda. Se integraron las tarjetas hijas y las antenas con la tarjeta madre formando los dos niveles del USRP1.

La configuración de OpenBTS se realizó mediante el archivo OpenBTS.config y el plan de marcado de Asteriks se ejecutó mediante el archivo extesions.conf para crear el control de numeración de los usuarios.

Para facilitar la administración de Asterisk, se instaló Asterisk GUI como administrador Web. Luego se integró un reloj externo de 52 MHz a la tarjeta madre obteniendo el prototipo funcional. Los resultados, pruebas y problemas se comentan más adelante después de la implementación de la solución.

2.3 IMPLEMENTACIÓN DE LA SOLUCIÓN

Para poder realizar el despliegue de la comunicación es necesario contar con unos requerimientos tanto de hardware como de software. La base del hardware

53 FLORES, Darío. Manual de uso e instalación de OpenBTS. [en línea]. Año 2011. <Disponible: https://wush.net/trac/rangepublic/attachment/wiki/WikiStart/Manual%20de%20instalaci%C3%B3n%20de%20OpenBTS%20Versi%C3%B3n%200.2.pdf > [consulta: 5 Feb. 2012]. p. 15.

fue adquirida en la compañía ETTUS RESEARCH LLC y el software utilizado fue totalmente de código abierto.

2.3.1 Requerimientos de software

Se recomienda un sistema operativo basado en Linux o MAC OS X. Para el presente trabajo se utilizó el sistema operativo Ubuntu 10.04 LTS (Lucid Lynx). Flores54 recomienda usar Ubuntu 10.04 LTS Desktop o Ubuntu 10.10 Desktop debido a que estas distribuciones poseen el mejor soporte de dependencias para poder posteriormente configurar, compilar e instalar GNU radio, OpenBTS y Asterisk.

Para construir e instalar OpenBTS se necesita tener instaladas las siguientes dependencias: el controlador para el USRP1 libusrp, la librería SIP oSIP2 y la librería oRTP55. Libusrp está disponible una vez se instale GNU Radio, oSIP2 y oRTP están disponibles a través del sistema de gestión de paquetes (apt-get) en Ubuntu 10.04 LTS.

Las actuales versiones de GNU Radio no tienen soporte para el controlador libusrp. Se recomienda utilizar la versión estable 3.4.256, razón por la cual fue la versión que se utilizó en el presente trabajo.

Se recomienda el uso de versiones basadas en Asterisk 1.4 o 1.6. Las versiones basadas en Asterisk 1.8 presentan un problema a nivel de SIP trabajando con OpenBTS, el cual provoca que las llamadas se terminen a los 32 segundos57. Para este trabajo se utilizó la versión 1.6.2.22.

En el presente trabajo se utilizó la versión de OpenBTS P2.6 Mamou.

2.3.2 Requerimientos de Hardware

Un computador con puerto USB-2.0. La página web de GNU Radio no recomienda algunos modelos de portátiles marca Dell, porque su hardware

54 Ibid. p. 15. 55 GNU Radio Project. Building and Running OpenBTS: Dependencies. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSBuildingAndRunning> [consulta: 9 Oct. 2011]. 56 GNU Radio Project. OpenBTS: UHD Devices: USRP1. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSUHD> [consulta: 9 Oct. 2011]. 57 FLORES, Darío. Op. cit. p. 14.

tiende a introducir ruido por medio de los cables USB58. Por esta razón se trabajó con un portátil Acer con procesador Intel Atom de 1.5 GHz, 2GB de memoria RAM y puerto USB-2.0. Es probable que en máquinas virtuales no funcione.

El paquete USRP-PKG es un kit que incluye la tarjeta madre (motherboard), la carcasa, 2 cables RF con conectores SMA, cable USB, fuente de poder y componentes para el ensamble.

Dos tarjetas hijas (daughterboards) RFX900, que pueden cubrir las bandas GSM 850/900. Sin embargo, también se pueden usar las RFX1800 para cubrir las bandas GSM 1800/1900. Es recomendable usar dos tarjetas hijas para minimizar la diafonía entre la trasmisión y la recepción; de esta forma se obtiene una mejor calidad de la señal y cobertura. En el presente trabajo se utilizaron dos tarjetas hijas RFX900, con una figura de ruido de 8dB. En el cuadro 3 se muestran las características de frecuencia y potencia de las tarjetas hijas.

Cuadro 3. Características de frecuencia y potencia de las tarjetas hijas

Tarjetas hijas RFX900 RFX1800

Rango de frecuencia 750 a 1050 MHz 1.5 a 2.1 GHz

Potencia de trasmisión 200 mW (23 dBm) 100 mW (20 dBm)

Fuente: LOULA, A. OpenBTS, installation and configuration guide. s.p.i. 2009. p. 3.

Dos antenas VERT900 (una por cada tarjeta hija) con las siguientes características: Antena vertical omnidireccional, 3dBi de ganancia. 824 a 960 MHz, 1710 a 1990 MHz, cuatribanda Cellular/PCS y banda ISM. Trabaja con las tarjetas hijas WBX, RFX900, RFX1800.

Reloj de referencia de 52MHz con una alta precisión mayor a 0.05 ppm. El USRP1 tiene por defecto un reloj de 64 MHz que no es el adecuado para el buen funcionamiento de GSM. En este trabajo se usó el Fairwaves СlockTamer, especialmente diseñado para usarse con el USRP159.

58 GNU Radio Project. Desktop Testing of OpenBTS. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSDesktopTestingKit> [consulta: 9 Oct. 2011]. 59 FAIRWAVES. Clock Tamer project. [en línea]. Año 2011. <Disponible en: http://code.google.com/p/clock-tamer/ > [consulta: 10 Ago. 2011]

Figura 9. Kit USRP PKG

Fuente: Autores

Equipos celulares GSM con SIM cards. Estos deben funcionar en modo de búsqueda manual de red.

2.3.2.1 Proceso de ensamblaje de USRP (Ver Anexo A)

2.3.3 Proceso de adecuación del hardware. Para poder utilizar la USRP1 con un reloj externo es necesario realizar modificaciones de hardware. Estas modificaciones se realizan para deshabilitar el reloj interno que trae por defecto el USRP1 y habilitar la entrada del reloj externo60.

Para la adecuación del hardware se recomienda seguir los siguientes pasos:

60 GNU Radio Project. Reclocking the USRP-1 for OpenBTS: Hardware modifications to the USRP to use a external clock. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSClockModifications> [consulta: 9 Oct. 2011].

Tarjetas

hijas

Antenas

USRP

Soldar un conector SMA hembra en J2001, esta es la entrada del reloj externo. Hay que tener cuidado de no romper el delicado camino desde J2001 a C927.

Mover la resistencia R2029 a R2030. Esto deshabilita el reloj por defecto de la USRP.

Mover el capacitor C925 a C926.

Remover el capacitor C924.

Soldar una resistencia SMD (Surface Mount Device, Dispositivo de Montaje Superficial) de 50 Ohm en el conector SMA de la entrada del reloj externo.

Para fijar el Clock Tamer se suelda un conector de 16 pines a J24.

Para alimentar el Clock Tamer desde el conector del ventilador del USRP, se debe remplazar la resistencia de limitación R7 con una resistencia de 0 Ohmios o un corto circuito. Esta resistencia está localizada al lado derecho del conector de energía del ventilador J3.

Figura 10. Modificaciones del USRP

Fuente: Autores

2.3.4 Proceso de instalación. Aquí se describe detalladamente la instalación del software necesario para el funcionamiento de la microcelda. Se parte de la base que ya se tiene un computador corriendo el sistema operativo Ubuntu 10.04 LTS. En el presente trabajo se utilizó el nombre de emergencybts para el proceso de instalación tal como se muestra en la figura 9. No obstante, si se desea cambiar este nombre de usuario, es posible realizar el cambio siempre y cuando se continúe usando el nuevo nombre de usuario.

Figura 11. Instalación de Ubuntu 10.04 LTS con usuario emergencybts

Fuente: Autores

2.3.4.1 Instalación de GNU Radio. Todos los comandos son corridos desde una terminal. Para su ejecución, seleccione los comandos y arrástrelos a la terminal o cópielos en la terminal presionando las teclas Shift → Insert.

Primero se instalan las actualizaciones disponibles, se abre una terminal, se va a Aplicaciones → Accesorios → terminal o se presiona la combinación de teclas Ctrl → Alt → t y se escribe el siguiente comando a la terminal.

sudo apt-get update && sudo apt-get upgrade

Para la instalación de GNU Radio en Ubuntu 10.04 LTS se requiere la instalación de varios paquetes o dependencias61:

Herramientas de desarrollo (necesarias para la compilación) o g++ o git o make o autoconf, automake, libtool o sdcc o guile o ccache (no es requerido pero necesario si se compila frecuentemente)

Librerías (necesarias para el tiempo de ejecución y compilación) o python-dev o SWIG o FFTW 3.X (libfftw3-dev) o cppunit (libcppunit-dev) o Boost 1.35 (o más) o GSL GNU Scientific Library (libgsl0-dev) o libusb y libusb-dev o ALSA (alsa-base, libasound2 y libasound2-dev)

Para instalar las dependencias se selecciona y arrastra el siguiente script a la terminal:

sudo apt-get -y install libfontconfig1-dev libxrender-dev

libpulse-dev swig g++-4.3 automake autoconf libtool python-dev

libfftw3-dev \

libcppunit-dev libboost-all-dev libusb-dev fort77 sdcc sdcc-

libraries \

libsdl1.2-dev python-wxgtk2.8 git-core guile-1.8-dev \

libqt4-dev python-numpy ccache python-opengl libgsl0-dev \

python-cheetah python-lxml doxygen qt4-dev-tools \

libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools python-qwt5-

qt4

61 GNU Radio Project. Building GNU Radio on Ubuntu Linux: Install the Pre-Requisites. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall> [consulta: 6 Jul. 2011].

Descargar GNU radio

wget

http://gnuradio.org/redmine/attachments/download/279/gnuradio-

3.4.2.tar.gz

Descomprimir el fichero y acceder a la carpeta

tar -zxvf gnuradio-3.4.2.tar.gz

cd gnuradio-3.4.2

Instalar GNU radio en el directorio por defecto. Este punto es un poco demorado. No cierre la terminal hasta que termine de instalar.

./configure

make && make check

sudo make install

Debido a que el intérprete Python no encuentra el directorio de las librerías, se debe agregar la línea /usr/local/lib al archivo ld.so.conf. Lo anterior es un problema de Debian/Ubuntu62.

sudo gedit /etc/ld.so.conf

Quedando el archivo de la siguiente manera:

include /etc/ld.so.conf.d/*.conf

/usr/local/lib

Guardar, cerrar y correr.

sudo ldconfig

Verificar la instalación de GNU Radio ejecutando un programa. Ejemplo:

cd /usr/local/share/gnuradio/examples/audio

python dial_tone.py

62 GNU Radio Project. Building GNU Radio on Ubuntu Linux: Broken libtool on Debian and Ubuntu. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall> [consulta: 6 Jul. 2011].

El ejemplo anterior es el “Hola Mundo de GNU Radio” que se había descrito con anterioridad. Se escuchará un tono de marcado si la tarjeta de audio del computador se encuentra en buenas condiciones.

Para usar el USRP1 con GNU Radio, prender el USRP1 y conectar el cable USB al computador. Ejecutar los siguientes comandos para agregar el grupo usrp, permisos para el usuario y las reglas para su funcionamiento y detección. En el campo <NOMBRE DE USUARIO> escriba el nombre con el que opera el sistema, en este caso es emergencybts.

sudo addgroup usrp

sudo usermod -G usrp -a <NOMBRE DE USUARIO>

echo 'ACTION=="add", BUS=="usb", SYSFSidVendor=="fffe",

SYSFSidProduct=="0002", GROUP:="usrp", MODE:="0660"' > tmpfile

sudo chown root.root tmpfile

sudo mv tmpfile /etc/udev/rules.d/10-usrp.rules

Reiniciar el equipo con el USRP1 prendido y conectado al computador.

sudo reboot

Abrir de nuevo la terminal y ejecutar

sudo udevadm control --reload-rules

Mirar si el USRP1 es reconocido ejecutando:

ls -lR /dev/bus/usb | grep usrp

El resultado debe ser algo como:

crw-rw---- 1 root usrp 189, 514 Mar 24 09:46 003

Verificar que GNU Radio trabaje con el USRP1

cd ~/gnuradio-3.4.2/gnuradio-examples/python/usrp

./usrp_benchmark_usb.py

La aplicación usrp_benchmark_usb.py muestra la tasa promedio de trasmisión exitosa (throughput). El resultado debe ser algo como:

Testing 2MB/sec... usb_throughput = 2M

ntotal = 1000000

nright = 998435

runlength = 998435

delta = 1565

OK

Testing 4MB/sec... usb_throughput = 4M

ntotal = 2000000

nright = 1998041

runlength = 1998041

delta = 1959

OK

Testing 8MB/sec... usb_throughput = 8M

ntotal = 4000000

nright = 3999272

runlength = 3999272

delta = 728

OK

Testing 16MB/sec... usb_throughput = 16M

ntotal = 8000000

nright = 7992153

runlength = 7992153

delta = 7847

OK

Testing 32MB/sec... usb_throughput = 32M

ntotal = 16000000

nright = 15986239

runlength = 15986239

delta = 13761

OK

Max USB/USRP throughput = 32MB/sec

Verificar que el máximo throughput sea 32MB/sec.

Correr otro ejemplo:

cd ~/gnuradio-3.4.2/usrp/host/apps

./test_usrp_standard_rx

Ya están listos para usar GNU Radio con el USRP1.

2.3.4.2 Instalación de OpenBTS. Para instalar OpenBTS se deben instalar dependencias extras que son:

Python-all-dev, libboost-dev, libosip2-dev, libortp-dev. Se Procede corriendo el siguiente comando:

sudo apt-get install python-all-dev libboost-dev libosip2-dev

libortp-dev

En Ubuntu hay un problema dentro del script de configuración que no mira el lugar correcto buscando libusrp63. Para corregir esto se realizan los siguientes pasos:

cd /usr/local/include/

sudo ln -sf usrp/usrp_bytesex.h .

sudo ln -sf usrp/usrp_standard.h .

sudo ln -sf usrp/usrp_prims.h .

Descargar openbts2.6.0 en el directorio /home/emergencybts. Para ello se abre la terminal y se ejecuta:

cd ~

wget http://sourceforge.net/projects/openbts/files/openbts-

2.6.0Mamou.tar.gz

Descomprimir el fichero

tar xzf openbts-2.6.0Mamou.tar.gz

Se mueve a la carpeta openbts-2.6.0Mamou y se procede con la instalación.

cd openbts-2.6.0Mamou

./configure

make

make check

sudo make install

OpenBTS necesita de un archivo de configuración. No es necesario crearlo desde cero, simplemente se copia el archivo de configuración de ejemplo "OpenBTS.config.example" que está en ~/openbts-2.6.0Mamou/apps a "OpenBTS.config" en la misma carpeta. Para ello se ejecuta:

cp ~/openbts-2.6.0Mamou/apps/OpenBTS.config.example ~/openbts-

2.6.0Mamou/apps/OpenBTS.config

2.3.4.3 Instalación de Asterisk. Unos buenos pasos para la instalación de Asterisk en Ubuntu se encuentran en Madsen et. al64. El proceso a seguir está muy bien detallado. Solo se cambió la versión de Asterisk a instalar, ya que Asterisk 1.8 presenta un problema a nivel SIP trabajando con OpenBTS.

Instalar las dependencias que se requieren para compilar Asterisk

63 GNU Radio Project. Building and Running OpenBTS. Op. cit. p. 1. 64 MADSEN, Leif; VAN MEGGELEN, Jim y BRYANT, Russell. Op. cit. p. 29.

sudo apt-get install build-essential subversion libncurses5-dev

libssl-dev libxml2-dev

LibPRI. Es una librería que añade soporte para la RDSI (Integrated Services Digital Network, Red Digital de Servicios Integrados (PRI y BRI). El uso de LibPRI es opcional, toma muy poco tiempo en instalar, no interfiere en el funcionamiento básico de Asterisk y será muy útil si alguna vez desea agregar tarjetas a un sistema en un momento posterior. Ejecutar los siguientes comandos para su instalación.

sudo make cd /usr/src/

sudo wget

http://downloads.asterisk.org/pub/telephony/libpri/libpri-1.4-

current.tar.gz

sudo tar -zxvf libpri-1.4-current.tar.gz

cd libpri-1.4.12

sudo make

install

DAHDI. El Digium Asterisk Hardware Device Interface, o DAHDI, es el software que usa Asterisk para interactuar con el hardware de telefonía. Se recomienda instalarlo porque DAHDI es una dependencia requerida para usar aplicaciones de Asterisk como Meetme(). DAHDI es actualmente una combinación de dos códigos base separados: DAHDI-tools, el cual proporciona varias herramientas de administrador y DAHDI-linux, el cual proporciona los controladores (drivers) del kernel.

Se procede ejecutando los siguientes comandos:

cd /usr/src/

sudo wget http://downloads.asterisk.org/pub/telephony/dahdi-

linux-complete/dahdi-linux-complete-2.6.0+2.6.0.tar.gz

sudo tar -zxvf dahdi-linux-complete-2.6.0+2.6.0.tar.gz

cd dahdi-linux-complete-2.6.0+2.6.0

Para instalar DAHDI es importante que la versión del kernel que está siendo usada coincida exactamente con la del kernel fuente que se va a instalar. Para ello se corre el siguiente comando:

sudo apt-get install linux-headers-`uname -r`

Continuar con la instalación

sudo make all

sudo make install

sudo make config

Asterisk. Al principio del capítulo cuando se describieron los componentes del sistema se habló de Asterisk, ahora se procede a su instalación ejecutando los siguientes comandos:

cd /usr/src/

sudo wget

http://downloads.asterisk.org/pub/telephony/asterisk/old-

releases/asterisk-1.6.2.22.tar.gz

sudo tar -zxvf asterisk-1.6.2.22.tar.gz

cd asterisk-1.6.2.22

sudo ./configure

Con la ejecución del siguiente comando se abre el menú de selección o menuselect. Con el menú de selección se pueden elegir los módulos a compilar e instalar con el fin de aumentar las funcionalidades de Asterisk. El menú de selección también permite poner banderas que pueden ayudar en problemas de depuración, poner banderas de optimización, escoger diferentes archivos y formatos de mensajes de sonido como música en espera, entre otros65. Por defecto Asterisk solo instala los archivos core de sonido en idioma inglés y en formato gsm. En el presente trabajo se instaló el sonido en español y en otros formatos. La razón por la que se instalaron múltiples formatos para los mismos archivos es que Asterisk puede reproducir el formato apropiado dependiendo de cuál códec es negociado entre el servidor y el teléfono. Esto reduce la carga de la CPU sobre un sistema significativamente. Para la ejecución del siguiente comando se necesita que la terminal tenga un tamaño de por lo menos 80 x 27.

sudo make menuselect

El funcionamiento básico del menú de selección es el siguiente: con las flechas del teclado se desplaza arriba y abajo, con la flecha derecha o ENTER se entra en un submenú, y con la flecha izquierda se regresa al menú principal. Con la tecla ENTER se seleccionan y deseleccionan módulos. Con la tecla 'q' se sale del menú de selección, mientras que con la tecla 's' se guardan las selecciones y luego se cierra el menú de selección. Se baja hasta Core Sound Packages, se presiona la flecha derecha o ENTER para entrar al submenú. La lista que se muestra representa el core de archivos de sonido en varios lenguajes y formatos. La selección se realiza como se muestra a continuación:

[*] CORE-SOUNDS-ES-WAV [*] CORE-SOUNDS-ES-ULAW [ ] CORE-SOUNDS-ES-ALAW

65 Ibid. p. 59.

[*] CORE-SOUNDS-ES-GSM

Después de seleccionar los archivos de sonido apropiados, se presiona la flecha izquierda, para ir atrás al menú principal. Se va a la opción Music On Hold File Packages, y se presiona la tecla derecha o ENTER. Se realiza la selección como se muestra a continuación:

[*] MOH-OPSOUND-WAV [*] MOH-OPSOUND-ULAW [ ] MOH-OPSOUND-ALAW [*] MOH-OPSOUND-GSM

Por último se presiona la tecla izquierda para volver al menú principal y luego la tecla ‘s’ para guardar y cerrar el menú de selección.

Se continúa con la instalación ejecutando:

sudo make

sudo make install

sudo make config

sudo make samples

Con el fin de correr Asterisk como usuario emergencybts se debe asignar permisos a los directorios de Asterisk, para ello se corren los siguientes comandos:

sudo chown -R emergencybts:emergencybts /etc/asterisk/

sudo chown -R emergencybts:emergencybts /usr/lib/asterisk/

sudo chown -R emergencybts:emergencybts /var/lib/asterisk/

sudo chown -R emergencybts:emergencybts /var/spool/asterisk/

sudo chown -R emergencybts:emergencybts /var/log/asterisk/

sudo chown -R emergencybts:emergencybts /var/run/asterisk/

sudo chown emergencybts:emergencybts /usr/sbin/asterisk

De igual forma para usar Asterisk y DAHDI como usuario emergencybts se ejecuta:

sudo gedit /etc/udev/rules.d/dahdi.rules

Cambiar la última línea de dahdi.rules quedando:

SUBSYSTEM=="dahdi", OWNER="emergencybts", GROUP="emergencybts",

MODE="0660"

Indicar a Asterisk que va a ser ejecutado por usuario y grupo emergencybts.

gedit /etc/asterisk/asterisk.conf

Verificar que los siguientes parámetros queden de la siguiente forma:

runuser=emergencybts

rungroup=emergencybts

Asterisk-addons. Los paquetes de Asterisk-addons proveen controladores para la conexión a servidores de mysql y manejo de bases de datos, además de proveer de controladores para el manejo de archivos en mp3, entre otros. Su instalación es opcional. Ejecutar los siguientes comandos:

cd /usr/src/

sudo wget

http://downloads.asterisk.org/pub/telephony/asterisk/old-

releases/asterisk-addons-1.6.2.4.tar.gz

sudo tar -zxvf asterisk-addons-1.6.2.4.tar.gz

cd asterisk-addons-1.6.2.4

sudo ./configure

sudo make

sudo make install

Asterisk puede funcionar tanto como un demonio en segundo plano o como una aplicación en primer plano. En general, se desea que se ejecute como una aplicación cuando se están construyendo, probando y solucionando problemas, y como un demonio cuando se necesita que funcione dentro de una producción66.

El comando para iniciar Asterisk es el mismo independientemente de si lo está ejecutando como un demonio o una aplicación. Escribir en una terminal:

asterisk

Una vez arranque el equipo, Asterisk ya inicia corriendo en segundo plano. Sin embargo, para poder ver paso a paso el comportamiento de Asterisk se deben pasar algunas opciones a este comando y de esta forma supervisar mejor el funcionamiento que se está buscando. A continuación se proporcionan algunos ejemplos de usos comunes:

asterisk -h

Con esta opción el comando muestra una lista útil de las opciones que se pueden usar. Para una completa lista de las opciones y sus descripciones, se ejecuta el comando man asterisk.

66 Ibid. p. 55.

asterisk -c

Con esta opción Asterisk inicia como una aplicación o programa de usuario. Esto significa que Asterisk está ligado a la sesión de usuario. En otras palabras, si se cierra la sesión de usuario, Asterisk deja de correr. Esta es la opción que se usa típicamente cuando se está construyendo, probando y depurando, pero no será una buena elección usar esta opción en producción. Si se inicia Asterisk con esta opción, al escribir core stop now en el prompt CLI (Command Line Interface, Interfaz de Línea de Comandos), Asterisk para y se cierra.

asterisk -r

Esta opción es esencial si se quiere conectar remotamente a Asterisk en un sistema donde Asterisk ya está corriendo como un demonio. Probablemente se usa esta opción más que cualquier otra para sistemas con Asterisk que están en producción. Para salir del prompt CLI cuando esta opción ha sido usada, se escribe exit y se cierra la conexión, pero Asterisk no dejará de correr.

asterisk -v, -vv, -vvv, -vvvv, -vvvvv

Esta opción es usada con el fin de aumentar la verbosidad de la consola de salida (aumentar la cantidad de información que se obtiene en la consola), puede ser usada con otras opciones (p. ej., -cvvv, -rvv). Esta opción hace exactamente lo mismo que el comando core set verbose n escrito en el prompt CLI, donde n es cualquier número entero entre 0 y 5 (cualquier número entero superior a 5 va a funcionar, pero no proporcionará más verbosidad).

asterisk -d, -dd, -ddd, -dddd

Esta opción puede ser usada igual que -v, pero en lugar de la salida normal, esta especificará el nivel de salida de depuración, lo cual es especialmente útil para los desarrolladores quienes desean solucionar los problemas con el código. También se necesita habilitar la salida de información de depuración en el archivo logger.conf.

asterisk -T

Esta opción añade fecha y hora a la salida del CLI.

asterisk -x

Esta opción combinada con -r permite ejecutar un comando como si éste haya sido escrito en el prompt CLI. Por ejemplo, si se quieren ver todos los canales en uso, basta con escribir:

asterisk -rx 'core show channels'

asterisk -n

Esta última opción deshabilita los colores ANSI incluso en terminales capaces de mostrarlos.

Asterisk GUI. Unos buenos pasos para la instalación de Asterisk GUI se encuentran en Van Meggelen et. al67. Asterisk GUI (Graphical User Interface, Interfaz Gráfica de Usuario) a nivel Web que facilita la administración y el control de servidores Asterisk. Con Asterisk GUI se pueden configurar, de forma fácil, usuarios, correo de voz, colas de llamadas, reglas de marcado, backup, IVR, entre otras funcionalidades. Se Procede a su instalación:

cd /usr/src

sudo svn co http://svn.asterisk.org/svn/asterisk-gui/tags/2.1.0-

rc1 asterisk-gui

cd asterisk-gui

sudo ./configure

sudo make

sudo make install

Para permitir la conexión vía Web a Asterisk se configura el archivo http.conf

gedit /etc/asterisk/http.conf

Verificar que los siguientes parámetros en el archivo queden de la siguiente forma:

[general]

enabled = yes

bindaddr = 0.0.0.0

bindport = 8088

prefix = asterisk

enablestatic = yes

redirect = / /asterisk/static/config/cfgbasic.html

Agregar un usuario y contraseña a Asterisk GUI y modificar el archivo manager.conf para permitir que se envíen comandos a Asterisk.

gedit /etc/asterisk/manager.conf

Verificar que los siguientes parámetros en el archivo queden de la siguiente forma:

[general]

67 VAN MEGGELEN, Jim; MADSEN, Leif y SMITH, Jared. Op. cit. p. 249.

displaysystemname=yes

enabled = yes

webenabled=yes

httptimeout=60

port = 5038

bindaddr = 0.0.0.0

[emergencybts]

secret=admin

read=system,call,log,verbose,command,agent,user,config,read,write

,originate

write=system,call,log,verbose,command,agent,user,config,read,writ

e,originate

En el archivo anterior se evidencia que el nombre de usuario es emergencybts y la contraseña es admin. Para comprobar que la configuración de los archivos quedó bien. Se corre:

sudo make checkconfig

Agregar los permisos de nuevo al directorio /var/lib/asterisk/ y reiniciar el servicio de Asterisk

sudo chown -R emergencybts:emergencybts /var/lib/asterisk/

service asterisk restart

Acceder a la interfaz de administración Web. Si ingresamos desde el mismo computador donde está instalado el servicio Web, se abre un navegador Web y se escribe la siguiente dirección:

http://localhost:8088

Si se ingresa desde otro computador en la misma red, se abre un navegador Web y se remplaza localhost por la dirección IP del computador donde está instalado el servicio Web.

http://direcciónIP:8088

Luego se ingresa con el nombre de usuario emergencybts y contraseña admin. La figura 10 muestra la interfaz principal de Asterisk GUI.

Kalibrate. O kal es un programa que puede ser usado para escanear estaciones base BTS GSM en una banda de frecuencia dada y puede usar estas BTS’s para calcular la frecuencia de offset del oscilador local68.

El estándar GSM especifica 50ppb = 0.05ppm de precisión de frecuencia para un reloj de referencia en una macro BTS y 100ppb = 0.1ppm para femtoceldas. Offsets hasta de 500 Hz en la banda de GSM900 permiten que la mayoría de los celulares trabajen sin ningún problema. Es recomendable calibrar el Clock Tamer a 100ppb para evitar problemas69. También es necesario recalibrarlo después de fuertes cambios de temperatura. Igualmente Kalibrate se usará para definir el ARFCN70 en la configuración de OpenBTS.

Figura 12. Interfaz web Asterisk GUI

Fuente: Autores

Se Procede a su instalación ejecutando los siguientes comandos en una terminal:

wget http://thre.at/kalibrate/kal-v0.4.1.tar.bz2

tar -xjvf kal-v0.4.1.tar.bz2

cd kal-v0.4.1

./bootstrap

./configure

68 LACKEY, Joshua. Kalibrate: SUMMARY. [en línea]. Ago. 29, 2010. <Disponible en: http://thre.at/kalibrate/> [consulta: 16 Ene. 2012]. 69 CHEMERIS, Alexander. Clock Tamer Calibration: Introduction. [en línea]. OCT. 18, 2011. <Disponible en: http://code.google.com/p/clock-tamer/wiki/ClockTamerCalibration> [consulta: 16 Ene. 2012]. 70 Para una lista completa de ARFCN visitar el enlace. http://gnuradio.org/redmine/attachments/115/all_gsm_channels_arfcn.txt

make

sudo make install

2.3.5 Configuración para la puesta en funcionamiento de la microcelda. Antes de realizar la puesta en funcionamiento hay que configurar unos archivos de OpenBTS y Asterisk. La configuración de estos archivos requiere un grado de conocimiento de algunos parámetros de la red GSM y programación en Asterisk.

2.3.5.1 Configuración de OpenBTS. Aunque la red GSM trabaja en varias bandas de frecuencia, OpenBTS puede trabajar en 4 de las más usadas: GSM850, GSM900, GSM1800 y GSM1900. Cuando se describe la red GSM se habla sobre un sistema numérico de identificación. El IMSI es el número de identificación más importante dentro del archivo de configuración de OpenBTS y en Asterisk representa el nombre de usuario SIP. Como se mencionó al hablar del sistema específico de numeración GSM, el IMSI es un número que identifica de forma única una MS dentro de la red. El IMSI se graba en la tarjeta SIM cuando el suscritor se registra con el operador de telefonía móvil determinado en algún país. Como se observa en el cuadro 4, el máximo número de dígitos del IMSI es 15 y está compuesto del MCC, el MNC y el MSIN.

Cuadro 4. Conformación del IMSI

IMSI

MCC MNC MSIN

3 dígitos 2 o 3 dígitos Máximo 10 dígitos

------------------------- Máximo 15 dígitos --------------------

Fuente: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSIntroduction_To_GSM

El MCC para Colombia y el MNC de los operadores que prestan sus servicios en Colombia están registrados en el cuadro 5. Algunas redes pueden tener más de un MNC asignado.

Un ejemplo de un código IMSI en Colombia es IMSI732101018240432. En este código se identifica el país, en este caso, Colombia por el 732 y al operador, en este caso Comcel por el 101.

Otro parámetro importante en la configuración de OpenBTS es la banda de operación que se usó. Esta banda está ligada al ARFCN que también es necesario en el archivo de configuración. Como se vio, el ARFCN es un número que determina los canales de trasmisión de la MS a la BTS (uplink) y recepción por parte de la MS (downlink) que se van a usar.

Ahora que ya se han explicado los parámetros que se van a modificar en el archivo de configuración, se procede a realizar los cambios. El archivo de configuración es llamado “OpenBTS.config”. Este archivo se creó basado en un archivo de ejemplo cuando se describió la instalación de OpenBTS. Los comentarios en este archivo se hacen con el símbolo “#”. Se abre el archivo con el siguiente comando:

gedit ~/openbts-2.6.0Mamou/apps/OpenBTS.config

Cuadro 5. Operadores que prestan servicios en Colombia

MCC MNC Operador de la red

732 001 Telefónica Telecom

732 002 Edatel

732 011 Edatel

732 099 Emcali

732 101 Comcel

732 102 Movistar

732 103 Tigo

732 111 Tigo

732 123 Movistar

732 130 Avantel

Fuente: International Numbering Plans

Lo primero que se modifica es la ruta para indicarle a OpenBTS que se está utilizando un reloj de 52 MHz. Se va hasta donde dice TRX.Path y debe quedar de la siguiente manera:

#TRX.Path ../Transceiver/transceiver

TRX.Path ../Transceiver52M/transceiver

Luego se identifican los códigos de la red, se elige la configuración de OpenBTS como MCC: el número 732 correspondiente a Colombia y como MNC un número de dos o tres dígitos diferente al que usan los operadores en Colombia que registra el cuadro 5. En este caso se seleccionó el número 003, quedando de la siguiente manera:

GSM.MCC 732

GSM.MNC 003

Luego se define la banda de frecuencia a usar. En este caso se usó la banda GSM850. De igual forma hay que indicar los canales de uplink y downlink que van a ser usados dentro de la banda GSM850. Para ello hay que definir el ARFCN. Se

conecta el USRP1 a la energía y el cable USB al computador, se abre una terminal y escanea la red con el siguiente comando:

kal -s GSM850 -F 52000000 -R B

El resultado muestra una lista de los canales y la potencia de trasmisión. Se escoge el ARFCN que muestre mayor potencia, en este caso el ARFCN es 137, quedando el archivo de la siguiente forma:

GSM.Band 850

$static GSM.Band

GSM.ARFCN 137

$static GSM.ARFCN

Se configura el mensaje de bienvenida una vez que la MS se registra en la red. Para ello hay que modificar el archivo en las siguientes líneas:

Control.NormalRegistrationWelcomeMessage Bienvenido a

EmergencyBTS para registrarse marque 1234

Control.NormalRegistrationWelcomeShortCode 0000

Por último, se verifica la IP del servidor Asterisk. En este caso el servidor corre localmente con OpenBTS y se deja la IP por defecto 127.0.0.1.

Asterisk.IP 127.0.0.1

SIP.IP 127.0.0.1

2.3.5.2 Configuración de Asterisk71. Como se describió al hablar de Asterisk, los archivos de configuración se encuentran en el directorio /etc/asterisk/. Básicamente los archivos que son necesarios configurar son dos, sip.conf y extensions.conf.

Para comprender el archivo extensions.conf se debe hacer un acercamiento básico al plan de marcado de Asterisk.

El plan de marcado es el corazón de Asterisk. Éste define como fluyen las llamadas hacia dentro y fuera del sistema. Es una forma de lenguaje en script pues contiene instrucciones que Asterisk sigue en respuesta a disparadores externos e internos. En contraste con los sistemas tradicionales de telefonía, el plan de marcado de Asterisk es totalmente personalizable y de libre desarrollo.

71

MADSEN, Leif; VAN MEGGELEN, Jim y BRYANT, Russell. Op. cit. p. 29.

El plan de marcado de Asterisk se encuentra especificado en el archivo de configuración llamado extensions.conf que usualmente se encuentra en la ruta /etc/asterisk/ El plan de marcado se compone de cuatro conceptos principales: contextos, extensiones, prioridades y aplicaciones.

Contextos: El plan de marcado está dividido en secciones llamados contextos. Los contextos impiden que diferentes partes del plan de marcado interactúen unas con otras. Una extensión definida en un contexto es totalmente aparte de las extensiones en cualquier otro contexto, a menos que la interacción sea específicamente permitida.

Los contextos son definidos escribiendo el nombre del contexto entre corchetes [ ], el nombre puede estar compuesto de dígitos alfanuméricos (a-z, A-Z y 0-9), guion y/o guion bajo. El tamaño máximo del nombre del contexto es 79 caracteres. No se deben usar espacios en blanco.

Ejemplo de definición de contexto: [llamadas-entrantes1]

Todas las instrucciones puestas a continuación de la definición son parte del contexto, hasta que el siguiente contexto sea definido. Al inicio del plan de marcado hay dos contextos especiales llamados [general] y [globals]. La sección [general] contiene la lista de las configuraciones generales del plan de marcado, pero en realidad ninguno de los dos son contextos, por lo tanto se debe evitar usar dichos nombres, (incluyendo [default]), como nombres de contextos. Cuando se define un canal (lo cual se hace en sip.conf), uno de los parámetros requeridos por cada canal es el contexto. El contexto es el punto en el plan de marcado donde empezarán las conexiones desde ese canal. La configuración del contexto para el canal, es como se conecta el canal al plan de marcado.

Figura 13. Relación entre los archivos sip.conf y extensions.conf

Fuente: Madsen et al. Asterisk the definitive guide. Tercera edición.

Extensiones: En el mundo de las telecomunicaciones, la palabra extensión usualmente se refiere a un identificador numérico que, cuando es marcado, hará timbrar un teléfono (o un recurso el sistema como una cola o grupo de timbrado). En Asterisk una extensión es mucho más poderosa, ya que define la serie única de pasos (cada paso contiene una aplicación), a través del cual Asterisk llevará a cabo esa llamada.

Dentro de cada contexto, nosotros podemos definir tantas extensiones como sean requeridas. Cuando una extensión en particular es disparada, Asterisk seguirá los pasos definidos para esa extensión.

La sintaxis para una extensión es la palabra exten, seguido por una flecha formada por un igual y un mayor que:

exten =>

Esto es seguido por el nombre (o número) de la extensión; de hecho en Asterisk una extensión puede ser una mezcla de caracteres alfanuméricos, lo cual no es posible en las plantas telefónicas tradicionales.

Cada paso en una extensión está compuesto por tres componentes:

El nombre o número de la extensión.

La prioridad (cada extensión puede incluir múltiples pasos; el número que

indica el consecutivo de pasos es llamado así).

La aplicación (o comando) que se realizará en ese paso.

Estos tres componentes son separados por comas, así: exten => nombre,prioridad,aplicación()

Éste es un ejemplo sencillo de como se vería una extensión real:

exten => 123,1,Answer()

Prioridades: Cada extensión puede tener múltiples pasos llamados prioridades. Las prioridades se enumeran secuencialmente empezando en 1, y cada una ejecuta una aplicación específica. Lo importante es que Asterisk sigue las prioridades en su respectivo orden. Por ejemplo:

exten => 123,1,Answer()

exten => 123,2,hacer algo

exten => 123,3,hacer algo más

exten => 123,4,hacer una última cosa

exten => 123,5,Hangup()

Éste tipo de sintaxis realmente ya no se usa en las nuevas versiones de Asterisk, pues resulta engorroso agregar líneas intermedias cuando ya se han enumerado todas. Desde la versión 1.2 se agregó la prioridad n (next), así cada vez que Asterisk encuentra una prioridad llamada n, toma el número anterior y lo aumenta en 1. Esto hace que sea más fácil hacer cambios en el plan de marcado, evitando tener que renumerar todas las prioridades al agregar una línea intermedia: exten => 123,1,Answer()

exten => 123,n,hacer algo

exten => 123,n,hacer algo más

exten => 123,n,hacer una última cosa

exten => 123,n,Hangup()

Se debe tener en cuenta que siempre debe existir la prioridad 1, pues de lo contrario la extensión dejará de existir para Asterisk, pues no encontrará donde empezar su plan de marcado. Para simplificar el código, una forma más sencilla de crear extensiones fue puesta a disposición; el operador “same =>” permite que no sea necesario escribir el número de la extensión, siempre que ésta permanezca igual a la de la línea anterior, y remplaza a su vez al operador “exten=>” exten => 123,1,Answer()

same => n,hacer algo

same => n,hacer algo más

same => n,hacer una última cosa

same => n,Hangup()

La sangría no es necesaria, pero hace más fácil la lectura. Éste estilo de plan de marcado permitirá copiar más fácilmente código de una extensión a otra. También se pueden adicionar etiquetas a las prioridades, esto nos sirve para hacer saltos de algún lugar de un plan de marcado a otro, haciendo referencia a dicha etiqueta, esto permite que sea más lógico y entendible la revisión del código. Más adelante veremos como hacer el salto, por el momento vemos como se escribiría: exten => 123,n(etiqueta),aplicación()

Un error común es insertar coma entre la n y el paréntesis de la etiqueta.

Aplicaciones: las aplicaciones son las encargadas de realizar las acciones específicas en el canal actual, como la reproducción de un sonido, la aceptación de tonos de entrada, buscar algo en una base de datos, marcar, colgar, entre muchas otras. En los ejemplos anteriores se introdujeron dos aplicaciones sencillas: answer() y hangup(), las cuales contestan y cuelgan el canal actual respectivamente. Estas funciones no necesitan argumentos, pero la mayoría si requieren recibir información, dichos parámetros se colocan dentro del paréntesis, separados por comas. Otra función básica muy común es Playback(), la cual recibe como parámetro la ruta de un archivo de audio para ser reproducido.

exten => 200,1,Answer()

same => n,Playback(hello-world)

same => n,Hangup()

Asterisk trae por defecto una gran cantidad de grabaciones profesionales prediseñadas, las cuales usualmente están en la carpeta /var/lib/asterisk/sounds/. Cuando se instala Asterisk se puede elegir instalar estos sonidos de ejemplo. La función Goto(), como su nombre lo indica sirve para enviar la llamada a otra parte del plan de marcado, los parámetros que recibe son los siguientes: same => n,Goto(contexto,extensión,prioridad)

La función Dial recibe cuatro parámetros, pero el cuarto no es necesario analizarlo en este trabajo de grado. same => n,Dial(Tecnología/usuario,tiempo-fuera,opciones)

Las tecnologías que Asterisk maneja más comúnmente son SIP, DAHDI e IAX2. Éste proyecto de grado se enfoca en la tecnología SIP. También se puede marcar a varios canales al mismo tiempo concatenándolos con el símbolo “&”. El tiempo fuera indica la cantidad de segundos en que se esperará respuesta del equipo llamado. Si la llamada se contesta antes del tiempo fuera se puenteará la comunicación y el plan de marcado habrá terminado. Si el canal de destino no contesta, está ocupado o no está disponible, Asterisk asignará una variable llamada DIALSTATUS con el valor obtenido y luego continuará con la siguiente prioridad del plan de marcado. El tercer argumento son las opciones, hay una gran cantidad de ellas, para efectos del trabajo de grado se utilizaron r y t. La opción r envía tonos de espera o tonos de timbrado al llamante inclusive aunque en realidad en el canal destino no esté timbrando. La opción r permite al llamado transferir la llamada por medio de una secuencia de tonos DTMF configurada en el archivo features.conf Ejemplo: exten => 201,1,Dial(SIP/201,10,rt)

Asterisk también puede manejar variables, para esto se usa la función SET(). Ejemplo: exten => 301,1,Set(LEIF=SIP/0000FFFF0001)

same => n,Dial($LEIF,20)

Asterisk es sensible a mayúsculas y minúsculas. Las variables CHANNEL y EXTEN están reservadas para el sistema. Es común por notación ver que las variables globales se escriben en mayúsculas (NOMBREDEVARIABLE) y las variables de canal se escriben en camel case (nombreDeVariable). La variable EXTEN almacena el número que ha discado el usuario llamante. Las variables globales se definen en el contexto [globals], sin necesidad de usar la función set. [globals]

LEIF=SIP/0000FFFF0001

También se pueden definir dentro de otro contexto por medio de la función GLOBAL(): exten => 301,1,Set(GLOBAL(LEIF=SIP/0000FFFF0001))

Las variables de canal se definen por medio de la función set, como vimos en un ejemplo muy parecido al anterior.

Asterisk se vale de patrones de marcado para verificar las marcaciones que realiza el usuario para así poder agruparlos por tipos de llamadas, como entre extensiones, locales, nacionales, internacionales, etc. Los patrones de marcado empiezan con guion bajo ( _ ). Luego del guión bajo se pueden usar las siguientes letras: X coincide con un dígito del 0 al 9 Z coincide con un dígito del 1 al 9 N coincide con un dígito del 2 al 9 [15-7] coincide un simple carácter, el 1 o los numero del 5 al 7, incluyéndolos. . Comodín, coincide uno o más caracteres, no importa cual. Ejemplo: exten => _[1-3]XX,1,Playback(auth-thankyou)

En éste ejemplo, al marcar un número del 100 al 399 reproducirá el archivo auth-thankyou. Por ejemplo para llamadas locales, el patrón sería NXXXXXX, pues en los números locales no se usa el 1 en la primera cifra. Un patrón para llamadas nacionales sería por ejemplo 05ZNXXXXXX Otra función utilizada fue GotoIf() la cual es un salto condicional, es decir que verifica una condición y dependiendo de su validez salta a una determinada etiqueta. GotoIf(condición?destino1:destino2)

Si la condición o prueba lógica es verdadera la llamada se enrrutará al destino 1, de lo contrario irá al destino 2. Los destinos se pueden escribir de las siguientes tres maneras:

Extensión

Prioridad, extensión

Contexto, prioridad, extensión

Uno de los dos destinos puede estar vacío para efectos de ahorro de código, por ejemplo: exten => 201,1,Set(TEST=1)

same => n,GotoIf($[$TEST = 1]?medellin:bogota)

same => n(medellin),Playback(bienven-medellin)

same => n,Hangup()

same => n(bogota),Playback(bienven-bogota)

same => n,Hangup()

Puede escribirse como: exten => 345,1,Set(TEST=1)

same => n,GotoIf($[$TEST = 1]?:bogota)

same => n,Playback(bienven-medellin)

same => n,Hangup()

same => n(bogota),Playback(bienven-bogota)

same => n,Hangup()

Otras funciones utilizadas:

LEN: En el plan de marcado escrito para el trabajo de grado, se usó además la función LEN(), la cual devuelve el tamaño que tiene la variable o cadena que recibe. NoOp: La función NoOp, aunque su nombre indique que no realiza ninguna operación, sirve para imprimir mensajes en la consola de Asterisk (CLI), por ejemplo se puede usar para verifica estados de variables permitiendo hacer un debug en caliente. MusicOnHold(): Como su nombre lo indica, sirve para activar la música en espera.

Macros: Se pueden ver como subrutinas del plan de marcado de propósito general, a las cuales se les pueden pasar argumentos. Es muy parecido a una función en otros tipos de lenguajes de programación.

Para definir una macro basta con escribir la palabra macro seguida de un guion y luego de éste el nombre que se le va a asignar, por ejemplo: [macro-buzon]

Para ejecutar esta macro, por ejemplo pasándole un argumento sería: exten => 101,1,Macro(buzon,ocupado)

Una macro posee variables intrínsecas y otras que se pasan como argumentos: $MACRO_CONTEXT Contexto original desde donde la macro fue llamada. $MACRO_EXTEN Extensión original desde donde la macro fue llamada. $MACRO_PRIORITY Prioridad original desde donde la macro fue llamada. $ARG n Son los argumentos que se pasaron al llamar la macro.

En el ejemplo anterior al llamar a $ARG 1, ésta sería igual a “ocupado”. La declaración de las extensiones, canales y troncales; y sus parámetros respectivos se encuentran en el fichero sip.conf. Con dichos parámetros Asterisk sabrá cómo controlar dicho canal. Cuando un usuario marca desde una extensión a otra, primero se verificará el contexto en el archivo extensions.conf, para llevar a cabo el comportamiento del flujo de llamada, dicho archivo es el encargado de marcar a la extensión llamada. Esto lo podemos ver más claramente en la Figura 14.

Figura 14. Relación de extensiones dentro de los archivos de configuración.

Fuente: Madsen et al. Asterisk the definitive guide. Tercera edición. El tipo de configuración depende del tipo de extensión o canal que se está usando. Hay tres tipos de definición que permitirán un comportamiento distinto de Asterisk: type=peer: Permite solicitudes entrantes basándose en la IP de la fuente y el puerto type=user: Permite solicitudes entrantes basándose en el nombre de usuario en el encabeza FROM de la solicitud SIP type=friend: Permite solicitudes en ambos tipos, peer y user. Por medio del parámetro autocreatepeer, permite a OpenBTS crear extensiones en el Asterisk de forma automática. Los archivos de configuración con su respectiva explicación, se encuentran en el ANEXO B.

2.4 PRUEBAS, AJUSTES Y RESULTADOS FINALES

Para verificar la funcionalidad del prototipo de la estación celular portátil, se realizaron una serie de pruebas iniciando con la de arranque del sistema que consiste en conectar el USRP1 a la energía y luego al puerto USB2.0 del computador. Se abre una terminal y se inicia corriendo OpenBTS.

cd ~/openbts-2.6.0Mamou/apps

./OpenBTS

Luego se abre otra terminal y se conecta remotamente al prompt CLI de Asterisk con el siguiente comando:

asterisk -rvvv

Es importante conocer cuáles son los comandos útiles desde el prompt CLI de OpenBTS y Asterisk. El cuadro 6 describe estos comandos para OpenBTS y el cuadro 7 para Asterisk.

Cuadro 6. Comandos relevantes desde el prompt CLI de OpenBTS

Comando Descripción

help Lista todos los comandos disponibles.

help <cmd> Información de un comando particular.

exit Cierra OpenBTS.

cellid Muestra el ID de la celda.

rolllac Incrementa el LAC en uno.

sendsms <IMSI> <SRC> Envía un mensaje de texto al IMSI desde el número SRC

tmsis Lista el IMSI asociado y el respectivo TMSI

tmsis clear Borra la tabla de TMSIS

power Inspecciona o cambia la potencia de downlink

Fuente: Autores

Cuadro 7. Comandos relevantes desde el prompt CLI de Asterisk

Comando Descripción

dialplan reload Recarga el plan de marcado

sip reload Recarga el archivo sip.conf

sip show peers Muestra los dispositivos SIP y su estado

exit Cierra el CLI pero no para Asterisk

Fuente: Autores

La siguiente prueba fue de conexión de los celulares a la microcelda. OpenBTS se había configurado previamente para la identificación de la red, pero no se obtenía el mensaje de bienvenida y tampoco salían ni entraban llamadas porque no se tenía configurado Asterisk.

Inicialmente, al hacer la prueba de conexión, no se vieron los resultados en los celulares puesto que no se conectaron a la red creada para el funcionamiento del prototipo debido a que continuaban conectados a la red del operador a la cual estaban suscritos los celulares. Para superar la prueba se cambió la configuración de los teléfonos ya que ellos tienen la opción de selección y modo de búsqueda de red en el menú herramientas o ajustes. Por defecto, el modo de búsqueda es automático, pero se requirió cambiarlo a modo de búsqueda manual para que los celulares iniciaran la búsqueda de redes disponibles. Una vez hecho esto la pantalla del celular muestra la lista de redes disponibles, se elige la red OpenBTS; en algunos casos podría mostrar el nombre como “732003” que corresponde al “MCC 732 y MNC 003” configurado anteriormente en el archivo OpenBTS.config. De esta forma el celular, al conectarse con la microcelda, recibe un mensaje indicando cuál es el IMSI del celular. Igualmente se puede observar en la terminal donde estaba corriendo OpenBTS un mensaje que dice: “LocationUpdatingController registration FAIL: IMSI=732103022299561”. OpenBTS arrojó fallo en el intento de registro SIP porque este IMSI aún no se había provisionado en la configuración de Asterisk. Las pruebas se realizaron con un teléfono de marca Alcatel OT-203, un Nokia, un Iphone y un Samsung GT-E1086L que no conectó. Luego se repitieron las pruebas en el laboratorio pero el Samsung definitivamente no conectó; sin embargo, los otros tres teléfonos sí lo hicieron. Es necesario destacar que la señal de los operadores no era muy buena en el laboratorio.

La siguiente prueba consistió en definir el usuario SIP con el IMSI proporcionado en las pruebas anteriores para cada celular. Se realizaron los ajustes registrando en el archivo sip.conf el IMSI como nombre de usuario SIP, y en el extensions.conf un pequeño plan de marcado (dialplan) que añade un número de extensión por teléfono y ejecuta la aplicación de marcado cuando se digite el número de las extensiones, en este caso, 102 o 103.

Para la configuración de Asterisk se realizó el siguiente procedimiento:

Se abre el archivo sip.conf

gedit /etc/asterisk/sip.conf

Al final del archivo se escribe lo siguiente:

[732103022299561] ;Nombre del usuario SIP ext. 102.

callerid= "Julian Vasquez" <102>

canreinvite= no

type= friend

context= sip-local

allow= gsm

host= dynamic

dtmfmode= info

[732101018239328] ;Nombre del usuario SIP ext. 103.

callerid= "Ivan Santa" <103>

canreinvite= no

type= friend

context= sip-local

allow= gsm

host= dynamic

dtmfmode= info

Se abre el archivo extensions.conf:

gedit /etc/asterisk/extensions.conf

Al final del archivo se escribe lo siguiente:

[sip-local]

exten => 102,1,Macro(dialSIP,SIP/732103022299561)

exten => 103,1,Macro(dialSIP,SIP/732101018239328)

[macro-dialSIP]

exten => s,1,Dial($ARG1)

exten => s,2,Goto(s-$DIALSTATUS,1)

exten => s-CANCEL,1,Hangup

exten => s-NOANSWER,1,Hangup

exten => s-BUSY,1,Busy(30)

exten => s-CONGESTION,1,Congestion(30)

exten => s-CHANUNAVAIL,1,playback(ss-noservice)

exten => s-CANCEL,1,Hangup

Se realizó el ajuste de la versión de Asterisk desinstalando la versión 1.8 e instalando la versión Asterisk 1.6.2.22. Se trabajó sobre la opción autocreatepeer en el archivo de configuración, en la sección [general] de sip.conf. Se cambió el plan de marcado para manejar de forma “automática” la asignación del número de extensión de los usuarios de la red. Al establecer autocreatepeer=yes se realiza una especie de autoregistro porque permite la aceptación de cualquier intento de registro de usuario SIP con Asterisk PBX.

Se ajustó el archivo OpenBTS para agregar el mensaje de bienvenida: “Bienvenido a EmergencyBTS para registrarse marque 1234”. Si se observa la

terminal donde está conectado a Asterisk, se puede ver que un nuevo IMSI ha sido registrado. Al marcar 1234 se asigna el número 1001 al celular. El paso anterior se repite con los otros celulares, asignando los número 1002, 1003 y así sucesivamente hasta el número 1012. En la terminal donde se está conectado a Asterisk se puede evidenciar los pasos de registro y asignación de números en el prompt CLI de Asterisk. Hay que tener en cuenta que una típica configuración para un ARFCN soporta 7 llamadas concurrentes72.

Fue necesario cambiar el hardware para deshabilitar el reloj de 64 MHz y proceder al montaje de uno de 52 MHz.

Finalmente, para añadir otro cliente SIP al sistema se utilizó el softphone Zoiper para pruebas, se logró conectar el teléfono Samsung GT-E1086L, el Alcatel OT-203 y se agregó un Huawei. Esta prueba se realizó en un sótano con la señal de los operadores nula. Es preciso aclarar que la prueba se debe realizar en una zona donde la señal de los operadores celulares sea nula, con el fin de que la señal que genera OpenBTS no sea enmascarada por la señal de los operadores.

Además se instaló Asterisk GUI como administrador Web y se añadió una nueva extensión SIP por medio de este.

Por último, se midió como cobertura unos 10 metros. La conexión se realizó sin necesidad de quitar la batería y la SIM card, se probaron los mensajes enviados desde la terminal donde corre OpenBTS con el comando sendsms, de la siguiente forma:

OpenBTS> sendsms 732101018239328 1001

Prueba de un sms con EmergencyBTS

De esta manera se envía un mensaje al celular con IMSI 732101018239328 desde el número 1001.

72 Range Networks. OpenBTS P2.8 Users’ Manual. Op. cit. p. 23

3. DIFICULTADES, BENEFICIOS Y RECOMENDACIONES

3.1 Dificultades en la instalación.

La instalación se llevó a cabo desde el centro de software de Ubuntu, por lo que se instalaba la última versión, en ese momento Asterisk 1.8, que presenta un problema a nivel de SIP trabajando con OpenBTS, haciendo que las llamadas se terminen a los 32 segundos. Por esto, se recomienda el uso de versiones basadas en Asterisk 1.4 o 1.6.

Se recomienda instalar el DAHDI porque ofrece ventajas en las aplicaciones del plan de marcado de Asterisk. Ahora, al instalar el DAHADI, se presentó un error de instalación porque no estaban instalados los encabezados, razón por la cual es necesario instalar los headers del kernel que se están utilizando. Para subsanar esta dificultad, fue necesario volver a correr el comando y reiniciar la instalación de DAHDI:

sudo apt-get install linux-headers-`uname -r`

En la instalación de Asterisk, los archivos de sonido bajaron dañados o corruptos debido a un problema de conexión, por lo que se generó este error:

gzip: stdin: invalid compressed data--format violated

make: *** [datafiles] Error 2

Se recomienda eliminar los archivos de sonido y reiniciar la instalación de Asterisk.

sudo rm /usr/src/asterisk-1.6.2.22/sounds/*

cd /usr/src/

sudo tar -zxvf asterisk-1.6.2.22.tar.gz

cd asterisk-1.6.2.22

sudo make menuselect

sudo make

sudo make install

sudo make config

sudo make samples

Debido a que el intérprete Python no encuentra el directorio de las librerías, se debe agregar la línea /usr/local/lib al archivo ld.so.conf. Lo anterior es un problema de Debian/Ubuntu.

sudo gedit /etc/ld.so.conf

Quedando el archivo de la siguiente manera:

include /etc/ld.so.conf.d/*.conf

/usr/local/lib

Guardar, cerrar y correr:

sudo ldconfig

3.2 Dificultades en la operación.

El USRP1 viene con un reloj por defecto de 64 MHz. Se sabía que el registro de los celulares podría fallar porque los relojes de GSM son derivados de 13 MHz73 por lo cual se recomienda trabajar con un reloj de 52 MHz de alta precisión. Así, se vio la necesidad de comprar un reloj, pero este, solo lo vendían en el exterior. Fue inevitable adquirir dos relojes, dado que el primero, comprado en Alemania, no se pudo programar a la frecuencia requerida y fue imperioso comprar un nuevo reloj en Holanda, lo cual retrasó injustificadamente la realización del proyecto.

Al inicio de la conexión se tuvo problemas porque al escanear automáticamente la lista de redes disponibles no aparecía en los celulares la red con la que se estaba haciendo la prueba. Como quiera que en la búsqueda automática no apareciera la red, se procedió a listarlas de manera manual sin obtener resultados positivos. Se recomienda, entonces quitar la batería y la SIM card para borrar el TMSI. En ocasiones fue necesario agregar la red “732003” en la lista de redes predefinidas del celular y ponerla con prioridad UNO. Después escanear de nuevo para que apareciera la “732003”.

Como ya se dijo en las dificultades de instalación, se estaba instalando la última versión de Asterisk desde el centro de software de Ubuntu, lo cual ocasionó dificultades en la operación porque las llamadas duraban 32 segundos. En la terminal de Asterisk se apreciaban algunos errores y warnings de tráfico RTP. Debido a esto, cuando se intentaba rechazar o colgar una llamada, el celular que inició la comunicación no se colgaba, y quedaba activo hasta los 32 segundos.

Al hacer el cambio del reloj de 64 a 52 MHz y ejecutar OpenBTS se apreciaba en la terminal el siguiente error:

73 GNU Radio Project. Reclocking the USRP-1 for OpenBTS: Hardware modifications to the USRP to use a external clock. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSClockModifications> [consulta: 9 Oct. 2011].

1254342002.0361 ALARM 1077699712 Transceiver.cpp:519: RX failed

to tune

1254342002.0375 ALARM 1073875856 TRXManager.cpp:357: RXTUNE

failed with status 1

1254342002.0805 ALARM 1073875856 TRXManager.cpp:409: POWERON

failed with status 1

1254342002.0850 ALARM 1073875856 TRXManager.cpp:422: SETPOWER

failed with status 1

Para enmendar este error se recomienda cambiar el archivo OpenBTS.config para que quede de la siguiente manera:

#TRX.Path ../Transceiver/transceiver

TRX.Path ../Transceiver52M/transceiver

Al ejecutar ./OpenBTS OpenBTS aparece el siguiente error:

bind()failed: Address already in use

terminate called after throwing an instance of 'SocketError'

Aborted

El error es producido porque anteriormente se cerró OpenBTS de forma no adecuada y se quedó el proceso transceiver en ejecución. Como solución se recomienda matar el proceso transceiver con el siguiente comando:

killall transceiver

El archivo OpenBTS.config no se pudo abrir, originando el siguiente error:

Starting program: OpenBTS

Reading symbols for shared libraries .+++.+ done

cannot open configuration file OpenBTS.config

El error se produce porque no existe el archivo de configuración OpenBTS.config. Esta archivo no es necesario crearlo desde cero, simplemente se copia el archivo de configuración de ejemplo "OpenBTS.config.example" que está en ~/openbts-2.6.0Mamou/apps a "OpenBTS.config" en la misma carpeta. Para ello se ejecuta:

cp ~/openbts-2.6.0Mamou/apps/OpenBTS.config.example ~/openbts-

2.6.0Mamou/apps/OpenBTS.config

4. POSIBLES MEJORAS AL PROTOTIPO

4.1 MEJORA EN ALCANCE Y POTENCIA.

El rango de cobertura máximo definido en la especificación GSM de una BTS a una MS es de 35 Km. Por otra parte, según Pahlavan74, las microceldas abarcan desde cientos de metros hasta 1 km más o menos. Con un USRP1 y una sola tarjeta hija RFX, el rango cae a alrededor de 10 metros. Con un USRP1 más dos tarjetas hijas WBX, aproximadamente se logran 25 metros, empero, la versión OpenBTS P2.6 Mamou no posee soporte para trabajar con una sola tarjeta hija RFX ni para tarjetas hijas WBX, es necesario utilizar la versión OpenBTS-UHD.75 Usando una sola tarjeta hija RFX1800 con un duplexer y LNA (Low-Noise Amplifier, Amplificador de Bajo Ruido) se podría obtener un rango de 200 metros en un espacio abierto sin un amplificador de potencia.

El alcance de sistemas simples basados en la familia USRP no está limitado por la potencia de trasmisión o ganancia del receptor sino por la pérdida de potencia trasmitida de regreso al receptor, principalmente a través de las antenas y el aumento del piso de ruido en el receptor de -80 a -50 dBm en lugar de los -121 dBm que debería ser. Uno de los principales factores que limitan el rendimiento de una BTS es el aislamiento entre el uplink y el downlink. A menos que se tenga más de 130 dB de aislamiento entre el receptor y el trasmisor, no tiene ningún sentido incrementar la potencia de salida e intentar mejorar la ganancia del receptor. De hecho, aumentando la potencia trasmitida probablemente hará que el rendimiento sea peor e inclusive se podría mejorar el alcance disminuyendo la potencia de salida.76

Cuando muchas MS’s intentan conectarse simultáneamente con la BTS, se congestiona el canal y la BTS responde con un mensaje de rechazo de asignación de canal (Immediate Assignment Reject). Este mensaje lleva un valor, T3122, que indica cuánto tiempo la MS rechazada debe esperar antes de hacer otro intento de acceso a la red. OpenBTS implementa un algoritmo de back-off exponencial (exponential back-off algorithm) que causa que el valor T3122 crezca exponencialmente siempre que se congestione el canal. Los límites para el valor T3122 son establecidos en los parámetros de configuración GSM.T3122Max y GSM.T3122Min, dados en milisegundos en el archivo OpenBTS.config. Si se desea deshabilitar esta funcionalidad se establecen los dos parámetros mínimo y máximo con el mismo valor. 74 PAHLAVAN, Kaveh y KRISHNAMURTHY, Prashant. Principles of Wireless Networks. New Jersey: Prentice Hall PTR, 2002. p. 53. 75 GNU Radio Project. OpenBTS Frequently Asked Questions. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSFAQ> 76 Ibid. s.p.

OpenBTS puede automáticamente ajustar su potencia de downlink (la trasmisión de la BTS a la MS) para limitar carga y prevenir congestión. Esta característica es especialmente útil en áreas donde hay gran cantidad de suscriptores.77 También existen aplicaciones donde se requiere limitar la potencia a trasmitir. Los parámetros de configuración en el archivo OpenBTS.config asociados a este mecanismo son:

GSM.PowerManager.TargetT3122: Este es el valor aceptable de T3122 que el ciclo administrador de potencia intenta alcanzar. Si el actual valor de T3122 es mayor que este, la BTS reducirá su potencia de salida. Si el actual valor de T3122 es menor que este, la BTS incrementará su potencia de salida (si no está ya maximizada). Este valor debe estar entre los límites puestos en GSM.T3122Max y GSM.T3122Min.

GSM.PowerManager.Period: Este es el tiempo de adaptación constante en milisegundos.

GSM.PowerManger.MaxAttenDB: La máxima atenuación permitida, dada en dB, la cual determina el mínimo nivel de potencia de salida. Este es también el nivel de atenuación inicial.

GSM.PowerManager.MinAttenDB: La mínima atenuación permitida, dada en dB, la cual determina el máximo nivel de potencia de salida. Este valor es normalmente cero, permitiendo que la BTS opere en el máximo nivel de potencia soportado por el hardware.

Para deshabilitar el control de potencia automático, se pone el mínimo y el máximo nivel de atenuación al el mismo valor, normalmente cero, para permitir que la BTS opere al máximo nivel de potencia admitida por el hardware todo el tiempo.

GSM utiliza un control de potencia de lazo cerrado para uplink (la trasmisión de la MS a la BTS). Los máximos niveles de potencia de salida de una MS son descritos en la especificación GSM 05.05 sección 4.1.1. En el cuadro 8 se pueden observar estos niveles para una modulación GMSK que es soportada por OpenBTS. Una MS multi-banda puede tener diferentes clases de potencia en cada una de las bandas que soporta. La menor potencia de salida disponible en cualquier banda es de 5 dBm.78 El rango de control de potencia se determina con los parámetros de configuración GSM.MS.Power.Min y GSM.MS.Power.Max, ambos expresados en dBm, y estan están normalmente establecidos en 5 y 39 respectivamente. Estas son configuraciones globales aplicadas a todas las MS’s de forma uniforme. Por ejemplo, el efecto de establecer el valor de GSM.MS.Power.Max a algo menos

77 Range Networks. OpenBTS P2.8 Users’ Manual. Op. cit. p. 34. 78 Ibid. p. 35.

que 39 dBm en GSM900 va a perder cualquier ventaja de rango que tendría por ser una MS de potencia clase 2. Si una MS recibe un valor de potencia (GSM.MS.Power.Min y GSM.MS.Power.Max) que esté por fuera de sus rangos de potencia disponibles, esa MS va a definir su potencia de salida al nivel disponible más cercano, ya sea el máximo o el mínimo. Por lo tanto no hay ningún riesgo en definir estos parámetros de forma más amplia de lo que la MS soporta. Sin embargo en algunas instalaciones puede ser deseable limitar la potencia de la MS para prevenir interferencias con otras celdas en el área.

Cuadro 8. Máxima potencia de salida para una MS GSM modulación GMSK

Potencia clase

GSM850 GSM900 Máx. Potencia

DCS1800

Máx. Potencia

PCS1900

Máx. Potencia

1 N/A 1 W (30 dBm) 1 W (30 dBm)

2 8 W (39 dBm) 0.25 W (24 dBm) 0.25 W (24 dBm)

3 5 W (37 dBm) 4 W (36 dBm) 2 W (33 dBm)

4 2 W (33 dBm) N/A N/A

5 0.8 W (29 dBm) N/A N/A

Fuente: Especificación GSM 05.05 sección 4.1.1

Para el control de sincronización uplink, GSM utiliza un control de avance temporal de lazo cerrado. En OpenBTS el parámetro de configuración GSM.MS.TA.Max determina un límite en el avance temporal de la MS y puede ser usado para limitar deliberadamente el rango del servicio. El valor de este parámetro puede variar entre 1 y 63 y, cada incremento en uno, equivale aproximadamente a 550 metros. El valor normal para este parámetro es 63 que equivale a un rango máximo de 35 km.

Para verificar y cambiar algunos parámetros de potencia trabajando con OpenBTS se cuenta con los dos siguientes comandos:

Comando power: Muestra o cambia los parámetros de potencia de downlink. Si no se le pasan argumentos, este comando muestra la configuración actual de potencia y sus límites. Para definir el nivel de atenuación se usa el comando power de la siguiente manera.

OpenBTS> power <minAtenuación> <maxAtenuación>

Comando chans: Muestra el estado del canal físico para canales dedicados activos. No se le pasan argumentos y dentro de los valores de reporte que pasa está el TXPWR que especifica la potencia actual de uplink (desde la MS) en dBm:

OpenBTS> chans

Para ayudar a mejorar la potencia y alcance logrando obtener una mayor cobertura se pueden usar unos componentes entre el USRP1 y la antena. Estos componentes son descritos a continuación:

Duplexer: Para pruebas con baja potencia está bien el uso de antenas separadas para la recepción y la trasmisión, no obstante, el uso de un duplexer es necesario para evitar que la señal de trasmisión afecte la señal de recepción, aumentando el nivel de aislamiento entre las dos señales y compartiendo una antena en común.

Amplificador de potencia: Para el aumento de la potencia de la señal trasmitida se requiere un amplificador con una muy buena eficiencia. La potencia de trasmisión emitida no debe sobrepasar la máxima potencia de salida para una estación base definida en la especificación GSM 05.05 sección 4.1.2, ni tampoco violar los límites de intensidad de campo establecidos por el Ministerio de Tecnologías de la Información y las Comunicaciones.

LNA: Una de las especificaciones importantes en el diseño de los receptores de RF es la sensibilidad. Esta indica la capacidad del receptor para capturar señales débiles, por lo que será una medida directa del alcance del sistema. El uso de un LNA ayuda a superar cualquier ruido o diafonía dentro del USRP1 y aumenta el nivel de sensibilidad del receptor.

BPF (Band-Pass Filter, Filtro Pasa Banda): proporciona un aumento en el aislamiento de la señal de downlink y uplink y aumenta la selectividad del receptor.

Para proceder a realizar los cálculos de los requisitos que deben cumplir los diferentes componentes y la máxima distancia estimada en la BTS y la MS se supone un escenario donde se utilizan los siguientes componentes:

Antena de 10 dB de ganancia ubicada a 15 metros de altura.

Cable RF LMR-600, con una atenuación nominal de 0.082 dB/m @ 900 MHz. Se usarán 16 metros, para una pérdida de 1.3 dB.

Un duplexer con una pérdida de inserción de 1 dB.

Un LNA con una figura de ruido de 1 dB.

La potencia de la MS de 33 dBm (2 W). MS de potencia clase 4 en GSM850/900.

Un BPF con una pérdida de inserción inferior a 1 dB y una frecuencia de paso para uplink. No es tenido en cuenta en los cálculos.

Trayectoria de recepción - uplink (de la MS a la BTS)

MS → Antena → Cable → Duplexer → LNA → BPF → USRP1

Primero se procede a calcular el piso de ruido térmico en un canal GSM. Para calcular la potencia de ruido de un ancho de banda dado, se necesita establecer el ruido base (base noise) que es la potencia de ruido en un ancho de banda de 1 Hz. Conociendo esto, se multiplica la potencia de ruido en 1 Hz por el ancho de banda en Hz. Se define la potencia de ruido térmico como:

Sus unidades están en dBW, K es la constante de Boltzmann = 1.380 x 10-23 (J/K), T es la temperatura en grados Kelvin (K) y B es el ancho de banda en Hertz (Hz). A una temperatura ambiente (290 K) y en un ancho de banda de 1 Hz se calcula la potencia:

Al pasar el valor a dBm se tiene:

Donde -174 dBm/Hz es la potencia de ruido térmico para un ancho de banda de 1 Hz a temperatura ambiente. Esta potencia de ruido se utiliza en los cálculos del diseño de un sistema de radio. Para calcular el piso de ruido térmico en un canal GSM se toma el ancho de banda del canal, que como se describió en el capítulo 2, es de 200 KHz.

-121 dBm es el piso de ruido térmico en un canal GSM.

El rango completo del ADC en el USRP1 es de 2V pico-pico, con una entrada de 50 ohms diferencial. Lo que se traduce en una potencia de entrada de 10mW (V2

rms/50), o 10dBm. El nivel de piso de ruido es alrededor del 5% del rango completo cuando el receptor está operando a máxima ganancia, dando un piso de

ruido de -16 dBm. El USRP1 ya tiene una ganancia interna de hasta 81 dB79 por lo que se obtiene un piso de ruido en el conector de entrada de -97 dBm. Conociendo el piso de ruido térmico en un canal GSM (-121 dBm) se necesitará (-97) – (-121)= 24 dB de ganancia en el LNA. Sin contar la ganancia requerida para compensar las pérdidas por inserción y pérdidas en el cable.

Como se describió en los requerimientos de hardware, la tarjeta hija RFX900 tiene una NF (Noise Figure, Figura de Ruido) de 8 dB, por lo que se calcula el piso de ruido en el receptor de la siguiente forma.

Ahora se calcula la sensibilidad del receptor:

La relación señal a ruido de la señal modulada Ec/No es de 8 dB según la especificación GSM 03.30 sección 3.2. Por lo que se tiene:

Este es el nivel mínimo de señal que el receptor es capaz de detectar de forma adecuada. Una referencia del nivel de sensibilidad es descrita en la especificación GSM 05.05 sección 6.2 tanto para la MS como para la BTS.

Se calcula la máxima pérdida en la trayectoria (Path Loss) permitida para obtener una señal de -105 dBm que corresponde con la sensibilidad del receptor.

Se tiene entonces:

Resolviendo queda:

Donde PL es el Path Loss permitido, en este caso PL=144.7 dB.

79 GNU Radio Project. Burning Man 2009 RF Chains. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSBM2009RF>

Trayectoria de trasmisión - downlink (de la BTS a la MS)

USRP1 → PA → Duplexer → Cable → Antena → MS

Se supone que se tiene una licencia para trasmitir señal celular a una potencia de 20 W (43 dBm). En la trayectoria de trasmisión se tiene también en cuenta la pérdida en el duplexer y en el cable, al igual que la ganancia de 10 dB de la antena. Se procede a calcular la ganancia máxima a la salida del amplificador sin que sobrepase el límite de potencia de trasmisión de 20 W (43 dBm). Analizando la trayectoria desde el PA a la antena se tiene:

Donde T es la potencia de trasmisión desde el PA a la antena. Resolviendo se obtiene que T es igual a 35.3 dBm. La potencia de salida del USRP1 es de 200 mW (23 dBm) especificado por la tarjeta hija RFX900, por lo que se requiere una ganancia en el PA de 12.3 dB. En conclusión, el PA que se requiere debe tener una potencia de salida de 35.3 dBm y una ganancia de 12.3 dB. Si la ganancia del PA con que se cuenta es mayor, se puede ajustar la potencia de salida del USRP1 o utilizar un atenuador.

Según Pahlavan80, es conveniente utilizar el modelo empírico desarrollado por Bertoni et. al para áreas donde se utilizan microceldas. Teniendo el Path Loss se puede calcular el rango de alcance de cobertura estimado de la microcelda. Se plantea el siguiente escenario donde se opera en la banda GSM850 MHz en un área urbana con edificios altos y la MS está localizada en una calle perpendicular a la BTS con LOS (Line-Of-Sight, Línea de Vista). Teniendo esto se puede usar la siguiente ecuación.

PL es el Path Loss en dB, hb es la altura de la antena de la estación base en metros, fc es frecuencia de operación en GHz y d es la distancia de alcance aproximada.

Se despeja la distancia:

Remplazando los valores se tiene:

80 PAHLAVAN, Kaveh y KRISHNAMURTHY, Prashant. Op. cit. p. 53.

Se resuelve y se obtiene el resultado:

Como se observa, aumenta el rango de cobertura a 2.3 km. La figura 15 muestra el diagrama de bloques de la distribución de los componentes tanto en la trayectoria de trasmisión como de recepción.

Figura 15. Diagrama de bloques de la distribución de los componentes

Fuente: Autores

4.2 ANÁLISIS ENERGÉTICO DEL PROTOTIPO Y SUGERENCIA DEL SISTEMA DE POTENCIA AUTÓNOMO.

El USRP1 es alimentado por un convertidor de potencia AC/DC conectado a la energía eléctrica con una capacidad de entrada de 100 a 240VAC, opera a 50 y 60 Hz. De esta forma podría funcionar en cualquier país. A la salida entrega 6VDC y 3A81. Si hay necesidad de utilizar otra fuente de alimentación, USRP1 tiene un conector de alimentación DC estándar 2.1mm/5.5mm. La tarjeta madre trabaja con 5VDC, sin embargo, si se le conectan las tarjetas hijas, se necesita una fuente de 6VDC para su correcta operación. El Consumo es cerca de 1,6 A con 2 tarjetas hijas conectadas a la tarjeta madre82. No se debe exceder el valor del voltaje porque debido a que las tarjetas hijas tienen reguladores LDO (Low-DropOut)

81 Incluido en el USRP-PKG adquirido a la ETTUS RESEARCH LLC. https://www.ettus.com/product/details/Power-Supply 82 HAMZA, Firas. Op. cit. p. 12.

ADP3336, a 5 V y 3.3 V, se ocasiona una disipación alta de energía y supera los límites de algunos componentes causando su daño83. La alimentación puede ser comprobada conectando la fuente de poder al USRP1 y viendo un LED parpadeando. Si no hay un LED que parpadea, se deben revisar todas las conexiones eléctricas, y verificar la continuidad en el fusible (F501, cerca del conector de alimentación). Si el fusible necesita ser remplazado, este es SMD de tamaño 0603 de 3 A.

El computador portátil trabaja a un voltaje de 19V y un consumo máximo de corriente de 2.15A.

4.2.1 Acercamiento al sistema de potencia autónomo

Los dos equipos necesarios para el funcionamiento de la microcelda; USRP y computador portátil, trabajan con voltaje de corriente directa, lo cual permite tomar una fuente de voltaje de DC y regularla para obtener los voltajes deseados.

Se recomienda usar baterías de automóvil, pues son de fácil consecución, y permiten una larga duración y una fácil recarga por medio del mismo auto.

El diagrama de bloques simplificado se puede observar en la Figura 16.

83 Ibid. p. 14.

Figura 16. Diagrama de bloques simplificado del sistema de potencia autónomo

Fuente: Autores

Para obtener un voltaje de 6V con una corriente de salida máxima de 1.6 se puede utilizar un regulador LM7806C, cuya corriente máxima de salida es de 2.2A.84 Dicho regulador entrega directamente el voltaje de 6V necesario para el funcionamiento del USRP.

Para obtener un voltaje de 19V de DC desde una fuente de DC hay varias opciones. Una de las más sencillas es por medio del comúnmente utilizado LM317. La corriente máxima de salida de dicho regulador es de 3.4A.85

La aplicación típica de dicho circuito es el de regulación de voltaje de directa en un rango de 1.2V a 25V, lo cual se puede observar en la figura 17.

84 National Semiconductors. LM140A/LM140/LM340A/LM340/LM7800C Series. 3-Terminal Positive Regulators. 85 National Semiconductors. LM117/LM317A/LM317 3-Terminal Adjustable Regulator.

Figura 17. Aplicación Típica del LM317: Regulador de voltaje

Fuente: LM117/LM317A/LM317. 3-Terminal Adjustable Regulator. National Semiconductor.

El capacitor C1 es necesario si los capacitores de filtros están a más de 6 pulgadas del dispositivo. El capacitor C2 es opcional y mejora la respuesta transitoria. Los capacitores de salida en el rango de 1uF a 1000uF de aluminio o de tantalio son comúnmente usados para aumentar la impedancia de salida y el rechazo de transitorios.

La ecuación que rige el voltaje de salida Vout es la siguiente:

(

)

Lo ideal es que tienda a 0, por lo cual el segundo término se cancela. La

resistencia R1es comúnmente fijada a 220Ω y la resistencia R2 se puede obtener por medio de cálculo, y acercarla a un valor comercial o llegado el caso y como se observa en el circuito; usar una resistencia variable.

Así, si queremos un voltaje de salida de 19V la ecuación será la siguiente:

(

)

El circuito resultante es el mostrado en la Figura 18.

Figura 18. Circuito de potencia básico.

Fuente: Autores.

Se debe tener en cuenta que el circuito de potencia autónomo fue diseñado para las necesidades básicas de energía del sistema, es decir, no se tuvo en cuenta las posibles mejoras de alcance que se pueden hacer con un amplificador de potencia.

CONCLUSIONES

Mediante una Estación Celular Portátil se puede contribuir en la atención de desastres o emergencias donde las redes tienen una alta probabilidad de colapsar o carecen de cobertura necesaria en el lugar del suceso, además se ha comprobado que por medio de las comunicaciones se han mitigado los efectos de los desastres. Dentro de las ventajas que tiene la telefonía móvil celular es la rápida restauración de su red comparada con otro tipo de comunicación de difusión como la televisión o el radio, otra ventaja es la descentralización de la comunicación lo que permite que la información se transmita persona a persona. El prototipo de una Estación Celular Portátil se puede desarrollar apelando al proyecto OpenBTS que genera una interfaz de aire GSM Um, que es la interfaz que se usa para establecer la comunicación entre la MS y la BTS en una arquitectura de red GSM convencional. OpenBTS hace uso del hardware USRP y el software GNU Radio corriendo sobre un computador. Además utiliza el software Asterisk para realizar el control y conmutación de las llamadas. Usando dos tarjetas hijas RFX900 con un duplexer, un amplificador de potencia, un LNA (Low-Noise Amplifier, Amplificador de Bajo Ruido), un BPF (Band-Pass Filter, Filtro Pasa Banda) se podría obtener un radio de alcance de 2.3 Km. Para la implementación y desarrollo de la estación se usaron hardware y software libre, lo cual es ventajoso pues se tiene acceso al código fuente, además cuenta con soporte disponible a través de foros y listas de correos, igual que todos los esquemáticos y lista de materiales para el hardware. Para la implementación y desarrollo de la estación celular se usó el sistema operativo Ubuntu 10.04 LTS, en el cual se instalaron eficientemente los programas para el despliegue de la solución. En el software se utilizó la versión de Asterisk 1.6.2.22 porque las versiones basadas en Asterisk 1.8 presentan problemas integradas con la versión de OpenBTS P2.6 Mamou que fue usada. Además se utilizó GNU Radio 3.4.2. OpenBTS implementa la pila de protocolos GSM y permite que un celular GSM estándar sea visto como un cliente SIP dentro de Asterisk, permitiendo de esta forma hacer llamadas telefónicas sin usar las redes de los operadores convencionales.

El USRP1 tiene por defecto un reloj de 64 MHz que no es el adecuado para el buen funcionamiento de GSM, por lo que es necesario utilizar uno de 52 MHz con una alta precisión mayor a 0.05 ppm. El reloj utilizado Fairwaves СlockTamer viene especialmente diseñado para usarse con el USRP1.

BIBLIOGRAFÍA

AGENCIA NACIONAL DEL ESPECTRO. Uso eficiente del espectro radioeléctrico. [en línea] 2010. <Disponible en: http://ane.gov.co/apc-aa-files/35383137643637613966333438336638/cartilla_3.pdf> p. 20

BLOSSOM, Eric. GNU Radio: Tools for Exploring the Radio Frequency Spectrum. [en línea]. Jun 01, 2004. [en línea]. <Disponible en: http://www.linuxjournal.com/article/7319> [consulta: 10 Ene. 2012].

BRYANT, Russell. Asterisk. EN: The Architecture of Open Source Applications : Elegance, Evolution, and a Few Fearless Hacks. 2011. P. 1-14.

BURGESS, David A. y SAMRA, Harvind S. The Open BTS Project. [en línea]. 3 Ago. 2008. <Disponible en: http://www.ahzf.de/itstuff/papers/OpenBTSProject.pdf> [consulta: 2 Feb. 2012].

BURGESS, David A. Low Cost Cellular Networks with OpenBTS. Año 2010. <Disponible en: http://www.osbr.ca/ojs/index.php/osbr/article/view/1052/1011> [consulta: 15 Feb. 2012].

COLOMBIA. PRESIDENCIA DE LA REPÚBLICA DE COLOMBIA. Decreto Ley 919. (1, mayo, 1989). Por el cual se organiza el Sistema Nacional para la Prevención y Atención de Desastres y se dictan otras disposiciones. Diario Oficial. Bogotá, 1989. No. 38799.

COLOMBIA, CONGRESO DE LA REPÚBLICA. Constitución Política de Colombia. (20, julio, 1991). Gaceta Constitucional. Bogotá, 1991. No. 116.

COLOMBIA. PRESIDENCIA DE LA REPÚBLICA DE COLOMBIA. Decreto 93. (13, enero, 1998). Por el cual se adopta el Plan Nacional para la Prevención y Atención de Desastres. Diario Oficial. Bogotá, 1998. No. 43217.

COLOMBIA, CONGRESO DE LA REPÚBLICA. Ley 1032. (22, junio, 2006). Por la cual se modifican los artículos 257, 271, 272 y 306 del Código Penal. Diario Oficial. Bogotá, 2006. No. 46307.

COLOMBIA, CONGRESO DE LA REPÚBLICA. Ley 1341. (30, julio, 2009). Por la cual se definen principios y conceptos sobre la sociedad de la información y la organización de las TIC, se crea la ANE y se dictan otras disposiciones. Diario Oficial. Bogotá, 2009. No. 47426.

CASEY, Douglas. GNU Radio and the USRP as a solution for remote emergency monitoring. Año 2004. [en línea]. <Disponible en:

http://www.csb.uncw.edu/mscsis/complete/pdf/TuckerCasey_Final.pdf> [consulta: 10 Ene. 2012].

CHEMERIS, Alexander. Clock Tamer Calibration: Introduction. [en línea]. OCT. 18, 2011. <Disponible en: http://code.google.com/p/clock-tamer/wiki/ClockTamerCalibration> [consulta: 16 Ene. 2012].

ETTUS RESEARCH LLC. Brochure for the entire USRP product family. [en línea]. Actualizado, año 2010. <Disponible en: http://www.olifantasia.com/gnuradio/usrp/files/datasheets/usrp_productline_brochure.pdf> [consulta: 10 Oct. 2010].

ETTUS RESEARCH LLC. USRP motherboard datasheet. [en línea]. Actualizado, año 2010. <Disponible en: http://www.olifantasia.com/gnuradio/usrp/files/datasheets/er_ds_usrp_v5b.pdf> [consulta: 10 Oct. 2011].

ETTUS RESEARCH LLC. USRP Bus Series: USRP1. [en línea]. Año 2012. <Disponible en: https://www.ettus.com/product/category/USRP_Bus_Series> [consulta: 10 Ene. 2011].

FAIRWAVES. Clock Tamer project. [en línea]. Año 2011. <Disponible en: http://code.google.com/p/clock-tamer/ > [consulta: 10 Ago. 2011]

FLORES, Darío. Manual de uso e instalación de OpenBTS. [en línea]. Año 2011. <Disponible en: https://wush.net/trac/rangepublic/attachment/wiki/WikiStart/Manual%20de%20instalaci%C3%B3n%20de%20OpenBTS%20Versi%C3%B3n%200.2.pdf > [consulta: 5 Feb. 2012].

GNU Radio Project. Building and Running OpenBTS: Dependencies. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSBuildingAndRunning> [consulta: 9 Oct. 2011].

GNU Radio Project. Building and Running OpenBTS: Building and Installing, Building dependencies: libusrp. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSBuildingAndRunning> [consulta: 9 Oct. 2011].

GNU Radio Project. The OpenBTS Wiki Subspace. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTS> [consulta: 9 Oct. 2011].

GNU Radio Project. OpenBTS: UHD Devices: USRP1. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSUHD> [consulta: 9 Oct. 2011].

GNU Radio Project. Desktop Testing of OpenBTS. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSDesktopTestingKit> [consulta: 9 Oct. 2011].

GNU Radio Project. Reclocking the USRP-1 for OpenBTS: Hardware modifications to the USRP to use a external clock. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSClockModifications> [consulta: 9 Oct. 2011].

GNU Radio Project. Building GNU Radio on Ubuntu Linux: Install the Pre-Requisites. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall> [consulta: 6 Jul. 2011].

GNU Radio Project. Burning Man 2009 RF Chains. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSBM2009RF>

GNU Radio Project. OpenBTS Frequently Asked Questions. [en línea]. Año 2011. <Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSFAQ>

GORRICHO, Mónica y GORRICHO, Juan Luis. Comunicaciones móviles. Barcelona: UPC, 2002.

GSMA. The role of mobiles in disasters and emergencies. [en línea]. 2005. <disponible en: http://www.enlightenmenteconomics.com/about-diane/assets/disasterreport.pdf>

HAMZA, Firas. The USRP under 1.5X Magnifying Lens!. [en línea]. Actualizado 12 de junio de 2008. <Disponible en: http://gnuradio.org/redmine/attachments/download/129> [consulta: 5 Oct. 2011].

HAMDI, Fatma. GSM/GPRS Evaluation and optimization tool. Año 2006. [en línea]. <Disponible en: http://es.scribd.com/doc/49823859/18/Figure-1-2-Signalling-protocol-structure-in-GSM> [consulta: 2 feb. 2012].

HERNANDO RÁBANOS, José María. Comunicaciones móviles. 2 ed. Madrid: Centro de Estudios Ramón Areces, 2004. 744 p.

KREBS, Antonia. La segunda On line. Sistema de alerta temprana estará operativo en Chile a comienzos del 2012. [en línea]. 2011. <Disponible en: http://www.lasegunda.com/Noticias/Economia/2011/03/633291/Sistema-de-alerta-temprana-estara-operativo-en-Chile-a-comienzos-del-2012>

LACKEY, Joshua. Kalibrate: SUMMARY. [en línea]. Ago. 29, 2010. <Disponible en: http://thre.at/kalibrate/> [consulta: 16 Ene. 2012].

MADSEN, Leif; VAN MEGGELEN, Jim y BRYANT, Russell. Asterisk : The Definitive Guide. 3 ed. Sebastopol, CA: O’Reilly Media, 2011. 736 p. ISBN 978-0-596-51734-2.

MEŠKOVIĆ, Saša. Implementation of Uncoordinated Direct Sequence Spread Spectrum (U-DSSS) using Software Defined Radios. Abril. 2008. [en línea]. <Disponible en: http://e-collection.library.ethz.ch/eserv/eth:30545/eth-30545-01.pdf> [consulta: 2 Feb. 2012]. p. 9.

MINISTERO DE TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIÓNES. Estudio vulnerabilidad y riesgo de redes e infraestructura de telecomunicaciones en zonas vulnerables expuestas a eventos desastrosos. Bogotá, 2010. p. 395.

PAHLAVAN, Kaveh y KRISHNAMURTHY, Prashant. Principles of Wireless Networks. New Jersey: Prentice Hall PTR, 2002. p. 583. PATRICELLI, F.; BEAKLEY. J; CARNEVALE, A. Disaster management and mitigation: the telecommunications infrastructure. EN: Disasters. Enero. 2009. 33, p. 23-37.

RANGE NETWORKS. OpenBTS P2.8 Users’ Manual. Año 2011. [en línea]. <Disponible en: https://wush.net/trac/rangepublic/attachment/wiki/WikiStart/SoftwareP2.8Manual.pdf> [consulta: 11 Ene. 2012].

RUOLIN Zhou, OMER Mian, XUE Li, BIN Wang y ZHIQIANG Wu. A software-defined radio based cognitive radio demonstration over FM band. Año 2009. [en línea]. <Disponible en: http://onlinelibrary.wiley.com/doi/10.1002/wcm.903/abstract> [consulta: 5 Nov. 2011].

RODRIGUEZ MUÑOZ, David. Sistemas inalámbricos de comunicación personal: El sistema panaeuropeo: GSM. 1 ed. México, D.F.: Alfaomega, 2001. 333 p.

RANGE NETWORKS. OpenBTS Public Release. [en línea]. Año 2011. <Disponible en: https://wush.net/trac/rangepublic> [consulta: 9 Feb. 2012].

(R)[49] RANGE NETWORKS. OpenBTS P2.8 Users’ Manual. Año 2011. [en línea]. <Disponible en: https://wush.net/trac/rangepublic/attachment/wiki/WikiStart/SoftwareP2.8Manual.pdf> [consulta: 11 Ene. 2012].

STEIL, Andreas. OpenBTS. [en línea]. Actualizado, año 2010. <Disponible en:http://www.fh-kl.de/~andreas.steil/Projekte/OpenBTS/index.html> [consulta: 11 Oct. 2011].

SHAJEDUL HASAN, S.M.; Balister, P. Prototyping a Software Defined Radio Receiver Based on USRP and OSSIE. Dic 14, 2005. [en línea]. <Disponible en: http://www.ece.vt.edu/swe/chamrad/crdocs/CRTM01_051214_USRP.pdf> [consulta: 11 Ene. 2012].

VAN MEGGELEN, Jim; MADSEN, Leif y SMITH, Jared. Asterisk : The Future of Telephony. 2 ed. Sebastopol, CA: O’Reilly Media, 2005. 408 p. ISBN 978-0-596-00962-5.

WATERMEYER, Kalen. Design of a hardware platform for narrow-band Software Defined Radio applications. Ene. 2007. [en línea]. <Disponible en: http://www.rrsg.uct.ac.za/theses/msc_theses/kwatermeyer_thesis.pdf > [consulta: 2 Feb. 2012].