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.



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



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



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



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



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



Í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



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



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


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



Ilustración 51 - Mockup de la pantalla de administración de zonas. Fuente

propia. ............................................................................................................ 137



Índice de tablas

Tabla 1 - Requerimiento funcional 1 .............................................................. 38









Tabla 10 - Requerimiento funcional 10 .......................................................... 41



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



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



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?



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.



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/

http://www.20minutos.es/noticia/1641576/0/cronologia/tragedia/madrid-arena/

http://www.20minutos.es/noticia/1641576/0/cronologia/tragedia/madrid-arena/



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

http://www.huffingtonpost.com/bruce-parker/japan-tsunami_b_1335737.html

http://www.huffingtonpost.com/bruce-parker/japan-tsunami_b_1335737.html

http://www.bbc.com/news/world-europe-34818994



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



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.



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.



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/

https://es.wikipedia.org/wiki/Peer-to-peer

http://www.emule.com/es/emule-preguntas-frecuentes/que-es-emule/




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

https://developer.android.com/training/connect-devices-wirelessly/wifi-direct.html

https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works




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



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

http://www.wi-fi.org/discover-wi-fi/wi-fi-direct

https://wncg.org/research/briefs/device-device-d2d-communication-fundamentals-applications-lte

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

http://www.radio-electronics.com/info/cellulartelecomms/lte-long-term-evolution/4g-lte-advanced-d2d-device-to-device.php



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



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

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



http://www.mibqyyo.com/articulos/2016/02/01/radiodifusiones-emergencia-alertas-oficiales-bq/#/vanilla/discussion/embed/?vanilla_discussion_id=0

http://www.mibqyyo.com/articulos/2016/02/01/radiodifusiones-emergencia-alertas-oficiales-bq/#/vanilla/discussion/embed/?vanilla_discussion_id=0



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.



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.



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



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.



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.



• Bloque 5 – Desarrollo de las funcionalidades avanzadas del servidor.

• Bloque 6 – Desarrollo de las funcionalidades avanzadas de conexión y

envío de datos.



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.



• 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



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



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



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.



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


RF02


Identificación del usuario generador

Características: Los usuarios generadores deberán iniciar sesión para poder acceder a las funciones del sistema.


Se comprobará las credenciales con la información almacenada en la base de datos.


Baja



RF03


Generar mensaje

Características: Los usuarios generadores pueden crear alertas en el sistema


El usuario especificará el mensaje y las características de éste.


Alta





RF04


Envío de mensaje

Características: Los usuarios generadores pueden enviar el mensaje al sistema


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.


Alta



RF05


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.


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.


Alta



RF06


Consulta de mensajes

Características: Un usuario consumidor consultará si hay mensajes en su área al sistema o a dispositivos cercanos.


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.




Alta



RF07


Recepción de un mensaje

Características: El usuario recibirá mensajes del sistema u otro usuario


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.


Alta



RF08


Reenvío de un mensaje

Características: Cualquier usuario puede reenviar un mensaje a otros usuarios de la zona.


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.


Alta



RF09


Descartar alerta dado el tiempo de vida

Características: Un usuario descartará un mensaje cuando éste supere su tiempo de vida.


Cualquier usuario que tenga un mensaje el cual su tiempo de vida haya terminado, dejará de transmitirlo y lo descartará.




Media



RF10


Crear usuarios

Características: El usuario administrador deberá validar la cuenta de un usuario generador antes de que ésta pueda ser utilizada


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.


Baja



RF11


Crear zonas

Características: El usuario administrador podrá crear las zonas a las que puede acceder un usuario generador.


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.


Baja



RF12


Crear organizaciones

Características: El usuario administrador deberá dar de alta en el sistema a las organizaciones.


Las organizaciones podrán tener varios usuarios y zonas asignados.




Baja


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



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



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)



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.


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.



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.


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.



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.



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.



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.



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.



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.



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



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



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.




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.




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



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.



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.



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.



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.



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.



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.



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.



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



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,



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.



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

https://developer.android.com/training/articles/keystore.html?hl=es



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

https://es.wikipedia.org/wiki/Criptograf%C3%ADa_sim%C3%A9trica

https://es.wikipedia.org/wiki/Advanced_Encryption_Standard



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)

https://en.wikipedia.org/wiki/CCMP_(cryptography)



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



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



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



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.



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.



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.



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”



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.



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



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.



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.



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



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



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.

http://tfg-wifi.appspot.com/getmessages?latitud=38.347052&longitud=-0.488053

http://tfg-wifi.appspot.com/getmessages?latitud=38.347052&longitud=-0.488053



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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



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.



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.



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.



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.



Ilustración 30 - Captura de pantalla con el dispositivo A dando servicio. Fuente propia.



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.



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



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



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.

http://tfg-wifi.appspot.com/setmessage



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.



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.



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.



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.



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.



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.



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:



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.



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.



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.



• 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



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.



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



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.



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



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)


Idol3 Pixi4 Idol 3 Pixi4

5 (10) SI SI 10 10 (20)

15 (30) SI SI 11 10 (21)

25 (50) SI NO 11 -



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)


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



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)


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.



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.




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




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.



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



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



Á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



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.



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.



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.



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.



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.



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.



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.



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



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



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



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.



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.


https://www.youtube.com/watch?v=5-MmlH75MaY

https://www.youtube.com/watch?v=eyhsIIonhjc

https://www.youtube.com/watch?v=i52nC7Bq-JU



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


[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



[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



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

Agradecimientos - rua.ua.es · importar la distancia, me parecía casi cosa de magia. Ahora,...

Documents

Transcript of Agradecimientos - rua.ua.es · importar la distancia, me parecía casi cosa de magia. Ahora,...