Scan Response

Scan Response

A advertising data." data-category="GAP & Advertising">scan response is an optional secondary advertising payload that a BLE peripheral sends in reply to a SCAN_REQ from a central device performing active scanning. It provides up to 31 additional bytes of data beyond the primary advertising packet, effectively doubling the amount of information available before a connection is established.

How Scan Response Works

When a central device performs active scanning and receives an advertising packet of type ADV_IND or ADV_SCAN_IND, it can send a SCAN_REQ packet back to the advertiser on the same channel. The peripheral then responds with a SCAN_RSP packet containing supplementary AD (Advertising Data) structures. This three-packet exchange (ADV, SCAN_REQ, SCAN_RSP) completes within a few milliseconds.

The scan response payload uses the same AD structure format as the advertising packet. Common data placed in the scan response includes the complete local name (when the advertising packet only contains the shortened name), additional service UUIDs, manufacturer-specific data, and TX power level.

Use Cases

Scan response data is useful when the 31-byte advertising payload is insufficient to convey all necessary information. A fitness tracker might advertise its primary service ATT">UUID and flags in the advertising packet while placing its full device name, battery level, and manufacturer identifier in the scan response.

For beacon protocols like iBeacon, the scan response is often unused because the advertising packet already contains all necessary data (UUID, major, minor). However, Eddystone beacons may use scan response for additional URL or TLM (telemetry) frames.

Power and Bandwidth Considerations

Scan responses consume additional power because the peripheral must keep its radio active after the advertising transmission to listen for SCAN_REQ packets and send the response. If many central devices are scanning simultaneously in a crowded venue, the peripheral may receive and respond to multiple SCAN_REQ packets per advertising event, increasing energy consumption.

For applications where power is critical and scan response data is not needed, using ADV_NONCONN_IND (non-connectable, non-scannable) advertising eliminates scan response overhead entirely. The introduction of extended advertising in Bluetooth 5.0 also reduces the need for scan response by supporting payloads up to 255 bytes in a single advertising set.