Peripheral — cos’è, ruolo in BLE e come pubblicizza i servizi

Cos’è un Peripheral in BLE?

Peripheral è un dispositivo BLE che implementa un server GATT e pubblicizza le proprie capacità attraverso canali advertising. A differenza di un Central, che cerca attivamente dispositivi, un Peripheral attende passivamente le connessioni. Questo è un modello asimmetrico ottimizzato per l’efficienza energetica dei dispositivi alimentati a batteria.

Peripheral può trovarsi in diverse modalità: advertising (pubblicità), connected (connesso a un Central), sleeping (sospensione con pubblicità disattivata). In modalità advertising, il Peripheral invia periodicamente brevi pacchetti di dati consumando energia minima. Dopo la connessione, il Peripheral passa alla modalità connected, dove scambia dati con il Central secondo l’intervallo di connessione concordato.

Secondo Bluetooth Core Specification 5.4 (2023), un dispositivo può passare dinamicamente tra i ruoli di Peripheral e Central, ma in ogni momento il ruolo è fisso per una singola connessione. Uno scenario tipico: un sensore IoT funziona costantemente come Peripheral, mentre uno smartphone gestisce la connessione come Central.

È importante che gli sviluppatori comprendano: il Peripheral determina quali servizi e caratteristiche sono disponibili e gestisce l’accesso ad essi. La struttura del server GATT sul Peripheral determina quali dati il Central può leggere e quali comandi può scrivere.

Processo di advertising

Advertising è il meccanismo con cui un Peripheral annuncia la propria presenza. Il Peripheral invia pacchetti advertising su tre canali dedicati (37, 38, 39) con un intervallo da 20 ms a 10,24 secondi. Ogni pacchetto advertising contiene informazioni fisse e può includere dati opzionali.

Esistono due tipi di pacchetti advertising: advertising PDU (pacchetto principale) e scan response PDU (risposta a una richiesta del Central). Il pacchetto principale contiene campi obbligatori: tipo di pacchetto, indirizzo del mittente, dati. Se un Central invia una richiesta di scansione, il Peripheral risponde con un pacchetto aggiuntivo contenente informazioni più complete, ad esempio il nome completo del dispositivo.

I parametri di advertising influenzano la velocità di rilevamento e il consumo energetico. Advertising interval è il tempo tra le trasmissioni dei pacchetti. Più breve è l’intervallo, più velocemente il Central rileverà il dispositivo, ma maggiore sarà il consumo energetico del Peripheral. Intervallo consigliato: 100–1000 ms per la maggior parte dei dispositivi.

Struttura del pacchetto advertising

Il pacchetto advertising BLE ha un limite di 31 byte per l’advertising PDU e altri 31 byte per lo scan response. All’interno del pacchetto, i dati sono organizzati in formato AD Structure (Advertising Data Structure): ogni campo ha un tipo (1 byte), una lunghezza (1 byte) e un valore.

I tipi AD più comuni: Flags (0x01) — modalità di connessione e rilevamento, Local Name (0x08 o 0x09) — nome del dispositivo, Service UUID List (0x02–0x07) — elenco degli UUID dei servizi, Manufacturer Specific Data (0xFF) — dati del produttore. Impacchettare correttamente i dati in un pacchetto di 31 byte è un compito importante per gli sviluppatori di dispositivi embedded.

Per i dispositivi che devono trasmettere più dati, extended advertising (BLE 5.0+) aumenta la dimensione del pacchetto advertising a 251 byte e aggiunge nuovi tipi di pacchetto. Extended advertising supporta anche canali PHY codificati per una portata maggiore fino a 1 km in aree aperte.

Quando si progetta un pacchetto advertising, tenere presente: più dati ci sono nel pacchetto advertising, maggiore è la probabilità di collisione con altri dispositivi. Per un rilevamento rapido, si consiglia di inserire solo i dati critici (Service UUID) nell’advertising PDU e i dati aggiuntivi nello scan response.

Peripheral come server GATT

Server GATT sul Peripheral contiene tutti i servizi e le caratteristiche che un Central può scoprire e con cui può interagire. Dopo la connessione, il Central scopre i servizi, poi le caratteristiche e interagisce con essi tramite il protocollo GATT.

Peripheral come server GATT deve gestire correttamente le richieste del Central: richieste di lettura, richieste di scrittura, notifiche e indicazioni. Ogni richiesta passa attraverso la tabella GATT, dove ogni attributo (servizio, caratteristica, descrittore) corrisponde a un Handle — un indirizzo a 16 bit.

Lo sviluppatore di Peripheral definisce i permessi di accesso per ogni attributo: sola lettura, sola scrittura, lettura e scrittura, con o senza crittografia. Per i dati sensibili (informazioni personali, indicatori medici), si consiglia di abilitare la crittografia tramite MITM Protection.

Peripheral su iOS: CBPeripheralManager

CBPeripheralManager è una classe Core Bluetooth per implementare il ruolo Peripheral su iOS. Gestisce il server GATT, pubblica servizi e caratteristiche e gestisce le richieste dei Central. A differenza di CBCentralManager, CBPeripheralManager non esegue la scansione — si limita a pubblicizzare e gestire le connessioni.

I passaggi principali per implementare un Peripheral su iOS: inizializzare CBPeripheralManager, aggiungere servizi tramite add, avviare la pubblicità tramite startAdvertising, gestire le richieste dei Central tramite il delegato 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 consente al Peripheral di funzionare in background con la chiave bluetooth-peripheral in Background Modes. In background, iOS può pubblicizzare con un set limitato di dati e gestire le connessioni. Per una pubblicità prolungata (oltre 180 secondi), utilizzare l’opzione CBAdvertisementDataWaitForResponseFromCentral per risparmiare energia.

Peripheral su Android: BluetoothLeAdvertiser

Android fornisce BluetoothLeAdvertiser per lavorare nel ruolo Peripheral (a partire dall’API 21). L’API consente di avviare la pubblicità con parametri configurabili: potenza del trasmettitore, intervallo di pubblicità, dati del pacchetto. Android supporta anche extended advertising (BLE 5.0) sui dispositivi compatibili.

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
    );
}

Su Android, il supporto di Peripheral dipende dal produttore e dalla versione del sistema operativo. Non tutti i dispositivi supportano BluetoothLeAdvertiser — verificare tramite adapter.isMultipleAdvertisementSupported(). A partire da Android 10, è richiesta l’autorizzazione BLUETOOTH_ADVERTISE per il ruolo Peripheral, insieme a una richiesta runtime per le app con target SDK 31+.

Efficienza energetica di Peripheral

L’efficienza energetica è un vantaggio chiave del BLE e il Peripheral svolge un ruolo principale in questo. Un dispositivo può funzionare con una batteria CR2032 (220 mAh) per oltre un anno grazie al consumo energetico ottimizzato. La maggior parte del tempo, il Peripheral rimane in modalità sospensione con la pubblicità disattivata, svegliandosi solo per inviare un pacchetto advertising o elaborare una richiesta da un Central.

Consumo energetico di Peripheral in diverse modalità: modalità sospensione (sonno profondo) — 1–5 µA, inattivo con timer attivato — 10–50 µA, advertising — 5–15 mA (durante la trasmissione del pacchetto), connected — 5–10 mA (durante l’evento di connessione). Con un intervallo advertising di 1000 ms e una durata del pacchetto di 4 ms, la corrente media è di circa 50–100 µA.

Secondo Texas Instruments Application Report (SWRA478, 2024), ottimizzare l’intervallo advertising da 100 ms a 1000 ms riduce il consumo energetico medio del 90%. Ulteriori risparmi si ottengono tramite slave latency (saltare eventi di connessione), ridurre la potenza Tx su brevi distanze e disattivare la pubblicità dopo la connessione (connectable advertising).