pablo e. bullian
I M P L E M E N TA C I Ó N D E R E D C E L U L A R G S M C O N H A R D WA R E S D R
pablo e. bullian
Proyecto Final Ingeniería en Telecomunicaciones
Escuela de Ciencia y Tecnología – Universidad Nacional de San Martin
tutor:
R E S U M E N
El presente proyecto se centra en la aplicación de hardware de radio-frecuencia reconfigurado por software para darle un uso de estación base celular. Además se aprovechan algunas implementaciones de software libre para cumplir los roles de los distintos elementos de una red Core celular y asi poder tener un sistema autónomo com-pleto. Sumado a esto último se investiga el rendimiento del mismo y sus posibles optimizaciones para actuar en un ambiente que no sea únicamente de laboratorio.
Toda la implementación se hace con software FOSS1(Software de có-digo abierto y libre) con lo cual no queda reducido a ningún provee-dor de software particular sino a un ecosistema mucho más amplio de posibles arreglos para lograr el mismo o similar resultado.
Por último, el presente documento desarrollado en LaTeX2 se presen-ta bajo la licencia BY-SA 4.0 de Creative Common3 para el libre uso del material presentado.
1 Free and Open Source Software: http://www.gnu.org.ua/philosophy/ free-software-for-freedom.html.
2 LaTeX:https://www.latex-project.org/.
Í N D I C E G E N E R A L
i introduccion teorica i
1 introducción iii
1.1 Procesamiento Digital de Señales . . . v
1.1.1 Teorema de Nyquist, muestreo y cuantificación. v 1.1.2 Elementos de un sistema PDS . . . vii
1.1.3 Conceptos del Procesamiento Digital . . . viii
1.2 Principio de Operación de los SDR . . . ix
1.2.1 Esquema Ideal . . . ix
1.2.2 Receptores SDR Comerciales . . . ix
1.3 Introducción a GNURadio . . . xi
1.4 Software OpenBTS y red GSM . . . xiii
1.5 Tecnologia GPRS . . . xvii
1.5.1 Estructura de Trama . . . xviii
1.5.2 Estructura de un burst GPRS . . . xix
1.6 Tecnologia VoIP . . . xix
1.6.1 Software Asterisk . . . xxi
ii implementacion xxiii 2 implementación xxv 2.1 Esquema Introductorio . . . xxv
2.2 Hardware y Software Utilizado . . . xxvi
2.2.1 Servidor con GNU/Linux . . . xxvi
2.2.2 Software Defined Radio . . . .xxvii
2.2.3 Antenas . . . .xxviii
2.2.4 Telefonos de prueba y SIMs . . . xxix
2.3 Software Utilizado en el Servidor . . . xxx
2.4 Instalación OS y Modulos principales . . . xxxi
2.4.1 Instalación UBUNTU . . . xxxi
2.4.2 Compilacion OpenBTS e instalación de bibliote-cas requeridas . . . xxxi
2.4.3 Instalación Modulos OpenBTS . . . .xxxiii
2.5 Pruebas de Funcionamiento . . . xxxv
2.5.1 Placa SDR . . . .xxxv
2.6 Configuración del Servidor e inicialización . . . .xxxviii
2.6.2 Configuraciones Principales OpenBTS . . . xl
2.6.3 Configuracion para el ruteo de llamadas en
As-terisk . . . xlii
2.6.4 Salida de llamadas fuera de la red celular . . . xliii 2.7 Configuracion de red IP para GPRS . . . xliv 2.8 Configuración de los terminales . . . xlvi 2.8.1 Creacion de suscriptores en SIPAuthServe . . .xlviii 2.8.2 Registracion contra el SGSN . . . .xlviii
iii mediciones y resultados li
3 mediciones y optimización liii
3.1 Mediciones con HackRF y GNURadio . . . liii 3.1.1 Esquema en GNURadio . . . liv 3.2 Capturas de tráfico con GNU-Radio . . . lvi 3.3 Calculo de perdidas en espacio libre con modelado
Okumura/Hata . . . lix
3.4 Medición de cobertura con analizador de frecuencia . . lx
iv conclusiones lxiii
4 conclusiones lxv
4.1 Conclusión . . . lxv
v anexos lxvii
5 anexos lxix
5.1 Script de Inicio de la Interfaz . . . lxix 5.2 Reglas IPTables . . . lxxi 5.3 Script para tomar datos de Medición . . . lxxi 5.4 Calculo de puntos para modelado Okumura/Hata . .lxxiii 5.5 Esquema GNURadio para recepción . . . .lxxiv
Í N D I C E D E F I G U R A S
Figura 1 Esquema en bloques del sistema implementado iv
Figura 2 Esquema de sinusoides muestreadas . . . vi
Figura 3 Procesamiento analógico de una señal . . . vii
Figura 4 Procesamiento digital de una señal analógica . viii
Figura 5 Esquema de un tradicional transmisor analogico x
Figura 6 Esquema de un SDR receptor y transmisor . . x
Figura 7 Ejemplo de diagrama de Bloques del entorno
visual de GnuRadio . . . xii Figura 8 Esquema de una red Celular GSM tradicional.
Siglas en Cuadro3 . . . xiii Figura 9 Esquema de una red Celular con transporte IP xvii
Figura 10 Esquema de transporte de datos a traves de
tramas GPRS . . . xix Figura 11 Estructura de un Burst GSM/GPRS normal . . xix Figura 12 Esquema de comunicación VoIP . . . xx
Figura 13 Esquema en bloques del sistema implementado xxv Figura 14 Esquema de arquitectura interna del SDR B210xxvii
Figura 15 Antena de uso interno para frecuencias de GSMxxviii
Figura 16 Sims de Prueba . . . xxx
Figura 17 Calculo de Kc en terminal y Estacion base . . . xxx
Figura 18 Esquema de servicios en OpenBTS . . . .xxxii
Figura 19 Arquitectura de conexión de los modulos . . .xxxv
Figura 20 Laboratorio con elementos de medición . . . .xxxix
Figura 21 Arte ascii como interfaz de usuario . . . xl
Figura 22 Captura con GNURadio del ARFCN51con
vi-sualizacion cascada, espectro y de constelación xli Figura 23 Registro de SIP exitoso . . . xliv
Figura 24 Esquema de ruteo de IPTables . . . xlvi
Figura 25 Busqueda de redes mobiles con una SIM de
operador comercial . . . xlvi Figura 26 Registración con una SIM comercial . . . xlvii
Figura 27 Lista de TMSIs . . . .xlviii
Figura 28 Registración correcta con una SIM de operador
Figura32 Origen SDR . . . liv
Figura33 Receptor GSM . . . lv
Figura34 Adaptador GSM . . . lv
Figura35 Mapeadores de Canales . . . lvi
Figura36 Salida a socket PDU . . . lvi
Figura37 Visualizaciones . . . lvii
Figura38 Inmmediate Assigment . . . lviii
Figura39 SMS recibido . . . lviii
Figura40 Analizador de espectro centrado en el canal
ARFCN51 . . . lxi
Figura41 Diagrama completo de recepción . . . lxxv
Í N D I C E D E C U A D R O S
Cuadro1 Definición de las siglas de la figura6. . . xi
Cuadro2 Definicion de Siglas de Red celular . . . xvi
Cuadro3 Definición de las siglas de la figura9. . . xviii
Parte I
1
I N T R O D U C C I Ó N
La Radio Definida por Software (SDR) es una tecnología en rápida evolución que está recibiendo enormes reconocimiento y generando un amplio interés en la industria de las telecomunicaciones. Sobre to-do en los últimos años, los sistemas de radio analógicos están siento-do reemplazados por sistemas de radio digital como algunas aplicacio-nes de radio en espacios militares, civiles y comerciales. Además de esto, los módulos de hardware programables se utilizan cada vez más en los sistemas de radio en diferentes niveles funcionales.
La tecnología SDR tiene como objetivo aprovechar estos desarrollos Aunque el concepto de SDR no es nuevo, la reciente evolución de la circuitería digital ha hecho posible desde el punto de vista práctico muchos de los procesos que tiempo atrás eran solamente posibles desde el punto de vista teórico.
en hardware para construir un software de sistema de radio basado en arquitectura abierta. La tecnología SDR facilita la implementación de algunos de los módulos funcionales en un sistema de radio ta-les como modulación / demodulación, generación de señata-les, codi-ficación y protocolos de capa de enlace (capa 2 del modelo OSI) en
software. Esto ayuda a construir sistemas de radio de software recon-figurables donde es posible la selección de parámetros para cada uno de los módulos funcionales antes mencionados.
Un sistema de radio basado en hardware tiene una utilidad limita-da ya que los parámetros para calimita-da los módulos funcionales son fijos ya que fueron establecidos en el momento del diseño y fabricación. Un sistema de radio construido utilizando la tecnología SDR amplía la gama de aplicaciones utilizando diferentes protocolos de capa de enlace y métodos de modulación / demodulación.
La industria de las comunicaciones inalámbricas comerciales se en-frenta actualmente a problemas de una rápida evolución de los están-dares de protocolo de capa de enlace (2.5G, 3G y 4G), la existencia
SDR promete resolver estos problemas mediante la implementación de módulos de software que se ejecutan en una plataforma genérica de hardware.
Figura1: Esquema en bloques del sistema implementado
En la figura 1se esquematiza a grandes rasgos el proyecto a realizar.
Donde con la ayuda de la placa SDR actuando como transmisor/re-ceptor se procesa la información para poder lograr una red celular autónoma que cuenta con los servicios básicos de una red de dichas características como puede ser la voz, sms, servicios adicionales de re-gistración y control, y datos. Esta red también dispone por medio de la tecnología VoIP una conexión a la red telefónica tradicional, com-pletando todas las partes que componen a un servicio de red celular.
1.1 procesamiento digital de señales v
1.1 procesamiento digital de señales
El procesamiento digital de señales (PDS, digital signal processing o DSP) es el tratamiento, análisis y manipulación de la información contenida en una o más señales que a su vez pueden ser representa-das en funciones matemáticas específicas, con la finalidad de mejorar o modificar las mismas. En este sentido la señal está caracterizada por manejar la amplitud de forma discreta y por estar en función del dominio del tiempo discreto, las cuales son condiciones necesarias para que la señal pueda ser procesada por un microprocesador o un procesador DSP especializado.
1.1.1 Teorema de Nyquist, muestreo y cuantificación.
La señal de la voz es contínua en el tiempo y en amplitud. Para que pueda ser procesada por hardware(y software) digital es necesario convertirla a una señal que sea discreta tanto en el tiempo como en amplitud.
El teorema de muestreo de Nyquist-Shannon, es un teorema funda-mental de la teoría de la información. El teorema trata con el mues-treo, que no debe ser confundido o asociado con la cuantificación.
Una muestra es un valor numérico en función del tiempo. Este valor es parte de una señal continua o de una señal discreta y son extraídos de éstas para un procesado matemático mediante elementos electró-nicos que nos permita realizar funciones tales como el filtrado de una señal. El muestreo con lo que a señales respecta, es el primer paso para el procesamiento de una señal y lo que hace en sí es tomar me-didas a intervalos regulares de tiempo, llamadas muestras(samples), se graban temporalmente en un circuito de memoria (hold) y luego se hace con los pulsos resultantes lo que se tenga previsto. Finalmen-te, el muestreo permite que una señal analógica se convierte en una secuencia de números que normalmente están uniformemente espa-ciados en el tiempo
Por ejemplo en la figura 2 se denota que si tomamos las muestras de las dos señales en los instantes marcados, ambas encajan con la representación obtenida, haciendo que nuestro muestreo no pueda diferenciar entre ambas dos.
Figura2: Esquema de sinusoides muestreadas
Si la frecuencia más alta contenida en una señal analógica xa(t) es
Fmax = B y la señal se muestrea a una tasa Fs > 2Fmax ≡ 2B , entoncesxa(t)se puede recuperar totalmente a partir de sus muestras
mediante la siguiente función de interpolación
g(t) = sin2πBt2πBt
Así,xa(t)se puede expresar como:
xa(t) =P∞
n=−∞xa
n Fs
gt− n Fs
dondexa
n Fs
=xa(nT)≡x(n)son las muestras dexa(t).
Segun el teorema una señal continua se puede muestrear correcta-mente sólo si no contiene componentes de frecuencia superiores a un medio de la frecuencia de muestreo. Si el criterio no es satisfecho, existirán frecuencias cuyo muestreo coincide con otras.
La cuantificación es la conversión de una señal discreta en el tiempo evaluada de forma contínua a una señal discreta en el tiempo discre-tamente evaluada. El valor de cada muestra de la señal se representa como un valor elegido de entre un conjunto finito de posibles valores.
1.1 procesamiento digital de señales vii
1.1.2 Elementos de un sistema PDS
La mayoría de las señales en ciencia e ingeniería tienen una natu-raleza analógica, es decir, tanto las variables independientes de las funciones que las representan como sus valores son continuos. Mate-máticamente estas señales se representan como funcionesf(t)
f:ℜ→ℜ
es decir, relaciones matemáticas que mapean valores reales en valores reales. Este tipo de señales pueden ser tratadas directamente utilizan-do sistemas analógicos, como por ejemplo filtros pasivos o analizautilizan-do- analizado-res de frecuencia (figura3).
Figura3: Procesamiento analógico de una señal
El procesamiento digital (figura 4) requiere transformar las señales
de entrada a un formato digital, es decir, a funcionesf(n)
f:Z→Z
Esto ocurre en una etapa llamada conversión analógica-digital(A/D).
teléfonos celulares utilizan algoritmos de alta complejidad que hace tan solo15años hubieran requerido computadores de gran tamaño y
costo.
Figura4: Procesamiento digital de una señal analógica
El último paso del procesamiento digital consiste en convertir la sa-lida del bloque procesador a una señal analogica, lo que ocurre en el llamado convertidor digital-analogico (D/A). En aplicaciones de
análisis de señal, la última etapa puede no ser necesaria, cuando la información a extraer se obtiene directamente de las representaciones digitales.
1.1.3 Conceptos del Procesamiento Digital
Conceptos algorıtmicos clásicos del procesamiento digital son: com-presión, cifrado, reconocimiento, identificación, sintetización, elimi-nación de ruido, estimación espectral y filtrado, entre otros.
La compresión consiste en la reducción de capacidad necesaria pa-ra almacenar o tpa-ransmitir una señal. En telefonía celular se utiliza la compresion para ahorrar tiempo de transmicion y recepcion de cada terminal para poder optimizar el canal.
El cifrado es necesario para proteger la confidencialidad de la infor-mación transmitida. Como la tecnología celular utiliza un medio in-seguro (el aire) es importante que se cifre la información.
La sintetización permite producir señales artificiales similares a aque-llas generadas a traves de fenomenos fisicos.
1.2 principio de operación de los sdr ix
permiten reducir el efecto de dichas distorsiones.
El filtrado es un concepto básico del procesamiento digital que for-ma parte de prácticamente cualquier otro algoritmo. El sistefor-ma que realiza esta tarea se denomina filtro, y permite el paso de solo ciertas “componentes” de su señal de entrada, y bloqueando el paso de otras.
1.2 principio de operación de los sdr
1.2.1 Esquema Ideal
El esquema de receptor ideal sería conectar un convertidor analógico-digital a una antena. Un procesador de señales analógico-digitales leería el con-vertidor, y entonces su software transformaría la trama de datos del convertidor a cualquier otra forma programada en el software.
Un transmisor ideal sería similar. Un procesador de señal digital gene-raría un flujo de números. Éstos se enviarían a un convertidor digital-analógico conectado a una antena de radio.
El esquema ideal no es completamente realizable debido a los límites reales de la tecnología. El problema principal en ambas direcciones es la dificultad de conversión entre los dominios digital y analógico a una velocidad suficientemente alta y una precisión suficientemen-te alta al mismo tiempo y sin suficientemen-tener en cuenta procesos físicos como interferencia y resonancia electromagnética.
1.2.2 Receptores SDR Comerciales
Como se ve en la figura 5 un transmisor analogico utiliza un
Figura5: Esquema de un tradicional transmisor analogico
En cambio en un transmisor o receptor SDR como en la figura6
tene-mos una etapa de conversion analogica digital y un procesamiento di-gital que permite, con la ayuda de software como GNURadio, imple-mentar todo tipo de amplificadores, filtros, mezcladores que pueden ser modificados incluso mientras se procesa la señal sin necesidad de cambiar nada en los circuitos físicos.
Figura6: Esquema de un SDR receptor y transmisor
pre-1.3 introducción a gnuradio xi
sigla definición
ADC ó A/D conversor analogico a digital DAC ó D/A conversor digital a analogico FPGA matriz de puertas programables DSP Procesador digital de señales
ASIC Circuito integrado de aplicación específica CORBA Common Object Request Broker Architecture RF Radiofrecuencia
Cuadro1: Definición de las siglas de la figura6
ceder al paso de conversión y este dispositivo introduce sus propios problemas. Por ejemplo, si hay señales espurias (lo que es típico, sien-do las mismas un armonico de la señal deseada), estas compiten con las señales deseadas dentro del rango dinámico del amplificador. Pue-den introducir distorsión en las señales deseadas, o puePue-den bloquear-las completamente. La solución estándar es colocar filtros de paso de banda entre la antena y el amplificador, pero estos reducen la flexibi-lidad de la radio. Los dispositivos comerciales a menudo tienen dos o tres filtros de canal analógico con diferentes anchos de banda para evitar la frecuencia imagen.
1.3 introducción a gnuradio
Como se especifico en la sección anterior, los SDR se programan para hacer el procesamiento de la señal. Un set de herramientas para fa-cilitar la programación a bajo nivel que se debe hacer es utilizar las bibliotecas de GNURadio que son implementaciones en software (len-guaje de programación Python) de diversos elementos físicos para el tratamiento de las señales digitales.
in-vestigación de comunicaciones inalámbricas y los sistemas de radio del mundo real.
Figura7: Ejemplo de diagrama de Bloques del entorno visual de GnuRadio
GNU Radio realiza todo el procesamiento de la señal. Puede utilizar-se para escribir aplicaciones que reciban datos de flujos digitales o para enviar datos a flujos digitales, que luego se transmiten median-te hardware (SDRs). GNU Radio tiene filtros, códigos de canal, ele-mentos de sincronización, ecualizadores, demoduladores, vocoders, decodificadores y muchos otros elementos (identificados en la apli-cación como bloques de elementos, ver figura 7 ) que normalmente
1.4 software openbts y red gsm xiii
método para conectar estos bloques y luego gestiona cómo se pasan los datos de un bloque a otro.
Las aplicaciones de radio GNU se escriben principalmente utilizando el lenguaje de programación de Python1, mientras que la ruta de pro-cesamiento de señal crítica, que se suministra, se implementa en C ++2 utilizando extensiones de punto flotante del procesador, cuando
estén disponibles.
1.4 software openbts y red gsm
El proyecto OpenBTS es una colección de componentes de softwa-re de código abierto que se pueden utilizar para construir una softwa-red celular con software utilizando las placas SDR con transmisores/re-ceptores.
Las redes celulares tradicionales cuentan con numerosos elementos que en conjunto brindan una gama de servicios, pero estos compo-nentes deben estar separados por ejemplo la conectividad de datos se realiza a través de un servidor que se denomina GGSN (Gateway GPRS Support Node) y la de voz a traves de otro denominado GMSC (Gateway Mobile Switching Center) (ver figura8), OpenBTS permite
que la interfaz de radio Um3 de la red móvil tradicional se interco-necte directamente con los protocolos de telefonía IP (ver figura 9 y
cuadro3).
Figura8: Esquema de una red Celular GSM tradicional. Siglas en Cuadro3
La red tradicional GSM como se ve en la figura 8 se puede explicar
mirando desde la derecha desde el handset o teléfono celular. Este se
1 Lenguaje de programación Python:https://www.python.org.
2 Lenguaje de programación C++:https://isocpp.org.
conecta inalámbricamente por medio de la interfaz denominada Um hacia una estación base o BTS. Esta es la encargada de recepcionar los datos recibidos del terminal, y orquestar la comunicación cuando hay multiples de estos elementos como veremos más adelante en tramas y canales lógicos.
Este se conecta por otra interfaz lógica llamada ABIS hacia un Sub-sistema de estación base o BSC que es el encargado de manejar la señalización de la red, los casos de handover (cuando un terminal pasa de una estación base a otra más cercana a el), y es quien se-para la información a ser enviada a los demás elementos de la red discriminando la necesidad (voz, datos, registración con la red, etc.)
Este ultimo servidor se conecta por medio de la interfaz lógica de-nominada Gb al Serving GPRS support node o SGSN cuando el re-querimiento del terminal son los datos (por ejemplo navegación por internet). Este es el encargado de mantener la información del termi-nal como en que celda se encuentra, de etiquetar correctamente los datos recibidos para entregar a cada terminal y de mantener la infor-mación del uso del servicio para poder ser tarifado. Una vez que se completa la información por una interfaz lógica llamada Gn se conec-ta al Gateway GPRS support node o GGSN que es que actúa como un router entre la red celular y una red IP como internet. Es este servidor el que interconecta ambos mundos.
1.4.0.1 Proceso de establecimiento de una llamada de voz
El establecimiento de una llamada de voz entre dos terminales GSM se define a continuación.
• La central telefónica local o de tránsito reconoce el código de destino nacional corresponde a una red de comunicaciones mó-viles y, por consiguiente, encamina la llamada hacia la pasarela GMSC más cercana
1.4 software openbts y red gsm xv
• La llamada se extiende al msc, quien inicia el procedimiento de avisar al terminal de la existencia de una llamada destinada a el. Dicho procedimiento consiste en difundir un mensaje espe-cífico, concebido para esta función. La difusión se extiende al area de cobertura del MSC, ya que cabe la posibilidad de que no se conozca exactamente en qué subsistema de estaciones ba-se BSS ba-se halla el terminal. El canal a través del cual ba-se efectúa la difusión es el canal PCH (Paging CHannel).
• La terminal responde al mensaje anterior determinando de este modo su ubicación precisa en ese instante.
• Seguidamente, se autentifica al usuario y se establecen los pará-metros de cifrado de la comunicación posterior.
• El VLR comunica al MSC los parámetros necesarios para iniciar la llamada. En esta etapa, el VLR dispone de la opción de asig-nar al terminal un nuevo identificador temporal TMSI exclusivo para esta llamada
• El MSC envía un mensaje de solicitud de establecimiento de llamada al terminal. Este y los subsiguientes mensaje de señali-zación se transfieren sobre un canal dedicado SDCCH. (Stand-Alone Dedicated Control CHannel)
• El terminal confirma la recepción del mensaje y alerta al usua-rio de la existencia de una llamada entrante. Por otro lado, se transmite al abonado llamante una indicación de progreso de la llamada.
• Cuando finalmente el abonado llamado responde, su terminal envía un mensaje de conexión, a lo que la red responde adjudi-cando un canal para tráfico TCH y emitiendo el correspondiente mensaje informando de la conexión al usuario llamante. El pro-ceso termina cuando desde la red se envia a la estación móvil una confirmación, que hace pasar la llamada al estado de activa.
sigla definición
A Interfaz A Abis Interfaz Abis
AuC Central de Autenticación B Interfaz B
BSC Controlador de Estación Base BTS Estación Transductora Base GB Interfaz Gb
GGSN Nodo de soporte de Gateway para GRPS GMSC Nodo de Gateway para red conmutada celular Gn Interfaz Gn
H Interfaz H IP Internet Protocol HLR Registro de locación
MSC Centro de conmutacion de red celular Nc Interfaz Nc
SGSN Nodo de servicio de GPRS SS7-MAP Sistema de senalización7 SGSN Nodo de servicio de GPRS Um Interfaz de aire de red movil VLR Registro de servicio de locación
1.5 tecnologia gprs xvii
1.4.0.2 Caso OpenBTS
Son innecesarios cambios de software o configuración en el teléfono, ya que la interfaz de radio a la red móvil es idéntica a una red tradicio-nal. El núcleo de la red, sin embargo, ya no se compone de una serie de protocolos y servidores complejos. Consiste en protocolos abier-tos y utiliza la IP como su transporte. Ya existen muchos proyecabier-tos de software que implementan protocolos abiertos y tantos otros que hacen comunicacion VoIP como Asterisk4. También se desarrollaron nuevos componentes en OpenBTS para proporcionar funcionalidad, que todavía no estaban disponibles, para conectar los distintos servi-cios en el mundo de internet.
Figura9: Esquema de una red Celular con transporte IP
Como se ve en la figura 9 el servidor OpenBTS nuclea los distintos
elementos como BTS, BSC, SGSN, etc y se encarga de traducir como lo haría un GGSN los datos GPRS en IP y enviarlos a su destino como la voz en el protocolo SIP o RTP que son los que se comunican en servicios VoIP, por medio de los mensajes SIP que están especificados por el RFC (request for comments que es como la norma del protocolo y su especificación detallada) proximamente referido en la sección Software Asterisk.
1.5 tecnologia gprs
GPRS se basa en la estructura GSM básica. Utiliza el mismo formato de señal que tiene anchos de banda de canal de 200 kHz. También
tiene el mismo esquema de modulación siendo GMSK. Mantener el
sigla definición
Um Interfaz de aire de red GSM SIP Protocolo de iniciación de sesión RTP Protocolo de Transporte en Tiempo Real DSP Procesador digital de señales
PSTN Red telefónica pública conmutada
Cuadro3: Definición de las siglas de la figura9
mismo esquema de modulación significa que se minimiza el nivel de actualización necesario para poder admitir GPRS además de GSM.
GMSK, Gaussian Minimum Shift Keying es una forma de modulación de fase que se utiliza en un sin número de elementos de comunicaciones portátiles y varias aplicaciones inalámbricas. Tiene ventajas en términos de eficiencia espectral así como una amplitud casi constante que permite el uso de amplificadores de potencia de transmisor más eficientes, ahorrando así el consumo de energia, un problema crítico para equipos a baterías.
1.5.1 Estructura de Trama
La interfaz inalambrica de GRPS emplea la misma estructura básica que la adoptada para GSM, que es una trama similar a la dividida en ranuras por tiempo (TDMA 5). La estructura global de ranuras para este canal es la misma que la utilizada en GSM, que tiene el mismo perfil de potencia, y atributos de avance de sincronización para superar los diferentes tiempos de viaje de señal a la estación base dependiendo de la distancia que el móvil se encuentre. Esto permite que la ranura encaje perfectamente con la estructura GSM existente y no sea necesario cambiar nada en la estacion base o el terminal para soportarlo.
La unidad de datos del protocolo de la capa de red, denominada N-PDU o paquete, es recibida de la capa de red y es transmitida a través del interfaz de aire entre la estación móvil y el SGSN usando el protocolo LLC. Primero el protocolo encargado de la traduccion en-tre redes GPRS e IP denominado SNDCP transforma los paquetes en tramas denominadas logical link control o LLC caracteristicas de una red IP. El proceso incluye opcionalmente la compresión de la cabecera de datos, segmentación y encriptado. Una trama trama LLC es seg-mentada en bloques de datos denominados RLC, que son formados en la capa física, cada bloque consta de 4 bursts o rafaga normales
que son similares a las de TDMA.
1.6 tecnologia voip xix
Figura10: Esquema de transporte de datos a traves de tramas GPRS
1.5.2 Estructura de un burst GPRS
Cada GPRS de información es de0.577mS de longitud y es el mismo
que el utilizado en GSM como ya mencionamos. La ráfaga o burst GPRS lleva dos bloques de 57 bits de información en línea con una ráfaga GSM, dando un total de 114 bits por ráfaga. Por lo tanto,
re-quiere cuatro ráfagas GPRS para llevar cada 20 mS bloque de datos,
es decir,456bits de datos codificados. Las ranuras pueden ser
asigna-das dinámicamente por el BSC a GPRS dependiendo de la demanda, siendo las restantes utilizadas para el tráfico GSM.
Figura11: Estructura de un Burst GSM/GPRS normal
El BSC asigna canales logicos denominados PDCH a intervalos de tiempo particulares y habrá momentos en que el PDCH esté inactivo, permitiendo al móvil comprobar otras estaciones base y supervisar sus intensidades de señal para permitir a la red juzgar cuándo se re-quiere el traspaso o handover. La ranura GPRS también puede ser usada por la estación base para juzgar el retardo usando un canal lógico conocido como Canal de Control Avanzado de Tiempo de Pa-quetes (PTCCT).
1.6 tecnologia voip
las llamadas. Para ello utilizaremos un software que se basa en la tecnología de Voz sobre IP, siendo la voz digitalizada y procesada por software para ser transportada bajo el protocolo IP.
En mas detalle la Voz sobre Protocolo de Internet (Voz sobre IP, VoIP y telefonía IP) es una metodología y un grupo de tecnologías para la entrega de comunicaciones de voz y sesiones multimedia a través de redes IP6, como Internet. Los términos telefonía por Internet, telefo-nía de banda ancha y servicio telefónico de banda ancha se refieren específicamente al suministro de servicios de comunicaciones (voz, fax, SMS, mensajes de voz) a través de la Internet pública, en lugar de la red telefónica pública conmutada (RTPC).
Los pasos y principios implicados en la emisión de llamadas
tele-Figura12: Esquema de comunicación VoIP
fónicas VoIP son similares a la telefonía digital tradicional e implican la señalización, la configuración de canales, la digitalización de las señales de voz analógicas y la codificación. En lugar de transmitir-se a través de una red de conmutación de circuitos; Sin embargo, la información digital se empaqueta y la transmisión se produce como paquetes IP a través de una red de conmutación de paquetes. Trans-portan flujos de audio utilizando protocolos de entrega de medios especiales que codifican audio y video con códecs de audio y codecs de vídeo. Existen varios códecs que optimizan el flujo de medios ba-sado en los requisitos de la aplicación y el ancho de banda de la red; Algunas implementaciones se basan en la banda estrecha y el discur-so comprimido, mientras que otros discur-soportan códecs estéreo de alta fidelidad. Algunos codecs populares incluyen las versiones de la ley µy de G.7117, G.7228, y muchos otros.
El codec G.711 codifica la voz desde la frecuencia de 50 hz a los 7
khz, utilizando un bitrate de80a96Kbps y es el mas compatible con
6 RFC de Internet Protocol:https://tools.ietf.org/html/rfc791
7 ITU G.711:https://www.itu.int/rec/T-REC-G.711-198811-I/en
1.6 tecnologia voip xxi
los sistemas de telefonía fija digital. El codec G.722utiliza un bitrate de 24 a 32 Kbps y es preferido cuando se tiene un enlace con poca
pérdida de tramas.
1.6.1 Software Asterisk
Asterisk es una implementación de software de una central telefónica privada (PBX); Permite a los teléfonos conectados hacer llamadas en-tre sí y conectarse a otros servicios telefónicos, como la red telefónica pública conmutada (PSTN) y los servicios de Voz sobre Protocolo de Internet (VoIP).
Asterisk es lanzado con un modelo de licencia dual, usando la Li-cencia Pública General GNU (GPL)9 como una licencia de software libre10y una licencia de software propietaria para permitir a los licen-ciatarios distribuir componentes de sistemas propietarios e inéditos.
Asterisk fue creado en 1999 por Mark Spencer de Digium.
Diseña-do originalmente para Linux, Asterisk se ejecuta en una variedad de sistemas operativos, incluyendo NetBSD, OpenBSD, FreeBSD, macOS y Solaris, y otros sistemas enbebidos.
Hoy en día, hay más de un millón de sistemas de comunicaciones basados en Asterisk en uso, en más de 170países. Es utilizado por
casi toda la lista Fortune1000de clientes. Asterisk puede convertirse
en la base de un sistema telefónico comercial completo o utilizarse pa-ra mejopa-rar o ampliar un sistema existente o papa-ra supepa-rar una brecha entre sistemas.
9 Licencia GPL Version3:https://www.gnu.org/licenses/gpl.html
Parte II
2
I M P L E M E N TA C I Ó N
2.1 esquema introductorio
Para comprender mejor las subsiguientes secciones se muestra en la figura 13el esquema completo de la implementación.
Figura13: Esquema en bloques del sistema implementado
Se puede observar desde la izquierda que los módulos que residen en el servidor son primeramente el software del driver de la placa, en este caso elUHDpara las placas USRP como la utilizada (modelo B210). Este driver envía la información al OpenBTS que paquetiza (más información en las subsiguientes secciones) lo recibido y se co-necta con elSIPAuthServeque es el encargado de la la autenticación y manejo de sesiones como el BSC que se explica en el capitulo1. Este
también es encargado de redireccionar al igual que en una red GSM convencional al software Asterisk que cumple el rol del MSC para la comunicación de voz. En el caso de SMS se envía la información al SMQueue que procesa y responde a los mensajes recibidos o los redirige al OpenBTS si es un SMS de terminal a terminal.
paso intermedio por medio delTinyProxypara el caso de comunica-ciones que tienen ya marcados un proxy como los terminales Black-Berry. Todos ellos se conectan a bases SQL donde guardan la infor-mación de abonados, tarifaciones, datos históricos de transacciones e incluso las configuraciones. El ruteo externo a internet es indepen-diente, pero la conexión con la PSTN se realiza por medio de este camino con la voz paquetizada en IP.
Cuenta tambien para la administración remota con un servidorSSH (Secure SHell) para el acceso al terminal del sistema.
2.2 hardware y software utilizado
2.2.1 Servidor con GNU/Linux
El primer requisito es una PC con GNU/Linux. Aunque varias ar-quitecturas de procesadores son compatibles se utilizó un procesador x86 con software para 32 bits. Esta computadora debe ser una
má-quina fisica separada por los requisitos mínimos para la potencia de procesamiento y la RAM. Aunque no están claramente definidas las características, las numerosas variables implicadas, como el número de señales portadoras concurrentes, la carga, tipo de uso de red, en-torno de radio, etc. cada uno afectará a los recursos requeridos.
Una única señal portadora requiere que el software OpenBTS genere formas de onda de enlace descendente para transmitir al teléfono mó-vil y demodular las formas de onda de enlace ascendente recibidas desde el handset. OpenBTS soporta la creación de múltiples seña-les portadoras simultáneas en una única radio física para aumentar linealmente la capacidad de la red, pero las demandas de procesa-miento son muy altos. Para una configuración de laboratorio estable con una sola señal portadora (máximo de siete canales de voz concu-rrentes), una Intel i51 o algo comparable con2 GB de RAM es reco-mendado. También debe tener al menos una interfaz USB3.
En un entorno productivo pueden utilizarse múltiples señales porta-doras simultáneas, lo que aumenta drásticamente el ancho de banda de muestra requerido. Además, los algoritmos usados para demodu-lar señales puede configurarse para funcionar de una manera más
2.2 hardware y software utilizado xxvii
robusta (por ejemplo, para rectificar la distorsión de la señal debido al entorno de despliegue). Por lo tanto, la potencia de procesamiento necesaria para generar y demodular estas señales podría ser un orden de magnitud mayor que en una configuración de laboratorio.
2.2.2 Software Defined Radio
La radio definida por software (SDR) es el avance clave que hace OpenBTS posible desde una perspectiva de hardware. Los SDRs se han utilizado en aplicaciones militares durante unos 20 años. Sólo
recientemente se han puesto a disposición de un público más amplio debido a la disminución del costo de la tecnología.
El SDR utilizado se denomina USRP B210de la empresa laboratorio
ETTUS. Sus características principales son:
• Dispositivo USRP de dos canales totalmente integrado con cober-tura continua de RF de70MHz a6GHz.
• Funcionamiento dúplex completo, MIMO (2Tx y 2 Rx) con hasta 56 MHz de ancho de banda en tiempo real (61,44MS / s en
cuadratura).
• Conectividad USB3.0de SuperSpeed rápida.
• GNURadio y soporte de OpenBTS a través de la fuente abierta USRP Hardware Driver (UHD).
• Chip FPGA reconfigurable Spartan6XC6SLX150FPGA.
En la figura 14 se observa la arquitectura del SDR utilizado, donde, desde la izquierda, tenemos la conexión USB 3.0 de alta velocidad y
su puerto físico en el servidor. Estos datos son procesados por el dri-ver UHD el cual divide en colas las dos salidas Tx y la información de las entradas en Rx, todo procesado por el FPGA. Esta informacion es procesada en paralelo por el circuito integrado de radiofrecuencia o RFIC que referencia un conjunto de elementos para el procesamiento analogico saliendo luego a una interfaz de radio. También cuenta con un reloj integrado que se le puede ser anexado un reloj externo para más precisión, como así también un valor de referencia de frecuencia externo.
El hardware B210cubre frecuencias RF de70MHz a6GHz, tiene una
Spartan6 FPGA y conectividad USB 3.0. Esta plataforma permite la
experimentación con una amplia gama de señales incluyendo FM y difusión de TV, celular, Wi-Fi, y más. El USRP B210ofrece un total de
dos canales de recepción y dos de transmisión, un GPIO, e incluye una fuente de alimentación externa. Utiliza un Analog Devices RFIC para ofrecer una plataforma de experimentación de RF rentable y pueden transmitir hasta 56 MHz de ancho de banda instantáneo a
través de un bus USB3.0de alto ancho de banda.
2.2.3 Antenas
Figura15: Antena de uso interno para frecuencias de GSM
Muchos SDRs tienen suficiente sensibilidad de transmisión y recep-ción para operar sin antenas en un entorno pequeño. Típicamente, se puede conseguir un área de cobertura con un radio de 1 m. Esta es
2.2 hardware y software utilizado xxix
de cobertura no se superponen e interfieren entre sí. Además, la red no interferirá con ningún operador en el área.
Incluso si el área de cobertura es muy pequeña, el regulador nacional muy probablemente requiere que se obtenga una licencia de prueba antes de usar frecuencias GSM. La adición de un par de pequeñas antenas de5 dBi puede aumentar considerablemente, hasta un radio
de 25 m en un ambiente sin obstrucciones. Estas son por lo general
antenas de goma estilo pato con un conector SubMiniature versión A (SMA), similar en apariencia a una típica antena de enrutador WiFi doméstico. Un ejemplo se muestra en la Figura15.
Las antenas se instalan para una frecuencia específica, así que se eli-je una que más se aproxima a la banda GSM que va a utilizar (850, 900,1800o1900MHz). La frecuencia también juega un papel en el
ta-maño del área de cobertura. Las bandas de baja frecuencia (850y900
MHz) propagan distancias mayores que las bandas de alta frecuencia, a veces casi el doble.
2.2.4 Telefonos de prueba y SIMs
El SIM utilizado en los teléfonos GSM no es más que una tarjeta inte-ligente recortada. Las tarjetas inteinte-ligentes también se conocen como tarjetas de chip o tarjetas de circuitos integrados (ICC) y se pueden encontrar en muchas aplicaciones de autenticación e identificación. Una tarjeta inteligente de tamaño completo tiene las mismas dimen-siones que una tarjeta de crédito; Las tarjetas de crédito más nuevas utilizan la tecnología de tarjetas inteligentes para aumentar la seguri-dad. Las tarjetas SIM se programan utilizando escritores estándar de tarjetas inteligentes y, una vez escritas, se salen del marco de la tarjeta de tamaño completo para que encajen en un teléfono GSM.
ope-Figura16: Sims de Prueba
rador y el teléfono es lo que permite a la red determinar otra clave, denominada Kc, que se utiliza para dar soporte al cifrado de llama-das. Al no contar con estos datos esta característica de seguridad se perdera. La otra opción es utilizar un grabador de tarjetas inteligen-tes en el cual podemos insertar nuestro Ki personalizado sobre una tarjeta virgen con el cual se podra calcular elKc(Figura17) en ambos
lados.
Figura17: Calculo de Kc en terminal y Estacion base
Para este proyecto se utilizó SIMCards de proveedores comerciales de distintas empresas los cuales se los registra en el SIPAuthServe y conectan a la red como si fuera una conexión de una red externa (roaming).
2.3 software utilizado en el servidor
Se optó por una distribución de GNU/Linux2 denominada UBUN-TU3 en su versión LTS Server 16.04 para la instalación del OS del 2 GNU/Linux:https://en.wikipedia.org/wiki/GNU/Linux_naming_controversy
2.4 instalación os y modulos principales xxxi
servidor en donde va a estar el software de manejo de la placa SDR y el procesamiento de los datos. Estos datos van a ser tratados luego por el software OpenBTS que fue compilado en el mismo servidor en base al código fuente.
En una primera instancia se instaló el Servidor VoIP Asterisk dentro del mismo servidor y se lo conectó a la red IP por medio de su inter-faz gigabit ethernet. El mismo procesa los requerimientos de llamada y los reenvía al gateway de red telefónica IP brindado para la salida externa.
2.4 instalación os y modulos principales
2.4.1 Instalación UBUNTU
El sistema operativo fue instalado siguiendo un proceso de automa-tización. Esto permite que varias copias del mismo sistema puedan ser recreadas de forma rápida con mínima intervención humana. Esa opción además permite una fácil actualización de las subsiguientes versiones de software. El sistema para la automatización se llama an-sible4. Ansible corre por conexiones SSH5 ejecutando scripts de Pyt-hon6 que a su vez ejecutan y corroboran ejecutables del sistema.
El programa Ansible para la instalación se publicó al sistema ansible-galaxy bajo la licencia GPL versión 37. El sistema se divide en
insta-lación de paquetes, configuración de los mismo, descarga del código fuente de OpenBTS, compilación de OpenBTS y asterisk.
2.4.2 Compilacion OpenBTS e instalación de bibliotecas requeridas
Para la construccion del entorno es necesario contar con algunas he-rramientas basicas para la compilacion de paquetes, un gestor de GIT (sistema de versionamiento de codigo) y algunas herramientas espe-cificas, en este caso para ubuntu, para manejar la instalacion de los paquetes previamente compilados (APT8.).
4 Ansible:https://www.ansible.com
5 SSH:https://linux.die.net/man/1/ssh
6 Python:https://www.python.org
7 GPL V.3:https://www.gnu.org/licenses/gpl-3.0.en.html
Las bibliotecas utilizadas para la compilacion son:
• autoconf
• libtool
• libosip2
• libortp
• libusb-1.0
• g++
• sqlite3
• libsqlite3-dev
• libreadline6-dev
• libncurses5-dev
El paquete de servicios que se instala se puede visualizar en la si-guiente figura
Figura18: Esquema de servicios en OpenBTS
Los elementos del sistema se van a dividir principalmente en el Trans-receiver, que es el software que va a programar la capa1de radio,
im-plementandose sobre el hardware SDR, en este caso con los detalles necesarios para la placa de Ettus Research. Este módulo es controlado por OpenBTS.
El software OpenBTScorre la implementación del TDMA en capa 1
y luego todos los demás elementos de la capa2,3 y la comunicación
necesaria con la4. El mismo también controla las llamadas de usuario
para definir configuraciones.
2.4 instalación os y modulos principales xxxiii
base de datos conectada con los datos de los subscriptores habilita-dos.
El servidorSIPAuthServees el encargado de la registración y autori-zación SIP, quien maneja la actualizacion de ubicación de los termina-les que llegan del OpenBTS para actualizar los datos en ambas bases de datos.
El servidor de mensajes de texto SMS elSmQueuees un servicio adi-cional que no es totalmente necesario pero complementa el servicio de telefonía. El mismo tiene conexión a una base propia para manejar colas de mensaje, historiales y una conexión a la base de subscripto-res.
El servidor de Datos GPRS se controla dentro de OpenBTS pero es separado en el caso de UMTS donde es llamado OpenBTS-UMTSy se conecta a al SIPAuthServer para controlar el acceso de los subscrip-tores. Ambos sistemas, GPRS y UMTS utilizan el módulo de red de GNU/Linux para derivar los paquetes IP. La herramienta utilizada para el ruteo de los mismos es IPTables.
2.4.3 Instalación Modulos OpenBTS
Para la instalación se tomó el codigo fuente de OpenBTS desde git-hub9el cual se compilo con el script armado en el mismo denominado build.sh para la arquitectura B210que es la placa utilizada.
La compilación y el armado de los .deb se hizo modulo por modulo, primero el de la librería a53, para la encriptación de la comunicación
en caso de que se cuente con la Kc, luego el subscriber Registry que consta de la API para cargar los suscritos a la red y el sipathserve, el smqueue que es un SMS gateway , el cliente de asterisk con algunas configuraciones pre-armadas para openbts y por ultimo el modulo propiamente openbts con el transreceiver y las herramientas de inter-faz con el administrador.
Los Archivos generados fueron los siguientes:
root@openbts:/home/pbullian/dev/BUILDS/installed# ls | grep .deb
liba53_0.1_i386.deb
libcoredumper1_1.2.1-1_i386.deb
libcoredumper-dev_1.2.1-1_i386.deb
openbts_5.0_i386.deb range-asterisk_11.7.0.5_i386.deb range-asterisk-config_5.0_all.deb range-configs_5.1-master_all.deb SIPAuthServe_5.0_i386.deb smqueue_5.0_i386.deb
Los cuales se instalaron junto algunos servicios adicionales.
Uno de ellos es bind910, una implementación de servidor DNS para
poder brindar una resolución de nombres local a la red. Otro paquete es tinyproxy11, el cual se utiliza com proxy para aquellos celulares que tengan configurado el mismo en el APN y no pueda ser cambia-do como el caso de los blackberry. Se instalaron el set de herramientas y driver de ettus-research uhd, el cual se utiliza para cargar el código de la b210al FPGA de la placa y hacer algunas pruebas de
transmi-sión y recepción. Se instalo la herramienta kalibrate 12 ya que al no contar con un reloj externo se necesita tener una idea de la desviación para ajustarla en el transreceiver. Esta es una herramienta que permi-te obpermi-tener diferencias tomando como referencia anpermi-tenas de GSM de alguna empresa de telefonía celular. Algunas librerías adicionales co-mo zeroqm3 y libcoredumper13 de google fueron instaladas también
para poder compilar algunas herramientas de openbts.
En la Figura 19 podemos observar como queda el esquema
comple-to de conexionado entre los modulos. En el se visualiza la conexión de radio Um contra el hardware de radio USRP, el cual por el usb pasa la informacion para ser procesada por el software de transrecei-ver. Esta informacion se paquetiza en UDP (protocolo de capa 4 de
red montado sobre IP ) para ser tratada por OpenBTS y hacer el di-reccionamiento a cada módulo necesario, como el SIPAuthServe para la registración y control, el SMQueue para el manejo de SMS o el Asterisk para el establecimiento de llamadas de voz.
10 Documentacion Bind9:https://wiki.debian.org/Bind9
11 Documentacion Tinyproxy:https://tinyproxy.github.io/
12 Repositorio de Kalibrate:https://github.com/ttsou/kalibrate
2.5 pruebas de funcionamiento xxxv
Figura19: Arquitectura de conexión de los modulos
2.5 pruebas de funcionamiento
En la presente sección se harán las pruebas para corroborar el correcto funcionamiento de la placa, la conexión contra el driver UHD y la recepcion de informacion. También se prueba la ganancia de salida del transmisor para lograr que no se genere una retroalimentación en el receptor que sature y genere ruido a la señal recibida. Por último se hacen pruebas del SNR recibido con transmisiones de prueba.
2.5.1 Placa SDR
Para las primeras pruebas se utiliza las herramientas provistas por
Ettus-Research. En una primera instancia utilizamosuhd_images_downloader el cual detecta la placa conectada por USB y descarga de sus
servido-res la imagen a copiar en el FPGA de la placa. Para enviar la imagen descargada se utilizauhd_image_loadero el mismo openbts lo hace al iniciar el transreceiver.
La prueba de conexion y propiedades de la placa se corre conuhd_usrp_probe, que da la siguiente información.
root@openbts:/home/pbullian/dev/BUILDS/installed# uhd\_usrp\ _probe
linux; GNU C++ version 5.3.1 20151219; Boost\_105800; UHD\_003
.009.002-0-unknown
-- Detected Device: B210
-- Operating over USB 3.
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 16.000000 MHz...
-- Actually got clock rate 16.000000 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Setting master clock rate selection to ’automatic’. _____________________________________________________
/
| Device: B-Series Device
| _____________________________________________________
| /
| | Mboard: B210
| | revision: 4
| | product: 2
| | serial: 3111809
| | name: MyB210
| | FW Version: 8.0
| | FPGA Version: 13.0
| |
| | Time sources: none, internal, external, gpsdo
| | Clock sources: internal, external, gpsdo
| | Sensors: ref_locked
| |
_____________________________________________________
| | /
| | | RX DSP: 0
| | | Freq range: -8.000 to 8.000 MHz
| |
_____________________________________________________
| | /
| | | RX DSP: 1
| | | Freq range: -8.000 to 8.000 MHz
| |
_____________________________________________________
| | /
| | | RX Dboard: A
| | |
_____________________________________________________
| | | /
| | | | RX Frontend: A
| | | | Name: FE-RX2
| | | | Antennas: TX/RX, RX2
| | | | Sensors: temp, rssi, lo_locked
2.5 pruebas de funcionamiento xxxvii
| | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB
| | | | Bandwidth range: 200000.0 to 56000000.0 step
0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | |
_____________________________________________________
| | | /
| | | | RX Frontend: B
| | | | Name: FE-RX1
| | | | Antennas: TX/RX, RX2
| | | | Sensors: temp, rssi, lo_locked
| | | | Freq range: 50.000 to 6000.000 MHz
| | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB
| | | | Bandwidth range: 200000.0 to 56000000.0 step
0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | |
_____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: B210 RX dual ADC
| | | | Gain Elements: None
| |
_____________________________________________________
| | /
| | | TX DSP: 0
| | | Freq range: -8.000 to 8.000 MHz
| |
_____________________________________________________
| | /
| | | TX DSP: 1
| | | Freq range: -8.000 to 8.000 MHz
| |
_____________________________________________________
| | /
| | | TX Dboard: A
| | |
_____________________________________________________
| | | /
| | | | TX Frontend: A
| | | | Name: FE-TX2
| | | | Antennas: TX/RX
| | | | Sensors: temp, lo_locked
| | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
| | | | Bandwidth range: 200000.0 to 56000000.0 step
0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | |
_____________________________________________________
| | | /
| | | | TX Frontend: B
| | | | Name: FE-TX1
| | | | Antennas: TX/RX
| | | | Sensors: temp, lo_locked
| | | | Freq range: 50.000 to 6000.000 MHz
| | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
| | | | Bandwidth range: 200000.0 to 56000000.0 step
0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | |
_____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: B210 TX dual DAC
| | | | Gain Elements: None
En nuestro laboratorio vamos a utilizar el Frontend A.
Para las pruebas de transmisión podemos utilizar benchmark_rate –rx_rate 10e6 –tx_rate 10e6, el cual transmite y recibe en la misma
frecuencia y nos devuelve los resultados de ambos.
Tambien tenemos una prueba mas visual de receptor conrx_ascii_art_dft –freq930e6–rate 5e6 –gain20 –bw 5e6–ref-lvl -3014, como se ve en
la figura21
2.6 configuración del servidor e inicialización
Cuando se pone en funcionamiento un servidor, ya sea para correr estos programas o un servidor WEB/SMTP, etc, es necesario controlar y administrar como actúa ante los reinicios del sistema y en el caso de ser necesario cuál es la priorización de inicio de un servicio sobre otro, como por ejemplo no podemos inicializar el servicio Asterisk
2.6 configuración del servidor e inicialización xxxix
Figura20: Laboratorio con elementos de medición
sin antes contar con una conexión a internet para el acceso a la PSTN. Para ello hay herramientas en GNU/Linux que pueden ser utilizadas.
2.6.1 Inicio de los modulos
El sistema que controla hoy en dia el inicio y orquestación de de-monios en linux es llamado systemd15, quien reemplazó al antiguo programa llamadosysv16. Openbts ya tiene configuraciones para ini-ciar con upstart17, un sistema muy similar a sysv que se utilizaba en ubuntu. Al ser simple para manejar los módulos y los pocos servicios adicionales se reemplaza por el mismo instalando el paquete upstart-sysv. Para el inicio de los módulos como primer paso recomiendo iniciar el asterisk y corroborar su correcta ejecucion, para luego ini-ciar los módulos de smqueue, y SIPAuthServe los cuales si también inician correctamente puede llevarse a cabo la ejecución de openbts.
15 Systemd:https://wiki.debian.org/systemd
16 SysV:http://glennastory.net/boot/init.html
Figura21: Arte ascii como interfaz de usuario
Upstart utiliza el prefijo start o stop seguido del nombre del servicio para iniciar o detenerlos. Los logs los nuclea en /var/log/upstart/nom-bre_del_servicio.log.
Luego de un inicio correcto del transreceiver podemos visualizar los leds de la salida de antena de Tx y Rx y podemos corroborarlo si sabemos el canal y frecuencia utilizada (ARFCN), con otro SDR o un analizador de espectro. En la figura22 se visualiza una captura del
espectro tomado con el software GNURadio y un sdr HackRF en una frecuencia945.2Mhz que es el Uplink delARFCN5118el cual estaba
configurado el OpenBTS.
2.6.2 Configuraciones Principales OpenBTS
Para poder utilizar la placa USRP es necesario en base a las pruebas previamente realizadas establecer la ganancia de salida que OpenBTS va a necesitar informar al driver UHD, así también como algunas con-figuraciones de qué frecuencia utilizar y como tratar algunas señales de radio.
Algunas configuraciones básicas del sistema se acceden desde la in-terfaz OpenBTSCLI, la cual se encuentra dentro de la carpeta dev/-NodeManager. Al ejecutar el comando entramos a la configuración del OpenBTS.
2.6 configuración del servidor e inicialización xli
Figura22: Captura con GNURadio del ARFCN51con visualizacion cascada, espectro y de constelación
Primero luego de calibrar la placa es necesario setear la ganancia de la misma, por defecto el valor es muy alto para la placa B210y genera que se sature la entrada por Rx así que se disminuye a10 Db
OpenBTS> devconfig GSM.Radio.RxGain 10
Luego seteamos un nombre de fantasía para la radio base, la cual figurara en los terminales una vez que se registren, con
OpenBTS> config GSM.Identity.ShortName UNSAMnet
Podemos también configurar algunos mensajes SMS que llegan al móvil dependiendo de la modalidad de registración que utilizamos, siguiendo el mismo criterio podemos listar estas configuraciones con
OpenBTS> config Registration.Message
La cual nos dara una lista para modificar a gusto.
Luego vamos a setear algunos datos como el MCC y el MNC19de la estación con el primero MCC en722que es el codigo para Argentina,
y el MNC tiene que ser uno distinto a los MNC de los proveedores de telefonía celular en el area, ya que si no los terminales se conectan a la misma confundiendolo con la red de su SIM.
OpenBTS> config GSM.Identity.MCC 722
OpenBTS> config GSM.Identity.MNC 001
Continuando seleccionaremos el rango de frecuencia a utilizar, por ejemplo GSM900
OpenBTS> config GSM.Radio.Band 900
Y seteamos el ARFCN a un valor que no sea igual a otras redes, por ejemplo51
OpenBTS> config GSM.Radio.C0 51
En las subsiguientes secciones se configuraran los datos necesarios para una conexión por GPRS.
2.6.3 Configuracion para el ruteo de llamadas en Asterisk
Como se explico en el capítulo 1 es necesario contar con un MSC
que dirija el establecimiento de llamadas y soporte la conexión y el direccionamiento hacia la PSTN en caso de que se quiera salir fuera de la red celular. El servicio de ASterisk también consulta la base de datos SQL para obtener información de los terminales en la red, su MSISDN e informa y controla la tarifación en las llamadas.
La configuración de Asterisk respecto a la integración con OpenBTS se resuelve con la configuracion de extensiones. Los datos en tiem-po real de los usuarios conectados y sus msisdn asignados se tomas de la base de datos. La base de datos es sqlite320 . Podemos ver la
configuración con las consultas pertinentes
[phones](HangupCause) ;define un contexto
exten => _[*#+0-9]!, 1,Set(CDR(B-IMSI)=\${ODBC_SQL(select dial from dialdata_table where exten=\"\${CDR(B-Number)}\")})
same => n,GotoIf(\${EXISTS(\${CDR(B-IMSI)})}?B-IPAddr) ;el
numero es conocido
same => n,GoSub(to-e164,\${CDR(B-Number)},1) ;pasarlo a e164
y volver a probar
same => n,Set(CDR(B-Number)=\${GOSUB_RETVAL}) ;update
B-Number
2.6 configuración del servidor e inicialización xliii
same => n,Set(CDR(B-IMSI)=\${ODBC_SQL(select dial from dialdata_
table where exten=\"\${CDR(B-Number)}\")})
same => n,GotoIf(\$["\${CDR(B-IMSI)}"=""]?to-pstn,\${CDR(B-Number
)},1) ;No es un numero en la celda, envia el
pedido a la PSTN
same => n(B-IPAddr),Set(CDR(B-IPAddr)=\${ODBC_SQL(select ipaddr
from sip_buddies where username=\"\${CDR(B-IMSI)}\")})
same => n,ExecIf(\$["\${CDR(B-IPAddr)}"=""]?Set(CDR(B-IPAddr)
="127.0.0.1")) ;setea el puerto
same => n,Set(CDR(B-Port)=\${ODBC_SQL(select port from sip_
buddies where username=\"\${CDR(B-IMSI)}\")})
same => n,ExecIf(\$["\${CDR(B-Port)}"=""]?Set(CDR(B-Port)=5062))
;setea el puerto
same => n,GoSub(to-openBTS,\${CDR(B-Number)},1(\${CDR(B-IMSI)
},\${CDR(B-IPAddr)},\${CDR(B-Port)}))
same => n,Goto(h-\${HANGUPCAUSE},1)
2.6.4 Salida de llamadas fuera de la red celular
Para la salida a la PSTN se debe configurar un Trunk SIP para deri-var las llamadas. En este caso podemos ver la configuración de un servicio accesible por internet.
[onsip]
type=peer
host=sip.onsip.com ; direccion del servidor
username=unsam ;usuario del trunk
fromuser=pablo ;usuario de salida en el trunk
fromdomain=unsam.onsip.com ;dominio del origen
secret=password
dtmfmode=rfc2833 ;modo de dtmf
context=incoming-context
insecure=invite
Para ello se debe llevar a cabo una registración, que se configura dependiendo del trunk. En este caso el pedido es el siguiente
register => pablo@unsam.onsip.com:password:unsam@sip.onsip.com
Para las comunicaciones hay dos datos necesarios, el From y la cabe-cera del Invite21 para inicializar un pedido.
exten => _X.,n,Set(CALLERID(name)=15135555555) ;from
exten => _X.,n,Dial(SIP/000\${EXTEN}@onsip) ;cabecera del invite
Para probar que el registro sea exitoso podemos hacerlo desde el asterisk CLI22, que se ejecuta con asterisk -r y corriendo el comando como se ve en la figura23
Figura23: Registro de SIP exitoso
Vemos que la registración es exitosa, luego podemos tratar de estable-cer llamadas y podemos ver los registros CDR23
"","IMSI722010003412733","i","to-pstn","IMSI722010003412733","SIP /00101100010-00000010","SIP/onsip-00000011","","","2017-08-01 22:53:32","2017-08-01 22:53:33","2017-08-01 22:54:14","42","41","ANSWERED","DOCUMENTATION ","1501638812.16","","A","","","1511111111","*98","IMSI 722010003412733",""
Donde se ve que se ruteo al contexto “to-pstn” desde el msisdn que se registro 151111111al numero *98 que es un sistema de voicemail
externo.
2.7 configuracion de red ip para gprs
GPRS es un servicio de datos (2.5G) que soporta teóricamente hasta 30kb/s con el esquema adecuado y los recursos asignados necesarios.
Para la configuración de GPRS primero es necesario activar el seg-mento que va a levantar el GGSN y el SGSN simulados dentro de openbts.
21 RFC3261SIP:https://tools.ietf.org/html/rfc3261
22 Asterisk CLI:https://www.voip-info.org/wiki-Asterisk+CLI
2.7 configuracion de red ip para gprs xlv
OpenBTS> config GPRS.Enable 1
Luego vamos a elegir un rango de Ips para asignar a los termina-les, esta red va a ser enmascarada (nateo, que es el enmascaramiento de redes privadas hacia las redes publicas por una direccion de la misma) con IPTables, y al ser una nueva interfaz que se va a crear ne-cesitamos que sea un rango de IP distinto para no generar problemas en el ruteo interno. Par ejemplo una red de 254terminales (clase A
subneteada, pero para ruteo en LAN24)10.10.10.0/24 OpenBTS> config GGSN.MS.IP.Base 10.10.10.1
OpenBTS> Config GGSN.MS.IP.MaxCount 254
También especificamos un DNS externo publico como el de google por ejemplo con
OpenBTS> config GGSN.DNS 8.8.8.8
El ruteo es manejado por iptables. Como se puede ver en la figura24
se ponen la table filter en aceptar todo y luego en la tabla nat sobre la política de POSTROUTING se agrega un filtro MASQUERADE pa-ra que tome todo lo que entre a dicha regla y haga un NAT por la interfaz seleccionada. (ver anexo5.2)
Como se ve en la figura 24, IPtables cuenta con muchas tablas
dife-rentes que procesan el paquete IP recibido o a enviar. Se divide en grandes razgos como PREROUTING (antes de ser ruteada o direccio-nada), INPUT (aquellos paquetes entrantes y el tratamiento que se le da), FORWARD (aquellos paquetes que deben ser redireccionados a otro lado, OUTPUT (para paquetes que saldrán del equipo hacia el exterior y fueron generados dentro del mismo) y POSTROUTING ( para todas aquellas reglas a aplicar antes de la salida por la interfaz de red).
Para el manejo de aquellos celulares con proxy se armo un script (ver anexo 5.1) para generar una interfaz “dummy” con la ip del proxy
que se consulta por el celular. Esto se puede ver haciendo un tcpdump del tráfico por la interfaz o activando el logging de GPRS a debug. Luego se configura el tinyproxy para escuchar por todas las interfaces y rutear el tráfico por la salida a internet (ver anexo5.2)
Figura24: Esquema de ruteo de IPTables
2.8 configuración de los terminales
La configuración de los terminales (MS) es bastante simple. Aquellos terminales que tengan una SIM de un operador comercial pueden conectarse a la red, pero por la configuración de la SIM y su red de operación nativa, la red de OpenBTS figurara como Roaming. Con solo buscar la red el terminal debería listar la misma como se ve en la figura 25. Depende de como tenga la configuración en la SIM puede
ser que los nombres que muestra varien, en este caso muestra el MCC y MNC juntos como identificador ya que en su lista no existe dicha combinacion.
2.8 configuración de los terminales xlvii
La primera interacción del terminal con la red ejecuta un LUR25 (lo-cation update request) cuando seleccionamos la red en la pantalla como se ve en la figura 26. En ese momento en la estación base esa
petición es interpretada y se envía al SIPAuthServe para ser tratada. El SIPAuthServe busca en su base de datos si existe la información del IMSI que solicita la registración, si no existe rechazara la regis-tración, pero va a quedar registrado en una tabla de intercambios de información que se denomina TMSI26 (formalmente Temporary mobile subscriber identification aunque no se le asigne uno en este momento.), como se ve en la figura27. Esta tabla indica en la columna
Auth si existe o no en la base de datos.
Figura26: Registración con una SIM comercial
Otra opción es que la red sea de registración abierta, sin un previo chequeo. Esto es configurable en el SIPAuthServe y podemos utilizar RegEx para filtrar por ejemplo por SIM de cierto operador, o de cierto país, etc..
25 Location Update Request: http://www.eventhelix.com/RealtimeMantra/Telecom/ GSM_Location_Update_Sequence_Diagram.pdf
Figura27: Lista de TMSIs
2.8.1 Creacion de suscriptores en SIPAuthServe
Para registrar un numero en el SIPAuthServe podemos escribir en la base de datos o podemos utilizar una herramienta que proporciona openBTS para cargar los datos. Cada terminal que se conecte a la red debe tener asignado un MSISDN (Mobile Station Integrated Services Digital Network) por lo tanto es un dato que tenemos que generar. La herramienta es nmcli, escrita en python que interacciona con el servicio zeroMQ para ejecutar comandos contra el sistema pot TCP. La ejecución para agregar un nuevo subscriptor es la siguiente
./nmcli.py SIPAuthServe subscribers create name imsi msisdn ki
El imsi lo podemos obtener de la tabla y se puede verificar en los ter-minales ingresando el código *#06# para verificar que se el terminal
que queremos agregar. El ki es opcional, las comunicaciones no esta-rán cifradas sin el, en las SIM que sean de un proveedor comercial no podemos averiguar este codigo, por lo tanto lo dejaremos vacío.
Una vez que se ingresa el suscriptor, podemos reintentar la registra-ción y vemos como en la figura 28 que el mismo se puede registrar
correctamente. Podemos ver tambien la registración exitosa desde el log de openbts.
2.8.2 Registracion contra el SGSN
Una vez registrado comenzará a enviar peticion de registración con-tra el SGSN para la conexión de datos con su TMSI y otros datos adicionales. Para esto el terminal necesita tener configurado un APN, por más que no tenga valores reales, sin un APN configurado el soft-ware del terminal no intenta ninguna registración contra un SGSN.
En los terminales más modernos la registración de datos puede tardar varios minutos, ya que la tecnología2G es muy lenta para una
2.8 configuración de los terminales xlix
Figura28: Registración correcta con una SIM de operador comercial
otras combinaciones contra la estación base antes de terminar en una conexión GPRS27.
Podemos observar en la figura 29 un terminal registrado y en línea
contra el sgsn
Figura29: lista de usuarios activos de SGSN
Parte III
3
M E D I C I O N E S Y O P T I M I Z A C I Ó N
3.1 mediciones con hackrf y gnuradio
Las mediciones se realizaron con una placa SDR HackRF, la cual cons-ta de una antena de similares características a las utilizadas con la pla-ca USRP B210. En primera instancia se utilizó el software GQRX para
verificar la correcta transmisión de la señal en la Banda de Upload y Download. Siendo el ARFCN 51 las bandas como vemos en la tabla 4 nos centramos cerca de la frecuencia a monitorear y podemos ver
como en la figura30se observa el espectro de la misma.
Figura30: Espectro de Downlink
También podemos ver como solo en momentos de recepción de da-tos transmitidos desde un terminal vemos que hay un espectro en la banda de 900.2 Mhz. En la figura 31 se puede observar en el grafico
de cascada los momentos de no transmisicion.
Cuadro4: Tabla de Frecuencias para ARFCN51
Banda ARFCN Downlik (Mhz) Uplink (Mhz)