Bluetooth Low Energy

Introduction

La technologie BLE a été introduite en 2010 à la fois comme un complément à la technologie Bluetooth classique et comme une nouvelle technologie consommant très peu d’énergie. Bien que BLE fasse partie du standard Bluetooth et emprunte un certain nombre de concepts de son parent, la technologie est suffisamment différente pour être considérée comme une nouvelle technologie.

La technologie Bluetooth classique a été développée dans le but de permettre un échange de données sans fil entre ordinateurs et téléphones. La technologie a gagné en popularité grâce au succès des dispositifs audio sans fil. Avec le temps, la technologie s’est développée essentiellement dans le but de fournir un débit supérieur, afin de mieux répondre aux besoins. La technologie Bluetooth classique a ainsi évolué d’un début maximum de 1 Mbps (Basic Rate, Bluetooth 1.0) à un débit de 3 Mbps (Enhanced Data Rate, Bluetooth 2.0). Avec Bluetooth 3.0, la technologie a encore évolué pour supporter des débits de plusieurs dizaines de Mbps, en adoptant la couche physique IEEE 802.11. Cette évolution a été semblable pour d’autres technologies comme le Wi-Fi, Ethernet ou les modems analogiques.

Dans tous ces cas, ces évolutions n’ont pas permis l’émergence de dispositifs consommant moins d’énergie et c’est la raison pour laquelle BLE a vu le jour. Le développement du standard BLE a été piloté dès le début par le besoin de fournir un dispositif consommant le moins possible d’énergie. Dans le même temps, il était important de développer également une technologie à bas coût, afin de permettre de s’établir dans les marchés où le nombre d’appareils est très important comme le marché des smartphones.

Afin de pouvoir développer une technologie à basse consommation et bas coût, les concepteurs de la technologie ont tenu compte des points suivants :

La bande de fréquences utilisée devait être sans licence afin de minimiser les coûts. L’utilisation d’une bande de fréquences disponible dans le monde entier est un autre facteur d’économie. Le choix de la bande 2.4 GHz s’imposait donc, bien que cette bande soit très utilisée et ne possède pas les meilleures caractéristiques pour un dispositif à faible consommation (absorption, coexistence avec d’autres technologies).
Les coûts de licence de la technologie devaient être aussi faibles que possible. Cette approche a toujours été adoptée par le Bluetooth SIG, qui était donc un candidat idéal pour mettre en place le standard BLE sur la base de la technologie Wibree développée en 2006 par Nokia.
Réduire la consommation d’énergie contribue à réduire les coûts puisque les besoins en capacité de batterie sont limités ainsi que les besoins de changement de batterie. Pour cette raison, le choix a été fait dès la conception de développer une technologie pouvant fonctionner avec des batteries boutons.

Le positionnement de la technologie BLE en termes de débit est illustré dans l’image ci-dessous :

Pour lire correctement ce diagramme, il faut bien comprendre que la technologie BLE peut atteindre des débits supérieurs aux 50 kbps illustrés, mais que des débits supérieurs rendent la technologie plus énergivore et donc moins basse consommation. Dans le cas où des débits plus élevés sont mis en œuvre, l’autonomie des dispositifs BLE sera réduite en proportion.

Les topologies du réseau BLE

Un dispositif BLE peut communiquer avec d’autres dispositifs BLE selon deux mécanismes différents : par broadcasting ou par connexion. Chaque mécanisme présente ces propres avantages et inconvénients.

Lorsque le mécanisme du broadcasting est utilisé, un broadcaster peut envoyer des données à tout dispositif BLE qui est à portée et qui écoute (scanne) dans le but de recevoir des données. Les rôles de broadcaster et d’observer sont définis par le standard BLE pour cette topologie :

Le broadcaster envoie, à intervalle régulier, des paquets d’advertising destinés à tout appareil observant.
L’observer scanne régulièrement les fréquences dédiées à l’advertising afin de recevoir les paquets provenant d’un broadcaster.

Ce mécanisme est illustré ¹ ci-dessous :

Cette topologie est la seule topologie permettant à un dispositif de transmettre des données à plus d’un appareil simultanément. Par contre, ce mécanisme permet uniquement un transfert de données unidirectionnel, du broadcaster vers l’observer. La quantité de données pouvant être transmise est également limitée par la taille des paquets d’advertising, qui contiennent un payload de 31 octets. Cette quantité peut être doublée par l’utilisation du mécanisme de Scan Request / Scan Response, mais le payload maximal reste tout de même limité à 62 octets.

Afin de transmettre des données dans les deux directions ou de transmettre de plus grandes quantités de données, BLE permet l’utilisation d’une topologie de connexion. Dans ce mode, deux appareils établissent une connexion et peuvent ensuite échanger des données à intervalle régulier. L’échange de données est ainsi privé et la taille des messages n’est plus limitée. Il est important de comprendre que, si la connexion est sécurisée, aucun autre dispositif que les deux dispositifs faisant partie de la connexion ne peut avoir accès aux données échangées. Cela n’est bien sûr pas le cas pour une topologie de Broadcasting.

La topologie par connexion est illustrée dans l’image ¹ ci-dessous :

Le mécanisme de connexion implique deux rôles différents :

Le rôle central (master) : le dispositif jouant ce rôle scanne les canaux d’advertising afin de détecter des paquets d’un dispositif peripheral autorisant la connexion. Le dispositif établit une connexion et gère la connexion établie (paramétrage, initiation des échanges de données).
Le rôle peripheral (slave) : le dispositif envoie des paquets d’advertising à intervalle régulier et accepte les demandes de connexion provenant de dispositifs central. Lorsqu’une connexion est établie, le dispositif Peripheral respecte les paramètres de temps fixés par le central et échange régulièrement des données avec celui-ci.

Afin d’amorcer une connexion, un dispositif central peut choisir un paquet d’advertising provenant d’un dispositif peripheral et, en respectant certaines contraintes temporelles, envoyer une requête de connexion à celui-ci. Une connexion est établie de manière exclusive entre ces deux dispositifs et, lorsque la connexion est établie, le dispositif peripheral cesse d’envoyer des paquets d’advertising. Lors de la connexion, les échanges de données peuvent être bidirectionnels.

Au-delà des points mentionnés ci-dessus, un avantage important de l’échange de données par connexion est que dans ce cas, les données échangées sont organisées de façon très structurée dans un concept d’architecture client-serveur. Cet échange de données est géré par la couche de protocole GATT (Generic Attribute Profile) et permet un échange de données avec un contrôle précis des données échangées. En d’autres termes, grâce au GATT, deux dispositifs peuvent optimiser l’échange de données et offrir un contrôle précis de celles-ci.

Il est aussi intéressant de noter que dans le contexte BLE, une connexion n’est rien d’autre qu’un échange périodique de données entre deux dispositifs à intervalle régulier. Chaque échange a lieu à intervalle régulier dans ce qui est nommé un connection event.

Dès la norme BLE 4.1, toute restriction dans les combinaisons de rôles que peut jouer un dispositif ont été supprimées. Les configurations suivantes sont donc possibles :

Un dispositif peut être simultanément un central et un peripheral.
Un dispositif central peut être connecté à plusieurs dispositifs peripheral.
Un dispositif peripheral peut être connecté à plusieurs dispositifs central.

Ces diverses possibilités sont illustrées dans l’image ¹ ci-dessous :

La pile du protocole BLE

La technologie BLE a bien sûr été conçue comme un protocole de communication en couches, comme illustré dans la figure ¹ ci-dessous :

Comme on peut le voir dans cette figure, la pile est divisée en trois parties bien distinctes :

La couche Application est la couche dans laquelle chaque application BLE est écrite. Aucune architecture particulière n’est fixée par le standard BLE pour cette couche, qui est distincte d’un fabricant à l’autre.
La couche Host inclut parmi d’autres les couches GAP et GATT, qui sont les couches que tout développeur BLE doit connaître en détail. Cette couche contient également la partie Host de la couche HCI (Host Controller Interface) qui est la couche d’interface avec le Controller.
La couche Controller contient bien sûr la couche de liaison et la couche physique, mais aussi la partie Controller de la couche HCI.

La couche physique

La description détaillée du fonctionnement de la couche physique est hors du cadre de ce cours. Nous donnons ici quelques informations permettant de comprendre certaines caractéristiques de la technologie.

La bande de fréquence 2.4 GHz adoptée par le Bluetooth SIG est également utilisée par de nombreuses autres technologies de communication, dont le Wi-Fi (IEEE 802.11) et les technologies IEEE 802.15.4. De plus, beaucoup de bruit est également émis dans cette bande de fréquences par nombres d’appareils comme les fours à micro-ondes, des micros sans-fils ou certains radars. Pour cette raison, BLE a adopté le principe du Adaptive Frequency Hopping, qui permet de détecter rapidement les sources d’interférences et d’adapter les canaux utilisés afin d’éviter ces interférences. En combinaison avec une stratégie permettant de minimiser l’influence des pertes de paquets, ce choix fait de BLE une technologie pouvant opérer de manière robuste dans une telle bande de fréquence.

La figure ci-dessous ² illustre les canaux utilisés par BLE. 40 canaux sont utilisés de 2.4 GHz à 2.4835 GHz, dont 37 sont utilisés pour les connexions et 3 pour l’advertising. La figure illustre également le mécanisme du Adaptive Frequency Hopping. À l’aide de ce mécanisme, les canaux qui interfèrent avec d’autres appareils (ici un réseau Wi-Fi) sont automatiquement déactivés. Selon le mécanisme, le prochain événement de connexion devrait utiliser le canal 16. Or celui-ci étant identifié comme un canal perturbé, le canal utilisé est le canal 24.

La couche de liaison

Comme dans d’autres technologies de communication réalisées en couches, la couche de liaison est la couche qui interface directement avec la couche physique. Elle est souvent réalisée en combinant hardware dédié et software, afin de pouvoir respecter les contraintes temporelles de la spécification BLE. La couche de liaison fait partie de la partie Controller et est isolée du reste des couches par le HCI.

La couche de liaison définit les rôles suivants :

L’Advertiser est un dispositif envoyant des paquets d’advertising.
Le Scanner est un dispositif scannant les paquets d’advertising.
Le Master est un dispositif amorçant et contrôlant une connexion.
Le Slave est un dispositif acceptant une requête de connexion et suivant les consignes du Master au cours de la connexion.

Ces rôles sont logiquement regroupés en deux paires : Advertiser/Slave et Scanner/Master. Dans beaucoup de scénarios, un périphérique basse consommation joue les rôles Advertiser/Slave et un smartphone joue les rôles Scanner/Master. La couche BLE est conçue de façon asymétrique entre ces deux paires de rôles. Jouer le rôle de Scanner/Master requiert plus de ressources. Cette asymétrie est couramment présente dans les protocoles, comme dans le protocole USB où le rôle d’USB host requiert plus de ressources que celui d’USB device. Cette asymétrie permet de développer des périphériques à l’aide de microcontrôleurs peu coûteux, alors que les rôles nécessitant plus de ressources sont réalisés sur des smartphones ou des ordinateurs.

Les adresses BLE

Les dispositifs BLE possèdent une adresse comme identifiant, similaire à l’adresse Ethernet Media Access Control (MAC). Une adresse BLE est un nombre de 48 bits, qui peut être :

une adresse publique, qui est programmée à la fabrication et qui doit être annoncée auprès de l’autorité compétente (IEEE Registration Authority).
une adresse aléatoire, qui peut être préprogrammée ou générée dynamiquement. Ce type d’adresse est très souvent utilisé.

Le format des paquets BLE

BLE réalise un seul format de paquet dans la couche de liaison, pour deux types de paquets différents : les paquets d’advertising et les paquets data. Le type advertising est bien sûr utilisé lorsque la couche de liaison est dans le mode advertising ou scanning, alors que le type data est utilisé en mode connecté.

Le format du paquet BLE est donné dans la figure ³ ci-dessous :

Il est important de noter qu’à partir de BLE 5.0, le standard BLE permet d’utiliser une couche physique avec encodage. Dans ce cas, le format du paquet BLE est différent.

Avec le standard BLE 4.2, la taille du PDU a également été étendue à 257 octets. Dès la version 4.2, le format ⁴ du paquet est donc :

Format du paquet BLE (dès la version 4.2)

Pour la couche physique sans encodage, ce format s’applique aux deux types de paquets. Le préambule (preamble) est utilisé pour la synchronisation radio sur le récepteur et il est toujours le même pour les paquets d’advertising. Le champ contenant l’access address est également fixe pour les paquets d’advertising. Le PDU (Protocol Data Unit) est différent pour les deux types de paquets.

Pour les paquets d’advertising, le PDU a la forme générale ⁴ :

avec l’entête ³ pour la version 4.0 et 4.1 (taille du PDU limité à 39 octets et taille du payload limité à 31 octets) :

et l’entête ⁴ pour les versions 4.2 et suivantes :

Entête du PDU (paquet d'advertising dès la version 4.2)

Comme vous pouvez le remarquez, dans la version 4.0, le champ décrivant la taille du payload occupait 6 bits (suffisant pour une taille de moins de 31 octets) avec deux bits RFU. RFU signifiant Reserved for Future Use, ces deux bits ont été alloués dès la version 4.2 pour représenter une taille sur 8 bits permettant de représenter une taille de moins de 255 octets. L’allocation des bits RFU permet de réaliser des extensions au standard tout en garantissant la compatibilité backward des dispositifs : un dispositif 4.0 doit continuer à fonctionner correctement avec un dispositif 4.2 et suivant.

Les autres champs de l’entête ont des significations différentes en fonction du type de PDU, que nous n’abordons pas ici. Veuillez noter que dès la version 5.0, un autre bit réservé de l’entête a été alloué (ChSel).

Comme on peut le voir dans la description de l’entête du PDU, il existe plusieurs types de PDU, qui se différencient selon trois propriétés :

Connectability : indique au scanner si l’advertiser accepte les connexions. Un advertiser peut donc être connectable ou non-connectable.
Scannability : indique au scanner si l’advertiser accepte les scan requests. Un advertiser peut donc être scannable ou non-scannable.
Directability : indique si les paquets d’advertising sont dédiés à un scanner spécifique ou non. Un paquet d’advertising peut donc être directed ou undirected.

Les différentes combinaisons des propriétés ci-dessus permettent de créer des paquets d’advertising de différents types, comme illustré dans la table ci-dessous

Type d’advertising	Connectability	Scannability	Directability
ADV_IND	x	x
ADV_DIRECT_IND	x		x
ADV_NONCONN_IND
ADV_SCAN_IND		x

Pour les paquets de type ADV_IND, ADV_NONCONN_IND et ADV_SCAN_IND, le format ³ du payload est :

Format du payload pour l'advertising non direct

Dans ce format, AdvA est l’adresse publique ou aléatoire de l’appareil émettant le paquet d’advertising et AdvData constitue la donnée d’advertising. C’est la donnée qu’une application peut configurer et modifier, comme le réalisera l’application broadcaster du TP 03.

Le format ³ du payload pour les paquets de type ADV_DIRECT_IND est différent des autres paquets :

Format du payload pour l'advertising direct

Dans ce format, AdvA est identique aux autres types de paquets, mais la donnée d’advertising InitA contient l’adresse du dispositif auquel ce paquet d’advertising est adressé. Ce type de paquets d’advertising est utilisé afin de permettre des reconnexions rapides lorsque qu’une connexion entre deux dispositifs est interrompue.

Le format ³ des données d’advertising AdvData est donné ci-dessous :

Une donnée d’advertising est donc constitué d’une suite de structures de données appelées AD Structure, chaque structure étant composée d’un champ Length (\(1\) octet), d’un AD type (\(n\) octets) et finalement d’un AD Data (\(Length - n\) octets). Les valeurs de AD type possibles sont définies dans un supplément du standard BLE ⁵.

Un exemple ⁵ de donnée d’advertising simple avec deux AD Structure est donné ci-dessous :

Exemple de AdvData avec deux AD Structures

Les AD types que nous utiliserons lors du TP 03 sont les suivants :

Flags : le champ Flags défini par le type 0x01 a une longueur de 0 à n octets. Ce champ permet de décrire certaines caractéristiques du dispositif BLE émettant le paquet avec le minimum d’octets. Très souvent, ce champ a une taille de 1 octet avec la signification des bits selon la table ³ ci-dessous :

Local Name : le champ Local Name contient le nom du dispositif BLE émettant le paquet. Le AD type utilisé pour les noms spécifiés entièrement est 0x09. Il est également possible de spécifier un nom abrégé avec le AD type 0x08.
Service : le champ Service permet au dispositif BLE d’indiquer les services que le dispositif réalise. Il existe plusieurs manières de spécifier ces services. Lorsque le AD type est spécifié avec la valeur 0x03, la liste complète des services décrits avec des UUIDs sur 16 bits est fournie. Si un dispositif réalise un nombre limité de services faisant partie de la liste des services spécifiés par le standard BLE, il est possible avec une telle méthode de spécifier la liste complète des services réalisés par un dispositif. C’est le cas de notre broadcaster qui réaliser le service Environmental Sensing Service.
Service Data : le champ Service Data permet au dispositif d’ajouter des données spécifiques à un service. Le AD type pour ce champ est 0x16. Dans le cas de l’application broadcaster du TP 03, nous utiliserons ce champ afin de transmettre les données des capteurs environnementaux, données associées au service Environmental Sensing Service.

L’ Advertising et le Scanning

Les paquets advertising sont utilisés dans deux scénarios différents. Le premier scénario est celui du broadcaster/observer : dans ce cas, le but est de diffuser des données pour des applications qui ne nécessitent pas l’utilisation d’une connexion. Le deuxième scénario est justement celui de l’établissement d’une connexion entre un master et un slave : les paquets d’advertising sont utilisés dans ce cas dans le but de découvrir les dispositifs slave et de permettre au master d’établir une connexion avec un slave.

Les paquets d’advertising sont toujours envoyés de manière asynchrone. En d’autres termes, le dispositif effectuant un advertising ne sait pas si un scanner est présent ou non. Les paquets sont envoyés à intervalle régulier, intervalle compris entre 20 ms et 10.24 s. En principe, les paquets sont envoyés successivement sur les trois canaux d’advertising. Les mécanismes d’advertising et de scanning sont illustrés dans la figure ¹ ci-dessous.

Comme on peut le constater dans cette figure, lorsque l’on développe une application broadcaster et scanner, il est important de choisir les paramètres advertising interval, scan window et scan interval de façon à optimiser à la fois la consommation et la réactivité du système développé. De manière générale, on peut dire que :

plus la valeur d’advertising interval (comprise entre 20 ms et 10.24 s) est grande, moins la consommation du dispositif broadcaster sera importante. Dans le même temps, plus la valeur d’advertising interval sera grande, plus la valeur de scan interval sur le dispositif observer devra être petite, afin d’assurer une réception des données suffisamment bonne.
plus la valeur de scan interval sera petite et la valeur de scan window grande, meilleures seront les chances que l’observer reçoive un paquet émis par le broadcaster. Dans le même temps, la consommation augmentera.

Il est important de rappeler que le standard BLE a volontairement introduit une asymétrie entre les différents rôles : le rôle de broadcaster doit pouvoir être réalisé en utilisant le moins d’énergie possible, alors qu’il est courant que le rôle d’observer soit réalisé par un dispositif disposant de plus d’énergie (par exemple un smartphone).

Afin de permettre d’échanger une plus grande quantité de données en mode advertising, le standard BLE a mis en place le mécanisme du scanning actif. Avec ce mécanisme, un scanner peut répondre à la réception d’un paquet d’advertising avec une requête de scan. À la réception de cette requête, l’advertiser répondra avec une réponse scan. Il est dénommé souvent par active scanning et est illustré dans le diagramme ¹ ci-dessous :

Ce mécanisme permet ainsi de doubler la quantité de données utiles qu’un advertiser peut diffuser en mode advertising. Il faut noter que ce mécanisme ne permet pas de transférer des données du scanner vers l’advertiser. Ce mécanisme est réalisé à l’aide de deux types de paquets d’advertising supplémentaires : les types SCAN_REQ et SCAN_RSP. Le payload pour ces types n’est pas détaillé ici.

L’ensemble des types de PDU pour les paquets d’advertising tel que spécifié pour la norme BLE 4.0 est illustré ci-dessous ³ :

BLE PDU types — Les différents types PDU (advertising)

Les connexions BLE

Le type PDU CONNECT_REQ est le type utilisé par le scanner lorsque celui-ci veut établir une connexion. Ce type de paquets appartient encore à la famille des paquets d’advertising et le format du paquet est le suivant ³ :

BLE Connection Request PDU — PDU pour un paquet CONNECT_REQ

Le champ LLData contient les informations permettant de configurer la connexion ³ :

BLE LLData — LLData (paquet CONNECT_REQ)

Les informations les plus importantes dans le champ LLData sont :

l’intervalle de connexion, défini comme le temps entre le début de deux événements de connexion consécutifs. Ce temps est compris dans la plage de 7.5 ms à 4 s.
la slave latency, définie comme le nombre d’événements de connexion qu’un slave peut choisir de manquer sans risquer une déconnexion.
le connection supervision timeout, défini comme le temps maximal entre deux réceptions de paquets valides avant qu’une connexion soit considérée comme perdue.
le hop increment, défini comme le nombre utilisé dans la séquence de hopping que le master et le slave suivront pour toute la durée de la connexion.

Le mécanisme de connexion entre un master et un slave est illustré dans la figure ¹ ci-dessous :

BLE Connection Event — Événement de connexion BLE

Les paramètres WinSize et WinOffset du champ LLData sont utilisés pour l’établissement de la connexion selon le scénario temporel illustré ³ ci-dessous :

BLE Connection Establishment — Établissement d'une connexion BLE

En utilisant le mécanisme de connexion entre deux dispositifs, plus l’intervalle de connexion sera petit et plus le débit sera élevé et la latence faible, au prix d’une consommation plus élevée. Dans ce cas, le standard BLE a à nouveau introduit une asymétrie entre les différents rôles : le rôle de slave doit pouvoir être réalisé en utilisant le moins d’énergie possible. Ainsi, la slave latency permet à celui-ci de manquer un certain nombre d’événements de connexion sans pour autant provoquer une déconnexion. L’utilisation de ce mécanisme combinée avec un intervalle de connexion relativement petit permet ainsi un échange de données avec un minimum de latence, tout en minimisant la consommation d’énergie du dispositif slave.

Exercice Bluetooth Low Energy/1

Énoncez les différents types de paquets d’advertising. Expliquez les propriétés de ces paquets et les scénarios pour lesquels ils peuvent être utilisés.

Solution

Les différents types de paquets d’advertising sont donnés dans la figure [BLE PDU types]. Les propriétés des paquets sont affichés dans la table des propriétés affichée ci-dessus. Les scénarios d’utilisation sont :

ADV_IND (ou Connectable undirected advertising) : un périphérique comme un traceur d’activités ou une montre connectée qui veut indiquer sa présence à un smartphone, afin que celui-ci puisse établir une connexion.
ADV_DIRECT_IND (ou Connectable directed advertising) : un périphérique dont la connexion avec un central vient d’être perdue et qui veut permettre à celui-ci de rétablir rapidement la connexion.
ADV_NONCONN_IND (ou Non-connectable undirected advertising) : un broadcaster qui veut diffuser des informations à tous les observers qui sont à portée.
ADV_SCAN_IND (ou Scannable undirected advertising) : un broadcaster qui peut ainsi diffuser le double de données utiles vers les observers.
SCAN_REQ : envoyé par un observer ou un central qui souhaite obtenir un paquet SCAN_RSP du broadcaster/périphérique qui a émis un paquet de type ADV_SCAN_IND/ADV_IND.
SCAN_RSP : envoyé par un broadcaster/périphérique qui avait émis au préalable une paquet de type ADV_SCAN_IND/_ADV_IND, en réponse à un paquet _SCAN_REQ reçu.
CONNECT_REQ : envoyé par un central qui a reçu un paquet d’advertising ADV_IND ou ADV_DIRECT_IND afin d’établir une connexion avec celui-ci.