Advertising Data dans BLE : définition, structure et types de données
Advertising Data sont des données structurées qu'un périphérique BLE transmet dans des paquets publicitaires pour s'identifier et identifier ses services. La Bluetooth Core Specification 5.4 (2023) définit le format AD Structure : chaque élément contient une longueur (1 octet), un type (1 octet) et une valeur (jusqu'à 29 octets). La spécification décrit plus de 30 types AD, de Flags et Local Name à Service UUID et Manufacturer Specific Data. Le bon empaquetage des advertising data est essentiel pour la compatibilité du périphérique avec iOS, Android et d'autres plateformes, et détermine également la vitesse de découverte et l'efficacité énergétique de la publicité.
Points Clés
- AD Structure est le format de données dans un paquet publicitaire BLE : longueur (1 octet), type (1 octet), valeur (jusqu'à 29 octets).
- Le paquet publicitaire est limité à 31 octets, le scan response fournit 31 octets supplémentaires pour les données additionnelles.
- Flags (0x01) est un type AD obligatoire qui définit les modes LE Limited Discoverable et BR/EDR Not Supported.
- Service UUID est transmis au format abrégé (2 octets) ou complet (16 octets).
- Manufacturer Specific Data (0xFF) est un type flexible pour toutes données personnalisées du fabricant.
Qu'est-ce qu'Advertising Data ?
Advertising Data est un ensemble structuré de champs qu'un périphérique BLE transmet dans des paquets publicitaires pour s'identifier et décrire ses capacités. Le Central, en scannant les ondes, lit ces données et décide de se connecter au périphérique, de l'ignorer ou de demander des informations supplémentaires via Scan Response.
Les données sont organisées selon le principe TLV (Type-Length-Value) : chaque élément AD se compose de trois champs. Length (1 octet) est la longueur de Value + Type (c'est-à-dire la longueur totale de l'élément moins 1 octet pour Length). Type (1 octet) est l'identifiant du type de données de Bluetooth Assigned Numbers. Value (N octets) est le contenu selon le type.
Un paquet publicitaire standard peut contenir jusqu'à 31 octets de données AD. Si cela ne suffit pas, on utilise Scan Response (31 octets supplémentaires) ou Extended Advertising (BLE 5.0, jusqu'à 251 octets). Les premiers octets du paquet publicitaire sont réservés pour l'en-tête PDU et l'adresse du périphérique — la charge utile AD commence à un décalage.
Format AD Structure
Chaque élément AD dans le paquet publicitaire commence par le champ Length (1 octet). La valeur Length indique le nombre d'octets qui suivent après Length — c'est-à-dire Type + Value. Par exemple, un élément avec Length=3 signifie qu'après Length il y a 1 octet de Type et 2 octets de Value. Le paquet se termine lorsque la somme des longueurs de tous les éléments atteint la taille des données publicitaires.
| Champ | Taille | Description |
|---|---|---|
| Length | 1 octet | Longueur de Type + Value (excluant Length) |
| Type (AD Type) | 1 octet | Identifiant du type de données de Bluetooth SIG |
| Value | 0–29 octets | Données du type spécifié |
L'analyseur Central lit la séquence d'éléments AD en commençant par le premier octet après l'en-tête. Si Length=0, l'élément est ignoré et l'analyseur passe à l'octet suivant. Les types AD en double (plusieurs éléments avec le même Type dans un même paquet) sont autorisés, mais le Central peut ne traiter que le premier ou le dernier selon l'implémentation de la pile.
Une règle importante : la somme de tous les Length(+1) dans le paquet ne doit pas dépasser la taille des données publicitaires (31 octets pour l'advertising PDU). Si les données ne tiennent pas, des priorités doivent être établies — quels types AD sont critiques pour la découverte initiale et lesquels peuvent être déplacés vers Scan Response.
Flags (0x01) : type AD obligatoire
Flags (AD Type 0x01) est un élément obligatoire dans le paquet publicitaire de tout périphérique BLE. Il occupe 3 octets : Length (0x02), Type (0x01), Value (1 octet de drapeaux binaires). Les drapeaux définissent les modes de découverte et les capacités du périphérique. La Core Specification recommande d'inclure Flags dans chaque paquet publicitaire.
Principaux drapeaux : LE Limited Discoverable Mode (bit 0) — le périphérique est détectable pendant un temps limité, LE General Discoverable Mode (bit 1) — le périphérique est toujours détectable, BR/EDR Not Supported (bit 2) — le périphérique supporte uniquement LE, Simultaneous LE and BR/EDR (bit 3) — supporte les deux modes. Pour les périphériques purement BLE, la combinaison LE General Discoverable + BR/EDR Not Supported est obligatoire.
Une valeur incorrecte de Flags est l'une des causes fréquentes pour lesquelles un périphérique n'est pas détecté sur iOS ou Android. Par exemple, si le drapeau BR/EDR Not Supported n'est pas défini, iOS peut essayer de se connecter via Bluetooth classique au lieu de BLE. Vérifiez la valeur de Flags lors du débogage du paquet publicitaire avec un analyseur Bluetooth (nRF Connect, Wireshark).
Local Name : nom du périphérique
Local Name (AD Type 0x08 ou 0x09) est le nom affiché du périphérique BLE. Le type 0x08 (Shortened Local Name) est un nom abrégé, utilisé lorsque le nom complet ne tient pas dans le paquet publicitaire. Le type 0x09 (Complete Local Name) est le nom complet du périphérique. La longueur maximale du nom est de 248 octets, mais dans un paquet publicitaire standard, pas plus de 28 octets ne sont disponibles.
Si le nom du périphérique dépasse l'espace disponible dans le paquet publicitaire, il est recommandé de placer le nom abrégé dans l'advertising PDU (type 0x08) et le nom complet dans Scan Response (type 0x09). iOS affiche le nom du paquet publicitaire lors du scan, tandis que le nom complet devient disponible après la connexion ou Scan Response.
Lors du choix d'un nom de périphérique, gardez à l'esprit qu'un nom trop long occupe de l'espace qui pourrait être utilisé pour Service UUID ou d'autres données importantes. La longueur de nom recommandée est de 8 à 16 caractères. Évitez les caractères non standard et les espaces — certaines piles BLE peuvent les traiter incorrectement.
Service UUID : identification des services
Service UUID (AD Type 0x02–0x07) est l'un des types AD les plus importants, permettant au Central de déterminer quels services le périphérique fournit sans s'y connecter. Bluetooth SIG définit plusieurs formats de transmission d'UUID selon la taille : 0x02 (Incomplete 16-bit), 0x03 (Complete 16-bit), 0x04 (Incomplete 32-bit), 0x05 (Complete 32-bit), 0x06 (Incomplete 128-bit), 0x07 (Complete 128-bit).
UUID 16 bits (2 octets) pour les services standard Bluetooth SIG, par exemple 0x180F (Battery Service), 0x180A (Device Information). UUID 128 bits (16 octets) pour les services personnalisés définis par le développeur. Un UUID 16 bits n'occupe que 4 octets dans AD (Length + Type + 2 octets UUID), tandis qu'un UUID 128 bits occupe 18 octets. Si plusieurs UUID personnalisés doivent être transmis dans un seul paquet, ils peuvent ne pas tenir dans 31 octets.
Il est recommandé d'utiliser le type Incomplete (0x02/0x04/0x06) si tous les UUID du périphérique ne sont pas transmis, seulement les plus importants pour le filtrage. La liste complète des UUID est transmise via Scan Response ou GATT Discovery après la connexion. Cela économise de l'espace dans le paquet publicitaire pour d'autres types AD.
Manufacturer Specific Data
Manufacturer Specific Data (AD Type 0xFF) est le type AD le plus flexible, conçu pour transmettre des données personnalisées du fabricant. Les 2 premiers octets de Value sont le Company Identifier Code attribué par Bluetooth SIG (par exemple, 0x004C pour Apple, 0x0075 pour Samsung). Les octets restants sont des données arbitraires dans un format défini par le fabricant.
Apple utilise Manufacturer Data pour iBeacon : Company ID (0x004C), type Beacon (0x0215), UUID (16 octets), Major (2 octets), Minor (2 octets), TX Power (1 octet). Google utilise un format similaire pour Eddystone. Les fabricants de dispositifs IoT placent souvent des lectures de capteurs ou l'état du périphérique dans Manufacturer Data.
js
// Parse Manufacturer Specific Data on Central
function parseManufacturerData(data) {
const view = new DataView(data.buffer);
// Company Identifier Code (first 2 bytes)
const companyId = view.getUint16(0, true);
// Check for Apple iBeacon
if (companyId === 0x004C) {
return parseIBeacon(view);
}
return null;
}Lors de l'utilisation de Manufacturer Data, il est important de respecter la limitation de taille : 31 octets pour l'ensemble du paquet publicitaire moins les types AD obligatoires. Pour Apple iBeacon, l'ensemble du paquet occupe 30 octets, ne laissant de place que pour Flags (3 octets). Pour Eddystone — jusqu'à 31 octets. Les formats personnalisés compacts peuvent inclure la température, l'humidité ou la pression en 4 à 8 octets.
Stratégie d'empaquetage des données
Le bon empaquetage des advertising data est l'art de placer le maximum d'informations utiles dans l'espace limité de 31 octets. La stratégie dépend de l'objectif du périphérique : une balise a besoin d'un identifiant, un capteur IoT a besoin de lectures, un tracker de fitness a besoin d'un nom et d'UUID de services. Le principe général : plus le Central doit prendre une décision rapidement, plus les données doivent être critiques dans l'advertising PDU.
Stratégie recommandée : advertising PDU (31 premiers octets) — Flags (3 octets) + un Service UUID 16 bits (4 octets) + nom abrégé (jusqu'à 12 caractères = 14 octets) + Manufacturer Data (jusqu'à 10 octets). Scan Response (31 deuxièmes octets) — nom complet (reste) + Service UUID supplémentaires + TX Power Level (3 octets). Cette distribution permet au Central de filtrer rapidement les périphériques par UUID.
| Priorité | Type AD | Taille | Placer dans |
|---|---|---|---|
| 1 (obligatoire) | Flags (0x01) | 3 octets | Advertising PDU |
| 2 (filtrage) | Service UUID (0x02–0x03) | 4+ octets | Advertising PDU |
| 3 (identification) | Local Name (0x08–0x09) | 2+ octets | Advertising PDU (abrégé) |
| 4 (supplémentaire) | TX Power Level (0x0A) | 3 octets | Scan Response |
| 5 (personnalisé) | Manufacturer Data (0xFF) | 4+ octets | Advertising PDU / Scan Response |
| 6 (données complètes) | UUID restants | Selon taille | Scan Response |
Le débogage des advertising data est une étape obligatoire du développement de périphériques BLE. Utilisez nRF Connect (Nordic Semiconductor) ou Wireshark avec un analyseur Bluetooth pour visualiser les données brutes du paquet. Vérifiez que tous les types AD ont une longueur correcte, que la somme des longueurs ne dépasse pas 31 octets et que Flags sont correctement définis pour votre cas d'utilisation.
Foire aux questions
Que se passe-t-il si la somme des éléments AD dépasse 31 octets ?
La pile du Bluetooth Controller rejettera les données dépassant la limite ou n'enverra pas le paquet. Vérifiez la longueur totale des éléments AD lors de l'assemblage du paquet publicitaire. Si les données ne tiennent pas, déplacez une partie dans Scan Response ou utilisez Extended Advertising (BLE 5.0) avec une limite de 251 octets.
Peut-on transmettre des lectures de capteurs dans un paquet publicitaire ?
Oui, via Manufacturer Specific Data (0xFF). Emballez les lectures en 4–8 octets : par exemple, la température (2 octets au format virgule fixe), l'humidité (2 octets), la tension de la batterie (2 octets). Cette approche permet au Central de lire les données sans connexion, économisant de l'énergie.
Quel type AD utiliser pour les services personnalisés ?
Pour les services personnalisés, utilisez UUID 128 bits (AD Type 0x06–0x07). Si l'UUID ne tient pas dans l'advertising PDU (16 octets par UUID), déplacez-le dans Scan Response ou utilisez le format abrégé Incomplete (0x06) pour spécifier seulement le premier ou les deux premiers UUID.
Quelle est la différence entre les types Complete et Incomplete de Service UUID ?
Complete — tous les UUID de service du périphérique sont listés dans le paquet. Incomplete — seulement une partie des UUID (généralement les plus importants). Le Central ne peut pas se fier à Incomplete comme liste complète, mais l'utilise pour un filtrage rapide. La liste complète est disponible après GATT Discovery.
Pourquoi iOS ne voit-il pas mon périphérique BLE ?
Une cause fréquente est un Flags (0x01) incorrect. Assurez-vous que le bit BR/EDR Not Supported est défini. La deuxième cause est l'absence de Service UUID dans le paquet publicitaire (iOS filtre par UUID). La troisième est que le périphérique annonce trop rarement (iOS attend un intervalle ne dépassant pas 1000 ms).
Résumé
- Advertising Data sont des données structurées au format AD Structure (Length-Type-Value), transmises dans les paquets publicitaires BLE.
- Un paquet publicitaire standard contient jusqu'à 31 octets de données ; Scan Response fournit 31 octets supplémentaires pour des informations additionnelles.
- Flags (0x01) est un type AD obligatoire qui définit les modes de découverte. BR/EDR Not Supported est obligatoire pour les périphériques BLE.
- Service UUID est transmis au format 16 bits (2 octets) ou 128 bits (16 octets), Complete ou Incomplete selon l'espace disponible.
- Manufacturer Specific Data (0xFF) est un type flexible pour les données personnalisées, utilisé dans les balises iBeacon, Eddystone et les dispositifs IoT.
- Stratégie d'empaquetage : types AD obligatoires (Flags, Service UUID, nom abrégé) dans l'advertising PDU ; les supplémentaires dans Scan Response.
- Déboguez les advertising data avec nRF Connect ou Wireshark — une étape de développement obligatoire pour vérifier la structure AD correcte.
Nous développerons une application mobile clé en main
IT Sectr crée des applications iOS et Android pour les startups et les entreprises depuis 2017. Nous vous conseillerons et vous proposerons la meilleure solution.
Lisez aussi