The underlying model without marketing language
Bluetooth Low Energy (BLE) broadcasting is the mechanism that makes proximity beacons work. Rather than forming a two-way connection like a Bluetooth headset pairing with a phone, a beacon simply transmits a small packet of data at regular intervals. Any device within range that is listening for BLE signals can receive that packet without ever pairing or connecting.
This one-way, connectionless approach is what separates BLE broadcasting from classic Bluetooth. Classic Bluetooth devices negotiate a connection, maintain it, and exchange data in both directions. A broadcasting beacon does none of that. It transmits into the room at a set power level and cadence, and nearby devices either hear it or they do not.
The transmitted data arrives in an advertising packet. This packet is small — typically well under 50 bytes — and contains a limited set of information. Within that packet sit identifiers that tell a receiving app or platform which beacon is transmitting and, by extension, where the user is standing. The detailed structure of those identifiers is covered in the next article in this series, but the key point here is that the packet itself is tiny and fixed until someone physically reprogrammes the beacon.
BLE uses three dedicated advertising channels — numbered 37, 38 and 39 — which sit outside the main data channels used for connected Bluetooth communication. This separation helps advertising packets cut through interference from other Bluetooth devices. The beacon cycles through these three channels each time it transmits, giving receiving devices multiple chances to pick up the signal even if one channel is temporarily congested.
Two settings on the beacon directly shape how the system behaves in practice: the advertising interval and the transmit power.
The advertising interval is the gap between consecutive transmissions, typically configurable from around 100 milliseconds up to several seconds. A shorter interval means a receiving device has more opportunities to detect the beacon in a given period, which improves responsiveness at the cost of battery life. A longer interval conserves the battery but introduces a noticeable lag — a visitor might walk past a beacon before their device catches a transmission.
The transmit power controls how strongly the beacon broadcasts, measured in decibels relative to one milliwatt (dBm). A higher transmit power pushes the signal further, but it also increases the chance of the signal bleeding into adjacent zones and causing interference with other beacons. A lower transmit power keeps the signal contained, which is often preferable when you need tight zone boundaries.
It is worth emphasising that broadcasting is entirely one-sided. The beacon has no idea whether anyone is listening, how many devices detected it, or what those devices did with the information. All of that logic — detection, interpretation, triggering a notification, logging an event — happens on the receiving device or on a backend server, not on the beacon itself.
Devices, environment and user behaviour
Understanding broadcasting behaviour matters because the settings you choose dictate what is physically possible in your space.
In a retail environment, a common approach is to place beacons near entrance points or specific product displays. The advertising interval needs to be short enough that a customer's phone detects the beacon within a second or two of entering the zone, but not so short that the beacon's battery drains in weeks rather than months. Transmit power is typically set low enough that the signal does not reach across the shop floor to a neighbouring zone, which would trigger the wrong notification.
Museums face a different challenge. Exhibits are often close together, and visitors move slowly. Here, a lower transmit power combined with a moderate advertising interval keeps each beacon's reach limited to its own exhibit case. If two beacons overlap, the receiving app needs clear logic to decide which exhibit the visitor is actually standing at — a problem that starts with how the beacons are configured to broadcast.
For events, the infrastructure is temporary and the environment changes rapidly. A conference might use beacons to mark session rooms, registration areas and sponsor stands. Because the layout is not permanent, broadcasting settings may need adjusting on-site once the physical structures are in place and interference from other equipment — Wi-Fi access points, PA systems, LED lighting drivers — becomes measurable.
The choice of advertising interval and transmit power always involves a trade-off between three things: detection responsiveness, battery life and zone precision. You cannot optimise all three simultaneously. A beacon set to broadcast every 100 milliseconds at maximum power will be detected almost instantly but may last only a fraction of its rated battery life and will almost certainly bleed into neighbouring zones. A beacon set to broadcast every two seconds at minimum power will run for a long time and stay neatly contained, but visitors may walk well past it before their device registers a detection.
The receiving side also constrains what broadcasting can achieve. On iOS, apps can scan for BLE beacons in the background, but the operating system throttles how often those scans occur and may delay delivery of detections to preserve battery. On Android, background scanning behaviour varies by manufacturer and OS version. Web Bluetooth, which would allow detection without a native app, has significant limitations on both platforms and is not a reliable foundation for beacon-based systems. These receiving-side constraints mean that even a perfectly configured beacon cannot guarantee instant or consistent detection.
Common misunderstandings and checks
The most frequent mistake is treating the beacon's theoretical range as its reliable detection range. A manufacturer might state a range of up to 70 metres, but that figure assumes open air, no obstructions and an ideal receiver. In a real retail unit, museum gallery or event hall, walls, shelving, display cases and the bodies of other visitors all attenuate the signal. The distance at which a phone consistently detects a beacon is often far shorter than the stated maximum.
A second common error is configuring all beacons with identical settings regardless of their location. A beacon mounted high on a ceiling in an open atrium can reasonably use a higher transmit power than a beacon tucked behind a till point in a cramped corridor. Treating the entire site as a uniform environment leads to overlapping zones, missed detections or both.
Assuming that broadcasting guarantees detection is another pitfall. BLE operates in the 2.4 GHz band, which is shared with Wi-Fi, microwaves, some wireless cameras and other Bluetooth devices. In a busy venue, a meaningful proportion of advertising packets may be lost to interference. The three-channel advertising design helps, but it does not eliminate the problem entirely.
Failing to test with a representative set of devices also causes problems. A system that works reliably with a recent iPhone may behave differently with an older Android phone, or with a device in a thick case. If your visitors use a mix of hardware — and they almost certainly do — your pilot should include the devices your audience actually carries, not just the test phone your integrator brought to the site.
Before accepting a deployment, run through these checks:
- Verify the advertising interval configured on each beacon using the manufacturer's own tools or a trusted diagnostic app, rather than relying on a configuration screenshot.
- Measure the actual transmit power with a signal strength metre or a phone running an RSSI logging app, and compare it to the intended setting.
- Walk the space with multiple devices and note where detections are missed, delayed or triggered in the wrong zone.
- Check that beacons in adjacent zones are not detectable from each other's territory at the configured power level.
- Confirm that the advertising packet format matches what your receiving app or platform expects — a mismatch here means every transmission is silently ignored.
- Ask your integrator or supplier for the exact firmware version on the beacons and check whether any known issues affect the broadcasting behaviour you are relying on.
BLE broadcasting is a straightforward mechanism, but the gap between what the beacon does and what the visitor experiences is wide. The beacon simply transmits. Everything else — detection, interpretation, relevance, timing — depends on how well that transmission is tuned to the physical space and the devices moving through it.
The packet format is only one layer
iBeacon, AltBeacon and Eddystone describe payload layouts, not a complete proximity service. The receiving application still needs permission, scanning behaviour, identifier mapping and a fallback. A configurable payload can make hardware reusable, but it also requires access control and change records so that identifiers are not duplicated or silently redirected.
