Advertising Data в BLE: структура и типове данни
Advertising Data — са структурирани данни, които BLE устройството предава в рекламни пакети за идентификация на себе си и своите услуги. Bluetooth Core Specification 5.4 (2023) дефинира формата AD Structure: всеки елемент съдържа дължина (1 байт), тип (1 байт) и стойност (до 29 байта). Спецификацията описва общо над 30 AD типа — от Flags и Local Name до Service UUID и Manufacturer Specific Data. Правилното опаковане на advertising data е критично за съвместимостта на устройството с iOS, Android и други платформи, а също така определя скоростта на откриване и енергийната ефективност на рекламата.
Основни точки
- AD Structure — формат на данните в рекламния пакет BLE: дължина (1 байт), тип (1 байт), стойност (до 29 байта).
- Рекламният пакет е ограничен до 31 байт, scan response — още 31 байта за допълнителни данни.
- Flags (0x01) — задължителен AD тип, определящ режимите LE Limited Discoverable и BR/EDR Not Supported.
- Service UUID се предава в съкратен (2 байта) или пълен (16 байта) формат.
- Manufacturer Specific Data (0xFF) — гъвкав тип за всякакви персонализирани данни на производителя.
Какво е Advertising Data?
Advertising Data — е структуриран набор от полета, които BLE устройството предава в рекламни пакети за идентификация и описание на своите възможности. Central, сканирайки канала, чете тези данни и взема решение: да се свърже с устройството, да го игнорира или да поиска допълнителна информация чрез Scan Response.
Данните са организирани според принципа TLV (Type-Length-Value): всеки AD елемент се състои от три полета. Length (1 байт) — дължина на Value + Type (т.е. общата дължина на елемента минус 1 байт за Length). Type (1 байт) — идентификатор на типа данни от Bluetooth Assigned Numbers. Value (N байта) — съдържание в зависимост от типа.
Стандартният рекламен пакет може да съдържа до 31 байта AD данни. Ако това не е достатъчно, се използва Scan Response (още 31 байта) или Extended Advertising (BLE 5.0, до 251 байта). Първите байтове на рекламния пакет са запазени за заглавката на PDU и адреса на устройството — полезният AD товар започва от отместване.
Формат на AD Structure
Всеки AD елемент в рекламния пакет започва с полето Length (1 байт). Стойността Length показва броя байтове след Length — т.е. Type + Value. Например елемент с Length=3 означава, че след Length следва 1 байт Type и 2 байта Value. Пакетът завършва, когато сумата от дължините на всички елементи достигне размера на рекламните данни.
| Поле | Размер | Описание |
|---|---|---|
| Length | 1 байт | Дължина на Type + Value (без Length) |
| Type (AD Type) | 1 байт | Идентификатор на типа данни според Bluetooth SIG |
| Value | 0–29 байта | Данни от определен тип |
Парсерът на Central чете последователността от AD елементи, започвайки от първия байт след заглавката. Ако Length=0, елементът се игнорира и парсерът преминава към следващия байт. Дублирани AD типове — няколко елемента с еднакъв Type в един пакет — са разрешени, но Central може да обработи само първия или последния в зависимост от имплементацията на стека.
Важно правило: сумата от всички Length(+1) в пакета не трябва да надвишава размера на рекламните данни (31 байта за рекламен PDU). Ако данните не се побират, трябва да се определят приоритети — кои AD типове са критични за първичното откриване и кои могат да бъдат преместени в Scan Response.
Flags (0x01): задължителен AD тип
Flags (AD Type 0x01) — задължителен елемент в рекламния пакет на всяко BLE устройство. Заема 3 байта: Length (0x02), Type (0x01), Value (1 байт битови флагове). Флаговете определят режимите на откриване и възможностите на устройството. Core Specification препоръчва включването на Flags във всеки рекламен пакет.
Основни флагове: LE Limited Discoverable Mode (бит 0) — устройството е достъпно за откриване за ограничено време, LE General Discoverable Mode (бит 1) — устройството е постоянно достъпно, BR/EDR Not Supported (бит 2) — устройството поддържа само LE, Simultaneous LE and BR/EDR (бит 3) — поддръжка на двата режима. За чисто BLE устройства задължителна комбинация: LE General Discoverable + BR/EDR Not Supported.
Неправилната стойност на Flags е една от честите причини, поради които устройството не се открива в iOS или Android. Например, ако флагът BR/EDR Not Supported не е зададен, iOS може да се опита да се свърже чрез класически Bluetooth вместо BLE. Проверявайте стойността на Flags при отстраняване на грешки в рекламния пакет с Bluetooth анализатор (nRF Connect, Wireshark).
Local Name: име на устройството
Local Name (AD Type 0x08 или 0x09) — показваното име на BLE устройството. Тип 0x08 (Shortened Local Name) — съкратено име, използва се когато пълното име не се побира в рекламния пакет. Тип 0x09 (Complete Local Name) — пълното име на устройството. Максималната дължина на името е 248 байта, но в стандартния рекламен пакет са налични не повече от 28 байта.
Ако името на устройството надвишава наличното място в рекламния пакет, се препоръчва: поставете съкратеното име в рекламния PDU (тип 0x08), а пълното име в Scan Response (тип 0x09). iOS показва името от рекламния пакет при сканиране, а пълното име става достъпно след свързване или Scan Response.
При избора на име на устройството вземете предвид: твърде дългото име заема място, което би могло да се използва за Service UUID или други важни данни. Препоръчителната дължина на името е 8–16 знака. Избягвайте нестандартни знаци и интервали — някои BLE стекове може да ги обработват неправилно.
Service UUID: идентификация на услуги
Service UUID (AD Type 0x02–0x07) — един от най-важните AD типове, който позволява на Central да определи какви услуги предоставя устройството без да се свързва с него. Bluetooth SIG дефинира няколко формата за предаване на UUID в зависимост от размера: 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 байта) — стандартни Bluetooth SIG услуги, например 0x180F (Battery Service), 0x180A (Device Information). 128-bit UUID (16 байта) — персонализирани услуги, дефинирани от разработчика. 16-bit UUID заема само 4 байта в AD (Length + Type + 2 байта UUID), а 128-bit — 18 байта. Ако в един пакет трябва да се предадат няколко персонализирани UUID, те може да не се поберат в 31 байта.
Препоръчва се използването на тип Incomplete (0x02/0x04/0x06), ако не се предават всички UUID на устройството, а само най-важните за филтриране. Пълният списък с UUID се предава чрез Scan Response или GATT Discovery след свързване. Това спестява място в рекламния пакет за други AD типове.
Manufacturer Specific Data
Manufacturer Specific Data (AD Type 0xFF) — най-гъвкавият AD тип, предназначен за предаване на персонализирани данни на производителя. Първите 2 байта на Value са Company Identifier Code, присвоен от Bluetooth SIG (например 0x004C за Apple, 0x0075 за Samsung). Останалите байтове са произволни данни във формат, определен от производителя.
Apple използва Manufacturer Data за iBeacon: Company ID (0x004C), тип Beacon (0x0215), UUID (16 байта), Major (2 байта), Minor (2 байта), TX Power (1 байт). Google използва аналогичен формат за Eddystone. Производителите на IoT устройства често поставят в Manufacturer Data показания от сензори или състояние на устройството.
js
// Анализирай Manufacturer Specific Data на Central
function parseManufacturerData(data) {
const view = new DataView(data.buffer);
// Идентификационен код на компанията (първите 2 байта)
const companyId = view.getUint16(0, true);
// Провери за Apple iBeacon
if (companyId === 0x004C) {
return parseIBeacon(view);
}
return null;
}При използване на Manufacturer Data е важно да се спазва ограничението на размера: 31 байта за целия рекламен пакет минус задължителните AD типове. За Apple iBeacon целият пакет заема 30 байта, оставяйки място само за Flags (3 байта). За Eddystone — до 31 байта. Компактните персонализирани формати могат да включват температура, влажност или налягане в 4–8 байта.
Стратегия за опаковане на данни
Правилното опаковане на advertising data — е изкуството да поставите максимално полезна информация в ограниченото пространство от 31 байта. Стратегията зависи от предназначението на устройството: маякът се нуждае от идентификатор, IoT сензорът — от показания, фитнес тракерът — от име и UUID на услуги. Общ принцип: колкото по-бързо трябва Central да вземе решение, толкова по-критични данни трябва да бъдат в рекламния PDU.
Препоръчителна стратегия: рекламен PDU (първите 31 байта) — Flags (3 байта) + един 16-bit Service UUID (4 байта) + съкратено име (до 12 знака = 14 байта) + Manufacturer Data (до 10 байта). Scan Response (вторите 31 байта) — пълно име (остатък) + допълнителни Service UUID + TX Power Level (3 байта). Това разпределение позволява на Central бързо да филтрира устройства по UUID.
| Приоритет | AD тип | Размер | Поставете в |
|---|---|---|---|
| 1 (задължително) | Flags (0x01) | 3 байта | Рекламен PDU |
| 2 (филтриране) | Service UUID (0x02–0x03) | 4+ байта | Рекламен PDU |
| 3 (идентификация) | Local Name (0x08–0x09) | 2+ байта | Рекламен PDU (съкратено) |
| 4 (допълнително) | TX Power Level (0x0A) | 3 байта | Scan Response |
| 5 (персонализирано) | Manufacturer Data (0xFF) | 4+ байта | Рекламен PDU / Scan Response |
| 6 (пълни данни) | Останали UUID | По размер | Scan Response |
Отстраняването на грешки в advertising data е задължителен етап от разработката на BLE устройство. Използвайте nRF Connect (Nordic Semiconductor) или Wireshark с Bluetooth анализатор за преглед на суровите данни на пакета. Проверете дали всички AD типове имат правилен Length, дали сумата от дължините не надвишава 31 байта и дали Flags са зададени правилно за вашия сценарий на използване.
Често задавани въпроси
Какво се случва, ако сумата на AD елементите надвиши 31 байта?
Стекът на Bluetooth Controller ще отхвърли данните, надвишаващи лимита, или няма да изпрати пакета. Проверявайте общата дължина на AD елементите при сглобяване на рекламния пакет. Ако данните не се побират — преместете част от тях в Scan Response или използвайте Extended Advertising (BLE 5.0) с лимит от 251 байта.
Могат ли показания от сензори да се предават в рекламния пакет?
Да, чрез Manufacturer Specific Data (0xFF). Опаковайте показанията в 4–8 байта: например температура (2 байта във fixed-point формат), влажност (2 байта), напрежение на батерията (2 байта). Този подход позволява на Central да чете данни без свързване, спестявайки енергия.
Кой AD тип да използвам за персонализирани услуги?
За персонализирани услуги използвайте 128-bit UUID (AD Type 0x06–0x07). Ако UUID не се побира в рекламния PDU (16 байта за един UUID), преместете го в Scan Response или използвайте съкратен формат Incomplete (0x06) за посочване само на първите един или два UUID.
Каква е разликата между типовете Complete и Incomplete Service UUID?
Complete — в пакета са изброени всички UUID на услугите на устройството. Incomplete — само част от UUID (обикновено най-важните). Central не може да разчита на Incomplete като на пълен списък, но го използва за бързо филтриране. Пълният списък е достъпен след GATT Discovery.
Защо iOS не вижда моето BLE устройство?
Честа причина — неправилен Flags (0x01). Уверете се, че битът BR/EDR Not Supported е зададен. Втора причина — липса на Service UUID в рекламния пакет (iOS филтрира по UUID). Трета — устройството рекламира твърде рядко (iOS очаква интервал не по-голям от 1000 ms).
Резюме
- Advertising Data — структурирани данни във формат AD Structure (Length-Type-Value), предавани в рекламни пакети BLE.
- Стандартният рекламен пакет съдържа до 31 байта данни, Scan Response — още 31 байта за допълнителна информация.
- Flags (0x01) — задължителен AD тип, определящ режимите на откриване. За BLE устройства BR/EDR Not Supported е задължителен.
- Service UUID се предава в 16-bit (2 байта) или 128-bit (16 байта) формат, Complete или Incomplete — в зависимост от наличното място.
- Manufacturer Specific Data (0xFF) — гъвкав тип за персонализирани данни, използван в маяци iBeacon, Eddystone и IoT устройства.
- Стратегия за опаковане: задължителни AD типове (Flags, Service UUID, съкратено име) — в рекламния PDU, допълнителни — в Scan Response.
- Отстраняване на грешки в advertising data чрез nRF Connect или Wireshark — задължителен етап от разработката за проверка на коректността на AD структурата.
Ще разработим мобилно приложение под ключ
IT Sectr създава iOS и Android приложения за стартъпи и бизнеси от 2017 г. Ще ви консултираме и ще предложим най-доброто решение.
Прочетете също