Advertising Data in BLE: cos'è, struttura e tipi di dati
Advertising Data sono dati strutturati che un dispositivo BLE trasmette in pacchetti pubblicitari per identificare se stesso e i propri servizi. La Bluetooth Core Specification 5.4 (2023) definisce il formato AD Structure: ogni elemento contiene una lunghezza (1 byte), un tipo (1 byte) e un valore (fino a 29 byte). La specifica descrive oltre 30 tipi AD, da Flags e Local Name a Service UUID e Manufacturer Specific Data. Il corretto impacchettamento degli advertising data è fondamentale per la compatibilità del dispositivo con iOS, Android e altre piattaforme, e determina anche la velocità di rilevamento e l'efficienza energetica della pubblicità.
Punti Chiave
- AD Structure è il formato dei dati in un pacchetto pubblicitario BLE: lunghezza (1 byte), tipo (1 byte), valore (fino a 29 byte).
- Il pacchetto pubblicitario è limitato a 31 byte, lo scan response fornisce altri 31 byte per dati aggiuntivi.
- Flags (0x01) è un tipo AD obbligatorio che definisce le modalità LE Limited Discoverable e BR/EDR Not Supported.
- Service UUID viene trasmesso in formato abbreviato (2 byte) o completo (16 byte).
- Manufacturer Specific Data (0xFF) è un tipo flessibile per qualsiasi dato personalizzato del produttore.
Cos'è Advertising Data?
Advertising Data è un insieme strutturato di campi che un dispositivo BLE trasmette in pacchetti pubblicitari per identificarsi e descrivere le proprie capacità. Il Central, scansionando l'etere, legge questi dati e decide se connettersi al dispositivo, ignorarlo o richiedere informazioni aggiuntive tramite Scan Response.
I dati sono organizzati secondo il principio TLV (Type-Length-Value): ogni elemento AD è composto da tre campi. Length (1 byte) è la lunghezza di Value + Type (cioè la lunghezza totale dell'elemento meno 1 byte per Length). Type (1 byte) è l'identificatore del tipo di dati da Bluetooth Assigned Numbers. Value (N byte) è il contenuto a seconda del tipo.
Un pacchetto pubblicitario standard può contenere fino a 31 byte di dati AD. Se ciò non è sufficiente, si utilizza Scan Response (altri 31 byte) o Extended Advertising (BLE 5.0, fino a 251 byte). I primi byte del pacchetto pubblicitario sono riservati per l'intestazione PDU e l'indirizzo del dispositivo — il payload AD inizia a un offset.
Formato AD Structure
Ogni elemento AD nel pacchetto pubblicitario inizia con il campo Length (1 byte). Il valore Length indica il numero di byte che seguono dopo Length — cioè Type + Value. Ad esempio, un elemento con Length=3 significa che dopo Length ci sono 1 byte di Type e 2 byte di Value. Il pacchetto termina quando la somma delle lunghezze di tutti gli elementi raggiunge la dimensione dei dati pubblicitari.
| Campo | Dimensione | Descrizione |
|---|---|---|
| Length | 1 byte | Lunghezza di Type + Value (escluso Length) |
| Type (AD Type) | 1 byte | Identificatore del tipo di dati di Bluetooth SIG |
| Value | 0–29 byte | Dati del tipo specificato |
Il parser Central legge la sequenza di elementi AD a partire dal primo byte dopo l'intestazione. Se Length=0, l'elemento viene ignorato e il parser passa al byte successivo. Tipi AD duplicati (più elementi con lo stesso Type in un pacchetto) sono consentiti, ma il Central può elaborare solo il primo o l'ultimo a seconda dell'implementazione dello stack.
Una regola importante: la somma di tutti i Length(+1) nel pacchetto non deve superare la dimensione dei dati pubblicitari (31 byte per advertising PDU). Se i dati non ci stanno, è necessario stabilire le priorità — quali tipi AD sono critici per il rilevamento iniziale e quali possono essere spostati in Scan Response.
Flags (0x01): Tipo AD Obbligatorio
Flags (AD Type 0x01) è un elemento obbligatorio nel pacchetto pubblicitario di qualsiasi dispositivo BLE. Occupa 3 byte: Length (0x02), Type (0x01), Value (1 byte di flag binari). I flag definiscono le modalità di rilevamento e le capacità del dispositivo. La Core Specification raccomanda di includere Flags in ogni pacchetto pubblicitario.
Flag principali: LE Limited Discoverable Mode (bit 0) — il dispositivo è rilevabile per un tempo limitato, LE General Discoverable Mode (bit 1) — il dispositivo è sempre rilevabile, BR/EDR Not Supported (bit 2) — il dispositivo supporta solo LE, Simultaneous LE and BR/EDR (bit 3) — supporta entrambe le modalità. Per i dispositivi puramente BLE, la combinazione LE General Discoverable + BR/EDR Not Supported è obbligatoria.
Un valore errato di Flags è una delle cause comuni per cui un dispositivo non viene rilevato su iOS o Android. Ad esempio, se il flag BR/EDR Not Supported non è impostato, iOS potrebbe tentare di connettersi tramite Bluetooth classico invece di BLE. Verificare il valore di Flags durante il debug del pacchetto pubblicitario con un analizzatore Bluetooth (nRF Connect, Wireshark).
Local Name: Nome del Dispositivo
Local Name (AD Type 0x08 o 0x09) è il nome visualizzato del dispositivo BLE. Il tipo 0x08 (Shortened Local Name) è un nome abbreviato, utilizzato quando il nome completo non entra nel pacchetto pubblicitario. Il tipo 0x09 (Complete Local Name) è il nome completo del dispositivo. La lunghezza massima del nome è di 248 byte, ma in un pacchetto pubblicitario standard non sono disponibili più di 28 byte.
Se il nome del dispositivo supera lo spazio disponibile nel pacchetto pubblicitario, si raccomanda di: inserire il nome abbreviato nell'advertising PDU (tipo 0x08) e il nome completo in Scan Response (tipo 0x09). iOS visualizza il nome dal pacchetto pubblicitario durante la scansione, mentre il nome completo diventa disponibile dopo la connessione o Scan Response.
Quando si sceglie un nome dispositivo, tenere presente che un nome troppo lungo occupa spazio che potrebbe essere utilizzato per Service UUID o altri dati importanti. La lunghezza del nome raccomandata è di 8–16 caratteri. Evitare caratteri non standard e spazi — alcuni stack BLE potrebbero gestirli in modo errato.
Service UUID: Identificazione dei Servizi
Service UUID (AD Type 0x02–0x07) è uno dei tipi AD più importanti, consentendo al Central di determinare quali servizi fornisce il dispositivo senza connettersi ad esso. Bluetooth SIG definisce diversi formati di trasmissione UUID a seconda della dimensione: 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 a 16 bit (2 byte) per i servizi standard Bluetooth SIG, ad esempio 0x180F (Battery Service), 0x180A (Device Information). UUID a 128 bit (16 byte) per i servizi personalizzati definiti dallo sviluppatore. Un UUID a 16 bit occupa solo 4 byte in AD (Length + Type + 2 byte UUID), mentre un UUID a 128 bit occupa 18 byte. Se è necessario trasmettere più UUID personalizzati in un unico pacchetto, potrebbero non entrare in 31 byte.
Si consiglia di utilizzare il tipo Incomplete (0x02/0x04/0x06) se non vengono trasmessi tutti gli UUID del dispositivo, solo quelli più importanti per il filtraggio. L'elenco completo degli UUID viene trasmesso tramite Scan Response o GATT Discovery dopo la connessione. Ciò risparmia spazio nel pacchetto pubblicitario per altri tipi AD.
Manufacturer Specific Data
Manufacturer Specific Data (AD Type 0xFF) è il tipo AD più flessibile, progettato per trasmettere dati personalizzati del produttore. I primi 2 byte di Value sono il Company Identifier Code assegnato da Bluetooth SIG (ad esempio, 0x004C per Apple, 0x0075 per Samsung). I byte rimanenti sono dati arbitrari in un formato definito dal produttore.
Apple utilizza Manufacturer Data per iBeacon: Company ID (0x004C), tipo Beacon (0x0215), UUID (16 byte), Major (2 byte), Minor (2 byte), TX Power (1 byte). Google utilizza un formato simile per Eddystone. I produttori di dispositivi IoT spesso inseriscono letture dei sensori o stato del dispositivo in 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;
}Quando si utilizza Manufacturer Data, è importante rispettare il limite di dimensione: 31 byte per l'intero pacchetto pubblicitario meno i tipi AD obbligatori. Per Apple iBeacon, l'intero pacchetto occupa 30 byte, lasciando spazio solo per Flags (3 byte). Per Eddystone — fino a 31 byte. I formati personalizzati compatti possono includere temperatura, umidità o pressione in 4–8 byte.
Strategia di Impacchettamento dei Dati
Il corretto impacchettamento degli advertising data è l'arte di posizionare il massimo delle informazioni utili nello spazio limitato di 31 byte. La strategia dipende dallo scopo del dispositivo: un beacon ha bisogno di un identificatore, un sensore IoT ha bisogno di letture, un fitness tracker ha bisogno di un nome e di UUID dei servizi. Il principio generale: più velocemente il Central deve prendere una decisione, più critici devono essere i dati nell'advertising PDU.
Strategia raccomandata: advertising PDU (primi 31 byte) — Flags (3 byte) + un Service UUID a 16 bit (4 byte) + nome abbreviato (fino a 12 caratteri = 14 byte) + Manufacturer Data (fino a 10 byte). Scan Response (secondi 31 byte) — nome completo (resto) + Service UUID aggiuntivi + TX Power Level (3 byte). Questa distribuzione consente al Central di filtrare rapidamente i dispositivi per UUID.
| Priorità | Tipo AD | Dimensione | Inserire in |
|---|---|---|---|
| 1 (obbligatorio) | Flags (0x01) | 3 byte | Advertising PDU |
| 2 (filtraggio) | Service UUID (0x02–0x03) | 4+ byte | Advertising PDU |
| 3 (identificazione) | Local Name (0x08–0x09) | 2+ byte | Advertising PDU (abbreviato) |
| 4 (aggiuntivo) | TX Power Level (0x0A) | 3 byte | Scan Response |
| 5 (personalizzato) | Manufacturer Data (0xFF) | 4+ byte | Advertising PDU / Scan Response |
| 6 (dati completi) | UUID rimanenti | In base alla dimensione | Scan Response |
Il debug degli advertising data è una fase obbligatoria dello sviluppo di dispositivi BLE. Utilizzare nRF Connect (Nordic Semiconductor) o Wireshark con un analizzatore Bluetooth per visualizzare i dati grezzi del pacchetto. Verificare che tutti i tipi AD abbiano una lunghezza corretta, che la somma delle lunghezze non superi 31 byte e che i Flags siano impostati correttamente per il proprio caso d'uso.
Domande Frequenti
Cosa succede se la somma degli elementi AD supera 31 byte?
Lo stack Bluetooth Controller scarterà i dati che superano il limite o non invierà il pacchetto. Verificare la lunghezza totale degli elementi AD durante l'assemblaggio del pacchetto pubblicitario. Se i dati non ci stanno, spostare una parte in Scan Response o utilizzare Extended Advertising (BLE 5.0) con un limite di 251 byte.
È possibile trasmettere letture dei sensori in un pacchetto pubblicitario?
Sì, tramite Manufacturer Specific Data (0xFF). Impacchettare le letture in 4–8 byte: ad esempio, temperatura (2 byte in formato fixed-point), umidità (2 byte), tensione della batteria (2 byte). Questo approccio consente al Central di leggere i dati senza connettersi, risparmiando energia.
Quale tipo AD utilizzare per i servizi personalizzati?
Per i servizi personalizzati, utilizzare UUID a 128 bit (AD Type 0x06–0x07). Se l'UUID non entra nell'advertising PDU (16 byte per UUID), spostarlo in Scan Response o utilizzare il formato abbreviato Incomplete (0x06) per specificare solo il primo o i primi due UUID.
Qual è la differenza tra i tipi Complete e Incomplete di Service UUID?
Complete — nel pacchetto sono elencati tutti gli UUID dei servizi del dispositivo. Incomplete — solo una parte degli UUID (di solito i più importanti). Il Central non può fare affidamento su Incomplete come elenco completo, ma lo utilizza per un filtraggio rapido. L'elenco completo è disponibile dopo GATT Discovery.
Perché iOS non vede il mio dispositivo BLE?
Una causa comune è un Flags (0x01) errato. Assicurarsi che il bit BR/EDR Not Supported sia impostato. La seconda causa è l'assenza di Service UUID nel pacchetto pubblicitario (iOS filtra per UUID). La terza è che il dispositivo pubblicizza troppo raramente (iOS si aspetta un intervallo non superiore a 1000 ms).
Riepilogo
- Advertising Data sono dati strutturati in formato AD Structure (Length-Type-Value), trasmessi in pacchetti pubblicitari BLE.
- Un pacchetto pubblicitario standard contiene fino a 31 byte di dati; Scan Response fornisce altri 31 byte per informazioni aggiuntive.
- Flags (0x01) è un tipo AD obbligatorio che definisce le modalità di rilevamento. BR/EDR Not Supported è obbligatorio per i dispositivi BLE.
- Service UUID viene trasmesso in formato a 16 bit (2 byte) o 128 bit (16 byte), Complete o Incomplete a seconda dello spazio disponibile.
- Manufacturer Specific Data (0xFF) è un tipo flessibile per dati personalizzati, utilizzato in beacon iBeacon, Eddystone e dispositivi IoT.
- Strategia di impacchettamento: tipi AD obbligatori (Flags, Service UUID, nome abbreviato) nell'advertising PDU; quelli aggiuntivi in Scan Response.
- Eseguire il debug degli advertising data con nRF Connect o Wireshark — una fase di sviluppo obbligatoria per verificare la corretta struttura AD.
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