Entre los principales protocolos de comunicaci贸n inal谩mbrica de Internet de las cosas que se comentan en este art铆culo, el m谩s utilizado para comunicaciones de bajo consumo y corto alcance es el Bluetooth Low Energy (BLE), dada su alta eficiencia y el bajo coste de los equipos de radio. Por supuesto, tiene muchas limitaciones en t茅rminos de velocidad de datos y rango operativo, pero es suficiente para muchas redes de sensores inal谩mbricos construidas dentro de un edificio peque帽o como un piso o un invernadero, o en un campo abierto, como en el jard铆n.
Hoy veremos c贸mo funciona Bluetooth Low Energy y c贸mo podemos usarlo para aplicaciones de Internet de las cosas, analizando dos formas de usar el protocolo de comunicaci贸n inal谩mbrica BLE para recuperar datos de muchos nodos de detecci贸n en IoT.
Tambi茅n veremos los puntos fuertes y d茅biles de este protocolo, tanto comparado con Bluetooth Classic como incluso con el potente y r谩pido Wi-Fi.
Qu茅 es Bluetooth Low Energy y c贸mo funciona
Bluetooth de baja energ铆a es un protocolo de comunicaci贸n de corto alcance que se puede utilizar para crear redes de 谩rea personal inal谩mbricas (WPAN), que normalmente tienen un alcance de unos pocos metros hasta uno 50 metros en aplicaciones de l铆nea de visi贸n (LoS). Entonces, mirando el siguiente gr谩fico, estamos viendo la esquina inferior derecha. Uno de los protocolos m谩s comunes utilizados para este tipo de red inal谩mbrica es Bluetooth, que se puede utilizar en la variante Classic para operaciones de transferencia de datos sincr贸nica, o Bluetooth Low Energy, que se utiliza a menudo para redes de sensores inal谩mbricos de m煤ltiples nodos de baja potencia y para interiores. Tambi茅n para localizaci贸n a trav茅s de balizas, ya que tiene un buen alcance y un consumo energ茅tico muy bajo.
Bluetooth Classic vs Bluetooth Low Energy: casos de uso y diferencias de la capa f铆sica
Como se mencion贸 anteriormente, Bluetooth Classic es la versi贸n est谩ndar original, que se lanz贸 inicialmente en 1999. La 煤ltima versi贸n del est谩ndar Bluetooth Classic es la 5.2 y, como la anterior, opera en 79 canales con un ancho de banda de 1 MHz y un espaciado de 1 MHz en la banda ISM de 2.4 GHz, que se definen como se muestra a continuaci贸n.
Bluetooth Low Energy est谩 disponible desde la versi贸n 4.0 del protocolo y, como su nombre indica, BLE sacrifica el rendimiento y el rango operativo a favor de un menor consumo de energ铆a. En comparaci贸n con la variante Classic, BLE opera en la misma banda ISM libre de 2.4 GHz y utiliza las mismas t茅cnicas de modulaci贸n por desplazamiento de frecuencia gaussiana (GFSK) y espectro ensanchado por salto de frecuencia (FHSS) para minimizar los efectos destructivos del desvanecimiento y el ruido de canal de Wi-Fi que operan en la misma banda (a continuaci贸n puede ver el espectro de canales Wi-Fi 2.4 GHz).
A diferencia de Bluetooth Classic, la variante BLE utiliza solo 40 canales en la banda de 2,4 GHz, con un espaciado de canales que va de 1 a 2 MHz. Entre los 40 canales proporcionados por el BLE, tres de ellos est谩n reservados exclusivamente para el proceso de Publicidad, a saber, los canales 37, 38 y 39. Los 37 canales restantes, en cambio, se utilizan para la transferencia de datos entre el maestro y el esclavo en modo conexi贸n. Estos tres canales de publicidad est谩n ubicados en los puntos finales y en el medio de la banda de 2.4 GHz, para limitar la interferencia con las redes Wi-Fi, como se ve a continuaci贸n.
Normalmente, Bluetooth Classic se utiliza principalmente para todo tipo de conexiones que requieren sincronizaci贸n continua ( Synchronous Connection Oriented Link ), como, por ejemplo, una conexi贸n entre un tel茅fono inteligente y un altavoz Bluetooth, un par de auriculares o durante una conexi贸n de datos reales como la transferencia de datos entre dos tel茅fonos inteligentes vecinos. BLE, en cambio, se usa principalmente para dispositivos port谩tiles, dispositivos inteligentes y sensores ambientales econ贸micos que funcionan con bater铆as, ya que estos dispositivos comunican sus datos peri贸dicamente a un maestro central que act煤a como puerta de enlace, por lo que realizan comunicaciones de datos as铆ncronas ( conexi贸n as铆ncrona sin enlace ) a uno o m谩s nodos maestros.
Bluetooth Classic vs Bluetooth Low Energy: tasas de datos, consumo de energ铆a y rangos operativos
Los dos protocolos tienen casos de uso diferentes, tienen un consumo de energ铆a significativamente diferente, por lo tanto, rangos de operaci贸n diferente. La velocidad de transmisi贸n de Bluetooth Classic (tasa de bits) depende del tipo de modulaci贸n por desplazamiento de fase adoptado pero, por lo general, la tasa de transferencia te贸rica va desde 1 Mbps hasta 3 Mbps (con EDR). En cambio, Bluetooth Low Energy puede alcanzar una velocidad m谩xima de datos de aproximadamente 2 Mbps en la quinta versi贸n del protocolo.
El rango de funcionamiento de la tecnolog铆a Bluetooth Classic depende de la potencia radiada por la antena. Con base en este 煤ltimo factor, es posible identificar tres clases de potencia principales para dispositivos Bluetooth Classic, que se muestran en la siguiente tabla. Generalmente, los dispositivos que funcionan con el protocolo Bluetooth Classic pertenecen a la Clase 2, por lo que tienen un alcance t铆pico de hasta 30 m en campo abierto.
En cuanto a Bluetooth Low Energy, a diferencia de Bluetooth Classic, no existen clases de potencia, sino un rango de funcionamiento entre dos extremos, es decir, los valores de potencia m谩xima y m铆nima a la salida del transmisor. Estos l铆mites son respectivamente 10 mW y 0,01 mW, por lo que son mucho m谩s bajos que los dispositivos Bluetooth Classic. A diferencia de este 煤ltimo, el rango de funcionamiento tambi茅n disminuye, oscilando desde un m铆nimo de un metro hasta un m谩ximo en torno a los 20 metros en campo abierto.
Estructuras de paquetes Bluetooth
BLE funciona de manera ligeramente diferente en niveles de protocolo m谩s altos en comparaci贸n con Bluetooth Classic. De hecho, BLE no solo tiene menos canales que Bluetooth Classic, sino que tambi茅n sus paquetes son m谩s peque帽os. Bluetooth Classic tiene diferentes tipos de paquetes, seg煤n el tipo de transporte l贸gico utilizado para la transmisi贸n. Normalmente son: Asynchronous Connection Less (ACL), Synchronous Connection Oriented (SCO) y enhanced Synchronous Connection Oriented (eSCO). Sin embargo, un paquete gen茅rico de Bluetooth Classic se compone de tres campos: c贸digo de acceso (68 o 72 bits), encabezado (54 bits) y carga 煤til (de 0 a 2745 bits). Su estructura se muestra a continuaci贸n.
El c贸digo de acceso identifica todos los paquetes emitidos en el mismo canal f铆sico, que tendr谩n el mismo valor. En cambio, el encabezado es una serie de 54 bits que contiene toda la informaci贸n sobre el control de la conexi贸n y la direcci贸n l贸gica de transporte, que se usa para identificar el esclavo activo de una piconet, seguida del tipo de paquete utilizado. Finalmente, la carga 煤til, que contiene los datos reales transportados. Adem谩s, tambi茅n existe un segundo tipo de paquete relacionado con la variante EDR (Enhanced Data Rate) de Bluetooth, que, a diferencia del primer tipo, proporciona algunos sistemas de control adicionales para aprovechar dos modulaciones diferentes simult谩neas utilizadas para la transmisi贸n de un mismo paquete.
Los paquetes BLE son, como se dijo anteriormente, m谩s peque帽os (en particular los paquetes publicitarios) con el fin de minimizar el tiempo de activaci贸n de la radio para la transmisi贸n y recepci贸n y, por lo tanto, el consumo de energ铆a. La estructura del paquete BLE t铆pico es visible a continuaci贸n y, como puede ver, hay cuatro partes: Pre谩mbulo (8 bits), Direcci贸n de acceso (32 bits), Unidad de datos de protocolo (entre 2 y 39 bytes) y un C贸digo de redundancia c铆clica (CRC) final de (24 bits).
El pre谩mbulo consta de 8 bits y el receptor lo utiliza para la sincronizaci贸n. Tambi茅n es 煤til para identificar qu茅 paquetes se emiten en los canales de publicidad y en los canales de datos. La Direcci贸n de Acceso consta de 32 bits y tiene diferentes valores seg煤n el tipo de canal: canales de publicidad o de datos. Por ejemplo, la direcci贸n de acceso de cualquier paquete transmitido en los canales de publicidad tiene un valor hexadecimal igual a 8E89BED6. El campo Protocol Data Unit (PDU) tiene una longitud variable (de 2 a 39 bytes) y tiene una estructura diferente seg煤n el tipo de canal de destino (Datos o Publicidad). Para los canales de publicidad, la PDU est谩 compuesta por dos campos: un encabezado de 2 bytes y un campo de carga 煤til de 0 a 37 bytes. En cambio, para los canales de datos, la estructura de la PDU tiene tres componentes: un encabezado de 2 bytes y una carga 煤til con un tama帽o de hasta 255 bytes, que podr铆a incluir un campo de verificaci贸n MIC.
Mecanismo de direcci贸n: algo que debe saber antes de desarrollar en BLE
Bluetooth Low Energy tiene muchos tipos diferentes de direcciones. Normalmente, la direcci贸n de Bluetooth transmitida de un dispositivo corresponde a la direcci贸n MAC del equipo de radio. Sin embargo, muchos dispositivos, especialmente los tel茅fonos inteligentes, utilizan de forma predeterminada una direcci贸n de tipo aleatorio, que, por supuesto, no es la direcci贸n MAC real del dispositivo. Entonces, mirando la especificaci贸n de Bluetooth, hay muchos tipos de direcciones. Las dos categor铆as principales son: direcciones p煤blicas y direcciones aleatorias. Por lo general, los wearables y los dispositivos baratos vienen con una direcci贸n p煤blica, que es la direcci贸n MAC fija de la radio del dispositivo. Por lo tanto, nunca cambiar谩. Sin embargo, como se dijo antes, los dispositivos complejos como tel茅fonos inteligentes, relojes inteligentes e incluso computadoras, generalmente usan una direcci贸n aleatoria para mejorar la privacidad y seguridad, que se puede categorizar en dos clases: Est谩tica y Privada. Adem谩s, las direcciones privadas se pueden clasificar en resolubles y no resolubles. Puede consultar el siguiente esquema para comprender mejor la categorizaci贸n de direcciones.
Como se anticip贸, los tel茅fonos inteligentes Android utilizan Private Resolvable addresses, que explotan un algoritmo matem谩tico para la generaci贸n de una clave de resoluci贸n, que se comparte peri贸dicamente con los dispositivos emparejados. Esta compartici贸n peri贸dica es la raz贸n por la cual, si bien la direcci贸n cambia peri贸dicamente, los dispositivos ya emparejados a煤n pueden resolverlo y realizar la conexi贸n sin tener que repetir los pasos de autenticaci贸n.
Cualquier tipo de direcci贸n consta de 48 bits. En las direcciones de tipo p煤blico, los primeros 24 bits son asignados por el fabricante, mientras que el segundo grupo de 24 bits es el ID del propio fabricante. En cambio, las direcciones aleatorias se generan aleatoriamente y, entre ellas, las de tipo resoluble se dividen en dos partes, el hash y el prand, mientras que las de tipo no resoluble contienen 46 bits totalmente aleatorios. La caracter铆stica de capacidad de resoluci贸n est谩 indicada por el bit 47, que identifica una direcci贸n no resoluble
(valor 0) o una direcci贸n resoluble (valor 1), como se ve a continuaci贸n.
Algunos ejemplos de paquetes de datos publicitarios (PDU) de Bluetooth de baja energ铆a
Los paquetes publicitarios pueden tener diferentes tipos de PDU, dependiendo del objetivo de la interacci贸n del dispositivo ( transmisi贸n, publicidad, conexi贸n, escaneo activo o pasivo ). La interacci贸n de Bluetooth Low Energy depende de su estado operativo, pero lo discutiremos m谩s adelante, en la siguiente secci贸n. Volviendo a las PDU, hasta Bluetooth 4.2 solo hab铆a siete PDU, mientras que con Bluetooth 5.0 – y superior – se han agregado PDU adicionales ( PDU extendidas ), gracias a la introducci贸n del concepto de canales de publicidad secundaria. Analizar茅 solo las PDU primarias, ya que son las PDU clave para el funcionamiento de BLE.
PDU ADV_IND
La PDU ADV_IND se utiliza para eventos de publicidad indirecta que incluyen la posibilidad de conexi贸n y escaneo por parte de todos los dem谩s nodos que escuchan. Est谩 compuesto por el campo AdvA, que especifica la direcci贸n del Anunciante y si es aleatorio o p煤blico. Luego, hay un campo AdvData, que contiene los datos anunciados. A continuaci贸n, puede ver la estructura de la PDU.
Los eventos Publicitarios de esta PDU pueden finalizar de tres formas:
1. cuando un dispositivo de escucha responde con un tipo de PDU CONNECT_IND, en caso de que sea un nodo inicializador, estableciendo as铆 una conexi贸n con el nodo Anunciante ;
2. cuando un dispositivo de escucha responde con un tipo de PDU SCAN_REQ, en el caso de que sea un esc谩ner activo. Despu茅s de eso, el dispositivo del anunciante enviar谩 una respuesta de la PDU SCAN_RSP al esc谩ner, lo que conducir谩 al final del evento.
3. si alg煤n dispositivo responde al anunciante, el evento finaliza despu茅s de que la PDU se haya transmitido en los tres canales de publicidad.
PDU ADV_DIRECT_IND
El tipo de PDU ADV_DIRECT_IND se utiliza para eventos publicitarios con el prop贸sito de establecer una conexi贸n con un dispositivo cuya direcci贸n ya se conoce de antemano. El campo AdvA especifica la direcci贸n del anunciante, mientras que TargetA contiene la direcci贸n del dispositivo de destino.
Los eventos Publicitarios de esta PDU finalizan de dos formas:
1. cuando el dispositivo de destino, que est谩 escuchando, responde con un tipo de PDU CONNECT_IND, pasando por tanto al estado de conexi贸n;
2. si el Anunciante no recibe ninguna respuesta de otros dispositivos, el nodo contin煤a enviando la PDU en los canales restantes, hasta que se alcanza el tiempo m谩ximo.
PDU ADV_SCAN_IND
El tipo de PDU ADV_SCAN_IND es utilizado por los eventos de publicidad para indicar a todos los dispositivos que est谩n en el estado de exploraci贸n, que no permiten ninguna conexi贸n. El campo AdvA especifica la direcci贸n del anunciante, mientras que AdvData contiene cualquier informaci贸n o dato que el anunciante quiera transmitir a los esc谩neres.
Los eventos Publicitarios de esta PDU finalizan de dos formas:
1- cuando los dispositivos en estado esc谩ner activos responden con un tipo de PDU SCAN_REQ. Luego, el anunciante responder谩 con un tipo de PDU SCAN_RSP. Posteriormente, la PDU ADV_SCAN_IND tambi茅n se env铆a a los otros canales publicitarios.
2- cuando nadie responde en los tres canales publicitarios principales, el evento finaliza.
PDU ADV_NONCONN_IND
El tipo de PDU ADV_NONCONN_IND se utiliza para eventos Publicitarios que no permiten ni la conexi贸n ni el escaneo activo por otros nodos, ya que durante este tipo de eventos el anunciante no est谩 a la escucha en los canales. El campo AdvA especifica la direcci贸n del anunciante, mientras que AdvData contiene cualquier informaci贸n o dato que el anunciante quiera transmitir a los esc谩neres.
Es un tipo de PDU que se utiliza para realizar transmisiones no directas. Los eventos caracterizados por esta PDU finalizan despu茅s de enviar el paquete en los tres canales de publicidad.
Otras PDU y PDU extendida
Entre los otros tipos de PDU, es necesario mencionar las PDU SCAN_REQ y SCAN_RSP utilizadas en los eventos de exploraci贸n. Por lo tanto, tambi茅n existe una PDU CONNECT_IND, que se utiliza para inicializar una transferencia de datos a trav茅s de los canales de datos, y establecer la conexi贸n real entre dos dispositivos. Finalmente, hay una PDU ADV_EXT_IND adicional, que se ha introducido con Bluetooth 5.0 y se utiliza para cambiar de los canales de publicidad primarios (37, 38 y 39) a los secundarios, es decir, el canal de datos, normalmente destinado solo para el intercambio de datos en Bluetooth 4.2. En los canales de publicidad secundaria tambi茅n hay PDU adicionales, todas caracterizadas por el prefijo AUX_ que, sin embargo, no se estudiara en este art铆culo.
La eficiencia energ茅tica de Bluetooth Low Energy para las aplicaciones de Internet de las cosas
La clave de la eficiencia BLE es sin duda el menor n煤mero de canales (40 frente a los 79 definidos para el Bluetooth Classic), de los cuales solo tres, los de advertising, se utilizan realmente para publicidad, escaneo y establecimiento de conexi贸n entre dos nodos. Esto, combinado con paquetes m谩s peque帽os y una potencia de transmisi贸n bastante baja, permite reducir el tiempo en el que la radio y todos los dem谩s equipos de transmisi贸n permanecen activos durante la transmisi贸n o recepci贸n, lo que permite m谩s tiempo en estado de espera y, por lo tanto, un consumo de energ铆a reducido. Todos estos elementos juntos hacen que Bluetooth Low Energy sea adecuado para diferentes aplicaciones de Internet de las cosas donde muchos nodos de detecci贸n alimentados por bater铆a de IoT necesitan comunicar sus datos a una puerta de enlace central mediante un protocolo de comunicaci贸n inal谩mbrica. Como ya se dijo, BLE son los protocolos m谩s utilizados para wearables, dispositivos inteligentes y sensores ambientales econ贸micos alimentados por bater铆as, que comunican sus datos peri贸dicamente a un maestro central que act煤a como puerta de enlace, asegurando una buena duraci贸n de la bater铆a en un formato diminuto. Sin embargo, hay muchas otras caracter铆sticas que hacen que BLE Internet of Things sea amigable y eficiente. Ve谩moslos en los siguientes p谩rrafos.
Perfil de atributo gen茅rico (GATT): servicios y caracter铆sticas para las comunicaciones de IoT
Otra caracter铆stica clave de Bluetooth Low Energy que se ha tomado y mejorado parcialmente de la variante Classic para alcanzar una utilizaci贸n m谩s eficiente de los recursos, es el Generic Attribute Profile (GATT), que establece c贸mo intercambiar perfiles y datos sobre una conexi贸n BLE establecida entre un perif茅rico (servidor GATT) y un dispositivo central (cliente GATT). GATT utiliza un protocolo de datos gen茅rico llamado Atribute Protocol (ATT), que se utiliza para almacenar servicios, caracter铆sticas y datos relacionados en una tabla de b煤squeda utilizando ID (handler) de 16 bits para cada entrada. GATT solo puede manejar una conexi贸n a la vez, por lo que cuando un perif茅rico se conecta a un dispositivo central, este 煤ltimo dejar谩 de publicitarse inmediatamente, de modo que otros dispositivos ya no podr谩n verlo o conectarse a 茅l hasta que se interrumpa la conexi贸n existente. Un comportamiento que se debe tener en cuenta cuando se trata de redes de sensores inal谩mbricos con m煤ltiples dispositivos perif茅ricos que deben conectarse e intercambiar datos con un dispositivo central, escenario recurrente en muchas aplicaciones de Internet de las Cosas que involucran el uso de Bluetooth Low Energy. El procedimiento de conexi贸n entre el servidor GATT y el cliente GATT se muestra a continuaci贸n y, cuando hay una gran cantidad de dispositivos, se debe implementar un sistema inteligente de acceso m煤ltiple, con el fin de optimizar el acceso al servidor GATT.
Una vez que un cliente est谩 conectado a un servidor, Perfil, Servicios y Caracter铆sticas gestionan el proceso de intercambio de datos entre los dos nodos. Un perfil es simplemente una colecci贸n predefinida de servicios que ha sido definida por Bluetooth SIG. Un perfil puede combinar varios servicios, lo que depende de la naturaleza del dispositivo. En cambio, un servicio se utiliza para separar los datos en una o m谩s caracter铆sticas. Cada servicio se distingue de otros servicios por un ID num茅rico 煤nico llamado UUID, que puede ser de 16 bits o de 128 bits. Como los perfiles, tambi茅n los UUID de Servicios est谩n definidos por Bluetooth Developer Portal, sin embargo, los usuarios pueden crear f谩cilmente un servicio personalizado para un prop贸sito espec铆fico. Los 煤ltimos elementos de GATT son las Caracter铆sticas, que encapsulan un 煤nico punto de datos que podr铆a ser una matriz de datos, dado su tama帽o m谩ximo de 512 bytes. Como Servicios, tambi茅n la caracter铆stica se identifican a trav茅s de un UUID de 16 o 128 bits. La estructura completa del GATT se puede ver en la siguiente imagen. Entonces, cada vez que un Cliente GATT se conecta a un Servidor GATT, escribe o lee datos sobre una o m谩s Caracter铆sticas. Por lo tanto, las caracter铆sticas son un punto clave de cualquier conexi贸n BLE y una de las posibles formas de utilizar BLE para aplicaciones de Internet de las cosas donde muchos nodos de detecci贸n BLE tienen que comunicar sus datos a una puerta de enlace central.
Un n煤mero limitado y bien definido de estados activos.
Bluetooth Low Energy debe su eficiencia a un estado bien definido, que define el comportamiento de un dispositivo BLE durante muchas operaciones. De hecho, hay cinco estados de Capa de enlace: Advertising,(Publicidad), En espera, Iniciando, Escaneo y Conexi贸n. A continuaci贸n, se puede ver un diagrama de flujo de cada transacci贸n posible de estado.
En el estado de espera, que es el estado en el que cualquier dispositivo BLE pasa la mayor parte del tiempo, la radio Bluetooth est谩 pr谩cticamente apagada. Cuando se encuentra en este estado, el nodo no establece ninguna conexi贸n, porque no transmite ning煤n paquete y ni siquiera los escucha. Un dispositivo en espera puede cambiar a uno de los tres estados activos como resultado de un comando recibido de la interfaz de controlador de host (HCI). En el estado de Conexi贸n, los canales de datos se utilizan para el intercambio efectivo de paquetes de datos entre el maestro y el esclavo. Esta fase siempre est谩 precedida por un evento de Advertising o el estado de Iniciaci贸n, necesario para el establecimiento de la conexi贸n entre dos dispositivos. Despu茅s de un comando recibido de la interfaz de controlador de host (HCI), el estado de la conexi贸n puede volver al estado de espera.
El estado de Advertising es el estado fundamental de Bluetooth Low Energy, ya que conduce al establecimiento de una conexi贸n, al descubrimiento de nuevos dispositivos cercanos y otras operaciones. Cuando un nodo est谩 en estado de publicidad, durante un cierto intervalo de tiempo, definido como un evento de publicidad, el dispositivo transmite paquetes de publicidad Bluetooth en los tres canales dedicados. El tiempo de transmisi贸n y escucha de cada paquete debe ser menor o igual a 10 milisegundos para cada canal de publicidad. Cada evento publicitario, por tanto, tiene una duraci贸n variable pero debe ser inferior a 30 milisegundos. El tiempo entre dos eventos publicitarios se puede definir como advEvent, y corresponde a la suma de los intervalos de tiempo advInterval y advDelay. El advInterval identifica un m煤ltiplo de 0,625 milisegundos y va desde un m铆nimo de 20 milisegundos hasta un m谩ximo de 10.485 segundos, mientras que advDelay identifica un valor aleatorio entre 0 y 10 milisegundos generado para cada evento publicitario. El advDelay se ha introducido para minimizar el riesgo de colisi贸n de paquetes de otros dispositivos cercanos.
El estado de Escaneo se utiliza para detectar dispositivos publicitarios cercanos con el fin de obtener m谩s informaci贸n sobre ellos sin establecer una conexi贸n real. Hay dos tipos de escaneo: escaneo pasivo y escaneo activo.
- Escaneo pasivo: cuando un nodo de Bluetooth Low Energy est谩 en escaneo pasivo, no transmite ning煤n paquete en los canales de publicidad, pero escucha los paquetes de publicidad entrantes durante una determinada ventana de tiempo, llamada scanWindow. El proceso de escaneo se puede repetir despu茅s de un cierto intervalo de tiempo, definido por el intervalo de escaneo, con una duraci贸n igual o menor que la ventana de escaneo.
- Escaneo Activo: a diferencia del Escaneo Pasivo, durante un Escaneo Activo algunos paquetes se env铆an a los nodos de Publicidad que se transmiten con ADV_IND o ADV_SCAN_IND en las PDUs (Packet Data Units), para solicitar informaci贸n adicional. Despu茅s de recibir una de estas PDU, el dispositivo de esc谩ner puede transmitir las PDU de tipo SCAN_REQ al anunciante para obtener m谩s informaci贸n. Para minimizar el riesgo de colisi贸n,
el esc谩ner implementa un sistema de retroceso (backoff), caracterizado por las variables backoffCoun y upperLimit, con el objetivo de reducir el n煤mero de SCAN_REQs transmitidos en caso de no haber respuesta. Despu茅s de enviar la solicitud, el esc谩ner escucha en los canales publicitarios una PDU SCAN_RSP : si no se recibe, el mecanismo de retroceso gestiona la posible retransmisi贸n y el tiempo de espera. A continuaci贸n se muestra un ejemplo de escaneo activo.
Finalmente, est谩 el estado de iniciaci贸n, donde el dispositivo sigue escuchando en los canales de publicidad durante el intervalo de tiempo definido por la variable scanWindow. La operaci贸n de escucha se repite despu茅s de un cierto intervalo de tiempo, definido por la variable scanInterval. Por lo tanto, el estado de inicializaci贸n es muy similar a un escaneo pasivo, con la diferencia de que cuando el dispositivo recibe un paquete con una PDU tipo ADV_IND o ADV_DIRECT_IND, puede responder, (si la direcci贸n del anunciante est谩 en la lista blanca), con una PDU tipo CONNECT_IND, lo que hace que el nodo cambie al estado de conexi贸n y finalice el evento de publicidad, como se muestra en el siguiente ejemplo.
Redes de malla inal谩mbrica para alcanzar un rango operativo m谩s alto
El mayor inconveniente de la tecnolog铆a BLE es su limitado rango operativo, que, en un entorno real con paredes, obst谩culos y redes wifi de 2,4 GHz interferentes, apenas alcanza un rango operativo de dos a diez metros. Un buen rango para peque帽as redes de sensores inal谩mbricos, como en un piso peque帽o o en un invernadero, pero muy limitado para aplicaciones de IoT dentro de casas y edificios de tama帽o mediano. Dependiendo de las aplicaciones, existen dos soluciones:
- la m谩s simple es colocar m谩s dispositivos alimentados por la red (tambi茅n conocidos como servidores BLE o puertas de enlace ) dentro del edificio para alcanzar una cobertura completa, como si estuviera trabajando con puntos de acceso Wi-Fi y quisiera cubrir un edificio completo usando muchos puntos de acceso colocados en los lugares correctos. Es una soluci贸n muy simple y efectiva que se adapta bien a alg煤n tipo de aplicaciones, donde, por ejemplo, tiene una buena cantidad de nodos de detecci贸n BLE alimentados por bater铆a y la posibilidad (tanto econ贸mica como en t茅rminos de configuraci贸n de espacio / red) para colocar m谩s pasarelas. El principal inconveniente es un mayor costo de implementaci贸n para alcanzar una cobertura perfecta, porque, le guste o no, siempre habr谩 uno o m谩s nodos de detecci贸n colocados en una esquina o cerca de los l铆mites de su red, lo que implica una ubicaci贸n meticulosa de las puertas de enlace;
- la soluci贸n compleja pero m谩s barata es implementar una red de malla inal谩mbrica BLE, permitiendo as铆 que cualquier nodo sensor llegue a la puerta de enlace central de una manera inteligente y eficiente. Wireless Mesh Network es una topolog铆a de red cooperativa que consta de varios nodos inteligentes que act煤an como receptor, transmisor y reenviador de paquetes hacia el nodo receptor, permitiendo conectar entre ellos dispositivos a los que no se puede acceder de forma directa sino solo a trav茅s de comunicaciones multisalto. Con el est谩ndar Bluetooth 4.1, se ha introducido la posibilidad de hacer que un dispositivo act煤e tanto como Maestro como Esclavo, permitiendo as铆 que un posible nodo Bluetooth act煤e como intermediario en una comunicaci贸n entre otros dos dispositivos. Esto podr铆a ampliar significativamente el rango operativo de las redes BLE, permitiendo cubrir todo un edificio. Sin embargo, esta soluci贸n es un poco compleja de implementar incluso cuando Bluetooth 5.0 ha introducido algunas funciones nuevas y 煤tiles dedicadas a las redes inal谩mbricas en malla. Adem谩s, los nodos que act煤an como reenviadores de paquetes tienen un mayor consumo de energ铆a, ya que tienen que dedicar m谩s tiempo a escuchar los paquetes entrantes, lo que limita la vida 煤til de la bater铆a de los dispositivos restringidos.
驴C贸mo podemos usarlo para aplicaciones de Internet de las cosas?
Bueno, ahora que aprendi贸 c贸mo act煤a Bluetooth Low Energy, podemos ver qu茅 tan eficazmente lo usamos para nuestras redes de sensores inal谩mbricos o, m谩s en general, para diferentes tipos de aplicaciones en Internet de las cosas. Como deber铆a haber entendido en la secci贸n anterior, hay dos formas posibles de usarlo para la comunicaci贸n de datos entre un nodo maestro (p. Ej., Una puerta de enlace BLE a Internet) y un dispositivo esclavo (p. Ej., Un nodo sensor alimentado por bater铆a):
- Implementaci贸n de un servidor GATT y uso de Servicios y Caracter铆sticas para transferir datos en ambas direcciones entre dos dispositivos (cliente y servidor);
- Uso del estado de publicidad y escaneo para la comunicaci贸n unidireccional entre uno o m谩s nodos.
Hay muchas diferencias entre estas dos posibles formas. El primero necesita establecer una conexi贸n entre los dos dispositivos, por lo que requiere algo de tiempo, porque el servidor GATT, que tiene el rol de Maestro y define uno o m谩s Servicios con una o m谩s Caracter铆sticas, tiene que publicitarse para poder ser encontrado por el nodo esclavo, que act煤a como cliente. Una vez que se logra la conexi贸n, puede proceder la transferencia de datos reales en los canales de datos, lo que permite al cliente (el nodo esclavo) transferir una buena cantidad de datos en ambas direcciones simplemente escribiendo o leyendo la caracter铆stica deseada. Sin embargo, existen dos grandes inconvenientes: primero, como se dijo antes, el proceso de publicidad, escaneo, iniciaci贸n y conexi贸n toma algo de tiempo (m谩s de lo que podr铆a pensar), especialmente en dispositivos de baja potencia que tienen capacidades de procesamiento limitadas y, como expliqu茅 antes, una vez que un dispositivo est谩 conectado a un servidor GATT (que, en una aplicaci贸n de IoT, podr铆a ser nuestra puerta de enlace) otros nodos de detecci贸n cercanos no pueden encontrarlo (porque deja de anunciarse a s铆 mismo), lo que desperdicia energ铆a para seguir busc谩ndolo. Esto nos lleva al segundo inconveniente: los datos se pueden intercambiar solo con un dispositivo esclavo a la vez, lo que podr铆a ser un problema para las redes BLE densamente pobladas, dados los tiempos de conexi贸n y desconexi贸n.
Sin embargo, por lo general, los dispositivos de detecci贸n alimentados por bater铆a en una red de sensores inal谩mbricos tienen una menor cantidad de datos para transmitir de manera monodireccional hacia la puerta de enlace de la red BLE. Aqu铆 viene la segunda v铆a de comunicaci贸n, que encaja muy bien para este tipo de aplicaciones, ya que la carga 煤til limitada de los paquetes Publicitarios ( 27 bytes 煤tiles ) es suficiente para transmitir un identificador ID (si la direcci贸n BLE no es suficiente) y muchos datos de sensores. Puede jugar con las variables correctas para reducir y optimizar el tama帽o de la carga 煤til. En este caso, la puerta de enlace act煤a como un esc谩ner pasivo, que escucha los paquetes de publicidad entrantes de muchos nodos de detecci贸n, recuperando su carga 煤til. De este modo, Tambi茅n es posible recopilar datos casi simult谩neamente de diferentes esclavos, ya que se encuentran disponibles tres canales de publicidad, lo que hace que esta soluci贸n sea adecuada para redes BLE de alta densidad. Por supuesto, el mayor inconveniente es el tipo de comunicaci贸n mono-direccional y la menor seguridad (casi nula) de la comunicaci贸n, ya que por defecto no existe cifrado en la carga 煤til de los paquetes publicitarios. El 煤ltimo problema podr铆a evitarse parcialmente aplicando un cifrado propio a la carga 煤til, mientras que el primero requiere un intercambio de roles entre el maestro y el esclavo para superarlo.
Bueno, estas son las cosas que debe saber con respecto a Bluetooth Low Energy. Por supuesto, quedan muchas m谩s cosas, pero creo que este art铆culo es un buen punto de partida para los principiantes de BLE Internet of Things. Saludos y gracias por leer.