Apple announced iBeacon (protocol/firmware) in December 2013.
- iBeacon is proprietary to Apple, and officially only works with iOS. However, many Android SDKs do effectively monitor iBeacon devices.
- iBeacon transmits a UUID (16 digit string of numbers), Major (4 digits) and Minor (4 digits). That’s it. Nothing else. They aren’t mini-servers or tracking devices. Beacons themselves do not track anything. Apps do the tracking if that’s what they are programmed to do.
- iBeacon requires an app be programmed to recognize the specific UUID established for that app to be able to engage.
- The UUID is typically the same for all iBeacons working with a specific app. The “Major” and “Minor” IDs are used to identify each beacon uniquely.
- iBeacon provides two ways to detect devices:
- Monitoring: works even if the app is in a killed state
- Ranging: works only for active apps.
Google announced EddystoneTM (protocol/firmware) in July 2015. Side note: it was called UriBeacon for a while, then it was announced that the tech had evolved beyond the original specs. To differentiate, they changed the name to Eddystone.
Eddystone is an open protocol. Beacons with support for Eddystone can transmit four different frame types: Eddystone-URL, Eddystone-UID, Eddystone-EID and Eddystone-TLM. All four frame types work with iOS and Android.
- Eddystone-URL is the beacon format for the “Physical Web”, where you put content if you want everybody to be able to access it.
- Eddystone-URL does NOT require a custom app. It works with beacon scanners (sometimes referred to as beacon browsers). Upside: you don’t need to build/develop an app.
- Eddystone-URL will also work with compatible apps for inbound marketing initiatives, and we offer an SDK to easily make any app compatible.
- Eddystone-URL broadcasts a URL, which is simply a web page. Nothing complicated about it. You can link to any site on the Internet.
- Those links can be easily managed with our PHY.net platform.
- Eddystone-UID requires an app to receive that specific UID for your app to be able to engage.
- Eddystone is very similar to iBeacon, but it only broadcasts a 16 digit string of characters, divided into a 10 character “Namespace” and a 6 character “Instance” ID. Typically the Namespace is used to identify an entity and the Instance an individual beacon.
- No two beacons will ever have the same UID.
- Eddystone-UID works in conjunction with Google’s Beacon Registry, and multiple apps can make use of the same beacons.
- Eddystone-EID functions like Eddystone-UID except that it is designed for heightened security.
- EID stands for Ephemeral ID, and rather than a fixed namespace and instance ID, the EID is a seemingly random identifier.
- The EID is resolved in the Google Beacon Registry, where it can return attachments assigned to it from the Google Proximity API or the Google Developer’s Console.
- The rotating nature of the EID secures it from hijacking, spoofing, and it prevents consumers from being tracked by fixed ID beacons.
- Eddystone-TLM bridges both App and Browser uses. (TLM = Telemetry) and is designed to be broadcast alongside UID or UID/URL beacons.
- The main function of Eddystone is to transmit sensor and administrative data from the beacon itself. Currently, this frame includes the beacon’s battery state, its temperature, the time since power-on, and a count of the advertising packets since power-on, but it could also include other sensor data in the future.
Enough of the Tech Talk
We know that some people don’t want the tech, they just want the high-level overview. If that’s what you’re looking for, check out our blog post, “A Simplified Explanation of iBeacon and Eddystone Beacons.” For our latest thinking on the advantages of the Physical Web vs. iBeacon, visit, “The New Conventional Wisdom: ‘Mythbusting’ iBeacon and the Physical Web.”