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-устройство передаёт в advertising-пакетах для идентификации и описания своих возможностей. Central, сканируя эфир, считывает эти данные и принимает решение: подключаться к устройству, игнорировать его или запросить дополнительную информацию через Scan Response.
Данные организованы по принципу TLV (Type-Length-Value): каждый AD-элемент состоит из трёх полей. Length (1 байт) — длина Value + Type (то есть общая длина элемента минус 1 байт на Length). Type (1 байт) — идентификатор типа данных из Bluetooth Assigned Numbers. Value (N байт) — содержимое в зависимости от типа.
Стандартный advertising-пакет может содержать до 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) — обязательный элемент в advertising-пакете любого BLE-устройства. Он занимает 3 байта: Length (0x02), Type (0x01), Value (1 байт битовых флагов). Флаги определяют режимы обнаружения и возможности устройства. Core Specification рекомендует включать Flags в каждый advertising-пакет.
Основные флаги: 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 при отладке advertising-пакета с помощью Bluetooth-анализатора (nRF Connect, Wireshark).
Local Name: имя устройства
Local Name (AD Type 0x08 или 0x09) — отображаемое имя BLE-устройства. Тип 0x08 (Shortened Local Name) — сокращённое имя, используется, если полное имя не помещается в рекламный пакет. Тип 0x09 (Complete Local Name) — полное имя устройства. Максимальная длина имени — 248 байт, но в стандартном advertising-пакете доступно не более 28 байт.
Если имя устройства превышает доступное место в рекламном пакете, рекомендуется: поместить сокращённое имя в advertising PDU (тип 0x08), а полное имя — в Scan Response (тип 0x09). iOS отображает имя из advertising-пакета при сканировании, а полное имя становится доступным после подключения или 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 после подключения. Это экономит место в advertising-пакете для других 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 байт на весь advertising-пакет минус обязательные 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 года. Мы проконсультируем вас и предложим наилучшее решение.
Читайте также