Peripheral — quest-ce que cest, rôle dans BLE et comment il annonce les services

Quest-ce qu’un Peripheral en BLE ?

Peripheral est un périphérique BLE qui implémente un serveur GATT et annonce ses capacités via des canaux advertising. Contrairement à un Central, qui recherche activement des périphériques, un Peripheral attend passivement les connexions. Il s’agit d’un modèle asymétrique optimisé pour l’efficacité énergétique des appareils alimentés par batterie.

Peripheral peut être dans plusieurs modes : advertising (publicité), connected (connecté à un Central), sleeping (veille avec publicité désactivée). En mode advertising, le Peripheral envoie périodiquement de courts paquets de données avec une consommation d’énergie minimale. Après la connexion, le Peripheral passe en mode connected, où il échange des données avec le Central selon l’intervalle de connexion convenu.

Selon Bluetooth Core Specification 5.4 (2023), un périphérique peut basculer dynamiquement entre les rôles Peripheral et Central, mais à tout moment, le rôle est fixe pour une seule connexion. Un scénario typique : un capteur IoT fonctionne constamment en tant que Peripheral, tandis qu’un smartphone gère la connexion en tant que Central.

Il est important que les développeurs comprennent : le Peripheral détermine quels services et caractéristiques sont disponibles et gère leur accès. La structure du serveur GATT sur le Peripheral détermine les données que le Central peut lire et les commandes qu’il peut écrire.

Processus de publicité (Advertising)

Advertising est le mécanisme par lequel un Peripheral annonce sa présence. Le Peripheral envoie des paquets advertising sur trois canaux dédiés (37, 38, 39) avec un intervalle de 20 ms à 10,24 secondes. Chaque paquet advertising contient des informations fixes et peut inclure des données optionnelles.

Il existe deux types de paquets advertising : advertising PDU (paquet principal) et scan response PDU (réponse à une demande du Central). Le paquet principal contient des champs obligatoires : type de paquet, adresse de l’expéditeur, données. Si un Central envoie une demande de scan, le Peripheral répond avec un paquet supplémentaire contenant des informations plus complètes — par exemple, le nom complet du périphérique.

Les paramètres advertising affectent la vitesse de découverte et la consommation d’énergie. Advertising interval est le temps entre les transmissions de paquets. Plus l’intervalle est court, plus le Central découvre rapidement le périphérique, mais plus le Peripheral consomme d’énergie. Intervalle recommandé : 100–1000 ms pour la plupart des appareils.

Structure du paquet advertising

Le paquet advertising BLE a une limite de 31 octets pour l’advertising PDU et 31 octets supplémentaires pour le scan response. À l’intérieur du paquet, les données sont organisées au format AD Structure (Advertising Data Structure) : chaque champ a un type (1 octet), une longueur (1 octet) et une valeur.

Les types AD les plus courants : Flags (0x01) — modes de connexion et de découverte, Local Name (0x08 ou 0x09) — nom du périphérique, Service UUID List (0x02–0x07) — liste des UUID de services, Manufacturer Specific Data (0xFF) — données fabricant. Empaqueter correctement les données dans un paquet de 31 octets est une tâche importante pour les développeurs de périphériques embarqués.

Pour les périphériques qui doivent transmettre plus de données, extended advertising (BLE 5.0+) augmente la taille du paquet advertising à 251 octets et ajoute de nouveaux types de paquets. Extended advertising prend également en charge les canaux PHY codés pour une portée accrue jusqu’à 1 km en extérieur.

Lors de la conception d’un paquet advertising, gardez à l’esprit : plus il y a de données dans le paquet advertising, plus la probabilité de collision avec d’autres périphériques est élevée. Pour une découverte rapide, il est recommandé de placer uniquement les données critiques (Service UUID) dans l’advertising PDU et les données supplémentaires dans le scan response.

Peripheral en tant que serveur GATT

Serveur GATT sur le Peripheral contient tous les services et caractéristiques qu’un Central peut découvrir et avec lesquels il peut interagir. Après la connexion, le Central découvre les services, puis les caractéristiques, et interagit avec eux via le protocole GATT.

Peripheral en tant que serveur GATT doit traiter correctement les demandes du Central : demandes de lecture, demandes d’écriture, notifications et indications. Chaque demande traverse la table GATT, où chaque attribut (service, caractéristique, descripteur) correspond à un Handle — une adresse 16 bits.

Le développeur de Peripheral définit les droits d’accès pour chaque attribut : lecture seule, écriture seule, lecture et écriture, avec ou sans cryptage. Pour les données sensibles (informations personnelles, indicateurs médicaux), il est recommandé d’activer le cryptage via MITM Protection.

Peripheral sous iOS : CBPeripheralManager

CBPeripheralManager est une classe Core Bluetooth pour implémenter le rôle Peripheral sous iOS. Il gère le serveur GATT, publie les services et caractéristiques, et traite les demandes des Centrals. Contrairement à CBCentralManager, CBPeripheralManager ne scanne pas — il se contente de faire de la publicité et de gérer les connexions.

Les principales étapes pour implémenter un Peripheral sous iOS : initialiser CBPeripheralManager, ajouter des services via add, démarrer la publicité via startAdvertising, traiter les demandes des Centrals via le délégué CBPeripheralManagerDelegate.

import CoreBluetooth

class BLEPeripheralManager: NSObject, CBPeripheralManagerDelegate {

    private var peripheralManager: CBPeripheralManager!

    func startAdvertising() {
        let advertisementData: [String: Any] = [
            CBAdvertisementDataLocalNameKey: "BLE Sensor",
            CBAdvertisementDataServiceUUIDsKey: [
                CBUUID("180F")
            ]
        ]
        peripheralManager.startAdvertising(advertisementData)
    }

    func peripheralManagerDidUpdateState(
        _ peripheral: CBPeripheralManager
    ) {
        if peripheral.state == .poweredOn {
            startAdvertising()
        }
    }
}

iOS permet au Peripheral de fonctionner en arrière-plan avec la clé bluetooth-peripheral dans Background Modes. En arrière-plan, iOS peut faire de la publicité avec un ensemble limité de données et gérer les connexions. Pour une publicité prolongée (plus de 180 secondes), utilisez l’option CBAdvertisementDataWaitForResponseFromCentral pour économiser de l’énergie.

Peripheral sous Android : BluetoothLeAdvertiser

Android fournit BluetoothLeAdvertiser pour travailler dans le rôle Peripheral (à partir de l’API 21). L’API permet de démarrer la publicité avec des paramètres configurables : puissance de l’émetteur, intervalle de publicité, données du paquet. Android prend également en charge extended advertising (BLE 5.0) sur les périphériques compatibles.

import android.bluetooth.le.*;

private BluetoothLeAdvertiser advertiser;

public void startPeripheral() {
    BluetoothAdapter adapter =
        BluetoothAdapter.getDefaultAdapter();
    advertiser = adapter.getBluetoothLeAdvertiser();

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

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

    advertiser.startAdvertising(
        settings, data, advertiseCallback
    );
}

Sous Android, la prise en charge de Peripheral dépend du fabricant et de la version de l’OS. Tous les périphériques ne prennent pas en charge BluetoothLeAdvertiser — vérifiez via adapter.isMultipleAdvertisementSupported(). À partir d’Android 10, l’autorisation BLUETOOTH_ADVERTISE est requise pour le rôle Peripheral, ainsi qu’une demande d’exécution pour les applications avec target SDK 31+.

Efficacité énergétique de Peripheral

L’efficacité énergétique est un avantage clé du BLE, et le Peripheral joue un rôle majeur à cet égard. Un périphérique peut fonctionner sur une pile CR2032 (220 mAh) pendant plus d’un an grâce à une consommation d’énergie optimisée. La plupart du temps, le Peripheral reste en mode veille avec la publicité désactivée, se réveillant uniquement pour envoyer un paquet advertising ou traiter une demande d’un Central.

Consommation énergétique de Peripheral dans différents modes : mode veille (sommeil profond) — 1–5 µA, inactif avec minuterie activée — 10–50 µA, advertising — 5–15 mA (pendant la transmission du paquet), connected — 5–10 mA (pendant l’événement de connexion). Avec un intervalle advertising de 1000 ms et une durée de paquet de 4 ms, le courant moyen est d’environ 50–100 µA.

Selon Texas Instruments Application Report (SWRA478, 2024), l’optimisation de l’intervalle advertising de 100 ms à 1000 ms réduit la consommation moyenne d’énergie de 90 %. Des économies supplémentaires sont réalisées grâce à la latence esclave (saut d’événements de connexion), à la réduction de la puissance Tx sur de courtes distances et à la désactivation de la publicité après la connexion (connectable advertising).