PROTOTIPO DE UNA ESTACIÓN CELULAR PORTÁTIL

Transcripción

PROTOTIPO DE UNA ESTACIÓN CELULAR PORTÁTIL PARA ATENCIÓN DE
EMERGENCIAS
JULIÁN DAVID VÁSQUEZ GUTIÉRREZ
[email protected]
IVÁN FERNADO SANTA RAMÍREZ
[email protected]
JOSÉ VALENTÍN RESTREPO LAVERDE
[email protected]
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í:

3
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.
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.

4
5
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.
Ibid. p. 133.
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-alertatemprana-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/aboutdiane/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
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
concientización ciudadana15.
para
capacitación,
toma
de
decisiones
y
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
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.

18
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
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=83b9c79498dcd8dfd7c5a69d819b
929282c9c1ba9d8f9a81d883d5c2a1dc929c

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:

21
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
MADSEN, Leif; VAN MEGGELEN, Jim y BRYANT, Russell. Asterisk : The
Definitive Guide. 3 ed. Sebastopol, CA: O’Reilly Media, 2011. ISBN 978-0-59651734-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-3054501.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ón 29. 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
Spectrum (U-DSSS) using Software Defined Radios. Abr. 2008. [en línea].
<Disponible
en:
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 aplicaciones 36.
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-Signallingprotocol-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
450 a 458 824 a 849 890 a 915 1710
a 1850
a
frecuencia
MHz
MHz
MHz
1785 MHz 1910 MHz
uplink
Rango
460 a 468 869 a 894 935 a 960 1805
a 1930
a
frecuencia
MHz
MHz
MHz
1880 MHz 1990 MHz
downlink
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.pd
f> [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
profesionales.
comercial, monitoreo
de
redes u
otros
servicios
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.
<Disponible
en:
f> [consulta: 11 Ene. 2012]. p. 15.
51
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%2
0de%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

54
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
Ibid. p. 15.
GNU Radio Project. Building and Running OpenBTS: Dependencies. [en línea].
Año
2011.
<Disponible
en:
http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSBuildingAndRunning>
56
GNU Radio Project. OpenBTS: UHD Devices: USRP1. [en línea]. Año 2011.
<Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSUHD>
57
FLORES, Darío. Op. cit. p. 14.
55
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>
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
Tarjetas
hijas
Antenas
USRP
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>

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 sdcclibraries \
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-qwt5qt4
61
GNU Radio Project. Building GNU Radio on Ubuntu Linux: Install the PreRequisites.
[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/gnuradio3.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:
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",
SYSFS{idVendor}=="fffe",
SYSFS{idProduct}=="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
ntotal = 2000000
nright = 1998041
runlength = 1998041
delta = 1959
OK
ntotal = 4000000
nright = 3999272
runlength = 3999272
delta = 728
OK
ntotal = 8000000
nright = 7992153
runlength = 7992153
delta = 7847
OK
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
libortp-dev
install
python-all-dev
libboost-dev
libosip2-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/openbts2.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
2.6.0Mamou/apps/OpenBTS.config
~/openbts-
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
64
GNU Radio Project. Building and Running OpenBTS. Op. cit. p. 1.
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.4current.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/dahdilinux-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
http://downloads.asterisk.org/pub/telephony/asterisk/oldreleases/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
wget
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 otros 65. 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
sudo
sudo
sudo
make
make install
make config
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
sudo
sudo
sudo
sudo
sudo
sudo
chown
chown
chown
chown
chown
chown
chown
-R emergencybts:emergencybts /etc/asterisk/
-R emergencybts:emergencybts /usr/lib/asterisk/
-R emergencybts:emergencybts /var/lib/asterisk/
-R emergencybts:emergencybts /var/spool/asterisk/
-R emergencybts:emergencybts /var/log/asterisk/
-R emergencybts:emergencybts /var/run/asterisk/
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",
MODE="0660"
OWNER="emergencybts",
GROUP="emergencybts",
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
http://downloads.asterisk.org/pub/telephony/asterisk/oldreleases/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
wget
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
sistema donde Asterisk ya está corriendo como un demonio. Probablemente
usa esta opción más que cualquier otra para sistemas con Asterisk que están
producción. Para salir del prompt CLI cuando esta opción ha sido usada,
escribe exit y se cierra la conexión, pero Asterisk no dejará de correr.
un
se
en
se
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.0rc1 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/clocktamer/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
3 dígitos
MNC
MSIN
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
732
001
732
002
732
011
732
099
732
101
732
102
732
103
732
111
732
123
732
130
Fuente: International Numbering Plans
Operador de la red
Telefónica Telecom
Edatel
Edatel
Emcali
Comcel
Movistar
Tigo
Tigo
Movistar
Avantel
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
EmergencyBTS para registrarse marque 1234
Control.NormalRegistrationWelcomeShortCode 0000
a
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
exten
exten
exten
exten
=>
=>
=>
=>
=>
123,1,Answer()
123,2,hacer algo
123,3,hacer algo más
123,4,hacer una última cosa
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
exten
exten
exten
exten
=>
=>
=>
=>
=>
123,1,Answer()
123,n,hacer algo
123,n,hacer algo más
123,n,hacer una última cosa
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=>”
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.
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
N
[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 auththankyou.
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
same
same
same
=>
=>
=>
=>
n(medellin),Playback(bienven-medellin)
n,Hangup()
n(bogota),Playback(bienven-bogota)
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
help
help <cmd>
exit
cellid
rolllac
sendsms <IMSI> <SRC>
tmsis
tmsis clear
power
Fuente: Autores
Descripción
Lista todos los comandos disponibles.
Información de un comando particular.
Cierra OpenBTS.
Muestra el ID de la celda.
Incrementa el LAC en uno.
Envía un mensaje de texto al IMSI desde el
número SRC
Lista el IMSI asociado y el respectivo TMSI
Borra la tabla de TMSIS
Inspecciona o cambia la potencia de downlink
Cuadro 7. Comandos relevantes desde el prompt CLI de Asterisk
Comando
dialplan reload
sip reload
sip show peers
exit
Fuente: Autores
Descripción
Recarga el plan de marcado
Recarga el archivo sip.conf
Muestra los dispositivos SIP y su estado
Cierra el CLI pero no para Asterisk
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 GTE1086L 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 OT203 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 MHz 73
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:
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
1254342002.0850 ALARM 1073875856 TRXManager.cpp:422: SETPOWER
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 ~/openbts2.6.0Mamou/apps a "OpenBTS.config" en la misma carpeta. Para ello se ejecuta:
cp
~/openbts-2.6.0Mamou/apps/OpenBTS.config.example
2.6.0Mamou/apps/OpenBTS.config
~/openbts-
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
78
Range Networks. OpenBTS P2.8 Users’ Manual. Op. cit. p. 34.
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
1
N/A
1 W (30 dBm)
2
8 W (39 dBm)
0.25 W (24 dBm)
3
5 W (37 dBm)
4 W (36 dBm)
4
2 W (33 dBm)
N/A
5
0.8 W (29 dBm)
N/A
Fuente: Especificación GSM 05.05 sección 4.1.1
PCS1900
Máx. Potencia
1 W (30 dBm)
0.25 W (24 dBm)
2 W (33 dBm)
N/A
N/A
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
(V2rms/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. 3Terminal 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-aafiles/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>
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>
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
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
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/clocktamer/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_brochu
re.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>
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%20i
nstalaci%C3%B3n%20de%20OpenBTS%20Versi%C3%B3n%200.2.pdf
>
GNU Radio Project. Building and Running OpenBTS: Dependencies. [en línea].
Año
2011.
<Disponible
en:
GNU Radio Project. Building and Running OpenBTS: Building and Installing,
Building dependencies: libusrp. [en línea]. Año 2011. <Disponible en:
GNU Radio Project. The OpenBTS Wiki Subspace. [en línea]. Año 2011.
<Disponible
en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTS>
GNU Radio Project. OpenBTS: UHD Devices: USRP1. [en línea]. Año 2011.
<Disponible en: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSUHD>
GNU Radio Project. Desktop Testing of OpenBTS. [en línea]. Año 2011.
<Disponible
en:
http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSDesktopTestingKit>
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:
GNU Radio Project. Building GNU Radio on Ubuntu Linux: Install the PreRequisites.
[en
línea].
Año
2011.
<Disponible
en:
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/aboutdiane/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-Signallingprotocol-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-alertatemprana-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-0596-51734-2.
Spectrum (U-DSSS) using Software Defined Radios. Abril. 2008. [en línea].
<Disponible
en:
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.
<Disponible
en:
f> [consulta: 11 Ene. 2012].
RUOLIN Zhou, OMER Mian, XUE Li, BIN Wang y ZHIQIANG Wu. A softwaredefined 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:
f> [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-59600962-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].

PROTOTIPO DE UNA ESTACIÓN CELULAR PORTÁTIL

Transcripción

Documentos relacionados

Descarga aqui - Carol Automatismos Igualada SA

Curso: Introducción a la VoIP y Asterisk

Revista informatica.qxp

Guía Metodológica para el análisis forense

GPRS - Si busca información sobre el proyecto de Clusters, el