Advertising Data in BLE: What It Is, Structure and Data Types
Advertising Data is structured data that a BLE device transmits in advertising packets to identify itself and its services. The Bluetooth Core Specification 5.4 (2023) defines the AD Structure format: each element contains a length (1 byte), type (1 byte), and value (up to 29 bytes). The specification describes over 30 AD types — from Flags and Local Name to Service UUID and Manufacturer Specific Data. Proper packing of advertising data is critical for device compatibility with iOS, Android, and other platforms, and also determines discovery speed and advertising energy efficiency.
Key Takeaways
- AD Structure is the data format in a BLE advertising packet: length (1 byte), type (1 byte), value (up to 29 bytes).
- The advertising packet is limited to 31 bytes, scan response provides another 31 bytes for additional data.
- Flags (0x01) is a mandatory AD type that defines LE Limited Discoverable and BR/EDR Not Supported modes.
- Service UUID is transmitted in shortened (2 bytes) or full (16 bytes) format.
- Manufacturer Specific Data (0xFF) is a flexible type for any custom manufacturer data.
What Is Advertising Data?
Advertising Data is a structured set of fields that a BLE device transmits in advertising packets to identify itself and describe its capabilities. The Central, scanning the airwaves, reads this data and decides whether to connect to the device, ignore it, or request additional information via Scan Response.
The data is organized using the TLV (Type-Length-Value) principle: each AD element consists of three fields. Length (1 byte) is the length of Value + Type (i.e., the total element length minus 1 byte for Length). Type (1 byte) is the data type identifier from the Bluetooth Assigned Numbers. Value (N bytes) is the content depending on the type.
A standard advertising packet can contain up to 31 bytes of AD data. If that is not enough, Scan Response (another 31 bytes) or Extended Advertising (BLE 5.0, up to 251 bytes) is used. The first bytes of the advertising packet are reserved for the PDU header and device address — the AD payload starts at an offset.
AD Structure Format
Each AD element in the advertising packet starts with the Length field (1 byte). The Length value indicates the number of bytes following Length — that is, Type + Value. For example, an element with Length=3 means that after Length there is 1 byte of Type and 2 bytes of Value. The packet ends when the sum of all element lengths reaches the advertising data size.
| Field | Size | Description |
|---|---|---|
| Length | 1 byte | Length of Type + Value (excluding Length) |
| Type (AD Type) | 1 byte | Data type identifier from Bluetooth SIG |
| Value | 0–29 bytes | Data of the specified type |
The Central parser reads the sequence of AD elements starting from the first byte after the header. If Length=0, the element is ignored and the parser moves to the next byte. Duplicate AD types — multiple elements with the same Type in one packet — are allowed, but the Central may process only the first or the last depending on the stack implementation.
An important rule: the sum of all Length(+1) in the packet must not exceed the advertising data size (31 bytes for advertising PDU). If the data does not fit, priorities must be set — which AD types are critical for initial discovery and which can be moved to Scan Response.
Flags (0x01): Mandatory AD Type
Flags (AD Type 0x01) is a mandatory element in the advertising packet of any BLE device. It occupies 3 bytes: Length (0x02), Type (0x01), Value (1 byte of bit flags). The flags define discovery modes and device capabilities. The Core Specification recommends including Flags in every advertising packet.
Main flags: LE Limited Discoverable Mode (bit 0) — the device is discoverable for a limited time, LE General Discoverable Mode (bit 1) — the device is always discoverable, BR/EDR Not Supported (bit 2) — the device supports LE only, Simultaneous LE and BR/EDR (bit 3) — supports both modes. For pure BLE devices, the combination LE General Discoverable + BR/EDR Not Supported is mandatory.
An incorrect Flags value is one of the common reasons why a device is not detected on iOS or Android. For example, if the BR/EDR Not Supported flag is not set, iOS may try to connect via classic Bluetooth instead of BLE. Check the Flags value when debugging the advertising packet using a Bluetooth analyzer (nRF Connect, Wireshark).
Local Name: Device Name
Local Name (AD Type 0x08 or 0x09) is the display name of the BLE device. Type 0x08 (Shortened Local Name) is a shortened name, used when the full name does not fit in the advertising packet. Type 0x09 (Complete Local Name) is the full device name. The maximum name length is 248 bytes, but in a standard advertising packet no more than 28 bytes are available.
If the device name exceeds the available space in the advertising packet, it is recommended to: place the shortened name in the advertising PDU (type 0x08), and the full name in the Scan Response (type 0x09). iOS displays the name from the advertising packet during scanning, while the full name becomes available after connection or Scan Response.
When choosing a device name, keep in mind: a name that is too long takes up space that could be used for Service UUID or other important data. The recommended name length is 8–16 characters. Avoid non-standard characters and spaces — some BLE stacks may handle them incorrectly.
Service UUID: Service Identification
Service UUID (AD Type 0x02–0x07) is one of the most important AD types, allowing the Central to determine what services the device provides without connecting to it. Bluetooth SIG defines several UUID transmission formats depending on size: 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 bytes) is for standard Bluetooth SIG services, e.g. 0x180F (Battery Service), 0x180A (Device Information). 128-bit UUID (16 bytes) is for custom services defined by the developer. A 16-bit UUID takes only 4 bytes in AD (Length + Type + 2 bytes UUID), while a 128-bit UUID takes 18 bytes. If multiple custom UUIDs need to be transmitted in one packet, they may not fit in 31 bytes.
It is recommended to use the Incomplete (0x02/0x04/0x06) type if not all device UUIDs are transmitted, only the most important ones for filtering. The full list of UUIDs is transmitted via Scan Response or GATT Discovery after connection. This saves space in the advertising packet for other AD types.
Manufacturer Specific Data
Manufacturer Specific Data (AD Type 0xFF) is the most flexible AD type, designed for transmitting custom manufacturer data. The first 2 bytes of Value are the Company Identifier Code assigned by Bluetooth SIG (e.g., 0x004C for Apple, 0x0075 for Samsung). The remaining bytes are arbitrary data in a manufacturer-defined format.
Apple uses Manufacturer Data for iBeacon: Company ID (0x004C), Beacon type (0x0215), UUID (16 bytes), Major (2 bytes), Minor (2 bytes), TX Power (1 byte). Google uses a similar format for Eddystone. IoT device manufacturers often place sensor readings or device status 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;
}When using Manufacturer Data, it is important to observe the size limitation: 31 bytes for the entire advertising packet minus mandatory AD types. For Apple iBeacon, the entire packet occupies 30 bytes, leaving room only for Flags (3 bytes). For Eddystone — up to 31 bytes. Compact custom formats can include temperature, humidity, or pressure in 4–8 bytes.
Data Packing Strategy
Proper packing of advertising data is the art of placing the maximum useful information in the limited space of 31 bytes. The strategy depends on the device purpose: a beacon needs an identifier, an IoT sensor needs readings, a fitness tracker needs a name and service UUIDs. The general principle: the faster the Central must make a decision, the more critical the data should be in the advertising PDU.
Recommended strategy: advertising PDU (first 31 bytes) — Flags (3 bytes) + one 16-bit Service UUID (4 bytes) + shortened name (up to 12 characters = 14 bytes) + Manufacturer Data (up to 10 bytes). Scan Response (second 31 bytes) — full name (remainder) + additional Service UUIDs + TX Power Level (3 bytes). This distribution allows the Central to quickly filter devices by UUID.
| Priority | AD Type | Size | Place In |
|---|---|---|---|
| 1 (mandatory) | Flags (0x01) | 3 bytes | Advertising PDU |
| 2 (filtering) | Service UUID (0x02–0x03) | 4+ bytes | Advertising PDU |
| 3 (identification) | Local Name (0x08–0x09) | 2+ bytes | Advertising PDU (shortened) |
| 4 (additional) | TX Power Level (0x0A) | 3 bytes | Scan Response |
| 5 (custom) | Manufacturer Data (0xFF) | 4+ bytes | Advertising PDU / Scan Response |
| 6 (full data) | Remaining UUIDs | By size | Scan Response |
Debugging advertising data is a mandatory stage of BLE device development. Use nRF Connect (Nordic Semiconductor) or Wireshark with a Bluetooth analyzer to view raw packet data. Check that all AD types have correct Length, that the sum of lengths does not exceed 31 bytes, and that Flags are set correctly for your use case.
Frequently Asked Questions
What happens if the sum of AD elements exceeds 31 bytes?
The Bluetooth Controller stack will discard data exceeding the limit or will not send the packet. Check the total length of AD elements when assembling the advertising packet. If the data does not fit, move part of it to Scan Response or use Extended Advertising (BLE 5.0) with a 251-byte limit.
Can sensor readings be transmitted in an advertising packet?
Yes, via Manufacturer Specific Data (0xFF). Pack the readings into 4–8 bytes: for example, temperature (2 bytes in fixed-point format), humidity (2 bytes), battery voltage (2 bytes). This approach allows the Central to read data without connecting, saving energy.
Which AD type should I use for custom services?
For custom services, use 128-bit UUID (AD Type 0x06–0x07). If the UUID does not fit in the advertising PDU (16 bytes per UUID), move it to Scan Response or use the Incomplete shortened format (0x06) to specify only the first one or two UUIDs.
What is the difference between Complete and Incomplete Service UUID types?
Complete — all service UUIDs of the device are listed in the packet. Incomplete — only a subset of UUIDs (usually the most important ones). The Central cannot rely on Incomplete as a full list but uses it for quick filtering. The full list is available after GATT Discovery.
Why doesn't iOS see my BLE device?
A common cause is an incorrect Flags (0x01). Make sure the BR/EDR Not Supported bit is set. The second cause is the absence of Service UUID in the advertising packet (iOS filters by UUID). The third is that the device advertises too infrequently (iOS expects an interval of no more than 1000 ms).
Summary
- Advertising Data is structured data in AD Structure format (Length-Type-Value), transmitted in BLE advertising packets.
- A standard advertising packet holds up to 31 bytes of data, Scan Response provides another 31 bytes for additional information.
- Flags (0x01) is a mandatory AD type that defines discovery modes. BR/EDR Not Supported is mandatory for BLE devices.
- Service UUID is transmitted in 16-bit (2 bytes) or 128-bit (16 bytes) format, Complete or Incomplete depending on available space.
- Manufacturer Specific Data (0xFF) is a flexible type for custom data, used in iBeacon, Eddystone beacons, and IoT devices.
- Packing strategy: mandatory AD types (Flags, Service UUID, shortened name) in advertising PDU, additional ones in Scan Response.
- Debug advertising data using nRF Connect or Wireshark — a mandatory development stage for verifying correct AD structure.
We will develop a mobile application turnkey
IT Sectr creates iOS and Android applications for startups and businesses since 2017. We will advise you and propose the best solution.
Read also