Advertising Data in BLE: structuur en gegevenstypen
Advertising Data — zijn gestructureerde gegevens die een BLE-apparaat in advertentiepakketten verzendt om zichzelf en zijn diensten te identificeren. Bluetooth Core Specification 5.4 (2023) definieert het AD Structure-formaat: elk element bevat een lengte (1 byte), type (1 byte) en waarde (tot 29 bytes). De specificatie beschrijft in totaal meer dan 30 AD-typen — van Flags en Local Name tot Service UUID en Manufacturer Specific Data. Het correct inpakken van advertising data is cruciaal voor de compatibiliteit van het apparaat met iOS, Android en andere platformen en bepaalt de detectiesnelheid en energie-efficiëntie van de advertentie.
Belangrijkste punten
- AD Structure — gegevensformaat in het BLE-advertentiepakket: lengte (1 byte), type (1 byte), waarde (tot 29 bytes).
- Het advertentiepakket is beperkt tot 31 bytes, scan response — nog 31 bytes voor aanvullende gegevens.
- Flags (0x01) — verplicht AD-type dat de modi LE Limited Discoverable en BR/EDR Not Supported definieert.
- Service UUID wordt in ingekorte (2 bytes) of volledige (16 bytes) formaat verzonden.
- Manufacturer Specific Data (0xFF) — flexibel type voor alle aangepaste gegevens van de fabrikant.
Wat is Advertising Data?
Advertising Data — is een gestructureerde set velden die een BLE-apparaat in advertentiepakketten verzendt om zijn mogelijkheden te identificeren en te beschrijven. Central scant het kanaal, leest deze gegevens en neemt een beslissing: verbinding maken met het apparaat, het negeren of om aanvullende informatie vragen via Scan Response.
De gegevens zijn georganiseerd volgens het TLV (Type-Length-Value)-principe: elk AD-element bestaat uit drie velden. Length (1 byte) — lengte van Value + Type (d.w.z. de totale lengte van het element minus 1 byte voor Length). Type (1 byte) — identificatie van het gegevenstype uit Bluetooth Assigned Numbers. Value (N bytes) — inhoud afhankelijk van het type.
Een standaard advertentiepakket kan tot 31 bytes aan AD-gegevens bevatten. Als dit niet voldoende is, wordt Scan Response (nog 31 bytes) of Extended Advertising (BLE 5.0, tot 251 bytes) gebruikt. De eerste bytes van het advertentiepakket zijn gereserveerd voor de PDU-header en het apparaatadres — de AD-nuttige lading begint vanaf een offset.
AD Structure-formaat
Elk AD-element in het advertentiepakket begint met het veld Length (1 byte). De waarde van Length geeft het aantal bytes na Length aan — dus Type + Value. Een element met Length=3 betekent bijvoorbeeld dat na Length 1 byte Type en 2 bytes Value komen. Het pakket eindigt wanneer de som van de lengtes van alle elementen de grootte van de advertentiegegevens bereikt.
| Veld | Grootte | Beschrijving |
|---|---|---|
| Length | 1 byte | Lengte van Type + Value (exclusief Length) |
| Type (AD Type) | 1 byte | Identificatie van het gegevenstype volgens Bluetooth SIG |
| Value | 0–29 bytes | Gegevens van een specifiek type |
De parser van Central leest de reeks AD-elementen beginnend bij de eerste byte na de header. Als Length=0 is, wordt het element genegeerd en gaat de parser naar de volgende byte. Gedupliceerde AD-typen — meerdere elementen met hetzelfde Type in één pakket — zijn toegestaan, maar Central kan afhankelijk van de stackimplementatie alleen de eerste of laatste verwerken.
Belangrijke regel: de som van alle Length(+1) in het pakket mag de grootte van de advertentiegegevens (31 bytes voor advertentie-PDU) niet overschrijden. Als de gegevens niet passen, moeten prioriteiten worden gesteld — welke AD-typen van cruciaal belang zijn voor primaire detectie en welke naar Scan Response kunnen worden verplaatst.
Flags (0x01): verplicht AD-type
Flags (AD Type 0x01) — een verplicht element in het advertentiepakket van elk BLE-apparaat. Het neemt 3 bytes in beslag: Length (0x02), Type (0x01), Value (1 byte bitvlaggen). De vlaggen bepalen de detectiemodi en mogelijkheden van het apparaat. Core Specification beveelt aan om Flags in elk advertentiepakket op te nemen.
Belangrijkste vlaggen: LE Limited Discoverable Mode (bit 0) — apparaat is gedurende beperkte tijd detecteerbaar, LE General Discoverable Mode (bit 1) — apparaat is permanent detecteerbaar, BR/EDR Not Supported (bit 2) — apparaat ondersteunt alleen LE, Simultaneous LE and BR/EDR (bit 3) — ondersteuning voor beide modi. Voor puur BLE-apparaten is de combinatie verplicht: LE General Discoverable + BR/EDR Not Supported.
Een onjuiste Flags-waarde is een veelvoorkomende reden waarom een apparaat niet wordt gedetecteerd in iOS of Android. Als de vlag BR/EDR Not Supported bijvoorbeeld niet is ingesteld, kan iOS proberen verbinding te maken via klassieke Bluetooth in plaats van BLE. Controleer de Flags-waarde bij het debuggen van het advertentiepakket met een Bluetooth-analysator (nRF Connect, Wireshark).
Local Name: apparaatnaam
Local Name (AD Type 0x08 of 0x09) — de weergegeven naam van het BLE-apparaat. Type 0x08 (Shortened Local Name) — ingekorte naam, gebruikt wanneer de volledige naam niet in het advertentiepakket past. Type 0x09 (Complete Local Name) — volledige naam van het apparaat. De maximale lengte van de naam is 248 bytes, maar in een standaard advertentiepakket is niet meer dan 28 bytes beschikbaar.
Als de apparaatnaam de beschikbare ruimte in het advertentiepakket overschrijdt, wordt aanbevolen: plaats de ingekorte naam in de advertentie-PDU (type 0x08) en de volledige naam in Scan Response (type 0x09). iOS toont de naam uit het advertentiepakket tijdens het scannen en de volledige naam wordt beschikbaar na verbinding of Scan Response.
Houd bij het kiezen van een apparaatnaam rekening met het volgende: een te lange naam neemt ruimte in beslag die gebruikt zou kunnen worden voor Service UUID of andere belangrijke gegevens. Aanbevolen naam lengte is 8–16 tekens. Vermijd niet-standaard tekens en spaties — sommige BLE-stacks kunnen ze onjuist verwerken.
Service UUID: identificatie van diensten
Service UUID (AD Type 0x02–0x07) — een van de belangrijkste AD-typen, waarmee Central kan bepalen welke diensten het apparaat biedt zonder er verbinding mee te maken. Bluetooth SIG definieert verschillende formaten voor het verzenden van UUID afhankelijk van de grootte: 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 bytes) — standaard Bluetooth SIG-diensten, bijvoorbeeld 0x180F (Battery Service), 0x180A (Device Information). 128-bit UUID (16 bytes) — aangepaste diensten gedefinieerd door de ontwikkelaar. 16-bit UUID neemt slechts 4 bytes in AD (Length + Type + 2 bytes UUID), en 128-bit — 18 bytes. Als meerdere aangepaste UUID's in één pakket moeten worden verzonden, passen ze mogelijk niet in 31 bytes.
Het wordt aanbevolen om het type Incomplete (0x02/0x04/0x06) te gebruiken als niet alle UUID's van het apparaat worden verzonden, maar alleen de belangrijkste voor filtering. De volledige lijst met UUID's wordt via Scan Response of GATT Discovery na verbinding verzonden. Dit bespaart ruimte in het advertentiepakket voor andere AD-typen.
Manufacturer Specific Data
Manufacturer Specific Data (AD Type 0xFF) — het meest flexibele AD-type, bedoeld voor het verzenden van aangepaste fabrikantgegevens. De eerste 2 bytes van Value zijn Company Identifier Code, toegewezen door Bluetooth SIG (bijvoorbeeld 0x004C voor Apple, 0x0075 voor Samsung). De overige bytes zijn willekeurige gegevens in een door de fabrikant gedefinieerd formaat.
Apple gebruikt Manufacturer Data voor iBeacon: Company ID (0x004C), Beacon-type (0x0215), UUID (16 bytes), Major (2 bytes), Minor (2 bytes), TX Power (1 byte). Google gebruikt een vergelijkbaar formaat voor Eddystone. Fabrikanten van IoT-apparaten plaatsen vaak sensoruitlezingen of apparaatstatus in Manufacturer Data.
js
// Parseer Manufacturer Specific Data op Central
function parseManufacturerData(data) {
const view = new DataView(data.buffer);
// Bedrijfsidentificatiecode (eerste 2 bytes)
const companyId = view.getUint16(0, true);
// Controleer op Apple iBeacon
if (companyId === 0x004C) {
return parseIBeacon(view);
}
return null;
}Bij gebruik van Manufacturer Data is het belangrijk om de groottebeperking in acht te nemen: 31 bytes voor het hele advertentiepakket minus verplichte AD-typen. Voor Apple iBeacon neemt het hele pakket 30 bytes in beslag, waardoor er alleen ruimte overblijft voor Flags (3 bytes). Voor Eddystone — tot 31 bytes. Compacte aangepaste formaten kunnen temperatuur, vochtigheid of druk bevatten in 4–8 bytes.
Strategie voor gegevensinpakking
Het correct inpakken van advertising data — is de kunst om maximaal nuttige informatie in de beperkte ruimte van 31 bytes te plaatsen. De strategie hangt af van het doel van het apparaat: een beacon heeft een identificatie nodig, een IoT-sensor heeft uitlezingen nodig, een fitnesstracker heeft een naam en service-UUID's nodig. Algemeen principe: hoe sneller Central een beslissing moet nemen, hoe kritischer de gegevens in de advertentie-PDU moeten zijn.
Aanbevolen strategie: advertentie-PDU (eerste 31 bytes) — Flags (3 bytes) + één 16-bit Service UUID (4 bytes) + ingekorte naam (tot 12 tekens = 14 bytes) + Manufacturer Data (tot 10 bytes). Scan Response (tweede 31 bytes) — volledige naam (rest) + extra Service UUID's + TX Power Level (3 bytes). Deze verdeling stelt Central in staat om apparaten snel op UUID te filteren.
| Prioriteit | AD-type | Grootte | Plaatsen in |
|---|---|---|---|
| 1 (verplicht) | Flags (0x01) | 3 bytes | Advertentie-PDU |
| 2 (filteren) | Service UUID (0x02–0x03) | 4+ bytes | Advertentie-PDU |
| 3 (identificatie) | Local Name (0x08–0x09) | 2+ bytes | Advertentie-PDU (ingekort) |
| 4 (aanvullend) | TX Power Level (0x0A) | 3 bytes | Scan Response |
| 5 (aangepast) | Manufacturer Data (0xFF) | 4+ bytes | Advertentie-PDU / Scan Response |
| 6 (volledige gegevens) | Overige UUID's | Op grootte | Scan Response |
Het debuggen van advertising data is een verplichte fase in de ontwikkeling van BLE-apparaten. Gebruik nRF Connect (Nordic Semiconductor) of Wireshark met een Bluetooth-analysator om de ruwe pakketgegevens te bekijken. Controleer of alle AD-typen de juiste Length hebben, of de som van de lengtes niet groter is dan 31 bytes en of Flags correct zijn ingesteld voor uw gebruiksscenario.
Veelgestelde vragen
Wat gebeurt er als de som van AD-elementen meer dan 31 bytes bedraagt?
De Bluetooth Controller-stack zal gegevens die de limiet overschrijden afwijzen of het pakket niet verzenden. Controleer de totale lengte van AD-elementen bij het samenstellen van het advertentiepakket. Als de gegevens niet passen — verplaats een deel naar Scan Response of gebruik Extended Advertising (BLE 5.0) met een limiet van 251 bytes.
Kunnen sensoruitlezingen worden verzonden in het advertentiepakket?
Ja, via Manufacturer Specific Data (0xFF). Pak de uitlezingen in 4–8 bytes: bijvoorbeeld temperatuur (2 bytes in fixed-point formaat), vochtigheid (2 bytes), batterijspanning (2 bytes). Deze aanpak stelt Central in staat om gegevens te lezen zonder verbinding, waardoor energie wordt bespaard.
Welk AD-type moet worden gebruikt voor aangepaste diensten?
Gebruik voor aangepaste diensten 128-bit UUID (AD Type 0x06–0x07). Als UUID niet past in de advertentie-PDU (16 bytes voor één UUID), verplaats het dan naar Scan Response of gebruik het ingekorte formaat Incomplete (0x06) om alleen de eerste één of twee UUID's aan te geven.
Wat is het verschil tussen Complete en Incomplete Service UUID-typen?
Complete — in het pakket worden alle UUID's van de diensten van het apparaat vermeld. Incomplete — slechts een deel van de UUID's (meestal de belangrijkste). Central kan niet op Incomplete vertrouwen als volledige lijst, maar gebruikt het voor snelle filtering. De volledige lijst is beschikbaar na GATT Discovery.
Waarom ziet iOS mijn BLE-apparaat niet?
Een veelvoorkomende oorzaak is een onjuiste Flags (0x01). Zorg ervoor dat de bit BR/EDR Not Supported is ingesteld. De tweede oorzaak is het ontbreken van Service UUID in het advertentiepakket (iOS filtert op UUID). De derde — het apparaat adverteert te zelden (iOS verwacht een interval van niet meer dan 1000 ms).
Samenvatting
- Advertising Data — gestructureerde gegevens in AD Structure-formaat (Length-Type-Value), verzonden in BLE-advertentiepakketten.
- Een standaard advertentiepakket bevat tot 31 bytes aan gegevens, Scan Response — nog 31 bytes voor aanvullende informatie.
- Flags (0x01) — verplicht AD-type dat de detectiemodi definieert. Voor BLE-apparaten is BR/EDR Not Supported verplicht.
- Service UUID wordt verzonden in 16-bit (2 bytes) of 128-bit (16 bytes) formaat, Complete of Incomplete — afhankelijk van de beschikbare ruimte.
- Manufacturer Specific Data (0xFF) — flexibel type voor aangepaste gegevens, gebruikt in iBeacon, Eddystone beacons en IoT-apparaten.
- Inpakstrategie: verplichte AD-typen (Flags, Service UUID, ingekorte naam) — in advertentie-PDU, aanvullende — in Scan Response.
- Het debuggen van advertising data via nRF Connect of Wireshark — een verplichte ontwikkelingsfase om de juistheid van de AD-structuur te controleren.
We ontwikkelen een mobiele applicatie turnkey
IT Sectr creëert sinds 2017 iOS- en Android-applicaties voor startups en bedrijven. We adviseren u en stellen de beste oplossing voor.
Lees ook