Advertising in BLE: What It Is, Packet Formats and Advertising Mechanisms

What is Advertising in BLE?

Advertising is the process of periodically transmitting short data packets through which a BLE device announces its presence and availability. Unlike classic Bluetooth, where device discovery takes seconds, BLE advertising allows device discovery in milliseconds while consuming minimal power.

The BLE architecture divides devices into two roles: Peripheral (advertises) and Central (scans). The Peripheral sends advertising packets, while the Central scans the air and decides whether to connect. This asymmetric model is a key advantage of BLE: the advertising device only spends energy on sending short packets rather than constantly listening to the air.

The advertising process consists of three stages: advertising event (sending the packet on all three channels), scan request/response (optional exchange with Central) and connection request (connection initiation by Central). Each stage is managed by the Bluetooth Controller at the Link Layer level.

Advertising Channels and Their Purpose

BLE uses 40 channels in the 2.4 GHz band, of which 37 (2402 MHz), 38 (2426 MHz) and 39 (2480 MHz) are dedicated exclusively to advertising. Three channels represent a compromise between discovery reliability and throughput: one channel may be occupied by Wi-Fi or other interference, but the device will still be discovered on the other two.

Channel 37 is located near Wi-Fi channel 1, channel 39 is near Wi-Fi channel 6, and channel 38 sits between them in the zone of minimal interference. The choice of three channels ensures that the device will be discovered even in dense radio environments — for example, in a shopping center with dozens of Wi-Fi access points.

The Peripheral transmits the advertising packet sequentially on all three channels — this is called an advertising event. The central device scans one channel at a time, switching between them according to an algorithm implemented in the Bluetooth Controller. The probability of discovery within one advertising event in the absence of collisions is close to 100%.

Types of Advertising Packets

Bluetooth Core Specification defines several types of advertising PDU (Protocol Data Unit), each with its own purpose. The main types are: ADV_IND (connectable undirected advertising) — standard advertising with connection capability, ADV_NONCONN_IND (non-connectable undirected advertising) — advertising only without connection, ADV_SCAN_IND (scannable undirected advertising) — supports scan request, ADV_DIRECT_IND (directed advertising) — advertising for a specific Central.

ADV_IND is the most common type used in most BLE devices. Upon receiving ADV_IND, the Central can send a connection request and establish a connection. ADV_NONCONN_IND is used by beacons: the device advertises but does not accept connection requests — only one-way data transmission.

ADV_DIRECT_IND contains the address of the target Central, allowing quick connection establishment without waiting for scanning. It is used when devices already “know” each other — for example, after reconnecting to a previously paired smartphone. This type reduces power consumption as it does not require advertising on all channels.

Advertising Interval and Power Consumption

Advertising interval is the time between successive advertising events. The specification allows an interval from 20 ms to 10.24 s with a step of 0.625 ms. The actual interval is calculated as the sum of a fixed value and a random delay (0–10 ms), which reduces the probability of collisions between multiple advertising devices.

Choosing the interval is a balance between discovery speed and power consumption. At a 20 ms interval, the device will be discovered within 20–30 ms, but the average current will be about 1–2 mA. At a 1000 ms interval, discovery will take up to 1 second, but the average current will drop to 50–100 µA. For most IoT devices, the recommended interval is 200–1000 ms.

According to Texas Instruments Application Report SWRA478 (2024), increasing the advertising interval from 100 ms to 1000 ms reduces power consumption by 90%. If the device does not require instant discovery (for example, a temperature sensor transmitting data once per minute), the optimal interval is 1000–2000 ms.

An additional parameter is advertising timeout — the maximum time during which the device advertises. In iOS, the Peripheral automatically stops advertising after 180 seconds in the background. Android has no such limitation, but manufacturers may add their own limits.

Scan Response: Additional Data

Scan Response is an additional data packet (up to 31 bytes) that the Peripheral sends in response to a scan request from the Central. The scan request is sent by the Central after receiving the advertising packet if it needs more information before connecting. Scan Response does not require additional advertising — it is sent only upon request, saving airtime.

Typical data distribution: the advertising PDU (31 bytes) contains flags (3 bytes), service UUIDs (2–16 bytes) and manufacturer data (remaining bytes). The scan response carries the full device name (up to 28 bytes) and additional UUIDs or TX Power Level. This separation allows the Central to quickly filter devices by UUID without reading the scan response.

When designing the advertising packet, keep in mind: if all 31 bytes are occupied in the advertising PDU, the Central will not be able to determine whether the device supports scan response. It is recommended to leave at least 3–5 bytes free in the advertising PDU to indicate scan response capability.

Extended Advertising in BLE 5.0

Extended Advertising (BLE 5.0) is an extension of the advertising mechanism that increases the advertising packet size from 31 to 251 bytes and adds new packet types. Extended Advertising also supports coded PHY for extending communication range up to 1 km in open areas and periodic advertising for synchronizing multiple Centrals.

Main innovations: ADV_EXT_IND — extended advertising PDU that can transmit up to 251 bytes of data in a single packet. Extended Advertising uses the primary channels (37, 38, 39) only to indicate which secondary channel (0–36) carries the full data. This reduces the load on advertising channels and increases overall system throughput.

Periodic Advertising is an additional mechanism where the Peripheral sends data on secondary channels at a fixed interval, and the Central can synchronize with this sequence. It is used for services requiring regular data updates — for example, audio streaming or real-time sensor readings.

Configuring Advertising on iOS and Android

iOS (Core Bluetooth) provides CBPeripheralManager for managing advertising. Advertising parameters are set through the advertisementData dictionary with keys CBAdvertisementDataLocalNameKey (device name), CBAdvertisementDataServiceUUIDsKey (service UUIDs), CBAdvertisementDataTxPowerLevelKey (power level). iOS automatically manages the advertising interval and does not allow setting it manually.

import CoreBluetooth

class AdvertiserManager: NSObject, CBPeripheralManagerDelegate {

    private var peripheralManager: CBPeripheralManager!

    func startBLEAdvertising() {
        let data: [String: Any] = [
            CBAdvertisementDataLocalNameKey: "BLE Beacon",
            CBAdvertisementDataServiceUUIDsKey: [
                CBUUID("180F")
            ],
            CBAdvertisementDataIsConnectable: true
        ]
        peripheralManager.startAdvertising(data)
    }
}

Android (BluetoothLeAdvertiser) provides more detailed control. Available: AdvertiseSettings — mode configuration (LOW_POWER, BALANCED, LOW_LATENCY), transmitter power and interval; AdvertiseData — packet data. Android supports extended advertising (BLE 5.0) on compatible devices, but the share of such devices on the market is about 30–40%.

BluetoothLeAdvertiser advertiser =
    BluetoothAdapter.getDefaultAdapter()
    .getBluetoothLeAdvertiser();

AdvertiseSettings settings = new AdvertiseSettings.Builder()
    .setAdvertiseMode(
        AdvertiseSettings.ADVERTISE_MODE_LOW_POWER
    )
    .setTxPowerLevel(
        AdvertiseSettings.ADVERTISE_TX_POWER_MEDIUM
    )
    .build();

AdvertiseData data = new AdvertiseData.Builder()
    .setIncludeDeviceName(true)
    .addServiceUuid(new ParcelUuid(
        UUID.fromString(
            "0000180F-0000-1000-8000-00805F9B34FB"
        )
    ))
    .build();

advertiser.startAdvertising(
    settings, data, advertiseCallback
);

When developing a cross-platform BLE application, consider the differences: iOS does not allow directly controlling the advertising interval but guarantees stable operation on all devices; Android provides full control, but version and manufacturer fragmentation may lead to incompatibility. It is recommended to test advertising on real devices of both platforms.