Estudio sobre el uso de redes inalámbricas en la estimación de aforos

Universidad de Valladolid ESCUELA DE INGENIER´ IA INFORM ´ ATICA GRADO EN INGENIER´ IA INFORM ´ ATICA MENCI´ ON EN TECNOLOG´ IAS DE LA INFORMACI ´ ON Estudio sobre el uso de redes inal´ambricas en la estimaci´on de aforos Alumno: Alejandro Garc´ıa G´omez Tutor: Jes´us M. Vegas Hern´andez AGRADECIMIENTOS Agradecimientos A mis padres, por apoyarme en todo momento durante estos a˜nos. A mis amigos, por estar ah´ı en cualquier situaci´on, ayud´andome en los peores momentos y compartiendo con ellos este camino. I AGRADECIMIENTOS II RESUMEN Resumen El reciente aumento del n´umero de dispositivos inal´ambricos que lleva la gente en su d´ıa a d´ıa supone un nuevo reto para los algoritmos de rastreo y captura de paquetes, afectando directamente a aquellos programas dedicados a detectar la ocupaci´on de una sala. Esto, sumado a la poca fiabilidad de sistemas para el c´alculo del aforo ya existentes, como los sistemas basados en el di´oxido de carbono o en c´amaras de v´ıdeo, generan la necesidad de dise˜nar nuevos m´etodos m´as fiables y adaptados a las nuevas pol´ıticas de privacidad. Por ello, en este proyecto, se dise˜nar´an dos algoritmos que permitan identificar dispositivos Bluetooth y relacionar los dispositivos WiFi entre s´ı, algo que se ha tratado en otros trabajos y art´ıculos pero sin llegar a una conclusi´on definitiva sobre ello. Con estos algoritmos se tendr´a una aproximaci´on m´as fiel a la realidad alej´andose de la hip´otesis de que cada persona lleva un ´unico dispositivo, detectando as´ı la ocupaci´on de una forma m´as adecuada. Para probar el sistema y ajustar sus par´ametros se realizar´a una prueba en un entorno real junto con un estudio de campo. III RESUMEN IV ABSTRACT Abstract The recent growth in the number of the personal wireless devices, represents a new challenge for packet capture and tracking algorithms, directly impacting room ocupation detecting softwares. This, added to the unreliability of existing ocuppancy detection systems, such as CO2 or videocams based programs, create the need to design new more reliable methods which are adapted to recent privacy policies. Therefore, the objective of this proyect is to design two algorithms which will allow to identify Bluetooth devices and link WiFi devices to each other. This algorithms will allow us to have a more realistic approach to a real world scenario dispelling the idea that each person carries a single device, making easier to detect room ocupation. In order to probe the system and adjust its parameters a test will be carried out in a real enviroment together with a survey. V ABSTRACT VI ´ INDICE GENERAL ´ Indice general Agradecimientos I Resumen III Abstract V Lista de figuras XI Lista de tablas XIII 1. Introducci´on 1 2. Estado del arte 3 2.1. Trabajorelacionado ................................ 3 2.1.1. Sistemas basados en factores naturales . . . . . . . . . . . . . . . . . . 3 2.1.2. Sistemas basados en v´ıdeo . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.3. Sistemas basados en redes inal´ambricas . . . . . . . . . . . . . . . . . 4 2.1.4. Sistemasderastreo............................. 4 2.2. Caracter´ısticas utilizables para la identificaci´on . . . . . . . . . . . . . . . . . 5 2.2.1. BluetoothyBLE.............................. 5 2.2.2. DireccionesMAC.............................. 5 2.2.3. SSID..................................... 7 VII ´ INDICE DE TABLAS XIV CAP´ ITULO 1. INTRODUCCI ´ ON Cap´ıtulo 1 Introducci´on El reciente aumento del n´umero de dispositivos inal´ambricos y su creciente popularidad ha supuesto un incremento en la cantidad de dispositivos que lleva encima la gente en su d´ıa a d´ıa, como tel´efonos m´oviles, pulseras y relojes inteligentes, cascos inal´ambricos o incluso sensores biom´edicos como parches para controlar la glucosa en personas diab´eticas. Todos estos dispositivos utilizan redes inal´ambricas para conectarse a internet o entre s´ı, siendo las m´as frecuentes WiFi y Bluetooth, respectivamente. Por ello la pregunta que se va a intentar responder en este proyecto es si se puede calcular el aforo de una sala a partir del n´umero de dispositivos que haya en esta, siendo capaces de relacionar los dispositivos entre s´ı para tener la estimaci´on tanto de dispositivos como de personas. Adem´as de intentar dar una soluci´on para este problema, se realizar´a un experimento en un entorno real para comprobar la eficacia de esta soluci´on, y un estudio de campo para poder ajustar m´as detalladamente par´ametros como el n´umero medio de dispositivos que suele llevar un usuario normal. Existen otro tipo de soluciones y m´etodos para calcular de forma autom´atica el aforo de una sala, siendo los m´as comunes sensores de CO2 y c´amaras de v´ıdeo, aunque con varios problemas como la distribuci´on del CO2 por la sala o la identificaci´on de las personas, respectivamente. Por ello, si se logra dar una soluci´on v´alida en este proyecto, supondr´a un avance en la utilizaci´on de este tipo de tecnolog´ıa y m´etodo en la estimaci´on de la ocupaci´on, sin poner en peligro la privacidad de las personas ya que no se interact´ua con los dispositivos en ning´un momento. Adem´as, puede ser ´util para varias situaciones tanto en el ´ambito personal como empresarial, por ejemplo para comprobar qu´e salas son las m´as ocupadas de una empresa e invertir m´as en su comodidad o tener una valor constantemente actualizado del aforo para negocios peque˜nos, siendo una soluci´on barata que podr´ıan permitirse. El principal objetivo de este proyecto es dar una soluci´on v´alida al problema de la relaci´on de dispositivos entre s´ı, ya que se ha llegado a varias soluciones para resolver el problema de detectar el n´umero de dispositivos que hay en una sala pero no se ha llegado a profundizar en la relaci´on que tienen esos dispositivos, dando en la mayor´ıa de ocasiones soluciones con 1 la hip´otesis de que cada persona lleva un ´unico dispositivo. Una vez se consiga dise˜nar un algoritmo que permita esa relaci´on, se dise˜nar´a un estudio de campo y un experimento para probar su eficacia en un entorno real ajustando par´ametros del algoritmo, bas´andose tanto en nuestro estudio como en estudios ajenos, hechos por compa˜n´ıas como Cisco. La estructura que seguir´a en este proyecto es la siguiente. En el Cap´ıtulo 2 se tratar´an los trabajos previos y relacionados que hay para resolver este problema adem´as de una descripci´on del sistema propuesto y de la tecnolog´ıa utilizada. En el Cap´ıtulo 3 se detallar´a la soluci´on y el sistema implementado completo as´ı como el dise˜no y desarrollo del experimento y del estudio de campo. En el Cap´ıtulo 4 se expondr´an los resultados tanto del experimento realizado como de la encuesta, pasando a analizarlos y discutirlos en el Cap´ıtulo 5. Por ´ultimo, en el Cap´ıtulo 6 se expondr´an las conclusiones obtenidas en este proyecto. 2 CAP´ ITULO 2. ESTADO DEL ARTE Cap´ıtulo 2 Estado del arte En este cap´ıtulo se expondr´an los trabajos y m´etodos existentes para detectar la ocupaci´on de una sala, as´ı como los trabajos que han servido de referencia para realizar este proyecto. Se expondr´a tambi´en el sistema propuesto junto a una explicaci´on de los conceptos m´as importantes en los que se basa el trabajo. Adem´as, se explicar´a tambi´en la tecnolog´ıa y programas utilizados para el desarrollo del sistema. 2.1. Trabajo relacionado Existen varios sistemas para detectar cu´antas personas se encuentran en una sala, el principal objetivo de este trabajo, y varios programas y algoritmos para rastrear dispositivos bien sea a trav´es de Bluetooth o de WiFi, algo que no se abarca aqu´ı pero que ha servido como influencia para este proyecto. 2.1.1. Sistemas basados en factores naturales El sistema m´as utilizado con este funcionamiento es el que mide el volumen de CO2 que hay en la sala, a partir del cual se calcula el aforo, conservando totalmente la privacidad de estas personas ya que no se obtiene ning´un dato sobre esas personas [1]. La contra de este sistema es que la distribuci´on del CO2 por la sala no es totalmente uniforme, ya que depende de la distribuci´on de las personas y de la ventilaci´on que haya, por lo que el valor medido puede variar f´acilmente haciendo que el aforo sea muy distante al real. Para buscar una soluci´on m´as precisa se ha integrado a este sistema la detecci´on de otras medidas como la humedad, acerc´andose as´ı al valor real pero sin ser suficientemente preciso como para que sea fiable. 3 2.1. TRABAJO RELACIONADO 2.1.2. Sistemas basados en v´ıdeo El principal m´etodo dentro de estos sistemas es la detecci´on del aforo a trav´es c´amaras de v´ıdeo, mucho m´as preciso que el anterior pero con el problema de la privacidad, ya que identifica a todas las personas de la sala, por lo que previamente deben haber dado su consentimiento para ello. Para evitar este problema y prevenir que se reconozcan las caras se utilizan c´amaras de muy baja resoluci´on o se colocan a una altura suficientemente baja para que no se vean las caras. Normalmente se utiliza este sistema combinado con el de CO2 para aumentar la precisi´on en salas con baja iluminaci´on o mucha ventilaci´on, casos en los que ambos m´etodos por separado son menos fiables [1]. 2.1.3. Sistemas basados en redes inal´ambricas Este tipo de sistemas calculan el aforo tanto en interiores como exteriores a partir de la informaci´on obtenida de los paquetes WiFi y Bluetooth que se transmiten. Se analizan los paquetes de descubrimiento de red, especialmente los paquetes probe request (en la siguiente secci´on se explican m´as detalladamente), para obtener los valores RSSI (Receive Signal Strenght Indicator) y CSI (Channel State Information), con los que a partir de diferentes algoritmos y modelos se obtienen estimaciones cercanas a la realidad. El problema con este m´etodo es que no escala bien con muchas personas, limitando as´ı las pruebas y experimentos que se han hecho a un m´aximo de 10 personas [1, 2]. Otros sistemas se basan en obtener las direcciones MAC de los dispositivos y as´ı hacer una estimaci´on m´as directa del n´umero de dispositivos alrededor, que combinado con el RSSI del m´etodo anterior obtienen una aproximaci´on de los dispositivos en un umbral m´as cercano o m´as lejano. Uno de los problemas de este m´etodo, como se explicar´a en la siguiente secci´on, es la aleatoriedad de la direcci´on MAC, la cu´al hace que si no se detecta correctamente se obtengan m´as dispositivos de los que realmente hay en la sala [3]. Otra contra que surge de ambos tipos de sistemas es que est´an hechos para detectar dispositivos, no personas. Con el uso cada vez m´as com´un de dispositivos inal´ambricos, como auriculares o pulseras inteligentes, se detectar´ıan muchos m´as dispositivos de las personas que realmente habr´ıa en la sala, por lo que no se puede establecer una relaci´on uno a uno entre dispositivo y persona, siendo necesario buscar nuevos m´etodos dentro de esta categor´ıa con los que tener una aproximaci´on m´as real [1, 4]. 2.1.4. Sistemas de rastreo Este tipo de sistemas han servido de referencia, aunque difieran de lo que se hace en este proyecto, por su conocimiento de las direcciones MAC tanto en Bluetooth como en WiFi, as´ı como por la informaci´on que se obtiene de los paquetes de descubrimiento de ambas redes. Uno de los conceptos en los que se basan este tipo de sistemas es lo que se conoce como “huella dactilar”, explicado en profundidad en la siguiente secci´on. Al recolectar todas las redes conocidas y asociarlas con su direcci´on MAC, se puede establecer un identificador ´unico 4 CAP´ ITULO 2. ESTADO DEL ARTE con el que seguir la pista al dispositivo. Teniendo varios puntos de acceso usados para rastreo, se puede trazar la trayectoria del usuario, ver por donde ha pasado y cu´ando, pudiendo establecer un patr´on solamente con la informaci´on de su huella [3, 5, 6]. 2.2. Caracter´ısticas utilizables para la identificaci´on El sistema propuesto para este proyecto es una estimaci´on del aforo de una sala a partir del rastreo de paquetes WiFi y Bluetooth que emitan sus dispositivos, con una Raspberry Pi, siendo capaces de relacionar los dispositivos WiFi entre s´ı acerc´andonos a una aproximaci´on real de las personas que se encuentren en el interior. Este sistema ir´a acompa˜nado de un estudio de campo sobre los dispositivos que lleva encima la gente, lo que permitir´a estimar la media de dispositivos que tiene una persona o las redes que lleva conectadas, y de un experimento realizado en la Escuela de Ingenier´ıa Inform´atica donde se recoger´an datos y se probar´an los algoritmos desarrollados sobre un grupo de usuarios controlados. Para sentar unas bases sobre estas estimaciones tanto por WiFi como por Bluetooth, se explicar´a a continuaci´on la diferencia entre los dos est´andares Bluetooth que existen, as´ı como el funcionamiento de los paquetes de descubrimiento y la informaci´on que contienen. 2.2.1. Bluetooth y BLE Comenzando por este protocolo, existe una variante creada a partir de la actualizaci´on de Bluetooth 4.0 llamada Bluetooth Low Energy, conocida como BLE. Este nuevo subprotocolo se dise˜n´o para ser utilizado en dispositivos menos potentes y m´as peque˜nos, siendo un chip de menor tama˜no que el de Bluetooth normal. La mayor´ıa de tel´efonos m´oviles y ordenadores incorporan ambos protocolos, que se van alternando dependiendo del dispositivo al que se haya conectado [7]. Ambos protocolos funcionan en la misma banda de frecuencia, 2.4 GHz, pero con la diferencia de que BLE permanece en suspensi´on hasta que activamente se inicia una conexi´on y se transmiten datos, a diferencia de Bluetooth que mientras est´e activado est´a en funcionamiento constante. Por esta diferencia, Bluetooth se utiliza para conexiones duraderas en la que se va a intercambiar una gran cantidad de datos y BLE para dispositivos que no van a transmitir tantos datos. En este proyecto se trabajar´a con BLE, ya que consume menos energ´ıa y se pueden detectar f´acilmente los dispositivos con este protocolo. 2.2.2. Direcciones MAC Una direcci´on MAC, tambi´en llamado direcci´on f´ısica, es un conjunto de 48 bits que se utiliza como un identificador ´unico del dispositivo en la capa de enlace del modelo de red OSI. Aunque este identificador supone lo mismo tanto para Bluetooth como WiFi, el significado 5 2.2. CARACTER´ ISTICAS UTILIZABLES PARA LA IDENTIFICACI ´ ON de sus bytes var´ıa: WiFi: Los 3 primeros bytes, llamados OUI, identifican al fabricante de la interfaz de red, mientras que los 3 ´ultimos bytes identifican al dispositivo, siendo la parte que se altera si se trata de una MAC aleatoria [8]. Figura 2.1: Formato de una direcci´on MAC Todos estos fabricantes est´an registrados en una lista, dentro de IEEE, en la que cada uno tiene asignados un conjunto de bytes propios. Por tanto, gracias a estos 3 bytes, se puede tener un peque˜no conocimiento sobre el dispositivo WiFi del que se est´a obteniendo informaci´on y resolver uno de los problemas que se plantear´an m´as adelante, la aleatoriedad de las direcciones MAC. Bluetooth: Dependiendo de si la direcci´on es p´ublica o aleatoria, los significados de los bytes var´ıan. Si la MAC es p´ublica los bits tienen el mismo significado que en las direcciones WiFi, pero si la MAC es aleatoria, todos sus bits ser´an generados al azar excepto los 2 m´as a la derecha, que nos indicar´an si es aleatoria pero est´atica (no var´ıa a lo largo del tiempo) o si es privada (la direcci´on cambia cada cierto tiempo) [9]. En la figura 2.2 se pueden ver los distintos tipos de direcciones que hay, de los cuales para este proyecto solo nos centraremos en la capa superior, siendo capaces de diferenciar MACs p´ublicas de aleatorias. 6 CAP´ ITULO 2. ESTADO DEL ARTE Figura 2.2: Tipos de direcciones MAC en Bluetooth Una vez hecha la distinci´on entre las dos redes con las que se va a trabajar, veamos uno de los principales problemas que surgen de estas direcciones, la aleatoriedad. MAC Aleatoria Las MACs aleatorias surgieron de la necesidad de mantener la privacidad de los usuarios. Antes de que fuese un est´andar com´un, los dispositivos ten´ıan una ´unica MAC durante toda su vida ´util, por lo que era muy f´acil rastrear estos dispositivos [5]. Con estos nuevos algoritmos se complica mucho m´as seguir el rastro a un dispositivo, ya que se tiene constancia solamente del fabricante del dispositivo. Por otro lado, para el estudio del aforo que se quiere hacer en este proyecto, basta con conocer solamente el OUI de la MAC, por lo que teniendo estos 3 bytes se puede saber si el mismo dispositivo sigue en la sala o no, ya que son bytes fijos que no van a cambiar con el resto de bits. Esta aleatoriedad de las direcciones f´ısicas est´a presente tanto en Bluetooth como en WiFi, con la diferencia del OUI explicada en el apartado anterior. 2.2.3. SSID El SSID (Service Set Identifier) es una secuencia de 32 caracteres que se utiliza como identificador de una red, bien sea Bluetooth o Wifi. Todos los puntos de acceso a los que se intente conectar un dispositivo tienen que tener un nombre de red, por ejemplo eduroam, que es el SSID de la red Wifi de la universidad. Cabe destacar que mientras que la MAC es un identificador ´unico del dispositivo (asociado a la capa de enlace), el SSID no lo es, siendo un identificador usado para ocultar la MAC del punto de acceso [10]. Este identificador se utiliza tambi´en en la b´usqueda de redes si se est´a haciendo una b´usqueda activa, es decir, si el dispositivo busca las redes conocidas transmitiendo sus SSIDs [2]. 7 2.2. CARACTER´ ISTICAS UTILIZABLES PARA LA IDENTIFICACI ´ ON 2.2.4. RSSI El RSSI (Recive Signal Strenght Indicator) es una medida que indica como de buena es la se˜nal que le llega a un dispositivo desde un punto de acceso. Su valor siempre es negativo, donde m´as pr´oximo a 0 significa que llega una mayor se˜nal y, por tanto, indica que ese dispositivo se encuentra m´as pr´oximo al punto de acceso [11]. Esta medida viene dada como un ´ındice relativo, no como decibelios, aunque se puede aproximar el valor del RSSI a un equivalente en dBm. Adem´as de indicar la calidad de la se˜nal del punto de acceso, se puede utilizar tambi´en como un indicador para ver la distancia de los dispositivos al punto de acceso. Aunque influyen m´as factores como la calidad de la interfaz de red, los objetos que haya entre ambos y la calidad del router WiFi, su impacto en cuanto a la distancia va a ser muy leve por lo que se puede realizar la estimaci´on igualmente. Esta distancia no ser´a en valores absolutos si no relativos, estableciendo unos umbrales para distancias peque˜nas, medianas o grandes [12]. 2.2.5. Probe request yProbe response Los paquetes de tipo probe request son los paquetes que env´ıan los dispositivos WiFi a los puntos de acceso (AP) para obtener informaci´on sobre estos AP y establecer una conexi´on con ellos. Los paquetes probe response son las respuestas de estos AP hacia los dispositivos. Este tipo de paquetes se intercambian cuando el dispositivo realiza b´usqueda activa, es decir, cuando busca expl´ıcitamente las redes que ya tiene guardadas, transmitiendo en cada paquete el SSID de esas redes [1]. En este proyecto nos interesa quedarnos con los paquetes probe request que son los que se utilizar´an para detectar los dispositivos. Estos mensajes de descubrimiento se env´ıan por todos los canales WiFi, los cuales se transmiten en la banda de frecuencias de 2.4 GHz yendo desde 2.401 hasta 2.483 MHz. Los env´ıos en los distintos canales van rotando entre ellos, permitiendo as´ı que cualquier AP vea al menos un mensaje de difusi´on en alguno de los canales que detecte. Cada mensaje esta compuesto de varia informaci´on transmitida en texto plano, de la cu´al interesa para este trabajo los 3 campos explicados anteriormente, la direcci´on MAC, el SSID conocido que transmita y el RSSI. El campo del SSID puede no estar presente en todos los mensajes, ya que dependiendo del fabricante de la interfaz de red y del sistema operativo puede omitirse ese campo, transmitir solamente los SSIDs de redes p´ublicas o los SSIDs de redes p´ublicas y privadas. Por una parte esto se debe a la brecha de seguridad que supone transmitir todas las SSIDs privadas a las que se ha conectado, ya sea por ser f´acilmente rastreable o por la posibilidad de recibir ataques de tipo “man in the middle”, por lo que cada vez se transmite menos informaci´on privada que pueda suponer un riesgo para el usuario, incrementado adem´as por el constante cambio de las pol´ıticas de privacidad. En cuando a Bluetooth, existen tambi´en unos paquetes de descubrimiento muy similares a estos probe request llamados inquiry packets, los cuales hacen difusiones por todos los canales disponibles. De forma similar a los paquetes WiFi, nos interesa obtener de estos paquetes la direcci´on MAC y el RSSI. Las redes conocidas se enviaban en este tipo de paquetes pero tras el riesgo que supon´ıan quitaron este campo de la comunicaci´on. 8 CAP´ ITULO 2. ESTADO DEL ARTE 2.2.6. Huella WiFi Se le denomina huella dactilar del dispositivo al conjunto de SSIDs conocidos que se env´ıan en la b´usqueda de nuevas redes. La mayor´ıa de dispositivos m´oviles realizan una b´usqueda activa de nuevas redes, estando presente en los sistemas operativos m´as utilizados hoy en d´ıa (Android, Windows, iOS, etc). Esto quiere decir que los dispositivos env´ıan paquetes de tipo probe request cada cierto tiempo buscando las redes que ya conocen, por lo que se tiene un conjunto de paquetes de difusi´on con redes conocidas distintas que se env´ıan por todos los canales. Capturando todos estos paquetes y viendo los SSIDs que contienen se puede establecer entonces una especie de identificador para cada dispositivo, combinado con la direcci´on MAC, que permitir´a detectar cada dispositivo aislado y establecer patrones gracias a ello. Esta huella es lo que se utilizar´a en el algoritmo dise˜nado para detectar si dos dispositivos son de una misma persona. Al ser necesario conocer las redes conocidas que transmite el dispositivo, este tipo de identificador est´a presente ´unicamente en WiFi [3]. 2.3. Tecnolog´ıa utilizada En esta secci´on se detallar´a la tecnolog´ıa, tanto hardware como software, que se ha utilizado para desarrollar este trabajo. 2.3.1. Raspberry Pi 3 Comenzando por la parte hardware, se ha utilizado una Raspberry Pi 3 modelo B+ para la captura de los paquetes de ambas redes y el desarrollo de los algoritmos. Este modelo incluye tanto conexi´on BLE como conexi´on de red inal´ambrica, por lo que no ha sido necesario utilizar otro ordenador o dispositivo para realizar la captura. Las principales caracter´ısticas de este dispositivo son [13]: Procesador Broadcom BCM2837B0 con arquitectura ARM8 de 64-bit, con una frecuencia de 1,4 GHz. Puerto de red Gigabit Ethernet sobre USB2.0. Conectividad inal´ambrica en bandas de 2,4GHz y 5GHz. WiFi IEEE 802.11b/g/n/ac. Bluetooth 4.2, BLE. Puertos HDMI, USB, Micro SD, Micro USB. 9 3.2. DESARROLLO DEL SNIFF BLE RF1 - Captura de paquetes Tipo de requisito Funcional Prioridad Alta Descripci´on El algoritmo debe ser capaz de capturar los paquetes necesarios para el proyecto, obteniendo solo los de tipo probe request. Motivo Esta funcionalidad es principal para relacionar los dispositivos, por lo que es esencial implementarla. Cuadro 3.3: Requisito Bluetooth Nº1 RF2 - Almacenamiento de datos Tipo de requisito Funcional Prioridad Alta Descripci´on El algoritmo debe ser capaz de guardar los datos de los dispositivos y SSIDs capturados. Motivo Esta funcionalidad servir´a para relacionar los dispositivos manteni´endolos en la base de datos, por lo que es necesaria implementarla. Cuadro 3.4: Requisito Bluetooth Nº2 RF3 - Actualizaci´on de los datos Tipo de requisito Funcional Prioridad Alta Descripci´on El algoritmo debe ser capaz de actualizar los datos de la base de datos con los nuevos datos que se capturen. Motivo Deben actualizarse los registros de la DB para tener registrado las nuevas MACs aleatorias o el tiempo de vida del registro. Cuadro 3.5: Requisito Bluetooth Nº3 RF4 - Detecci´on del tipo de MAC Tipo de requisito Funcional Prioridad Media Descripci´on El algoritmo debe ser capaz de diferenciar si la MAC del dispositivo es aleatoria o p´ublica. Motivo Esta funcionalidad resulta ´util para tener constancia de los fabricantes de los dispositivos y de cu´antas direcciones hay de cada tipo. Cuadro 3.6: Requisito Bluetooth Nº4 16 CAP´ ITULO 3. DESARROLLO RF5 - Permanencia del dispositivo Tipo de requisito Funcional Prioridad Alta Descripci´on El algoritmo debe ser capaz de detectar si un dispositivo sigue estando en la sala o no. Motivo Esta funcionalidad ser´a principal para calcular correctamente los dispositivos que hay. Cuadro 3.7: Requisito Bluetooth Nº5 RNF1 - Almacenamiento en tiempo real Tipo de requisito No Funcional Prioridad Alta Descripci´on El algoritmo debe ser capaz de guardar en tiempo real la informaci´on que capture en la base de datos. Motivo Es necesario que se guarden los datos en tiempo real para tener los dispositivos guardados seg´un se capturen. Cuadro 3.8: Requisito Bluetooth Nº6 RNF2 - Actualizaci´on en tiempo real Tipo de requisito No Funcional Prioridad Alta Descripci´on El algoritmo debe ser capaz de mantener actualizados los datos de la base de datos constantemente en tiempo real. Motivo Es necesario que se actualicen los datos en tiempo real para tener constancia de los dispositivos que hay en la sala actualmente. Cuadro 3.9: Requisito Bluetooth Nº7 3.2.2. Modelo de datos Para este algoritmo se ha utilizado una ´unica tabla de la basde de datos llamada DataBluetooth, en la cu´al se guardar´an los datos recogidos de cada direcci´on MAC. Esta tabla se crear´a en la base de datos cada vez que se inicie la captura de paquetes de BLE y, en caso de que estuviese creada, se vaciar´a al inicio de la captura, por lo que no se conservar´an los datos de los dispositivos en la base de datos a lo largo del tiempo. Los datos que se guardar´an en esta tabla son: mac: Direcci´on MAC del dispositivo del que se ha capturado el paquete. mac type: Nombre del fabricante de la interfaz Bluetooth o Random en caso de que se una MAC aleatoria y no se conozca el fabricante. 17 3.2. DESARROLLO DEL SNIFF BLE rssi: Intensidad de la se˜nal del dispositivo. date: Fecha y hora a la que se ha capturado el paquete. TTL: Contador de tiempo de vida del paquete, inicialmente establecido en 1. Todos estos atributos de la tabla son de tipo text, lo que facilita guardarlos en la base de datos y las comparaciones entre ellos. 3.2.3. Dise˜no del algoritmo En esta secci´on se detallar´a el algoritmo con el que se obtienen los distintos paquetes y dispositivos Bluetooth, explicando la hip´otesis para la detecci´on de dispositivos y el algoritmo creado. Hip´otesis de captura La hip´otesis en la que se basar´a este algoritmo es una simplificaci´on del n´umero de dispositivos que puede llevar una persona, que se establecer´a en que cada dispositivo BLE es una persona. Por tanto, para cada MAC distinta que tengamos en la base de datos habr´a una persona en la sala. Algoritmo El primer paso que ejecuta este algoritmo es iniciar el rastreo de los paquetes con un bucle que capture cada 3 segundos y, una vez se analizan todos esos paquetes, volver a capturar. Estos paquetes son todos paquetes de descubrimiento de difusi´on, por lo que no es necesario aplicar un filtro para quedarse solo con esos paquetes. Para el an´alisis de cada paquete lo primero que se comprueba es si la direcci´on MAC se encuentra en la base de datos, donde si el identificador ya est´a guardado se pasa al siguiente paquete capturado. Tras esto se obtiene si la direcci´on MAC es p´ublica o privada, gracias a una funci´on de la librer´ıa utilizada, y, en caso de ser p´ublica, se comprueba si es una direcci´on registrada en IEEE. En caso de estar registrada se guardar´a en la base de datos el fabricante de ese chip, si no lo est´a pero es una direcci´on p´ublica se guardar´a la cadena “public, unknown manufacter” y si es una MAC aleatoria se guardar´a la cadena “random”. Como se comentaba en la secci´on anterior, se obtiene tambi´en la hora a la que se est´a analizando el paquete y el rssi del dispositivo, que se incluyen en la base de datos en una ´unica tupla junto a los datos de la MAC. Tras este paso se vuelve al inicio del bucle y se empiezan a capturar de nuevo paquetes. 18 CAP´ ITULO 3. DESARROLLO Figura 3.2: Diagrama de flujo del algoritmo BLE 3.2.4. Implementaci´on En esta secci´on se detallar´a el procedimiento seguido para el desarrollo de este algoritmo, as´ı como las herramientas utilizadas. 19 3.2. DESARROLLO DEL SNIFF BLE Entorno de trabajo Antes de empezar la programaci´on del algoritmo fue necesario preparar el entorno de trabajo e instalar las librer´ıas que se iban a utilizar en la Raspberry Pi. Como se ha utilizado la Raspberry que se utiliz´o en el proyecto de Aitor Ojeda, no ha hecho falta instalar ning´un software, ya que Wireshark,Scapy,Python ySQLite3 estaban ya instalados. Las versiones utilizadas de estos programas han sido: Kali Linux 2020.2 Python 3.9.2 Wireshark 3.4.4 SqLite3 3.33.0 Adem´as de estos programas, se ha utilizado el entorno de programaci´on que trae por defecto Kali Linux, Mousepad, que funciona como editor para diferentes lenguajes de texto. Las librer´ıas que se utilizan para este algoritmo son: bluepy: Se utilizar´a para capturar los paquetes de descubrimiento BLE, ya que es una herramienta bien optimizada y m´as sencilla de utilizar para Bluetooth que Scapy, adem´as de que filtra autom´aticamente los paquetes de difusi´on de descubrimiento [20]. mac vendor lookup: Se utilizar´a para obtener el fabricante del chip Bluetooth, ya que directamente busca si se encuentra la MAC registrada en IEEE [23]. db: Se ha creado esta clase, que se utilizar´a como librer´ıa, para crear, insertar y consultar la base de datos que se ha utilizado. Aunque ya estaba implementada en el proyecto de partida, se han a˜nadido nuevos m´etodos para la tabla de dispositivos Bluetooth datatime: Se ha utilizado esta librer´ıa del sistema para obtener la hora en la que se analiza el paquete y poder as´ı guardar la fecha y hora exacta en la base de datos. Las primeras dos librer´ıas se han instalado con el comando pip3, siguiendo sus respectivas p´aginas de documentaci´on: pip3 install <librer´ıa> Para este algoritmo se ha creado un ´unico archivo, llamado sniff bl.py, que contiene todo el proceso descrito anteriormente, adem´as de utilizar la clase db.py para la base de datos. 20 CAP´ ITULO 3. DESARROLLO 3.3. Desarrollo del algoritmo WiFi En esta secci´on se detallar´a todo el desarrollo del algoritmo implementado para relacionar los dispositivos WiFi entre s´ı y determinar as´ı el aforo de la sala. Se explicar´a tanto el dise˜no del algoritmo como las herramientas utilizadas, los datos que se guardar´an en la base de datos y la hip´otesis utilizada para dise˜nar el algoritmo. 3.3.1. An´alisis En esta secci´on se detallar´an los requisitos tanto funcionales como no funcionales del algoritmo, de forma similar a los requisitos del algoritmo Bluetooth en la secci´on anterior. RF1 - Captura de paquetes Tipo de requisito Funcional Prioridad Alta Descripci´on El algoritmo debe ser capaz de capturar los paquetes necesarios para el proyecto, obteniendo solo los de tipo probe request. Motivo Esta funcionalidad es principal para relacionar los dispositivos, por lo que es esencial implementarla. Cuadro 3.10: Requisito WiFi Nº1 RF2 - Almacenamiento de datos Tipo de requisito Funcional Prioridad Alta Descripci´on El algoritmo debe ser capaz de guardar los datos de los dispositivos y SSIDs capturados. Motivo Esta funcionalidad servir´a para relacionar los dispositivos manteni´endolos en la base de datos, por lo que es necesaria implementarla. Cuadro 3.11: Requisito WiFi Nº2 RF3 - Actualizaci´on de los datos Tipo de requisito Funcional Prioridad Alta Descripci´on El algoritmo debe ser capaz de actualizar los datos de la base de datos con los nuevos datos que se capturen. Motivo Deben actualizarse los registros de la DB para tener registrado las nuevas MACs aleatorias o el tiempo de vida del registro. Cuadro 3.12: Requisito WiFi Nº3 21 3.3. DESARROLLO DEL ALGORITMO WIFI RF4 - Detecci´on del tipo de MAC Tipo de requisito Funcional Prioridad Media Descripci´on El algoritmo debe ser capaz de diferenciar si la MAC del dispositivo es aleatoria o p´ublica. Motivo Esta funcionalidad resulta ´util para tener constancia de los fabricantes de los dispositivos y de cu´antas direcciones hay de cada tipo. Cuadro 3.13: Requisito WiFi Nº4 RF5 - Permanencia del dispositivo Tipo de requisito Funcional Prioridad Alta Descripci´on El algoritmo debe ser capaz de detectar si un dispositivo sigue estando en la sala o no. Motivo Esta funcionalidad ser´a principal para calcular correctamente el aforo sabiendo cu´antos dispositivos hay. Cuadro 3.14: Requisito WiFi Nº5 RF6 - Relaci´on de dispositivos Tipo de requisito Funcional Prioridad Alta Descripci´on El algoritmo debe ser capaz de relacionar los dispositivos entre s´ı. Motivo Esta funcionalidad permitir´a detectar a las personas en la sala adem´as de los dispositivos. Cuadro 3.15: Requisito WiFi Nº6 RF7 - Relaci´on dispositivo/persona Tipo de requisito Funcional Prioridad Alta Descripci´on El algoritmo debe ser capaz de detectar cuantos dispositivos llevan las personas de la sala bas´andose en el requisito Nº 6. Motivo Esta funcionalidad permitir´a detectar el n´umero de personas que hay en la sala independientemente de los dispositivos. Cuadro 3.16: Requisito WiFi Nº7 22 CAP´ ITULO 3. DESARROLLO RNF1 - Almacenamiento en tiempo real Tipo de requisito No Funcional Prioridad Alta Descripci´on El algoritmo debe ser capaz de guardar en tiempo real la informaci´on que capture en la base de datos. Motivo Es necesario que se guarden los datos en tiempo real para tener los dispositivos guardados seg´un se capturen. Cuadro 3.17: Requisito WiFi Nº8 RNF2 - Actualizaci´on en tiempo real Tipo de requisito No Funcional Prioridad Alta Descripci´on El algoritmo debe ser capaz de mantener actualizados los datos de la base de datos constantemente en tiempo real. Motivo Es necesario que se actualicen los datos en tiempo real para tener constancia de los dispositivos que hay en la sala actualmente. Cuadro 3.18: Requisito WiFi Nº9 3.3.2. Modelo de datos Para este algoritmo se han utilizado 4 tablas de la base de datos llamadas DataSniff, DataSniffRandom,SsidRegister yPerson. Las dos primeras se utilizan para guardar los dispositivos con MAC p´ublica y MAC aleatoria, respectivamente. Estas dos tablas fueron creadas en el proyecto de partida y se han mantenido para simplificar el trabajo con los paquetes WiFi. La 3ªtabla se utilzia para guardar los SSIDs que se capturen de los mensajes probe request, y la ´ultima tabla se utilizar´a para guardar los dispositivos relacionados entre s´ı, teniendo una “persona” por fila. Los campos de la tabla SsidRegister son: mac: Direcci´on MAC del dispositivo que transmite el paquete. ssid: SSID capturado del paquete. date: Fecha en la que se captur´o el paquete. Con estos campos se tiene la informaci´on necesaria para poder relacionar dos dispositivos como se ver´a en el siguiente apartado. Todos los atributos son de tipo text para guardar y comparar m´as f´acilmente los datos. La tabla Person guarda ´unicamente las direcciones MACs relacionadas entre s´ı, por lo que tendr´a de 2 a 4 campos, dependiendo del par´ametro de dispositivos por personas del algoritmo, el cu´al se explica m´as adelante, en los que se guardar´an esas direcciones. Igual que el resto de tablas, todos sus campos son de tipo text. 23 3.3. DESARROLLO DEL ALGORITMO WIFI 3.3.3. Dise˜no En esta secci´on se detallar´a el algoritmo con el que se relacionan los distintos dispositivos WiFi entre s´ı y se detectan cuantas personas hay en la sala, explicando la hip´otesis para la relaci´on de estos y el algoritmo creado. Hip´otesis de relaci´on La hip´otesis de este algoritmo es, fundamentalmente, que cada persona lleva consigo un n´umero medio de dispositivos, por lo que relacionandolos entre si se obtendr´a una estimaci´on m´as precisa del aforo de esa sala. Algoritmo Este algoritmo se ejecuta simult´aneamente junto con el de captura de dispositivos WiFi cuando el paquete capturado tenga un SSID dentro de los datos que transmite. Antes de ejecutar este algoritmo se comprueba si el SSID est´a en la base de datos y, en caso de que no est´e, se guarda en la tabla SsidRegister. El primer paso de este algoritmo es obtener todos los SSIDs que el dispositivo ha transmitido y, por tanto, se encuentran en la base de datos. Tras esto, si hay al menos dos redes se contin´ua con el proceso y, si no, se pasa a la siguiente captura. Este n´umero de redes m´ınimas viene establecido por la hip´otesis explicada en el apartado anterior. Tras esto se crea un diccionario en el que guardar las direcciones MAC como “key” y un valor num´erico como “value”, que ser´a el n´umero de SSIDs coincidentes por cada direcci´on MAC. Una vez se tienen las redes asociadas a ese dispositivo, se pasan a analizar individualmente. De cada una de ellas se obtienen las direcciones MACs que han transmitido esa SSIDs y se a˜naden al diccionario, incrementando en uno su valor si ya estaban en ´el o a˜nadiendo el identificador con un valor igual a 1. Por ´ultimo se trata cada MAC del diccionario por s´ı sola. Se comprueba si el valor de esa MAC es mayor que lo establecido como el n´umero m´ınimo de redes coincidentes necesarias para que dos dispositivos pertenezcan a la misma persona (en este caso 2, con el desarrollo del experimento m´as adelante explicado este valor podr´a cambiar para ajustarse a un caso m´as real), y en caso de ser as´ı se crea o actualiza la tupla de la tabla Person. En caso de que haya que actualizar la tupla se introducir´a la direcci´on MAC del diccionario en la misma fila que est´a la direcci´on MAC del dispositivo y, en caso de estar llena, se crear´a una nueva tupla con este identificador como ´unico valor. 3.3.4. Implementaci´on En esta secci´on se detallar´a el procedimiento seguido para el desarrollo de este algoritmo, as´ı como las herramientas utilizadas. 24 CAP´ ITULO 3. DESARROLLO Figura 3.3: Diagrama de flujo del algoritmo WiFi Entorno de trabajo Igual que se explicaba en el algoritmo BLE, antes de comenzar con la programaci´on del algoritmo fue necesario preparar el entorno de trabajo e instalar las librer´ıas que se iban a utilizar en la Raspberry Pi. 25 4.2. RESULTADOS DE LA ENCUESTA 4.2.1. Encuesta del experimento Durante el experimento se realiz´o la encuesta que se encuentra en el anexo B, contando con la participaci´on de los 11 alumnos presentes en el aula. En total hab´ıa en el aula 23 dispositivos, con una media de 2,09 dispositivos por persona. La principal marca de estos dispositivos es Xiaomi, habiendo un total de 7, seguida por Samsung con 4. De las 11 personas del aula, 9 llevan conectada la red WiFi y 7 llevan conectado Bluetooth, coincidiendo en 5 usuarios las dos redes encendidas simult´aneamente. Por la parte de WiFi, la media de redes que tienen guardadas los usuarios es 4,9, de las cuales todos los usuarios coinciden en que tienen menos de 2 redes p´ublicas guardadas, siendo las m´as frecuentes la red de la universidad y la red privada de casa. En cuanto a Bluetooth, 7 usuarios tienen guardados menos de 5 dispositivos a los que se han conectado, 2 usuarios tienen guardados entre 6 y 10 dispositivos y los otros 2 usuarios restantes tienen guardados entre 11 y 15 dispositivos a los que se han conectado previamente. De todos estos dispositivos guardados, los principales son cascos inal´ambricos, relojes o pulseras inteligentes, altavoces o reproductores multimedia y ordenadores. Con menos respuestas se encuentran los navegadores de los coches y las tablets. 4.2.2. Encuesta p´ublica La encuesta ha contado con una participaci´on de 153 usuarios. La media de dispositivos que llevan los encuestados es 1,87, algo menor que en la encuesta del experimento. La marca m´as com´un entre esos dispositivos es Xiaomi, con un total de 69, seguido por Samsung con 42 dispositivos. 130 de los encuestados llevan normalmente encendida la red WiFi, 76 llevan encendido Bluetooth y 72 de ellos coinciden en llevar ambas redes encendidas. En cuanto a WiFi, la media de redes que tienen guardadas los usuarios es de 10,46, de las cuales la mayor´ıa coinciden en que p´ublicas son menos de 2. En cuanto a Bluetooth, 125 usuarios tienen guardados menos de 5 dispositivos a los que se han conectado, siendo la mayor´ıa de respuestas. De esos dispositivos, los m´as comunes a los que se conectan los encuestado son cascos inal´ambricos, relojes o pulseras inteligentes, reproductores multimedia y navegadores de coches, en ese orden. 32 CAP´ ITULO 5. DISCUSI ´ ON Cap´ıtulo 5 Discusi´on En este cap´ıtulo se van a discutir los resultados obtenidos en el experimento relacion´andolos con la encuesta, tanto la propia del experimento como con la general. Adem´as se comparar´an los resultados obtenidos en la encuesta con otros estudios hechos por compa˜n´ıas como Cisco, y se definir´an los par´ametros del algoritmo WiFi dise˜nado en este proyecto para que sea lo m´as ´optimo posible. Bluetooth Comenzando por los dispositivos Bluetooth obtenidos en el experimento, se han detectado un total de 11 dispositivos. Relacionando este resultado con las de la encuesta, 7 alumnos llevaban encendido Bluetooth durante el experimento. El n´umero total de dispositivos que llevaban estos alumnos que indicaron que sol´ıan llevarlo encendido era 17, de los cuales 4 tienen una pulsera inteligente que llevan siempre conectada al tel´efono m´ovil. En la figura 5.1 se puede ver una parte de los resultados de la encuesta con los resultados pertenecientes a Bluetooth. Figura 5.1: Resultados de la encuesta en cuanto a Bluetooth De los 7 alumnos que ten´ıan encendido Bluetooth, 4 llevaban pulsera inteligente o cascos inal´ambricos conectados, por lo que ah´ı tenemos 2 dispositivos BLE para cada uno, teniendo as´ı por ahora 8 dispositivos reales. 33 Teniendo en cuenta que en el experimento realizado se detectaron 11 dispositivos, puede ser una estimaci´on bastante acertada teniendo en cuenta sabemos con certeza que hay m´ınimo 8 dispositivos con el Bluetooth activado, m´as alg´un dispositivo de los usuarios que suelen llevar encendido Bluetooth pero no tienen pulsera inteligente o cascos siempre conectado, el n´umero de dispositivos detectados es una estimaci´on aceptable de los dispositivos reales que hab´ıa. WiFi En el experimento se detectaron 600 entradas en la base de datos procedentes de dispositivos con una direcci´on MAC aleatoria. Dado que no hab´ıa tantos dispositivos en el aula, la causa de este n´umero tan alto de registros fue un problema con el tiempo de vida, TTL, de las entradas en la tabla. Al capturar paquetes en tiempo real, si una direcci´on MAC no se ha vuelto a detectar en un lapso de 3 minutos, se elimina de la base de datos y se considera que ese dispositivo no se encuentra en la sala. En la ejecuci´on del experimento se deshabilit´o la funci´on de eliminar registros de la base de datos para as´ı tener la mayor cantidad de informaci´on posible, pero no se tuvo en cuenta que esto podr´ıa darse. Por este motivo, el an´alisis de los datos se har´an bas´andose en las direcciones MAC p´ublicas y en las SSIDs capturadas, que aunque pertenezcan a un dispositivo con una MAC aleatoria servir´a para ajustar los par´ametros del algoritmo y aproximar el aforo del aula. Se detectaron 21 SSIDs distintas de un total de 46, por lo que hab´ıa dispositivos que estaban relacionados entre s´ı, por lo que se aplic´o el algoritmo WiFi dise˜nado en este proyecto con distintos par´ametros, para comprobar con que combinaci´on de ellos daban unos resultados m´as reales. Entre todas estas SSIDs se descart´o la red eduroam, ya que el experimento se realiz´o en un aula de la universidad y todos los dispositivos iban a transmitir esa red como una red conocida. Figura 5.2: Personas detectadas seg´un los par´ametros del algoritmo En la figura 5.2 se pueden ver los valores que se han dado a los par´ametros del algoritmo y a las personas que se han detectado con cada uno de esos par´ametros, junto al error de detecci´on que hay en cada caso. Aunque se detectan m´as personas de las que hab´ıa en el aula (13, aunque con el WiFi encendido solo hab´ıa 12 personas), se debe a que el experimento no se realiz´o de forma aislada y hab´ıa m´as alumnos tanto en las clases contiguas como en las aulas del piso de arriba, por lo que las condiciones no eran ideales. Al haber quitado eduroam del conjunto de SSIDs, lo m´as ´optimo seg´un se aprecia en la figura anterior es ajustar el par´ametro del n´umero de SSIDs coincidentes a 1 para este experimento, y a 2 cuando se est´e probando en un entorno real. 34 CAP´ ITULO 5. DISCUSI ´ ON Con este par´ametro a 1, se puede ajustar el par´ametro de n´umero m´aximo de dispositivo que puede llevar una persona. Tanto en la encuesta del experimento como en la encuesta p´ublica, la media de dispositivos por persona era de 2, por lo que con estos dos par´ametros ajustados en este entorno, se obtienen 19 personas dentro del aula (primera fila de la figura 5.2). Este resultado difiere ligeramente del n´umero de usuarios reales en la sala, que eran 12 con el WiFi activado, pero se podr´ıa considerar una estimaci´on aceptable teniendo en cuenta que var´ıa en 7 personas, que podr´ıan estar en alg´un aula contiguo como se explicaba anteriormente o que no se hayan podido capturar tantas SSIDs como para relacionar dos dispositivos. Seg´un el estudio realizado por Cisco [25], la media de dispositivos que lleva una persona pasar´a desde 2,4 que hab´ıa en 2018 hasta 3,6 en 2023, por lo que con el creciente aumento de dispositivos inal´ambricos con redes WiFi, se podr´ıa establecer este par´ametro del algoritmo en 3 dispositivos como m´aximo. Con esto, se tendr´ıan un total de 16 personas en el aula, m´as pr´oximo a la realidad aunque cambiando un par´ametro obtenido en la encuesta. De estos dispositivos que se indican en el estudio de Cisco, habr´a dispositivos que no tengan WiFi, como pueda ser una pulsera inteligente o cascos inal´ambricos, por lo que se dejar´a establecido en 2 el n´umero de dispositivos por persona para el algoritmo WiFi. La mayor´ıa de SSIDs capturados eran de redes p´ublicas, con alguna red privada de Movistar o Vodafone, pero en su mayor´ıa p´ublicas. Esto supone un problema a la hora de estimar el aforo correctamente, ya que no se tienen suficientes redes para relacionar dos dispositivos que puedan ser de la misma persona, debido como se explicaba en el cap´ıtulo 2 a que los dispositivos suelen transmitir solamente redes p´ublicas debido a brechas de seguridad. Esto tambi´en justifica que se hayan obtenido 19 personas en el aula, ya que no se pueden obtener m´as SSIDs ni informaci´on sobre los dispositivos relacionados sin interactuar directamente con ellos, algo fuera del alcance de este proyecto. 35 36 CAP´ ITULO 6. CONCLUSIONES Cap´ıtulo 6 Conclusiones En este proyecto se han presentado dos algoritmos completamente funcionales con los que detectar tanto los dispositivos Bluetooth como las personas que se encuentran en una sala, dando as´ı una aproximaci´on del aforo de esta. Adem´as, se han probado estos sistemas en un entorno real, obteniendo as´ı unos resultados que han servido para perfeccionar el segundo algoritmo y obtener as´ı una aproximaci´on m´as precisa. La encuesta cont´o con m´as participaci´on de la esperada, obteniendo un total de 153 respuestas, por lo que ha resultado ´util para ajustar esos par´ametros que se comentaban durante este documento. Los resultados obtenidos, pese a diferir de la realidad, son una estimaci´on aceptable teniendo en cuenta que el experimento no se realiz´o en condiciones ideales, por lo que el algoritmo dise˜nado para relacionar dispositivos WiFi resuelve el problema planteado al inicio del proyecto. El algoritmo Bluetooth tambi´en es completamente funcional, detectando los dispositivos que tenga cerca el punto de rastreo, dando as´ı una aproximaci´on de estos. Comparado con el resto de m´etodos para calcular el aforo, que se comentaban en el cap´ıtulo 2, el m´etodo dise˜nado en este trabajo tiene un coste mucho menor que otro tipo de sensores, adem´as de mantener la privacidad de los usuarios, por lo que puede ser interesante seguir trabajando sobre este m´etodo en un futuro e intentar ajustar m´as los algoritmos, intentando relacionar los dispositivos Bluetooth entre s´ı tambi´en o incluso los dispositivos Bluetooth y WiFi de la misma persona, dando as´ı una estimaci´on a´un m´as precisa de la ocupaci´on de la sala. 37 38 AP ´ ENDICE A. MANUAL DE USUARIO Ap´endice A Manual de usuario A.1. Script de ejecuci´on import os import threading import time from tempo import ∗ from s n i f f b l import ∗ from s n i f f w i f i import main wifi os . system ( ”airmon−ng check k i l l ” ) os . system ( ”airmon−ng s t a r t wlan0” ) thread tempo = threading . Thread ( ta rg et=tempo , daemon=True ) thread b l = threading . Thread ( tar ge t=main bl , daemon=True ) t h r e a d w i f i = th read ing . Thread ( t ar g et=main wifi , daemon=True ) thread tempo . s t a r t ( ) thread b l . s t a r t ( ) t h r e a d w i f i . s t a r t ( ) while True : time . s leep (10) Para ejecutar el script, y por tanto los 2 algoritmos, lo ´unico necesario ser´a moverse a la carpeta donde se encuentra el script y ejecutarlo con el comando: python3 s t a r t . py 39 A.1. SCRIPT DE EJECUCI ´ ON 40 AP ´ ENDICE B. PREGUNTAS DE LA ENCUESTA Ap´endice B Preguntas de la Encuesta Normalmente, ¿Cu´antos dispositivos con WiFi o Bluetooth llevas encima? 0 1 2 3 4 o m´as ¿De qu´e marca son los dispositivos que sueles llevar encima? (M´ovil, PC, Smartwatch, etc) Respuesta m´ultiple entre varias marcas con opci´on de “Otro”. En caso de utilizar Mi Band, Smartwatch, cascos inal´ambricos, etc ¿Lo llevas conectado la mayor parte del tiempo al tel´efono m´ovil? Si No ¿Que redes llevas encendidas normalmente? WiFi Bluetooth 41