Descargar

4. Aspectos de implementación.
Como se ha expuesto, aunque el método propuesto es susceptible de ser
implementado en multitud de sistemas de comunicaciones inalámbricos celulares, en
este trabajo se ha centrado la atención en la implementación en GSM/GPRS para
mostrar el rendimiento del sistema. Como se expondrá en los siguientes apartados, los
detalles de implementación condicionan el rendimiento del método considerablemente.
4.1 Terminal móvil.
Para llevar a cabo esta funcionalidad tenemos varias posibilidades en lo que a la
implementación se refiere. Así, en este proyecto se contemplaron dos posibles
implementaciones: en un terminal móvil y en un módem GSM/GPRS. Finalmente se
validó la implementación únicamente en módem GSM/GPRS debido al difícil acceso a
herramientas de diseño y desarrollo adecuadas para el terminal móvil elegido. De todas
maneras, ambas alternativas se describen a continuación.
4.1.1 Terminal móvil convencional.
En un primer momento se pensó en desarrollar una aplicación para un terminal
móvil convencional. Así, se programó una aplicación, en lenguaje Symbian C++, en un
terminal móvil con Sistema Operativo Symbian [29] e interfaz de usuario S60. Para ello
se utilizó el kit de desarrollo de software (SDK) de la serie S60 de Nokia. Este SDK
permite acceder a muchas de las funcionalidades de este tipo de teléfonos móviles,
como por ejemplo, la monitorización de la intensidad de señal recibida en el teléfono y
el control de llamadas de voz. Además, para facilitar la edición del programa se ha
utilizado el entorno de desarrollo Carbide v.2 C++.
Dado que, en cuanto a la monitorización de la señal recibida, en el terminal
utilizado teníamos acceso únicamente al nivel de señal, el programa diseñado consiste
en una aplicación que monitoriza la intensidad de la señal recibida en el teléfono de la
portadora piloto de la celda en la que se encuentra “acampado” el móvil. Cuando la
aplicación detecta que no es posible obtener la intensidad de la señal (no es posible
decodificar los canales comunes en el enlace descendente) se realiza una petición de
canal (llamada de voz o de emergencia), aunque, como sabemos, esta llamada no se
podrá terminar por la presencia del inhibidor, que impide la comunicación en el enlace
descendente. Este simple esquema de funcionamiento se ilustra en la Figura 13.
27
Medida de la fuerza de la
señal recibida de la
portadora de señalización
en el terminal (DL)
¿Se obtiene un
valor lógico?
SI
NO
Envío de mensaje de
petición de canal sobre el
canal RACH (UL)
Figura 13: Diagrama de funcionamiento de la aplicación
De las posibles causas que se pueden utilizar en la petición de canal, y tras las
pruebas realizadas, se utilizaron dos de ellas para validar el rendimiento del sistema. Por
un lado, la causa etiquetada con el número 5 en la Tabla 2, que se corresponde con
llamadas de voz convencionales, y por otro, la etiquetada con el número 12, que se
corresponde con llamadas al número de emergencia. La ventaja de la utilización de esta
última radica en la baja probabilidad de uso de la misma. Aunque como desventaja,
podríamos citar, según la información proporcionada por técnicos de Vodafone, que
este tipo de llamadas, dependiendo del tráfico en el interfaz radio, podría originar caídas
de llamadas en curso en un momento determinado. En este sentido, habría que llegar a
una solución de compromiso, debiendo validar el sistema en diferentes situaciones.
Sin embargo, tal y como se describe en el apartado de resultados, el problema
que se encontró con la implementación de esta aplicación en un terminal móvil
convencional radica en que en la práctica, el tiempo necesario para la detección de un
inhibidor, con las herramientas empleadas, era tan elevado que el terminal móvil perdía
la sincronización con la red rápidamente tras la detección de interferencia y por lo tanto
no era capaz de transmitir la petición de canal. Es decir, el tiempo de refresco de las
lecturas del nivel de la señal recibida no era lo suficientemente reducido. Esto se puede
achacar a que estas acciones se llevan a cabo mediante APIs que requieren de otras
funciones que tengan acceso a parámetros de nivel físico y necesitan un tiempo de
ejecución determinado. Durante la validación práctica se utilizaron APIs públicas por la
facilidad en la adquisición de las mismas.
Otro problema adicional encontrado es que las APIs utilizadas no contemplan la
utilización de números de emergencia. Para ello se requieren de APIs específicas,
generalmente suministradas por el fabricante del terminal, o incluso por los operadores.
4.1.2 Módem GSM/GPRS.
Dada la problemática existente en la solución anterior, se optó por implementar
la funcionalidad del terminal en un dispositivo diferente, tal como un módem
GSM/GPRS. En particular, se ha adquirido el módem GT864-PY [31] de la compañía
28
Telit [30], capaz de, por un lado, ser programado con mayor facilidad que un terminal
móvil convencional para reducir el tiempo de desarrollo de la aplicación, y por otro,
detectar la posible situación de inhibición de forma más rápida. En la Figura 14 se
muestra este dispositivo.
Figura 14: Módem GSM/GPRS utilizado. GT864-PY
Este dispositivo ofrece las mismas funcionalidades que un terminal GSM/GPRS
convencional y está pensado para implementar aplicaciones M2M (Machine to
Machine). Además, se controla mediante comandos AT y permite la ejecución de
aplicaciones desarrolladas en lenguaje Python. Para esto último Telit facilita un entorno
de desarrollo para facilitar la edición de Scripts en Python: PythonWin. En [31] se puede
encontrar toda la información necesaria para el desarrollo de Scripts en Python.
En este caso, tenemos acceso a mayor número de parámetros para la
monitorización de la señal recibida, tales como RxLevel, RxQual, BER, RSSI y power.
Sin embargo, el desarrollo final de la aplicación vino condicionada por la
implementación final del fabricante ya que el tiempo de refresco de los parámetros
RxLevel, RxQual, y BER era excesivo. Afortunadamente, el tiempo de refresco de los
parámetros RSSI y power (ambos son equivalentes) era lo suficientemente reducido
utilizando comandos AT propietarios de Telit. Por tanto la implementación final es
similar a la desarrollada para el terminal móvil convencional, expuesta en el apartado
anterior, con la diferencia de que en este caso se monitorizan las variaciones bruscas en
el nivel de señal de la portadora baliza del DL. En concreto se ha fijado un valor de 8
dB en este proyecto. En la Figura 15 se muestra el diagrama de flujo de la aplicación
implementada.
Figura 15: Aplicación añadida al terminal.
Tras las pruebas realizadas durante la validación de esta aplicación, nos
percatamos de un aspecto importante: el rango de valores que debe obtener la función
(comando AT) que monitoriza el nivel de la señal recibida tiene que ser lo
29
suficientemente amplio como para detectar un cambio de nivel ante cualquier nivel de la
señal recibida. Es decir, si la función que realiza la lectura del nivel de señal tiene un
valor de salida predeterminado indicando que la señal recibida tiene ese nivel o
superior, no podríamos detectar la presencia del inhibidor si el nivel de señal es lo
suficientemente alto. Esta situación se ha dado durante la validación del sistema y se ha
solventado introduciendo un atenuador en el conector coaxial de la antena del terminal.
Por lo tanto, es conveniente caracterizar el rango de medida del parámetro
monitorizado.
4.2 Dispositivo de seguimiento.
Como se ha expuesto, dentro del sistema se propone la implementación
mediante una plataforma SDR2 de un escáner de frecuencia para monitorizar el canal de
control común en el sentido descendente y encontrar continuas repeticiones de
respuestas a peticiones de establecimiento de canal, con la misma causa de
establecimiento, que el terminal inhibido nunca recibirá. Si este comportamiento en el
tráfico de señalización es detectado, se iniciará un proceso de polling o control de
estado en los terminales que están siendo protegidos frente a inhibidores en la celda. Por
lo tanto, se podrán proteger varios dispositivos frente a inhibidores de forma simultánea
con un único dispositivo de este tipo instalado estratégicamente junto a una estación
base.
Este proceso de interrogación de terminales para comprobar su estado quedó
fuera de la implementación del sistema piloto final por simplicidad.
El concepto fundamental detrás de la tecnología SDR es acercar el
procesamiento software tanto como sea posible a la antena. Es decir, el diseño de
sistemas de radiocomunicaciones definidos por software se basa en la utilización de
dispositivos que convierten las ondas de radio a la entrada de la antena en señales
digitales procesables en una computadora de forma transparente desde el punto de vista
del software.
Una posible implementación de la tecnología SDR se podría llevar a cabo
utilizando el software GNU Radio [23] junto con el dispositivo hardware USRP
(Universal Software Radio Peripheral) desarrollado por la compañía Ettus Research
LLC [24]. El USRP se utiliza para digitalizar las señales analógicas recibidas en las
frecuencias de radio para que puedan ser procesadas en un ordenador de propósito
general. De este modo, podríamos implementar en el ordenador un receptor o un
transmisor radio definido por software utilizando las herramientas que proporciona
GNU Radio. Esto genera gran flexibilidad en cuanto a la creación de casi cualquier tipo
de receptor o transmisor en software. Sin embargo existen limitaciones, por ejemplo
relacionadas con la velocidad de muestreo de la señal analógica recibida. En la Figura
16 se ilustra el procesado básico de la señal llevado a cabo en el USRP y GNU Radio.
2
Decir que se investigó el uso de otros sistemas comerciales y se terminó descartándolos, pues ninguno
de ellos permite monitorizar de forma continua la señalización común descendente. Al menos ninguno de
los equipos que, con un precio reducido, se revisaron.
30
Figura 16: Esquema de funcionamiento del USRP y GNU Radio.
Una ventaja adicional referente al empleo específico de estos elementos, radica
en que además de que GNU Radio y el USRP están basados en software y hardware
libre respectivamente, el esquemático del USRP está disponible públicamente. Esto
hace que las posibilidades en cuanto a soporte y desarrollo del sistema sean elevadas.
En la Figura 17 se muestra externamente el USRP.
Figura 17: USRP.
A continuación se describirán las herramientas utilizadas, tanto hardware como
software, por la plataforma SDR: El USRP y GNU Radio.
4.2.1 USRP.
El USRP se emplea para realizar la conexión entre el dominio de RF (Radio
Frequency) y la computadora (Figura 16). Este dispositivo toma a su entrada las señales
de radio provenientes de la antena, las digitaliza a una frecuencia intermedia conocida y
por último, transmite por el puerto USB estas señales en banda base. Como se observa,
es deseable que el USRP realice el mínimo procesamiento para que el sistema sea lo
más independiente del hardware como sea posible. Así, pese a poder programar, en la
FPGA que incorpora este dispositivo, ciertas funciones de procesamiento de señal, es
preferible que el USRP únicamente digitalice las señales que recibe para que éstas
puedan ser procesadas en una computadora donde todos los cálculos puedan ser
realizados en software.
Para entender el funcionamiento del USRP con mayor profundidad, se
describirán a continuación con cierto detalle los componentes que lo constituyen así
como sus respectivas funciones. En una primera clasificación, el dispositivo consta de
dos elementos principales: la placa principal, también conocida como placa base o
motherboard, y las placas auxiliares que hacen de interfaz con la antena, más conocidas
como daugtherboards. La elección de estas últimas dependerá del rango de frecuencias
en RF que estemos interesados en procesar. En la Tabla 3 se enumeran todas las placas
existentes. Por lo tanto, el USRP se compone de los siguientes elementos:
31

•
Controlador USB
•
ADC (Analog to Digital Coverter)
•
DAC (Digital to Analog Concerter)
•
PGA (Programmable Gain Amplifier)
•
Daugtherboards
•
FPGA (Field Programmable Gate Array)
Controlador USB 2.0.
El USRP se conecta con el ordenador a través del puerto USB. En particular,
utiliza la versión 2.0, llevando a cabo un rendimiento muy pobre con la versión 1.1.
Esto permite disponer a la salida una tasa de datos de 32 MB/s. Así, se puede apreciar
que esta conexión tiene un impacto serio en el rendimiento del sistema, pudiendo no ser
suficiente con esta tasa para los requerimientos específicos del mismo.

ADC (Analog to Digital Converter).
El convertidor analógico a digital tiene la función de digitalizar las señales
analógicas a su entrada. En concreto, el USRP consta de cuatro convertidores analógico
a digitales que operan a 64x106 muestras por segundo con una precisión de 12 bits, por
lo que en principio éste podría digitalizar señales de hasta 32 MHz de ancho de banda.
Por lo tanto, este elemento también impone una restricción al sistema ya que no es
posible procesar señales de mayor ancho de banda.

DAC (Digital to Analog Converter).
El convertidor digital a analógico convierte las señales digitales a su entrada en
analógicas. En particular, en USRP está dotado de cuatro convertidores que operan a
128x106 muestras por segundo con una precisión de 14 bits. En el USRP, se emplean en
el trayecto de transmisión para la emisión de señales definidas por software, por lo que
no se contempla su empleo en este proyecto.

PGA (Programmable Gain Amplifier).
En el trayecto de recepción, el amplificador de ganancia programable amplifica
la señal recibida, en caso de que ésta sea débil, antes de ser procesada por el convertidor
analógico a digital para aprovechar el rango dinámico del mismo. La ganancia de este
amplificador es configurable por software con valores que oscilan desde los 0 dB hasta
los 20 dB.

Daughterboards.
Para que el USRP pueda trabajar en diferentes bandas del espectro de
radiofrecuencia se debe dotar al mismo de alguna placa específica para la banda de
interés. Estas placas se conocen con el nombre de “daughterboards” por la existencia de
una placa base en la que se encuentran el resto de componentes del USRP que
proporciona cuatro slots donde es posible conectar hasta dos placas receptoras y dos
transmisoras, o bien únicamente dos placas transceptoras (RFX). Como se aprecia, estas
placas se utilizan como interfaces receptoras RF (escáner de frecuencia), o bien como
transmisoras. Además cada placa tiene acceso a dos de los cuatro ADC/DAC
32
(transmitiendo datos al ADC y recibiendo datos del DAC). Por lo tanto, concluimos que
es posible conectar múltiples placas a la placa base, permitiendo la transmisión y
recepción simultánea en el USRP.
En la Tabla 3 se enumeran las placas existentes en la actualidad.
Nombre
Basic RX / Basic TX
LFRX / LFRX
DBSRX
TVRX
RFX400
RFX900
RFX1200
RFX1800
RFX2400
Operación
Receptor / Trasmisor
Receptor / Trasmisor
Receptor
Receptor
Receptor y transmisor
Receptor y transmisor
Receptor y transmisor
Receptor y transmisor
Receptor y transmisor
Banda (Mhz)
1-250
0-30
800-2400
50-860
400-500
800-1000
1150-1450
1500-2100
2300-2900
Potencia máxima (mW)
100
100
200
200
100
10
Tabla 3: Placas disponibles para la placa base del USRP

FPGA (Field Programmable Gate Array).
La FPGA juega un papel muy importante en el USRP y es considerada el
corazón del mismo. Está conectada a todos los convertidores ADCs y DACs.
Básicamente, su función es llevar a cabo las operaciones de alta frecuencia y reducir la
tasa de datos para que el flujo de bits resultante se pueda transmitir por el puerto USB
2.0. Así, la FPGA está conectada al controlador del puerto USB, el Cypress FX2.
Ambos, el controlador USB y la FPGA son programables a través del bus USB.
Por configuración, la operación a alta frecuencia que realiza la FPGA es
conocida como DDC (Digital Down Converting). Su función es la conversión a banda
base de la frecuencia IF (Intermediate Frequency) presente a la salida del ADC. A partir
de esta operación, la señal es diezmada para que la tasa de datos se adapte a la velocidad
de transmisión USB y sea razonable para su posterior procesamiento en el ordenador.
4.2.2 GNU Radio.
GNU Radio es un conjunto de herramientas software de código abierto que
facilita el desarrollo de sistemas de radiocomunicaciones definidos por software. Para
desempeñar esta función, hace uso de diversos lenguajes de programación, cada uno con
objetivos diferentes. GNU Radio también incluye gran variedad de librerías de bloques
de procesamiento de señal como moduladores, demoduladores, filtros, etc. que se
pueden utilizar en el sistema de radiocomunicaciones que se esté diseñando.
Aunque en el principio de operación de GNU Radio está implícito la utilización
del USRP, éste no es necesario si no hay necesidad de un procesamiento en tiempo real,
ya que es posible trabajar con capturas de ficheros realizadas con este mismo
dispositivo.
El software de GNU Radio está organizado en una estructura de dos niveles.
Todos los bloques de procesamiento de señal están implementados en C++, mientras
que la organización de alto nivel, que conecta los bloques de procesamiento de señal
entre sí, se implementa en Python. El objetivo es implementar el sistema de
comunicaciones en una aplicación en Python que maneje y planifique los bloques de
procesamiento creados en C++, dejando toda la carga computacional presente en los
33
mismos en un segundo nivel. Adicionalmente, hay disponible un entorno gráfico para
facilitar el diseño del sistema de radiocomunicación, el GNU Radio Companion (GRC)
[13].
4.2.3 Implementación del algoritmo de detección.
Una vez que se han expuesto de forma general las herramientas disponibles, a
continuación enumeramos las que finalmente se han empleado:
•
Dispositivo USRP con placa receptora DBSRX (800-2400 MHz) [24],
válida para la recepción de cualquier banda de los sistemas GSM/GPRS y
UMTS. Además es necesario el empleo de una antena adecuada. Para ello
se ha empleado la antena SMA703 de la compañía COMET [25].
•
PC de propósito general con la distribución Ubuntu del Sistema Operativo
Linux.
•
Paquete de software GNU Radio.
•
Software de código abierto disponible en el proyecto Airprobe [27] para el
análisis del interfaz radio del sistema GSM.
A continuación se describirá el software empleado en el ordenador para la
detección de la situación de inhibición del terminal.
En primer lugar, hemos de tener perfectamente configurado el software GNU
Radio en el ordenador. GNU Radio se puede instalar sobre diversidad de sistemas
operativos, entre los que destacan Linux, MAC OS X y Windows. Entre ellos se ha
optado por la utilización de la distribución Ubuntu 8.04 del sistema operativo Linux por
su amplia difusión y fácil manejo. Las instrucciones para la correcta instalación de GNU
Radio en el sistema operativo Linux Ubuntu se pueden consultar en [26].
Una vez instalado GNU Radio hay que descargar e instalar el software de código
abierto disponible en el proyecto Airprobe [27]. Para ello se pueden seguir las pautas
que se indican en [28].
Con todo ello, únicamente resta modificar este último componente software para
que implemente nuestro algoritmo de detección. Es decir, se añadirá el código de
programación necesario para que el dispositivo de seguimiento detecte de forma
efectiva la posible situación de inhibición del terminal.
El algoritmo implementado es el expuesto en la Figura 16 donde el parámetro To'
se fijó a un valor lo suficientemente alto para no depender del tráfico presente en una
celda en un momento dado, mientras que el parámetro Nmax (Max_retrans) se fijó al
valor difundido por la estación base en la que se validó el sistema piloto, que en este
caso toma el valor de 4.
En la Figura 18 se muestran todos los elementos implicados. De izquierda a
derecha: terminal módem GSM/GPRS, USRP y PC con el software GNU Radio e
inhibidor de frecuencia en las bandas GSM900/GSM1800/UMTS.
34
Figura 18: Elementos utilizados para la validación del sistema.
35