Announcing instead of waiting
A Bluetooth Low Energy device cannot be found unless it says something. Advertising is how it does that. The device sends a short packet, waits, and sends it again, over and over, for as long as it wants to be discoverable. Devices that are listening, or scanning, pick the packets up and decide whether the advertiser is something they care about.
The Bluetooth Core Specification names the two sides of this exchange as roles in its Generic Access Profile. A Broadcaster sends advertising events, and an Observer receives them. A device that advertises and then accepts a connection is acting as a Peripheral, and a device that scans and then opens the connection is acting as a Central. The central and peripheral roles get their own article.
Where advertising happens on the radio
Bluetooth LE divides its band into 40 RF channels. The Link Layer specification sets aside 3 of them as primary advertising channels, used for initial advertising and all legacy advertising, and uses the other 37 for most other communication.
An advertising event sends the same packet on each primary advertising channel the device uses, then the device waits until the next event. The specification adds a small pseudo-random delay to each interval, so advertising events are spread out in time rather than repeating on an exact schedule. A scanner listens on the advertising channels and collects what it hears. In passive scanning it only receives. In active scanning it can, depending on the advertisement type, ask the advertiser for more information, which comes back as a scan response.
Advertisements come in several types. An advertiser can be connectable or not, and scannable or not. A beacon that only broadcasts a reading is non-connectable. A sensor that wants a phone to connect sends connectable advertisements.
What goes inside an advertisement
The payload is a sequence of AD structures. The Generic Access Profile defines the format: each structure starts with a one-octet length, then an AD type, then the data. The AD type values, such as Flags, lists of service UUIDs, the local name and manufacturer-specific data, are registered in the Bluetooth SIG’s Assigned Numbers.
The most useful item for app developers is usually a service UUID. A scanner can filter on it and ignore everything else, which is how an app finds its own devices in a room full of headphones and watches. The UUID identifies a GATT service that the device offers once connected; GATT services and characteristics explains that structure.
How much fits
Legacy advertising packets are small. Android’s BluetoothLeAdvertiser reference says an advertiser can broadcast up to 31 bytes of advertisement data, and that if the advertisement is connectable, three bytes are added for flags.
Extended advertising, an option in the Link Layer specification, moves most of the data off the three primary channels onto secondary channels and lets the controller split it across a chain of packets. The specification caps host advertising data at 1650 octets before fragmentation. Not every phone supports it: Android exposes isLeExtendedAdvertisingSupported and getLeMaximumAdvertisingDataLength on BluetoothAdapter so apps can check.
What phones let apps advertise
Mobile operating systems add their own limits on top of the specification.
iOS. Apple’s startAdvertising(_:) documentation says the peripheral manager supports only two advertising keys, the local name and service UUIDs. In the foreground an app can use up to 28 bytes of the initial advertisement for those keys, plus 10 bytes of scan response space for the local name only, not counting the 2 bytes of header each data type needs. Service UUIDs that do not fit go to an overflow area that only iOS devices explicitly scanning for them can discover. In the background, the local name is not advertised and every service UUID goes to the overflow area. Apple also describes advertising as best effort, because several apps may be advertising at once.
Android. Apps advertise with BluetoothLeAdvertiser, which can return null when the device does not support LE advertising. Scanning has its own rules: the BluetoothLeScanner reference says unfiltered scans stop when the screen turns off, so apps that need to keep finding devices pass a scan filter.
These rules shape app design. Two phones that rely on a custom service UUID to find each other in the background can fail to meet, even though each one works in the foreground.
Advertising is public
Advertising data is broadcast in the clear to anyone in range. Do not put secrets, personal names or stable identifiers in it that would let someone track a device over time. Keep it to what a scanner needs to decide whether to connect, and move everything else to an encrypted exchange after the connection is made.