Advertising Data in BLE: Was es ist, Struktur und Datentypen
Advertising Data sind strukturierte Daten, die ein BLE-Gerät in Werbepaketen sendet, um sich selbst und seine Dienste zu identifizieren. Die Bluetooth Core Specification 5.4 (2023) definiert das AD-Structure-Format: Jedes Element enthält eine Länge (1 Byte), einen Typ (1 Byte) und einen Wert (bis zu 29 Byte). Die Spezifikation beschreibt über 30 AD-Typen – von Flags und Local Name bis zu Service UUID und Manufacturer Specific Data. Die korrekte Paketierung von Advertising Data ist entscheidend für die Gerätekompatibilität mit iOS, Android und anderen Plattformen und bestimmt auch die Erkennungsgeschwindigkeit und die Energieeffizienz der Werbung.
Wichtige Punkte
- AD Structure ist das Datenformat in einem BLE-Werbepaket: Länge (1 Byte), Typ (1 Byte), Wert (bis zu 29 Byte).
- Das Werbepaket ist auf 31 Byte begrenzt, Scan Response bietet weitere 31 Byte für zusätzliche Daten.
- Flags (0x01) ist ein obligatorischer AD-Typ, der die Modi LE Limited Discoverable und BR/EDR Not Supported definiert.
- Service UUID wird im verkürzten (2 Byte) oder vollständigen (16 Byte) Format übertragen.
- Manufacturer Specific Data (0xFF) ist ein flexibler Typ für beliebige benutzerdefinierte Herstellerdaten.
Was ist Advertising Data?
Advertising Data ist eine strukturierte Menge von Feldern, die ein BLE-Gerät in Werbepaketen sendet, um sich selbst zu identifizieren und seine Fähigkeiten zu beschreiben. Der Central scannt die Luft, liest diese Daten und entscheidet, ob er eine Verbindung zum Gerät herstellt, es ignoriert oder zusätzliche Informationen über Scan Response anfordert.
Die Daten sind nach dem TLV-Prinzip (Type-Length-Value) organisiert: Jedes AD-Element besteht aus drei Feldern. Length (1 Byte) ist die Länge von Value + Type (d. h. die Gesamtlänge des Elements minus 1 Byte für Length). Type (1 Byte) ist der Datentyp-Identifikator aus Bluetooth Assigned Numbers. Value (N Byte) ist der Inhalt abhängig vom Typ.
Ein Standard-Werbepaket kann bis zu 31 Byte AD-Daten enthalten. Wenn das nicht ausreicht, werden Scan Response (weitere 31 Byte) oder Extended Advertising (BLE 5.0, bis zu 251 Byte) verwendet. Die ersten Bytes des Werbepakets sind für den PDU-Header und die Geräteadresse reserviert – die AD-Nutzlast beginnt bei einem Offset.
AD-Structure-Format
Jedes AD-Element im Werbepaket beginnt mit dem Length-Feld (1 Byte). Der Length-Wert gibt die Anzahl der Bytes nach Length an – also Type + Value. Beispielsweise bedeutet ein Element mit Length=3, dass nach Length 1 Byte Type und 2 Byte Value folgen. Das Paket endet, wenn die Summe aller Elementlängen die Werbedatengröße erreicht.
| Feld | Größe | Beschreibung |
|---|---|---|
| Length | 1 Byte | Länge von Type + Value (ohne Length) |
| Type (AD Type) | 1 Byte | Datentyp-Identifikator von Bluetooth SIG |
| Value | 0–29 Byte | Daten des angegebenen Typs |
Der Central-Parser liest die Sequenz der AD-Elemente beginnend mit dem ersten Byte nach dem Header. Wenn Length=0 ist, wird das Element ignoriert und der Parser fährt mit dem nächsten Byte fort. Doppelte AD-Typen – mehrere Elemente mit demselben Type in einem Paket – sind erlaubt, aber der Central verarbeitet je nach Stack-Implementierung möglicherweise nur das erste oder das letzte.
Eine wichtige Regel: Die Summe aller Length(+1) im Paket darf die Werbedatengröße (31 Byte für Advertising PDU) nicht überschreiten. Wenn die Daten nicht passen, müssen Prioritäten gesetzt werden – welche AD-Typen für die anfängliche Erkennung kritisch sind und welche in Scan Response verschoben werden können.
Flags (0x01): Obligatorischer AD-Typ
Flags (AD Type 0x01) ist ein obligatorisches Element im Werbepaket jedes BLE-Geräts. Es belegt 3 Byte: Length (0x02), Type (0x01), Value (1 Byte Bit-Flags). Die Flags definieren die Erkennungsmodi und Gerätefähigkeiten. Die Core Specification empfiehlt, Flags in jedes Werbepaket aufzunehmen.
Hauptflags: LE Limited Discoverable Mode (Bit 0) – das Gerät ist für begrenzte Zeit erkennbar, LE General Discoverable Mode (Bit 1) – das Gerät ist immer erkennbar, BR/EDR Not Supported (Bit 2) – das Gerät unterstützt nur LE, Simultaneous LE and BR/EDR (Bit 3) – unterstützt beide Modi. Für reine BLE-Geräte ist die Kombination LE General Discoverable + BR/EDR Not Supported obligatorisch.
Ein falscher Flags-Wert ist einer der häufigsten Gründe, warum ein Gerät unter iOS oder Android nicht erkannt wird. Wenn beispielsweise das Flag BR/EDR Not Supported nicht gesetzt ist, versucht iOS möglicherweise, eine Verbindung über klassisches Bluetooth statt BLE herzustellen. Überprüfen Sie den Flags-Wert beim Debuggen des Werbepakets mit einem Bluetooth-Analyzer (nRF Connect, Wireshark).
Local Name: Gerätename
Local Name (AD Type 0x08 oder 0x09) ist der angezeigte Name des BLE-Geräts. Typ 0x08 (Shortened Local Name) ist ein verkürzter Name, der verwendet wird, wenn der vollständige Name nicht in das Werbepaket passt. Typ 0x09 (Complete Local Name) ist der vollständige Gerätename. Die maximale Namenslänge beträgt 248 Byte, aber in einem Standard-Werbepaket sind nicht mehr als 28 Byte verfügbar.
Wenn der Gerätename den verfügbaren Platz im Werbepaket überschreitet, wird empfohlen: den verkürzten Namen in der Advertising PDU (Typ 0x08) und den vollständigen Namen in der Scan Response (Typ 0x09) zu platzieren. iOS zeigt den Namen aus dem Werbepaket während des Scannens an, während der vollständige Name nach der Verbindung oder Scan Response verfügbar ist.
Bei der Wahl eines Gerätenamens ist zu beachten: Ein zu langer Name belegt Platz, der für Service UUID oder andere wichtige Daten verwendet werden könnte. Die empfohlene Namenslänge beträgt 8–16 Zeichen. Vermeiden Sie nicht standardmäßige Zeichen und Leerzeichen – einige BLE-Stacks können sie möglicherweise nicht korrekt verarbeiten.
Service UUID: Dienstidentifikation
Service UUID (AD Type 0x02–0x07) ist einer der wichtigsten AD-Typen, der es dem Central ermöglicht, festzustellen, welche Dienste das Gerät bereitstellt, ohne eine Verbindung herzustellen. Bluetooth SIG definiert mehrere UUID-Übertragungsformate je nach Größe: 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) für Standard-Bluetooth-SIG-Dienste, z. B. 0x180F (Battery Service), 0x180A (Device Information). 128-Bit-UUID (16 Byte) für benutzerdefinierte Dienste, die vom Entwickler definiert werden. Eine 16-Bit-UUID belegt nur 4 Byte in AD (Length + Type + 2 Byte UUID), während eine 128-Bit-UUID 18 Byte belegt. Wenn mehrere benutzerdefinierte UUIDs in einem Paket übertragen werden müssen, passen sie möglicherweise nicht in 31 Byte.
Es wird empfohlen, den Typ Incomplete (0x02/0x04/0x06) zu verwenden, wenn nicht alle UUIDs des Geräts übertragen werden, sondern nur die für die Filterung wichtigsten. Die vollständige Liste der UUIDs wird nach der Verbindung über Scan Response oder GATT Discovery übertragen. Dies spart Platz im Werbepaket für andere AD-Typen.
Manufacturer Specific Data
Manufacturer Specific Data (AD Type 0xFF) ist der flexibelste AD-Typ, der für die Übertragung benutzerdefinierter Herstellerdaten entwickelt wurde. Die ersten 2 Byte von Value sind der Company Identifier Code, der von Bluetooth SIG zugewiesen wird (z. B. 0x004C für Apple, 0x0075 für Samsung). Die verbleibenden Bytes sind beliebige Daten in einem vom Hersteller definierten Format.
Apple verwendet Manufacturer Data für iBeacon: Company ID (0x004C), Beacon-Typ (0x0215), UUID (16 Byte), Major (2 Byte), Minor (2 Byte), TX Power (1 Byte). Google verwendet ein ähnliches Format für Eddystone. Hersteller von IoT-Geräten platzieren häufig Sensorwerte oder den Gerätestatus 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;
}Bei der Verwendung von Manufacturer Data ist die Größenbeschränkung zu beachten: 31 Byte für das gesamte Werbepaket abzüglich der obligatorischen AD-Typen. Für Apple iBeacon belegt das gesamte Paket 30 Byte, sodass nur Platz für Flags (3 Byte) bleibt. Für Eddystone – bis zu 31 Byte. Kompakte benutzerdefinierte Formate können Temperatur, Luftfeuchtigkeit oder Druck in 4–8 Byte enthalten.
Datenpaketierungsstrategie
Die korrekte Paketierung von Advertising Data ist die Kunst, die maximale Nutzinformation im begrenzten Raum von 31 Byte zu platzieren. Die Strategie hängt vom Gerätezweck ab: Ein Beacon benötigt eine Kennung, ein IoT-Sensor benötigt Messwerte, ein Fitness-Tracker benötigt einen Namen und Service-UUIDs. Das allgemeine Prinzip: Je schneller der Central eine Entscheidung treffen muss, desto kritischer sollten die Daten in der Advertising PDU sein.
Empfohlene Strategie: Advertising PDU (erste 31 Byte) – Flags (3 Byte) + eine 16-Bit-Service-UUID (4 Byte) + verkürzter Name (bis zu 12 Zeichen = 14 Byte) + Manufacturer Data (bis zu 10 Byte). Scan Response (zweite 31 Byte) – vollständiger Name (Rest) + zusätzliche Service-UUIDs + TX Power Level (3 Byte). Diese Verteilung ermöglicht es dem Central, Geräte schnell nach UUID zu filtern.
| Priorität | AD-Typ | Größe | Platzieren in |
|---|---|---|---|
| 1 (obligatorisch) | Flags (0x01) | 3 Byte | Advertising PDU |
| 2 (Filterung) | Service UUID (0x02–0x03) | 4+ Byte | Advertising PDU |
| 3 (Identifikation) | Local Name (0x08–0x09) | 2+ Byte | Advertising PDU (verkürzt) |
| 4 (zusätzlich) | TX Power Level (0x0A) | 3 Byte | Scan Response |
| 5 (benutzerdefiniert) | Manufacturer Data (0xFF) | 4+ Byte | Advertising PDU / Scan Response |
| 6 (vollständige Daten) | Übrige UUIDs | Nach Größe | Scan Response |
Das Debuggen von Advertising Data ist ein obligatorischer Schritt bei der BLE-Geräteentwicklung. Verwenden Sie nRF Connect (Nordic Semiconductor) oder Wireshark mit einem Bluetooth-Analyzer, um die Rohdaten des Pakets anzuzeigen. Überprüfen Sie, ob alle AD-Typen die korrekte Länge haben, ob die Summe der Längen 31 Byte nicht überschreitet und ob Flags für Ihren Anwendungsfall korrekt gesetzt sind.
Häufig gestellte Fragen
Was passiert, wenn die Summe der AD-Elemente 31 Byte überschreitet?
Der Bluetooth-Controller-Stack verwirft Daten, die das Limit überschreiten, oder sendet das Paket nicht. Überprüfen Sie die Gesamtlänge der AD-Elemente beim Zusammenstellen des Werbepakets. Wenn die Daten nicht passen, verschieben Sie einen Teil in Scan Response oder verwenden Sie Extended Advertising (BLE 5.0) mit einem Limit von 251 Byte.
Können Sensorwerte in einem Werbepaket übertragen werden?
Ja, über Manufacturer Specific Data (0xFF). Packen Sie die Messwerte in 4–8 Byte: zum Beispiel Temperatur (2 Byte im Festkommaformat), Luftfeuchtigkeit (2 Byte), Batteriespannung (2 Byte). Dieser Ansatz ermöglicht es dem Central, Daten ohne Verbindung zu lesen, was Energie spart.
Welchen AD-Typ sollte ich für benutzerdefinierte Dienste verwenden?
Für benutzerdefinierte Dienste verwenden Sie 128-Bit-UUID (AD Type 0x06–0x07). Wenn die UUID nicht in die Advertising PDU (16 Byte pro UUID) passt, verschieben Sie sie in Scan Response oder verwenden Sie das verkürzte Incomplete-Format (0x06), um nur die erste oder die ersten beiden UUIDs anzugeben.
Was ist der Unterschied zwischen Complete- und Incomplete-Service-UUID-Typen?
Complete – im Paket sind alle Service-UUIDs des Geräts aufgelistet. Incomplete – nur ein Teil der UUIDs (normalerweise die wichtigsten). Der Central kann sich nicht auf Incomplete als vollständige Liste verlassen, verwendet es aber für eine schnelle Filterung. Die vollständige Liste ist nach GATT Discovery verfügbar.
Warum sieht iOS mein BLE-Gerät nicht?
Eine häufige Ursache ist ein falscher Flags (0x01)-Wert. Stellen Sie sicher, dass das Bit BR/EDR Not Supported gesetzt ist. Die zweite Ursache ist das Fehlen einer Service UUID im Werbepaket (iOS filtert nach UUID). Die dritte Ursache ist, dass das Gerät zu selten wirbt (iOS erwartet ein Intervall von nicht mehr als 1000 ms).
Zusammenfassung
- Advertising Data sind strukturierte Daten im AD-Structure-Format (Length-Type-Value), die in BLE-Werbepaketen übertragen werden.
- Ein Standard-Werbepaket enthält bis zu 31 Byte Daten, Scan Response bietet weitere 31 Byte für zusätzliche Informationen.
- Flags (0x01) ist ein obligatorischer AD-Typ, der die Erkennungsmodi definiert. BR/EDR Not Supported ist für BLE-Geräte obligatorisch.
- Service UUID wird im 16-Bit- (2 Byte) oder 128-Bit-Format (16 Byte) übertragen, Complete oder Incomplete je nach verfügbarem Platz.
- Manufacturer Specific Data (0xFF) ist ein flexibler Typ für benutzerdefinierte Daten, der in iBeacon-, Eddystone-Beacons und IoT-Geräten verwendet wird.
- Paketierungsstrategie: Obligatorische AD-Typen (Flags, Service UUID, verkürzter Name) in der Advertising PDU, zusätzliche in der Scan Response.
- Debuggen Sie Advertising Data mit nRF Connect oder Wireshark – ein obligatorischer Entwicklungsschritt zur Überprüfung der korrekten AD-Struktur.
Wir entwickeln eine mobile Applikation schlüsselfertig
IT Sectr entwickelt seit 2017 iOS- und Android-Apps für Startups und Unternehmen. Wir beraten Sie und schlagen die beste Lösung vor.
Lesen Sie auch