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 байт для advertising 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 байт.
Якщо ім'я пристрою перевищує доступне місце в рекламному пакеті, рекомендується: помістити скорочене ім'я в advertising 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
// 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;
}При використанні Manufacturer Data важливо дотримуватися обмеження за розміром: 31 байт на весь рекламний пакет мінус обов'язкові AD-типи. Для Apple iBeacon весь пакет займає 30 байт, залишаючи місце тільки для Flags (3 байти). Для Eddystone — до 31 байта. Компактні користувацькі формати можуть включати температуру, вологість або тиск у 4–8 байтах.
Стратегія пакування даних
Правильне пакування advertising data — це мистецтво розміщення максимально корисної інформації в обмеженому просторі 31 байта. Стратегія залежить від призначення пристрою: маячку потрібен ідентифікатор, IoT-датчику — показники, фітнес-трекеру — ім'я та UUID сервісів. Загальний принцип: чим швидше Central має прийняти рішення, тим більш критичні дані повинні бути в advertising PDU.
Рекомендована стратегія: advertising 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 байти | Advertising PDU |
| 2 (фільтрація) | Service UUID (0x02–0x03) | 4+ байти | Advertising PDU |
| 3 (ідентифікація) | Local Name (0x08–0x09) | 2+ байти | Advertising PDU (скорочене) |
| 4 (додатково) | TX Power Level (0x0A) | 3 байти | Scan Response |
| 5 (користувацькі) | Manufacturer Data (0xFF) | 4+ байти | Advertising 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-елементів при збиранні advertising-пакета. Якщо дані не вміщаються — перенесіть частину в Scan Response або використовуйте Extended Advertising (BLE 5.0) з лімітом 251 байт.
Чи можна передавати показники датчиків у advertising-пакеті?
Так, через Manufacturer Specific Data (0xFF). Упакуйте показники в 4–8 байт: наприклад, температуру (2 байти у форматі fixed-point), вологість (2 байти), напругу батареї (2 байти). Такий підхід дозволяє Central читати дані без підключення, заощаджуючи енергію.
Який AD-тип використовувати для користувацьких сервісів?
Для користувацьких сервісів використовуйте 128-bit UUID (AD Type 0x06–0x07). Якщо UUID не вміщається в advertising 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 у advertising-пакеті (iOS фільтрує за UUID). Третя — пристрій рекламується занадто рідко (iOS очікує інтервал не більше 1000 мс).
Підсумки
- Advertising Data — структуровані дані у форматі AD Structure (Length-Type-Value), що передаються в рекламних пакетах BLE.
- Стандартний advertising-пакет вміщає до 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, скорочене ім'я) — в advertising PDU, додаткові — в Scan Response.
- Налагодження advertising data через nRF Connect або Wireshark — обов'язковий етап розробки для перевірки коректності AD-структури.
Ми розробимо мобільний застосунок під ключ
IT Sectr створює застосунки для iOS та Android для стартапів і бізнесу з 2017 року. Ми проконсультуємо вас і запропонуємо найкраще рішення.
Читайте також