Beacon protocols: Creating the language of beacons
Like any other technology, beacons need a protocol that facilitates the integration of manufacturing, programming, transmission and general functionality. Every tech product needs the rules of the game to be defined so that parameters and specifications are clear to anyone who wants to join. The creation of a standard for the growth of any early-stage technology helps to promote it focusing development around the protocol and preventing incompatible standards from fracturing the market and confusing consumers.
We’re all familiar with industries in which competing standards resulted in showdowns that produced a winner and, well, everyone else. Think of Blu-ray’s victory over HD DVD. Protocols like USB, HTML, 4G and a long list of others became industry standards in similar ways after rivals faded away. For those products, the market demanded a single standard for greatest efficiency. One got pushed to the top and others got pushed out the door.
There are, however, instances when similar standards occupy the same market space but accomplish tasks in different ways and with distinct advantages and disadvantages. Both mp3 and FLAC are audio formats but they occupy separate niches and are not in direct competition.
Both solutions offer the same utility although they may each offer certain benefits the other does not.
When things like cost and performance are basically identical, consumers often show no strong preference for one or the other. The choice between Coke and Pepsi rarely ignites much passion because we see them as substitutes for one another.
This is the scenario that most closely applies to the two main standards for Bluetooth beacon communication, iBeacon and Eddystone. Both of them are broadcasting protocols based on Bluetooth 4.0, both of them fully support beacon deployments and they both offer essentially the same functionality while featuring small extras the other does not.
They’re also both backed by tech giants who supply the protocols as a way to bridge the physical and digital worlds.
It’s important to remember that neither iBeacon nor Eddystone are pieces of hardware. You can’t hold them in your hand. They are software protocols that provide the communication standards for beacons made by third parties. Beacons – the hardware part of beacon deployments – can support one format or the other or both. Think of iBeacon and Eddystone as the languages that the devices speak when they communicate with the world.
Two big players are behind the most commonly used protocols for those small devices. Let’s take a look at who they are and how their standards for broadcasting beacon signals compare.
The first beacon standard, Apple’s iBeacon
At its 2013 Worldwide Developers Conference, Apple noted, almost in passing among bigger announcements, that it was releasing a platform for beacon development, iBeacon. In doing so, Apple laid the foundation for the emergence of the beacon industry and the world of proximity solutions. Almost immediately after it was released, iBeacon was installed in Apple’s company stores to highlight its retail applications and give curious early adopters a first look. iBeacon was also added to iOS 7, which meant it would be included in all iPhones and thus immediately accessible to millions. This significant user base was enough to jump-start the development community around beacons and accelerate interest in the potential applications of proximity infrastructures.
The fact that Apple’s name was attached to everything did much to push awareness of beacon technology into the mainstream even if it also caused confusion among those who thought that iBeacon was a physical product instead of a software platform. This is understandable since we’re talking about the people who gave us the iPod, iPad, iMac and iPhone – why wouldn’t the average person on the street think the iBeacon was the next must-have device?
As with other Apple products, the software that powers iBeacon is a proprietary, closed standard. Naturally, Apple made software development kits (SDKs) available for third parties to build beacon applications but the core of iBeacon’s code remains locked away in Cupertino, California.
You’ll find informative and detailed explanations of how beacons work here and here so let’s keep things in simple terms for our purposes by focusing only the role of iBeacon and Eddystone in beacon infrastructures.
The signal that iBeacon broadcasts contains three pieces of information and each has a role in how information from the beacon is interpreted and used. The four components are:
- A Universally Unique Identifier (UUID) that identifies the beacon (Its role is to say, for example, “This beacon belongs to Company X”)
- A Major number that identifies the beacon as part of a group (UUID + Major says “This beacon is in Company X’s store in Location Y”)
- A Minor number that identifies a specific beacon (UUID + Major + Minor says “This beacon is in Company X’s store in Location Y by the entrance”)
When data from applications is collected and analyzed, these three parts of the iBeacon signal make it possible to do things like track movement within a location (because, for example, you know that a device moved from the range of a beacon with one Minor to another) or know more about which store locations certain customers like to visit (because you know which app users interacted with a given beacon Major).
iBeacon is obviously native to devices running on Apple’s iOS and so it runs more smoothly and has slightly faster response times but it also supports Android devices, meaning that applications installed on Android phones will interact normally with iBeacon signals.
Google’s open beacon format, Eddystone
The Eddystone Lighthouse, just off the southwest coast of England, has been guiding ships to safety with its signal for centuries. Google thought this was the perfect concept to illustrate the role of beacons to a wider audience and borrowed the lighthouse’s name for the beacon communication protocol it introduced in 2015. With Eddystone, Google supplied an open-source protocol for developers of beacon apps working in the new world of proximity technology that Apple created two years before.
Eddystone brought a twist to beacon signals by making it possible to get more information in them through the use of three “packets”, spaces for additional pieces of information that can be used in various ways. The first of the three serves the same purpose as the information contained in the iBeacon signal as explained above, with codes used to identify who beacons belong to and where they’re being used.
The second data “packet” is what really made Eddystone stand out and is a big part of its appeal for developers – the ability to push a URL directly to a device without the need to create an application. Instead of needing an application that gets information from a server about what to do when a device is activated by a given beacon and then transmitting that command back to the device, Eddystone lets beacons send a URL directly to that smartphone or tablet. This ability to directly provide users with an online destination quickly became a common way to use beacons because it was so easy to do.
The third piece of data that Eddystone enables allows beacons to transmit information about the physical and environmental conditions that may threaten its performance like temperature and humidity and trigger actions based on those conditions.
Developers can choose to enable each packet individually, meaning that they don’t all have to be used if not needed.
Eddystone is native to Android, Google’s open operating system, and so any device running on it is ready to interact with beacons that “speak” Eddystone. Just like iBeacon, Eddystone is fully compatible with its “opposite” and so it supports iOS devices as well. Also, being open source means that developers can contribute to its development.
So what’s the difference between iBeacon and Eddystone?
For all practical purposes, the differences between iBeacon and Eddystone are as small as the beacons they power. Any distinctions that do exist between them are on the margins of their functionalities. There’s no reason for an end user to be aware of anything regarding the slightly different ways that they support proximity solutions.
As noted, both protocols work with both iOS and Android devices. There is no issue of incompatibility involved with beacon transmissions to 95+% of all the smart devices in the world. On top of that, beacons are capable of broadcasting in both signals, or “interleaving”, thus ensuring that all beacons can communicate with almost every smart device on the planet regardless of the operating system it uses.
So, from the perspective of end users, the honest answer to the question of “What’s the difference between iBeacon and Eddystone?” is a simple “Not much.”
Each protocol can duplicate the functionalities of the other even if they take different paths to get it done. To the extent that some of those paths are more direct than others, the difference in the time it takes to execute commands is only perceptible to machines and no end user will ever know the difference.
Developers of beacon applications might disagree a bit about the differences between the two protocols but mostly over technical things beyond the scope of our focus here and well beyond anything of interest to end users of those apps.