Universidad de Costa Rica
Facultad de Ingenier´ıa
Escuela de Ingenier´ıa El´
ectrica
Aplicaci´
on web para visualizaci´
on de datos
de dispositivos m´
oviles en el tiempo y el
espacio
Por:
Jos´e David Vargas Quir´os
Ciudad Universitaria “Rodrigo Facio”, Costa Rica
Aplicaci´
on web para visualizaci´
on de datos
de dispositivos m´
oviles en el tiempo y el
espacio
Por:
Jos´e David Vargas Quir´os
IE-0499 Proyecto el´ectrico Aprobado por el Tribunal:
Dr. Lochi Yu Lo Profesor gu´ıa
M. Sc. Teodoro Willink Castro Ing. Gustavo N´u˜nez Segura Profesor lector Profesor lector
Resumen
Ante la necesidad de una plataforma que permita a los usuarios verificar el cumplimiento de la cobertura celular y velocidades de datos ofrecidas por los operadores, se decidi´o crear un medio social y colaborativo para generar mapas de cobertura celular y velocidad de internet m´ovil en Costa Rica. El presente proyecto comprende la primera etapa del desarrollo de la plataforma, que consiste en el desarrollo de una aplicaci´on web capaz de generar mapas a partir de datos de localizaci´on geogr´afica (coordenadas), nivel de se˜nal y velocidad de internet. El desarrollo consisti´o en el dise˜no, la programaci´on y las pruebas a dicha aplicaci´on, con datos generados de manera aleatoria.
Los datos son enviados por usuarios de una aplicaci´on m´ovil (segunda etapa del proyecto) y almacendados en una base de datos. Se generan mapas para cada combinaci´on de tecnolog´ıa y operador celular utilizados en el pa´ıs. La aplicaci´on permite a los usuarios observar la cobertura real aproximada, con el fin de verificar y comparar los niveles ofrecidos.
La aplicaci´on lee la base de datos de mediciones y genera mapas hacien-do uso de Google Maps API para mostrar los resultahacien-dos. Se utiliz´o NodeJS (Javascript) como lenguaje de servidor y MongoDB como sistema de base de datos debido al importante soporte para datos geoespaciales y la capacidad de paralelismo y escalabilidad. Se dedic´o tiempo a crear una interfaz sencilla, vistosa y amigable debido a que el sitio est´a dirigido al p´ublico en general. Se cre´o una interfaz responsiva que se adapta a los dispositivos m´oviles para una mayor usabilidad.
El sistema de generaci´on cuenta con una novedad importante: los mapas son generados en el navegador, mediante Google Maps API. Este hecho per-miti´o una mayor velocidad en la generaci´on y flexibilidad en la configuraci´on de los mapas, a costa de menor de detalle. Se desarroll´o un algoritmo que permite que la resoluci´on del mapa aumente conforme se reciben m´as puntos, dando prioridad a las mediciones m´as recientes y reduciendo el efecto de las mediciones m´as antiguas. El algoritmo contribuye a mantener el mapa actua-lizado sin perder informaci´on de tiempo, como suceder´ıa si se promediaran las mediciones. Adem´as, mediante una distancia m´ınima entre datos, el algoritmo evita la sobrepopulaci´on de la base de datos, que afectar´ıa negativamente el desempe˜no de la aplicaci´on.
La segunda etapa del desarrollo, que no se comprende en este proyecto, consiste en desarrollar la aplicaci´on m´ovil que escriba a la base de datos, misma que utilizar´an los usuarios del sistema. Los mapas generados se podr´an visualizar por medio de la aplicaci´on web. Esta ´ultima se desarroll´o con la interfaz necesaria para comunicarse con los dispositivos m´oviles por medio de solicitudes HTTP, tanto para recibir los datos de los dispositivos m´oviles como para enviar los datos para generar mapas de cobertura.
´
Indice general
´Indice de figuras viii
´Indice de cuadros viii
Nomenclatura ix
1 Introducci´on 1
1.1 Justificaci´on . . . 1
1.2 Alcance del proyecto . . . 3
1.3 Objetivos . . . 4
1.4 Metodolog´ıa . . . 4
1.5 Contenido . . . 5
2 Antecedentes 7 2.1 Sistemas de Bases de Datos . . . 7
2.2 Lenguajes de Programaci´on Web . . . 11
2.3 APIs de Mapeo y Generaci´on de Mapas de Intensidad . . . 15
2.4 Medici´on de Se˜nal Celular . . . 17
3 Desarrollo de la aplicaci´on 21 3.1 Elecci´on de la plataforma de desarrollo . . . 21
3.2 Dise˜no de la base de datos . . . 23
3.3 Dise˜no de la Aplicaci´on Web . . . 31
4 Conclusiones y recomendaciones 47 Bibliograf´ıa 51 A Gu´ıa de Instalaci´on y Mantenimiento de sgnmp.app 53 A.1 ´Indice . . . 53
A.2 Instalaci´on de sgnmp.app . . . 53
A.3 Par´ametros Importantes . . . 56
A.4 Comunicaci´on con la Aplicaci´on M´ovil . . . 56
´
Indice de figuras
2.1 Mapa de calor creado con Google Maps API . . . 16
2.2 Modelo b´asico de un sistema de transmisi´on por radiofrecuencia (Debus, 2006). . . 17
2.3 Variables tomadas en cuenta por un modelo de transmisi´on por radiofrecuencia en un ´area urbana (Debus, 2006). . . 18
2.4 Constantes y variables del modelo de p´erdidas de Hata, que depen-den de la geograf´ıa y desarrollo de la zona (Debus, 2006). . . 19
3.1 P´agina principal de la aplicaci´on, a una resoluci´on de 1024x768 pixeles CSS . . . 42
3.2 Men´u lateral de la aplicaci´on, que permite elegir tipo de mapa, operadores y tecnolog´ıas celulares. . . 43
3.3 P´agina de descarga de la aplicaci´on m´ovil, que busca atraer a usua-rios interesados a colaborar con el proyecto. . . 43
3.4 P´agina de informaci´on detallada sobre el proyecto y datos de con-tacto. . . 44
3.5 A anchos menores a 800px la interfaz es de una sola columna con men´u desplegable. . . 44
3.6 Men´u retractil que desplaza el mapa de cobertura para permitir modificar la configuraci´on, en dispositivos con anchos menores 800px. 45
´
Indice de cuadros
2.1 Alcance en metros de una misma torre celular seg´un diferentes modelos de p´erdidas. . . 203.1 Claves de la colecci´on cdmadata. . . 27
3.2 Claves de la colecci´on gsmdata. . . 28
3.3 Claves de la colecci´on wcdmadata. . . 29
3.4 Claves de la colecci´on ltedata. . . 30
Nomenclatura
PHP Pre-Procesador de Hipertexto (PHP Hypertext Preproces-sor )
JS Javascript
GSM Sistema global para comunicaciones m´oviles (Global Sys-tem for Mobile communications)
LTE Evoluci´on a largo plazo (Long-Term Evolution) CDMA Code Division Multiple Access
WCDMA Wideband Code Division Multiple Access 2G Segunda generaci´on de tecnolog´ıa m´ovil 3G Tercera generaci´on de tecnolog´ıa m´ovil 4G Cuarta generaci´on de tecnolog´ıa m´ovil
ASU Unidad de fuerza arbitraria (Arbitrary Strengh Unit ) dBm Decibelio-miliwatt
MCC C´odigo m´ovil de pa´ıs (Mobile Country Code) MNC C´odigo m´ovil de red (Mobile Network Code)
LAC C´odigo de ´area de localizaci´on (Location Area Code) CID Identificador de celda (Cell IDentity)
RSSI Indicador de potencia de se˜nal recibida (Received Signal Strength Indication)
UMTS Sistema universal de telecomunicaciones m´oviles (Univer-sal Mobile Telecommunications System)
TAC C´odigo de area de seguimiento (Tracking Area Code) API Interfaz de programaci´on de aplicaciones (Application
Pro-gramming Interface)
DBMS Sistema de manejo de base de datos (DataBase Manage-ment System)
RDBMS Sistema de manejo de Base de datos relacional (Relational DataBase Management System)
JSON Notaci´on de objeto Javascript (JavaScript Object Nota-tion)
AJAX Javascript asincr´onico + XML (Asynchronous Javascript + XML)
HTML Lenguaje de marcado de hipertexto (HyperText Markup Language)
XML Lenguaje de marcado extensivo (EXtensive Markup Lan-guage)
CSS Hoja de estilos en cascada (Cascading StyleSheet )
SQL Lenguaje de consulta estructurado (Structured Query Lan-guage)
HTTP Protocolo de transferencia de hipertexto (HyperText Trans-fer Protocol )
FSPL Modelo de propagaci´on de se˜nales en el vac´ıo (Free Space Path Loss)
1
Introducci´
on
1.1
Justificaci´
on
A pesar de que los problemas de cobertura y velocidad de datos afectan a gran parte de los usuarios de dipositivos m´oviles en Costa Rica, no existe una he-rramienta que permita verificar si los operadores celulares realmente cumplen con los mapas de cobertura que muestran a sus clientes, y si la velocidad de Internet realmente es la ofrecida.
En el caso de esta ´ultima, se trata de una variable que no solo cambia de acuerdo a la localizaci´on del dispositivo, sino con la hora del d´ıa, seg´un la saturaci´on de la red celular. La comunidad de usuarios, que comprende una mayor´ıa de la poblaci´on, no tiene una herramienta colaborativa para verificar el cumplimiento de la cobertura y tomar decisiones informadas en este sentido. Existe una gran desinformaci´on al respecto y en algunos casos no se encon-traron mapas de cobertura en l´ınea por parte de los operadores, estos est´an incompletos o el rendimiento de la aplicaci´on es deficiente, al punto de ser poco ´utiles.
Al momento de realizar este proyecto, de los tres operadores celulares en Costa Rica, dos de ellos contaban con mapas de cobertura celular (Movistar, 2014; ICE, 2014). Sin embargo, estos no consideraban la velocidad del servi-cio de Internet m´ovil, una preocupaci´on cada vez mayor entre los usuarios. Solamente un operador prove´ıa un mapa para la velocidad de Internet para la red 4G LTE. El mapa, sin embargo, ofrec´ıa una escala con un rango am-plio de velocidades te´oricas, no velocidades reales medidas por dispotivos. Los operadores tampoco indicaban la forma en que se generaban dichos mapas. Solo un operador indic´o que se realizaba a partir de modelos m´atem´aticos con ajustes mediante mediciones de campo. En pocos casos se indicaba la ´ultima actualizaci´on de las mediciones.
En el 2013, la Superintendencia de Telecomunicaciones (SUTEL) liber´o una herramienta que muestra mapas de cobertura de los tres operadores celu-lares (SUTEL, 2014a). Sin embargo, en los t´erminos de uso de la herramienta se indica:
Los resultados divulgados, reflejan la evoluci´on en la calidad de las redes de los operadores ICE, Claro y Telef´onica a diciembre de 2012, por lo cual pueden existir en la actualidad una mayor cantidad de zonas con cobertura (SUTEL, 2014b).
2 1 Introducci´on
Adem´as se establece que los datos mostrados son provistos por los mismos operadores. Es decir, la herramienta es informativa pero no permite verificar la validez de dichos mapas:
Esta Superintendencia pone a disposici´on de los usuarios finales, los datos recopilados dentro de los pol´ıgonos de cobertura de los operadores, los cuales fueron aportados por ellos para el proce-samiento de los datos. Asimismo, es importante indicar que en consecuencia, los datos que se publican en el presente sitio, se en-cuentran dentro de las manchas de cobertura que los operadores publican en sus respectivas p´aginas WEB (SUTEL, 2014b).
Se vio por lo tanto la necesidad de una herramienta que genere mapas a partir de datos reales, de dispositivos m´oviles, y que distan de los mapas te´oricos basados en modelos a partir de la posici´on de las torres ((N. Rakesh, 2013)), que no toman en cuenta factores como obst´aculos, edificios y saturaci´on de la red en el caso de velocidades de datos. Las mediciones emp´ıricas, debido a que se realizan directamente en el dispositivo m´ovil, son la ´unica forma de medir la calidad del servicio que reciben los usuarios. El crowdsourcing se ha convertido en un fen´omeno de Internet y en una nueva forma de labor: pesonas comunes usando su tiempo libre para proveer informaci´on y resolver problemas. Esta idea se ha convertido en una importante herramienta para muchos proyectos y se vio en ella el potencial para resolver el problema (Howe, 2006).
1.2. Alcance del proyecto 3
1.2
Alcance del proyecto
La plataforma de mapeo de se˜nal comprende dos etapas o productos:
• Una aplicaci´on web encargada de generar mapas de cobertura y veloci-dad a partir de informaci´on almacenada en una base de datos.
• Una aplicaci´on m´ovil, que mediante una estrategia de crowdsourcing utilizan los usuarios para enviar su ubicaci´on exacta y niveles de se˜nal a la base de datos.
El presente proyecto comprende la primera etapa: el dise˜no, desarrollo y pruebas de una aplicaci´on m´ovil sencilla e intuitiva dirigida al p´ublico en general. La aplicaci´on debe ser capaz de generar mapas de se˜nal celular y de velocidad de datos para cada tecnolog´ıa celular implementada actualmente en el pa´ıs: GSM, WCDMA y LTE. En el caso de la velocidad de datos debe ser capaz adem´as de mostrar los cambios en la cobertura a lo largo del d´ıa. Concretamente la aplicaci´on comprende:
• Desarrollo de la interfaz de recepci´on de datos de la aplicaci´on m´ovil. Es-ta recibe los datos an´onimos de los usuarios, los procesa, y los almacena en la base de datos.
• Desarrollo del programa e interfaz para que los usuarios generen los mapas de cobertura. La interfaz permite adem´as obtener informaci´on sobre el proyecto, el funcionamiento de la aplicaci´on, y descarga de la misma.
• Desarrollo de la interfaz de solicitud de datos, que permite, solicitar mediciones de la base de datos mediante HTTP para generar mapas espec´ıficos en cualquier aplicaci´on.
• Scripts de mantenimiento autom´atico de la base de datos, que evitan la sobrepopulaci´on de la misma y analizan los datos peri´odicamente para aumentar la rapidez de la interfaz evitando solicitudes innecesarias. • Desarrollo de scripts de generaci´on de datos de prueba y ejecuci´on de
pruebas a todos los programas de los puntos anteriores.
• Documentaci´on completa del programa, especialmente de lo necesario para la puesta en funcionamiento y la comunicaci´on con la aplicaci´on m´ovil.
4 1 Introducci´on
1.3
Objetivos
Objetivo general
Desarrollar una aplicaci´on web que permita visualizar los datos y estad´ısticas de cobertura celular, localizaci´on y movilizaci´on de los usuarios a partir de una base de datos.
Objetivos espec´ıficos
Para el desarrollo de este proyecto se establecieron los siguientes objetivos:
• Obtener datos de prueba para la aplicaci´on web, ya sea mediante la generaci´on de datos aleatorios o el desarrollo de una aplicaci´on para celular, utilizada por sujetos de prueba.
• Desarrollar una aplicaci´on web de visualizaci´on de datos, compatible con dispositivos m´oviles utilizando un entorno e interfaces de programaci´on de aplicaciones.
• Realizar pruebas de funcionamiento y usabilidad a la aplicaci´on web utilizando los datos de prueba.
1.4
Metodolog´ıa
El desarrollo del trabajo incluye los siguientes pasos y procedimientos, listados en secuencia:
1. Elecci´on de las plataformas de desarrollo a utilizar: lenguaje de progra-maci´on, entornos de desarrollo, sistema de base de datos y API (Appli-cation Programming Interface) de mapeo.
2. Dise˜no de la base de datos requerida por la aplicaci´on. Se determinan los datos a almacenar y las tablas requeridas para el almacenamiento de los mismos.
3. Creaci´on u obtenci´on de datos de prueba para la aplicaci´on web, ya sea mediante el desarrollo de una aplicaci´on movil o la generaci´on de datos semi-aleatorios con el fin de popular las tablas creadas anteriormente. 4. Desarrollo de la aplicaci´on utilizando las herramientas y datos de prueba
1.5. Contenido 5
5. Desarrollo de la interfaz de comunicaci´on con la aplicaci´on m´ovil. Esta recibe datos de los usuarios, los procesa y los almacena en la base de datos.
6. Pruebas finales a la aplicaci´on. Verificaci´on de la funcionalidad y usabi-lidad de la misma a partir de los datos de prueba.
1.5
Contenido
Los cap´ıtulos del informe siguen la siguiente secuencia:
1. Introducci´on al proyecto. Se presenta una introducci´on, los alcances, objetivos, metodolog´ıa y el presente resumen de cap´ıtulos.
2. Antecedentes o estado de la cuesti´on. Se presentan las principales tecno-log´ıas celulares, sistemas de bases de datos y lenguajes de programaci´on de inter´es en el desarrollo del proyecto.
3. Desarrollo del proyecto, comprendiendo las consideraciones de dise˜no, la elecci´on de las plataformas a utilizar, la generaci´on de datos de prueba, la implementaci´on de la aplicaci´on y las pruebas realizadas a la misma. 4. Conclusiones y recomendaciones. Se presentan conclusiones y recomen-daciones importantes para el escalamiento futuro de la herramienta y el desarrollo de la aplicaci´on m´ovil.
2
Antecedentes
En el desarrollo de una aplicaci´on web moderna se requiere de un sistema de base de datos y de un lenguaje de programaci´on web en el servidor. Del lado del usuario, son necesarios un lenguaje de etiquetado y un lenguaje de estilos para la interpretaci´on de la informaci´on y dise˜no de la interfaz, respectivamen-te. Adicionalmente, existen entornos de desarrollo y herramientas auxiliares que pueden ser utilizadas para facilitar la programaci´on o el dise˜no de la he-rramienta. En este cap´ıtulo se hace una recopilaci´on de las herramientas m´as importantes que se tomaron en cuenta, tanto como posibles opciones, como las que finalmente se utilizaron para el desarrollo del proyecto.
Por ´ultimo, se hace una recopilaci´on de los modelos te´oricos de propagaci´on de se˜nales utilizados en el mapeo de se˜nal celular, que permiten determinar rangos te´oricos de antenas y dispositivos m´oviles.
2.1
Sistemas de Bases de Datos
Una base de datos es una forma de almacenar informaci´on de forma que esta pueda ser solicitada de vuelta. Normalmente ´esta es representada en forma de tablas con columnas, donde cada fila representa un dato y cada columna tiene un tipo de dato espec´ıfico (n´umero entero, fecha o texto, por ejemplo). Una tabla representa una colecci´on de objetos del mismo tipo y una base de datos est´a formada por un grupo de tablas, que pueden o no estar relacionadas entre s´ı.
Un sistema de bases de datos (DBMS por Database Management System) se encarga de almacenar, organizar y recuperar los datos y se compone de:
Kernel. Maneja la memoria y el almacenamiento de los datos.
Repositorio de Metadatos. Llamado tambi´en el diccionario de datos, con-tiene los metadatos de las entradas almacenadas.
Lenguaje de Solicitudes. Es el lenguaje que permite que aplicaciones ex-ternas realicen solicitudes de datos.
Las aplicaciones, por lo tanto, interaccionan con la base de datos por medio de lenguajes de consulta como SQL (Structured Query Language). El DBMS se encarga de abstraer el manejo de los datos de forma que la aplicaci´on pueda
8 2 Antecedentes
realizar solicitudes en un lenguaje de alto nivel y con la ilusi´on de que los datos est´an almacenados en tablas (Ashdown y Kyte, 2014).
Bases de Datos Relacionales / No Relacionales
La separaci´on de bases de datos en relacionales y no relacionales es relevante porque es la principal diferencia entre los dos sistemas de bases de datos que se analizaron para el desarrollo. Se trata de una diferencia en el n´ucleo mismo del sistema, que impacta en la utilidad y caracter´ısticas que puede ofrecer. En esta secci´on se explica la diferencia entre estos dos tipos de bases de datos, y sus implicaciones en el desarrollo.
Una base de datos es una colecci´on de tablas, cada una de las cuales con-tiene filas que, para una aplicaci´on, simbolizan objetos. Estos objetos pueden ser relacionados cuando algunas de sus columnas tienen el mismo valor. Por ejemplo, dos filas que representan un auto pueden tener el mismo valor en una columna ”Marca” para indicar que los autos son de la misma marca. Otra tabla que almacena las marcas de auto puede relacionarse por medio de una clave com´un. Por ejemplo, la marca ”Mazda” se identifica con un 5, de forma que los autos de esa marca tienen un 5 en su campo de ”Marca”. En la tabla de marcas, solamente Mazda tiene un 5 en la columna ID. Cada marca tiene un ID ´unico y diferente. Se dice entonces que ID podr´ıa ser una clave primaria de la tabla de marcas. Una clave primaria es una columna o grupo de columnas que son diferentes para cada dato. Sin embargo, aunque cada marca tiene un ID ´unico, varios autos s´ı pueden tener un 5 como ID de marca porque puede haber muchos con la misma marca. Por lo tanto, se dice que el ID de marca es una clave for´anea de la tabla de autos. Una clave for´anea relaciona los datos de una tabla (autos) con otra (marca). Por lo general se utiliza una columna como identificador en cada tabla, de forma que cada fila sea diferente y una o varias como claves for´aneas para relacionarlas. El sistema de base de datos, por lo tanto, puede obtener el nombre de la marca de un auto. Intuitivamente lo hace observando el 5 en la columna que act´ua como clave for´anea y buscan-do la marca con este ID en la tabla de marcas. Como cada marca tiene un ID ´
unico, la ´unica que coincide es Mazda.
Un sistema de bases de datos relacional como SQL sigue una serie de reglas que permite preservar la integridad de los datos, es decir, crear y mantener las relaciones entre ellos:
• Las filas en una tabla relacional siempre son distintas. Este es un requi-sito para crear una clave primaria (que puede incluir varias columnas o incluso todas). Datos iguales no son diferenciables. Se requiere que una o varias columnas siempre tengan valores ´unicos para poder identificar cada dato y asociarlo a datos de otras tablas.
2.1. Sistemas de Bases de Datos 9
• Los datos de las columnas no pueden ser arreglos. Para obtener el mismo resultado se pueden crear dos tablas relacionadas por separado.
• La base de datos utiliza un valor especial llamado NULL para indicar que falta un valor. Dos valores nulos no son considerados iguales por la base de datos. Sin embargo, no pueden existir valores nulos en una clave primaria, porque no permiten identificar el dato.
Las bases de datos relacionales permiten por lo tanto crear una jerarqu´ıa de objetos relacionados, especialmente ´util en muchos sistemas web. Por ejem-plo, un sistema de compras en l´ınea utilizar´ıa una tabla de usuarios, cada uno de los cuales est´a relacionado a una o varias tarjetas de cr´edito o medios de pago y una o varias direcciones f´ısicas. Adem´as cada usuario puede realizar una ilimitada cantidad de compras, cada una con uno o m´as art´ıculos art´ıcu-los, posiblemente diferentes. Una base de datos relacional permite representar todos los objetos involucrados y, mediante un lenguaje sencillo, realizar soli-citudes espec´ıficas. Por ejemplo, un programa podr´ıa solicitar la cantidad de usuarios que compraron un televisor en el ´ultimo mes, o la cantidad de clientes que viven en determinado lugar. (Oracle, 2014a)
Sistemas de Bases de Datos para Desarrollo Web
Existen numerosos sistemas de bases de datos de uso general y espec´ıfico. Dos de los sistemas m´as utilizados en nuevas aplicaciones web son MySQL y MongoDB. El primero es el DBMS relacional por excelencia en desarrollo web. Utiliza el conocido lenguaje SQL y es el DBMS m´as utilizado en Internet hasta la fecha. MongoDB, por su parte, es un sistema no relacional, que no soporta uniones de tablas ni lenguaje SQL y debe su fama a su velocidad, riqueza de tipos de dato y al conveniente almacenamiento de datos en formato JSON (Javascript Object Notation).
MySQL
MySQL es la base de datos m´as utilizada, probada y documentada en desarro-llo web. Tiene la capacidad de manejar Terabytes de datos por tabla. El l´ımite en cuanto a capacidad est´a dado por el sistema operativo y es considerado un sistema de bases de datos veloz. No posee tipos de datos ni funciones para manejar coordenadas de forma nativa pero las provee mediante una extensi´on de datos espaciales (Oracle, 2014b).
MySQL soporta varios motores de almacenamiento que se encargan de almacenar y manipular los datos de la base de datos en archivos, es decir, son el n´ucleo del sistema. Aunque MySQL soporta 10 motores de almacenamiento,
10 2 Antecedentes
la mayor´ıa tienen aplicaciones muy espec´ıficas. Se analizan tres de ellos que son de prop´osito general y potencialmente ´utiles para la aplicaci´on:
MyISAM es el motor de almacenamiento por defecto y el m´as utilizado en la web y otros ambientes. Soporta hasta 256TB de datos e integra todas las funciones de una base de datos que no requiera alta seguridad.
InnoDB es un motor seguro, con soporte para transacciones y capacidades de recuperaci´on, lo que la hace especial para aplicaciones que requieren movimientos seguros como sistemas de compras en l´ınea. Las transac-ciones evitan la p´erdida de datos sensibles, como montos monetarios, por ejemplo, al hacer operaciones en la base de datos.
Memory es un esquema que mantiene todos los datos de la base de datos en memoria RAM, para asegurar el acceso m´as r´apido posible. Sin embargo, no es ´util para bases de datos grandes (Oracle, 2014b).
De los motores descritos, MyISAM es el adecuado para la mayor´ıa de pro-yectos debido a su capacidad, velocidad y simplicidad. El soporte para transac-ciones de InnoDB es necesario en las aplicatransac-ciones que requieran transactransac-ciones seguras. La posibilidad de p´erdida de datos no es un problema para la mayor´ıa de herramientas que no involucran transferencia de fondos.
MongoDB
MongoDB es una base de datos de alto desempe˜no basada en documentos. En MongoDB cada fila de una tabla es un documento, almacenado en for-mato JSON (Javascript Object Notation) u objeto de Javascript en forfor-mato ”clave: valor” lo que facilita la manipulaci´on de los datos desde lenguajes de programaci´on.
MongoDB adem´as ofrece escalamiento autom´atico que divide los datos en-tre varios servidores, facilitando el crecimiento de la base de datos (MongoDB, 2014a).
Una de las principales ventajas de MongoDB es que posee variedad de modelos de datos nativos, como coordenadas espaciales, y funciones espec´ıficas que permiten reducir la cantidad de solicitudes y el tiempo de procesamiento de los datos.
MongoDB maneja dos tipos de superficies: esf´ericas y planas. Los datos esf´ericos se almacenan en objetos GeoJSON. Un objeto GeoJSON es un ob-jeto JSON con un formato espec´ıfico, utilizado par almacenar construcciones geom´etricas. Por ejemplo:
2.2. Lenguajes de Programaci´on Web 11
type: "Point",
coordinates: [ 40, 5 ] } }
Los datos planares se almacenan como pares de coordenadas tradicionales. Debido a que MongoDB es capaz de realizar c´alculos geom´etricos sobre los datos, la ventaja del sistema esf´erico es que toma en cuenta la curvatura de la superficie terrestre.
En la versi´on 2.4 de MongoDB se introdujeron los ´ındices 2dsphere, los cuales, aplicados a una columna de datos esf´ericos en GeoJSON, soportan operaciones geoespaciales sobre datos de coordenadas terrestres. Los objetos GeoJSON fueron introducidos recientemente y permiten almacenar, adem´as de puntos, l´ıneas, pol´ıgonos, multipuntos, multil´ıneas, multipol´ıgonos y colec-ciones de estos. En la aplicaci´on, se require almacenar inicialmente puntos o pares de coordenadas.
MongoDB ofrece tres operaciones geoespaciales de inter´es:
Inclusi´on. Se pueden solicitar localizaciones contenidas totalmente dentro de un pol´ıgono. Estas permiten, por ejemplo, analizar solamente un ´area del mapa de cobertura. Se utilizan ´ındices geoespaciales 2dsphere para me-jorar la velocidad de respuesta.
Intersecci´on. Se buscan localizaciones que intersequen a una figura descrita mediante un objeto GeoJSON. Requieren un ´ındice 2dsphere.
Proximidad. Permiten buscar los datos m´as cercanos a un punto dado. Requieren un ´ındice 2dsphere. Ordena los datos por cercan´ıa y permite especificar una
distancia m´ınima y m´axima, en metros.(MongoDB, 2014b).
2.2
Lenguajes de Programaci´
on Web
Existen lenguajes de programaci´on orientados a servidores que buscan facilitar el desarrollo de aplicaciones web. En general se trata de lenguajes de scrip-ting, que no requieren compilaci´on por parte del programador sino que son compilados y ejecutados por el servidor con cada solicitud. Los dos principales lenguajes utilizados en la actualidad son PHP (PHP Hypertext Preprocessor ) y Javascript.
PHP
PHP es el lenguaje de programaci´on web m´as utilizado y documentado. Se tra-ta de un lenguaje de scripting de alto nivel para servidores. Tradicionalmente se comunica con bases de datos MySQL para el desarrollo de aplicaciones
12 2 Antecedentes
web est´aticas. Requiere de un servidor web como Apache para interpretar los scripts en tiempo real. Las aplicaciones web modernas desarrolladas en PHP utilizan Javascript en el navegador para permitir la creaci´on de sitios web di-n´amicos, donde un script PHP es capaz de responder solicitudes realizadas por el navegador, sin necesidad de que el usuario recargue la p´agina. Este proceso se conoce como AJAX (Asynchronous Javascript + XML). Entre las ventajas de PHP se encuentran:
• Existe una amplia base de datos, documentaci´on y foros que facilitan al desarrollo, al ser el lenguaje m´as utilizado en desarrollo web.
• Se integra con MySQL y MongoDB sin problemas. Solamente se requiere la activaci´on de una extensi´on de PHP.
• Existen numerosos frameworks que facilitan el desarrollo de aplicaciones.
Javascript + Node.js + Express
Javascript para Servidor
A pesar de que Javascript naci´o como un lenguaje para navegadores, en los ´
ultimos a˜nos se ha trasladado al servidor a partir de la inicitiva Node.js. Node es un entorno de desarrollo asincr´onico basado en eventos concebido a partir del motor de Javascript de Google Chrome, que permite crear aplicaciones de red r´apidas y escalables. Se utiliza especialmente para aplicaciones en tiempo real debido a su naturaleza asincr´onica.
Node es m´as que un framework de programaci´on web. Se trata de un entorno para programaci´on de red. En Node el servidor web forma parte de la aplicaci´on. Para crear una aplicaci´on web tradicional, el programador puede r´apidamente crear y programar un servidor HTTP para responder solicitudes. Esto contrasta con el desarrollo tradicional en PHP que requiere la instalaci´on de un servidor web como Apache, bajo el cual corre la aplicaci´on web. Node a˜nade mayor control a un m´ınimo costo (Node.js, 2014).
Express Framework
Express, por su parte, es un marco de desarrollo minimalista de acceso li-bre y c´odigo abierto para Node.js que permite desarrollar aplicaciones web tradicionales mediante un esquema MVC (Model - View - Controller ).
Express se basa en el uso de middleware, definido como una funci´on con acceso a los objetos req (request) y res (response) y al siguiente middleware en el ciclo de solicitud - respuesta.
Los objetos req y res son pasados a las distintas funciones de middleware. El objeto req representa la solicitud HTTP recibida. Contiene la cadena de
2.2. Lenguajes de Programaci´on Web 13
solicitud, los parametros, el encabezado, el cuerpo y posibles cookies enviadas. El objeto res contiene la respuesta HTTP del servidor. Se pueden a˜nadir cookies, redireccionar o enviar c´odigo HTML en la respuesta. El middleware es el encargado tanto de interpretar la solicitud como de escribir la respuesta (Express, 2014).
Una funci´on de middleware puede hacer lo siguiente:
• Ejecutar c´odigo sin restricciones. • Hacer cambios a los objetos req y res. • Terminar el ciclo de solicitud - respuesta. • Llamar al siguiente middleware.
Ejemplos de los m´odulos de middleware que ofrece Express son (Express, 2014):
body-parser. Se encarga del parsing de la solicitud HTTP, extrayendo los par´amtros enviados por el usuario.
connect-timeout. Finaliza la solicitud cuando se ha cumplido un tiempo sin respuesta, 5000ms por defecto.
cookie-parser. Provee una interfaz para el acceso a las cookies. session. Interfaz para el acceso a las sesiones.
serve-static. Se encarga de responder las solicitudes a contenido est´atico, como im´agenes o archivos HTML.
morgan. Lleva un log de los eventos del servidor.
express-debud. Debugger de Express, que a˜nade una pesta˜na con informa-ci´on sobre objetos importantes como req.
Otro concepto central de Express es el de Router. Un router es un tipo de middleware que se asigna a una direcci´on de solicitud. Cuando se recibe una solicitud, esta se compara con las direcciones de los routers y se ejecutan aquellos que concuerden. Es una forma do rutear solicitudes a funciones con-troladoras que se encargan de accesar la base de datos y devolver la respueta. Por ejemplo:
14 2 Antecedentes
// Solo es llamado si la direcci´on comienza con /foo router.use(’/foo’, function(req, res, next) {
// Llama al siguiente router next();
});
// Siempre es llamado
router.use(function(req, res, next) { res.send(’Hello World’);
});
En este ejemplo el primer router solo es llamado cuando se solicita /foo al servidor. Tiene acceso a los objetos req, res y next. Cuando llama a next, se pasa a ejecutar el siguiente router para esa solicitud.
El segundo router del ejemplo no recibe una direcci´on, por lo que es llamado siempre. Este finaliza el ciclo de solicitud-respuesta al devolver una respuesta HTTP, en este caso con el texto ”Hello World”. En lugar de texto plano, el router podr´ıa devolver, por ejemplo, una p´agina HTML haciendo uso de vistas de Express. Antes de hacerlo podr´ıa acceder a la base de datos para solicitar objetos (Express, 2014).
El concepto de vista es importante y com´un a otros Frameworks MVC. Una vista es un archivo que genera el c´odigo HTML que es finalmente devuelto al navegador. Por ejemplo, un router que devuelve la vista de la p´agina principal de una aplicaci´on es:
router.get(’/’, function(req, res) { res.render(’index’, { title: ’My App’ }); }
En Express, el archivo index es solicitado del directorio de vistas de la aplicaci´on, el par´ametro title es pasado y es interpretado por el motor deno-minado Jade. Jade es un motor de generaci´on de plantillas que genera c´odigo HTML a partir de una sint´axis m´as sencilla, pudiendo insertar valores e iterar por vectores con facilidad. La funci´on render se encarga de generar la sali-da HTML y devolverla en la respuesta. En Express las plantillas pueden ser escritas directamente en HTML. Sin embargo, Jade ofrece mayor agilidad y velocidad. Tambi´en es un proyecto de acceso libre y c´odigo abierto desarrollado para Node.js en general(Lindesay, 2014).
La estructura de archivos de Express, que obedece a lo explicado anterior-mente, es la siguiente:
-MyApp
2.3. APIs de Mapeo y Generaci´on de Mapas de Intensidad 15
-node_modules M´odulos de NodeJS usados por la aplicaci´on -public Directorio p´ublico del servidor
-fonts Archivos de fuentes que utiliza la aplicaci´on -images Im´agenes utilizadas en la aplicaci´on
-javascripts Scripts JS que utiliza la aplicaci´on -stylesheets Archivos CSS que utiliza la aplicaci´on -routes Routers y controladores de Express
Generalmente se escribe un router por archivo -views Vistas o plantillas en Jade, HTML plano u otros app.js Archivo de inicializaci´on de la aplicaci´on package.json Informaci´on general y dependencias
2.3
APIs de Mapeo y Generaci´
on de Mapas de
Intensidad
Los principales servicios de mapeo, como el conocido Google Maps, ofrecen interfaces de programaci´on de aplicaciones (APIs) que permiten desde la vi-sualizaci´on de datos geoespaciales hasta la creaci´on de aplicaciones basadas en ubicaci´on. La visualizaci´on de datos puede abarcar desde la colocaci´on de marcadores hasta la creaci´on autom´atica de mapas de calor (heatmaps) o de intensidad a partir de coordenadas o puntos individuales. Al momento de desa-rrollar el proyecto, la API de generaci´on de mapas m´as completa, que adem´as inclu´ıa generaci´on de mapas de calor, era Google Maps API V3, que se datalla m´as adelante. Tambi´en se consider´o el servicio OpenStreetMap para desplegar el mapa y OpenLayers para generar el mapa de intensidad.
OpenStreetMap - OpenLayers
OpenStreetMap es un servicio de mapas mantenido por colaboradores alrede-dor del mundo, a partir de conocimiento y fuentes de datos locales. Existen diferentes APIs de terceros que se integran con OpenStreetMap para embeber mapas en sitios web y aplicaciones y a˜nadir capas como mapas de intensidad y de calor.
Una de las APIs m´as populares es OpenLayers 3, que permite a˜nadir una capa de mapa de calor ol.layer.Heatmap, con opciones para configurar la resoluci´on, opacidad y peso relativo de los puntos. La herramienta es desarro-llada en Javascript y la generaci´on se realiza en el navegador, por lo que es similar a Google Maps API en cuanto a sus ventajas. (OpenLayers, 2014)
16 2 Antecedentes
Figura 2.1: Mapa de calor creado con Google Maps API
Google Maps API
Siendo el principal servicio de mapas en l´ınea, Google Maps posee una API con caracter´ısticas suficientes para la mayor´ıa de aplicaciones. Entre las principales caracter´ısticas de inter´es de Google Maps API v3 (´ultima versi´on a la fecha) se encuentran:
• Carga asincr´onica que evita bloquear la aplicaci´on web.
• Permite modificar la interfaz por defecto, y a˜nadir elementos personali-zados.
• Creaci´on de mapas de calor (heatmaps) a partir de un grupo de coorde-nadas, con radios, opacidades y colores personalizables, como muestra la figura 2.1.
• Posibilidad de colocar informaci´on, marcadores e im´agenes sobre el ma-pa, adem´as de control b´asico sobre posici´on del mapa, nivel de zoom, entre otros.
2.4. Medici´on de Se˜nal Celular 17
Figura 2.2: Modelo b´asico de un sistema de transmisi´on por radiofrecuencia (Debus, 2006).
2.4
Medici´
on de Se˜
nal Celular
Nivel de Se˜nal
El nivel de se˜nal celular es medido tradicionalmente en Watts o dBm (decibe-lios - milliwatt), es decir, una medida de potencia. A este valor tambi´en se le llama RSSI (Received Signal Strength Indicator.
Una medici´on en dBm puede ser directamente convertida a un nivel lla-mado ASU (Arbitrary Strength Unit ) y viceversa. El nivel ASU es utilizado en software m´ovil y reportado por los sistemas operativos m´oviles como Android (Android, 2014). La ecuaci´on de conversi´on entre dBm y ASU var´ıa seg´un la tecnolog´ıa. Para GSM, por ejemplo, se obtiene como (ETSI, 2010).
ASU = dBm − dBmmin
2 =
dBm + 113
2 (2.1)
Modelos de P´erdidas por Propagaci´on
Existen diversos modelos matem´aticos que son utilizados por los operadores celulares para, desde la determinaci´on de la posici´on de las torres celulares, hasta la generaci´on de sus mapas de cobertura. Estos modelos permiten de-terminar, a partir de la potencia de transmisi´on de la antena, una distancia te´orica de cobertura, a la cu´al se provee una intensidad suficiente para permitir la comunicaci´on con los dispositivos m´oviles.
Un sistema de transmisi´on por radiofrecuencia puede verse, de manera sencilla, como en el diagrama de la figura 2.2.
En todo momento, la intensidad de se˜nal recibida por un dispositivo m´ovil est´a dada por la ecuaci´on 2.2.
R = Pt+ Gtot− L (2.2)
18 2 Antecedentes
Figura 2.3: Variables tomadas en cuenta por un modelo de transmisi´on por radiofrecuencia en un ´area urbana (Debus, 2006).
• Pt es la potencia del transmisor, en dBm. • Gtot es la ganancia total de las antenas, en dB. • L son las p´erdidas de transmisi´on, en dB.
Las p´erdidas son el factor m´as significativo en esta ecuaci´on, por lo mode-larlas ha sido de especial inter´es. A pesar de que depende de factores conocidos como la frecuencia, que es la misma para toda la red, tambi´en depende de otros como la altura de las antenas, la posici´on del receptor, interferencia y obst´aculos, entre otros.
El modelo te´orico m´as simple es el de p´erdidas de propagaci´on en el espacio vac´ıo (Free Space Path Loss) dado por la ecuaci´on 2.3.
L = 32,45 + 20log(dkm) + 20log(fM Hz) (2.3)
Sin embargo, de acuerdo a Debus (2006), este modelo es limitado e inexacto en la determinaci´on pr´actica de p´erdidas. Los modelos utilizados en la pr´actica toman en cuenta variables como la densidad de edificios, con constantes que var´ıan de acuerdo a si se trata de un ´area urbana o rural. En general la separaci´on y la potencia de las torres es mayor en ´areas rurales. Las variables que toman en cuenta algunos de los modelos m´as avanzados se muestran en la figura 2.3.
Las variables que pueden considerar estos modelos son: • hb, la altura de la antena sobre el nivel del suelo. • hm, altura de la antena m´ovil.
2.4. Medici´on de Se˜nal Celular 19
Figura 2.4: Constantes y variables del modelo de p´erdidas de Hata, que de-penden de la geograf´ıa y desarrollo de la zona (Debus, 2006).
• hB, altura de los edificios de la zona.
• b, la separaci´on entre edificios.
• w, el ancho de las calles o separaci´on entre edificios.
Un reconocido modelo usado ampliamente en la industria es el modelo de Hata, que se basa en extensivas mediciones experimentales en ´areas rurales y urbanas. Se trata en realidad de cuatro modelos, para ´areas abiertas, subur-banas, peque˜nas ciudades y grandes ciudades. La f´ormula general del modelo de Hata est´a dada por la ecuaci´on 2.4.
L = 69,55+26,16log(fM Hz)−13,82log(hb)−a(hm)+[44,9−6,55log(hb)]log(dkm)−K
(2.4) donde a(hm) y K son las constantes de la tabla de la figura 2.4, que
dependen del tipo de ambiente.
Debus (2006) muestra un estudio comparativo de siete diferentes modelos de p´erdidas utilizando valores t´ıpicos para evaluar las diferencias entre cada uno de los modelos. Para una misma potencia de transmisi´on Pt = 39dBm,
ganancias totales Gtot = 7,5dB, intensidad de se˜nal recibida R = −95dBm,
frecuencia f = 2350M Hz, altura de antena transmisora hb = 8m, y altura de
receptor hm = 1m.
Los resultados, mostrados en la table 2.1 indican enormes discrepancias entre los modelos. Debus (2006) resalta la importancia de utilizar mediciones de campo para determinar cu´al de los modelos se ajusta m´as al ambiente de trabajo. Los modelos de propagaci´on por s´ı solos est´an lejos de proveer una imagen clara de los rangos de transimisi´on efectivos, especialmente los que no toman en cuenta la densidad y altuora de las edificaciones y antenas como Free Space Path Loss.
20 2 Antecedentes
Cuadro 2.1: Alcance en metros de una misma torre celular seg´un diferentes modelos de p´erdidas.
Modelo de p´erdidas Alcance en metros Free-Space 121000
WIM LOS 16200 Hata - Zona abierta 5300 Hata - Zona suburbana 1600 WIM NLOS 820 Hata Ciudad 740
3
Desarrollo de la aplicaci´
on
3.1
Elecci´
on de la plataforma de desarrollo
Sistemas de base de datos
En la elecci´on del sistema de base de datos se deben tomar en cuenta varios as-pectos esenciales como el volumen de los datos manejar (longitud de las tablas y tasa de inserci´on/solicitud), los tipos de datos a almacenar, la disponibilidad de funciones que faciliten el manejo de los datos, y la necesidad o no de una base de datos relacional.
Volumen de Datos
El software a implementar debe ser capaz de almacenar y procesar grandes cantidades de datos de localizaci´on y nivel de se˜nal, entre otros. Debido a que cada dispositivo que utilice la aplicaci´on enviar´a datos con una frecuencia ajustable por el usuario, el flujo de datos que debe soportar el servidor es desconocido.
Por ejemplo, se puede considerar un usuario que env´ıa su localizaci´on cada minuto durante una hora diaria (tiempo en que se desplaza) y cada media hora durante el resto del d´ıa. Se tiene que el usuario env´ıa 106 datos diarios, lo que equivale a cerca de 39 000 datos anuales. Si se llegan a tener suficientes usuarios, puede ser necesario manejar millones de datos en pocos meses.
Se requiere por lo tanto un sistema de bases de datos con buen rendimiento en tablas grandes. El c´alculo es aproximado y no toma en cuenta el filtrado de los datos para evitar datos duplicados o muy similares. No todos los datos enviados deben necesariamente ser almacenados. Sin embargo, es necesaria una base de datos r´apida con capacidad para manejar millones de datos en una misma tabla sin que esto afecte la velocidad de la aplicaci´on.
Bases de Datos Relacional o No Relacional
Dadas las ventajas y desventajas de los esquemas relacionales, siendo MySQL el principal exponentes, y de los esquemas no relaciones como MongoDB, se decidi´o que una base de datos no relacional cumpl´ıa con lo necesario para el desarrollo porque:
22 3 Desarrollo de la aplicaci´on
1. Las mediciones son an´onimas y no est´aran relacionadas con un disposi-tivo o usuario en particular. El hecho de no contar con uniones de tablas no afecta el funcionamiento general de la aplicaci´on. Adem´as, el efecto equivalente, si fuera necesario, se puede obtener mediante dos solicitudes a una base de datos no relacional.
2. La flexibilidad que ofrece una base de datos no relacional como Mon-goDB, al no contar con el concepto de columnas, resulta muy ´util para el dise˜no de la aplicaci´on, dado que los par´ametros de configuraci´on y texto de la interfaz se pueden almacenar de forma muy conveniente en la base de datos.
Tipos de Dato y Funciones Espaciales
Otro aspecto a considerar al elegir la base de datos es la disponibilidad de funciones espaciales que faciliten el despliegue y procesamiento de los datos enviados por lo usuarios. Se busca por lo tanto una base de datos que almacene coordenadas espaciales nativamente y que cuente con funciones espaciales, como por ejemplo, seleccionar datos dentro de un pol´ıgono o c´ırculo.
Este tipo de funciones nativas aceleran considerablemente la aplicaci´on debido a que no requieren procesar potencialmente millones de datos usando PHP o Javascript para conocer, por ejemplo, si un punto se encuentra dentro del pol´ıgono de b´usqueda. Ejecutar la b´usqueda directamente en la base de datos utiliza menos recursos, aumenta la velocidad de la aplicaci´on web y simplifica la programaci´on. Algunas funciones ´utiles son:
• B´usqueda por cercan´ıa a una coordenada. • B´usqueda de datos en una reg´ı´on del espacio.
• Promedidado o combinaci´on de datos basado en la posici´on y el valor de una columna.
• Eliminaci´on de datos espacialmente cercanos.
MongoDB como base de datos
Basado en todos los criterios anteriores se eligi´o MongoDB como sistema de bases de datos para la aplicaci´on. En resumen, se consider´o que MongoDB se adec´ua a las necesidades del proyecto porque:
1. Tiene la capacidad de manejar el volumen de datos que requiere la apli-caci´on y ofrece las suficientes opciones de escalabilidad para garantizar el funcionamiento a largo plazo.
3.2. Dise˜no de la base de datos 23
2. Ofrece una enorme flexibilidad mediante un dise˜no no relacional en el que no existe el concepto de tabla y de columna, sino de objetos con diferentes atributos.
3. No es necesario contar con la funcionalidad de uniones de tablas propia de esquemas relacionales.
4. Ofrece las funciones y tipos de dato espaciales que requiere una aplica-ci´on para manejar coordenadas. Las funciones de b´usqueda por cercan´ıa o por pertenencia un pol´ıgono aceleran la b´usqueda de datos geoespa-ciales.
5. Se integra facilmente con Node.js, dado que ambos manejan objetos JSON, lo que simplifica el proceso de inserci´on y solicitud de datos.
3.2
Dise˜
no de la base de datos
Se establecieron las caracter´ısticas principales de la base de datos a dise˜nar:
• Se debe asociar a cada dato con un usuario, con el fin de identificar trayectorias. Sin embargo, como los datos son an´onimos, no es necesario tener una tabla de usuarios en un principio. Se utiliza por lo tanto un ID de usuario enviado por el dispositivo para identificar los datos. • Para cada dato se deber´an almacenar las coordenadas de la medici´on, y
el momento exacto de la misma.
• Se deben almacenar las m´etricas de nivel de se˜nal celular, asociadas a una latitud y longitud. Las m´etricas provistas por los dispositivos pueden ser distintas en escala y significado para tecnolog´ıa 2G (GSM), 3G (WCDMA) y 4G (LTE).
Se utiliza el API de Android como referencia para las m´etricas provistas debido a que se trata del sistema operativo m´ovil m´as utilizado. Se busca almacenar todas las m´etricas disponibles en el API de Android con el fin de tener informaci´on potencialmente ´util para el an´alisis.
• Adem´as de las m´etricas de se˜nal, se almacena la velocidad de la conexi´on de datos del usuario, si esta se encuentra activa, con el fin de analizar las velocidades y disponibilidades del internet celular.
Cada dato, entendi´endose como cada env´ıo que realiza un dispositivo clien-te, consta de las lecturas de coordenadas GPS (Global Positioning System) y
24 3 Desarrollo de la aplicaci´on
niveles de se˜nal del tel´efono, en la tecnolog´ıa que utilice. Los datos se almace-nan en una tabla distinta para cada tecnolog´ıa: GSM, WCDMA y LTE. Por lo tanto, son necesarias cuatro tablas, cada una con las siguientes columnas:
• ID de dato. Columna que idenfica cada dato individualmente. • Tiempo. Timestamp indicando el momento de la toma del dato.
• ID de usuario o de dispositivo. La aplicaci´on m´ovil se encarga de generar-lo, ya sea a partir de un identificador ´unico del dispositivo, aleatoriamen-te, o a partir de un nombre de usuario. Depende de la implementaci´on de la aplicaci´on m´ovil.
• Latitud y longitud. Se almacenan en objetos GeoJSON para tener acceso a las funciones de geolocalizaci´on de la base de datos. Para ello se crea un ´ındice 2dsphere en esta columna.
• M´etricas de nivel de se˜nal del dispositivo. Se utilizan como referencia las m´etricas disponibles en el API del sistema operativo Android, las cuales var´ıan de acuerdo a la tecnolog´ıa celular. Las m´etricas disponibles para cada tipo de se˜nal se detallan en la siguiente secci´on.
M´etricas de Cobertura
Las APIs de sistemas operativos m´oviles como Android ponen a disposici´on de las aplicaciones una serie de mediciones de fuerza y calidad de se˜nal para los distintos tipos de redes celulares. Estas constituyen toda la informaci´on que es posible obtener y analizar de los usuarios de la aplicaci´on m´ovil y que se almacenan en la base de datos (Android, 2014).
M´etricas para CDMA
cdmaAsuLevel. El nivel de se˜nal se reporta en una escala de 0 a 97 para CDMA. El n´umero 99 indica un nivel desconocido.
cdmaDbm. El RSSI (Received Signal Strength Indication), una medici´on de la potencia total recibida por la antena, en dBm.
cdmaEcio. El nivel Ec/Io de la se˜nal CDMA. Es una indicaci´on de la calidad efectiva de la se˜nal CDMA, en dB*10.
networkId. El identificador de la red, de 16 bits, permite identificar el ope-rador celular. Identifica una red celular completa dentro de un pa´ıs, la red de Claro en Costa Rica, por ejemplo.
3.2. Dise˜no de la base de datos 25
systemId. N´umero que identifica una red m´as peque˜na dentro de la red ce-lular del operador.
baseStationId. El identificador de la torre, de 16 bits.
M´etricas para GSM
gsmAsuLevel. El nivel de se˜nal GSM se reporta en una escala de 0 a 31. 99 indica un nivel desconocido.
gsmDbm. La potencia de la se˜nal GSM detectada por la antena, en dBm. gsmMcc. Mobile Country Code, de 3 d´ıgitos decimales. Indica el pa´ıs. gsmMnc. Mobile Network Code, de 2 o 3 d´ıgitos. Se utiliza para identificar
el operador.
gsmLac. El LAC (Location Area Code) de 16 bits.
gsmCid. El CID (Cell Identity) de 16 bits, que identifica una celda GSM dentro de una Location Area.
M´etricas para WCDMA
wcdmaAsuLevel. El nivel de se˜nal se reporta en una escala de 0 a 31 para WCDMA. El n´umero 99 indica un nivel desconocido.
wcdmaDbm. El RSSI (Received Signal Strength Indication), una medici´on de la potencia total recibida por la antena, en dBm.
wcdmaMcc. Mobile Country Code, de 3 d´ıgitos decimales. Indica el pa´ıs. wcdmaMnc. Mobile Network Code, de 2 o 3 d´ıgitos. Se utiliza para identificar
el operador.
wcdmaLac. El LAC (Location Area Code) de 16 bits.
wcdmaCid. El UMTS CID (Cell Identity) de 28 bits, que identifica una celda dentro de una Location Area.
M´etricas para LTE
lteAsuLevel. El nivel de se˜nal se reporta en una escala de 0 a 97 para LTE. El n´umero 99 indica un nivel desconocido.
lteDbm. El RSSI (Received Signal Strength Indication), una medici´on de la potencia total recibida por la antena, en dBm.
26 3 Desarrollo de la aplicaci´on
lteMcc. Mobile Country Code, de 3 d´ıgitos decimales. Indica el pa´ıs.
lteMnc. Mobile Network Code, de 2 o 3 d´ıgitos. Se utiliza para identificar el operador.
lteTac. El TAC (Tracking Area Code) de 16 bits.
lteCi. El CID (Cell Identity) de 28 bits, que identifica una celda dentro de una Location Area.
Tablas de la Base de Datos
Aunque en MongoDB no existe el concepto de tablas sino el de colecciones de objetos anidados, en el caso de la aplicaci´on se trabaja con objetos con colecciones de objetos con las misma claves. El dise˜no de dichas claves, por lo tanto, se realiz´o de manera similar al de una base de datos SQL. Tomando en cuenta lo anterior, se utilizan cuatro colecciones, una por tecnolog´ıa celular. Estas mismas tablas almacenan la velocidad de datos en una clave dedicada. En esta secci´on se resumen el dise˜no de la base de datos en tablas que muestran los nombres espec´ıficos, tipos de dato y descripci´on de los atributos de los objetos a almacenar.
Los tipos de dato en MongoDB tambi´en son abiertos, es decir, no se es-pecifican a la hora de crear una colecci´on y distintos objetos pueden tener un tipo de dato diferente para la misma clave. Por lo tanto, el tipo de dato que se indica en las siguientes tablas es solamente para efectos de comprensi´on del dise˜no.
La tabla 3.1 muestra las claves de la tabla de mediciones CDMA. Adem´as de las m´etricas detalladas en la secci´on 3.2, se agrega la localizaci´on, iden-tificadores, fechas y la velocidad de datos. A pesar de que el dise˜no de esta tabla se incluye en el trabajo, no se implementaron los mapas de la tecnolog´ıa CDMA devido a que dicho servicio ya no se presta en el pa´ıs.
La tabla 3.2, por su parte, muestra las claves de la colecci´on de medicio-nes GSM. Las cuatro tablas son similares en la mayor´ıa de las entradas, sin embargo, los indicadores y los rangos de medici´on son distintos en algunas de ellas. La separaci´on permite agregar m´etricas adicionales exclusivas de una tecnolog´ıa sin alterar el dise˜no.
Las tablas 3.3 y 3.4 muestran las claves de las colecciones respectivas. El formato GeoJSON para puntos dados por coordenadas cartesianas es:
{
type: "Point",
coordinates: [long, lat] }
3.2. Dise˜no de la base de datos 27
Cuadro 3.1: Claves de la colecci´on cdmadata. Clave Tipo Descripci´on
id String ID de objeto. Se mantiene el autogenerado por MongoDB. Se utiliza para operaciones de actua-lizaci´on o borrado en que se requiere identificar el objeto.
cpid String Identificador del tel´efono celular. Este ID es ge-nerado por la aplicaci´on m´ovil.
loc Punto GeoJSON Objeto que contiene las coordenadas de la me-dici´on en formato GeoJSON.
date Fecha Fecha de toma del dato. Es recibida de la apli-caci´on m´ovil dado que indica la fecha de la me-dici´on, no la fecha de inserci´on.
insdate Fecha Fecha de inserci´on del dato.
minutes Entero Minutos transcurridos desde el inicio del d´ıa. Se usa para obtener mediciones por hora del d´ıa. dbm Decimal negativo El RSSI (Received Signal Strength Indication),
una medici´on de la potencia total recibida por la antena, en dBm.
ecio String / Decimal negativo El nivel Ec/Io de la se˜nal CDMA. Es una indi-caci´on de la calidad efectiva de la se˜nal CDMA, en dB*10.
nid String / Entero positivo El identificador de la red, de 16 bits, permite identificar el operador celular. Identifica una red celular completa dentro de un pa´ıs.
sid String / Entero positivo Identifica una red m´as peque˜na dentro de la red celular del operador. No es usado por la aplica-ci´on pero puede llegar a serlo.
bsid String / Entero positivo El identificador de la torre CDMA, de 16 bits. downspeed Decimal Positivo Velocidad de descarga del servicio m´ovil, en
by-tes por segundo.
upspeed Decimal Positivo Velocidad de descarga del servicio m´ovil, en by-tes por segundo.
weight Decimal Positivo Almacena el peso relativo de la medici´on, entre cero y uno. Se usa para asignar el peso del punto en Google Maps API.
28 3 Desarrollo de la aplicaci´on
Cuadro 3.2: Claves de la colecci´on gsmdata. Clave Tipo Descripci´on
id String ID de objeto. Se mantiene el autogenerado por MongoDB. Se utiliza para operaciones de actua-lizaci´on o borrado en que se requiere identificar el objeto.
cpid String Identificador del tel´efono celular. Este ID es ge-nerado por la aplicaci´on m´ovil.
loc Punto GeoJSON Objeto que contiene las coordenadas de la me-dici´on en formato GeoJSON.
date Fecha Fecha de toma del dato. Es recibida de la apli-caci´on m´ovil dado que indica la fecha de la me-dici´on, no la fecha de inserci´on.
insdate Fecha Fecha de inserci´on del dato.
minutes Entero Minutos transcurridos desde el inicio del d´ıa. Se usa para obtener mediciones por hora del d´ıa. dbm Decimal negativo Potencia de la se˜nal detectada por la antena
(RSSI), en dBm.
asu Decimal positivo Nivel de se˜nal, en la escala de 0 a 31.
mcc String / Entero positivo Mobile Country Code de 3 d´ıgitos. Indica el pa´ıs. mnc String / Entero positivo Mobile Network Code, de 2 o 3 d´ıgitos. Identifica
el operador.
lac String / Entero positivo El LAC (Location Area Code) de 16 bits. cid String / Entero positivo El CID (Cell Identity) de 16 bits, que identifica
una celda GSM en un ´area.
downspeed Decimal Positivo Velocidad de descarga del servicio m´ovil, en by-tes por segundo.
upspeed Decimal Positivo Velocidad de descarga del servicio m´ovil, en by-tes por segundo.
weight Decimal Positivo Almacena el peso relativo de la medici´on, entre cero y uno. Se usa para asignar el peso del punto en Google Maps API.
3.2. Dise˜no de la base de datos 29
Cuadro 3.3: Claves de la colecci´on wcdmadata. Clave Tipo Descripci´on
id String ID de objeto. Se mantiene el autogenerado por MongoDB. Se utiliza para operaciones de actua-lizaci´on o borrado en que se requiere identificar el objeto.
cpid String Identificador del tel´efono celular. Este ID es ge-nerado por la aplicaci´on m´ovil.
loc Punto GeoJSON Objeto que contiene las coordenadas de la me-dici´on en formato GeoJSON.
date Fecha Fecha de toma del dato. Es recibida de la apli-caci´on m´ovil dado que indica la fecha de la me-dici´on, no la fecha de inserci´on.
insdate Fecha Fecha de inserci´on del dato.
minutes Entero Minutos transcurridos desde el inicio del d´ıa. Se usa para obtener mediciones por hora del d´ıa. dbm Decimal negativo Potencia de la se˜nal detectada por la antena
(RSSI), en dBm.
asu Decimal positivo Nivel de se˜nal, en la escala de 0 a 31.
mcc String / Entero positivo Mobile Country Code de 3 d´ıgitos. Indica el pa´ıs. mnc String / Entero positivo Mobile Network Code, de 2 o 3 d´ıgitos. Se utiliza
para identificar el operador.
lac String / Entero positivo El LAC (Location Area Code) de 16 bits. cid String / Entero positivo El UMTS CID (Cell Identity) de 28 bits, que
identifica una celda dentro de una Location downspeed Decimal Positivo Velocidad de descarga del servicio m´ovil, en
by-tes por segundo.
upspeed Decimal Positivo Velocidad de descarga del servicio m´ovil, en by-tes por segundo.
weight Decimal Positivo Almacena el peso relativo de la medici´on, entre cero y uno. Se usa para asignar el peso del punto en Google Maps API.
30 3 Desarrollo de la aplicaci´on
Cuadro 3.4: Claves de la colecci´on ltedata. Clave Tipo Descripci´on
id String ID de objeto. Se mantiene el autogenerado por MongoDB. Se utiliza para operaciones de actua-lizaci´on o borrado en que se requiere identificar el objeto.
cpid String Identificador del tel´efono celular. Este ID es ge-nerado por la aplicaci´on m´ovil.
loc Punto GeoJSON Objeto que contiene las coordenadas de la me-dici´on en formato GeoJSON.
date Fecha Fecha de toma del dato. Es recibida de la apli-caci´on m´ovil dado que indica la fecha de la me-dici´on, no la fecha de inserci´on.
insdate Fecha Fecha de inserci´on del dato.
minutes Entero Minutos transcurridos desde el inicio del d´ıa. Se usa para obtener mediciones por hora del d´ıa. dbm Decimal negativo El RSSI (Received Signal Strength Indication),
una medici´on de la potencia total recibida por la antena, en dBm.
asu Decimal positivo Nivel de se˜nal, en la escala de 0 a 97.
mcc String / Entero positivo Mobile Country Code de 3 d´ıgitos. Indica el pa´ıs. mnc String / Entero positivo Mobile Network Code, de 2 o 3 d´ıgitos. Se utiliza
para identificar el operador.
tac String / Entero positivo El TAC (Tracking Area Code) de 16 bits. cid String / Entero positivo El CID (Cell Identity) de 28 bits, que identifica
una celda dentro de una Location Area.
downspeed Decimal Positivo Velocidad de descarga del servicio m´ovil, en by-tes por segundo.
upspeed Decimal Positivo Velocidad de descarga del servicio m´ovil, en by-tes por segundo.
weight Decimal Positivo Almacena el peso relativo de la medici´on, entre cero y uno. Se usa para asignar el peso del punto en Google Maps API.
3.3. Dise˜no de la Aplicaci´on Web 31
donde long y lat son las coordenadas de longitud y latitud, respetando el orden. Debido a que GeoJSON soporta otras formas geom´etricas, se debe especificar que se trata de un punto. Un ejemplo de una entrada u objeto de la colecci´on cdmadata es:
{ "_id" : ObjectId("54497c2e41d9dd283394e8ed"), "cpid" : "FK83J6NS", "loc" : { "type" : "Point", "coordinates" : [ -84.03254580646946, 9.92480524686183 ] }, "date" : ISODate("2014-11-13T06:40:36Z"), "insdate" : ISODate("2014-11-13T06:40:36Z"), "minutes" : 40, "dbm" : -92, "asu" : 20, "mcc" : 712, "mnc" : 2, "lac" : 8343, "cid" : 2394, "downspeed" : 604649.0774024278, "upspeed" : 106021.56929671764, "weight": 1 }
Esta entrada fue generada aleatoriamente por un script de inserci´on pero ejemplifica los datos reales esperados.
3.3
Dise˜
no de la Aplicaci´
on Web
La aplicaci´on web est´a dirigida al p´ublico en general y busca proveer una interfaz sencilla e intuitiva para visualizar los datos de cobertura y movimiento que se obtengan de los usuarios. Se establecieron los siguientos requerimientos y caracter´ısticas necesarias:
• Visualizaci´on de mapas de calor de cobertura celular generado en tiempo real, con la posibilidad de seleccionar una o varias tecnolog´ıas celulares y uno o m´as operadores celulares. Los datos son tomados de la base de datos de acuerdo a este criterio y el heatmap es generado y mostrado al usuario.
32 3 Desarrollo de la aplicaci´on
• Generaci´on de mapas de calor de velocidad de la conexi´on de datos, por cada tecnolog´ıa y por cada operador. En lugar de mostrar el nivel de se˜nal se toma la velocidad de descarga para la generaci´on del heatmap. • Selecci´on del operador celular. Se muestra la cobertura de un operador
celular espec´ıfico.
• Interfaz sumamente sencilla e intuitiva con soporte para dispositivos m´oviles. El sitio debe ser accesible y usable dado que est´a dirigido al p´ublico en general.
• Creaci´on de secciones con informaci´on sobre el proyecto y sobre la des-carga de la aplicaci´on m´ovil. Estas deben informar al usuario sobre la iniciativa y la forma en que funciona el sistema.
• La aplicaci´on debe incluir la interfaz de comunicaci´on con la aplicaci´on m´ovil, que se encargue de recibir, verificar e insertar los datos enviados por los usuarios mediante HTTP.
Estructura General
La aplicaci´on se desarroll´o haciendo uso del framework Express para NodeJS. Express utiliza una arquitectura MVC (Modelo - Vista - Controlador) para facilitar el desarrollo de aplicaciones web tradicionales a partir de NodeJS. Se hizo uso de la herramienta Jade para crear las plantillas de la aplicaci´on. Para los estilos se utiliz´o el lenguaje de hojas de estilos CSS sin preprocesador y se hizo uso de jQuery en el desarrollo de la interfaz gr´afica de usuario (GUI).
Se sigui´o la estructura MVC y la jerarqu´ıa de archivos de Express para el desarrollo de la aplicaci´on, agregando los archivos y directorios necesarios para el desarrollo:
-sgnmp
-bin Binarios generados por Express. www
-data Archivos de la base de datos de MongoDB -node_modules M´odulos de NodeJS usados por la aplicaci´on -public Directorio p´ublico del servidor
-fonts Archivos de fuentes que utiliza la GUI -images Im´agenes utilizadas en la GUI
-javascripts Scripts JS que utiliza la GUI -stylesheets Archivos CSS que utiliza la GUI favicon.ico ´Icono de la aplicaci´on
-routes Routers y controladores de Express
3.3. Dise˜no de la Aplicaci´on Web 33
mapdata.js Ruta POST que devuelve mediciones
readings.js Ruta a archivos de comunicaci´on con la App m´ovil -views Vistas o plantillas
error.jade P´agina de error index.jade P´agina principal layout.jade Plantilla principal
sendReading.jade Formulario de env´ıo de datos de prueba app.js Archivo de inicializaci´on de la aplicaci´on package.json Informaci´on general y dependencias
Rutas y Controladores
Las rutas y controladores constituyen el n´ucleo de la aplicaci´on y son escencia-les para comprender su funcionamiento. Se establecieron tres rutas principaescencia-les, para los tipos de solicitud que maneja la aplicaci´on. Los controladores que ma-nejan la l´ogica del programa se escribieron en el mismo archivo de rutas. Segui-damente se detalla el funcionamiento de cada una de las rutas/controladores, que constituyen el n´ucleo de la aplicaci´on:
index.js Devuelve la p´agina principal. La aplicaci´on completa es devuelta en una sola solicitud. La vista devuelta es index.jade. El controlador obtiene de la base de datos algunos par´ametros de configuraci´on como los nombres de las tecnolog´ıas celulares y operadores (que no se almacenan en las colecciones de mediciones), as´ı como textos de la interfaz y los pasa a la plantilla de Jade.
mapdata.js Se encarga de responder las solicitudes AJAX que realiza la apli-caci´on. Conforme el usuario se desplaza en el mapa se solicitan medi-ciones de la base de datos para generar el mapa de calor. mapdata.js recibe por medio de una solicitud HTTP tipo GET los par´ametros que selecciona el usuario:
mapType Indica si es un mapa de cobertura o de velocidad de conexi´on de datos.
mapTime Array con dos valores en el intervalo de cero a 1440, que indican el rango inicial y final de minutos entre los seleccionar los valores.
mapTechs Indica las tecnolog´ıas celulares seleccionades. mapProvs Indica los operadores celulares seleccionados. pointLimit M´aximo n´umero de puntos a devolver.
northEast Coordenadas del punto noroeste del rect´angulo dentro del cu´al buscar mediciones.
34 3 Desarrollo de la aplicaci´on
southWest Coordenadas del punto sureste de la ventana de selecci´on de mediciones.
readings.js Crea dos rutas. La primera es readings/post, el controlador en-cargado de recibir por medio de solicitudes tipo POST las mediciones enviadas por la aplicaci´on m´ovil, o cualquier otro medio. Se encarga de validar los datos e insertarlos a la base de datos. Realiza preprocesa-miento de los datos para el c´alculo de variables como minutes. El script valida cada par´ametro del objeto recibido. Si se produce alg´un error de validaci´on, este es devuelto en la respuesta, junto con un c´odigo de error. El objetivo es asegurar la calidad de los datos que se almacenan.
La segunda ruta, llamada readings/send devuelve la vista sendReading.jade, que muestra un formulario pre-llenado que permite enviar datos a readings/post, con el fin de probar dicho script.
Generaci´on de Datos de Prueba
Para la generaci´on de datos aleatorios se cre´o un script, independiente del resto de la aplicaci´on, que se conecta a la base de datos y popula una de las colecciones con datos generados de manera aleatoria. Se definieron varios pa-r´ametros para especificar la cantidad y densidad de las mediciones. Se definen varias ´areas, cada una con varios puntos.
El algoritmo funciona de la siguiente manera:
1. Se mueve una distancia m´axima dAreas horizontal y verticalmente res-pecto al ´ultimo punto generado. El ´angulo y la distancia de separaci´on son aleatorios.
2. Genera una cantidad nPoints de puntos, movi´endose una distancia m´ a-xima dPoints respecto al punto anterior en cada iteraci´on. Cada punto tiene un peso m´aximo (proporcional al nivel de se˜nal) maxWeight y un ti-mestamp, velocidad de datos (upspeed y downspeed), y operador celular (mnc) aleatorios.
3. Repite el proceso, movi´endose a una nueva zona y generando nPoints puntos. Termina cuando se ha movido a una cantidad nAreas de zonas. 4. Repite el proceso para cada una de las cuatro colecciones, una por cada
tecnolog´ıa celular.
La cantidad total de datos generados en cada colecci´on es por lo tanto el producto de nAreas por nPoints. El algoritmo de generaci´on de datos GSM, en Javascript es el siguiente:
3.3. Dise˜no de la Aplicaci´on Web 35 var heatmapData = []; var previous = [-84.0512, 9.9368]; var dPoints = 0.01; var dAreas = 0.05; var nPoints = 64; var nAreas = 16; var tt, date; var tables = [’gsm’]; for(var h = 0; h < tables.length; h++) { var objects = [];
for (var i = 0; i < nAreas; i++) { previous = [ previous[0] + dAreas*Math.cos(Math.random()*2*Math.PI), previous[1] + dAreas*Math.cos(Math.random()*2*Math.PI) ]; for(var j = 0; j < nPoints; j++) { previous = [ previous[0] + dPoints*Math.cos(Math.random()*2*Math.PI), previous[1] + dPoints*Math.cos(Math.random()*2*Math.PI) ]; tt = 1413416539 + Math.round(Math.random()*2629740); obj = { tech: tables[h], data: { cpid : ’XXXX’, long: previous[0], lat: previous[1], timestamp: tt, dbm: -85 - Math.round(20*Math.random()), asu: 31*Math.random(); mcc: 712, mnc: Math.ceil(3*Math.random()), lac: 8343, cid: 2394, downspeed: 1000000*Math.random(), upspeed: 400000*Math.random() } }; request.post( ’http://localhost:3000/readings/post’,
