Advertising Data în BLE: structură și tipuri de date
Advertising Data — sunt date structurate pe care dispozitivul BLE le transmite în pachete publicitare pentru a se identifica pe sine și serviciile sale. Bluetooth Core Specification 5.4 (2023) definește formatul AD Structure: fiecare element conține lungime (1 octet), tip (1 octet) și valoare (până la 29 de octeți). Specificația descrie în total peste 30 de tipuri AD — de la Flags și Local Name până la Service UUID și Manufacturer Specific Data. Împachetarea corectă a advertising data este critică pentru compatibilitatea dispozitivului cu iOS, Android și alte platforme și determină viteza de detectare și eficiența energetică a publicității.
Puncte cheie
- AD Structure — formatul datelor în pachetul publicitar BLE: lungime (1 octet), tip (1 octet), valoare (până la 29 de octeți).
- Pachetul publicitar este limitat la 31 de octeți, scan response — încă 31 de octeți pentru date suplimentare.
- Flags (0x01) — tip AD obligatoriu care definește modurile LE Limited Discoverable și BR/EDR Not Supported.
- Service UUID este transmis în format scurt (2 octeți) sau complet (16 octeți).
- Manufacturer Specific Data (0xFF) — tip flexibil pentru orice date personalizate ale producătorului.
Ce sunt Advertising Data?
Advertising Data — este un set structurat de câmpuri pe care dispozitivul BLE le transmite în pachete publicitare pentru a-și identifica și descrie capacitățile. Central, scanând canalul, citește aceste date și ia o decizie: să se conecteze la dispozitiv, să îl ignore sau să solicite informații suplimentare prin Scan Response.
Datele sunt organizate după principiul TLV (Type-Length-Value): fiecare element AD constă din trei câmpuri. Length (1 octet) — lungimea Value + Type (adică lungimea totală a elementului minus 1 octet pentru Length). Type (1 octet) — identificatorul tipului de date din Bluetooth Assigned Numbers. Value (N octeți) — conținutul în funcție de tip.
Pachetul publicitar standard poate conține până la 31 de octeți de date AD. Dacă acest lucru nu este suficient, se utilizează Scan Response (încă 31 de octeți) sau Extended Advertising (BLE 5.0, până la 251 de octeți). Primii octeți ai pachetului publicitar sunt rezervați pentru antetul PDU și adresa dispozitivului — încărcătura utilă AD începe de la un offset.
Formatul AD Structure
Fiecare element AD din pachetul publicitar începe cu câmpul Length (1 octet). Valoarea Length indică numărul de octeți care urmează după Length — adică Type + Value. De exemplu, un element cu Length=3 înseamnă că după Length urmează 1 octet Type și 2 octeți Value. Pachetul se termină când suma lungimilor tuturor elementelor atinge dimensiunea datelor publicitare.
| Câmp | Dimensiune | Descriere |
|---|---|---|
| Length | 1 octet | Lungimea Type + Value (fără Length) |
| Type (AD Type) | 1 octet | Identificatorul tipului de date conform Bluetooth SIG |
| Value | 0–29 octeți | Date de tip specific |
Parserul Central citește secvența elementelor AD începând cu primul octet după antet. Dacă Length=0, elementul este ignorat, iar parserul trece la următorul octet. Tipurile AD duplicate — mai multe elemente cu același Type într-un singur pachet — sunt permise, dar Central poate procesa doar primul sau ultimul în funcție de implementarea stivei.
Regulă importantă: suma tuturor Length(+1) din pachet nu trebuie să depășească dimensiunea datelor publicitare (31 de octeți pentru PDU publicitar). Dacă datele nu încap, trebuie stabilite priorități — care tipuri AD sunt critice pentru detectarea primară și care pot fi mutate în Scan Response.
Flags (0x01): tipul AD obligatoriu
Flags (AD Type 0x01) — element obligatoriu în pachetul publicitar al oricărui dispozitiv BLE. Ocupă 3 octeți: Length (0x02), Type (0x01), Value (1 octet de fanioane binare). Fanioanele definesc modurile de detectare și capacitățile dispozitivului. Core Specification recomandă includerea Flags în fiecare pachet publicitar.
Fanioanele principale: LE Limited Discoverable Mode (bit 0) — dispozitivul este disponibil pentru detectare pentru o perioadă limitată, LE General Discoverable Mode (bit 1) — dispozitivul este disponibil permanent, BR/EDR Not Supported (bit 2) — dispozitivul suportă doar LE, Simultaneous LE and BR/EDR (bit 3) — suport pentru ambele moduri. Pentru dispozitivele exclusiv BLE, combinația obligatorie este: LE General Discoverable + BR/EDR Not Supported.
Valoarea incorectă a Flags — una dintre cauzele frecvente pentru care dispozitivul nu este detectat în iOS sau Android. De exemplu, dacă fanionul BR/EDR Not Supported nu este setat, iOS poate încerca să se conecteze prin Bluetooth clasic în loc de BLE. Verificați valoarea Flags când depanați pachetul publicitar cu un analizor Bluetooth (nRF Connect, Wireshark).
Local Name: numele dispozitivului
Local Name (AD Type 0x08 sau 0x09) — numele afișat al dispozitivului BLE. Tip 0x08 (Shortened Local Name) — nume scurtat, utilizat când numele complet nu încape în pachetul publicitar. Tip 0x09 (Complete Local Name) — numele complet al dispozitivului. Lungimea maximă a numelui este de 248 de octeți, dar în pachetul publicitar standard nu sunt disponibili mai mult de 28 de octeți.
Dacă numele dispozitivului depășește spațiul disponibil în pachetul publicitar, se recomandă: plasați numele scurtat în PDU publicitar (tip 0x08), iar numele complet în Scan Response (tip 0x09). iOS afișează numele din pachetul publicitar la scanare, iar numele complet devine disponibil după conectare sau Scan Response.
La alegerea numelui dispozitivului, luați în considerare: un nume prea lung ocupă spațiu care ar putea fi folosit pentru Service UUID sau alte date importante. Lungimea recomandată a numelui este de 8–16 caractere. Evitați caracterele non-standard și spațiile — unele stive BLE le pot procesa incorect.
Service UUID: identificarea serviciilor
Service UUID (AD Type 0x02–0x07) — unul dintre cele mai importante tipuri AD, care permite Central să determine ce servicii oferă dispozitivul fără a se conecta la el. Bluetooth SIG definește mai multe formate de transmitere a UUID în funcție de dimensiune: 0x02 (Incomplete 16-bit), 0x03 (Complete 16-bit), 0x04 (Incomplete 32-bit), 0x05 (Complete 32-bit), 0x06 (Incomplete 128-bit), 0x07 (Complete 128-bit).
16-bit UUID (2 octeți) — servicii standard Bluetooth SIG, de exemplu 0x180F (Battery Service), 0x180A (Device Information). 128-bit UUID (16 octeți) — servicii personalizate, definite de dezvoltator. 16-bit UUID ocupă doar 4 octeți în AD (Length + Type + 2 octeți UUID), iar 128-bit — 18 octeți. Dacă într-un singur pachet trebuie transmise mai multe UUID personalizate, este posibil să nu încapă în 31 de octeți.
Se recomandă utilizarea tipului Incomplete (0x02/0x04/0x06) dacă nu sunt transmise toate UUID-urile dispozitivului, ci doar cele mai importante pentru filtrare. Lista completă de UUID se transmite prin Scan Response sau GATT Discovery după conectare. Aceasta economisește spațiu în pachetul publicitar pentru alte tipuri AD.
Manufacturer Specific Data
Manufacturer Specific Data (AD Type 0xFF) — cel mai flexibil tip AD, destinat transmiterii datelor personalizate ale producătorului. Primii 2 octeți ai Value — Company Identifier Code, atribuit de Bluetooth SIG (de exemplu, 0x004C pentru Apple, 0x0075 pentru Samsung). Octeții rămași sunt date arbitrare într-un format definit de producător.
Apple utilizează Manufacturer Data pentru iBeacon: Company ID (0x004C), tip Beacon (0x0215), UUID (16 octeți), Major (2 octeți), Minor (2 octeți), TX Power (1 octet). Google utilizează un format similar pentru Eddystone. Producătorii de dispozitive IoT plasează adesea în Manufacturer Data citiri ale senzorilor sau starea dispozitivului.
js
// Analizează Manufacturer Specific Data pe Central
function parseManufacturerData(data) {
const view = new DataView(data.buffer);
// Codul de identificare al companiei (primii 2 octeți)
const companyId = view.getUint16(0, true);
// Verifică prezența Apple iBeacon
if (companyId === 0x004C) {
return parseIBeacon(view);
}
return null;
}La utilizarea Manufacturer Data, este important să se respecte limitarea de dimensiune: 31 de octeți pentru întregul pachet publicitar minus tipurile AD obligatorii. Pentru Apple iBeacon, întregul pachet ocupă 30 de octeți, lăsând loc doar pentru Flags (3 octeți). Pentru Eddystone — până la 31 de octeți. Formatele personalizate compacte pot include temperatură, umiditate sau presiune în 4–8 octeți.
Strategia de împachetare a datelor
Împachetarea corectă a advertising data — este arta de a plasa maximum de informații utile în spațiul limitat de 31 de octeți. Strategia depinde de destinația dispozitivului: un beacon are nevoie de un identificator, un senzor IoT — de citiri, un tracker de fitness — de nume și UUID de servicii. Principiul general: cu cât mai repede trebuie să ia o decizie Central, cu atât datele mai critice trebuie să fie în PDU publicitar.
Strategia recomandată: PDU publicitar (primii 31 de octeți) — Flags (3 octeți) + un 16-bit Service UUID (4 octeți) + nume scurtat (până la 12 caractere = 14 octeți) + Manufacturer Data (până la 10 octeți). Scan Response (a doua parte de 31 de octeți) — numele complet (restul) + Service UUID suplimentare + TX Power Level (3 octeți). Această distribuție permite Central să filtreze rapid dispozitivele după UUID.
| Prioritate | Tip AD | Dimensiune | Plasați în |
|---|---|---|---|
| 1 (obligatoriu) | Flags (0x01) | 3 octeți | PDU publicitar |
| 2 (filtrare) | Service UUID (0x02–0x03) | 4+ octeți | PDU publicitar |
| 3 (identificare) | Local Name (0x08–0x09) | 2+ octeți | PDU publicitar (scurtat) |
| 4 (suplimentar) | TX Power Level (0x0A) | 3 octeți | Scan Response |
| 5 (personalizat) | Manufacturer Data (0xFF) | 4+ octeți | PDU publicitar / Scan Response |
| 6 (date complete) | Alte UUID-uri | După dimensiune | Scan Response |
Depanarea advertising data — o etapă obligatorie în dezvoltarea dispozitivelor BLE. Utilizați nRF Connect (Nordic Semiconductor) sau Wireshark cu un analizor Bluetooth pentru a vizualiza datele brute ale pachetului. Verificați că toate tipurile AD au Length corect, că suma lungimilor nu depășește 31 de octeți și că Flags sunt setate corect pentru scenariul dvs. de utilizare.
Întrebări frecvente
Ce se întâmplă dacă suma elementelor AD depășește 31 de octeți?
Stiva Bluetooth Controller va respinge datele care depășesc limita sau nu va trimite pachetul. Verificați lungimea totală a elementelor AD la asamblarea pachetului publicitar. Dacă datele nu încap — transferați o parte în Scan Response sau utilizați Extended Advertising (BLE 5.0) cu o limită de 251 de octeți.
Pot fi transmise citirile senzorilor în pachetul publicitar?
Da, prin Manufacturer Specific Data (0xFF). Împachetați citirile în 4–8 octeți: de exemplu, temperatura (2 octeți în format fixed-point), umiditatea (2 octeți), tensiunea bateriei (2 octeți). Această abordare permite Central să citească datele fără conexiune, economisind energie.
Ce tip AD să folosesc pentru servicii personalizate?
Pentru servicii personalizate, utilizați 128-bit UUID (AD Type 0x06–0x07). Dacă UUID nu încape în PDU publicitar (16 octeți pentru un UUID), transferați-l în Scan Response sau utilizați formatul scurtat Incomplete (0x06) pentru a indica doar primele unul-două UUID-uri.
Care este diferența dintre tipurile Complete și Incomplete Service UUID?
Complete — în pachet sunt listate toate UUID-urile serviciilor dispozitivului. Incomplete — doar o parte din UUID-uri (de obicei cele mai importante). Central nu se poate baza pe Incomplete ca pe o listă completă, dar îl folosește pentru filtrare rapidă. Lista completă este disponibilă după GATT Discovery.
De ce iOS nu vede dispozitivul meu BLE?
Cauza frecventă — Flags (0x01) incorect. Asigurați-vă că bitul BR/EDR Not Supported este setat. A doua cauză — absența Service UUID în pachetul publicitar (iOS filtrează după UUID). A treia — dispozitivul face publicitate prea rar (iOS așteaptă un interval de cel mult 1000 ms).
Rezumat
- Advertising Data — date structurate în format AD Structure (Length-Type-Value), transmise în pachetele publicitare BLE.
- Pachetul publicitar standard conține până la 31 de octeți de date, Scan Response — încă 31 de octeți pentru informații suplimentare.
- Flags (0x01) — tip AD obligatoriu care definește modurile de detectare. Pentru dispozitivele BLE, BR/EDR Not Supported este obligatoriu.
- Service UUID este transmis în format 16-bit (2 octeți) sau 128-bit (16 octeți), Complete sau Incomplete — în funcție de spațiul disponibil.
- Manufacturer Specific Data (0xFF) — tip flexibil pentru date personalizate, utilizat în beacon-urile iBeacon, Eddystone și dispozitivele IoT.
- Strategia de împachetare: tipurile AD obligatorii (Flags, Service UUID, nume scurtat) — în PDU publicitar, cele suplimentare — în Scan Response.
- Depanarea advertising data prin nRF Connect sau Wireshark — etapă obligatorie de dezvoltare pentru verificarea corectitudinii structurii AD.
Vom dezvolta o aplicație mobilă la cheie
IT Sectr creează aplicații iOS și Android pentru startup-uri și afaceri din 2017. Vă vom consilia și vă vom propune cea mai bună soluție.
Citiți și