Agradecimientos - rua.ua.es · importar la distancia, me parecía casi cosa de magia. Ahora,...
Transcript of Agradecimientos - rua.ua.es · importar la distancia, me parecía casi cosa de magia. Ahora,...
Trabajo fin de grado
1 Jorge Prieto Martin
Agradecimientos
A mi tutor, Jose Vicente Berna por guiarme
siempre en la dirección correcta y a mi familia y
amigos por apoyarme y creer en mi durante todos
los años de mi carrera.
A todos, gracias.
Trabajo fin de grado
2 Jorge Prieto Martin
Contenido 1. Motivación, justificación, objetivo general ................................................. 12
2. Introducción ................................................................................................. 15
2.1 Problema ................................................................................................ 15
3. Estado del arte ............................................................................................. 19
3.1 Soluciones originarias ............................................................................ 19
3.1.1 P2P ................................................................................................... 20
3.1.2 Ad-Hoc y Mobile Ad-Hoc networks (MANET) ............................. 20
3.1.3 Red de Área Personal (WPAN) / Bluetooth .................................... 21
3.2 Soluciones de apoyo .............................................................................. 22
3.2.1 Wifi-Direct ...................................................................................... 22
3.3 Herramientas paralelas/ futuras ............................................................. 23
3.3.1 D2D ................................................................................................. 23
3.3.2 System for broadcasting geolocation information in emergency
situations via Wi-Fi interfaces of smartphones ........................................ 24
3.3.3 Alerta de emergencia ....................................................................... 25
4. Objetivos ..................................................................................................... 27
4.1 Identificación del problema ................................................................... 27
4.2 Objetivo principal .................................................................................. 27
4.3 Sub-objetivos ......................................................................................... 27
5. Metodología ................................................................................................. 29
5.1 Principios ............................................................................................... 29
5.2 Iteraciones del desarrollo ....................................................................... 31
Trabajo fin de grado
3 Jorge Prieto Martin
6. Análisis y especificación ............................................................................. 33
6.1 Propósito ................................................................................................ 33
6.2 Alcance .................................................................................................. 33
6.3 Perspectiva del producto ........................................................................ 34
6.4 Características del usuario ..................................................................... 34
6.5 Restricciones .......................................................................................... 36
6.6 Atenciones y dependencias .................................................................... 37
6.7 Requerimientos funcionales ................................................................... 37
6.8 Requisitos del banco de datos lógicos ................................................... 42
6.9 Funciones ............................................................................................... 43
6.9.1 Validación de las entradas y salidas del sistema ............................. 43
6.9.2 Secuencia de las operaciones .......................................................... 44
6.10 Requisitos no funcionales .................................................................... 47
6.10.1 Número de conexiones soportados ................................................ 47
6.10.2 Número de terminales soportados ................................................. 47
6.10.3 Cantidad y tipo de información manejada .................................... 47
6.11 Atributos del software del sistema ....................................................... 48
6.11.1 Fiabilidad ....................................................................................... 48
6.11.2 Disponibilidad ............................................................................... 48
6.11.3 Seguridad ....................................................................................... 48
6.11.4 Mantenimiento ............................................................................... 49
6.11.5 Portabilidad.................................................................................... 49
6.12 Organizar los requisitos específicos .................................................... 50
7. Presupuesto, estimaciones y planificación .................................................. 51
Trabajo fin de grado
4 Jorge Prieto Martin
7.1 Planificación semanal ............................................................................ 51
8. Diseño del sistema ....................................................................................... 52
8.1 Notas generales ...................................................................................... 52
8.2 Fase 1ª – Diseño básico de comunicación cliente-servidor-cliente ....... 53
8.2.1 Funcionamiento ............................................................................... 53
8.3 Fase 2ª – Diseño básico de comunicación cliente-cliente ..................... 55
8.3 Fase 3ª – Diseño básico de comunicación cliente-cliente en un entorno
desconectado ................................................................................................ 56
8.4 Diseño de un mensaje ............................................................................ 58
8.5 Área de actuación ................................................................................... 59
8.6 Diseño del usuario administrador .......................................................... 60
8.7 Diseño del usuario generador ................................................................ 61
8.8 Diseño del usuario consumidor ............................................................. 62
8.9 Seguridad ............................................................................................... 63
8.9.1 Seguridad en el acceso al sistema y generación del mensaje .......... 63
8.9.2 Seguridad en la creación y envío de un mensaje en entorno offline
.................................................................................................................. 67
8.9.3 Seguridad en las conexiones entre dispositivos .............................. 68
8.10 Emulaciones del sistema ...................................................................... 69
9. Implementación de la propuesta .................................................................. 72
9.1 Implementación en el lado del servidor ................................................. 72
9.2 Implementación en el lado del cliente ................................................... 74
9.2.1 Fase de geolocalización ................................................................... 74
9.2.2 Fase de creación de grupo y servicio .............................................. 74
Trabajo fin de grado
5 Jorge Prieto Martin
9.2.3 Fase de búsqueda de servicio .......................................................... 76
9.2.4 Fase de conexión e intercambio de datos ........................................ 77
9.2.5 Fase de reenvío ................................................................................ 77
9.2.6 Fase de desconexión ........................................................................ 78
9.3 Iteraciones .............................................................................................. 78
9.3.1 Iteración 0 – Testeo del sistema inicial ........................................... 79
9.3.2 Iteración 1 – API ............................................................................. 80
9.3.3 Iteración 2 – Llamada de la API desde la APP ............................... 83
9.3.4 Iteración 3 – Creación de grupo y servicios .................................... 87
9.3.5 Iteración 4 – Conexión entre dispositivos ....................................... 90
9.3.6 Iteración 5 – Envío de los mensajes ................................................ 95
9.3.6 Iteración 6 – Reenvío de los mensajes ............................................ 99
9.3.7 Iteración 7 – Creación de mensajes ............................................... 104
9.3.7 Iteración 8 – Creación y envío de mensajes offline ...................... 109
9.3.7 Iteración 9 – Implantación de mejoras y emulador ....................... 115
10. Pruebas y validación ................................................................................ 118
10.1 Pruebas globales del sistema ............................................................. 118
10.1.1 Pruebas con dos dispositivos .......................................................... 119
10.1.2 Pruebas con tres dispositivos .......................................................... 120
10.1.2 Pruebas con cuatro dispositivos ...................................................... 122
10.1.3 Conclusiones ............................................................................... 123
10.2 Pruebas del emulador del sistema ...................................................... 124
10.3 Consumo de batería ........................................................................... 129
10.4 Dificultades ........................................................................................ 131
Trabajo fin de grado
6 Jorge Prieto Martin
10.4.1 Problema de actualización de un mensaje ................................... 131
10.4.1 Problema de recibo de servicios .................................................. 131
10.4.2 Conclusiones ............................................................................... 133
11. Conclusiones y trabajo futuro ................................................................. 133
11.1 Implementaciones futuras .................................................................. 133
11.2 Monetización del proyecto................................................................. 137
11.3 Conclusión final y futuro del proyecto .............................................. 138
Apéndice ........................................................................................................ 139
12.1 Uso recomendado de las zonas .......................................................... 139
12.2 Material extra ..................................................................................... 141
Bibliografía .................................................................................................... 141
Trabajo fin de grado
7 Jorge Prieto Martin
Índice de ilustraciones
Ilustración 1 - Modelo entidad relación de la base de datos. Fuente propia. .. 43
Ilustración 2 - Caso de uso del sistema servidor. Fuente propia ..................... 53
Ilustración 3 - Esquema de la comunicación cliente-servidor-cliente. Fuente
propia. .............................................................................................................. 54
Ilustración 4 - Esquema de la transmisión de un mensaje. Fuente propia. ..... 55
Ilustración 5 - Esquema de la creación y transmisión de un mensaje cuando no
existe conexión a internet en el área. Fuente propia. ...................................... 56
Ilustración 6 - Esquema de la creación y transmisión de un mensaje sin
conexión y sin acceso a las coordenadas. Fuente propia. ............................... 57
Ilustración 7 - Esquema del contenido de un mensaje. Fuente propia. ........... 59
Ilustración 8 - Esquema de la relación de las zonas y los usuarios. Fuente
propia. .............................................................................................................. 61
Ilustración 9 - Diagrama de flujo del sistema básico. Fuente propia. ............. 63
Ilustración 10 - Diagrama del sistema de seguridad al enviar un mensaje al
servidor. Fuente Propia ................................................................................... 66
Ilustración 11 - Diagrama de descifrado de la información del Access Point.69
Ilustración 12 - Respuesta de una petición al servidor .................................... 73
Ilustración 13 - Diagrama de la arquitectura de la consulta de mensajes. Fuente
propia. .............................................................................................................. 73
Ilustración 14 - Captura con la información del Access Point. Fuente propia.
......................................................................................................................... 75
Ilustración 15 - Diagrama de las fases y sus transiciones. Fuente propia. ...... 78
Ilustración 16 - Captura de la aplicación de prueba. Fuente propia. ............... 80
Ilustración 17 - Captura de las entidades alarma. Fuente propia .................... 82
Ilustración 18 - Mapa del centro de Alicante. Fuente: Google Maps ............. 82
Ilustración 19 - Respuesta JSON del servidor................................................. 83
Ilustración 20 - Captura de pantalla con los mensajes de información sobre el
gps. Fuente propia. .......................................................................................... 86
Trabajo fin de grado
8 Jorge Prieto Martin
Ilustración 21 - Captura de pantalla con el mensaje recibido en formato JSON
y el texto de la alerta. Fuente propia. .............................................................. 87
Ilustración 22 - Captura de pantalla con la información del servicio activado.
Fuente propia. .................................................................................................. 89
Ilustración 23 - Captura de pantalla de un usuario consumidor que está
buscando servicios. Fuente propia. ................................................................. 90
Ilustración 24 - Captura de pantalla de un usuario emitiendo mensajes con otro
usuario conectado. Fuente propia. ................................................................... 93
Ilustración 25 - Captura de pantalla de un usuario conectado a otro usuario con
mensajes disponibles. Fuente propia. .............................................................. 94
Ilustración 26 - Captura de pantalla con el Access Point del usuario con
mensajes creado. Fuente propia. ..................................................................... 95
Ilustración 27 - Captura del dispositivo buscando servicios. Fuente propia. . 97
Ilustración 28 - Captura de pantalla de un dispositivo conectándose a otro.
Fuente propia. .................................................................................................. 98
Ilustración 29 - Captura de pantalla de un dispositivo después de recibir
mensajes desde otro dispositivo. Fuente propia. ............................................. 99
Ilustración 30 - Captura de pantalla con el dispositivo A dando servicio. Fuente
propia. ............................................................................................................ 101
Ilustración 31 - Captura de pantalla con el dispositivo A mostrando los
dispositivos conectados a su red. Fuente propia. ......................................... 102
Ilustración 32 - Captura de pantalla con el dispositivo B dando servicio. Fuente
propia. ............................................................................................................ 103
Ilustración 33 - Captura de pantalla con el dispositivo C mostrando los
dispositivos conectados a su red. Fuente propia. ......................................... 103
Ilustración 34 - Captura de pantalla con el dispositivo C dando servicio. Fuente
propia. ............................................................................................................ 104
Ilustración 35 - Captura de pantalla con la nueva Actividad mostrando el
formulario de creación de un mensaje. Fuente propia. ................................. 106
Trabajo fin de grado
9 Jorge Prieto Martin
Ilustración 36 - Captura de pantalla mostrando un aviso sobre la creación del
mensaje. Fuente propia. ................................................................................. 107
Ilustración 37 - Entidades creadas en la base de datos del sistema. Fuente
propia. ............................................................................................................ 108
Ilustración 38 - Captura de pantalla de un dispositivo recibiendo el nuevo
mensaje introducido en el sistema. Fuente propia. ....................................... 108
Ilustración 39 - Captura de la pantalla de la creación de un mensaje. .......... 110
Ilustración 40 - Captura de pantalla del mensaje offline enviado. Fuente propia.
....................................................................................................................... 111
Ilustración 41 - Captura de pantalla cuando un dispositivo se ha conectado a
nuestra red. Fuente propia. ............................................................................ 112
Ilustración 42 - Captura de pantalla de un dispositivo offline buscando
servicios. Fuente propia. ................................................................................ 113
Ilustración 43 - Captura de pantalla con el usuario offline conectado a una red.
Fuente propia. ................................................................................................ 114
Ilustración 44 - Captura de pantalla de un dispositivo que ha recibido un
mensaje y lo está reenviando. Fuente propia. ............................................... 115
Ilustración 45 - Tabla de la representación del área en la fase 0. Fuente propia.
....................................................................................................................... 125
Ilustración 46 - Tabla de la representación del área en la fase 10. Fuente propia.
....................................................................................................................... 126
Ilustración 47 - Representación del centro de Alicante en la fase 0. Fuente
propia. ............................................................................................................ 127
Ilustración 48 - Mockup de la pantalla de identificación. Fuente propia...... 134
Ilustración 49 - Mockup de la pantalla de administración de usuarios. Fuente
propia. ............................................................................................................ 135
Ilustración 50 - Mockup de la pantalla de administración de las organizaciones.
Fuente propia. ................................................................................................ 136
Trabajo fin de grado
10 Jorge Prieto Martin
Ilustración 51 - Mockup de la pantalla de administración de zonas. Fuente
propia. ............................................................................................................ 137
Trabajo fin de grado
11 Jorge Prieto Martin
Índice de tablas
Tabla 1 - Requerimiento funcional 1 .............................................................. 38
Tabla 2 - Requerimiento funcional 2 .............................................................. 38
Tabla 3 - Requerimiento funcional 3 .............................................................. 38
Tabla 4 - Requerimiento funcional 4 .............................................................. 39
Tabla 5 - Requerimiento funcional 5 .............................................................. 39
Tabla 6 - Requerimiento funcional 6 .............................................................. 40
Tabla 7 - Requerimiento funcional 7 .............................................................. 40
Tabla 8 - Requerimiento funcional 8 .............................................................. 40
Tabla 9 - Requerimiento funcional 9 .............................................................. 41
Tabla 10 - Requerimiento funcional 10 .......................................................... 41
Tabla 11 - Requerimiento funcional 11 .......................................................... 41
Tabla 12 - Requerimiento funcional 12 .......................................................... 42
Tabla 13 - Dispositivos utilizados para las pruebas. ..................................... 118
Tabla 14 - Seudónimos de los dispositivos utilizados para las pruebas. ...... 119
Tabla 15 - Pruebas entre dos dispositivos. .................................................... 119
Tabla 16 - Pruebas entre tres dispositivos, simultanea. ................................ 121
Tabla 17 - Pruebas entre tres dispositivos, consecutiva. ............................... 122
Tabla 18 - Pruebas entre cuatros dispositivos. Simultanea. .......................... 123
Tabla 19 - Pruebas entre cuatro dispositivos. Consecutiva. .......................... 123
Tabla 20 - Resultados de las pruebas del emulador. ..................................... 128
Tabla 21 - Resultado de pruebas del emulador. Con límite de conexiones. . 129
Tabla 22 - Pruebas del consumo de la batería. .............................................. 130
Trabajo fin de grado
12 Jorge Prieto Martin
1. Motivación, justificación, objetivo general
Quiero contribuir a mejorar el mundo.
Dentro del mundo de la informática, siempre he sentido curiosidad por cómo
se comunican los ordenadores. El hecho de poder enviar un mensaje,
documento, foto…. de un dispositivo a otro, de manera casi instantánea, sin
importar la distancia, me parecía casi cosa de magia.
Ahora, habiendo entendido el funcionamiento de este tipo de mecanismos
(redes, protocolos, puertos…), incluso de yo mismo haber podido realizar o
simular este tipo de conexiones entre dos dispositivos, ha hecho que mi interés
en este campo de la informática haya crecido lo suficiente como para llegar a
plantearme hacer una pequeña investigación por mi parte.
Por otra parte, está el deseo de ayudar. Como ingeniero informático (más bien,
aspirante a ingeniero informático), muchas veces me planteo de qué manera
puedo mejorar, o qué puedo aportar a esta sociedad, con solamente la ayuda de
un ordenador, y mi conocimiento.
Creo que, cada vez, está más ligada la informática al mundo real, a los avances
tecnológicos, sociales, de la ciencia y la medicina, de la educación, e incluso
del destino de un país entero y su seguridad. ¿Cómo puedo ayudar yo, a todo
esto, con sólo una máquina y conocimiento?
Estos dos puntos, de alguna manera, han estado siempre rondando en mi
cabeza, y es ahora, cuando veo la oportunidad de poder asumirlos y sacar algo
productivo de ello.
Vivimos en una sociedad conectada, es muy difícil encontrar un sitio donde no
haya cobertura, donde no podamos llamar o no podamos conectarnos a nuestro
Trabajo fin de grado
13 Jorge Prieto Martin
servicio de datos. La conexión wifi es ya una norma en cada hogar y
establecimiento. Hemos evolucionado de tal forma que, ya nadie sale de casa
sin su teléfono móvil (generalmente smartphone) a la calle. Vayas donde vayas,
encontrarás a alguien con su teléfono móvil. Un dispositivo, que, comparado
con ordenadores de años atrás, supera con creces su potencia y prestaciones.
Estos dispositivos cuentan con su propio procesador, memoria RAM,
almacenamiento, sistema operativo, cámara, antena de wifi, bluetooth,
infrarrojos…
Y, aun así, si nos quedamos sin cobertura en nuestro dispositivo o si este no
dispone de conexión a internet por alguna razón, nos quedamos desconectados.
Sin conexión a la red principal no hay forma de conectarse a internet, no hay
forma de llamar, no hay forma de comunicarse con ningún dispositivo, aún
incluso cuando tengamos nuestro dispositivo totalmente funcional y con
batería, con su antena wifi perfectamente operativa.
Este hecho es común por ejemplo cuando nos encontramos en una zona
reducida con una gran cantidad de gente (el centro de una ciudad, un
concierto…). De repente, no tenemos tan buena señal en el móvil, y nuestra
conexión a internet 4G no funciona como debería. Podemos ver que incluso
cambia nuestra señal 4G por una señal UMTS (3G) o señal GPRS(2G ), y en el
peor de los casos debido a la saturación incluso nos quedarnos sin señal.
Este tipo de situaciones son las que me han inspirado a enfocarme en este
trabajo. Y se me plantea una pregunta, a la que me gustaría dar una respuesta
al final de este proyecto.
De producirse un altercado peligroso dentro de un recinto, si se sufriera de una
catástrofe natural, o de un ataque terrorista, donde las comunicaciones
tradicionales se vieran afectadas y no tuviéramos conexión a internet para
informarnos ¿Cómo podríamos informar a toda esa gente de lo que está
ocurriendo?
Trabajo fin de grado
14 Jorge Prieto Martin
Todo esto, han sido mis motivaciones, no solo durante este último año de
carrera, sino que es una reflexión más antigua que emerge ahora en forma de
trabajo final de grado.
Trabajo fin de grado
15 Jorge Prieto Martin
2. Introducción
2.1 Problema
Recordemos por un momento el caso de Madrid Arena. El 1 de noviembre de
2012, hubo una macro fiesta en un pabellón multiusos llamado Madrid Arena.
Se dieron varias irregularidades, como el excesivo aforo (más de 20000
personas, en un recinto con un máximo de unas 10000 personas), poco personal
sanitario y una nula seguridad, hizo que la situación se agravara cuando se abrió
un portón de carga para el acceso a la pista central, juntándose en los pasillos
gente que quería salir del pabellón central con otra gente que quería entrar,
taponando así uno de los pasillos y produciendo el fallecimiento de cinco
personas1. Se ha criticado mucho todas las irregularidades del recinto, así como
la poca colaboración entre los diferentes servicios y la nula comunicación a los
asistentes del evento, ya que muchos de ellos, se enteraron de lo sucedido al día
siguiente y por las noticias.
¿Qué hubiera pasado, si se hubieran dado instrucciones a todos los asistentes
de cómo proceder para poder desbloquear ese pasillo?
Otra situación que me gustaría exponer, es la de los desastres naturales, más
concretamente, los tsunamis y terremotos en Japón. Allí, se ha ido
desarrollando unos sistemas de alarma cada vez más sofisticados, por el cual
avisan de tsunamis y terremotos, inclusos pocos minutos antes de que se
produzcan vía, televisión, radio e incluso mensajes a tu smartphone. Si miramos
casos más concretos, tenemos el tsunami de Fukushima de 2011, si bien, los
sistemas de alarma funcionaron bien, la gente no esperaba tal magnitud de ola
como la que al final se encontraron. En Japón, aparte de los sistemas de alarmas
ya mencionados, a lo largo de las ciudades, tienen sistemas de megafonía que
1 Referencia del diario 20 minutos http://www.20minutos.es/noticia/1641576/0/cronologia/tragedia/madrid-
arena/
Trabajo fin de grado
16 Jorge Prieto Martin
sirven tanto para avisar de los toques de queda (en invierno, cuando oscurece
sobre las 5pm, todos los niños de primaria deberían volver a sus casas), como
de avisos de emergencias en caso de tsunamis y terremotos. En este caso, el
terremoto y siguiente tsunami fueron de tal magnitud, que estos sistemas de
megafonía pronto dejaron de funcionar, y otros sistemas de comunicaciones
empezaron a fallar, dejando a la gente incomunicada, sin saber muy bien que
hacer o dónde dirigirse, y finalmente siendo sorprendida por el tsunami2.
Me gustaría reflejar en este ejemplo, como uno de los países mejor preparados
para las catástrofes naturales, depende de factores que tienden a fallar en,
concretamente, este tipo de situaciones.
Otro suceso importante, es el ocurrido en París, la noche del 13 de noviembre
de 2015, se perpetraron varios atentados a lo largo de la ciudad, dejando 137
personas fallecidas y 415 heridos. Si bien es cierto que este tipo de emergencias
son impredecibles y dejan poco margen de maniobra a la hora de actuar, sí que
podemos plantearnos el problema a la hora de evacuar cierta área o avisar de
forma masiva del estado de emergencia para dar instrucciones básicas o evitar
zonas de riesgo. Aunque, no transcurrió mucho tiempo entre un ataque y otro
(menos de una hora entre el primero y último), varios de los ataques fueron
realizados en la calle, donde los ciudadanos no tenían por qué saber lo que había
ocurrido esa misma noche en otras zonas de la ciudad3.
A lo largo de estos tres escenarios, muy diferentes entre sí, hemos podido
observar un problema común, la capacidad de reacción ante un problema
inesperado y la falta de información para con el ciudadano. Si bien por fallo de
las infraestructuras debido a una catástrofe natural, donde quedan inutilizadas
2 Artículo del Huffingtonpost (Inglés) http://www.huffingtonpost.com/bruce-parker/japan-
tsunami_b_1335737.html 3 Artículo de la bbc (Inglés) http://www.bbc.com/news/world-europe-34818994
Trabajo fin de grado
17 Jorge Prieto Martin
en cuestión de minutos, o bien por la inexistencia o poca utilidad de estas
infraestructuras en zonas donde las aglomeraciones de gente saturen y hagan
inoperables estos servicios o incluso en escenarios donde puedan ser
manipuladas para crear confusión y pánico. Problemas, donde, la capacidad de
reacción es, muchas veces, clave para disminuir la gravedad del problema sino
incluso evitarla.
Una observación que me gustaría hacer sobre los casos anteriores, es que, son
sucesos recientes, de hace menos de 7 años, donde por regla general, todo el
mundo llevaría un smartphone consigo, una herramienta muy potente, pero con
su gran talón de Aquiles, ya que, si le falta cobertura o conexión, se queda solo
en un dispositivo multimedia para hacer fotos, escuchar música o jugar.
Estamos creciendo en una sociedad donde se ha creado una infraestructura
tecnológica de gran capacidad que todo el mundo puede llevar en su bolsillo.
Capacidad suficiente como para crear redes descentralizadas de comunicación
si fueran capaces de conectarse entre sí, sin necesidad de una red central como
a la que estamos acostumbrados.
Hemos visto quizá unos escenarios, un tanto extremos, pero reales.
Pongámonos en un hipotético caso, más frecuente como la de un incendio.
Imaginemos que es en un edificio de oficinas grande, de más de 100 plantas, y
se genera fuego en la planta 50. Saltan las alarmas, debido al fuego empiezan a
fallar las conexiones y las personas dentro del edificio se quedan
incomunicadas, tanto por la destrucción de las conexiones a internet y sus
puntos de acceso como por la inhabilitación de las antenas del edificio que
sirven para comunicar a la gente dentro de este edificio. Aun así, sus
dispositivos móviles están funcionando al 100%. ¿Cómo podemos avisar a
todas las personas dentro del edificio de cómo actuar ante un incendio? ¿Cómo
Trabajo fin de grado
18 Jorge Prieto Martin
avisar a todos dónde está ocurriendo el fuego y cómo se está propagando?
¿Cómo avisar a los que estén por encima de la planta 50, que esperen en la
azotea a la evacuación por helicóptero? ¿Cómo avisar a los que están por debajo
de esa planta, a que evacuen por la salida de emergencias trasera, ya que la
delantera está bloqueada por escombros?
Mi propuesta plantea un acercamiento al problema de una manera diferente,
aprovechar y explotar el uso que se hace actualmente de los smartphones para
que en el momento que un dispositivo se encuentre sin conexión 3G/4G, ni
cobertura, ni acceso a internet. Se genere un mecanismo automático capaz de
organizar a todos los dispositivos de un área concreta para poder buscar otros
dispositivos y poder intercambiar información de carácter urgente, haciendo
posible que cuando uno de los dispositivos tenga acceso a esa información
urgente se pueda transmitir a todos los demás dispositivos del área afectada.
Incluso, en el caso de que ningún dispositivo tuviera acceso a internet, poder
hacer llegar ese mensaje de información urgente por la misma vía de reenvío
de información entre los dispositivos desde un dispositivo cercano que pueda
generar esa información urgente.
Trabajo fin de grado
19 Jorge Prieto Martin
3. Estado del arte
Entrando a comparar herramientas en el mercado qué ya implementen la idea
propuesta en este proyecto, se ha hecho difícil la tarea de encontrar una
herramienta qué disponga de la misma solución que aquí se propone. Se ha
hecho búsquedas intensivas en internet, y preguntado a colegas qué pueden
tener más conocimiento sobre las nuevas tecnologías.
Si bien, no se ha encontrado una herramienta que otorgue las mismas
soluciones, sí que hay herramientas que inspiran sobre las mismas ideas o
soluciones que en parte están implementadas en el proyecto.
Me gustaría destacar que la idea del proyecto no está inspirada en ningún otro
proyecto ya existente, y nace un poco de la necesidad, dada la poca explotación
que existe de productos comerciales de conexión entre dispositivos ajenos a
grandes infraestructuras.
Por lo tanto, el estado del arte se va a resumir en otras tecnologías, proyectos,
infraestructuras y protocolos, que se necesitan para el desarrollo del proyecto,
o han dado pie a las tecnologías que aquí se van a usar o han sido descubiertas
en la búsqueda de información para este proyecto.
Podemos categorizar estas soluciones en tres campos, herramientas originarias,
herramientas de apoyo, y herramientas paralelas o futuras.
3.1 Soluciones originarias
Estas soluciones se caracterizan por ser las pioneras, aquellas de las cuales
gracias a su nacimiento y explotación han dado fruto a nuevas herramientas
inspiradas en éstas o mejoradas para rellenar las carencias de las que contaban.
Trabajo fin de grado
20 Jorge Prieto Martin
3.1.1 P2P
Sin entrar en mucho detalle, podemos definir P2P (peer to peer) como una
tecnología de intercambio de información entre dos nodos, sin intermediarios
y asumiendo en todo momento el papel de cliente y servidor por ambas partes.
Este tipo de tecnología, goza de la ventaja de prescindir de intermediarios (no
en todas las tecnologías P2P, pero sí en las más anónimas) creando así una
comunicación directa entre dos nodos por la cual uno hace de cliente y otro de
servidor, pudiendo estar los papeles intercambiados incluso al mismo tiempo,
si cada uno está compartiendo un archivo con el otro nodo4.
La herramienta más popular qué utiliza este tipo de tecnología es, claramente,
Emule5, un programa aún con vida qué permite la creación de redes p2p, por la
cual los usuarios pueden intercambiar archivos.
Para mi propuesta, la tecnología p2p está muy presente si tenemos en cuenta
que existe un intercambio de datos directo entre un usuario que hace de cliente
y otro que hace de servidor, pudiendo cambiar los papeles en cualquier
momento. Se inspira también en la idea de no tener un servidor centralizado
para el intercambio de información, ya que una vez un dispositivo recibe un
mensaje (que si puede venir de un servidor central), éste irá conectándose con
otros dispositivos los cuales almacenarán su contenido y lo irán compartiendo
a su vez.
3.1.2 Ad-Hoc y Mobile Ad-Hoc networks (MANET)
Entendemos las redes ad-hoc, como un tipo de red inalámbrica descentralizada,
es decir, no hay un router central y todos los hosts son capaces de enrutar la
información.
4 Artículo de la Wikipedia https://es.wikipedia.org/wiki/Peer-to-peer 5 Definición de Emule por la página oficial del programa http://www.emule.com/es/emule-preguntas-
frecuentes/que-es-emule/
Trabajo fin de grado
21 Jorge Prieto Martin
Así, las mobile ad-hoc networks (MANET, redes ad-hoc móviles) son un
conjunto de hosts inalámbricos móviles capaces de crear una red (temporal) sin
necesidad de un host central.
Este tipo de redes son siempre dinámicas, ya que los hosts se pueden conectar
y desconectar de la red de manera continua.
En comparación con la tecnología D2D (más adelante) las MANET tienen un
gasto mayor de energía y su velocidad de transferencia es menor.
El uso de redes ad-hoc puede verse en productos comerciales como la Nintendo
3DS que permite a varios dispositivos conectarse entre sí y poder jugar.
El reflejo en mi propuesta es claro, ya que uno de los objetivos es crear una red
inalámbrica móvil, qué permite el intercambio de datos sin la necesidad de un
nodo central. Si bien es un poco irónico que, si pensamos en dispositivos
móviles, lo primero en lo que pensemos sea un smartphone con Android, lo
cierto es que los dispositivos Android no son compatibles con las redes ad-hoc6
(al menos de forma nativa) dando preferencia a Wifi-Direct.
3.1.3 Red de Área Personal (WPAN) / Bluetooth Las redes de área personal utilizan la radiofrecuencia para la transmisión de
voz y datos, bluetooth 7en concreto utiliza un tipo de red ad/hoc llamada piconet
donde uno de los dispositivos hace de master y el resto de esclavos.
Comparando con nuevas tecnologías, bluetooth es una tecnología lenta y muy
restrictiva en cuanto al espacio ya que deja de funcionar cuando la distancia
supera los pocos metros.
6 Características de las conexiones p2p wifi en Android (Inglés)
https://developer.android.com/training/connect-devices-wirelessly/wifi-direct.html 7 Descripción de Bluetooth por la página oficial (Inlgés) https://www.bluetooth.com/what-is-bluetooth-
technology/how-it-works
Trabajo fin de grado
22 Jorge Prieto Martin
Si bien era la tecnología principal para el intercambio de archivos entre
dispositivos, la cual se sigue utilizando y viene por defecto en la mayoría de
teléfonos móviles actuales, aunque haya caído un poco en desuso.
Este proyecto podría haberse enfocado en el desarrollo de intercambio de
información usando bluetooth, pero se ha querido evitar por los problemas que
conlleva, mencionados más arriba.
3.2 Soluciones de apoyo
Estas soluciones destacan por ser tecnologías en las que se apoya el desarrollo
de la propuesta. Al margen de ser más o menos actuales o existan soluciones
mejores. Se han optado estas como referencia porque son las que más se ajustan
al proyecto o las más conocidas para el ámbito en el que se va a trabajar.
3.2.1 Wifi-Direct
Esta tecnología podría verse como la versión mejorada de bluetooth, una
tecnología para crear redes entre dispositivos, la cual un dispositivo hace de
nodo principal y los demás se conectan a él, todo esto mediante wifi. Realmente
lo qué se está haciendo por detrás no es más que la creación de un Access Point
por parte del nodo principal y el resto de dispositivo se conectan a ese AP
haciendo el papel de router por parte del nodo principal. Esto permite que
únicamente el nodo principal que crea la red necesite de Wifi-Direct para poder
funcionar.
Esta tecnología se empezó a popularizar en 2008, pero no sé popularizó en
dispositivos móviles hasta 2011 con la versión de Android 4.0 Ice Cream
Sandwich, la primera versión en introducir WI-FI Direct.
El uso de esta tecnología en el proyecto es claro, y necesario para el buen
funcionamiento de la idea, si bien, no está integrado de una manera completa y
Trabajo fin de grado
23 Jorge Prieto Martin
se han seguido otros caminos para obtener lo que Wifi-Direct restringe de
manera nativa8.
3.3 Herramientas paralelas/ futuras
Las soluciones aquí descritas, son herramientas que bien se están desarrollando
en paralelo junto a este proyecto o son soluciones reales y factibles que
solventan, ya sea en parte o de manera parecida, el problema que en este
proyecto se propone.
3.3.1 D2D
D2D, device to device (del inglés, dispositivo a dispositivo) es una tecnología
emergente en redes LTE (4G) que permite el intercambio de datos entre
dispositivos sin la necesidad de pasar por una estación base. Hasta la fecha es
la tecnología más potente en cuanto a conexión entre dispositivos se refiere
debido a su velocidad de transferencia, seguridad, ahorro de energía y baja
interferencia.
Lo que se quiere conseguir con esta tecnología, es la capacidad de comunicar
dispositivos que están lo suficientemente cercanos como para que no haga falta
un intermediario (una estación base en este caso) para poder comunicarse.
La tecnología D2D podría verse como la evolución natural de anteriores
tecnologías que hemos visto de conexión directa entre dos dispositivos,
ofreciendo mayores velocidades con gasto menores de batería. 9
8 Artículo de la WI-FI Alliance sobre WI-FI Direct - http://www.wi-fi.org/discover-wi-fi/wi-fi-direct 9 Artículos sobre D2D (Inglés)- https://wncg.org/research/briefs/device-device-d2d-communication-
fundamentals-applications-lte , http://www.radio-electronics.com/info/cellulartelecomms/lte-long-term-
evolution/4g-lte-advanced-d2d-device-to-device.php
Trabajo fin de grado
24 Jorge Prieto Martin
Si bien el problema que puede residir en este formato, se encuentra en sí en el
modo de comunicación. Ya que, al basarse en 4G aun cuando exista una manera
para conectar los dispositivos, aunque la red esté caída, sí que requiere tener
una tarjeta SIM para poder operar, esto también limita al uso de otros
dispositivos portátiles que pueden tener o no, una tarjeta sim, como por
ejemplo, una Tablet. Además, es una tecnología aun desarrollándose con poca
información y recursos sobre el que hacer un proyecto.
3.3.2 System for broadcasting geolocation information in
emergency situations via Wi-Fi interfaces of smartphones
Quizá el proyecto que más se asemeja a mi propuesta, este trabajo ganador de
un premio y desarrollado por José Ángel Berná, investigador de la UA, el cual
he tenido la suerte de tener como profesor de Interconexión de Redes, ofrece
una APP por la cual un usuario puede emitir una señal de socorro con sus
coordenadas exactas sin necesidad de cobertura telefónica, sólo utilizando la
señal wifi de su dispositivo móvil, donde más tarde esa señal será recogida por
un equipo de rescate utilizando un receptor especial.
Este sistema innova a la hora de utilizar una señal wifi como medio de
comunicación sin necesidad de cobertura telefónica ni acceso a internet.
Como veremos más adelante, también en mi propuesta, se hace uso de la
tecnología wifi de los dispositivos móviles para el envío (e intercambio) de
información y alertas en casos de emergencia.
Una clara diferencia entre este proyecto y mi propuesta, es la naturaleza en sí
del objetivo, ya que, en el proyecto desarrollado de José Ángel Berná, este
objetivo es que una persona emita una señal de socorro desde su posición a un
equipo de rescate. Para mi propuesta, se podría entender como la inversa, ya
Trabajo fin de grado
25 Jorge Prieto Martin
que se trata qué desde un organismo capacitado para ello, envíen alertas a
usuarios en una zona de peligro, donde tales usuarios pueden estar ignorando
la presencia de peligro10.
3.3.3 Alerta de emergencia
Este servicio implementado desde la versión Lollipop de Android, trata de una
radiodifusión qué se envía al dispositivo a través de redes GSM o UMTS. Éstas
alarmas son creadas y enviadas por organismos gubernamentales y disponen de
varios niveles de alarma qué se pueden activar o desactivar a gusto del usuario.
Las alarmas que genera están pensadas para catástrofes naturales, situaciones
de emergencia en estados en guerra, e incluso desaparición de menores. Este
tipo de alarma son muy populares en Japón, para avisar mayormente de
terremotos, los cuales suceden cada muy poco tiempo ya sea a mayor o menor
escala.
El servicio de alerta de emergencia depende de las redes telefónicas por lo cual,
si éstas se ven afectadas o incluso si por cualquier razón nuestro dispositivo
careciera de tarjeta sim, el servicio dejaría de funcionar11.
Una parte de mi proyecto integra un sistema similar que permite obtener
mensajes dependiendo de la zona en la que te encuentres.
10 Artículo sobre la investigación de José Ángel Berná https://web.ua.es/es/actualidad-
universitaria/2016/septiembre16/26-30/un-investigador-de-la-ua-desarrolla-una-tecnologia-para-emitir-
senales-de-socorro-en-entornos-donde-no-existe-cobertura-de-telefonia-movil.html 11 Artículo sobre las alertas de emergencia http://www.mibqyyo.com/articulos/2016/02/01/radiodifusiones-
emergencia-alertas-oficiales-bq/#/vanilla/discussion/embed/?vanilla_discussion_id=0
Trabajo fin de grado
26 Jorge Prieto Martin
Trabajo fin de grado
27 Jorge Prieto Martin
4. Objetivos
4.1 Identificación del problema
El problema se entiende como una falta de acceso a la información de los
usuarios de teléfonos móviles en escenarios donde las conexiones de las redes
de comunicación tradicionales, como la telefonía móvil, no responden o están
saturadas. Provocando un aislamiento de este usuario o usuarios en una zona
de peligro, aun teniendo un dispositivo de gran capacidad tecnológica.
Así, la red no es tolerante a fallos, ya que, si cae el nodo central, deja
incomunicados al resto de nodos, aunque estos sí que estén operativos.
No existe la capacidad de comunicación de forma local, aunque existe la
tecnología para ello. En situaciones delicadas donde hay conflictos de guerra,
catástrofes naturales, terrorismo o alta concentración de personas en puntos
concretos, existe ese nodo central que puede estar o volverse inoperativo en
cualquier momento y dejar a la ciudadanía incomunicada y desinformada.
4.2 Objetivo principal
Ofrecer un sistema capaz de difundir información necesaria en el momento, a
los usuarios de estos dispositivos móviles en un área concreta, sin necesidad de
que estos estén conectados a las redes de comunicación tradicionales o con un
acceso limitado.
4.3 Sub-objetivos
• Realizar un estudio de las actuales propuestas tanto a nivel de aplicación,
estándar, protocolos o servicios que abordan dicha problemática.
• Proponer un modelo de mensajería y una herramienta de generación y
reenvío de mensajes de alerta, haciendo uso de la tecnología WI-FI.
Trabajo fin de grado
28 Jorge Prieto Martin
o Definición de un mensaje de alerta, sus características y tipos
o Definición del sistema de gestión de alertas, su creación y
difusión.
o Definición del sistema de reenvío de mensajes sin conexión.
o Desarrollar un prototipo de la propuesta que resuelva el problema
dado.
o Probar y validar la propuesta, diseñar pruebas y crear simulaciones
para comprobar que el sistema funciona correctamente a como se
ha especificado.
o Confeccionar un plan de viabilidad para la implantación.
• Desarrollar el proyecto en los términos y condiciones que dictan las
normativas respecto a los trabajos final de proyecto.
Trabajo fin de grado
29 Jorge Prieto Martin
5. Metodología
Debido a las características que presenta la propuesta, desarrollar un trabajo
final de grado, y la no existencia de un cliente externo (se tomará como cliente
al autor de este proyecto junto a su tutor), se busca una optimización del tiempo
y poder desarrollar un producto mínimo viable lo más rápido posible para
probar el sistema y adaptarlo según vayan surgiendo cambios.
Si echamos un vistazo dentro de las metodologías ágiles, vemos que SCRUM
y XP (extreme programming) son los que sobresalen dada su popularidad, sin
embargo, los pasos a seguir dentro de estas metodologías y su adaptación a una
variante “one person project” pueden no ayudar e incluso entorpecer al
desarrollo del software. Por eso, se ha decidido por la metodología Lean
Software Development, que no marca unos pasos a seguir sino, unos principios
a los que adaptarse, donde deberás amoldar tu forma de trabajo a esos
principios.
5.1 Principios
A continuación, se explican los principios a seguir y cómo se adaptan para esta
propuesta en concreto:
• Eliminación de desperdicio
o Aquí se evita malgastar el tiempo en trabajo que no nos lleve a
nada. Por ejemplo, crear código que no vamos a usar o empezar
demasiadas tareas simultáneamente que no podamos llevar a cabo.
o Para esta propuesta, se definirá un número de tareas a seguir, de
manera simultánea basándome en mi propia experiencia y en los
consejos del tutor. También, se irá eliminando código y tareas que
no hayan aportado valor al final de cada entregable.
• Crear conocimiento
Trabajo fin de grado
30 Jorge Prieto Martin
o La creación de conocimiento se puede abordar desde dos puntos
de vista, uno, como el aprendizaje del cliente en cuanto al proyecto
y su desarrollo y la otra como el auto-aprendizaje obtenido a través
del uso de nuevas herramientas y mejora de conocimientos para el
desarrollo del proyecto.
o Para esta propuesta, la creación de conocimiento se dará en base a
la documentación escrita y un auto-análisis de todo lo aprendido
en cada entregable.
• Diferir el compromiso
o Se entiende diferir el compromiso, en decidir lo más tarde posible,
cuando se toma una decisión que es irreversible. Se aconseja
dejarlo siempre para el último momento ya que si se toma una
decisión desde el principio puede afectar al proyecto y terminar
con un objetivo distinto de este.
o Para esta propuesta, y con la ayuda de mi tutor, se están valorando
todos los requerimientos, así como decidiendo los que son más
básicos y han sido más analizados desde un principio, y dejando
los que no están muy claros para cuando se vea avanzada la
propuesta.
• Entregas rápidas
o Para evitar que un proyecto se demore más de lo que debe y que
los cambios no tengan un coste elevado de implementación.
o Para esta propuesta, se propone una serie de entregables mínimos
a seguir que irán implementando uno o varios requisitos. Entre
estos entregables mínimos se esperan otros entregables para
corregir errores y adaptar requisitos.
• Respetar a las personas
o Este principio se basa en el respeto hacia el equipo, escuchando su
opinión y dándoles voz.
Trabajo fin de grado
31 Jorge Prieto Martin
o Para esta propuesta, este es un principio que se escapa un poco
debido a su naturaleza de trabajar en equipo, si bien, mantengo
este principio a la hora de escuchar las observaciones y
correcciones de mi tutor para la mejora de la propuesta.
• Optimizar el todo
o Este principio se refiere a no concentrarse en una fase en concreto
mientras se dejan las demás fases apartadas e intentar llevarlas
todas en conjunto.
o Para este proyecto, como se ha ido especificando, se va a seguir
una metodología ágil, por lo tanto, cada fase se irá desarrollando
junto a las otras en cada entregable.
5.2 Iteraciones del desarrollo
Se plantea definir iteraciones cortas, con objetivos muy concretos. La duración
de cada iteración será comprendida de entre 2 a 5 días, basándose en la
dificultad, experiencia previa de implementación de tareas similares y
magnitud de la implementación.
El desarrollo en paralelo de varias funcionalidades puede darse en una
iteración, pero seguirá la pauta de, por una parte, desarrollar una funcionalidad
desde cero y desde otra, arreglar y mejorar otra funcionalidad que complemente
a ésta otra.
Las iteraciones se pueden enmarcar en los siguientes bloques que pueden
componerse de una o varias iteraciones:
• Bloque 1 – Desarrollo de la funcionalidad básica del servidor.
• Bloque 2 – Desarrollo de las funcionalidades de geolocalización.
• Bloque 3 – Desarrollo de las funcionalidades de conexión entre
dispositivos.
• Bloque 4 – Desarrollo de las funcionalidades de envío de datos.
Trabajo fin de grado
32 Jorge Prieto Martin
• Bloque 5 – Desarrollo de las funcionalidades avanzadas del servidor.
• Bloque 6 – Desarrollo de las funcionalidades avanzadas de conexión y
envío de datos.
Trabajo fin de grado
33 Jorge Prieto Martin
6. Análisis y especificación
6.1 Propósito
Se quiere garantizar las metas y objetivos de la propuesta, esclareciendo todos
los requisitos que se crean necesarios y con ello facilitar el trabajo y su
comprensión por parte de terceros.
Todos los requisitos y funcionalidades aquí expuestas, son las esperadas para
un sistema completo, si bien, el propósito real del proyecto, es demostrar que
se puede desarrollar y es factible este tipo de tecnología. A continuación, se
propondrán todas las aptitudes para el sistema completo, dejando claro cuales
se estiman para desarrollar en el futuro, priorizando las funcionalidades críticas
para el funcionamiento óptimo de la propuesta.
6.2 Alcance
El funcionamiento general del sistema será el siguiente. Cuando un usuario se
encuentre en una zona afectada por un peligro, éste recibirá un mensaje de
alerta indicándole del peligro y cómo proceder. Este mensaje se transmitirá por
toda la zona afectada sin importar que haya conectividad o no en el área.
Para la creación de estos mensajes, existirá un tipo de usuario especial,
encargado de generar estos mensajes indicando a qué zona tienen que ser
enviados. Estos usuarios serán parte de una organización, la cual tendrá
permisos para enviar mensajes a ciertas áreas.
El sistema permitirá y no permitirá una serie de condiciones:
• El sistema permitirá el envío de mensajes a dispositivos móviles sin
necesidad de que estos tengan cobertura o conexión a internet, mediante
el uso de la tecnología wifi de cada dispositivo.
Trabajo fin de grado
34 Jorge Prieto Martin
• El sistema permitirá el envío de mensajes desde un sistema conectado a
un sistema no conectado.
• El sistema permitirá el reenvío de mensajes entre dispositivos no
conectados.
• El sistema permitirá la recepción de mensajes en áreas geolocalizadas.
• El sistema permitirá la creación y envío de mensajes desde un sistema
no conectado a otro sistema no conectado.
• El sistema no permitirá la generación de mensajes de contestación.
• El sistema no es un sistema de chat o de comunicación tradicional
• El sistema no es un sistema de compartición o intercambio de archivos.
6.3 Perspectiva del producto
Este sistema será independiente de cualquier otro sistema software, si bien,
estará ligado al sistema operativo que se use en el dispositivo móvil y el uso de
tecnologías como puede ser WI-FI.
También será necesario que los dispositivos cuenten con Wifi Direct para el
correcto funcionamiento del sistema. Aunque un dispositivo no contara de esta
tecnología, podría seguir recibiendo mensajes, pero no reenviándolos.
6.4 Características del usuario
Para este proyecto, podemos separar los usuarios en dos claros grupos:
• Usuario consumidor:
o Este usuario, será el usuario final de la aplicación, una vez
instalada la aplicación en su móvil, recibirá las alertas en su
dispositivo, haciendo que éste las reenvíe a otros usuarios
cercanos vía wifi de forma automática sin necesidad de actuación
por parte del usuario. El objetivo de las alertas es de informar y
dar instrucciones claras de cómo proceder en un caso concreto de
Trabajo fin de grado
35 Jorge Prieto Martin
alerta. No se espera ninguna habilidad especial para este tipo de
usuario.
o Este usuario puede encontrarse en dos modos:
▪ Modo online: El usuario aún tiene conexión a internet, por
lo tanto, puede recibir mensajes del sistema. Cuando recibe
un mensaje será el encargado de reenviarlo a usuarios no
conectados. Este usuario se convierte en un punto crítico a
la hora de la transmisión del mensaje, ya que puede hacer
de conexión entre la zona afectada con el resto del mundo.
▪ Modo offline: El usuario no dispone de conexión a internet,
y por lo tanto no le es posible comunicarse con el sistema
de mensajes. El usuario consumidor tiene dos
comportamientos básicos, primero, escuchará en su zona
por otros dispositivos que tengan mensajes del sistema que
puedan recibir, esto puede ser tanto de usuarios no
conectados como de usuarios conectados. Una vez reciba
mensajes del sistema, pasará a reenviarlos y entrará en el
mismo modo que pasa un usuario consumidor online
cuando recibe un mensaje.
• Usuario generador:
o Se considera al usuario privilegiado, capaz de generar las alertas
y su envío mediante la aplicación web o móvil. Este usuario
requiere de seguridad extra para la autenticación y generación de
alertas. Podrá crear alertas para enviar en el momento, así como
generarlas para su uso posterior. Si bien éste usuario no requiere
tampoco de habilidades especiales, tendrá que tener los
conocimientos adecuados para generar una alerta con directrices
claras y fáciles de entender. También tendrá la opción de enviar
Trabajo fin de grado
36 Jorge Prieto Martin
esta alerta mediante wifi con un dispositivo móvil o enviarla
mediante internet a través de la aplicación web.
o El usuario generador, a nivel real, necesitará ser parte de una
organización autorizada para crear mensajes en el sistema.
o Al igual que un usuario consumidor, éste dispone de dos modos
▪ Modo online: Se trata de cualquier usuario generador con
conexión a internet, capaz de enviar un mensaje al sistema.
▪ Modo offline: Se trata del usuario generador que no tiene
conexión a internet y crea un mensaje para ser enviado de
forma offline a otros dispositivos cercanos.
• Usuario administrador
o Este usuario se encarga del sistema, buen funcionamiento de éste
y su actualización.
o Podrá administrar a los usuarios generadores, así como el
contenido que generen.
o No podrá generar mensajes, pero si eliminarlos.
o Se encargará de asignar las zonas a las organizaciones y sus
usuarios.
6.5 Restricciones
• El sistema estará limitado por el hardware del dispositivo móvil.
Teniendo que disponer de una antena wifi para poder utilizar el sistema.
• No será siempre necesario, pero en algún momento determinado es
posible que ciertos usuarios requieran de gps integrado en el móvil y
conexión a internet.
• El sistema estará limitado por el software del dispositivo móvil. Más
concretamente por el sistema operativo, teniendo que ser este Android,
ya que el desarrollo se hará enfocado y bajo esta plataforma. A partir de
la versión Jelly Bean,no presenta problemas, pero si presenta
Trabajo fin de grado
37 Jorge Prieto Martin
comportamientos extraños en algunos dispositivos que en versiones
posteriores (a partir de la versión Marshmallow) se arreglan.
• Como se ha mencionado antes, se requiere de la versión mínima de
Android 4.0 Ice Cream Sandwich, ya que es la primera versión en
integrar WI-FI Direct. Los usuarios con versiones anteriores podrán
recibir mensajes, pero no reenviarlos.
• Los usuarios generadores, podrán crear mensajes desde un navegador
web.
6.6 Atenciones y dependencias
Se requiere de librerías especiales de Android que permiten el uso y acceso de
la tecnología Wifi y GPS.
Para la administración de la geolocalización, tendremos la librería de Android,
Location. Para la administración de Wifi en los dispositivos, y el estado de las
conexiones, necesitaremos la librería de Android, Net. Para las peticiones y
respuesta del sistema usuario con el sistema servidor, necesitaremos también la
librería Volley de Android. Así como las librerías JSON de Java en ambos
sistemas.
6.7 Requerimientos funcionales
En este apartado, nombraremos todas las funcionalidades requeridas para el
sistema. Cada requerimiento se establecerá en una tabla donde le identificará y
se explicará su función. Además, se le dará una prioridad, siendo los de
prioridad Alta, las funciones primordiales para el funcionamiento básico del
sistema, y los de prioridad Baja, funcionalidades que mejoran el sistema, pero
no son necesarios para la implementación inicial y pueden dejar para desarrollo
en el futuro.
Trabajo fin de grado
38 Jorge Prieto Martin
Identificación del requerimiento:
RF01
Nombre del Requerimiento:
Registro usuario generador
Características:
Los usuarios generadores deberán registrarse en el sistema para poder utilizar ciertas características.
Descripción del requerimiento:
La información registrada se guardará en una base de datos
Prioridad del requerimiento:
Baja
Tabla 1 - Requerimiento funcional 1
Identificación del requerimiento:
RF02
Nombre del Requerimiento:
Identificación del usuario generador
Características: Los usuarios generadores deberán iniciar sesión para poder acceder a las funciones del sistema.
Descripción del requerimiento:
Se comprobará las credenciales con la información almacenada en la base de datos.
Prioridad del requerimiento:
Baja
Tabla 2 - Requerimiento funcional 2
Identificación del requerimiento:
RF03
Nombre del Requerimiento:
Generar mensaje
Características: Los usuarios generadores pueden crear alertas en el sistema
Descripción del requerimiento:
El usuario especificará el mensaje y las características de éste.
Prioridad del requerimiento:
Alta
Tabla 3 - Requerimiento funcional 3
Trabajo fin de grado
39 Jorge Prieto Martin
Identificación del requerimiento:
RF04
Nombre del Requerimiento:
Envío de mensaje
Características: Los usuarios generadores pueden enviar el mensaje al sistema
Descripción del requerimiento:
El envío del mensaje online podrá hacerse a través de una conexión a internet, donde el mensaje quedará almacenado en el sistema, pudiendo ser accedido más tarde por un usuario consumidor.
Prioridad del requerimiento:
Alta
Tabla 4 - Requerimiento funcional 4
Identificación del requerimiento:
RF05
Nombre del Requerimiento:
Envío de mensaje offline
Características:
Los usuarios generadores serán capaces de enviar un mensaje en el área donde se encuentran al momento de crearla, sin necesidad de enviarla a un servidor.
Descripción del requerimiento:
El envío del mensaje offline hará uso de la tecnología WI-FI Direct, para mandar de manera multidifusión el mensaje generado a toda el área indicada por éste usuario generador.
Prioridad del requerimiento:
Alta
Tabla 5 - Requerimiento funcional 5
Identificación del requerimiento:
RF06
Nombre del Requerimiento:
Consulta de mensajes
Características: Un usuario consumidor consultará si hay mensajes en su área al sistema o a dispositivos cercanos.
Descripción del requerimiento:
El usuario consumidor enviará sus coordenadas al sistema y éste comprobará si algún mensaje almacenado coincide con las coordenadas del usuario o consultará los dispositivos de la zona para comprobar si existen mensajes.
Trabajo fin de grado
40 Jorge Prieto Martin
Prioridad del requerimiento:
Alta
Tabla 6 - Requerimiento funcional 6
Identificación del requerimiento:
RF07
Nombre del Requerimiento:
Recepción de un mensaje
Características: El usuario recibirá mensajes del sistema u otro usuario
Descripción del requerimiento:
Si el mensaje es recibido por el sistema, quiere decir que las coordenadas del mensaje coinciden con las del usuario. Si es recibido desde otro usuario, quiere decir que éste disponía de mensajes.
Prioridad del requerimiento:
Alta
Tabla 7 - Requerimiento funcional 7
Identificación del requerimiento:
RF08
Nombre del Requerimiento:
Reenvío de un mensaje
Características: Cualquier usuario puede reenviar un mensaje a otros usuarios de la zona.
Descripción del requerimiento:
Cuando se recibe un mensaje o se ha creado de forma offline, se empezará a transmitir ese mensaje en el área en la que el usuario se encuentre.
Prioridad del requerimiento:
Alta
Tabla 8 - Requerimiento funcional 8
Identificación del requerimiento:
RF09
Nombre del Requerimiento:
Descartar alerta dado el tiempo de vida
Características: Un usuario descartará un mensaje cuando éste supere su tiempo de vida.
Descripción del requerimiento:
Cualquier usuario que tenga un mensaje el cual su tiempo de vida haya terminado, dejará de transmitirlo y lo descartará.
Trabajo fin de grado
41 Jorge Prieto Martin
Prioridad del requerimiento:
Media
Tabla 9 - Requerimiento funcional 9
Identificación del requerimiento:
RF10
Nombre del Requerimiento:
Crear usuarios
Características: El usuario administrador deberá validar la cuenta de un usuario generador antes de que ésta pueda ser utilizada
Descripción del requerimiento:
Para evitar que cualquier usuario pueda generar mensajes, primero el usuario administrador creará esa cuenta y luego el usuario generador podrá identificarse en el sistema.
Prioridad del requerimiento:
Baja
Tabla 10 - Requerimiento funcional 10
Identificación del requerimiento:
RF11
Nombre del Requerimiento:
Crear zonas
Características: El usuario administrador podrá crear las zonas a las que puede acceder un usuario generador.
Descripción del requerimiento:
Las zonas serán asignadas a organizaciones por parte del administrador. Luego un usuario que pertenezca a cierta organización podrá enviar mensajes a áreas en los que su organización tenga permisos.
Prioridad del requerimiento:
Baja
Tabla 11 - Requerimiento funcional 11
Identificación del requerimiento:
RF12
Nombre del Requerimiento:
Crear organizaciones
Características: El usuario administrador deberá dar de alta en el sistema a las organizaciones.
Descripción del requerimiento:
Las organizaciones podrán tener varios usuarios y zonas asignados.
Trabajo fin de grado
42 Jorge Prieto Martin
Prioridad del requerimiento:
Baja
Tabla 12 - Requerimiento funcional 12
6.8 Requisitos del banco de datos lógicos
Se van a diferenciar dos tipos de bases de datos. Una base de datos primaria,
que es la principal del sistema, donde se almacenará toda la información, y otra
base de datos secundaria que se creará en el dispositivo de cada usuario, la cual
solo almacenará los mensajes.
Se requiere de una base de datos primaria tanto como para guardar las alertas
generadas de manera online, como para guardar la información de los usuarios
y las zonas. Para modificaciones futuras donde se integre el registro y la
identificación de usuarios, así como las zonas, se accederá a la base de datos
para comprobar credenciales y crear, borrar y actualizar usuarios, zonas y
organizaciones.
El acceso a la base de datos se hará de manera continua, cada vez que se crea
una alerta y cuando los usuarios hacen peticiones para comprobar si existen
alertas en su área.
Cuando el usuario genere una alerta offline, ésta se almacenará en la base de
datos generada en el dispositivo. Así como el usuario consumidor cuando
recibe una alerta ya sea de manera offline como online.
Los usuarios generadores serán identificados con una id única, así como de un
nombre, email, contraseña y la organización para la cual trabajan.
El usuario administrador podrá crear zonas que se almacenarán con un id único,
un nombre, la coordenada que la representa y un área de efecto. Cada zona
podrá tener asociada varias alarmas que creará el usuario consumidor, estas
alarmas también estarán identificadas con un id único, el mensaje, el tiempo de
Trabajo fin de grado
43 Jorge Prieto Martin
vida de la alarma en minutos, la fecha de creación, y el radio de efecto en metros
de la alarma.
Ilustración 1 - Modelo entidad relación de la base de datos. Fuente propia.
6.9 Funciones
6.9.1 Validación de las entradas y salidas del sistema
• Coordenadas
o La comunicación básica entre el sistema cliente y el sistema
servidor estará basada en el envío de coordenadas. Estas
coordenadas se basan en un parámetro longitud y otro, latitud. Se
enviarán al sistema servidor en formato REST URI para que
puedan ser procesadas.
• Mensaje
o Cuando unas coordenadas coinciden con las de un mensaje (el
campo coordenadas del mensaje más el campo distancia del
Trabajo fin de grado
44 Jorge Prieto Martin
mensaje). Se recogerá toda la información del mensaje del sistema
servidor y se enviará al sistema cliente en formato JSON.
• Información del mensaje
o Al igual que las coordenadas, un sistema cliente puede crear un
mensaje en el sistema servidor enviándole la información
mediante una REST URI que contendrá toda la información
necesaria para el registro adecuado del mensaje en el sistema.
• Mensaje reenviado
o Cuando un mensaje se reenvía de un usuario a otro, se enviará
como un objeto Java, que luego será interpretado por cada usuario
consumidor. Aprovechando así la misma función, en cualquier
caso.
• Información del servicio
o Cuando un usuario empieza a reenviar un mensaje, éste creará un
servicio (explicado más adelante) con ciertas características como,
por ejemplo, el nombre del servicio, el nombre del SSID y la
contraseña. Este servicio tendrá un formato especial que el usuario
consumidor le llegará como parámetro y tendrá que interpretar
para poder utilizar esa información más adelante.
6.9.2 Secuencia de las operaciones
6.9.2.1 Secuencia de operaciones para la consulta de mensajes por parte del
usuario consumidor con conexión
A continuación, se enumeran las operaciones que realiza el sistema cliente
cuando un usuario consumidor consulta mensajes en su zona:
1. Consultar si el usuario ha cambiado de zona (consultar las coordenadas
de su posición)
Trabajo fin de grado
45 Jorge Prieto Martin
2. Transformar las coordenadas en el formato REST URI, para qué pueda
ser interpretado por el servidor (cuando hay conexión).
3. Envío del mensaje al sistema servidor y espera de la respuesta
4. Recibo de mensajes (si alguno) en formato JSON.
5. Interpretación del mensaje.
6. Creación del grupo, es decir, creación de un Access Point.
7. Creación de un servicio con la información de la conexión al Access
Point.
8. Espera de conexiones por parte de otros usuarios consumidores.
Abertura de un socket server en un puerto determinado a la escucha de
peticiones.
9. Cuando haya una conexión desde otro usuario consumidor, establece la
conexión y le envía el mensaje almacenado.
10. Cuando el mensaje haya caducado, se deja de transmitirlo se elimina el
grupo y el servicio.
6.9.2.2 Secuencia de operaciones para la consulta de mensajes por parte del
usuario consumidor sin conexión
A continuación, se enumeran las operaciones que realiza el sistema cliente
cuando un usuario consumidor se encuentra sin conexión
1. Escuchar servicios de otros dispositivos.
2. Conexión a un dispositivo con mensajes disponibles.
3. Apertura de un socket para el recibo de información desde el otro
dispositivo.
4. Recibo de mensajes.
5. Interpretación del mensaje.
6. Creación del grupo, es decir, creación de un Access Point.
Trabajo fin de grado
46 Jorge Prieto Martin
7. Creación de un servicio con la información de la conexión al Access
Point.
8. Espera de conexiones por parte de otros usuarios consumidores.
Abertura de un socket server en un puerto determinado a la escucha de
peticiones.
9. Cuando haya una conexión desde otro usuario consumidor, establece la
conexión y le envía el mensaje almacenado.
10. Cuando el mensaje haya caducado, se deja de transmitirlo se elimina el
grupo y el servicio.
6.9.2.3 Secuencia de operaciones para la consulta de mensajes por parte del
sistema servidor
A continuación, se enumeran las operaciones que realiza el sistema servidor
cuando un usuario consumidor consulta mensajes en su zona:
1. Recibe las coordenadas de un usuario
2. Coge de la base de datos todos los mensajes disponibles
3. Utiliza la fórmula del haversine en cada mensaje almacenado en la base
de datos para establecer la distancia entre la coordenada del usuario y la
del servidor.
4. Si la coordenada entra dentro del rango del área del mensaje, se añadiera
a un array JSON para poder ser enviado.
5. Una vez analizado todos los mensajes, se envían aquellos almacenados
en el JSON array como respuesta al usuario.
Trabajo fin de grado
47 Jorge Prieto Martin
6.10 Requisitos no funcionales
6.10.1 Número de conexiones soportados
Ya que la creación de alertas puede extenderse a nivel nacional e incluso
mundial, y cada dispositivo hace consulta del servidor cada vez que cambien
sus coordenadas, se espera una tasa elevada de peticiones al sistema servidor.
En la fase de pruebas, ésta carga se ve exenta ya que el máximo número de
accesos simultáneos al sistema servidor es de 3.
6.10.2 Número de terminales soportados
Al ser un sistema que se distribuye en forma de aplicación, el número de
terminales soportados es ilimitado.
El sistema cliente tiene una parte de autonomía donde se puede comportar como
sistema servidor a la hora de reenviar un mensaje. Por lo tanto, esto sirve para
ahorrar carga al sistema servidor y facilita que el número de terminales
soportados sea ilimitado.
6.10.3 Cantidad y tipo de información manejada
El sistema servidor guardará información sobre mensajes de alerta, la cual se
transformará en formato JSON y en String para poder ser leída, procesada e
interpretada de manera fácil y rápida.
La naturaleza del sistema hacer que se espere poca cantidad de información, es
decir, que se creen mensajes solo cuando haya una emergencia de ciertas
características.
Trabajo fin de grado
48 Jorge Prieto Martin
6.11 Atributos del software del sistema
6.11.1 Fiabilidad
La fiabilidad del sistema reside en la capacidad de poder hacer llegar el mensaje
de alerta a todos los usuarios consumidores en un rango dado, evitando
colisiones y saturación en los canales de envío/recepción.
Para evitar la saturación de conexiones a un dispositivo, los usuarios que se
conecten para recibir los mensajes desde un dispositivo, se desconectarán de
éste tan pronto como el envío se haya completado.
A su vez, cuando un mensaje haya excedido el tiempo de vida será eliminado
del dispositivo y se dejará de reenviar.
6.11.2 Disponibilidad
El sistema contará con la capacidad de poder trabajar de manera offline sin la
necesidad de que la parte online esté operativa.
En todo caso, todos los datos se almacenarán en una base de datos en la nube.
Confiando en las copias y seguridad del propio servidor contratado para ello.
El punto fuerte del sistema reside en la disponibilidad ya que la clave es poder
seguir recibiendo mensajes, aunque las redes de comunicación caigan.
6.11.3 Seguridad
Se exigirá doble seguridad para el envío de ciertos mensajes, ya que no todos
los usuarios podrán crear mensajes en todas las áreas. Así como la
comunicación encriptada entre servidor y cliente en la autenticación y la
creación de una cuenta.
A su vez, los accesos serán restringidos dependiendo del tipo de usuario,
pudiendo denegar el acceso a cierto tipo de usuario.
Trabajo fin de grado
49 Jorge Prieto Martin
También se asegurará de que solo los usuarios generadores puedan hacer llegar
al servidor sus mensajes.
Cuando un usuario generador crea un mensaje de manera offline, éste se tendrá
que verificar en su propio dispositivo, enviando el mensaje en la zona afectada
pero catalogado como no fiable al 100% hasta que se valide en el servidor.
En el apartado de diseño se detallarán todos los elementos sobre la seguridad
del sistema.
6.11.4 Mantenimiento
El sistema estará modulado adecuadamente, facilitando el desacoplamiento y
así, además permitir entregables funcionales en periodos iniciales del
desarrollo.
Una vez terminado el desarrollo del proyecto, el mantenimiento se basará en la
actualización de la base de datos, mejoras de rendimiento y adaptaciones a los
nuevos sistemas y versiones móviles que puedan ir surgiendo.
6.11.5 Portabilidad
La parte del servidor, donde se almacenan los diferentes datos y mensajes, y se
hacen los cálculos de las distancias entre coordenadas, es totalmente
independiente del sistema cliente. Dado que la respuesta del servidor se
devuelve en formato JSON, y se entiende como una API, se facilita su
portabilidad pudiendo ser usado por otras aplicaciones como un sistema de
alarma geolocalizado.
El desarrollo de la aplicación móvil, se hará orientado al sistema Android, bajo
código java y el IDE Android Studio, dejando poco margen para la portabilidad.
Trabajo fin de grado
50 Jorge Prieto Martin
6.12 Organizar los requisitos específicos
En éste apartado se habla en más detalle sobre los modos que cuenta el sistema.
El sistema contará con dos modos, offline y online:
• Modo online
o Cuando los usuarios tengan acceso a internet, el modo online
estará activado, en este modo, un usuario consumidor podrá
acceder a las alertas almacenadas en la base de datos, mediante sus
coordenadas y se le enviará en caso de que haya alguna que
cumpla el criterio (es decir, cuando un mensaje se encuentre en el
área del usuario).
o Un usuario generador, podrá generar y enviar la alerta al servidor
para que la pueda recibir un usuario consumidor.
• Modo offline
o Cuando el sistema no tenga acceso a internet se activará el modo
offline.
o En este modo, el usuario generador podrá enviar directamente
desde su dispositivo móvil la alerta de manera multidifusión
mediante wifi.
o El usuario consumidor, podrá recibir alertas y re-enviarlas a otros
usuarios consumidores, también desde su dispositivo móvil y
mediante wifi.
Trabajo fin de grado
51 Jorge Prieto Martin
7. Presupuesto, estimaciones y planificación
La planificación de la propuesta se dividirá en dos partes, investigación y
documentación por una parte y por otra, desarrollo.
La parte de investigación y documentación, comprende toda la planificación y
diseño del sistema, aprendizaje previo y documentación de toda la vida del
proyecto (éste documento).
La parte de desarrollo implica en la implementación de los objetivos, pruebas,
así como aprendizaje de nuevas tecnologías a implementar.
Se prevé la duración de 100 horas para la parte de investigación y
documentación y unas 150 horas para la parte de desarrollo, las 50 horas
restantes se estima repartir entre las dos partes en caso de que la planificación
no fuese correcta.
Se estima que las funcionalidades extras no cruciales del sistema pueden salirse
fuera de las 300 horas a dedicar al proyecto.
También, dada por la falta de acceso a recursos, se desarrollarán pruebas qué
simulen el sistema de manera que prueben su comportamiento y demuestren su
viabilidad y funcionamiento.
7.1 Planificación semanal
El desarrollo del proyecto se divide en 15 semanas con una media de 20 horas
dedicadas por semana.
Semanas 1-5: Planteamiento de ideas, y desarrollo de la memoria.
Semanas 6-12: Desarrollo del diseño e implementación del proyecto.
Semanas 13-15: Actualizaciones en la memoria e implementación de mejoras
en el sistema.
Trabajo fin de grado
52 Jorge Prieto Martin
8. Diseño del sistema
8.1 Notas generales
La solución del problema vendrá especificada de la siguiente forma.
El sistema contará con un usuario generador. Este usuario generador, será capaz
de crear los mensajes que serán enviados a los usuarios consumidores.
El usuario consumidor será el usuario que recibirá las alertas que el usuario
generador envía.
En este apartado, se diseñará las aptitudes básicas del sistema y su
funcionamiento.
Como componentes principales tendremos:
• Usuario generador
• Usuario consumidor
• API (sistema)
• Mensaje
• Área del mensaje
Trabajo fin de grado
53 Jorge Prieto Martin
Ilustración 2 - Caso de uso del sistema servidor. Fuente propia
8.2 Fase 1ª – Diseño básico de comunicación cliente-
servidor-cliente
8.2.1 Funcionamiento
El usuario generador cuando quiere enviar un mensaje al sistema, deberá
identificarse para acceder a éste. El sistema, conociendo el tipo de usuario que
es al identificarse, dada la organización a la que pertenece, podrá saber cuál
serán las áreas a las que tiene acceso a enviar el mensaje.
El área donde se enviará el mensaje, lo indicará el usuario generador una vez
haya recibido la lista de sus áreas disponibles generadas por el sistema. Estas
listas de áreas disponibles se otorgarán a un usuario generador cuando se
registra en el sistema y se le vinculará un área, recinto o uso dependiendo a la
organización que pertenezca, siendo ésta ultima la que tiene que indicar la
Trabajo fin de grado
54 Jorge Prieto Martin
potestad del usuario. De esta manera, cuando un usuario generador, envíe al
sistema un mensaje, éste indicará sobre qué área enviarla y el sistema
identificará al usuario, comprobará los permisos y si efectivamente concuerda
el permiso otorgado con las capacidades del mensaje, éste será almacenado en
el sistema hasta que un usuario consumidor haga una consulta. A esta área se
le dará un radio de efecto, que por defecto será superior al área a cubrir, de esta
forma nos aseguramos que el mensaje será enviado a esa zona y a sus
alrededores.
Por otra parte, el usuario consumidor, irá enviando notificaciones al sistema
cada cierto tiempo, con su información de posicionamiento, así el sistema, al
recibir una notificación de un usuario, comparará el área de efecto de los
mensajes almacenados, con las coordenadas enviada del usuario consumidor,
si ésta coincide con el área de efecto del mensaje, se le enviará el mensaje.
Ilustración 3 - Esquema de la comunicación cliente-servidor-cliente. Fuente propia.
Trabajo fin de grado
55 Jorge Prieto Martin
8.3 Fase 2ª – Diseño básico de comunicación cliente-
cliente
Cuando un usuario consumidor reciba un mensaje de forma satisfactoria,
empezará a emitirlo por el medio usando la tecnología wifi de su dispositivo,
el resto de usuarios consumidores incapaces de conectarse al servicio del
servidor, entrarán en modo de búsqueda para recibir mensajes vía wifi. Así
pues, con solamente una persona con acceso al servicio, se podría llegar a
difundir el mensaje en toda el área.
Para facilitar la difusión de la información de manera correcta y para evitar
colisiones, se tomarán varias medidas:
• El mensaje tendrá un tiempo de vida, por el cual, una vez finalizado,
dejará de retransmitirse para evitar que el mensaje circule entre
dispositivos de forma indefinida.
• Si el mensaje es recibido por un dispositivo que se encuentra fuera del
área, será descartado
Ilustración 4 - Esquema de la transmisión de un mensaje. Fuente propia.
Trabajo fin de grado
56 Jorge Prieto Martin
8.3 Fase 3ª – Diseño básico de comunicación cliente-
cliente en un entorno desconectado
Existirán situaciones en las que, por alguna razón, un usuario generador sea
incapaz de conectarse a internet para generar un mensaje, pero se encuentre
cerca o en la misma zona afectada y desea generar un mensaje para avisar en
toda la zona del posible peligro.
Por esto, se implementará la opción de poder crear un mensaje y poder enviarlo
vía wifi desde un dispositivo sin conexión a internet. Las características del
mensaje serán las misma a crear desde un dispositivo online, pero se tendrá
especial cuidado en algunos aspectos.
Ilustración 5 - Esquema de la creación y transmisión de un mensaje cuando no existe conexión a internet en el área.
Fuente propia.
Por ejemplo, si la zona no estuviera registrada en el sistema, y se necesitara
obtener las coordenadas actuales de nuestro dispositivo, comprobaremos que
podemos acceder a las últimas coordenadas almacenadas en éste. De no tener
Trabajo fin de grado
57 Jorge Prieto Martin
ninguna coordenada disponible, los otros dispositivos que recojan el mensaje,
deberán asignarles sus propias coordenadas y aumentar el área del mensaje en
20 metros, para salvar el posible error de distancia que puede haber entre el
usuario generador y el usuario consumidor cuando se envíe el mensaje. Si este
usuario consumidor tampoco tuviera coordenadas accesibles, el próximo
usuario en recibir el mensaje haría lo mismo y así sucesivamente. Esto podría
dar a que el mismo mensaje se extendiera con diferente coordenada de origen,
pero no surge mayor problema ya que también tendrá un id introducido
automáticamente y éste sí que será introducido desde el usuario generador que
esté creando el mensaje.
Ilustración 6 - Esquema de la creación y transmisión de un mensaje sin conexión y sin acceso a las coordenadas. Fuente
propia.
El aumento de 20 metros el área no es algo aleatorio, si no que se estima que la
señal wifi que emite un dispositivo común puede alcanzar los 20 metros sin
pérdida de señal, por lo tanto, si un dispositivo recibiera un mensaje sin
coordenadas se estima que estará a un máximo de 20 metros del dispositivo
origen. Se aumenta para prevenir la perdida de este mensaje ya que es mejor
que llegue 20 metros extra en una zona a que no llegue.
Trabajo fin de grado
58 Jorge Prieto Martin
8.4 Diseño de un mensaje
El mensaje incorporará y se le podrá dar unas ciertas características. Por una
parte, el usuario generador podrá decidir el tiempo de vida del mensaje,
estableciendo el propio sistema un máximo de tiempo que se le pueda asignar
dado que el objetivo es la difusión de información urgente haciendo esta
información valida solo por un periodo de tiempo concreto, también se podrá
determinar el texto en sí del mensaje a enviar, la zona a enviarse o las
coordenadas de un punto y el área de efecto. Una vez enviado y almacenado en
el sistema, éste comprobará el usuario que lo ha enviado y le asignará el tiempo
de creación y un id único. Una vez el sistema haya encontrado un usuario
consumidor que se encuentre dentro del área del mensaje, se le enviará el
mensaje, junto con todas las características mencionadas anteriormente.
Cuando el usuario consumidor reciba el mensaje, comenzará a escuchar
peticiones de otros dispositivos cercanos e irá comprobando el tiempo de vida
restante del mensaje, para sí se ha excedido ese tiempo de vida, dejar de
enviarlo y descartarlo. Cuando un usuario consumidor reciba el mensaje con el
mismo id del mensaje que está reenviando, éste será rechazado. Si un usuario
consumidor recibe un mensaje con un id que no coincide con ningún mensaje
que esté retransmitiendo, a continuación, comprobará que los datos de área
(longitud y altitud) están dentro de su rango, en caso contrario, también se
descartaría.
Trabajo fin de grado
59 Jorge Prieto Martin
Ilustración 7 - Esquema del contenido de un mensaje. Fuente propia.
8.5 Área de actuación
Las áreas de actuación vendrán definidas en el sistema por el usuario
administrador, y siempre éste podrá añadir nuevas áreas siguiendo las
necesidades y peticiones de las organizaciones y los usuarios generadores.
Existen dos formas de determinar un mensaje para un área. La primera se podrá
elegir entre un conjunto de áreas ya definidas, dependiendo del tipo de usuario
generador y a la organización que pertenezcamos podremos acceder a unas
zonas u otras. La segunda forma de determinar un mensaje es por coordenada,
podremos determinar la coordenada a la que enviar el mensaje y un área de
alcance que será el radio de efecto de ese mensaje. Esta segunda forma también
estará limitada dependiendo del usuario generador y a la organización que
pertenece.
Al final, el sistema lo que almacena es una coordenada y un radio de efecto en
metros.
Trabajo fin de grado
60 Jorge Prieto Martin
Cuando se quiera generar un mensaje por coordenadas, pero no se tiene acceso
a internet para determinar la geolocalización, se establecerán las últimas
coordenadas guardadas. A su vez, si un usuario consumidor recibe un mensaje
y no puede acceder a su geolocalización, se aceptará igualmente, ya que es
preferible que, si no se está seguro de la localización de un usuario, éste reciba
el mensaje a ser descartado.
8.6 Diseño del usuario administrador
El usuario administrador será el encargado de administrar las organizaciones,
los usuarios generadores y las zonas.
El usuario podrá dar de alta a una organización y asignarle unas zonas de
difusión. La organización quedará limitada por estas zonas y los usuarios
generadores de esta organización podrán enviar mensajes a todas esas zonas
como máximo. Por ejemplo, si a una organización se le otorgan la zona Madrid
y Alicante, un usuario generador que pertenezca a esa organización, podrá
enviar un mensaje a la ciudad de Alicante , Madrid, ambas, o ninguna según
los permisos que tenga.
Con esta norma, se evita que cualquier organización pueda enviar un mensaje
a cualquier zona.
El usuario administrador, también se encargará de limitar las zonas a las que
un usuario generador puede enviar un mensaje. Esto se debe a que una
organización le puede no interesar que todos los usuarios pertenecientes a ésta
puedan operar en todas las zonas.
Otra responsabilidad del usuario administrador será la de generar zonas a las
que se pueda enviar un mensaje a petición de las organizaciones y los usuarios.
Para generar la información de una zona, el administrador tendrá que generarle
un nombre, una coordenada y un radio.
Trabajo fin de grado
61 Jorge Prieto Martin
8.7 Diseño del usuario generador
El usuario generador será parte de una organización, la cual tendrá un número
de zonas donde actuar. Los usuarios tendrán las mismas zonas que pueda tener
la organización o menos, nunca otras que no pertenezcan a la organización.
Estas zonas determinarán el área de efecto del mensaje a enviar. Así, cada
usuario vendrá limitado por su organización, qué a su vez, estará limitada
aplicándole ciertas medidas de seguridad y dependiendo del tipo de
organización (las zonas a utilizar serán diferentes para un organismo público y
para una empresa privada).
Por otra parte, habrá ciertas organizaciones que puedan enviar mensajes en
ciertas áreas que ellos determinen a la hora de crear el mensaje. Así, podría
interesar enviar un mensaje en cierta área determinada que no comprenda las
zonas preestablecidos.
Ilustración 8 - Esquema de la relación de las zonas y los usuarios. Fuente propia.
Trabajo fin de grado
62 Jorge Prieto Martin
8.8 Diseño del usuario consumidor
El usuario consumidor podrá dividirse en dos categorías dependiendo de su
acceso al medio
• Usuario en modo online
o Éste usuario tiene conexión a internet y es capaz de enviar
notificaciones con su posición al servidor. Cuando el servidor
conteste con un mensaje, el usuario consumidor empezará a
transmitirlo de manera multidifusión.
• Usuario en modo offline
o Éste usuario carece de alguna conexión a internet y, por lo tanto,
se prepara para poder recibir mensajes de otros usuarios. Al recibir
un mensaje, comprobará si está dirigido para él (se encuentra
dentro de su zona), de no ser así, lo descartará y en caso de qué sí
se encuentre dentro de su área, al igual que el usuario online,
empezará a reenviarlo de manera multidifusión.
Trabajo fin de grado
63 Jorge Prieto Martin
Ilustración 9 - Diagrama de flujo del sistema básico. Fuente propia.
8.9 Seguridad
En este apartado veremos todas las medidas de seguridad a tener en cuenta para
el sistema
8.9.1 Seguridad en el acceso al sistema y generación del
mensaje
El sistema está enfocado a que pueda ser utilizado en cualquier momento y por
cualquier persona, pero, cuando se trata de crear un mensaje que luego puede
llegar a una gran cantidad de gente, hay que tener ciertas medidas de seguridad
y no permitir que un usuario sin permisos para ello, pueda crear un mensaje
malintencionado.
Para el acceso al sistema, se implementará una identificación de Usuario y
Contraseña que se guardarán en el sistema. App Engine nos permite guardar la
contraseña de manera cifrada para evitar que la información del usuario pueda
verse comprometida.
Trabajo fin de grado
64 Jorge Prieto Martin
Una vez el usuario se ha identificado, se le permitirá crear mensajes. Como una
cuenta de un usuario siempre puede verse comprometida, se hará una
comprobación extra a la hora de enviar un mensaje al sistema. Se han propuesta
tres posibles soluciones para este problema:
1.Tarjeta de coordenadas
Administrar a cada usuario generador una tarjeta de coordenadas 12, de la cual
se pedirá una coordenada para verificar la autenticidad del usuario y poder
enviar el mensaje al servidor.
Esta solución requiere almacenar en el sistema una matriz de coordenadas por
cada usuario, con valores generados de forma aleatoria, que se guardarían de la
siguiente forma MatrizUsuario[i][j] = numero_random;
El sistema controlará los intentos fallidos, y de darse tres intentos fallidos
seguidos, se bloqueará la cuenta hasta que la organización del usuario
controlador se ponga en contacto con el usuario administrador para que vuelva
a desbloquear la cuenta (y generando una contraseña nueva).
A la hora de la implementación, es la más costosa si se quiere otorgar esta
tarjeta de forma física al usuario.
2. Código extra de confirmación
Este tipo de seguridad se basa en enviar un código al email del usuario que
tendrá que introducir en el sistema para poder enviar el mensaje. Cuando el
usuario haga la petición de envío al sistema se generará un código numérico de
forma aleatoria que se enviará al email registrado del usuario. Luego se esperará
durante un periodo fijo de tiempo la respuesta del usuario con el código enviado
por email. Si éste es el correcto, se guardará el mensaje en el sistema, de lo
12 Definición tarjeta de coordenadas: https://es.wikipedia.org/wiki/Tarjeta_de_coordenadas
Trabajo fin de grado
65 Jorge Prieto Martin
contrario o si el periodo de espera ha terminado, se rechazará. Al igual que con
la tarjeta de coordenadas, el sistema controlará los intentos fallidos, y de darse
tres intentos fallidos seguidos, se bloqueará la cuenta hasta que la organización
del usuario controlador se ponga en contacto con el usuario administrador para
que vuelva a desbloquear la cuenta (y generando una contraseña nueva).
3. Confirmación ajena
La confirmación ajena, se basa en la confirmación del mensaje por otra persona
de la misma organización. Es decir, cuando un usuario generador envíe un
mensaje al sistema. Éste guardará una variable de estado que hasta que no sea
confirmada, el mensaje se quedará bloqueado y no se podrá enviar a nadie. Para
confirmar este mensaje, otro usuario de la misma organización lo tendrá que
validar. La forma de validarlo se puede dar de dos maneras, aunque al final solo
se implementará una en el sistema:
1. Introduciendo en el sistema, el id del mensaje y un código numérico
aleatorio. Estos datos se mostrarán en la interfaz del usuario generador
que creó el mensaje y deberá comunicar al otro usuario de la
organización para que los pueda introducir. Esta solución también tendrá
un tiempo de respuesta y un máximo de intentos seguidos, bloqueando
al usuario si éste cometiera tres de ellos de manera consecutiva.
2. Permitiendo a cualquier usuario de la organización, confirmar los
mensajes, mostrándose todos los mensajes pendientes por validar, y que
no sean mensajes propios, mediante una interfaz. Esta segunda solución
debe ir complementada con el sistema de código extra de confirmación
para reforzar la seguridad.
Después de analizar las propuestas de seguridad anteriores, y teniendo las
limitaciones y costes de cada una en cuenta, se valora como la mejor opción
una combinación entre la confirmación ajena y el código extra de confirmación,
Trabajo fin de grado
66 Jorge Prieto Martin
donde primero se pedirá introducir un código de confirmación que se enviará
vía email al usuario que envía el mensaje, y luego otro usuario de la misma
organización deberá confirmar el mensaje introduciendo a su vez otro código
de confirmación que se enviará al email de éste.
Ilustración 10 - Diagrama del sistema de seguridad al enviar un mensaje al servidor. Fuente Propia
En la figura anterior, podemos observar como un usuario envía un mensaje al
sistema, y éste le responde con un código de confirmación enviado al email
relacionado con este usuario. Éste usuario contesta con la clave correcta y el
mensaje se almacena en el sistema pero no se activa, luego, otro usuario de la
misma organización, quiere validar el mensaje, y el servidor responde
generando otro código de confirmación diferente y enviándolo al email
asociado a este usuario, éste, responde de manera correcta, con lo cual el
mensaje se activa para poder ser enviado por peticiones de usuarios
consumidores.
Trabajo fin de grado
67 Jorge Prieto Martin
8.9.2 Seguridad en la creación y envío de un mensaje en
entorno offline
Hemos comprobado en el punto anterior, todas las medidas de seguridad que
se pueden dar cuando se envía un mensaje en el sistema, el entorno conectado
y el propio sistema nos ayuda a ejecutar estas pautas de seguridad, pero, ¿qué
ocurre cuando un usuario generador, crea un mensaje para enviarlo de forma
online? En este escenario, no podemos ayudarnos del sistema servidor para
confirmar la identidad del usuario, pero debemos tomar igualmente alguna
medida de seguridad para confirmar de alguna forma que no se está suplantando
la identidad del usuario.
El primer paso a seguir a implementar será la creación de una contraseña
especial para el envío de los mensajes de manera offline, para ello, el usuario
deberá identificarse desde su dispositivo móvil en el sistema, éste paso requiere
de conectividad a internet. Una vez logueados en el sistema, podremos generar
una contraseña especial para la creación de mensajes, la cual se enviará una
confirmación de la contraseña (y no la contraseña en sí) al sistema, ésta
confirmación se deberá verificar de igual forma que cuando se envía un
mensaje de manera online y deberá ser aprobada por otro usuario de la misma
organización o introducir un código extra, una vez confirmado, el servidor nos
enviará una respuesta afirmativa, que nos permitirá almacenar y codificar en el
dispositivo la contraseña, usando el sistema KeyStore13 de Android. Esto nos
permitirá tener una contraseña validada en el servidor y almacenada en el
sistema para poder usarla como identificación a la hora de enviar un mensaje
offline.
Aun así, al no poder confirmar la identidad del usuario de una manera
fehaciente se tomará una medida extra de concienciación del usuario
13 Explicación del Keystore - https://developer.android.com/training/articles/keystore.html?hl=es
Trabajo fin de grado
68 Jorge Prieto Martin
consumidor, añadiendo una cabecera visible al mensaje a enviar avisando de
que el siguiente mensaje puede no ser totalmente fiable y hay que tomarlo con
precaución.
Para una implementación futura, el sistema de seguridad de huella digital
podría mejorar la identificación para la creación de mensajes offline.
8.9.3 Seguridad en las conexiones entre dispositivos
Existen varias medidas de seguridad tomadas en el momento de la conexión
entre dispositivos que afectan a los usuarios generadores y consumidores.
Cuando un usuario recibe mensajes, éste entra en un modo para compartirles
en el que muestra información sensible de la conexión, como el nombre del
SSID, la dirección IP y la contraseña.
Esta información irá codificada mediante criptografía simétrica14 por la cual
solo el que tenga la contraseña podrá descifrar la información, como sistema de
cifrado se usará AES15, ya que su implementación no es costosa y es de los
sistemas más difíciles de romper hasta el momento.
La utilización de criptografía simétrica supone otro problema, la contraseña
debe ser común para todos los dispositivos. No es buena práctica que la
contraseña se encuentre almacenada en el propio código de la aplicación, así
que se encontrará almacenada y codificada en el servidor, por lo tanto, para
obtenerla utilizaremos la criptografía asimétrica 16entre un dispositivo cliente y
el servidor para poder transmitir esta clave de forma segura. El algoritmo más
acertado para implementar esta parte es el RSA17, qué de momento, al igual que
AES se mantiene difícil de romper. Esta implementación, tiene un coste mayor
al de AES e implicar guardar una clave extra por cada usuario que solicite la
14 Criptografía simétrica - https://es.wikipedia.org/wiki/Criptograf%C3%ADa_sim%C3%A9trica 15 Sistema de cifrado AES - https://es.wikipedia.org/wiki/Advanced_Encryption_Standard 16 Criptografía asimétrica - https://es.wikipedia.org/wiki/Criptograf%C3%ADa_asim%C3%A9trica 17 Sistema de cifrado RSA - https://es.wikipedia.org/wiki/RSA
Trabajo fin de grado
69 Jorge Prieto Martin
contraseña para el cifrado AES, pero, esta solicitud solo se hará una vez por
dispositivo cuando éste se instale e inicie por primera vez.
Ilustración 11 - Diagrama de descifrado de la información del Access Point.
Una vez tenemos los datos descifrados de la conexión, el siguiente paso es
conectarnos al Punto de Acceso, éste punto de acceso se crea automáticamente
con seguridad WPA218, este mecanismo nos cifrará todas las conexiones en la
red utilizando el cifrado CCMP19 que a su vez está basado en el cifrado AES.
Esto nos asegura que tanto la conexión como los datos que van por ésta, son
seguros.
8.10 Emulaciones del sistema
Cuando observamos el alcance del proyecto, nos damos cuenta que es grande,
muy grande, demasiado como para poder abarcar todos los casos y escenarios
18 Información sobre la seguridad WI-FI WPA2 (Inglés) https://en.wikipedia.org/wiki/Wi-
Fi_Protected_Access#WPA2 19 Información sobre el cifrado CCMP (Inglés) https://en.wikipedia.org/wiki/CCMP_(cryptography)
Trabajo fin de grado
70 Jorge Prieto Martin
posibles qué se pueden dar en el sistema, la propia naturaleza del proyecto
como trabajo de fin de grado y los recursos disponibles limitan los escenarios
donde hacer pruebas. Por ello, necesitamos crear una simulación donde nos
permita recrear escenarios de cualquier dimensión con cualquier número de
dispositivos.
Este emulador contará con la capacidad de dejar variable el área de efecto de
los mensajes, en metros, y el número de dispositivos que se verán
comprometidos en esa área. Una vez tenemos esas dos variables establecidas,
el emulador empezará a asignar los dispositivos en diferentes puntos del área
de forma aleatoria, siempre evitando que dos dispositivos se encuentren en el
mismo punto. Después de hacer la asignación de todos los dispositivos, se elige
uno para que sea el dispositivo inicial que recibe el mensaje y empiece la
difusión de éste, el dispositivo inicial se marca con una “o” y el resto, con una
“x”.
El algoritmo de la emulación, cuenta con un bucle que irá analizando cada
dispositivo. Primero se comprueba que el dispositivo se ha marcado con una
“x”, si no fuera así, no se comprobaría ya qué significa que ese dispositivo ya
tiene mensajes.
Si se ha marcado con una “x” entraremos en otro bucle que irá analizando el
resto de dispositivos. En este bucle, si se encuentra una “o” en el dispositivo
analizado, es decir tiene mensajes, se procederá a comparar las dos coordenadas
de los dispositivos y dependiendo de la distancia entre ellos, asignaremos un
porcentaje de éxito a la hora de intentar recoger el mensaje.
Haciendo una prueba con dispositivos reales, se ha comprobado que, a partir
de unos 25 metros sin obstáculos, la conexión se hace muy difícil, por debajo
de los 20 metros, la conexión es estable, pero en alguna ocasión ha presentado
dificultades de conexión, y por debajo de los 15 metros, los dispositivos han
Trabajo fin de grado
71 Jorge Prieto Martin
funcionado siempre de manera correcta. Por lo tanto, la tasa de errores se queda
de la siguiente manera:
Distancia entre los dispositivos Porcentaje de error
Mayor de 25 metros 100%
Entre 20 y 25 metros 90%
Entre 15 y 19 metros 30%
Menor de 15 metros 10%
Aunque por debajo de los 15 metros, no se han dado nunca problemas en las
pruebas, se asimila un porcentaje mínimo, para tener en cuenta las
interferencias y obstáculos que puedan darse en un área.
Si finalmente, hay éxito a la hora de recibir el mensaje, el dispositivo pasará de
“x” a “o” y dejará de comprobar más dispositivos cercanos. Una vez analice
todos los dispositivos del área, se finaliza la fase y empieza otra vez, así hasta
que finalice por uno de los dos filtros que podemos establecer en el simulador.
Primero podrá terminar si le indicamos un número máximo de fases, es decir,
si establecemos 10 fases, entrará en el bucle 10 veces, para intentar conectar
todos los dispositivos que estén a “x”, y la otra forma de terminar, es,
indicándole un porcentaje mínimo de dispositivos desconectados, es decir,
ejecutará las fases necesarias hasta que haya un porcentaje exacto o menor de
dispositivos en el área con el estado “x”.
Trabajo fin de grado
72 Jorge Prieto Martin
9. Implementación de la propuesta
Podemos dividir la implementación de la propuesta en dos grandes bloques,
implementación en el lado del servidor y la implementación en el lado cliente
9.1 Implementación en el lado del servidor
La implementación en el lado del servidor se compone de una REST API para
comunicarse con el cliente y la base de datos. La API está diseñada mediante
servlets en Java.
Java Applet
Éste servlet dispone de un get principal donde recibe del cliente dos valores
en forma de coordenada, su longitud y su latitud.
Una vez recibe las coordenadas, hace una llamada a la base de datos para
comprobar todos los mensajes almacenados.
Como se ha visto anteriormente, estos mensajes disponen de una coordenada y
un área de efecto. Se calcula la distancia entre la coordenada del usuario y las
coordenadas almacenadas en el sistema mediante la fórmula de haversine20. La
cual acarrea un error despreciable dado que la formula se emplea para puntos
en una esfera y no en un elipsoide como es la tierra, este error se puede solventar
dando un mayor área de efecto al mensaje. La implementación del algoritmo
viene a ser el siguiente:
Si la distancia entre los dos puntos es menor o igual al área de efecto, se asume
que está dentro del área y por lo tanto se añade el mensaje a una lista que se
enviará en formato Json al cliente.
20 Fórmula de haversine - https://es.wikipedia.org/wiki/F%C3%B3rmula_del_haversine
Trabajo fin de grado
73 Jorge Prieto Martin
Ilustración 12 - Respuesta de una petición al servidor
El alojamiento de los servlets se hace en un servicio de Google llamado app
engine mediante maven. Este servicio nos proporciona una base de datos no-
sql de fácil implementación.
El desarrollo de los servlets se ha hecho con el IDE Eclipse.
Ilustración 13 - Diagrama de la arquitectura de la consulta de mensajes. Fuente propia.
Trabajo fin de grado
74 Jorge Prieto Martin
9.2 Implementación en el lado del cliente
Para el lado del cliente se ha decidido crear una aplicación en Android,
utilizando Java y Android Studio como herramientas.
La implementación en el lado del cliente, a su vez, se divide en varias que
pueden ser no consecutivas.
-Fase de geolocalización
-Fase de creación de grupo y servicio
-Fase de búsqueda de servicio
-Fase de conexión e intercambio de datos
-Fase de reenvío
-Fase de desconexión
9.2.1 Fase de geolocalización
Esta fase sólo será utilizada para el usuario con conexión a internet. Aquí el
usuario informa de su posición cada vez qué cambia, enviando sus coordenadas
a la API que hemos visto en la implementación en el lado del servidor.
Se utiliza una de las api listener-gps de Android qué nos avisa cuando nuestra
posición ha cambiado. Así cada vez que cambia la posición y usando la librería
Volley qué facilita la llamada REST API la cual nos responderá con
información de algún mensaje, si lo hubiera. En el momento en el que se recibe
un mensaje de forma satisfactoria, se pasa a la fase de creación de grupo y
servicio.
9.2.2 Fase de creación de grupo y servicio
Esta fase puede ser accedida por cualquier usuario que haya recibido un
mensaje de cualquier forma.
Trabajo fin de grado
75 Jorge Prieto Martin
Para esta fase se utiliza principalmente Wifip2pManager. La clase
Wifip2pManager nos permite utilizar funcionalidades wifi, cómo crear un
Access point y conectar dispositivos de wifi-direct (de manera p2p).
Lo primero que hace esta fase, es crear un grupo. La creación de un grupo
implica la generación de una red wifi y un Access Point en nuestro dispositivo.
La seguridad de la red que se genera por defecto es WPA2 PSK y el SSID
también se genera de forma automática pudiendo ser reconocido por “DIRECT-
XX-modelo” siendo xx dos letras del abecedario y modelo, cómo el modelo del
móvil.
Ilustración 14 - Captura con la información del Access Point. Fuente propia.
Trabajo fin de grado
76 Jorge Prieto Martin
Cuando creamos un grupo, tendremos el Access Point listo para recibir
conexiones, pero falta comunicar de alguna forma a los dispositivos cercanos
de que tenemos un punto de acceso y estamos listos para recibir conexiones y
enviar mensajes, esto lo podemos conseguir con la creación de un servicio. Esto
nos permitirá, en forma de multidifusión, avisar a los demás dispositivos de que
se pueden conectar al nuestro y proporcionarles la información suficiente para
hacerlo.
Para el servicio, a diferencia del grupo, sí que podemos darle el nombre qué
queramos. Por lo tanto, aprovecharemos esto para pasarle junto al nombre del
servicio, la información necesaria para conectarse al punto de acceso, es decir,
el nombre del ssid, el password de la red y la ip del dueño del grupo (la ip
también la puede obtener el cliente una vez conectado al grupo).
El nombre del servicio tendrá la siguiente apariencia
TFGAPP:ssid:password: group_ip
Así cuando otro dispositivo busque servicios, recibirán como nombre de
servicio, por ejemplo, TFGAPP: DIRECT-lw-Onetouch:1234:192.168.45.1. Al
analizar la primera parte del nombre TFGAPP, el dispositivo que está buscando
servicios, sabrá que es un servicio adecuado para conectarse.
Una vez el servicio se ha creado de forma satisfactoria, abriremos un server
socket a la espera de conexiones para poder enviar los mensajes.
9.2.3 Fase de búsqueda de servicio
Esta fase solo la implementará el usuario sin conexión, y se activará nada más
conectarse a la app y comprobar qué no hay conexión a internet, también,
cuando nuestra conexión cambie a modo no conectado.
Al igual que la creación de servicio, se utilizará la clase Wifip2pManager para
la búsqueda de servicios. El listener especial “DnsSdServiceResponseListener”
Trabajo fin de grado
77 Jorge Prieto Martin
encargado de esta tarea nos avisará y mostrará todos los servicios encontrados
a nosotros y su información.
Una vez tenemos el servicio, y gracias al formato del servicio que genera el
usuario conectado en la fase de creación de servicio, podemos analizar y
comprobar los servicios que nos interesa. Si encontramos un servicio de tipo
TFGAPP continuaremos reconstruyendo la información para la conexión del
grupo.
9.2.4 Fase de conexión e intercambio de datos
En esta fase intervienen los dos tipos de usuario. El primer paso lo da el usuario
desconectado que mediante la clase WifiManager, podrá conectarse a una red
wifi, conociendo su SSID y el password. Una vez conectado, se abrirá un socket
con el dueño del grupo, y cuya dirección ip conocíamos ya al descubrir el
servicio. Cuando el usuario offline conecta con el usuario conectado, éste
último le enviará la lista de mensajes que tiene en ese momento, incluyendo
toda la información qué el mismo ha recibido en formato json. El usuario
offline comparará sus coordenadas (las últimas guardadas en el sistema) y si
entran dentro del área del mensaje lo guardará, si no, lo descartará.
Una vez que el usuario offline recibe la información, cierra el socket y la
conexión al grupo, es decir se conecta de la red (por implementar) y a su vez,
creará un grupo y un servicio, es decir, empezará la fase de reenvío.
9.2.5 Fase de reenvío
Podemos definir esta fase como la fase de creación de grupo y servicio para un
usuario no conectado. Esta fase se comporta de manera exacta a la mencionada
fase.
Trabajo fin de grado
78 Jorge Prieto Martin
9.2.6 Fase de desconexión
Para que ocurra la fase de desconexión, es decir, dejar de buscar o crear
servicios y grupos, debemos estar en uno de los siguientes estados:
• El tiempo de mensaje ha caducado por lo tanto no es necesario seguir
reenviándolo.
• Se ha recuperado la conexión a internet y se deja de buscar servicios.
En cualquiera de los dos casos anteriores, el comportamiento es el mismo, el
usuario pasa a la fase de geolocalización, hasta que vuelve a recibir un mensaje
y vuelve a la fase de creación de grupo y servicio, o pierde la conexión a
internet, con lo cual pasaría a la fase de búsqueda de servicios.
Ilustración 15 - Diagrama de las fases y sus transiciones. Fuente propia.
9.3 Iteraciones
A continuación, siguiendo la metodología escogida para el desarrollo de la
propuesta, se van a ir describiendo todas las iteraciones por las que se han
Trabajo fin de grado
79 Jorge Prieto Martin
pasado en el desarrollo, si bien, hay que tener en cuenta, qué en algunas
iteraciones, el desarrollo y la documentación no han ido en paralelo y pueden
apreciarse implementaciones extra en algunas fases tempranas.
9.3.1 Iteración 0 – Testeo del sistema inicial
Lo primero a hacer, y dado la falta de experiencia con el desarrollo de Android,
es, crear pequeñas aplicaciones que me permitan probar las API de Android, en
este caso, la API del gps.
También se invierte algo de tiempo en la investigación para descubrir la mejor
forma de sacar la distancia entre dos puntos del planeta y si hay alguna forma
ya integrada para hacerlo.
Usamos el IDE de Android, llamado Android Studio, una plataforma que nos
permitirá desarrollar en Java aplicaciones para Android.
Existen clases ya integradas en las librerías de Android para trabajar con
coordenadas, pero ninguna de base para calcular la distancia entre dos
coordenadas.
Se decide crear nuestro proprio algoritmo para el cálculo de coordenadas. Una
vez estudiado varios algoritmos de distancias entre dos puntos, se escoge la
fórmula de haversine por su sencilla implementación y su baja tasa de error.
Junto con este algoritmo, se implementa una sencilla interfaz por la que se
puedan introducir dos coordenadas, un botón para introducir directamente las
coordenadas de tu dispositivo, y otro botón para poder calcular la distancia
entre las dos coordenadas que saldrá como output en forma de texto en la
pantalla.
Se restringe el input de coordenadas a valores numéricos positivos y negativos.
Trabajo fin de grado
80 Jorge Prieto Martin
Ilustración 16 - Captura de la aplicación de prueba. Fuente propia.
Para comprobar que las distancias son correctas, se ha usado Google maps para
calcular las distancias.
Con esta primera iteración se ha podido comprobar el funcionamiento de la API
del gps y la implementación de una aplicación Android.
9.3.2 Iteración 1 – API
Para la primera iteración del desarrollo, necesitamos crear la parte del servidor.
Es decir, una API que nos deje recibir las peticiones de los usuarios, almacene
y devuelva la información de los mensajes al usuario.
Trabajo fin de grado
81 Jorge Prieto Martin
Herramientas
Para el desarrollo de la API, vamos a usar un IDE diferente al que usamos para
el desarrollo de la app. Usaremos el entorno Eclipse, para desarrollo en Java,
ya que la API también será desarrollada en Java. Además, para el hosting de la
API y la BD, vamos a utilizar el servicio App Engine de Google, que permite,
de forma gratuita el hosting de APIs y creación de base de datos no-sql.
Además de la IDE Eclipse, el tipo de proyecto a crear, será un proyecto
MAVEN, esto nos permitirá la creación de aplicaciones web qué además
permiten la sincronización con la app engine de Google de manera muy
sencilla.
Implementación
El primer paso es implementar una clase de tipo GETTER que nos permita leer
las coordenadas de la URI.
Una vez tenemos las coordenadas del usuario, y gracias a la clase Query de
appengine, podremos acceder a todos los mensajes creados en la base de datos.
Luego por cada mensaje, utilizaremos las coordenadas para obtener la distancia
entre ésta y la coordenada recibida de la uri para determinar la distancia que
existe, y también utilizaremos la distancia para comprobar que si es menor o
igual a la distancia obtenida en el paso anterior, se introducirá ese mensaje en
un objeto JSON para devolverlo como respuesta.
Si no se encuentra ningún mensaje, se devolverá un array vacío.
Resultado
Para poder probar esta primera fase del desarrollo, necesitaremos introducir
mensajes en el sistema directamente desde la página de App Engine. De
momento, solo se van a introducir cuatro alarmas, para las pruebas, una en la
Trabajo fin de grado
82 Jorge Prieto Martin
zona del centro de alicante (coordenada central luceros, con un radio de un
kilómetro), otra en el mercado central (radio de un kilómetro), una en la plaza
manila (300 metros) y la última en la universidad (2 kilómetros).
Ilustración 17 - Captura de las entidades alarma. Fuente propia
Para proceder con las pruebas, debemos construir la URI adecuada, con la
coordenada precisa que nos permita comprobar qué, efectivamente, solo nos
aparezca los mensajes de las zonas en las qué me encuentro.
Un ejemplo, si escogemos una coordenada en la calle Alfonso el sabio de
Alicante, que conecta la plaza de los luceros y el mercado central.
Ilustración 18 - Mapa del centro de Alicante. Fuente: Google Maps
Trabajo fin de grado
83 Jorge Prieto Martin
Deberían aparecernos los dos mensajes almacenados, ya que los radios de las
dos zonas comprenden la coordenada insertada.
Ya solo debemos construir la URI de la siguiente forma en nuestro navegador:
http://tfg-wifi.appspot.com/getmessages?latitud=38.347052&longitud=-
0.488053
Y si todo ha ido correcto, aparecerán los objetos json de los dos mensajes
Ilustración 19 - Respuesta JSON del servidor.
9.3.3 Iteración 2 – Llamada de la API desde la APP
Herramientas
Al igual que en la iteración 0, vamos a desarrollar la APP en Android Studio,
utilizando Java como lenguaje de programación. Para esta parte vamos a
trabajar con el GPS del dispositivo, para ello, necesitaremos las librerías
Location de Android para poder interactuar con nuestro GPS y obtener las
coordenadas.
Trabajo fin de grado
84 Jorge Prieto Martin
También para procesar las llamadas Http Request que necesitamos hacer al
servidor, implementaremos la librería Volley, recomendada por Android, para
poder hacer de manera sencilla éstas peticiones y almacenar el objeto JSON
que nos será devuelto.
Implementación
Una vez tenemos la API implementada y ofreciendo un servicio, ya podemos
desarrollar la app. El primer paso será usar el GPS del dispositivo móvil para
averiguar nuestras coordenadas, algo que ya se ha aprendido a hacer en la
iteración 0, y poder enviarlas al servidor para qué nos conteste con el mensaje.
Para esta fase primero se ha implementado un botón qué gracias a la API qué
gestiona el sensor GPS de Android, podemos obtener las últimas coordenadas
almacenadas.
Una vez probado qué funciona de manera exitosa, el siguiente paso es qué
automáticamente, y cada vez que se cambia mi posición geométrica, haga una
petición al servidor con esas coordenadas.
Gracias a la clase LocationListener, que proporciona Android, podemos
implementar esta opción, así cada vez que nuestras coordenadas cambian
enviaremos una petición al servidor.
Existen dos maneras de obtener la Localización, desde el GPS de nuestro móvil
o desde nuestra conexión, tenemos que tener en cuenta que por lo general sólo
uno puede estar activado, así que debemos comprobar y manejar los errores qué
nos puedan devolver un valor NULL uno de ellos.
Para hacer la petición y luego guardar el objeto JSON que recibimos, usaremos
la clase JsonArrayRequest que nos ofrece la librería Volley. Como parámetros
debemos introducir la URL con los parámetros qué en este caso serán la
longitud y latitud que hemos podido obtener con la clase Location.
Trabajo fin de grado
85 Jorge Prieto Martin
Tendremos una función onResponse que nos devolverá un JsonArray como
respuesta qué tendremos que sobrescribir para indicar que queremos hacer con
este array. De momento para estas primeras fases, nos interesa sobre todo coger
el atributo mensaje de las alertas para poder mostrarlo por la pantalla del
dispositivo.
Resultado
Hemos creado para esta parte, dos campos en pantalla, uno será un textbox para
poder conocer el estado del GPS y qué coordenadas se envían, éste textbox, no
estaría implementado en la parte final. El otro campo, es un listbox donde se
nos mostrará el campo mensaje de todas las alertas que se encuentren cerca de
nosotros.
Trabajo fin de grado
86 Jorge Prieto Martin
Ilustración 20 - Captura de pantalla con los mensajes de información sobre el gps. Fuente propia.
En la primera pantalla, podemos observar qué el GPS se encuentra
deshabilitado. Una vez lo habilitamos, podremos ver cómo cambia el texto, ya
qué se ha establecido que muestre el objeto JSON y en la parte central, vemos
solo el campo mensaje.
Trabajo fin de grado
87 Jorge Prieto Martin
Ilustración 21 - Captura de pantalla con el mensaje recibido en formato JSON y el texto de la alerta. Fuente propia.
9.3.4 Iteración 3 – Creación de grupo y servicios
Herramientas
Para esta fase haremos bastante uso de la librería wifip2p de Android, que
permitirá crear el núcleo del proyecto, es decir, la primera fase para poder
conectar dispositivos mediante wifi.
Implementación
Si bien antes de esta iteración se hizo pruebas con botones para la creación de
grupos y servicios, pasaremos a explicar la forma automática en esta sección.
Trabajo fin de grado
88 Jorge Prieto Martin
Como se ha explicado anteriormente, la creación de un grupo no es más que la
creación de una red local y de un Access Point.
Para esto utilizaremos la clase ManagerP2P qué nos permitirá crear un Grupo,
también, creamos unos Listeners asociados a este grupo qué se activarán, por
ejemplo, cuando el grupo esté activo o se agreguen nuevos miembros al grupo.
Cuando el grupo esté creado, usaremos el listener
WifiP2pManager.WIFI_P2P_CONNECTION_CHANGED_ACTION.equals(a
ction) que nos avisa de que el grupo ha sido creado, para a continuación crear
el servicio que nos permita mostrar a otros usuarios la información del grupo.
Al igual que con el grupo, para el servicio también utilizaremos la clase
ManagerP2P utilizada anteriormente. Con la función RequestGroupInfo,
podremos recibir la información del grupo, que incluye, el SSID, la contraseña
del Access point y la dirección IP del creador del grupo.
Con toda esta información, podremos crear la clase WifiP2pDnsSdServiceInfo,
que nos permite generar el nombre de servicio. A este nombre le daremos un
formato especial para evitar confusiones con otros servicios que puedan existir,
poniéndole como prefijo TFGAPP y separando cada campo entre “:” para poder
leerlo bien por parte de otros usuarios.
Por último, se llamará a la función addLocalService para generar el servicio. Si
creamos un grupo y su servicio de forma satisfactoria, lo indicaremos en la
pantalla, igualmente si existe algún fallo.
Por otra parte, y como parte de la misma iteración ya que las pruebas son
conjuntas, se crear otra clase ManagerP2p qué en lugar de crear un grupo y un
servicio, su misión es la de crear un Listener de servicios. La clase
WifiP2pDnsSdServiceRequest nos permitirá poner en escucha al dispositivo en
busca de servicios y la función onDnsSdServiceAvailable será llamada cada vez
que un servicio entre en la zona del usuario.
Trabajo fin de grado
89 Jorge Prieto Martin
Resultado
Para la iteración 3, no cambia nada del diseño, lo único que se añade es otro
textbox, para ir comprobando que los pasos de creación y escucha de servicio
se hacen correctamente.
Ilustración 22 - Captura de pantalla con la información del servicio activado. Fuente propia.
Mostramos, solamente para pruebas, que el grupo y servicio ha sido creado,
podemos ver el nombre del ssid, la contraseña y la ip.
Trabajo fin de grado
90 Jorge Prieto Martin
Ilustración 23 - Captura de pantalla de un usuario consumidor que está buscando servicios. Fuente propia.
Si el dispositivo no tiene conexión, entraremos en el modo de escucha de
servicios. Si todo va correctamente, nos aparecerá el mensaje “Success service
request” por pantalla.
9.3.5 Iteración 4 – Conexión entre dispositivos
Herramientas
En este paso, utilizaremos además de las clases Wifip2p que nos ofrece
Android como es Wifip2pManager, también usaremos las de clase Wifi, como
por ejemplo WifiManager qué nos permitirá la conexión con un Access Point.
Trabajo fin de grado
91 Jorge Prieto Martin
Implementación
En esta iteración, implementaremos parte de la funcionalidad más importante
del sistema. La conexión de dispositivos mediante Wifi. En el paso anterior lo
dejamos todo preparado con un Access Point a la escucha y esperando recibir
conexiones.
Para poder comprender este paso, primero explicaremos la primera fase de esta
iteración y el problema a resolver y la solución que se ha escogido para la
segunda fase.
Primera fase
La primera fase consistía en conectar los dispositivos con la clase ya
predeterminada para ello de Wifip2p. Con esto, una vez creado un grupo, solo
hacía falta llamar a la función prediseñada connect de Wifip2pManager que
permite la conexión directa de un grupo o un dispositivo conociendo la
dirección de éste, cosa que se puede obtener desde un servicio.
Al implementar esta fase, se comprueba que, efectivamente, la conexión
funciona, pero surgen varios problemas. El primero de ellos es, que no se puede
conectar de forma automática y se necesita que el usuario del dispositivo que
ha creado el grupo, acepte manualmente al dispositivo entrante. Esto supone un
retraso muy grande a la hora de expandir y reenviar un mensaje a muchos
dispositivos en poco tiempo y también choca con la naturaleza del proyecto qué
quiere actuar como si de un servicio en el background del móvil se tratara. El
segundo problema es, que, esta función connect es solo posible en dispositivos
con Wifi-Direct, a día de hoy instalado en la mayoría de dispositivos pero
ciertamente, cuantas menos restricciones se imponga al usuario final, mayor
utilización del servicio.
Trabajo fin de grado
92 Jorge Prieto Martin
Segunda fase
Una vez se ha determinado los problemas que nos complican el desarrollo y la
naturaleza del proyecto, se decide buscar por una alternativa. En lugar de
utilizar la clase predeterminada Wifip2pManager para hacer la conexión, se
usará la clase WifiManager, para simplemente conectarnos a una red wifi.
Para ello, los pasos que hay que seguir son los siguientes:
1. Creamos una clase WifiManager y otra clase WifiConfiguration.
2. Añadimos el nombre del SSID y la contraseña en WifiConfiguration.
3. Con WifiManager añadimos la información de la nueva red a nuestro
dispositivo.
4. Desconectamos cualquier conexión wifi que tuviéramos.
5. Activamos la nueva red añadida.
6. Nos reconectamos a la nueva red activada.
Resultado
Estas pruebas son las que más tiempo han llevado, ya que se ha demostrado un
comportamiento diferente por cada dispositivo utilizado y versión de Android
utilizada. Por lo general, el comportamiento es satisfactorio menos en los
dispositivos de marca Samsung, ya que, se ha probado en tres dispositivos
diferentes de esta marca y los tres presentan el mismo problema. Para crear
grupo y aceptar conexiones dos de los tres dispositivos no han dado ningún tipo
de problema, pero para luego conectarse a otros dispositivos de manera
automática, los tres han fallado. El problema reside en que hasta que no entras
manualmente en la configuración wifi de tu dispositivo, éste no parece detectar
la nueva red, así que, una vez entras en la configuración y se refresca la lista de
redes sí que procede a conectarse automáticamente.
Trabajo fin de grado
93 Jorge Prieto Martin
Sin embargo, las pruebas producidas en otros dispositivos (en el caso de las
capturas, dos modelos diferentes del fabricante Alcatel) son satisfactorias y los
dispositivos se comportan de la forma esperada.
Ilustración 24 - Captura de pantalla de un usuario emitiendo mensajes con otro usuario conectado. Fuente propia.
En la anterior captura se muestra cuando otro dispositivo se ha conectado al
dispositivo que está ofreciendo el servicio. Se ha añadido un texto con la
información de los dispositivos que están conectados a éste.
Trabajo fin de grado
94 Jorge Prieto Martin
Ilustración 25 - Captura de pantalla de un usuario conectado a otro usuario con mensajes disponibles. Fuente propia.
Por la parte del usuario sin conexión buscando servicio, podemos ver que una
vez se conecta, modificando la clase anterior de escucha de servicios, hemos
obtenido la información del servicio ofrecido por el otro dispositivo. Sin
embargo, lo importante es que se establece una conexión wifi.
Trabajo fin de grado
95 Jorge Prieto Martin
Ilustración 26 - Captura de pantalla con el Access Point del usuario con mensajes creado. Fuente propia.
Comprobamos que, efectivamente, la conexión ha sido con el dispositivo que
estaba con su servicio activado.
9.3.6 Iteración 5 – Envío de los mensajes
Herramientas
Para esta iteración haremos uso de Sockets. Utilizaremos la librería de sockets
que proporciona Java.
Implementación
Una vez tenemos a los dos dispositivos conectados, el usuario con los mensajes
y dueño del grupo enviará estos mensajes a todos los otros usuarios que se
conecten al Access Point.
Trabajo fin de grado
96 Jorge Prieto Martin
Para esto, una vez el usuario dueño del grupo ha terminado de generar el
servicio. Ha creado un ServerSocket que se quedará escuchando peticiones.
Este ServerSocket se debe crear de la siguiente manera, ServerSocket
serverSocket = new ServerSocket(puerto, backlog, dirección ip); ya que se
debe indicar la dirección IP por la que queremos estar escuchando. Al haber
creado una red nueva, si ya teníamos el dispositivo conectado a otra red, esto
generará dos direcciones IP diferentes, y por lo tanto se deberá indicar la
dirección IP de la nueva red que se ha creado, de lo contrario, podría
establecerse la otra IP y no se produciría la comunicación por sockets
correctamente.
Para la realización y pruebas del proyecto se dejará el socket 9999 escuchando
peticiones. Por la parte del usuario que se conecta al grupo, abriremos un socket
y haremos una petición al puerto 9999 y a la dirección IP del dueño del servicio
que guardamos anteriormente usando socket.connect((new
InetSocketAddress(dirección_ip, puerto)), intento_en_milisegundos); .
Haciendo una petición al puerto de una dirección ip por un tiempo concreto en
milisegundos.
El intercambio de datos, no es más que el envío de un ArrayList de tipo Alerta.
Una clase creada para guardar todos los datos de un mensaje. Los datos que
guardaremos en una clase de tipo Alerta, de momento los más comunes para
las pruebas, son los siguientes:
String id;
String mensaje;
double area;
double latitud;
double longitud;
int tiempo_vida;
Esto nos permite comprobar e intercambiar datos de manera más sencilla y
rápida. Así, una vez recibido el objeto de tipo ArrayList<Alerta> desde la
conexión con el socket, añadiremos a la lista de mensajes del ListView que
Trabajo fin de grado
97 Jorge Prieto Martin
hemos visto antes, el valor mensaje de cada Alerta del ArrayList para poder
visualizar en el dispositivo offline los mensajes qué nos ha llegado a través del
socket.
Como usuario consumidor offline, una vez cerramos el socket, cerraremos la
conexión con el grupo para evitar saturaciones en éste. El usuario consumidor
online, es decir, el dueño del grupo, seguirá escuchando peticiones y enviando
sus mensajes hasta que el tiempo de vida del último mensaje por enviar se
termine.
Resultado
Para poder comprobar esta iteración, mostramos los mensajes recibidos en el
dispositivo que no tiene conexión a internet.
Ilustración 27 - Captura del dispositivo buscando servicios. Fuente propia.
En la captura se nos muestra el dispositivo desconectado, cuando ya ha recibido
información de un servicio y procede a la conexión de ese dispositivo.
Trabajo fin de grado
98 Jorge Prieto Martin
Ilustración 28 - Captura de pantalla de un dispositivo conectándose a otro. Fuente propia.
En la captura podemos observar como en un momento la conexión wifi
aparece conectándose a una red, ésta es, la red creada por el otro usuario.
Trabajo fin de grado
99 Jorge Prieto Martin
Ilustración 29 - Captura de pantalla de un dispositivo después de recibir mensajes desde otro dispositivo. Fuente propia.
Y vemos que, al breve periodo de tiempo vuelve a desconectarse, mostrando
los mensajes recibidos desde el otro dispositivo.
9.3.6 Iteración 6 – Reenvío de los mensajes
Herramientas
Para esta iteración volveremos a utilizar la clase ManagerP2p, al igual que sus
listeners como vimos en la iteración 3.
Implementación
Esta iteración está enfocada en un usuario consumidor que ha recibido
mensajes desde otro dispositivo y se dispone e reenviarlos. La implementación
es muy sencilla y se reutilizarán elementos de la iteración 3.
Trabajo fin de grado
100 Jorge Prieto Martin
Lo siguiente a hacer después de desconectarse a la red wifi como se ha visto en
la iteración anterior, será crear un grupo para poder crear nuestra propia red y
un punto de acceso.
Una vez creamos el grupo con la función createGroup, éste llamará al listener
implementado en la iteración 3, que se encargaba de crear el servicio mostrando
nuestra información de conexión y siguiendo los mismos pasos y funciones de
un dispositivo conectado que ha recibido mensajes.
Resultado
Para comprobar la prueba de esta iteración, deberemos hacer los siguientes
pasos:
• Recibir los mensajes con un dispositivo A, conectado a internet.
• Recibir mensajes desde el dispositivo A a un dispositivo B que no tiene
conexión a internet.
• Recibir mensajes desde el dispositivo B a un dispositivo C, con los dos
dispositivos sin acceso a internet.
Se han utilizado los siguientes dispositivos para hacer las pruebas:
Dispositivo A : Samsung Galaxy Tab 4
Dispositivo B: Alcatel Idol 3
Dispositivo C: Alcatel Pixi 4
El dispositivo A, será el dispositivo conectado a internet. Se muestran las
siguientes capturas, primero, dando servicios y luego mostrando los
dispositivos conectados a él.
Trabajo fin de grado
101 Jorge Prieto Martin
Ilustración 30 - Captura de pantalla con el dispositivo A dando servicio. Fuente propia.
Trabajo fin de grado
102 Jorge Prieto Martin
Ilustración 31 - Captura de pantalla con el dispositivo A mostrando los dispositivos conectados a su red. Fuente propia.
A continuación, se muestran las capturas del dispositivo B, que una vez
conectado y recibido mensajes desde el dispositivo A está mostrando el servicio
creado y cuando se conecta el dispositivo C.
Trabajo fin de grado
103 Jorge Prieto Martin
Ilustración 32 - Captura de pantalla con el dispositivo B
dando servicio. Fuente propia.
Ilustración 33 - Captura de pantalla con el dispositivo C
mostrando los dispositivos conectados a su red. Fuente
propia.
Por último, se muestra una captura del último dispositivo, el C, que ha recibido
mensajes del dispositivo B y éste ha creado un grupo y mostrando el servicio
para conectarse
Trabajo fin de grado
104 Jorge Prieto Martin
Ilustración 34 - Captura de pantalla con el dispositivo C dando servicio. Fuente propia.
9.3.7 Iteración 7 – Creación de mensajes
Herramientas
Para esta iteración volveremos a crear una nueva petición en el servidor al igual
que crearemos y haremos uso de una nueva actividad en la app de Android.
Volveremos a utilizar la clase HttpServletResponse así como de la librería
Volley para las peticiones al servidor.
Implementación
El primer paso en esta implementación de dos partes, será crear una nueva clase
en el servidor que nos permite recoger los parámetros recibidos por la petición
HTTP, estos datos son todos los necesarios para insertar un mensaje en la base
Trabajo fin de grado
105 Jorge Prieto Martin
de datos, como puede ser las coordenadas, el texto del mensaje, el área, y el
tiempo de vida del mensaje.
Para añadir el mensaje en el datastore crearemos un objeto de clase
DatastoreService que nos ofrece la librería de appengine de Google y luego un
objeto de clase Entity de la misma librería para poder rellenar una nueva entidad
de tipo alarma y actualizarla en el servidor con la función put de la clase
DatastoreService.
Desde el otro lado del desarrollo, la parte del cliente, es decir, la app en
Android, se introducirá una nueva Actividad. Es decir, una nueva clase en java
que extiende de la interfaz Activity especial de Android para poder interactuar
con el entorno de éste.
Ésta nueva actividad, muestra un formulario para la creación de mensajes y dos
botones. Uno para enviar el mensaje al servidor qué se desarrollará en esta
iteración, y otro, que servirá para enviar nuestro mensaje de forma offline y qué
se desarrollará en la siguiente iteración.
Aunque no sea la prioridad en estas iteraciones, se ha establecido un poco de
seguridad, como por ejemplo dejar introducir solo valores numéricos a la hora
de introducir el área, el tiempo de vida y las coordenadas.
También se ha añadido un botón en la actividad principal de la aplicación para
poder acceder a esta nueva actividad.
Para poder enviar los mensajes al servidor, tendremos preparado el botón para
ello, que al igual que la funciona que enviaba solo las coordenadas al sistema
servidor, enviará a la siguiente URL http://tfg-wifi.appspot.com/setmessage los
datos del mensaje.
Trabajo fin de grado
106 Jorge Prieto Martin
Resultado
Para comprobar esta iteración, se creará un mensaje desde la app móvil, se
consultará en la base de datos y luego desde otro dispositivo comprobaremos
que se recibe de forma exitosa.
Ilustración 35 - Captura de pantalla con la nueva Actividad mostrando el formulario de creación de un mensaje. Fuente
propia.
El botón de “Mi posición” nos dejará introducir automáticamente nuestras
coordenadas, al igual que se hacía en la iteración 0.
Trabajo fin de grado
107 Jorge Prieto Martin
Ilustración 36 - Captura de pantalla mostrando un aviso sobre la creación del mensaje. Fuente propia.
Si el mensaje se crear de forma correcta, se volverá automáticamente a la
actividad principal, mostrando un mensaje Toast “Mensaje enviado
correctamente”
Para asegurar qué efectivamente el mensaje se ha creado, lo comprobaremos
en la base de datos de la app engine.
Trabajo fin de grado
108 Jorge Prieto Martin
Ilustración 37 - Entidades creadas en la base de datos del sistema. Fuente propia.
Para terminar la prueba, comprobamos que desde otro dispositivo llega el
nuevo mensaje.
Ilustración 38 - Captura de pantalla de un dispositivo recibiendo el nuevo mensaje introducido en el sistema. Fuente
propia.
Trabajo fin de grado
109 Jorge Prieto Martin
9.3.7 Iteración 8 – Creación y envío de mensajes offline
Herramientas
Para esta iteración trabajaremos en la misma clase que la iteración anterior, es
decir, la Actividad del formulario para crear un mensaje y que nos faltaba el
botón “Compartir Offline” para desarrollar. Haremos llamadas a funciones de
las que ya tenemos el código implementado como es el CreateGroup y
usaremos la clase Alerta.
Implementación
La implementación de esta iteración se ha llevado a cabo de forma rápida y
sencilla ya que la mayoría de los elementos ya estaban implementados y no se
requiere del sistema servidor.
Se ha creado una nueva función para administrar el botón de “Compartir
Offline” que creará un nuevo objeto de la clase Alarma con los datos recogidos
del formulario.
Como el id del mensaje se estaba asignando automáticamente desde la base de
datos, ahora se asignará un número cogiendo el id único que genera Android y
sumándole una constante numérica que aumenta con cada mensaje creado por
el mismo dispositivo, haciendo así un id único para cada mensaje.
También se comprobará que se han introducido las coordenadas, de no ser así,
se asignará un valor por defecto mayor a lo que podría ser una coordenada para
evitar errores y para poder controlar desde otro dispositivo si las coordenadas
introducidas son correctas.
Una vez creada la alerta, la introducimos en la lista de Alertas, actualizamos el
ListView para que la podamos ver en nuestro sistema y llamamos a la función
de crear grupo que hará que continúe todo el proceso de compartir un mensaje.
Trabajo fin de grado
110 Jorge Prieto Martin
Resultado
Para comprobar que todo funciona bien, creamos un mensaje sin conexión y
hacemos que lo reciba otro dispositivo sin conexión a internet.
1. El dispositivo que crea la alerta de manera offline y la envía:
Ilustración 39 - Captura de la pantalla de la creación de un mensaje.
Primero, el usuario introduce la información del mensaje a enviar. En esta
prueba, el usuario no le asigna coordenadas.
Trabajo fin de grado
111 Jorge Prieto Martin
Ilustración 40 - Captura de pantalla del mensaje offline enviado. Fuente propia.
Cuando le damos al botón compartir offline, nos sale un aviso de que el mensaje
se está enviando al área, y se nos muestra por pantalla.
Trabajo fin de grado
112 Jorge Prieto Martin
Ilustración 41 - Captura de pantalla cuando un dispositivo se ha conectado a nuestra red. Fuente propia.
En la última pantalla se observa como un usuario se ha conectado a nuestro
dispositivo y se dispone a recibir el mensaje.
2. El dispositivo que recibe la alerta:
Trabajo fin de grado
113 Jorge Prieto Martin
Ilustración 42 - Captura de pantalla de un dispositivo offline buscando servicios. Fuente propia.
Lo primero que hace el dispositivo desconectado es buscar servicios por su
zona.
Trabajo fin de grado
114 Jorge Prieto Martin
Ilustración 43 - Captura de pantalla con el usuario offline conectado a una red. Fuente propia.
A continuación, recibe un servicio y se conecta a la red del dispositivo que ha
levantado el servicio.
Trabajo fin de grado
115 Jorge Prieto Martin
Ilustración 44 - Captura de pantalla de un dispositivo que ha recibido un mensaje y lo está reenviando. Fuente propia.
Por último, vemos como recibe el mensaje creado por el otro dispositivo offline
y empieza a reenviarlo.
9.3.7 Iteración 9 – Implantación de mejoras y emulador
Esta iteración recoge todas las mejoras finales y las que se han ido haciendo a
lo largo de la vida del proyecto, así como el desarrollo del emulador.
Mejoras
A continuación, se listan las mejoras añadidas para el buen funcionamiento del
sistema algunas de ellas se han añadido en la última iteración para no entorpecer
o ralentizar las pruebas.
Trabajo fin de grado
116 Jorge Prieto Martin
• Petición de mensajes al servidor cada 5 minutos para evitar la saturación
al servidor.
• Filtración por coordenadas de mensajes recibidos en modo offline.
• Eliminación de mensajes del sistema cuando caducan.
• Borrado de grupo y cancelación del servicio cuando todos los mensajes
caducan.
Emulador
El desarrollo del emulador se ha hecho con el entorno de desarrollo NetBeans
con el lenguaje de programación Java.
Se ha creado la clase Punto2D para almacenar las coordenadas y sus valores.
Para la distancia entre dos puntos se ha utilizado el teorema de Pitágoras21. Para
imprimir los resultados en un archivo de texto, se ha hecho uso de las librerías
Java, BufferedWriter y FileWriter.
El algoritmo del programa es el siguiente:
1. Inicializar el número de dispositivos y el área.
2. Establecer un punto inicial conectado de manera aleatoria.
3. Establecer el resto de puntos desconectados de manera aleatoria.
4. Imprimir el resultado
5. Bucle que recorre todos los puntos
a. Si es un dispositivo desconectado entro en otro bucle para analizar
el resto de dispositivos.
i. Si es un dispositivo conectado comparo las distancias.
ii. Si la distancia es la adecuada intento coger el mensaje.
iii. Si cojo el mensaje, activo el dispositivo en la siguiente fase
y salgo del bucle, si no, vuelvo al punto i.
21 Explicación del teorema de Pitágoras - https://es.wikipedia.org/wiki/Teorema_de_Pit%C3%A1goras
Trabajo fin de grado
117 Jorge Prieto Martin
b. Imprimo los resultados, y actualizo los estados de los dispositivos,
si tengo más del 90% conectados salgo del programa, si no, vuelvo
al punto 5.
Trabajo fin de grado
118 Jorge Prieto Martin
10. Pruebas y validación
En este apartado se mostrarán todas las pruebas globales que se han generado,
ya que las individuales se han ido mostrando a lo largo de las iteraciones,
también veremos las pruebas de eficacia y rendimiento a una escala mayor a
través del emulador.
10.1 Pruebas globales del sistema
Antes de analizar todas las pruebas realizadas. Vamos a analizar todos los
dispositivos con los que se ha trabajado de manera continua, si bien además de
estos, se han utilizado otros dispositivos en ciertas ocasiones para validar
ciertos comportamientos y detectar errores que no serán mencionados.
Modelo Versión Android Problemas
Samsung Galaxy S3 Android 4.3 Jelly Bean -Problema al crear
servicio
Alcatel Idol 3 Android 5.0 Lollipop
-Problema para
conectarse a otros
dispositivos y recibir
mensajes
Samsung Galaxy Tab 4 Android 5.0 Lollipop -Ninguno
Alcatel Pixi 4 Android 6.0
Mashmallow -Ninguno
Tabla 13 - Dispositivos utilizados para las pruebas.
También hay que tener en cuenta que el hardware de cada dispositivo, así como
la antena wifi, puede cambiar y verse afectado su rendimiento.
A continuación, se detallan todas las pruebas realizadas con el sistema básico
implementado. Para acortar en las definiciones de los dispositivos se utilizarán
Trabajo fin de grado
119 Jorge Prieto Martin
los seudónimos vistos en la tabla siguiente para referirnos a los dispositivos
utilizados.
Modelo Seudónimo
Samsung Galaxy S3 S3
Alcatel Idol 3 Idol3
Samsung Galaxy Tab 4 Tab4
Alcatel Pixi 4 Pixi4
Tabla 14 - Seudónimos de los dispositivos utilizados para las pruebas.
10.1.1 Pruebas con dos dispositivos
La primera prueba a realizar, será para comprobar que el sistema funciona de
forma correcta y esperada. Se utilizarán los dispositivos Idol3 y Pixi4. Como
en las iteraciones se ha demostrado el funcionamiento correcto del sistema, aquí
solo mostraremos las medidas recogidas y los posibles fallos que puedan surgir
en la realización de las pruebas. Las medidas a recoger serán la distancia entre
dispositivos, si reciben los mensajes, y el tiempo de respuesta desde que un
dispositivo empieza a ofrecer el servicio de envío de mensajes, hasta que el otro
dispositivo recibe los mensajes. Para calcular la distancia, se ha modificado la
aplicación para que muestre la hora en la que un dispositivo genera el servicio,
y cuando el otro dispositivo recibe los mensajes.
Distancia (en metros) Mensaje/s recibido/s Tiempo (en segundos)
5 Si 10
15 Si 11
25 No -
Tabla 15 - Pruebas entre dos dispositivos.
Trabajo fin de grado
120 Jorge Prieto Martin
Observaciones
La prueba de los 25 metros se ha realizado en 7 ocasiones, pero solo en una se
ha logrado la conexión, el tiempo rondaba los 12 segundos.
Hay que tener en cuenta que, si hacemos las pruebas con un usuario conectado
a internet con una conexión Wifi, a la hora de crear el grupo con WI-FI Direct
éste será creado a la misma frecuencia a la que está conectado el dispositivo, es
decir, se creará otra red inalámbrica que trabajará a la misma frecuencia que la
red a la que el dispositivo actual está conectado, así que, si por ejemplo un
dispositivo está conectado a une red WI-FI ac es decir una red con una señal de
5GHz, luego un dispositivo que solo emplee tecnología WI-FI n, es decir,
señales a 2,4GHZ no podrá conectarse a estas redes ya que al trabajar en otras
frecuencias no le será posible detectarlas.
10.1.2 Pruebas con tres dispositivos
En este escenario en el que contamos con tres dispositivos, se realizarán dos
tipos de pruebas, la primera, dos de los dispositivos estarán desconectados y
pedirán los mensajes de manera simultánea (estando a la misma distancia del
dispositivo conectado), en la segunda, los dispositivos estarán posicionado de
tal forma que, un dispositivo solo estará al alcance de otro dispositivo a la vez,
es decir, el dispositivo A con conexión, enviará mensajes al dispositivo B y éste
al dispositivo C, ya que no hay señal suficiente entre los dispositivos A y C.
Para las pruebas se utilizarán el Tab3 como dispositivo conectado, y el Idol3 y
Pixi4 como los desconectados.
Conexión simultanea
Distancia
(metros)
Mensaje/s recibido/s Tiempo (segundos)
Idol3 Pixi4 Idol 3 Pixi4
Trabajo fin de grado
121 Jorge Prieto Martin
5 SI SI 10 10
15 SI SI 10 11
25 SI NO 11 -
Tabla 16 - Pruebas entre tres dispositivos, simultanea.
Observaciones
Se puede apreciar como el hardware afecta directamente a los resultados, ya
que el Idol3 es de una gama superior al Pixi4, y la antena wifi que incorpora
Idol3 es de una serie más nueva que la de Pixi4, capaz de soportar mayores
rangos de transferencia.
Aparte de esto, vemos que el comportamiento es el esperado y puede atender
varias conexiones simultaneas. A la hora de hacer las pruebas hay que tener en
cuenta activar la aplicación en los dispositivos Idol3 y Pixi4 de manera
simultánea, o en su defecto, alejarlos entre ellos una distancia considerable,
pero que estén a la misma distancia con el dispositivo Tab4, de manera que si
alguno coge el mensaje y se pone a transmitir antes que el otro, no afecte al
dispositivo que aún esté mirando los servicios y se conecte al nuevo transmisor,
inhabilitando así la prueba.
Conexión consecutiva
Distancia
(metros)
Mensaje/s recibido/s Tiempo (segundos)
Idol3 Pixi4 Idol 3 Pixi4
5 (10) SI SI 10 10 (20)
15 (30) SI SI 11 10 (21)
25 (50) SI NO 11 -
Trabajo fin de grado
122 Jorge Prieto Martin
Tabla 17 - Pruebas entre tres dispositivos, consecutiva.
Observaciones
Para esta prueba se han alineado los dispositivos de tal forma que el Tab4 solo
está visible para el Idol3, y éste es visible por el Pixi4.
Las tablas de tiempo son muy parecidas a las anteriores, si bien el tiempo global
es mayor a la suma de los tiempos individuales, podemos observar que no
afecta el tiempo entre un dispositivo conectado que ha recibido un mensaje por
internet (Del Tab4 al Idol3), a un dispositivo desconectado que ha recibido los
mensajes desde otro dispositivo (Del Idol3 al Pixi4)
10.1.2 Pruebas con cuatro dispositivos
Estas pruebas se harán de forma muy parecida a las pruebas con tres
dispositivos. Lo que se quiere conseguir añadiendo otro dispositivo más, es
poder comprobar que sigue siendo estable cuando un dispositivo recibe
múltiples conexiones. Por otra parte, el límite de conexiones simultaneas a un
dispositivo no se ha podido comprobar por falta de recursos.
Para esta prueba seguiremos utilizando el Tab4 como dispositivo conectado (y
más adelante el Idol3) y por la parte desconectada utilizaremos el Idol3, Pixi4
y el S3.
Conexión simultanea
Distancia
(metros)
Mensaje/s recibido/s Tiempo (segundos)
Idol3 Pixi4 S3 Idol3 Pixi4 S3
5 SI SI SI 11 11 10
15 SI SI SI 10 11 12
25 SI NO SI 10 - 11
Trabajo fin de grado
123 Jorge Prieto Martin
Tabla 18 - Pruebas entre cuatros dispositivos. Simultanea.
Observaciones
Como se esperaba, los resultados son muy similares a las pruebas con tres
dispositivos, y no se ha notado ningún retraso notable a la hora de recibir los
mensajes.
Conexión consecutiva
Distancia
(metros)
Mensaje/s recibido/s Tiempo (segundos)
Idol3 Pixi4 S3 Idol 3 Pixi4 S3
5 (10)(15) SI SI SI 10 11 10
15(30)(45) SI SI SI 10 11 11
25(50)(75) SI NO NO 10 - -
Tabla 19 - Pruebas entre cuatro dispositivos. Consecutiva.
Observaciones
Al igual que con tres dispositivos, se repiten resultados muy similares. En este
caso, se puede apreciar un problema al introducir un dispositivo de gama baja
en distancias largas, y es que se convierte en un cuello de botella que impide a
otros dispositivos recibir mensajes, qué, de tratarse de otro dispositivo, sí que
los recibirían.
10.1.3 Conclusiones
Las pruebas han sido realizadas en un espacio abierto sin obstáculos (edificios
o muros), se ha requerido de ayuda para poder activar todos los dispositivos de
forma simultánea. Cada prueba se ha realizado una media de 5 veces,
recogiendo datos en cada intento para luego hacer una media con los tiempos
obtenidos.
Trabajo fin de grado
124 Jorge Prieto Martin
Podemos concluir con una media de éxito todas las pruebas realizadas,
comprobando que los mensajes llegan adecuadamente y de forma correcta,
fallando en algunos dispositivos cuando se fuerzan las distancias máximas a las
que pueden llegar.
10.2 Pruebas del emulador del sistema
En capítulos anteriores, se ha explicado y justificado el uso del emulador para
poder probar el sistema en rangos de áreas y con un número de dispositivos que
no se podría implementar de otra forma.
Éstas pruebas se recogen en un archivo formato txt al que luego se exportará a
excel para poder mostrarlo.
Las variables que podemos introducir en el sistema, serán el número de
dispositivos y el área (en metros) donde se introducirán esos dispositivos de
forma aleatoria. Luego el sistema no devolverá una serie de fases por la cual se
puede ir viendo, dependiendo del caso y sus variables, el avance y propagación
del mensaje. Gracias a las pruebas realizadas en el apartado anterior,
conocemos qué de media el sistema envía y recoge mensajes en 11 segundos,
tiempo que se asociará a una fase.
El siguiente ejemplo se muestra un área de 200x200 metros con 300
dispositivos en él.
Trabajo fin de grado
125 Jorge Prieto Martin
Ilustración 45 - Tabla de la representación del área en la fase 0. Fuente propia.
En la imagen se muestra la Fase 0, donde solo existe un dispositivo con el
mensaje inicial (dentro del círculo rojo) que se irá propagando según pasen las
fases.
A continuación, se puede ver el estado del área en la fase 10 (después de 110
segundos en un escenario real).
Trabajo fin de grado
126 Jorge Prieto Martin
Ilustración 46 - Tabla de la representación del área en la fase 10. Fuente propia.
Se puede observar cómo se ha propagado el mensaje (los puntos de valor “o”)
en un área de 200x200 metros después de 110 segundos.
Para poder hablar dentro de un contexto real, la siguiente imagen nos muestra
cómo se verían los dispositivos propagados en un área de 200x200 metros en
el centro de Alicante.
Trabajo fin de grado
127 Jorge Prieto Martin
Ilustración 47 - Representación del centro de Alicante en la fase 0. Fuente propia.
A continuación, se mostrará una tabla con los datos recogidos de diferentes
pruebas, en ellas se indica el área en metros que representa el escenario, el
número de dispositivos, el número de fases hasta que se ha podido completar
un escenario, es decir cuando un escenario tiene el 90% de dispositivos
conectados(podrían darse bucles infinitos si se espera el 100% ya que puede
haber nodos aislados), se considera completado y los segundos en tiempo real
que harían falta para llegar al escenario completo.
Tabla de pruebas del emulador
Área
(metrosxmetros) Dispositivos
Fase completa
(90%) Tiempo (segundos)
200x200 300 12 132
200x200 600 9 99
200x200 1000 7 77
Trabajo fin de grado
128 Jorge Prieto Martin
500x500 300
No se completa,
puntos demasiado
aislados
-
500x500 1000 23 253
500x500 10000 14 154
1000x1000 1000
No se completa,
puntos demasiado
aislados
-
1000x1000 10000 34 374
1000x1000 100000 25 275
Tabla 20 - Resultados de las pruebas del emulador.
Como podemos observar en la tabla, cuantos más dispositivos existan en un
área y cuanto más reducida sea ésta, mejor se propagará el mensaje, aquí se ve
el claro problema de la aplicación en cuanto al desuso, si los dispositivos se
encuentran muy aislados, el avance del mensaje se corta. Igualmente, en estas
pruebas hemos jugado con el escenario ideal, es decir, no hemos tenido en
cuenta el máximo número de dispositivos que se pueden conectar a un solo
dispositivo, por lo tanto, la propagación no se ve afectada. Para poder
comprobar cómo afectaría limitar el número de conexiones a un dispositivo,
vamos a modificar la emulación para no dejar más de 5 dispositivos conectarse
al mismo en cada fase, después de comenzar otra fase, se entiende que no hay
ningún dispositivo conectado a ningún otro ya que al coger un mensaje se
desconecta de la red.
Tabla de pruebas del emulador con límite de conexiones
Trabajo fin de grado
129 Jorge Prieto Martin
Área
(metrosxmetros) Dispositivos
Fase completa
(90%) Tiempo (segundos)
200x200 300 9 99
200x200 600 11 121
200x200 1000 9 99
500x500 300
No se completa,
puntos demasiado
aislados
-
500x500 1000 29 319
500x500 10000 19 209
1000x1000 1000
No se completa,
puntos demasiado
aislados
-
1000x1000 10000 35 385
1000x1000 100000 30 330
Tabla 21 - Resultado de pruebas del emulador. Con límite de conexiones.
Al limitar las conexiones a 5 por dispositivo, podemos ver cómo se retrasa el
despliegue del mensaje por toda el área, aunque sigue manteniendo la misma
propiedad de cuanto más dispositivos antes se propaga.
10.3 Consumo de batería
Un detalle muy importante en éste tipo de proyectos a tener en cuenta, es, el
consumo de batería, ya que la implantación ideal del sistema, sería como un
servicio corriendo en el background del sistema operativo Android, por lo
tanto, sería una aplicación que haría peticiones a un servidor cada 5 minutos, y
Trabajo fin de grado
130 Jorge Prieto Martin
de obtener mensajes, entraría en un modo en el que despliega una red wifi, o de
lo contrario, si deja de tener conexión entraría en un modo de búsqueda de
servicios, con todo el gasto de batería que ello implica.
Para las pruebas, se han dejado los dispositivos Alcatel Idol 3 y Alcatel Pixi 4,
utilizando ambos modos de la aplicación por varias horas, comparando con el
gasto de batería sin activar la aplicación.
El modelo Idol3 estará un periodo breve de tiempo buscando mensajes y a
continuación pasará a compartir mensajes, en cuanto al modelo Pixi4, estará
buscando servicios durante todo el periodo de tiempo de pruebas.
Consumo de batería
Alcatel Idol 3 (Batería 2910mAh) Alcatel Pixi 4 (Batería 2000mAh)
Tiempo de uso
(horas)
Batería restante (%) Tiempo de uso
(horas)
Batería restante (%)
Con App Sin App Con App Sin App
2 88% 95% 2 94% 97%
4 82% 89% 4 89% 92%
8 66% 72% 8 76% 78%
12 41% 50% 12 58% 62%
Tabla 22 - Pruebas del consumo de la batería.
Después de recoger los resultados, se puede comprobar que el consumo extra
de la aplicación cuando está en modo de envío, ronda el 7%, mientras que, si
solo está en búsqueda de servicio, se encuentra alrededor del 3%. Podemos
considerarlo como un gasto extra bastante bajo y asimilable para cualquier
dispositivo.
Trabajo fin de grado
131 Jorge Prieto Martin
10.4 Dificultades
Normalmente, cuando se intenta crear una solución para un problema, se
termina creando otros tipos de problemas que surgen con la implantación de la
solución. En este caso, también se han podido observar problemas que han
surgido después de implementar la solución.
10.4.1 Problema de actualización de un mensaje
Este problema se da cuando se quiere modificar un mensaje que ya se ha
enviado. La propia naturaleza del sistema hace que sea muy difícil la
modificación de un mensaje. La implementación actual hace que el dispositivo
se desconecte una vez ha recogido un mensaje y se ponga a retransmitir esos
mensajes sin escuchar el resto de servicios buscando por nuevos mensajes hasta
que no ha terminado la vida de todos los mensajes que está retransmitiendo.
Esto es una mejora futura a implementar, pero aun así persiste el error de no
poder garantizar que cuando se modifique un mensaje y se vuelva a
retransmitir, vaya a llegar a los mismos dispositivos que había llegado el primer
mensaje por la naturaleza cambiante del sistema (un dispositivo no está fijo en
un punto).
10.4.1 Problema de recibo de servicios
Este problema se da a la hora de analizar los servicios cercanos de un
dispositivo. Cuando un dispositivo está desconectado, puede darse el caso de
encontrarse en un punto medio donde recibe dos servicios diferentes, y cada
servicio tiene mensajes diferentes. En la versión actual, cuando recibo mensajes
de un dispositivo, se deja de buscar servicios y el dispositivo empieza a
retransmitir, perdiendo así, el otro mensaje que debería recibir del dispositivo
al que no se ha conectado.
Trabajo fin de grado
132 Jorge Prieto Martin
Esto tiene una solución en principio sencilla, analizar todos los servicios
cercanos, conectarse a ellos y guardar los mensajes, pero esta solución acarrea
aún más problemas. Si estoy en un área masificada el coste de analizar y
conectarse a todos los dispositivos puede ser muy alto, más incluso cuando las
probabilidades de que todos tengan el mismo mensaje son muy altas. Así una
solución entre medias, sería analizar un número máximo de servicios cercanos
y conectarse a ellos para comprobar los mensajes, aumentado la probabilidad
de recibir mensajes diferentes, con un coste más bajo, pero sin estar seguros de
que hemos recibido todos los mensajes.
Otra solución más factible sería añadir al nombre del servicio, la fecha de la
creación del mensaje más actual que tengamos, así los otros dispositivos
pueden analizar los servicios, sin tener que conectarse, solo comparando las
fechas del mensaje más nuevo que tienen con la fecha del servicio. Si bien, la
fecha no es un id único, sí que podemos discretizar bastante a la hora de filtrar
por fechas ya que nos permite comprobar hasta la milésima de segundo en la
que el mensaje fue creado, haciendo muy difícil que dos mensajes tengan la
misma fecha. Esta solución a su vez, acarrea otros problemas, por ejemplo, que
si solo miramos que la fecha sea más nueva que la de nuestro último mensaje,
cuando hemos actualizado con un mensaje muy reciente, es posible que otro
dispositivo tenga un mensaje algo más antiguo pero que nosotros no tengamos
almacenados o que dos dispositivos pueden coincidir con la última fecha del
mensaje más reciente, pero que tenga mensajes anteriores que el dispositivo
escuchando servicios no tiene. Aun así, se toma como la solución más factible
y rápida, dando como excusa que un mensaje más antiguo puede no
interesarnos ya que podría estar desfasado.
Trabajo fin de grado
133 Jorge Prieto Martin
10.4.2 Conclusiones
Las dificultades que hemos podido observar, están muy relacionadas con la
introducción de nuevos mensajes en el sistema. Aun así, las soluciones a estos
problemas se dejan a analizar para un futuro y ver si vale la pena comprometer
rendimiento con eficacia, puesto que, el objetivo del sistema es muy concreto,
y el uso deseado para éste es el de, avisar de forma urgente mediante un mensaje
a un área determinada, haciendo que el recibo de dos mensajes diferentes en
una misma zona se vea improbable e incluso contraproducente ya que puede
desorientar al usuario que recibe varios mensajes diferentes, que no sean
actualizaciones sobre la misma situación de emergencia.
11. Conclusiones y trabajo futuro
En este último apartado de la memoria, se comentarán las implementaciones
futuras de mejora del sistema, la posible rentabilidad del proyecto, así como
pensamientos propios del proyecto y el futuro de éste.
11.1 Implementaciones futuras
Dado el despliegue del sistema, se han dado prioridades y objetivos a cumplir
imprescindibles para la entrega del trabajo, esto es, el funcionamiento básico
del sistema capaz de recibir mensajes y reenviarlos en zonas donde no exista
conexión a internet. Se le ha rebajado prioridad a las funciones relacionadas
con la administración y seguridad, igual de importantes para un sistema final,
pero más relevantes para el objetivo de éste proyecto.
En el apartado de diseño, se explica las implementaciones futuras a seguir a la
hora de desplegar el sistema de seguridad, con ciertas medidas ya
implementadas. También se habla del usuario administrador y su papel en el
sistema, pero sin mostrar los detalles de la interfaz que manejara.
Trabajo fin de grado
134 Jorge Prieto Martin
Los siguiente mockups detallarán las implementaciones futuras de la
administración del sistema.
Pantalla de identificación:
Ilustración 48 - Mockup de la pantalla de identificación. Fuente propia.
El siguiente mockup muestra la pantalla de identificación en la aplicación web,
donde podrá identificarse tanto el usuario administrador como el usuario
generador.
Trabajo fin de grado
135 Jorge Prieto Martin
Ilustración 49 - Mockup de la pantalla de administración de usuarios. Fuente propia.
La siguiente escena muestra el menú de administración de usuarios de un
administrador, donde puede dar de alta a un usuario, cuando éste usuario es
dado de alta, se le enviará un email con su contraseña a la dirección que haya
indicado. En la parte derecha tenemos la lista de todas las organizaciones donde
podremos elegir un usuario para editarlo o borrarlo.
Trabajo fin de grado
136 Jorge Prieto Martin
Ilustración 50 - Mockup de la pantalla de administración de las organizaciones. Fuente propia.
Éste mockup presenta una apariencia muy parecida con los usuarios, ya que
las organizaciones tendrán los mismos procesos, pero sin necesitar enviar
ningún email con la contraseña, ya que la organización solo sirve para agrupar
usuarios. También se le podrán asignar zonas, las cuales se mostrarán para
elegir al usuario perteneciente a la organización.
Trabajo fin de grado
137 Jorge Prieto Martin
Ilustración 51 - Mockup de la pantalla de administración de zonas. Fuente propia.
Por último, la pantalla de administración de zonas, mostrará todas las zonas
disponibles y podrá crear, editar y eliminar zonas.
Todas estas operaciones se resolverán en la base de datos.
11.2 Monetización del proyecto
La idea original de este trabajo de fin de grado era de poder crear una
herramienta fácil de usar y que pudiera llegar a todo el mundo, de forma
gratuita. En la rentabilidad del proyecto, no se incluye en ningún momento
hacerla de pago para el usuario consumidor, ya que depende directamente de
éste el éxito o fracaso de la implantación del proyecto. También, del lado del
usuario generador, siempre y cuando se le dé el uso original para el que ha sido
desarrollado, se ofrecerá de forma gratuita.
Si bien, siempre pueden salir modelos de negocio basándonos en la idea de
hacer llegar mensajes en un área concreta. Este proyecto puede derivarse en
Trabajo fin de grado
138 Jorge Prieto Martin
otros proyectos más comerciales, donde la monetización podría darse al uso de
las áreas. Entonces, se podría cobrar a una organización por el “uso” de un área
para enviar mensajes, fijando diferentes precios dependiendo del tamaño del
área y del tipo de área a enviar. (El mensaje llegará a más gente en la gran vía
de Madrid, que, por ejemplo, en la Rambla de Alicante).
En conclusión, el objetivo principal es poder llegar al mundo, y ayudarlo, si
ésta herramienta llegara a utilizarse y gracias a ella, se pudieran salvar vidas,
habría logrado el objetivo final de éste proyecto.
11.3 Conclusión final y futuro del proyecto
El trabajo de fin de grado, ha sido un proyecto muy ambicioso, aunque he
alcanzado el objetivo principal propuesto, conseguir transmitir un mensaje en
un área sin conexión a internet donde todo el mundo tiene la tecnología
suficiente para enviarlo y recibirlo, aún quedan muchos cabos sueltos para
poder llamarlo una aplicación robusta, segura y sin fallos para poder sacar al
mercado.
El futuro del proyecto, es, poder terminar el sistema como un producto factible,
para luego, poder seguir investigando, y convertirlo en el tipo de sistema al que
está orientado, es decir, un servició del propio sistema operativo Android, qué
nos permita, sin tener que hacer instalaciones o configuraciones extras, tener
una alternativa de comunicación al mundo, si éste dejara de funcionar.
Para terminar, una reflexión final sobre el proyecto.
Desde el principio ha sido un proyecto muy ambicioso, ha sido todo un reto,
donde he empezado desde cero, siempre con la incertidumbre de si un sistema
así sería posible con la tecnología actual. He tenido que aprender nuevas
tecnologías, así como algoritmos y protocolos que conviven con nosotros desde
hace tiempo. Una nueva experiencia para mí, donde te encuentras solo ante el
Trabajo fin de grado
139 Jorge Prieto Martin
peligro (aunque siempre con la ayuda y el apoyo de mi tutor), y tienes que
afrontar problemas demostrando todo lo aprendido a lo largo de la carrera.
Como he mencionado antes, es un proyecto muy ambicioso que aún necesita
muchas horas para poder ser llamado un sistema completo, pero a la vez, me
siento muy satisfecho con los resultados conseguidos.
Apéndice
Uso recomendado de las zonas
A continuación, se detallan todas las zonas y sus recomendaciones de uso:
• Nación
o Comprende todo un país. Su uso debería ser muy limitado y
utilizarse sólo en casos de máxima emergencia (estado en guerra
de un país, catástrofe natural o humana a muy gran escala…). Para
utilizar este nivel se recomienda el envío del mensaje desde
diferentes puntos del país o el uso de repetidores en lugares
estratégicos para poder solventar el problema de distancias
demasiado grandes y en áreas tecnológicamente desiertas.
• Comunidad
o Comprende el área de una comunidad autónoma, su uso está
reservado a catástrofes naturales o humanas a nivel grande/medio.
Se recomienda el envío desde los puntos más poblados de la
comunidad y usar repetidores en zonas despobladas.
• Región
Trabajo fin de grado
140 Jorge Prieto Martin
o Comprende el área de una región o provincia, similar al nivel de
comunidad, pero enfocado a catástrofes naturales o humanas de
nivel medio.
• Ciudad
o Comprende el área de una ciudad. Su uso puede ser muy variado
y utilizarse en varios casos (terrorismo, catástrofes, grandes
accidentes…). A este nivel se puede empezar a prescindir de
envíos desde diferentes posiciones y el uso de repetidores.
• Barrio
o Comprende el área de un barrio o distrito. Su uso es similar al de
ciudad pero a una menor escala, para evacuar zonas de accidentes
medios (un incendio en un edificio que se vaya propagando),
incomunicación por manipulación de terceros o amenazas de
terrorismo.
• Recinto
o Comprende el área de un recinto específico. Su uso se limitará
para las organizaciones (privadas o públicas) con potestad sobre
cierto recinto. Estos recintos tendrán que ser registrados en el
sistema con anterioridad.
• Área especifica
o Comprende áreas que no se han especificado en los casos
anteriores (Bosques, carreteras…). Se recomienda su uso en casos
dónde se necesita cubrir un área en concreto que no comprende el
sistema (una zona de carretera donde ha habido un accidente, un
bosque cercano a un pueblo que ha empezado a extenderse, un
alud que ha enterrado varios edificios). Para este uso, el usuario
generador podrá indicar el epicentro del desastre y darle un radio
de acción, o bien enviar su propia posición e indicarle un rango de
acción.
Trabajo fin de grado
141 Jorge Prieto Martin
Material extra
Como material extra se han producido unos videos sobre las pruebas de
comportamiento de dispositivos. A continuación, los enlaces:
Recibiendo mensajes de forma offline:
https://www.youtube.com/watch?v=5-MmlH75MaY
Creación y envío de un mensaje de forma online:
Parte 1 - https://www.youtube.com/watch?v=eyhsIIonhjc
Parte 2 - https://www.youtube.com/watch?v=i52nC7Bq-JU
Bibliografía
[1] Diario 20 minutos (1 de Noviembre de 2013). Madrid Arena, cronología de
la investigación sobre una fiesta de Halloween que acabó en tragedia.
http://www.20minutos.es/noticia/1641576/0/cronologia/tragedia/madrid-
arena/
[2] Parker, Bruce (3 de Noviembre de 2011). Why Did the 2011 Japan Tsunami
Kill So Many People?. HuffingtonPost. http://www.huffingtonpost.com/bruce-
parker/japan-tsunami_b_1335737.html
[3] Artículo de la BBC (9 de Diciembre de 2015). Paris attacks: What happened
on the night. http://www.bbc.com/news/world-europe-34818994
[4] Artículo de la Wikipedia sobre Peer to peer
https://es.wikipedia.org/wiki/Peer-to-peer
[5] Definición de Emule. Página oficial de Emule.
http://www.emule.com/es/emule-preguntas-frecuentes/que-es-emule/
Trabajo fin de grado
142 Jorge Prieto Martin
[6] Características de Wifi P2P. Página oficial de Android para desarrolladores.
https://developer.android.com/training/connect-devices-wirelessly/wifi-
direct.html
[7] Definición de Bluetooth. Página oficial de Bluetooth.
https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works
[8] Articulo sobre Wifi Direct. Página oficial de la Wifi Alliance.
http://www.wi-fi.org/discover-wi-fi/wi-fi-direct
[9.1] Artículo de Wireless Networking & Communication Group sobre D2D (9
de Junio de 2014) https://wncg.org/research/briefs/device-device-d2d-
communication-fundamentals-applications-lte
[9.2] Poole, Ian. Artículo sobre D2D. 4G LTE Advanced device to device, D2D
communication for high data rate local direct communications using LTE
devices. Radio-Electronics.com
http://www.radio-electronics.com/info/cellulartelecomms/lte-long-term-
evolution/4g-lte-advanced-d2d-device-to-device.php
[10] Articulo de la Universidad de Alicante (28 de Septiembre de 2016) Un
investigador de la UA desarrolla una tecnología para emitir señales de socorro
en entornos donde no existe cobertura de telefonía móvil.
https://web.ua.es/es/actualidad-universitaria/2016/septiembre16/26-30/un-
investigador-de-la-ua-desarrolla-una-tecnologia-para-emitir-senales-de-
socorro-en-entornos-donde-no-existe-cobertura-de-telefonia-movil.html
[11] Malvarez (1 de Febrero de 2016) Radiodifusiones de emergencia: alertas
oficiales a través de tu BQ.
http://www.mibqyyo.com/articulos/2016/02/01/radiodifusiones-emergencia-
alertas-oficiales-bq/#/vanilla/discussion/embed/?vanilla_discussion_id=0
Trabajo fin de grado
143 Jorge Prieto Martin
[12] Artículo de la Wikipedia sobre la tarjeta de Coordenadas
https://es.wikipedia.org/wiki/Tarjeta_de_coordenadas
[13] Características de un KeyStore. Página oficial de Android para
desarrolladores.
https://developer.android.com/training/articles/keystore.html?hl=es
[14] Artículo de la Wikipedia sobre la Criptografía simétrica
https://es.wikipedia.org/wiki/Criptograf%C3%ADa_sim%C3%A9trica
[15] Artículo de la Wikipedia sobre el sistema de cifrado AES
https://es.wikipedia.org/wiki/Advanced_Encryption_Standard
[16] Artículo de la Wikipedia sobre la Criptografía asimétrica
https://es.wikipedia.org/wiki/Criptograf%C3%ADa_asim%C3%A9trica
[17] Artículo de la Wikipedia sobre el sistema de cifrado RSA
https://es.wikipedia.org/wiki/RSA
[18] Artículo de la Wikipedia sobre la seguridad Wifi WPA2
https://en.wikipedia.org/wiki/Wi-Fi_Protected_Access#WPA2
[19] Artículo de la Wikipedia sobre CCMP
https://en.wikipedia.org/wiki/CCMP_(cryptography)
[20] Artículo de la Wikipedia sobre Haversine
https://es.wikipedia.org/wiki/F%C3%B3rmula_del_haversine
[21] Artículo de la Wikipedia sobre el teorema de Pitágoras
https://es.wikipedia.org/wiki/Teorema_de_Pit%C3%A1goras
[Otros]
Agrupación astronómica Jerezana MAGALLANES - Distancia entre dos
puntos y radio terrestre
Trabajo fin de grado
144 Jorge Prieto Martin
https://agrupacionastronomicamagallanes.wordpress.com/experimento-de-
eratostenes/distancia-entre-dos-puntos/
Dr. Jukka Initial Investigation with Wifi-Direct
http://www.drjukka.com/blog/wordpress/?p=24
Guias de desarrollo Android - https://developer.android.com/training/connect-
devices-wirelessly/index.html