Beacons and Physical Web Essentials
I see references to Beacon, iBeacon and The Physical Web technologies nearly every day, but I still do not have a great understanding of the technology, so I requested my friend, uber geek and Cognizant digital/mobile expert, Peter Rogers, to give us a deep dive. Thanks Peter!
Beacon technology uses strategically placed bluetooth sensors to recognize individual smartphones in close proximity and to automatically send them messages relevant to their locations. For instance you walk up to a table full of boots, and instantly your phone vibrates and there is a discount coupon on your phone specific to the boots. Wow! How did my smartphone know I was standing in front of boots? How did the retail store know I was standing if front of boots. In this article you can begin to understand the technology behind these capabilities and how you might benefit.
Basic Beacons 101:
- Beacons do not push out notifications. They broadcast an advertisement of themselves (traditionally their UUID, major and minor values) and can be detected by Bluetooth Low Energy (BLE) devices.
- The proximity from a number of Beacons can be measured using typical triangulation techniques in order to get a (very) rough idea of (typically) indoor location.
- The Beacon UUID, major and minor version values are typically used for identification and used to map to either a message, service, media content, website, application or location inside the Native App.
- Beacons can have their UUID, major and minor versions (and indeed power level) modified statically before deployment or dynamically using WiFi connectivity. A Beacon Management App is often provided by a Beacon Platform Vendor to allow you to manage these values dynamically.
- Updating the Beacon major and minor values can be used to update the identity of the Beacons and subsequently change what they map to inside the Native App. This does mean there is a security risk of somebody remotely hacking your Beacons and changing their values to take down or corrupt your service.
- iBeacon is Apple’s proprietary BLE profile but their patents seem to cover more than just the profile aspect. There were Beacons before iBeacons. Apple did not invent the Beacon. What they did is an incredibly good job of integrating Beacon support into iOS. iBeacon is not a piece of hardware. It is a BLE profile that is loaded onto a piece of hardware. This profile makes the Beacon an iBeacon.
- There are many Beacon vendors who offer various capabilities such as: BlueCats; BlueSense; Gelo; Kontakt.io; Glimworm; Sensorberg; Sonic Notify; beaconstac; mibeacon (Mubaloo); estimote; Gimbal (Qualcomm); Apple; and Google, etc.
Beacon vendors offer a range of products and services such as:
- proprietary BLE Beacon profiles
- support for popular profiles
- remote Beacon management
- associated content management
- marketing campaigns
- software version management
- profile switching
- client side SDKs
- professional support services
Most do not offer the whole solution, and so it was interesting to see Apple and then Google throw their hat into the ring. Most people are still really excited about Apple’s iBeacons, but they look like they will become a closed eco-system which could possibly even include being able to be physically undetectable to non-Apple hardware. Today Beacon vendors are just not allowed to provide library based support for iBeacons on Android hardware (http://beekn.net/2014/07/ibeacon-for-android/).
At the start of 2015 Google created a new form of Beacon called UriBeacon (http://uribeacon.io/) which was able to actually advertise a URL pointing to a website or a URL that could be processed locally. This was in stark contrast to all the previous forms of Beacon which could only advertise their identity (UUID, minor, major). UriBeacons also promised to be cheaper and easier to configure, which was largely down to their more limited use case of just being used to advertise a URL/URI. The killer concept, however, was that of The Physical Web. The Physical Web is an approach to unleash the core superpower of the web: interaction on demand. People should be able to walk up to any smart device and not have to download an app first. A small pre-installed App (like the Web Browser or something Operating System level) on the phone scans for URLs that are nearby. Google previously used the UriBeacon format to find nearby URLs without requiring any centralized registrar.
This was a major breakthrough because having to download an App for each Beacon vendor completely breaks the organic, intelligent, evolutionary Smart City model. Notice that I used the words ‘without having to download an App’. You still need an App to process the UriBeacons, however, this can be built into the Web Browser (Chrome offers this for iOS) or the Operating System (Android M offers this). The following vendors offer UriBeacons: Blesh; BKON; iBliO; KST; and twocanoes, etc.
Recently Google updated their single-case UriBeacon specification to that of Eddystone. Eddystone is an open-source cross-platform beacon solution that supports broadcasting of UUID, URL, EIDs and Telemetry data. Previously Beacons had only supported UUID until UriBeacons offered the single option of URL advertisement. Eddystone offers an additional two frame types: Ephemeral ID is an ID which changes frequently and is only available to an authorised app; Telemetry is data about the beacon or attached sensors: e.g. battery life, temperature, humidity. Unlike iBeacons, which must be approved by Apple, anyone can make an Eddystone-compatible beacon. Current beacon manufacturers include: Estimote; Kontakt; and Radius Networks, etc.
The Eddystone-URL frame broadcasts a URL using a compressed encoding format in order to fit more within the limited advertisement packet. Once decoded, the URL can be used by any client with access to the internet. For example, if an Eddystone-URL beacon were to broadcast A URL then any client that received this packet and with an Internet connection could choose to visit that URL (probably over WiFi). You can use an App to manage that experience and either take you directly to the URL or process a URI internally to perform some other function without network connectivity. Better still The Physical Web initiative has moved away from UriBeacon to the open initiative of Eddystone.
Now one thing to realise is that Eddystone may support iOS but that obviously does not include integration with CoreLocation as per iBeacons. Eddystone beacons only interact with iOS devices via CoreBluetooth which means you have more work to do. Likewise, on Android M there are a whole bunch of new APIs and those will not be available on iOS.
- The Nearby API makes it easy for apps to find and communicate with beacons to get specific information and context. Apparently it uses a combination of Bluetooth, Wi-Fi, and inaudible sound.
- Nearby provides a proximity API called Nearby Messages in which iOS devices, Android devices and Beacons can discover, communicate and share data/content with each other.
- Place Picker is an extension of Places API that can show Beacons in your immediate vicinity. The Places API is also able to read and write Beacon positioning information (GPS coordinates, indoor floor level, etc.) from/to the Google Places database using a unique Place ID based around the Beacon UUID and then have the Beacons navigable though Google Maps. This would provide a much better retail solution where customers could literally Google “Hair Shampoo” inside a Boots store and be taken directly to the product using indoor positioning.
I am sure you have many questions such as, can a Beacon run iBeacon and Eddystone simultaneously. At the moment the Beacon vendors offer the ability to support both profiles but not simultaneously. This is apparently due to battery usage. Most vendors do seem to support simultaneous broadcast of UUID, URL and Telemetrics within Eddystone though. For any other questions then here is a fantastic Q&A on Eddystone from Kontakt.io (http://kontakt.io/blog/eddystone-faq/).
The Physical Web has now moved away from UriBeacon and onto Eddystone-URL frames. A few months ago, Chrome for iOS added a Today widget. The new Chrome for iOS integrates the Physical Web into the Chrome Today widget, enabling users to access an on-demand list of web content that is relevant to their surroundings. The Physical Web displays content that is broadcasted using Eddystone-URL format. You can add your content to the Physical Web by simply configuring a beacon that supports Eddystone-URL to transmit your URL of choice. When users who have enabled the Physical Web open the Today view, the Chrome widget scans for broadcasted URLs and displays these results, using estimated proximity of the beacons to rank the content.
The Physical Web also support finding URLs through Wifi using mDNS (and uPnP). The multicast Domain Name System (mDNS) resolves host names to IP addresses within small networks that do not include a local name server. It is a zero-configuration service, using essentially the same programming interfaces, packet formats and operating semantics as DNS. While designed by Stuart Cheshire to be stand-alone capable, it can work in concert with DNS servers. The mDNS protocol is implemented by the Apple Bonjour and by Linux nss-mdns services. In other words rather than waiting for your client to discover a Beacon advertising a UUID or URL then you could actually start searching for local services hosted on Beacons using a multicast form of DNS. Beacons are actually more powerful than most people realise and can often run micro-services on them. In fact if we think about it then Beacon based services are the ultimate form of a micro-service architecture. Brillo is an upcoming Android-based operating system for IoT devices and this lightweight OS could theoretically run on a Beacon which would enable a portable way of deploying a Beacon based micro-service architecture.