Bluetooth Technology
and the Physical Web

Much has been written about Bluetooth^® beacons and, in fact, I wrote a three-part series last year — read part one here.

In the past, applications of beacons tended to use either Apple’s iBeacon™ data format or the AltBeacon format from Radius Networks. These two beacon types and the way they are used by developers are very similar. Google, meanwhile, has been taking a fresh and different look at Bluetooth beacons under the banner of their Physical Web project and last year released details of their new Bluetooth beacon format which they called Eddystone after the famous lighthouse of that name.

The Physical Web

It’s a great name for a project and it has a tagline which captures its aims quite succinctly: “Walk up and use anything.”

It’s a simple statement but one that hides a powerful concept. Anyone (human or otherwise) should be able to approach any physical object and use it from a suitable computing device like a smartphone and all without the need to install a special, custom application which understands the physical object. Sound familiar?

It’s familiar because we’re already accustomed to using a general purpose application to interact with the World Wide Web — an application which is powerful enough to consume and process content of widely varying types from any web server on the planet. It can render text, gather information securely, play back videos, and allow me to interact in real time with games and much more. I am of course referring to the not so humble web browser.

Are Apps Really the New Browser?

For a while, it was suggested that the browser was less important on mobile computing devices with users preferring to install custom applications for specific purposes. This may or may not be true in the most general sense.

But let’s return to the world of Bluetooth Beacons. With iBeacon and AltBeacon, a unique ID is broadcast in Bluetooth advertising packets. That ID represents something, typically a physical location like the Sporting Goods department of the Kingston-Upon-Thames store or an item of interest like the T-Rex exhibit in a museum. These IDs are allocated by the organisation owning the beacons and therefore only they know what they represent. To map a beacon ID to a specific and meaningful piece of information requires a custom application on a smartphone. Organisations deploying beacons must develop that application and persuade their customers to download and install it. With the application installed, customers can benefit from the beacon service. Without it, the beacons may as well not exist. They’re invisible to such users.

Google is equipping their Chrome browser with the ability to respond to beacon messages without advanced knowledge of what those beacons are trying to say. In Google’s world of the physical web, the only beacon application you need to install is the browser, and you already have that.

Eddystone

The physical web leverages Eddystone beacons. So how do Eddystone beacons differ from  iBeacon™ and AltBeacon beacons?

iBeacon™ and AltBeacon both use the Manufacturer Data field in Bluetooth^® advertising packets to contain a unique number which encodes the organisation that owns the beacons and the location or object of interest the beacon indicates. Figure 1 shows the two Manufacturer Data formats as used by these two remarkably similar beacon formats side by side.

Eddystone does not use the Manufacturer Data field. Instead, it places a value of 0xFEAA in the complete list of 16-bit Service UUIDs field and uses the associated Service Data field as the container for beacon information. The specification provides full details.

In further contrast to the other beacon formats, Eddystone defines a number of frame types so that a beacon can transmit various distinct types of information. Right now, three types are defined:

The UID frame type is similar in concept and purpose to the IDs used in iBeacon™ and AltBeacon beacons. Where things get really interesting is with the second frame type, the URL. It’s the URL frame type which really is at the heart of Google’s physical web.

Walk Up and Use Anything

It’s not hard to imagine how this works in practice. Simply walk up to a bus stop, a vending machine, or even a lost puppy with a collar. If there is an Eddystone beacon embedded and your smartphone’s browser can respond in a sensible and contextual way, it can tell you when the next bus is due, allow you to order a tasty beverage, or present you with details of the lost puppy’s owner so you can help it home — unless you’re into dognapping which we do not endorse, even when the puppy is *really* cute!

State of Play

Google Chrome for iOS supports Eddystone beacons and the physical web. The next version of Chrome, version 49 will add Eddystone support for Android users too.

The relationship between the browser and Bluetooth^® technology is not just about beacons. The W3C have a community group working on JavaScript APIs for web developers that allow web content to securely communicate with Bluetooth devices as well — see https://www.w3.org/community/web-bluetooth/.

The all-important browser and Bluetooth are becoming the best of friends. The physical web is on its way and we can’t wait to see what Google and its developer community do with it.