RDS Aplicado A Teconología GSM, UMTS y LTE

Universidad Tecnológica Nacional
Facultad Regional Córdoba

Departamento de Ingeniería Electrónica
Implementación de los estándares de

comunicación GPRS, UMTS y LTE con
Radio Denida por Software (RDS)
Práctica Profesional Supervisada (PPS)
GUTIERREZ, Diego A.
Córdoba Argentina
12/12/2018
1
PPS - Implementación de los estándares de comunicación GPRS, UMTS y LTE con RDS 2
Contents
1 Introducción 5
2 Desarrollo 7
2.1 Descripción del Hardware, Ettus B200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 OpenBTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 OpenBTS-UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3 OpenLTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Ensayos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 Conguración del eNodeB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.2 Conguración y análisis de espectro de la Banda 1 . . . . . . . . . . . . . . . . . . . . . . 18
2.3.3 Relación Ancho de Banda - procesamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Dicultades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.1 IP no asignada a la red GPRS en OpenBTS . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.2 Red PLMN−00101 no visible en OpenLTE . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3 Conclusión 29
Acrónimos
• GSM: Global System for Mobile Communications.
• GPRS: General Packet Radio Service.
• UMTS: Universal Mobile
• LTE: 3GPP Long Term Evolution.
• USPR: Universal Software Radio Peripheral.
• UHD: USPR Hard Driver.
• SIM: Subscriber Identity Module.
• USIM: Universal SIM.
• MCC: Mobile Country Code.
• MNC: Mobile Network Code.
• AUC: Authentication Center.
• UE: User Equipment.
• EARFCN: E-UTRA Absolute Radio Frequency Channel Number.

Resumen
En el grupo de trabajo GinTEA (Grupo de Investigación de Transferencia y Electrónica Avanzada) se desarrolla
un proyecto donde se implementan estaciones base de telefonía móvil mediante técnicas SDR. Al momento de
iniciar la PPS, se contaba con información sobre las implementaciones disponibles tanto para 2G, 2.5G, 3G y
4G, y alguna experiencia inicial en la implementación de 2G. Sobre esta base, el trabajo de PPS consiste en
explorar estas implementaciones, realizar las tareas de instalación, conguración y testeo mediante un caso real
de conexión con un terminal de usuario. Asimismo, se realizaron tareas para contar con tarjetas SIM propias
que posibiliten estos ensayos. Este trabajo permitirá evaluar la mejor opción para adoptar en el proyecto de
I+D vigente en el Grupo.
1 Introducción
Es indudable que nos encontramos en el apogeo de las telecomunicaciones digitales, ya que si bien es una tec-
nología que lleva estudiandose hace mucho más de un siglo es recién hasta nes de la década de los 70's que
toma gran relevancia. A nuestros días es notable el avance exponencial en las diversas ramas que componen a la
telecomunicación digital, ya sea video streaming, television Full HD, videollamadas, cibernética y podrían seguir
citandose incontables ejemplos. Todos ellos fueron posible gracias al avance en las investigaciones, desarrollo y
perfeccionamiento de las diversas técnicas de modulación.
Por otro lado, la tecnología SDR (Software Dened Radio) es un sistema de radiocomunicaciones
donde varios de los componentes típicamente implementados en hardware como ser mezcladores, ltros, modu-
ladores/demoduladores, detectores, etc; son implementados en software, utilizando una computadora personal
o algún otro sistema embebido. Más especícamente, un SDR está conformado por
• Conversor A/D.
• Adaptador de Radiofrecuencia RF.
• Procesadores de propósito general o FPGA para el procesamiento de señales.
• Software que permita congurar los diversos protocolos de comunicación.
Para éste último item existen diversas alternativas pagas como simulink de Mathworks y de código abierto,
como el que se usará aquí GNURadio.
La técnica SDR tiene muchísimo potencial, sus principales campos de aplicación hablan de ello, estas son la
telefonía celular y el uso militar, pues en ambos casos se manejan varios protocolos en tiempo real, que cambian
casi constantemente según se necesite. En este trabajo nos centraremos indudablemente en el primer campo,
estudiando y analisando los distintos estándares de comunicación con correspondientes protocolos en orden de
su evolución, esto es desde GMS (2G), GPRS (2.5G), UMTS (3G) y LTE (4G).
Todos estándares de aplicación estudiados aquí están basados en proyectos de código abierto sobre una placa
de desarrollo Ettus B200. La computadora de control encargada de la conguración de los distintos protocolos
es la PC de GinTEA (Grupo de Investigación de Transferencia y Electrónica Avanzada) situada en la sede
institucional UTN-FRC. La misma opera bajo el Sistema Operativo GNU Linux Ubuntu Xenial 16.04.2 LTS,
cuenta además con un procesador intel Core−i7 y 16GB de memoria Ram.
2 Desarrollo
2.1 Descripción del Hardware, Ettus B200
La plataforma de hardware usada para llevar a cabo los ensayos es la USPR-B200
1 de la rma Ettus Research,
la misma se muestra en la g.1.
Figure 1: USPR B200, Ettus Reseach.
Las principales características de la placa son:
• FPGA Xilinx Spartan 6 XC6SLX75.
• Transreceptor de conversión directa, Analog Devices AD9364 RFIC.
• Rango de Frecuencia: 70 MHz - 6 GHz
• Hasta 56 MHz de Ancho de Banda en tiempo real.
• Full duplex, SISO (1 Tx y 1 Rx).
• Conectividad USB 3.0.
Desde el lado del software, las principales aplicaciones que se pueden desarrollarse usando como esta celda
como plataforma madre, son:
• GNU Radio.
• MathWorks Simulink.
• OpenBTS (GSM y GPRS).
• OpenBTS UMTS (3GPP).
• OpenLTE.
Los datos provenientes de esta placa se adquieren mediante el driver UHD. Éste driver fué desarrollado en
Linux (Ubuntu o Fedora), aunque también tiene soporte para los Sistemas Operativos especícos como los de
Mac OS X y Windows 7. Todas los ensayos que se describen en éste texto usan la distribución de Ubuntu
16.04.2 LTS Xenial x64.
1 Vease https://www.ettus.com/product/details/UB200-KIT para más detalles acerca de la placa.

2.2 Implementación
Se describen brevemente los proyectos que implementan los diferentes estándares de telecomunicación móvil
mediante la aplicación de la técnica de SDR sobre la placa base de desarrollo.
2.2.1 OpenBTS
El proyecto OpenBTS
2 (Open Base Transceiver Station - Estación Base Transrecpetora Abierta) es un punto de
acceso a la red 2G (GSM - GPRS) basado en software (SDR), que permite a los teleféfonos móviles compatibles
con el estándar 2G realizar llamadas telefónicas y acceder a internet para la implementación de maquetas, redes
experimentales o instalaciones especiales en forma totalmente autónoma. Esto es porque OpenBTS reemplaza
la infraestructura tradicional del Subsistema de Conmutación de Red del operador de GSM, desde la estación
base del transreceptor (BTS) hacia arriba, es decir que en lugar de reenviar el tráco de la llamada a través del
Centro de Conmutación Móvil (MSC) del operador, las mismas son reenviadas como datos a través de la PBX
Asterisk mediante los protocolos Session Initiation Protocol (SIP) y Voz sobre IP (VoIP).
A continuación, la página ocial del proyecto y el repositorio en github.
http://openbts.org/
https://github.com/RangeNetworks/dev/wiki
Además se tiene a disposición el manual de referencia del proyecto, Getting Started with OpenBTS,
desarrollado por Michael Ledesma como material complementario de la compania Range Networks, Inc.3 ,
siendo éste el principal desarrollador del proyecto. Este manual contempla un amplio margen de temas, desde
la instación del proyecto en una estación terminal DTE, hasta la conguración de los protocolos de GSM y GPRS.
En la g.2 se presenta la arquitectura de la red 2G implementada por OpenBTS.
Figure 2: Arquitectura de la red 2G implementada por OpenBTS.
Si bien no se probó en la práctica, pero debido a su relevancia, se menciona a modo de referencia el proyecto
OsmoBTS, cuyo amplio ecosistema se encuentra en
https://osmocom.org/projects/osmobts/wiki/Wiki
2 Vease https://es.wikipedia.org/wiki/OpenBTS.
3 Range Network, Inc. es el una compania Norteamericana que desarrolla productos dedicados de Software de código abierto
para usarse en la red de telefonía celular.
2.2.2 OpenBTS-UMTS
A n de explorar implementaciones en el estándar 3G, se dedicó un breve tiempo para la instalación y testeo
básico del proyecto OpenBTS-UMTS sin éxito. Además debido a la límitación de la escasa información que
hay por parte de los principales desarrolladores, es que se decidió abordar la migración hacia 4G mediante el
proyecto OpenLTE, como se vera en el siguiente apartado.
2.2.3 OpenLTE
OpenLTE es una implementación de código abierto de las especicaciones 3GPP LTE. Como tal, existen difer-
entes empresas y desarrolladores que llevan a cabo su propia implementación del estándar LTE, como ser:
• Open Air Interface, (https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home).

• FairWaves, (https://fairwaves.co/).
• Sofware Radio System (https://github.com/srsLTE/srsLTE).
• Amarsoft, (https://www.amarisoft.com/).
• OpenLTE, desarrollado por Ben Wojtowicz, Dennis Senyonjo y equipo.
(a) E-Utran
(b) UE - EPC
Figure 3: Arquitectura 4G LTE.

Por lo general todos estos proyectos coinciden en integrar conjuntamente el eNodeB (Estación Base de Radio,
parte de la Evolved UMTS Terrestrial Radio Access Network o Amarisoft LTE) y el EPC (Evolved Packet Core),
por supuesto, además de todas las herramientas dedicadas para su gestión. En la g.3 se muestra la arquitectura
general de LTE.
De los proyectos listados arriba, se implementará OpenLTE en su versión 20.05, cuyo repositorio principal
se encuentra en:
https://sourceforge.net/projects/openlte/
Los requisitos mínimos que demanda el proyecto se listan a continuación.
• Interfaz USB3.0.
• Procesador Intel Core i5, Core i7 o equivalente con SSE4.1, SSE4.2 y soporte AVX.
• Drivers UHD (Ettus SDR B-200) en su última versión.
• GNURadio.
Algunos de los principales recursos que se brindan en esta versión son:
• Código de Octave para simular la funcionalidad de transimisión y recepeción del enlace de bajada (down-
link) y lo propio con el PRACH del enlace de subida (uplink).
• Aplicaciones de GNURadio para transmitir y recibir datos desde-hacia un archivo.
• Testeo de recepción en el enlace de bajada mediante USRP B2x0, HackRF o rtl-sdr.
• Implementación y testeo de EnodeB con USRP B2x0, HackRF o rtl-sdr.
• Escaneo de celdas operadores cercanas.
Se centrará completamente en el testeo del funcionamiento del eNodeB. Cabe mencionarse que al ser un
estándar bastante complejo en cuanto al volumen de mensajes de comunicación y vericación, su proceso de
análisis y estudio es muy lento y es por eso que sólo se estudiará en detalle el enlace de bajada.
En primer lugar, para testear la interface con el eNodeB se necesita un terminal móvil, que para ésta versión
del proyecto requiere ser física, es decir que no se puede simular un teléfono móvil. De todas maneras para esta
situación es preciso tener en cuenta las diversas alternativas viables, las mismas se listan a continuación.
• Módulos de comunicación QUECTEL, TELIT. Si bien estos chips soportan el estándar GSM-GPRS y
3GPP, no así para LTE. Sin embargo, a modo de información se recomienda el módulo LE910C1-NA de
TELIT con soporte para LTE, cuya disribución se realiza por parte de la empresa de Electromponentes.
La ventaja de éstos modulos es que permiten tener el control total del terminal móvil, como la selección
de las bandas de comunicación que se describirá en breve.
• Teléfono móvil liberado y con permiso root.
Se opta por la segunda opción, dado que por el momento no se cuenta con un módulo de comunicación
compatible con el estándar. El celular utilizado para los ensayos es el modelo Alcatel OneTouch 5042A, g.4,
cuyas características técnicas de interés son:
• Procesador, Quad-core 1.2 GHz.
• Sistema Operativo, Android Lollipop v5.0.
• Liberado de fábrica.
• Permisos de Root.
• Bandas de telecomunicación móvil.
2G, GSM 850 / 900 / 1800 / 1900.
3G, HSDPA 850 / 900 / 1900 / 2100.
4G. LTE 800 / 900 / 1800 / 2100 / 2600 (Bandas 1, 3, 7, 8, 20).
Max. Velocidad HSPA 42.2/11.5 Mbps, LTE Cat4 150/50 Mbps.

Figure 4: Terminal Móvil, Alcatel 5042A.
Pues bien, ahora es necesario denir a las tarjetas SIM/USIM, y cual de ellas se implementaran en el
proyecto. Es necesario para ello conocer las carácteristicas y prestaciones que ofrece cada una.
• SIM fué introducido por el estándar GSM (2G) y extendido por EDGE/GPRS con la nalidad de autenticar
al suscriptor en la red.
• USIM fué introducido por el estándar UMTS (3G) para cubrir los aspectos generales de la tarjeta además
de aplicaciones especíca. Al igual que con GPRS, se utiliza el protocolo para autenticar al suscriptor en
la red con el agregado de una clave K o Ki, propia de cada tarjeta. El protocolo USIM es retrocompatible
con su predecesor SIM, hoy en día casi todos los teléfonos móviles soportan este estándar.
Algoritmos de autenticación.
Una red GSM puede admitir cualquier algoritmo de autenticación, siempre que éste se implemente en la (U)SIM
y la AUC. Como ambos son controlados por el operador local del suscriptor es que el operador puede elegir
libremente cualquier algoritmo para la autenticación. Sin embargo, la realidad es que no todos los operadores
tienen tanto la experiencia en criptografía como un poder de mercado lo sucientemente signicativo como para
que los fabricantes de SIM implementen su algoritmo. Es así que los algoritmos son diseñados por el GSMA y
en consecuencia implementados por los operadores, siendo el algoritmo más conocido para GSM el COMP128.
Para el caso de las redes UMTS y LTE sucede algo similar en la que sólo el USIM y el AUC necesitan conocer
el algoritmo. En la práctica el algoritmo más implementado y difundido es el MILENAGE.
Códigos OP, OPC y K.4

El código OP (Operator Code), es un Campo de conguración del algoritmo de variante del operador de 128 bits
o dicho de otra manera es un código asignado a un operador en particular y empleado en algoritmos de generación
de claves de autenticación para redes 3G y 4G, por lo que el OP no es propio de las tarjetas SIM ni de los
usuarios de la red. Por otro lado, el OPC y Ki son claves proias de las tarjetas SIM, más especícamente el OPC
toma el lugar del OP a un nivel de usuario dado que éste se calcula por medio del algoritmo RijndaelEncrypt
que toma por entrada las claves OP y Ki. Con esto último se deduce que si algún usuario tiene conocimiento del
código OPC de la SIM, entonces puede clonar únicamente esa SIM, no todas las SIM. Demás esta decir que esto
está prohibido legalmente a nivel mundial y eso hace que su manipulación sea sumamente riesgosa. Entonces,
en resumen el código OP es propio del operador mientras que el OPC es propio de cada usuario (SIM).
Con lo mencionado en los párrafos anteriores es indefectiblemente que se deben conocer los códigos Ki, OPC
de la tarjeta SIM y el OP de la BTS. Para éste último, mediante el path del archivo genérico del proyecto
/openlte_v00-20-05/liblte/src/liblte_security.cc
4 https://diameter-protocol.blogspot.com/2013/06/usage-of-opopc-and-transport-key.html
se obtiene el código OP=63bfa50ee652336514c1f45f88737d de la BTS congurado por defecto.

Para obtener los dos códigos restantes se proponen tres alternativas viables
• Obtener clave Ki mediante un simulador de sim con microcontrolador.
• Lector de tarjetas SIM SuperSim.
• Tarjetas USIM SJS1 Sysmocom.
Para el primer caso se implementa el esquema eléctrico de la g.5 especicado en el sitio web
https://sites.google.com/site/ehobbyprojects/make-a-gsm-sim-using-pic-microcontroller
(a) Simulador SIM esquemático
(b) Implementación simulador
Figure 5: Simulador SIM con microcontrolador.
Microchip. También
Para programar el pic 16F877A y la memoria se usó el programador pickit3 de la rma
se descargo el software recomendado SIM_EMU_6.01_CFG_v2.1 disponible únicamente para el Sistema
Operativo Windows. Se cargan los dos archivos
16f877a.hex
24c64.hex
Se prueban SIM's activas de distintos operadores como Personal, Movistar, Claro y Tuenti. Tras correr
los programas, siguiendo en detalle cada uno de los pasos del post, no se pudo obtener información relevante
de algún código y es por ello que se descarta este método dado que además no se tiene acceso al código de
programación.
Se pone en práctica entonces el segundo método con el lector de SIM SuperSIM de la g.6. También sin
exito debido a que únicamente se dispone del lector, si bien se pudo descargar los drivers tanto para Windows
como para Linux en ningún momento podía leer los datos de las tarjetas de prueba. Esto nos permitió deducir
que es necesaria una tarjeta virgen especial que permita grabar/leer datos en la misma como la que se observa
en la gura.
Figure 6: Lector universal de SIM - SuperSIM.
El anterior método nos brindó una noción de que es lo que podría funcionar y es así que decide abandonar las
tarjetas anteriores y adquierír las nuevas tarjetas USIM-SJS1, g.7, de la empresa Osmocom. Éstas soportan:
• Ki, K, OP y OPC programables. (OPC por defecto)
• ICCID, IMSI, MSISDN programables.
• Autenticación UMTS: MILENAGE (por defecto), XOR.
• Autenticación GSM: COMP128v1 (por defecto), COMP128v2 y COMP128v3, XOR, MILENAGE.
• Clave ADM para cada tarjeta individual.
• Compatibilidad GSM TS 11.11.
• Memoria Flash de 64kByte.
Además debe mencionarse que el vendedor nos ha proporcionado una tabla con todos los códigos de la
tarjeta. Estos están resguardados a modo de back up para volver a una condiguración por defecto en algún
momento, dado que como se mencionó antes es posible programarla en su totalidad.
Figure 7: USIM SJS1 - Sysmocom.
También se adquiere el lectograbador de tarjetas SIM distribuido por la misma empresa cuyo modelo es
Cardman 3121 - Omnikey HID, g.8.
Figure 8: Cardman 3121 - Omnikey HID.
A continuación se listan los comandos de instalación del proyecto libre

5 Pysim que permite leer y programar
las tarjetas con el lector descripto.
sudo apt-get install pcscd pcsc-tools libccid libpcsclite-dev

sudo /usr/bin/python setup.py build_ext install
sudo apt-get install python-pip
pip install --upgrade setuptools
sudo pcsc_scan
/* Descargar el proyecto pyscard desde el link:

* https://sourceforge.net/projectas/pyscard/files/pyscard/
*/
sudo /usr/bin/python setup.py build_ext install
git clone git://git.osmocom.org/pysim pysim
cd pysim
pip install pyserial
Una vez instalado el proyecto, para programar las tarjetas se llama al programa pySim-prog.py. Para más
detalle respecto a los comandos de programación, ver la sección 7.1 pySim-prog.py del manual de referencia de
5 Existen versiones de prueba para Windows, pero estas son muy limitadas a menos que se compre la licencia de uso. Chipman
es un software con el que se intentó leer el código de las tarjetas pero no se obtuvo información relevante alguna.
sysmocom. Un detalle a tener en cuenta es que las tarjetas se programan por defecto con un valor de OPC, sin
embargo modicando una bandera del registro EE.OPC puede seleccionarse la programación con el código OP
u OPC. Otra alternativa para esto es utilizar un programa sysmo-usim-tool también cubierto por el proyecto
Pysim pero esto solo se comenta ya que no se implemento en la práctica.
diego@Sputnik9210:~/Descargas/pyscard-1.9.5/pysim$ ./pySim-prog.py -p 0 -t sysmoUSIM-SJS1

-a 78663659 -x 001 -y 01 -i 901700000023604 -s 8988211000000236045
-o d3b5defbda0e53609dab7ad38e5d75a8 -k 329C7F8B99929377FBBFE77A765A7867
Insert card now (or CTRL-C to cancel)
Generated card parameters :
> Name : Magic
> SMSP : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
> ICCID : 8988211000000236045
> MCC/MNC : 1/1
> IMSI : 901700000023604
> Ki : 329C7F8B99929377FBBFE77A765A7867
> OPC : d3b5defbda0e53609dab7ad38e5d75a8
> ACC : None
Programming ...
Done !
De igual manera, para la lectura de las tarjetas se llama al programa pySim-read.py.
diego@Sputnik9210:~/Descargas/pyscard-1.9.5/pysim$ ./pySim-read.py -p0
ICCID: 8988211000000236045
IMSI: 901700000023604
SMSP: ffffffffffffffffffffffffffffffffffffffffffffffffe1ffffffffffffffffffffffff
0581005155f5ffffffffffff000000
PLMNsel: fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffffffffffffffff
PLMNwAcT: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffff
OPLMNwAcT: fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffffffffffffffffff
HPLMNAcT: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffff
ACC: 0010
MSISDN: Not available
Done !
2.3 Ensayos
Los ensayos se llevarán a cabo sobre la aplicación LTE_fdd_enodeb de OpenLTE, pero primero se describe
brevemente el proceso de instalación del proyecto. Para ello se siguen los pasos de la página ocial del mismo
https://sourceforge.net/p/openlte/wiki/Installing\%20OpenLTE/
/* Instalación de librerias libpolarSSL y libbladerf-dev */
sudo apt-get install libbladerf-dev
sudo apt-get install libpolarssl-dev

/* En caso de no funcionar se prueban los siguientes comandos*/
wget http://launchpadlibrarian.net/195987839/libpolarssl7_1.3.9-2.1_amd64.deb
wget http://launchpadlibrarian.net/195987837/libpolarssl-dev_1.3.9-2.1_amd64.deb
dpkg -i libpolarssl7_1.3.9-2.1_amd64.deb"
sudo dpkg -i libpolarssl7_1.3.9-2.1_amd64.deb
/* Descarga y compilación del proyecto OpenLTE en su version 20.05 */

git clone https://sourceforge.net/projects/openlte/files/
mkdir build
cd build
sudo cmake ../
sudo make
sudo make install
2.3.1 Conguración del eNodeB

Para la conguración del eNodeB se abren dos terminales T1 y T2, en la primera se llama al proceso LTE_fdd_enodeb
y en T2 se abre el puerto 30000 mediante el comando telnet 30000 éste se encargará del control de la red
mediante unos comandos básicos. Con el comando help se ve la conguración actual de la red, como se lista
abajo.
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
*** LTE FDD ENB ***
Type help to see a list of commands
help
***System Configuration Parameters***
Read parameters using read <param> format
Set parameters using write <param> <value> format
Commands:
start - Constructs the system information and
starts the eNB
stop - Stops the eNB
shutdown - Stops the eNB and exits
construct_si - Constructs the new system information
help - Prints this screen
add_user imsi=<imsi> imei=<imei> k=<k> - Adds a user to the HSS (<imsi> and
<imei> are 15 decimal digits, and <k> is 32 hex digits)
del_user imsi=<imsi> - Deletes a user from the HSS
print_users - Prints all the users in the HSS
Radio Parameters:
available_radios: (read-only)
0: no_rf
1: type=b200,name=,serial=F54397,product=B200
selected_radio_name (read-only) = type=b200,name=,serial=F54397,product=B200
selected_radio_idx = 1
tx_gain = 0
rx_gain = 0
clock_source = internal
System Parameters:
band = 1
bandwidth = 5
cell_id = 1
debug_level = radio phy mac rlc pdcp rrc mme gw user rb timer iface
debug_type = error warning info debug
dl_center_freq = 1822500000
dl_earfcn = 575
dns_addr = 08080808
enable_pcap = 0
ip_addr_start = 0A000001
mcc = 001
mnc = 01
n_ant = 1
n_id_cell = 0
p0_nominal_pucch = -96
p0_nominal_pusch = -70
q_hyst = 0
q_rx_lev_min = -140
search_win_size = 0
sib3_present = 0
sib4_present = 0
sib5_present = 0
sib6_present = 0
sib7_present = 0
sib8_present = 0
tracking_area_code = 1
ul_center_freq = 1727500000
ul_earfcn = 18575
use_cnfg_file = 1
use_user_file = 1
Los comandos start, stop y shutdown controlan el encendido y apagado de la red. Mientras que los demás
pa¯ametros pueden congurarse mediante el comando write, como por ejemplo
write bandwidth 5
De igual manera, si es que se quiere conocer el valor de un parámetro en particular se realiza mendiante el
comando read seguido por el parámetro.
Para el UE se selecciona una tarjeta virgen sysmocom y se la congura con los siguientes códigos.
IMSI: 901700000023604
ICCID: 8988211000000236045
ACC: 0010
PIN1: 3669
PUK1: 82164838
PIN2: 3402
PUK2: 67148281
Ki: 329C7F8B99929377FBBFE77A765A7867
OPC: 49A8C98BE9F93366BACEF7E5D4E3C9C7
ADM1: 78663659
KIC1: 62247DC638936B293799E0144270C973
KID1: 681BE63FEAEC5A305B1C6C70C7B2FA2A
KIK1: 08618C0F328B4A8BA9F95BD9957C7C3F
En la lista anterior se observa que se carga el código Ki brindado por el fabricante, mientras que el OPC
ingresado se corresponde con el valor calculado por el eNodeB a partir del OP y Ki. Para ello debe cargarse un
nuevo usuario en la red mediante el comando
add_user imsi=901700000023604 imei=014152007407532 k=329C7F8B99929377FBBFE77A765A7867

Un parámetro muy importante del estándar LTE es el earfcn y describe la frecuencia de portadora en los
enlaces uplink/downlink de cada banda asignada al protocolo. Debe tenerse en cuencia que el valor de earfcn
es independiente del ancho de banda del canal elegido. Para más detalle referirse al documento de Referencia
ETSI TS 136 106 V10.0.0 (2011-01).
En un principio se seleccionó la banda 3, con un ancho de banda de 10MHz, sin embargo no era posible
visualizar la red por parte del móvil. Tras investigar en el foro del proyecto se opta por cambiar a la banda 1,
teniendo la certeza de que teléfono soporta esta banda. Se atiende también al detalle de usar las antenas de alta
ganancia (5 a 8dBi) recomendadas por el desarrollador, particularmente se usaron las antenas VERT900 y los
niveles de ganancia de transmisión-recepción típicos (60 y 30). Dicho esto se realiza la siguiente conguración ,
6
la justicación del valor de cada parámetro se irán explicando en las siguientes secciones.
write band 1
write bandwidth 5
write dl_earfcn 575
write mcc 001
write mnc 01
write tx_gain 60
write rx_gain 30
Para comprobar y seguir el intercambio de mensajes por las distintas capas que componen al eNodeB se usa
un tercer terminal T3 que se conecta al puerto 30001, el comando es el mismo que el de T2, telnet 30001. Los
resultados obtenidos en éste terminal se desarrollan en la sección 2.5.
2.3.2 Conguración y análisis de espectro de la Banda 1

Como se aclaró en la sección anterior, se elige la banda 1 para establecer el enlace. Sin embargo, es sumamente
importante tener presente que esta banda es muy usada para broadcast y por lo tanto se debe ser cuidadoso al
momento de realizar las pruebas de enlace, de otra manera deberá pedirse un tipo de licencia de investigación
a ENACOM, organismo que regula las bandas de telecomunicación en nuestro país.
Por lo pronto, se decide realizar un barrido de frecuencia sobre la banda 1 con el analizador de espectro
Signal Hound SA44B, g.9, a nes de estudiar su contenido espectral en los canales uplink (1930 - 1990MHz),
downlink (2110 - 2170MHz) y ver si es posible usar una frecuencia especíca para la prueba de transmisión.
Figure 9: Analizador de Espectro - Signal Hound SA44B.
En la g.10 se observa el contenido espectral de la banda 1, sin la señal LTE generada por la estación base.
7
A partir de las imagenes anteriores y mediante la tabla de referencia citada en el Anexo , se opta por
transmitir en las frecuencias de 2167.5MHz (earfcn downlink 575) para el enlace de bajada y 1977.5MHz (earfcn
uplink 18575) para el de subida. En la g.11 se ve el espectro de transmisión generado por el eNodeB.
6 Para agilizar el proceso de preconguración se desarrollo un script.

7 A nes de corroboración, se usa la aplicación online que permite calcular la frecuencia a partir del earfcn,
http://niviuk.free.fr/lte_band.php.
(a) Uplink
(b) Downlink
Figure 10: Espectro de la Banda 1, sin transmisión.

(a) Uplink - 1977.5MHz
(b) Downlink - 2167.5MHz
(c) Downlink (zoom)
Figure 11: Especto de Banda 1 con transmisión del eNodeB.

2.3.3 Relación Ancho de Banda - procesamiento

Para la banda elegida se tiene como límite máximo un ancho de banda de 60MHz, pero se opta por un ancho
de banda de 10MHz dado que es lo recomendado por el desarrollador. Sin embargo, creimos oportuno realizar
una prueba de procesamiento, ya que mientras mayor sea el ancho de banda seleccionado mayor es la demanda
de procesamiento por parte de la computadora.
El comando top acusa el estado de todos los procesos corriendose en la computadora. Una variante de éste
que brinda aún mucho más información es htop, el cual se utiliza actualmente para la depuración a nivel de
procesos, pero por ahora nos limitamos sólo al uso del primero. Mediante el comando nice es posible congurar
la prioridad de ejecución de un proceso y con el agregado de -20 se asigna la mayor prioridad a esa tarea.
Las líneas de abajo muestran la secuencia de comandos que deben ingresarse en el terminal para la prueba de
procesamiento y en la g.12 se observan los resultados correspondientes.
sudo nice -n -20 LTE_fdd_enodeb

top
Figure 12: Comando top, procesamiento LTE_fdd_enodeb.
Se realizan diferentes pruebas con valores de ancho de banda de 10, 5, 3 y 1.4MHz. Este último es el
mínimo valor asignable, además cabe mencionar que en el terminal donde se llama al proceso principal de
LTE_fdd_enodeb, aparecen unas letras desconocidas U,L. Realizando un análisis en el foro, se encuentra que
hacen referencia al nivel de procesamiento por parte de la computadora respecto al requerimiento de la etapa
de RF. Dicho de otra manera, U=Underow y L=Late Package están acusando que el procesamiento de la
pc es demasiado lento para cumplir con los requisitos de la etapa de RF. Es lógico esperarse entonces que ante
un ancho de banda mayor aparezcan varias de estas letras, por la cantidad de procesamiento requerido en su
mayoria debido al cálculo de la FFT, que para un ancho de banda más chico.
Por ejemplo, para un ancho de banda de 10MHz la demanda de procesamiento es del 51% aproximadamente,
mientras que es de un 42% para 5MHz, como se muestra en la g.12. En la g.13 se observa también que la
cantidad de letras aumenta cuando el ancho de banda es relativamente grande, tal y como se había estimado.
En cuanto a los valores de BW más chicos no mostraban resultados muy diferentes a los obtenidos para 5MHz,
de hecho la cantidad de letras era mayor, se deduce entonces que el nivel óptimo de ancho de banda para las
pruebas que se llevan a cabo aquí es de 5MHz.
Figure 13: Mensajes en el terminal LTE_fdd_enodeb.

2.4 Dicultades
En esta sección se describen las dicultades técnicas que surgen tras implementar los protocolos en las diversas
plataformas y sus posibles soluciones aplicadas.
2.4.1 IP no asignada a la red GPRS en OpenBTS

Se implementa el estándar GSM con las nuevas tarjetas sysmocom con exito, con resultados exitosos. Cabe
mencionar que esto ya había sido posible de implementar con el uso de tarjetas SIM de operadores conocidos.
Pero como bien se aclaró en las secciones anteriores, en GSM no se requieren claves de autenticación para
registrarse en la red.
Por otra parte, al implementar el estándar GPRS los resultados ya no son muy positivos, puesto que no se
detecta alguna mejora respecto a los resultados que se habian obtenido con las tarjetas anteriores. Pero pueden
comentarse algunas cuestiones relevantes, como ser el uso del código ki de la tarjeta para registrar al usuario
en la red y con esto llevar a cabo parte de su autenticación. En las líneas que siguen se detalla el procedimiento
de registro de usuario en la red.
$ ./nmcli.py sipauthserve subscribers create "Alcatel" IMSI901700000023604 \0002

ki329C7F8B99929377FBBFE77A765A7867
raw request: {"command":"subscribers","action":"create","fields":
{"name":"Alcatel","imsi":"IMSI901700000023604","msisdn":"0002","ki":
"ki329C7F8B99929377FBBFE77A765A7867"}}
raw response: {
"code" : 200,
"data" : "both ok"
}
En la g.14 se muestra que el usuario está autenticado en la red, dado que AUTH=1. Se congura el APN
(Access Point Name) para el acceso a internet y se observa que tras correr los comandos de gprs list y sgsn
list la BTS sigue sin asignar una IP al teléfono.
Debe mencionarse que tras ejecutar los comandos, los mensajes de salida por lo general no suelen ser
repetibles como aparece en la imagen, es decir que tras correrlos algunas veces devuelven un valor como el que
se ve en la gura y otras veces simplemente no devuelven nada. Se sospecha que esto se deba a un problema
de ganancia de las antenas o un falla en la conguración del puente adaptador de red de la máquina virtual
donde se encuentra corriendo el sistema OpenBTS. No obstante, se probó cambiar las antenas por unas del tipo
VERT900, como recomienda el desarrollador, pero el problema persiste. En cuanto a la conguración del puente
adaptador, no parece haber problema alguno en su conguración. Dado que se ha centrado toda la atención en
la resolución de los problemas de OpenLTE es que no se continuó con la investigación de las posibles causas de
la falla.
2.4.2 Red PLMN−00101 no visible en OpenLTE

Como se comento anteriormente, luego de ejecutar el programa de LTE_fdd_enodeb, resulta que en el celular
de prueba no es posible visualizar la red. Se modicaron los parámetros básicos del protocolo, como ancho de
banda, banda de operación, canal de transmisión, ganancia de las antenas, aun así el problema persiste y no
tiene mejoras al respecto. Es ahí cuando surge la curiosidad de saber, cómo el teléfono realiza la elección de la
banda de comunicación en LTE a la que quiere conectarse. Tras investigar en la web, se descubren las siguientes
alternativas para sortear este inconveniente:
• Modo ingeniería, mediante la apliación de Android (MKT Engineering Mode).
• Rooteo del teléfono para instalar aplicaciones Android dedicadas.
• Información técnica del teléfono mediante el código *#*# 4636 #*#*, éste codigo diere según el fabri-
cante.
Se probaron cada una de las opciones listadas arriba y a continuación se expresan los resultados obtenidos
por las mismas.
Con la aplicación MKT Engineering Mode no se tuvo información relevante, dado que no permitia acceder
a esa información del teléfono, por mas que se le haya otorgado el permiso de root. En este caso, para el rooteo
del teléfono se uso la aplicación de escritorio para Windows de KingRoot, cuya página ocial es
Figure 14: Comandos gprs list y sgsn list en OpenBTS.
https://kingroot.net/
cabe mencionar que existen varios métodos para rootear teléfonos y algunos más ecientes que otros, con esto
quiero decir que el éxito de la operación depende del modelo del terminal y es por eso que es necesario vericar
primero que el método de rooteo soporte el modelo de teléfono. Ya con el permiso de root otorgado, se abre un
abanico de nuevas aplicaciones de propositos especícos muy potentes que permiten obtener mayor información
técnica del dispositivo del que antes no era posible acceder. Para nuestro propósito se instalan dos aplicaciones
muy destacadas en el campo:
• LTE Discovery.
• Network Signal Guru.
La aplicación más versatil y la que brinda mayor información respecto a los parámetros de la red es Network
Signal Guru. En las gs.15 se visualizan los datos relevados por la misma.
(a) Modulación (b) Nivel de señal
(c) Canales PUSCH/PUCCH (d) Conguración
Figure 15: Parámetros Banda 1 - Network Signal Guru.

Por otra parte en la g.16 se muestra los datos de red del tras ingresar el código, *#*# 4636 #*#*.
Figure 16: Datos de red LTE preseteado en móvil Alcatel 5042A.
Es importante remarcar que en esta instancia, todas las aplicaciones coinciden en su diagnóstico durante
el testeo de la red, acusando que la banda 1 y el earfcn 25 son los parámetros predenidos por defecto por el
teléfono. Debe remarcarse que cuando se realizaron estas capturas no se había llevado a cabo aún el barrido de
frecuencia de la banda 1, esto explica por que pueden llegar a variar el valor de los parámetros reejados en las
capturas, sin embargo no deja de ser relevante.
2.5 Resultados
A continuación se lista los mensajes de depuración obtenidos por el puerto telnet 30001, tras ejecutar el proceso
LTE_fdd_enodeb.
08/28/2018 10:24:40.639300 error phy LTE_fdd_enb_phy.cc 709 PDSCH current_tti from MAC (10231)
does not match PHY (1)
08/28/2018 10:24:42.839579 warning msgq LTE_fdd_enb_msgq.cc 234 mac_to_phy circular buffer

empty on receive
08/28/2018 10:24:42.842559 warning msgq LTE_fdd_enb_msgq.cc 234 mac_to_timer circular buffer
empty on receive
empty on receive
empty on receive
empty on receive
08/28/2018 10:24:50.875368 info mac LTE_fdd_enb_mac.cc 407 MAC_dl_tti - PHY_dl_tti != 2

(-10238), skipping 0 subframes
(-10239), skipping 0 subframes
(0), skipping 0 subframes
08/28/2018 10:24:50.878698 info mac LTE_fdd_enb_mac.cc 407 MAC_dl_tti - PHY_dl_tti != 2 (-1),

skipping 4 subframes
08/28/2018 11:00:57.232266 error radio LTE_fdd_enb_radio.cc 456 RX old time spec 9625929598 9625929600
08/28/2018 11:00:57.232523 error radio LTE_fdd_enb_radio.cc 464 RX overrun 9625931518 9625929600
08/28/2018 11:00:57.233852 info radio LTE_fdd_enb_radio.cc 424 RX modifying recv_size to sync
9625944958 9625943040
08/28/2018 11:00:57.233915 info radio LTE_fdd_enb_radio.cc 424 RX modifying recv_size to sync
9625944958 9625944958
08/28/2018 11:00:57.241712 error mme LTE_fdd_enb_mme.cc 712 Authentication failure cause=14,

RNTI=67,RB=SRB1
La primer cadena de mensajes de error hace referencia al canal PDSCH: Physical Downlink Shared Channel
y acusa de una falla de sincronización entre las capas física y mac. Si bien, la red LTE en esta instancia ya
es visible por parte del ue, éste aún no se encuentra autenticado en la base. Pese a esto, el mensaje de error
continúa presente a lo largo de todo el proceso. Según las recomendaciones del desarrollador es conveniente
analizar como se reparte el procesamiento en los diferentes núcleos del microprocesador de la computadora. Se
sospecha que aunque se haya congurado la transmisión para un ancho de banda de 5MHz el procesamiento de
los núcleos es todavia lento para poder cubrir los requisitos de RF necesarios para la transmisión. Los mensajes
de advertencia (warning) estarían informando justamente ésto, ya que es posible que el buer de recepción esté
vacio por que no se ha intercambiado mensajes entre estas dos capas debido a la falta de sincronismo.
El segundo error, es temporal ya que sólo se maniesta en el inicio del sistema pués la etapa de radio (RF)
se encuentra calibrando el oscilador al valor de 9625944958. Una vez que se alcanza el mensaje no vuelve a
aparecer pues ya se ha producido la sincronización.
En cambio, el tercer tipo de error se reere a la parte mme de la red, esto pertenece a la EPC. Como bien
anuncia hay un fallo en la autenticación del usuario en la red y se sospecha que sea por la falta de asignación
IP al ue. Para ello se conguró el APN www.openLTE.com en el teléfono celular, sin embargo el mensaje de
error persiste pero en la terminal T1 donde se llamó al proceso LTE_fdd_enodeb aparece el siguiente mensaje
info user authentication successful imsi=901700000023604 imei=014152007407532

Aparentemente el teléfono realiza el intento de registrarse en la red pero falla en un paso y esto puede estar
relacionado con la secuencia de mensajes intercambiados entre las dos entidades ue-enodeb, conocido con el
nombre de Random Access. En el caso de que el teléfono se registre correctamente en la red los mensajes que
deberían aparecer en el terminal T1 serían
info user authentication successful imsi=901700000023604 imei=014152007407532

info user fully attached imsi=901700000023604 imei=014152007407532
info default bearer setup for imsi=901700000023604 imei=014152007407532
Los mensajes informativos (info) avisan sólo el estado de procesamiento de la entidad en cuestión.
3 Conclusión
Para realizar un análisis detallado de los resultados obtenidos mediante las pruebas realizadas exigen un estudio,
al menos mínimo, de los diversos protocolos. Es evidente que cada protocolo puede llegar a ser inmensamente
complejo como es el caso de LTE y su estudio demoraría un tiempo considerable para poder entender cada
mensaje de intercambio entre las distintas capas que conforman al estándar. Si bien el objetivo principal de
estas prácticas era el de implementar los cuatro protocolos de comunicacióm móvil 2G, 2.5G, 3G y 4G, se ha
decidido dedicar gran parte del tiempo al estudio y resolución de problemas de OpenLTE. La razón de esto tiene
su fundamento en la complejidad de la misma y se preere estar actualizados en las nuevas generaciones de las
telecomunicaciones móviles, pese a que éste estándar tenga ya varios años en vigencia en el primer mundo no
es hasta hace 3 años que comenzo a tener vigencia en nuestro país. Por lo que su estudio y aplicación es relati-
vamente novedoso para nosotros, además de esta manera se tendrá una base teórica-práctica para comprender
la nueva generación 5G que se encuentra en desarrollo, cuya fecha de lanzamiento se cree que sea para el año 2020.
Los resultados obtenidos todavía requieren un estudio y análisis exhaustivo, pero aún así se cree que es un
muy buen punto de partida para llevar a cabo próximas pruebas que permitan brindar algún tipo de servi-
cio. Todo esto se traduce en tiempo, tiempo para investigar y solucionar problemas anes. Por el momento,
se dispone de otra placa de desarrollo LimeSDR, de la cual queda por instalar los drivers correspondientes y
analizar su compatibilidad con el proyecto OpenLTE principalmente. Se prevee que junto con la placa base
Ettus B200 se realice un testeo de transmisión-recepción, esto nos permitiría realizar un testeo continuo sobre
la red generada. El hecho de disponer de un lectograbador y tarjetas USIM reprogramables brindan un muy
buen nivel de versatilidad para poder realizar todo tipo de pruebas. Por el momento se han llevado a cabo los
ensayos con un teléfono celular liberado y con permiso root, se proyecta sumar más de estos dispositivos móviles
que cumplan con las condiciones mencionadas y también se deja abierta la posibilidad de sumar módulos de
comunicación con soporte del estándar LTE, como son los chips de QUECTEL EC20-A y TELIT LE910C1-NA.
El proyecto de OpenLTE ha sido estudiado en gran parte de éste trabajo, el mismo a sido desarrollado
principalmente para el testeo de la RAN (Radio Access Network) aunque tiene implementado un pequeño EPC
(Evolved packet Core) sobre el cual no se han realizado pruebas. Existen muchos otros proyectos enfocados
especícamente al EPC, no obstante hay uno que implementa tanto a la RAN como al EPC en un sólo proyecto,
se trata del proyecto OpenAirInterface. Por lo que se pudo averiguar, cada entidad deberá ser implementada
en una computadora individual puesto que se implementan dos kernel de diferentes versiones. Se propone seguir
investigando la viabilidad de implementar éste proyecto, parece ser muy atractivo saber que en él se encuentran
actualmente colaborando varias universidades y mas de 100 desarrolladores.
References
[1] M. Ledesma and S. Harvind, Getting Started with OpenBTS, Range Networks, 2015.
[2] W. Harald, SysmoUSIM User Manual, Sysmocom - s.f.m.c GmbH, 2018.
[3] Rohde & Schwarz, LTE Technology Introduction, Application Note, July 2012.
[4] ETSI, ETSI TS 136 106 V10.0.0 (2011-01), Technical Specication, January 2011.
Anexo

RDS Aplicado A Teconología GSM, UMTS y LTE

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

RDS Aplicado A Teconología GSM, UMTS y LTE

Cargado por

Copyright:

Formatos disponibles

Universidad Tecnológica Nacional

Facultad Regional Córdoba

Implementación de los estándares de

Práctica Profesional Supervisada (PPS)

• GPRS: General Packet Radio Service.

• UMTS: Universal Mobile

• LTE: 3GPP Long Term Evolution.

• USPR: Universal Software Radio Peripheral.

• UHD: USPR Hard Driver.

• SIM: Subscriber Identity Module.

• USIM: Universal SIM.

• MCC: Mobile Country Code.

• MNC: Mobile Network Code.

• AUC: Authentication Center.

• UE: User Equipment.

• EARFCN: E-UTRA Absolute Radio Frequency Channel Number.

• Adaptador de Radiofrecuencia RF.

• Procesadores de propósito general o FPGA para el procesamiento de señales.

• Software que permita congurar los diversos protocolos de comunicación.

Figure 1: USPR B200, Ettus Reseach.

Las principales características de la placa son:

• FPGA Xilinx Spartan 6 XC6SLX75.

• Transreceptor de conversión directa, Analog Devices AD9364 RFIC.

• Rango de Frecuencia: 70 MHz - 6 GHz

• Hasta 56 MHz de Ancho de Banda en tiempo real.

• Full duplex, SISO (1 Tx y 1 Rx).

• Conectividad USB 3.0.

• OpenBTS (GSM y GPRS).

• OpenBTS UMTS (3GPP).

1 Vease https://www.ettus.com/product/details/UB200-KIT para más detalles acerca de la placa.

A continuación, la página ocial del proyecto y el repositorio en github.

En la g.2 se presenta la arquitectura de la red 2G implementada por OpenBTS.

Figure 2: Arquitectura de la red 2G implementada por OpenBTS.

• Open Air Interface, (https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home).

Figure 3: Arquitectura 4G LTE.

• Drivers UHD (Ettus SDR B-200) en su última versión.

Algunos de los principales recursos que se brindan en esta versión son:

• Aplicaciones de GNURadio para transmitir y recibir datos desde-hacia un archivo.

• Testeo de recepción en el enlace de bajada mediante USRP B2x0, HackRF o rtl-sdr.

• Implementación y testeo de EnodeB con USRP B2x0, HackRF o rtl-sdr.

• Escaneo de celdas operadores cercanas.

• Teléfono móvil liberado y con permiso root.

• Procesador, Quad-core 1.2 GHz.

• Sistema Operativo, Android Lollipop v5.0.

• Bandas de telecomunicación móvil.

 2G, GSM 850 / 900 / 1800 / 1900.

 3G, HSDPA 850 / 900 / 1900 / 2100.

 4G. LTE 800 / 900 / 1800 / 2100 / 2600 (Bandas 1, 3, 7, 8, 20).

 Max. Velocidad HSPA 42.2/11.5 Mbps, LTE Cat4 150/50 Mbps.

Figure 4: Terminal Móvil, Alcatel 5042A.

Códigos OP, OPC y K.4

se obtiene el código OP=63bfa50ee652336514c1f45f88737d de la BTS congurado por defecto.

• Obtener clave Ki mediante un simulador de sim con microcontrolador.

• Lector de tarjetas SIM SuperSim.

• Tarjetas USIM SJS1 Sysmocom.

(a) Simulador SIM esquemático

(b) Implementación simulador

Figure 5: Simulador SIM con microcontrolador.

Figure 6: Lector universal de SIM - SuperSIM.

• Ki, K, OP y OPC programables. (OPC por defecto)

• ICCID, IMSI, MSISDN programables.

• Autenticación UMTS: MILENAGE (por defecto), XOR.

• Autenticación GSM: COMP128v1 (por defecto), COMP128v2 y COMP128v3, XOR, MILENAGE.

• Software que permita congurar los diversos protocolos de comunicación.

A continuación, la página ocial del proyecto y el repositorio en github.

En la g.2 se presenta la arquitectura de la red 2G implementada por OpenBTS.

2G, GSM 850 / 900 / 1800 / 1900.

3G, HSDPA 850 / 900 / 1900 / 2100.

4G. LTE 800 / 900 / 1800 / 2100 / 2600 (Bandas 1, 3, 7, 8, 20).

Max. Velocidad HSPA 42.2/11.5 Mbps, LTE Cat4 150/50 Mbps.

se obtiene el código OP=63bfa50ee652336514c1f45f88737d de la BTS congurado por defecto.

2.3.1 Conguración del eNodeB

2.3.2 Conguración y análisis de espectro de la Banda 1

6 Para agilizar el proceso de preconguración se desarrollo un script.

(c) Canales PUSCH/PUCCH (d) Conguración

[2] W. Harald, SysmoUSIM User Manual, Sysmocom - s.f.m.c GmbH, 2018.