iBeacon / Eddystone

Standardized BLE beacon advertisement protocols defining how beacons broadcast their identity and data. iBeacon was introduced by Apple in 2013; Eddystone was introduced by Google in 2015 (now deprecated). Both define the format of BLE advertisement packets enabling any compatible receiver to detect and interpret beacon signals. Widely used as the foundation for proximity detection, indoor positioning, and asset tracking in BLE RTLS deployments.

iBeacon (Apple, 2013) defines a BLE advertisement format broadcasting: UUID (16-byte identifier grouping beacons by deployment or organization), Major value (2-byte identifier grouping beacons within a deployment, e.g., by floor or zone), Minor value (2-byte identifier uniquely identifying individual beacon), and TX Power (reference RSSI at 1 meter used for distance estimation). Receiving devices compare measured RSSI against TX Power to estimate proximity (Immediate: under 0.5 m, Near: 0.5-3 m, Far: over 3 m). iBeacon advertisement interval typically 100 ms to 1 second, battery life 1-3 years on CR2032. Eddystone (Google, 2015, deprecated 2018) extended iBeacon with additional frame types: Eddystone-UID (unique beacon identifier), Eddystone-URL (broadcasts web URL for Physical Web), Eddystone-TLM (telemetry: battery voltage, temperature, packet count), and Eddystone-EID (ephemeral identifier for security). Despite Eddystone deprecation, its TLM frame remains used by some vendors for beacon health monitoring. AltBeacon is an open-source alternative to iBeacon with similar structure but no proprietary restrictions.

Industrial RTLS relevance: iBeacon/Eddystone protocols are used in BLE RTLS as the advertisement layer enabling gateways to detect and identify mobile tags. Most industrial BLE tags broadcast iBeacon-compatible advertisements, allowing any BLE gateway to receive and forward detections to the positioning engine regardless of vendor. This standardization enables multi-vendor BLE ecosystems where tags from one vendor can be detected by infrastructure from another. However, for BLE direction finding (AoA/AoD), standard iBeacon format must be extended with Constant Tone Extension (CTE) data defined in Bluetooth 5.1, requiring compatible hardware and firmware beyond basic iBeacon. In practice, industrial RTLS vendors typically use iBeacon format as baseline with proprietary extensions for advanced features (sensor data, security, update rate control), balancing interoperability with performance optimization.