• No se han encontrado resultados

Implementación de red celular GSM con hardware SDR.

N/A
N/A
Protected

Academic year: 2020

Share "Implementación de red celular GSM con hardware SDR."

Copied!
87
0
0

Texto completo

(1)

pablo e. bullian

(2)
(3)

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

(4)

tutor:

(5)

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/.

(6)
(7)

Í 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

(8)

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

(9)

Í 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

(10)

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

(11)

Parte I

(12)
(13)

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

(14)

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.

(15)

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

(16)

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.

(17)

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:ZZ

Esto ocurre en una etapa llamada conversión analógica-digital(A/D).

(18)

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.

(19)

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

(20)

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

(21)

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.

(22)

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

(23)

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.

(24)

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

(25)

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.

(26)

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

(27)

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

(28)

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.

(29)

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

(30)

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

(31)

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

(32)
(33)

Parte II

(34)
(35)

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.

(36)

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

(37)

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.

(38)

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

(39)

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.

(40)

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

(41)

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

(42)

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.

(43)

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

(44)

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

(45)

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...

(46)

-- 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

(47)

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

(48)

| | | | 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

(49)

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

(50)

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.

(51)

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.

(52)

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

(53)

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

(54)

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

(55)

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)

(56)

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.

(57)

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

(58)

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

(59)

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

(60)
(61)

Parte III

(62)
(63)

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)

Referencias

Documento similar

La Intervención General de la Administración del Estado, a través de la Oficina Nacional de Auditoría, en uso de las competencias que le atribuye el artículo

La campaña ha consistido en la revisión del etiquetado e instrucciones de uso de todos los ter- mómetros digitales comunicados, así como de la documentación técnica adicional de

You may wish to take a note of your Organisation ID, which, in addition to the organisation name, can be used to search for an organisation you will need to affiliate with when you

Where possible, the EU IG and more specifically the data fields and associated business rules present in Chapter 2 –Data elements for the electronic submission of information

The 'On-boarding of users to Substance, Product, Organisation and Referentials (SPOR) data services' document must be considered the reference guidance, as this document includes the

In medicinal products containing more than one manufactured item (e.g., contraceptive having different strengths and fixed dose combination as part of the same medicinal

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in