L'Advertising en BLE : qu'est-ce que c'est, formats de paquets et mécanismes de publicité

Qu'est-ce que l'Advertising en BLE ?

Advertising (publicité) est le processus de transmission périodique de courts paquets de données par lequel un périphérique BLE annonce sa présence et sa disponibilité. Contrairement au Bluetooth classique, où la détection des périphériques prend des secondes, l'Advertising BLE permet de détecter un périphérique en millisecondes tout en consommant un minimum d'énergie.

L'architecture BLE divise les périphériques en deux rôles : Peripheral (annonce) et Central (scan). Le Peripheral envoie des paquets publicitaires, tandis que le Central scanne les ondes et décide de se connecter. Ce modèle asymétrique est un avantage clé du BLE : le périphérique annonceur ne dépense de l'énergie que pour envoyer de courts paquets, et non pour écouter constamment les ondes.

Le processus de publicité comprend trois étapes : advertising event (envoi du paquet sur les trois canaux), scan request/response (échange facultatif avec le Central) et connection request (initiation de la connexion par le Central). Chaque étape est gérée par le Bluetooth Controller au niveau de la Link Layer.

Canaux publicitaires et leur rôle

BLE utilise 40 canaux dans la bande 2,4 GHz, dont 37 (2402 MHz), 38 (2426 MHz) et 39 (2480 MHz) sont dédiés exclusivement à la publicité. Trois canaux représentent un compromis entre fiabilité de détection et débit : un canal peut être occupé par le Wi-Fi ou d'autres interférences, mais le périphérique sera détecté sur les deux autres.

Le canal 37 se situe près du canal Wi-Fi 1, le canal 39 près du canal Wi-Fi 6, et le canal 38 se trouve entre eux, dans la zone d'interférence minimale. Le choix de trois canaux garantit que le périphérique sera détecté même dans des environnements radio denses — par exemple, dans un centre commercial avec des dizaines de points d'accès Wi-Fi.

Le Peripheral envoie le paquet publicitaire séquentiellement sur les trois canaux — ceci s'appelle un advertising event. Le périphérique central scanne un canal à la fois, en alternant entre eux selon un algorithme implémenté dans le Bluetooth Controller. La probabilité de détection en un seul advertising event en l'absence de collisions est proche de 100 %.

Types de paquets publicitaires

Bluetooth Core Specification définit plusieurs types de PDU publicitaires (Protocol Data Unit), chacun avec son objectif. Les principaux types sont : ADV_IND (connectable undirected advertising) — publicité standard avec possibilité de connexion, ADV_NONCONN_IND (non-connectable undirected advertising) — publicité seule sans connexion, ADV_SCAN_IND (scannable undirected advertising) — prend en charge le scan request, ADV_DIRECT_IND (directed advertising) — publicité pour un Central spécifique.

ADV_IND est le type le plus courant utilisé dans la plupart des périphériques BLE. Lors de la réception d'ADV_IND, le Central peut envoyer une demande de connexion et établir une connexion. ADV_NONCONN_IND est utilisé par les balises (Beacon) : le périphérique annonce mais n'accepte pas les demandes de connexion — uniquement une transmission unidirectionnelle de données.

ADV_DIRECT_IND contient l'adresse du Central cible, permettant d'établir rapidement une connexion sans attendre le scan. Il est utilisé lorsque les périphériques se « connaissent » déjà — par exemple, après la reconnexion à un smartphone précédemment appairé. Ce type réduit la consommation d'énergie car il ne nécessite pas de publicité sur tous les canaux.

Intervalle de publicité et consommation d'énergie

L'intervalle de publicité (Advertising interval) est le temps entre les advertising events successifs. La spécification autorise un intervalle de 20 ms à 10,24 s avec un pas de 0,625 ms. L'intervalle réel est calculé comme la somme d'une valeur fixe et d'un délai aléatoire (0–10 ms), ce qui réduit la probabilité de collisions entre plusieurs périphériques annonceurs.

Choisir l'intervalle est un équilibre entre vitesse de détection et consommation d'énergie. À un intervalle de 20 ms, le périphérique sera détecté en 20–30 ms, mais le courant moyen sera d'environ 1–2 mA. À un intervalle de 1000 ms, la détection prendra jusqu'à 1 seconde, mais le courant moyen chutera à 50–100 µA. Pour la plupart des dispositifs IoT, l'intervalle recommandé est de 200–1000 ms.

Selon le Texas Instruments Application Report SWRA478 (2024), augmenter l'intervalle de publicité de 100 ms à 1000 ms réduit la consommation d'énergie de 90 %. Si le périphérique ne nécessite pas de détection instantanée (par exemple, un capteur de température qui transmet des données une fois par minute), l'intervalle optimal est de 1000–2000 ms.

Un paramètre supplémentaire est le délai d'expiration de la publicité (advertising timeout) — le temps maximal pendant lequel le périphérique annonce. Sous iOS, le Peripheral désactive automatiquement la publicité après 180 secondes en arrière-plan. Sous Android, il n'y a pas de telle limitation, mais les fabricants peuvent ajouter leurs propres limites.

Scan Response : données supplémentaires

Scan Response est un paquet de données supplémentaire (jusqu'à 31 octets) que le Peripheral envoie en réponse à une demande de scan du Central. La demande de scan est envoyée par le Central après réception du paquet publicitaire s'il a besoin de plus d'informations avant de se connecter. Le Scan Response ne nécessite pas de publicité supplémentaire — il est envoyé uniquement sur demande, économisant ainsi du temps d'antenne.

Répartition typique des données : la PDU publicitaire (31 octets) contient les indicateurs (3 octets), les UUID de services (2–16 octets) et les données du fabricant (octets restants). La scan response transporte le nom complet du périphérique (jusqu'à 28 octets) et des UUID supplémentaires ou le niveau de puissance TX. Cette séparation permet au Central de filtrer rapidement les périphériques par UUID sans lire la scan response.

Lors de la conception du paquet publicitaire, gardez à l'esprit : si les 31 octets sont tous occupés dans la PDU publicitaire, le Central ne pourra pas déterminer si le périphérique prend en charge la scan response. Il est recommandé de laisser au moins 3–5 octets libres dans la PDU publicitaire pour indiquer la capacité de scan response.

Extended Advertising en BLE 5.0

Extended Advertising (BLE 5.0) est une extension du mécanisme de publicité qui augmente la taille du paquet publicitaire de 31 à 251 octets et ajoute de nouveaux types de paquets. Extended Advertising prend également en charge le coded PHY pour étendre la portée de communication jusqu'à 1 km en zone dégagée et la publicité périodique (Periodic Advertising) pour synchroniser plusieurs Centraux.

Principales innovations : ADV_EXT_IND — PDU publicitaire étendu qui peut transmettre jusqu'à 251 octets de données en un seul paquet. Extended Advertising utilise les canaux primaires (37, 38, 39) uniquement pour indiquer sur quel canal secondaire (0–36) les données complètes sont transmises. Cela réduit la charge sur les canaux publicitaires et augmente le débit global du système.

Periodic Advertising est un mécanisme supplémentaire dans lequel le Peripheral envoie des données sur des canaux secondaires à un intervalle fixe, et le Central peut se synchroniser avec cette séquence. Il est utilisé pour les services nécessitant des mises à jour régulières des données — par exemple, la diffusion audio ou les lectures de capteurs en temps réel.

Configuration de la publicité sous iOS et Android

iOS (Core Bluetooth) fournit CBPeripheralManager pour gérer la publicité. Les paramètres de publicité sont définis via le dictionnaire advertisementData avec les clés CBAdvertisementDataLocalNameKey (nom du périphérique), CBAdvertisementDataServiceUUIDsKey (UUID des services), CBAdvertisementDataTxPowerLevelKey (niveau de puissance). iOS gère automatiquement l'intervalle de publicité et ne permet pas de le définir manuellement.

import CoreBluetooth

class AdvertiserManager: NSObject, CBPeripheralManagerDelegate {

    private var peripheralManager: CBPeripheralManager!

    func startBLEAdvertising() {
        let data: [String: Any] = [
            CBAdvertisementDataLocalNameKey: "BLE Beacon",
            CBAdvertisementDataServiceUUIDsKey: [
                CBUUID("180F")
            ],
            CBAdvertisementDataIsConnectable: true
        ]
        peripheralManager.startAdvertising(data)
    }
}

Android (BluetoothLeAdvertiser) offre un contrôle plus détaillé. Disponibles : AdvertiseSettings — configuration du mode (LOW_POWER, BALANCED, LOW_LATENCY), puissance de l'émetteur et intervalle ; AdvertiseData — données du paquet. Android prend en charge l'extended advertising (BLE 5.0) sur les appareils compatibles, mais la part de ces appareils sur le marché est d'environ 30–40 %.

BluetoothLeAdvertiser advertiser =
    BluetoothAdapter.getDefaultAdapter()
    .getBluetoothLeAdvertiser();

AdvertiseSettings settings = new AdvertiseSettings.Builder()
    .setAdvertiseMode(
        AdvertiseSettings.ADVERTISE_MODE_LOW_POWER
    )
    .setTxPowerLevel(
        AdvertiseSettings.ADVERTISE_TX_POWER_MEDIUM
    )
    .build();

AdvertiseData data = new AdvertiseData.Builder()
    .setIncludeDeviceName(true)
    .addServiceUuid(new ParcelUuid(
        UUID.fromString(
            "0000180F-0000-1000-8000-00805F9B34FB"
        )
    ))
    .build();

advertiser.startAdvertising(
    settings, data, advertiseCallback
);

Lors du développement d'une application BLE multiplateforme, tenez compte des différences : iOS ne permet pas de contrôler directement l'intervalle de publicité mais garantit un fonctionnement stable sur tous les appareils ; Android offre un contrôle total, mais la fragmentation des versions et des fabricants peut entraîner des incompatibilités. Il est recommandé de tester la publicité sur des appareils réels des deux plateformes.