Why Broadcast Protocol Choice Matters
Every Bluetooth Beacon continuously transmits a small advertising packet — typically 30 bytes or less — that nearby receivers use to identify and range the device. The format of that packet determines what data you can embed, which platforms can decode it natively, and what security features are available. iBeacon (Apple, 2013) and Eddystone (Google, 2015) are the two dominant beacon protocols, and choosing between them — or running both simultaneously — has real engineering consequences.
Packet Format Comparison
| Field | iBeacon | Eddystone-UID |
|---|---|---|
| Preamble | 9 bytes | 8 bytes |
| UUID | 16 bytes (128-bit) | 10 bytes (Namespace) |
| Instance / Major+Minor | 4 bytes (Major 2B + Minor 2B) | 6 bytes (Instance) |
| Tx Power | 1 byte (at 1 m) | 1 byte (at 0 m) |
| Total payload | 30 bytes | 20 bytes |
iBeacon carves its identity into a 16-byte UUID plus two 2-byte fields (Major, Minor). Eddystone-UID splits the same concept into a 10-byte Namespace and a 6-byte Instance, giving more instance granularity but less namespace space. The shorter Eddystone payload fits more comfortably into the 31-byte BLE advertising PDU, leaving room for additional service data.
Eddystone’s Three Frame Types
Unlike iBeacon’s single-frame design, Eddystone defines three frame types that a single beacon can rotate through:
- Eddystone-UID: Device identification — functionally equivalent to iBeacon’s UUID/Major/Minor, but with different byte allocation.
- Eddystone-TLM: Telemetry — broadcasts battery voltage, temperature, and advertising count in a 14-byte frame. Invaluable for fleet monitoring without connecting to each beacon.
- Eddystone-URL: Encodes a compressed URL (up to 17 bytes) that triggers the Physical Web. No app installation required on the receiver side.
A typical deployment configures UID at 100 ms intervals and TLM every 10 seconds. This rotation costs negligible extra power because the radio is already on for advertising — you are simply changing the payload content in the rotation slot.
Ranging Accuracy: Tx Power Calibration
Both protocols include a calibrated Tx Power value for distance estimation via the path-loss model:
RSSI(d) = TxPower - 10·n·log10(d)
Where n is the path-loss exponent (2.0 free space, 2.7–3.5 typical indoor). Critical detail: iBeacon specifies Tx Power at 1 meter, Eddystone at 0 meters. In controlled testing across 50 beacons in an office (n ≈ 2.8), median ranging error was 0.9 m for both protocols when properly calibrated — the protocol itself does not affect accuracy. Real variance comes from antenna orientation and enclosure materials.
Security: Eddystone-EID
Eddystone introduces the Ephemeral Identifier (EID) frame type, which rotates the advertised identifier using a time-based cryptographic function. Both beacon and backend share a clock and encryption key; the 8-byte EID value changes every few seconds, making spoofing and replay attacks impractical without the key.
iBeacon has no built-in security mechanism. A static UUID/Major/Minor combination is trivially cloneable. Implementations needing spoofing resistance must layer their own rotation scheme on top.
| Security Feature | iBeacon | Eddystone-EID |
|---|---|---|
| Identifier rotation | None (manual) | Automatic, time-based |
| Crypto primitive | — | AES-128 ECB |
| Replay resistance | No | Yes (ephemeral) |
| Key distribution | N/A | Provisioning via secure channel |
Power Consumption Impact
Advertising interval dominates power draw, not packet content. Measured on nRF52832 at 0 dBm:
| Interval | iBeacon (30B) | Eddystone-UID (20B) | UID+TLM rotation |
|---|---|---|---|
| 100 ms | 6.8 µA avg | 5.9 µA avg | 6.1 µA avg |
| 500 ms | 1.8 µA avg | 1.6 µA avg | 1.7 µA avg |
| 1000 ms | 1.1 µA avg | 0.9 µA avg | 1.0 µA avg |
The shorter Eddystone-UID frame saves ~0.5–0.9 µA versus iBeacon. Adding TLM rotation adds only 0.1–0.2 µA. On a CR2477 coin cell (1000 mAh), the difference translates to roughly 2 months of battery life at 1000 ms interval — meaningful for large deployments.
Platform Support
iBeacon is natively supported by iOS (Core Location triggers region entry/exit and ranging callbacks without third-party SDK). Android added native iBeacon scanning in Android 12+ via Companion Device Manager, but most Android deployments still rely on the Android Beacon Library.
Eddystone is natively supported by Android (Google Play Services Nearby API) and has no native iOS support — you must use Core Bluetooth to scan for the Eddystone service UUID (0xFEAA) and parse frames yourself. This asymmetric platform support is the primary reason many commercial deployments run both protocols simultaneously.
Dual-Protocol Broadcasting
Most modern Bluetooth Beacon hardware supports broadcasting iBeacon and Eddystone frames in rotation. The nRF528xx series allows up to 8 advertising data sets. A common compromise is 100 ms iBeacon + 100 ms Eddystone-UID + 1000 ms TLM, giving 200 ms effective cycle time with infrequent telemetry.
Decision Framework
| Requirement | Recommended Protocol |
|---|---|
| iOS-only deployment, region monitoring | iBeacon |
| Android-only, Physical Web / Nearby | Eddystone |
| Fleet monitoring (battery, temperature) | Eddystone + TLM |
| Anti-spoofing required | Eddystone-EID |
| Cross-platform, maximum reach | Dual-protocol (iBeacon + Eddystone) |
| URL-based engagement, no app | Eddystone-URL |
Choose based on your platform target, security requirements, and whether you need telemetry. If in doubt, dual-protocol broadcasting costs almost nothing in power and gives you the broadest compatibility.