Advertising Data w BLE: struktura i typy danych
Advertising Data — to strukturyzowane dane, które urządzenie BLE przesyła w pakietach reklamowych w celu identyfikacji siebie i swoich usług. Bluetooth Core Specification 5.4 (2023) definiuje format AD Structure: każdy element zawiera długość (1 bajt), typ (1 bajt) i wartość (do 29 bajtów). Łącznie specyfikacja opisuje ponad 30 typów AD — od Flags i Local Name po Service UUID i Manufacturer Specific Data. Prawidłowe pakowanie advertising data jest krytyczne dla kompatybilności urządzenia z iOS, Android i innymi platformami, a także określa szybkość wykrywania i efektywność energetyczną reklamy.
Najważniejsze
- AD Structure — format danych w pakiecie reklamowym BLE: długość (1 bajt), typ (1 bajt), wartość (do 29 bajtów).
- Pakiet reklamowy jest ograniczony do 31 bajtów, scan response — kolejne 31 bajtów na dodatkowe dane.
- Flags (0x01) — obowiązkowy typ AD, określający tryby LE Limited Discoverable i BR/EDR Not Supported.
- Service UUID jest przesyłany w skróconym (2 bajty) lub pełnym (16 bajtów) formacie.
- Manufacturer Specific Data (0xFF) — elastyczny typ dla dowolnych danych producenta.
Czym są Advertising Data?
Advertising Data — to strukturyzowany zestaw pól, które urządzenie BLE przesyła w pakietach reklamowych w celu identyfikacji i opisu swoich możliwości. Central, skanując kanał, odczytuje te dane i podejmuje decyzję: podłączyć się do urządzenia, zignorować je lub poprosić o dodatkowe informacje przez Scan Response.
Dane są zorganizowane według zasady TLV (Type-Length-Value): każdy element AD składa się z trzech pól. Length (1 bajt) — długość Value + Type (czyli całkowita długość elementu minus 1 bajt na Length). Type (1 bajt) — identyfikator typu danych z Bluetooth Assigned Numbers. Value (N bajtów) — zawartość zależna od typu.
Standardowy pakiet reklamowy może zawierać do 31 bajtów danych AD. Jeśli to nie wystarcza, używany jest Scan Response (kolejne 31 bajtów) lub Extended Advertising (BLE 5.0, do 251 bajtów). Przy czym pierwsze bajty pakietu reklamowego są zarezerwowane na nagłówek PDU i adres urządzenia — ładunek AD zaczyna się od przesunięcia.
Format AD Structure
Każdy element AD w pakiecie reklamowym zaczyna się od pola Length (1 bajt). Wartość Length wskazuje liczbę bajtów następujących po Length — czyli Type + Value. Na przykład element z Length=3 oznacza, że po Length następuje 1 bajt Type i 2 bajty Value. Pakiet kończy się, gdy suma długości wszystkich elementów osiągnie rozmiar danych reklamowych.
| Pole | Rozmiar | Opis |
|---|---|---|
| Length | 1 bajt | Długość Type + Value (nie wliczając Length) |
| Type (AD Type) | 1 bajt | Identyfikator typu danych według Bluetooth SIG |
| Value | 0–29 bajtów | Dane określonego typu |
Parser Central odczytuje sekwencję elementów AD, zaczynając od pierwszego bajtu po nagłówku. Jeśli Length=0, element jest ignorowany, a parser przechodzi do następnego bajtu. Zduplikowane typy AD — kilka elementów o tym samym Type w jednym pakiecie — są dozwolone, ale Central może przetworzyć tylko pierwszy lub ostatni w zależności od implementacji stosu.
Ważna zasada: suma wszystkich Length(+1) w pakiecie nie może przekraczać rozmiaru danych reklamowych (31 bajtów dla PDU reklamowego). Jeśli dane się nie mieszczą, należy ustalić priorytety — które typy AD są krytyczne dla wstępnego wykrycia, a które można przenieść do Scan Response.
Flags (0x01): obowiązkowy typ AD
Flags (AD Type 0x01) — obowiązkowy element w pakiecie reklamowym każdego urządzenia BLE. Zajmuje 3 bajty: Length (0x02), Type (0x01), Value (1 bajt flag bitowych). Flagi określają tryby wykrywania i możliwości urządzenia. Core Specification zaleca dołączanie Flags do każdego pakietu reklamowego.
Główne flagi: LE Limited Discoverable Mode (bit 0) — urządzenie jest dostępne do wykrycia przez ograniczony czas, LE General Discoverable Mode (bit 1) — urządzenie jest dostępne stale, BR/EDR Not Supported (bit 2) — urządzenie obsługuje tylko LE, Simultaneous LE and BR/EDR (bit 3) — obsługa obu trybów. Dla urządzeń czysto BLE obowiązkowa jest kombinacja: LE General Discoverable + BR/EDR Not Supported.
Nieprawidłowa wartość Flags to jedna z częstych przyczyn, dla których urządzenie nie jest wykrywane w iOS lub Android. Na przykład, jeśli flaga BR/EDR Not Supporteed nie jest ustawiona, iOS może próbować połączyć się przez klasyczny Bluetooth zamiast BLE. Sprawdzaj wartość Flags podczas debugowania pakietu reklamowego za pomocą analizatora Bluetooth (nRF Connect, Wireshark).
Local Name: nazwa urządzenia
Local Name (AD Type 0x08 lub 0x09) — wyświetlana nazwa urządzenia BLE. Typ 0x08 (Shortened Local Name) — nazwa skrócona, używana gdy pełna nazwa nie mieści się w pakiecie reklamowym. Typ 0x09 (Complete Local Name) — pełna nazwa urządzenia. Maksymalna długość nazwy to 248 bajtów, ale w standardowym pakiecie reklamowym dostępne jest nie więcej niż 28 bajtów.
Jeśli nazwa urządzenia przekracza dostępne miejsce w pakiecie reklamowym, zaleca się: umieścić skróconą nazwę w PDU reklamowym (typ 0x08), a pełną nazwę w Scan Response (typ 0x09). iOS wyświetla nazwę z pakietu reklamowego podczas skanowania, a pełna nazwa staje się dostępna po połączeniu lub Scan Response.
Przy wyborze nazwy urządzenia uwzględnij: zbyt długa nazwa zajmuje miejsce, które mogłoby być wykorzystane na Service UUID lub inne ważne dane. Zalecana długość nazwy to 8–16 znaków. Unikaj niestandardowych znaków i spacji — niektóre stosy BLE mogą je nieprawidłowo przetwarzać.
Service UUID: identyfikacja usług
Service UUID (AD Type 0x02–0x07) — jeden z najważniejszych typów AD, umożliwiający Central określenie, jakie usługi oferuje urządzenie, bez łączenia się z nim. Bluetooth SIG definiuje kilka formatów przesyłania UUID w zależności od rozmiaru: 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 bajty) — standardowe usługi Bluetooth SIG, na przykład 0x180F (Battery Service), 0x180A (Device Information). 128-bit UUID (16 bajtów) — usługi niestandardowe, definiowane przez programistę. 16-bit UUID zajmuje tylko 4 bajty w AD (Length + Type + 2 bajty UUID), a 128-bit — 18 bajtów. Jeśli w jednym pakiecie trzeba przesłać kilka niestandardowych UUID, mogą się one nie zmieścić w 31 bajtach.
Zaleca się używanie typu Incomplete (0x02/0x04/0x06), jeśli przesyłane są nie wszystkie UUID urządzenia, a tylko te najważniejsze do filtrowania. Pełna lista UUID jest przesyłana przez Scan Response lub GATT Discovery po połączeniu. Oszczędza to miejsce w pakiecie reklamowym na inne typy AD.
Manufacturer Specific Data
Manufacturer Specific Data (AD Type 0xFF) — najbardziej elastyczny typ AD, przeznaczony do przesyłania danych producenta. Pierwsze 2 bajty Value to Company Identifier Code, przypisany przez Bluetooth SIG (na przykład 0x004C dla Apple, 0x0075 dla Samsung). Pozostałe bajty to dowolne dane w formacie określonym przez producenta.
Apple używa Manufacturer Data dla iBeacon: Company ID (0x004C), typ Beacon (0x0215), UUID (16 bajtów), Major (2 bajty), Minor (2 bajty), TX Power (1 bajt). Google używa analogicznego formatu dla Eddystone. Producenci urządzeń IoT często umieszczają w Manufacturer Data odczyty czujników lub stan urządzenia.
js
// Parsuj Manufacturer Specific Data na Central
function parseManufacturerData(data) {
const view = new DataView(data.buffer);
// Kod identyfikacyjny firmy (pierwsze 2 bajty)
const companyId = view.getUint16(0, true);
// Sprawdź obecność Apple iBeacon
if (companyId === 0x004C) {
return parseIBeacon(view);
}
return null;
}Przy używaniu Manufacturer Data ważne jest przestrzeganie ograniczenia rozmiaru: 31 bajtów na cały pakiet reklamowy minus obowiązkowe typy AD. Dla Apple iBeacon cały pakiet zajmuje 30 bajtów, pozostawiając miejsce tylko dla Flags (3 bajty). Dla Eddystone — do 31 bajtów. Kompaktowe niestandardowe formaty mogą zawierać temperaturę, wilgotność lub ciśnienie w 4–8 bajtach.
Strategia pakowania danych
Prawidłowe pakowanie advertising data — to sztuka umieszczania maksymalnie przydatnych informacji w ograniczonej przestrzeni 31 bajtów. Strategia zależy od przeznaczenia urządzenia: beacon potrzebuje identyfikatora, czujnik IoT — odczytów, tracker fitness — nazwy i UUID usług. Ogólna zasada: im szybciej Central musi podjąć decyzję, tym bardziej krytyczne dane powinny być w PDU reklamowym.
Zalecana strategia: PDU reklamowe (pierwsze 31 bajtów) — Flags (3 bajty) + jeden 16-bit Service UUID (4 bajty) + skrócona nazwa (do 12 znaków = 14 bajtów) + Manufacturer Data (do 10 bajtów). Scan Response (drugie 31 bajtów) — pełna nazwa (reszta) + dodatkowe Service UUID + TX Power Level (3 bajty). Taki podział pozwala Central szybko filtrować urządzenia po UUID.
| Priorytet | Typ AD | Rozmiar | Umieść w |
|---|---|---|---|
| 1 (obowiązkowy) | Flags (0x01) | 3 bajty | PDU reklamowe |
| 2 (filtrowanie) | Service UUID (0x02–0x03) | 4+ bajtów | PDU reklamowe |
| 3 (identyfikacja) | Local Name (0x08–0x09) | 2+ bajty | PDU reklamowe (skrócona) |
| 4 (dodatkowe) | TX Power Level (0x0A) | 3 bajty | Scan Response |
| 5 (niestandardowe) | Manufacturer Data (0xFF) | 4+ bajtów | PDU reklamowe / Scan Response |
| 6 (pełne dane) | Pozostałe UUID | Według rozmiaru | Scan Response |
Debugowanie advertising data to obowiązkowy etap rozwoju urządzenia BLE. Używaj nRF Connect (Nordic Semiconductor) lub Wireshark z analizatorem Bluetooth do przeglądania surowych danych pakietu. Sprawdź, czy wszystkie typy AD mają poprawny Length, czy suma długości nie przekracza 31 bajtów i czy Flags są ustawione prawidłowo dla Twojego scenariusza użycia.
Często zadawane pytania
Co się stanie, jeśli suma elementów AD przekroczy 31 bajtów?
Stos Bluetooth Controller odrzuci dane przekraczające limit lub nie wyśle pakietu. Sprawdzaj całkowitą długość elementów AD podczas składania pakietu reklamowego. Jeśli dane się nie mieszczą — przenieś część do Scan Response lub użyj Extended Advertising (BLE 5.0) z limitem 251 bajtów.
Czy można przesyłać odczyty czujników w pakiecie reklamowym?
Tak, przez Manufacturer Specific Data (0xFF). Zapakuj odczyty w 4–8 bajtów: na przykład temperaturę (2 bajty w formacie fixed-point), wilgotność (2 bajty), napięcie baterii (2 bajty). Takie podejście pozwala Central odczytywać dane bez łączenia, oszczędzając energię.
Którego typu AD użyć dla usług niestandardowych?
Dla usług niestandardowych używaj 128-bit UUID (AD Type 0x06–0x07). Jeśli UUID nie mieści się w PDU reklamowym (16 bajtów na jeden UUID), przenieś go do Scan Response lub użyj skróconego formatu Incomplete (0x06) do wskazania tylko pierwszego lub dwóch UUID.
Czym różnią się typy Complete i Incomplete Service UUID?
Complete — w pakiecie są wymienione wszystkie UUID usług urządzenia. Incomplete — tylko część UUID (zwykle najważniejsze). Central nie może polegać na Incomplete jako na pełnej liście, ale używa go do szybkiego filtrowania. Pełna lista jest dostępna po GATT Discovery.
Dlaczego iOS nie widzi mojego urządzenia BLE?
Częstą przyczyną jest nieprawidłowy Flags (0x01). Upewnij się, że ustawiony jest bit BR/EDR Not Supported. Drugim powodem jest brak Service UUID w pakiecie reklamowym (iOS filtruje po UUID). Trzecim — urządzenie reklamuje się zbyt rzadko (iOS oczekuje interwału nie większego niż 1000 ms).
Podsumowanie
- Advertising Data — strukturyzowane dane w formacie AD Structure (Length-Type-Value), przesyłane w pakietach reklamowych BLE.
- Standardowy pakiet reklamowy mieści do 31 bajtów danych, Scan Response — kolejne 31 bajtów na dodatkowe informacje.
- Flags (0x01) — obowiązkowy typ AD, określający tryby wykrywania. Dla urządzeń BLE obowiązkowy jest BR/EDR Not Supported.
- Service UUID jest przesyłany w formacie 16-bit (2 bajty) lub 128-bit (16 bajtów), Complete lub Incomplete — w zależności od dostępnego miejsca.
- Manufacturer Specific Data (0xFF) — elastyczny typ dla danych niestandardowych, używany w beaconach iBeacon, Eddystone i urządzeniach IoT.
- Strategia pakowania: obowiązkowe typy AD (Flags, Service UUID, skrócona nazwa) — w PDU reklamowym, dodatkowe — w Scan Response.
- Debugowanie advertising data przez nRF Connect lub Wireshark — obowiązkowy etap rozwoju do sprawdzenia poprawności struktury AD.
Opracujemy aplikację mobilną pod klucz
IT Sectr tworzy aplikacje na iOS i Androida dla startupów i firm od 2017 roku. Doradzimy Ci i zaproponujemy najlepsze rozwiązanie.
Przeczytaj również