Advertising Data i BLE: struktur och datatyper
Advertising Data — är strukturerad data som en BLE-enhet sänder i reklampaket för att identifiera sig själv och sina tjänster. Bluetooth Core Specification 5.4 (2023) definierar formatet AD Structure: varje element innehåller längd (1 byte), typ (1 byte) och värde (upp till 29 byte). Specifikationen beskriver totalt över 30 AD-typer — från Flags och Local Name till Service UUID och Manufacturer Specific Data. Korrekt packning av advertising data är avgörande för enhetens kompatibilitet med iOS, Android och andra plattformar och bestämmer detekteringshastigheten och energieffektiviteten för reklamen.
Huvudpunkter
- AD Structure — dataformat i BLE-reklampaketet: längd (1 byte), typ (1 byte), värde (upp till 29 byte).
- Reklampaketet är begränsat till 31 byte, scan response — ytterligare 31 byte för kompletterande data.
- Flags (0x01) — obligatorisk AD-typ som definierar lägena LE Limited Discoverable och BR/EDR Not Supported.
- Service UUID sänds i förkortat (2 byte) eller fullt (16 byte) format.
- Manufacturer Specific Data (0xFF) — flexibel typ för alla anpassade data från tillverkaren.
Vad är Advertising Data?
Advertising Data — är en strukturerad uppsättning fält som en BLE-enhet sänder i reklampaket för att identifiera och beskriva sina kapaciteter. Central skannar kanalen, läser denna data och fattar ett beslut: ansluta till enheten, ignorera den eller begära ytterligare information via Scan Response.
Data är organiserad enligt principen TLV (Type-Length-Value): varje AD-element består av tre fält. Length (1 byte) — längden på Value + Type (dvs. elementets totala längd minus 1 byte för Length). Type (1 byte) — identifierare för datatypen från Bluetooth Assigned Numbers. Value (N byte) — innehåll beroende på typ.
Ett standard reklampaket kan innehålla upp till 31 byte AD-data. Om detta inte räcker används Scan Response (ytterligare 31 byte) eller Extended Advertising (BLE 5.0, upp till 251 byte). De första byten i reklampaketet är reserverade för PDU-huvudet och enhetens adress — AD-nyttolasten börjar vid en offset.
Format för AD Structure
Varje AD-element i reklampaketet börjar med fältet Length (1 byte). Värdet på Length anger antalet byte som följer efter Length — dvs. Type + Value. Till exempel innebär ett element med Length=3 att efter Length kommer 1 byte Type och 2 byte Value. Paketet slutar när summan av längderna för alla element når storleken på reklamdata.
| Fält | Storlek | Beskrivning |
|---|---|---|
| Length | 1 byte | Längden på Type + Value (exklusive Length) |
| Type (AD Type) | 1 byte | Identifierare för datatypen enligt Bluetooth SIG |
| Value | 0–29 byte | Data av en specifik typ |
Centralens parser läser sekvensen av AD-element från den första byten efter huvudet. Om Length=0 ignoreras elementet och parsern går vidare till nästa byte. Duplicerade AD-typer — flera element med samma Type i ett paket — är tillåtna, men Central kan beroende på stackimplementering endast bearbeta den första eller sista.
Viktig regel: summan av alla Length(+1) i paketet får inte överstiga storleken på reklamdata (31 byte för reklam-PDU). Om data inte får plats måste prioriteringar göras — vilka AD-typer som är kritiska för primär detektering och vilka som kan flyttas till Scan Response.
Flags (0x01): obligatorisk AD-typ
Flags (AD Type 0x01) — obligatoriskt element i reklampaketet för varje BLE-enhet. Det upptar 3 byte: Length (0x02), Type (0x01), Value (1 byte bitflaggor). Flaggorna definierar enhetens detekteringslägen och kapaciteter. Core Specification rekommenderar att inkludera Flags i varje reklampaket.
Huvudflaggor: LE Limited Discoverable Mode (bit 0) — enheten är detekterbar under begränsad tid, LE General Discoverable Mode (bit 1) — enheten är permanent detekterbar, BR/EDR Not Supported (bit 2) — enheten stöder endast LE, Simultaneous LE and BR/EDR (bit 3) — stöd för båda lägena. För rena BLE-enheter är kombinationen obligatorisk: LE General Discoverable + BR/EDR Not Supported.
Ett felaktigt Flags-värde är en vanlig orsak till att en enhet inte detekteras i iOS eller Android. Om flaggan BR/EDR Not Supported inte är inställd kan iOS till exempel försöka ansluta via klassisk Bluetooth istället för BLE. Kontrollera Flags-värdet vid felsökning av reklampaketet med en Bluetooth-analysator (nRF Connect, Wireshark).
Local Name: enhetens namn
Local Name (AD Type 0x08 eller 0x09) — det visade namnet på BLE-enheten. Typ 0x08 (Shortened Local Name) — förkortat namn, används när det fullständiga namnet inte får plats i reklampaketet. Typ 0x09 (Complete Local Name) — enhetens fullständiga namn. Maximal längd på namnet är 248 byte, men i ett standard reklampaket är inte mer än 28 byte tillgängligt.
Om enhetens namn överstiger det tillgängliga utrymmet i reklampaketet rekommenderas: placera det förkortade namnet i reklam-PDU (typ 0x08) och det fullständiga namnet i Scan Response (typ 0x09). iOS visar namnet från reklampaketet vid skanning och det fullständiga namnet blir tillgängligt efter anslutning eller Scan Response.
Vid val av enhetsnamn, beakta: ett för långt namn tar upp utrymme som skulle kunna användas för Service UUID eller annan viktig data. Rekommenderad namnlängd är 8–16 tecken. Undvik icke-standardiserade tecken och mellanslag — vissa BLE-stackar kan bearbeta dem felaktigt.
Service UUID: identifiering av tjänster
Service UUID (AD Type 0x02–0x07) — en av de viktigaste AD-typerna, som gör det möjligt för Central att avgöra vilka tjänster enheten tillhandahåller utan att ansluta till den. Bluetooth SIG definierar flera format för att sända UUID beroende på storlek: 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 byte) — standard Bluetooth SIG-tjänster, till exempel 0x180F (Battery Service), 0x180A (Device Information). 128-bit UUID (16 byte) — anpassade tjänster definierade av utvecklaren. 16-bit UUID upptar endast 4 byte i AD (Length + Type + 2 byte UUID), och 128-bit — 18 byte. Om flera anpassade UUID måste sändas i ett paket kan de inte få plats i 31 byte.
Det rekommenderas att använda typen Incomplete (0x02/0x04/0x06) om inte alla UUID för enheten sänds, utan endast de viktigaste för filtrering. Den fullständiga listan över UUID sänds via Scan Response eller GATT Discovery efter anslutning. Detta sparar utrymme i reklampaketet för andra AD-typer.
Manufacturer Specific Data
Manufacturer Specific Data (AD Type 0xFF) — den mest flexibla AD-typen, avsedd för att sända anpassade tillverkningsdata. De första 2 byten av Value är Company Identifier Code, tilldelad av Bluetooth SIG (till exempel 0x004C för Apple, 0x0075 för Samsung). De återstående byten är godtyckliga data i ett format som definierats av tillverkaren.
Apple använder Manufacturer Data för iBeacon: Company ID (0x004C), Beacontyp (0x0215), UUID (16 byte), Major (2 byte), Minor (2 byte), TX Power (1 byte). Google använder ett liknande format för Eddystone. Tillverkare av IoT-enheter placerar ofta sensoravläsningar eller enhetsstatus i Manufacturer Data.
js
// Analysera Manufacturer Specific Data på Central
function parseManufacturerData(data) {
const view = new DataView(data.buffer);
// Företagsidentifikationskod (första 2 byte)
const companyId = view.getUint16(0, true);
// Kontrollera efter Apple iBeacon
if (companyId === 0x004C) {
return parseIBeacon(view);
}
return null;
}Vid användning av Manufacturer Data är det viktigt att följa storleksbegränsningen: 31 byte för hela reklampaketet minus obligatoriska AD-typer. För Apple iBeacon upptar hela paketet 30 byte och lämnar endast utrymme för Flags (3 byte). För Eddystone — upp till 31 byte. Kompakta anpassade format kan inkludera temperatur, luftfuktighet eller tryck i 4–8 byte.
Strategi för datapackning
Korrekt packning av advertising data — är konsten att placera maximalt med användbar information i det begränsade utrymmet på 31 byte. Strategin beror på enhetens ändamål: en beacon behöver en identifierare, en IoT-sensor behöver avläsningar, en fitness-tracker behöver namn och tjänste-UUID. Allmän princip: ju snabbare Central måste fatta ett beslut, desto mer kritisk data bör finnas i reklam-PDU.
Rekommenderad strategi: reklam-PDU (första 31 byte) — Flags (3 byte) + ett 16-bit Service UUID (4 byte) + förkortat namn (upp till 12 tecken = 14 byte) + Manufacturer Data (upp till 10 byte). Scan Response (andra 31 byte) — fullständigt namn (återstoden) + ytterligare Service UUID + TX Power Level (3 byte). Denna fördelning gör det möjligt för Central att snabbt filtrera enheter efter UUID.
| Prioritet | AD-typ | Storlek | Placera i |
|---|---|---|---|
| 1 (obligatoriskt) | Flags (0x01) | 3 byte | Reklam-PDU |
| 2 (filtrering) | Service UUID (0x02–0x03) | 4+ byte | Reklam-PDU |
| 3 (identifiering) | Local Name (0x08–0x09) | 2+ byte | Reklam-PDU (förkortat) |
| 4 (ytterligare) | TX Power Level (0x0A) | 3 byte | Scan Response |
| 5 (anpassat) | Manufacturer Data (0xFF) | 4+ byte | Reklam-PDU / Scan Response |
| 6 (fullständig data) | Övriga UUID | Efter storlek | Scan Response |
Felsökning av advertising data är en obligatorisk fas i utvecklingen av BLE-enheter. Använd nRF Connect (Nordic Semiconductor) eller Wireshark med en Bluetooth-analysator för att visa rådata i paketet. Kontrollera att alla AD-typer har korrekt Length, att summan av längderna inte överstiger 31 byte och att Flags är korrekt inställda för ditt användningsscenario.
Vanliga frågor
Vad händer om summan av AD-element överstiger 31 byte?
Bluetooth Controller-stacken kommer att avvisa data som överstiger gränsen eller inte skicka paketet. Kontrollera den totala längden av AD-element vid sammansättning av reklampaketet. Om data inte får plats — flytta en del till Scan Response eller använd Extended Advertising (BLE 5.0) med en gräns på 251 byte.
Kan sensoravläsningar sändas i reklampaketet?
Ja, via Manufacturer Specific Data (0xFF). Packa avläsningarna i 4–8 byte: till exempel temperatur (2 byte i fixed-point-format), luftfuktighet (2 byte), batterispänning (2 byte). Detta tillvägagångssätt gör det möjligt för Central att läsa data utan anslutning, vilket sparar energi.
Vilken AD-typ ska användas för anpassade tjänster?
För anpassade tjänster, använd 128-bit UUID (AD Type 0x06–0x07). Om UUID inte får plats i reklam-PDU (16 byte för ett UUID), flytta det till Scan Response eller använd det förkortade formatet Incomplete (0x06) för att endast ange de första ett eller två UUID.
Vad är skillnaden mellan typerna Complete och Incomplete Service UUID?
Complete — i paketet listas alla UUID för enhetens tjänster. Incomplete — endast en del av UUID (vanligtvis de viktigaste). Central kan inte lita på Incomplete som en fullständig lista, men använder det för snabb filtrering. Den fullständiga listan är tillgänglig efter GATT Discovery.
Varför ser inte iOS min BLE-enhet?
Vanlig orsak — felaktig Flags (0x01). Se till att biten BR/EDR Not Supported är inställd. Andra orsaken — avsaknad av Service UUID i reklampaketet (iOS filtrerar efter UUID). Tredje — enheten sänder för sällan (iOS förväntar sig ett intervall på högst 1000 ms).
Sammanfattning
- Advertising Data — strukturerad data i AD Structure-format (Length-Type-Value), som sänds i BLE-reklampaket.
- Ett standard reklampaket innehåller upp till 31 byte data, Scan Response — ytterligare 31 byte för kompletterande information.
- Flags (0x01) — obligatorisk AD-typ som definierar detekteringslägen. För BLE-enheter är BR/EDR Not Supported obligatoriskt.
- Service UUID sänds i 16-bit (2 byte) eller 128-bit (16 byte) format, Complete eller Incomplete — beroende på tillgängligt utrymme.
- Manufacturer Specific Data (0xFF) — flexibel typ för anpassad data, som används i iBeacon, Eddystone-beacons och IoT-enheter.
- Packningsstrategi: obligatoriska AD-typer (Flags, Service UUID, förkortat namn) — i reklam-PDU, ytterligare — i Scan Response.
- Felsökning av advertising data via nRF Connect eller Wireshark — en obligatorisk utvecklingsfas för att kontrollera korrektheten av AD-strukturen.
Vi utvecklar en mobil applikation nyckelfärdigt
IT Sectr skapar iOS- och Android-applikationer för startups och företag sedan 2017. Vi ger dig råd och föreslår den bästa lösningen.
Läs också