Advertising (pubblicità) è un meccanismo in Bluetooth Low Energy attraverso il quale un dispositivo Peripheral annuncia la propria presenza trasmettendo brevi pacchetti di dati su tre canali dedicati (37, 38, 39). La Bluetooth Core Specification 5.4 (2023) definisce due tipi di pubblicità: connectable — il dispositivo è pronto per la connessione, e non-connectable — utilizzato dai beacon che trasmettono solo dati senza stabilire una comunicazione bidirezionale. I parametri di pubblicità — intervallo da 20 ms a 10,24 s, potenza del trasmettitore da -20 a +10 dBm e tipo di pacchetto — influenzano direttamente la velocità di rilevamento del dispositivo e il suo consumo energetico, aspetto critico nello sviluppo di dispositivi IoT alimentati a batteria.
Punti chiave
Advertising (pubblicità) è il processo di trasmissione periodica di brevi pacchetti di dati attraverso cui un dispositivo BLE annuncia la propria presenza e disponibilità. A differenza del Bluetooth classico, dove il rilevamento dei dispositivi richiede secondi, l'advertising BLE consente di rilevare un dispositivo in millisecondi consumando energia minima.
L'architettura BLE divide i dispositivi in due ruoli: Peripheral (annuncia) e Central (scansiona). Il Peripheral invia pacchetti pubblicitari, mentre il Central scansiona l'aria e decide se connettersi. Questo modello asimmetrico è un vantaggio chiave del BLE: il dispositivo che pubblicizza spende energia solo per inviare brevi pacchetti, non per ascoltare costantemente l'aria.
Il processo di pubblicità si compone di tre fasi: advertising event (invio del pacchetto su tutti e tre i canali), scan request/response (scambio facoltativo con il Central) e connection request (avvio della connessione da parte del Central). Ogni fase è gestita dal Bluetooth Controller a livello di Link Layer.
BLE utilizza 40 canali nella banda 2,4 GHz, di cui 37 (2402 MHz), 38 (2426 MHz) e 39 (2480 MHz) sono dedicati esclusivamente alla pubblicità. Tre canali rappresentano un compromesso tra affidabilità di rilevamento e throughput: un canale può essere occupato dal Wi-Fi o da altre interferenze, ma il dispositivo verrà rilevato sugli altri due.
Il canale 37 si trova vicino al canale Wi-Fi 1, il canale 39 vicino al canale Wi-Fi 6 e il canale 38 si trova tra di loro, nella zona di interferenza minima. La scelta di tre canali garantisce che il dispositivo venga rilevato anche in ambienti radio densi — ad esempio, in un centro commerciale con decine di punti di accesso Wi-Fi.
Il Peripheral invia il pacchetto pubblicitario sequenzialmente su tutti e tre i canali — questo si chiama advertising event. Il dispositivo centrale scansiona un canale alla volta, alternandoli secondo un algoritmo implementato nel Bluetooth Controller. La probabilità di rilevamento in un singolo advertising event in assenza di collisioni è vicina al 100%.
Bluetooth Core Specification definisce diversi tipi di PDU pubblicitarie (Protocol Data Unit), ciascuna con il proprio scopo. I tipi principali sono: ADV_IND (connectable undirected advertising) — pubblicità standard con possibilità di connessione, ADV_NONCONN_IND (non-connectable undirected advertising) — solo pubblicità senza connessione, ADV_SCAN_IND (scannable undirected advertising) — supporta la richiesta di scansione, ADV_DIRECT_IND (directed advertising) — pubblicità per un Central specifico.
ADV_IND è il tipo più comune utilizzato nella maggior parte dei dispositivi BLE. Ricevendo ADV_IND, il Central può inviare una richiesta di connessione e stabilire una connessione. ADV_NONCONN_IND viene utilizzato nei beacon: il dispositivo pubblicizza ma non accetta richieste di connessione — solo trasmissione unidirezionale dei dati.
| Tipo PDU | Descrizione | Connessione | Scan response |
|---|---|---|---|
| ADV_IND | Pubblicità standard | Sì | Sì |
| ADV_DIRECT_IND | Pubblicità a un Central specifico | Sì | No |
| ADV_NONCONN_IND | Senza connessione (beacon) | No | No |
| ADV_SCAN_IND | Con supporto scansione | Sì | Sì |
| ADV_EXT_IND | Extended advertising (BLE 5.0) | Sì | Sì |
ADV_DIRECT_IND contiene l'indirizzo del Central target, consentendo di stabilire rapidamente una connessione senza attendere la scansione. Viene utilizzato quando i dispositivi si “conoscono” già — ad esempio, dopo la riconnessione a uno smartphone precedentemente associato. Questo tipo riduce il consumo energetico poiché non richiede pubblicità su tutti i canali.
Advertising interval è il tempo tra advertising event successivi. La specifica consente un intervallo da 20 ms a 10,24 s con passo di 0,625 ms. L'intervallo effettivo viene calcolato come somma di un valore fisso e un ritardo casuale (0–10 ms), riducendo la probabilità di collisioni tra più dispositivi che pubblicizzano.
Scegliere l'intervallo è un equilibrio tra velocità di rilevamento e consumo energetico. Con un intervallo di 20 ms, il dispositivo verrà rilevato in 20–30 ms, ma la corrente media sarà di circa 1–2 mA. Con un intervallo di 1000 ms, il rilevamento richiederà fino a 1 secondo, ma la corrente media scenderà a 50–100 µA. Per la maggior parte dei dispositivi IoT, l'intervallo raccomandato è 200–1000 ms.
Secondo il Texas Instruments Application Report SWRA478 (2024), aumentare l'intervallo di pubblicità da 100 ms a 1000 ms riduce il consumo energetico del 90%. Se il dispositivo non richiede rilevamento istantaneo (ad esempio, un sensore di temperatura che trasmette dati una volta al minuto), l'intervallo ottimale è 1000–2000 ms.
Un parametro aggiuntivo è advertising timeout — il tempo massimo durante il quale il dispositivo pubblicizza. In iOS, il Peripheral disattiva automaticamente la pubblicità dopo 180 secondi in background. In Android non esiste tale limitazione, ma i produttori possono aggiungere propri limiti.
Scan Response è un pacchetto di dati aggiuntivo (fino a 31 byte) che il Peripheral invia in risposta a una richiesta di scansione dal Central. La richiesta di scansione viene inviata dal Central dopo aver ricevuto il pacchetto pubblicitario se necessita di maggiori informazioni prima di connettersi. Scan Response non richiede pubblicità aggiuntiva — viene inviato solo su richiesta, risparmiando tempo di trasmissione.
Distribuzione tipica dei dati: la PDU pubblicitaria (31 byte) contiene flag (3 byte), UUID dei servizi (2–16 byte) e dati del produttore (byte rimanenti). Lo scan response trasporta il nome completo del dispositivo (fino a 28 byte) e UUID aggiuntivi o TX Power Level. Questa separazione consente al Central di filtrare rapidamente i dispositivi per UUID senza leggere lo scan response.
Quando si progetta il pacchetto pubblicitario, considerare: se tutti i 31 byte sono occupati nella PDU pubblicitaria, il Central non potrà determinare se il dispositivo supporta lo scan response. Si raccomanda di lasciare almeno 3–5 byte liberi nella PDU pubblicitaria per indicare la capacità di scan response.
Extended Advertising (BLE 5.0) è un'estensione del meccanismo pubblicitario che aumenta la dimensione del pacchetto pubblicitario da 31 a 251 byte e aggiunge nuovi tipi di pacchetto. Extended Advertising supporta anche coded PHY per estendere la portata di comunicazione fino a 1 km in aree aperte e pubblicità periodica (Periodic Advertising) per sincronizzare più Central.
Principali innovazioni: ADV_EXT_IND — PDU pubblicitaria estesa che può trasmettere fino a 251 byte di dati in un singolo pacchetto. Extended Advertising utilizza i canali primari (37, 38, 39) solo per indicare su quale canale secondario (0–36) vengono trasmessi i dati completi. Ciò riduce il carico sui canali pubblicitari e aumenta la capacità complessiva del sistema.
Periodic Advertising è un meccanismo aggiuntivo in cui il Peripheral invia dati su canali secondari a intervallo fisso e il Central può sincronizzarsi con questa sequenza. Viene utilizzato per servizi che richiedono aggiornamenti regolari dei dati — ad esempio, streaming audio o letture di sensori in tempo reale.
| Parametro | BLE standard | Extended BLE 5.0 |
|---|---|---|
| Dimensione max pacchetto | 31 byte | 251 byte |
| Canali | Solo 37, 38, 39 | + secondari 0–36 |
| Portata | Fino a 100 m | Fino a 1000 m (coded PHY) |
| Velocità | 1 Mbps | 125 kbps – 2 Mbps |
| Periodico | No | Sì |
iOS (Core Bluetooth) fornisce CBPeripheralManager per gestire la pubblicità. I parametri pubblicitari vengono impostati tramite il dizionario advertisementData con le chiavi CBAdvertisementDataLocalNameKey (nome dispositivo), CBAdvertisementDataServiceUUIDsKey (UUID servizi), CBAdvertisementDataTxPowerLevelKey (livello potenza). iOS gestisce automaticamente l'intervallo di pubblicità e non ne consente l'impostazione manuale.
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) fornisce un controllo più dettagliato. Disponibili: AdvertiseSettings — configurazione modalità (LOW_POWER, BALANCED, LOW_LATENCY), potenza trasmettitore e intervallo; AdvertiseData — dati del pacchetto. Android supporta extended advertising (BLE 5.0) su dispositivi compatibili, ma la quota di tali dispositivi sul mercato è circa del 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
);
Nello sviluppo di un'applicazione BLE multipiattaforma, considerare le differenze: iOS non consente di controllare direttamente l'intervallo di pubblicità ma garantisce un funzionamento stabile su tutti i dispositivi; Android offre il controllo completo, ma la frammentazione di versioni e produttori può causare incompatibilità. Si raccomanda di testare la pubblicità su dispositivi reali di entrambe le piattaforme.
Domande frequenti
La pubblicità connectable (ADV_IND) consente al Central di stabilire una connessione bidirezionale con il dispositivo. La non-connectable (ADV_NONCONN_IND) è solo trasmissione unidirezionale di dati, utilizzata dai beacon per trasmettere un identificatore senza possibilità di connessione.
Il pacchetto pubblicitario standard è di 31 byte, lo scan response di altri 31 byte. Extended Advertising (BLE 5.0+) aumenta il limite a 251 byte utilizzando canali secondari per la trasmissione dei dati.
Per la maggior parte dei dispositivi IoT, si consiglia 500–1000 ms. Se è necessario un rilevamento rapido (ad esempio, per collegare le cuffie), utilizzare 20–50 ms. Per sensori con trasmissione dati poco frequente, utilizzare 1000–2000 ms per risparmiare energia.
Tre canali (37, 38, 39) rappresentano un compromesso tra affidabilità di rilevamento e throughput. Un canale può essere occupato dal Wi-Fi, ma il dispositivo verrà rilevato sugli altri due. Il canale 38 si trova nella zona di interferenza minima tra i canali Wi-Fi.
La pubblicità è il principale consumatore di energia in BLE. Con un intervallo di 1000 ms, la corrente media è di 50–100 µA, consentendo al dispositivo di funzionare per un anno con una batteria CR2032. Con un intervallo di 20 ms, la corrente sale a 1–2 mA, riducendo il tempo di funzionamento a diverse settimane.
Riepilogo
Svilupperemo un'applicazione mobile chiavi in mano
IT Sectr crea applicazioni iOS e Android per startup e aziende dal 2017. Ti consulteremo e ti proporremo la soluzione migliore.
Leggi anche