Bluetooth LE beacons have shifted beyond prototypes and pilots into large-scale distribution. But this shift has brought us bumping up against the downside to a beacon’s elegance and simplicity. Because if a beacon is a relatively simple (and dumb) device, how do you intelligently manage them at scale?
One company thinks it has a solution. Meraki, a division of Cisco, launched a WiFi end point which can both act as a beacon and monitor devices in the area, report back to a cloud-based dashboard, and allow you to manage and shape WiFi traffic at the same time.
I spoke recently to the Meraki team. Adam Weis and Simon Tompson gave me an overview of their system and approach. For a company that’s managing massive networks of WiFi end points (70,000 hotel rooms in one case), they know a thing or two about fleet management.
And as beacons shift into distribution at scale, their approach will both help relieve some of the pain of beacon monitoring while offering the possibly larger advantage of being able to shape WiFi traffic and monitor WiFi networks from the same intuitive dashboard.
Beacons Call Home
The beauty of iBeacon (the trademarked term by Apple for its preferred configuration for the open standard of the Bluetooth Smart devices) was its simplicity. Apple did the heavy lifting in thinking about how beacons could be configured, provided easy-to-use software tools to help you create apps, and then stood back while the media branded the beacon industry with the iBeacon brush.
The move by Apple helped to accelerate an industry. By opening up support for beacon detection (and using your phone or tablet to broadcast as a beacon), we finally had a single standard that would work across all the major phone platforms. And by making the tools simple to use, it spurred a wave of innovation and testing which took advantage of the fact that a beacon doesn’t actually do very much.
Like any radio transmitter, a beacon transmits a signal. The signal contains a small packet of data (which also helps protect battery usage on both the beacon and the user’s phone), and that data includes unique ID numbers, some power and battery data, and a signal strength – all of which are used to identify which beacon you’ve detected and how far away you are.
But as the industry rapidly matured, this simplicity also started to show some cracks.
There was a scramble to make developing beacon detection for Android as simple as it was for Apple. And with Apple willing to enforce its trademarks and proprietary specifications, we started seeing separate beacon broadcasting specifications emerge, with a better-known example being the AltBeacon standard.
Beacon manufacturers emerged and took advantage of how relatively simple it was to build a beacon. But their simplicity came at a cost: it’s easy to create a beacon, configure it, put in a coin cell battery, and attach it to your wall.
But the beacons didn’t do much more than their original purpose. They broadcast a signal but they didn’t receive anything. If you wanted to reconfigure them or monitor their battery you needed to use an app while standing next to the beacon.
Your beacons, in other words, had no way to call home.
Managing Beacons at Scale
For a retailer, the idea that you’d deploy thousands of beacons across hundreds of locations and have no simple way to manage or monitor the devices without sending out staff seemed like a non-starter.
In the early days of the industry, more than one beacon company told me that managing your beacons wasn’t necessary: the devices were so cheap you could just throw them out when they died. But try telling that to a national retailer (or even a large museum!). Because the cost of training staff and sending them out to pop a new beacon on the wall was an instant deterrent to large installations.
The solutions included payloads embedded in user apps, extending the battery life through improved beacon performance, embedding beacons in light bulbs, or plugging them in. By making beacons last longer, the need to replace them would decrease.
But it was clear that beacon fleet management would quickly become a differentiator for the companies that could manage it well. Companies like Netclearance Systems launched a cloud management system and Kontakt.io recently launched its Cloud Beacon.
These solutions relied on placing another device in a store or venue: a sort of “hub” which could both call home and send/receive data, and could connect with beacons in the area in order to update their firmware, change their IDs, or monitor their batteries or performance.
In a World of WiFi, We Have An Endpoint
But Meraki thought it had a more elegant solution. Because why add another device to your location when you already need a box for the most pervasive endpoints available: WiFi.
The company has changed the game for how institutions manage WiFi infrastructure – moving us from the dark ages of what often looked like a command line interfaces to an elegant cloud-based solution that had a lot in common with the most intuitive dashboards available.
This was industrial scale WiFi management with a dashboard your mother might even love.
They took the pain out of managing WiFi endpoints. Organizations ranging from universities to hotel chains deploy, manage, monitor, secure and shape traffic for often widely distributed systems – and with Meraki do so in an intuitive way. (They were so successful that Cisco snapped them up).
So Meraki had a simple premise: since you’re already monitoring your WiFi with their endpoints, why not also use that same dashboard to monitor nearby beacons?
And while they were at it, they threw in the capacity of their WiFi box to ACT as a beacon – a boon to a smaller location that might not need a beacon in every aisle but just wants to send a beacon message when you arrive at the front door.
Their solution solved a simple problem: can I easily monitor all the beacons in the area, keep an eye on their batteries and other signals, and do something useful with the data?
Adam Weis, a brilliant guy and someone who helped drive a lot of the thinking behind the Meraki approach, explains:
Is Monitoring and Configuring the Same Thing?
The Meraki system is simple. It has an incredibly elegant and easy-to-use interface. It not only broadcasts as a beacon, but lets you monitor for ALL Bluetooth-enabled devices in its region:
It helps answer one of the more pressing challenges of fleet management: making sure your beacons are still working and that their batteries haven’t run out. By also monitoring other devices in the region, Meraki is providing a richer data set. I can now compare, for example, the number of total devices and then cross-tabulate that data to the number of beacon “app impressions”.
Meraki can’t, however, update a beacon’s firmware or update their UUIDs. To do that, you need to be able to “pair” with the beacon and the pairing is usually handled by tools provided by the beacon manufacturer. In many cases this might not be an issue – but an ideal scenario would be for Meraki to also partner with beacon manufacturers to allow institutions to also PAIR with the beacons via the Meraki dashboard.
In the meantime, it’s where solutions like the Kontakt Cloud Beacon come in – systems to manage your fleet of beacons and their ID numbers, but without the advantage of being a full WiFi endpoint.
WiFi + Beacon Is A Big Win for Many Use Cases
But let’s face it – in many cases, Meraki is enough. A library, for example, probably doesn’t need to swap the UUIDs of its beacons very often and firmware updates aren’t usually deployed, or rarely. And Meraki offers the advantage that it takes care of another key challenge in creating a ‘connected space’ – you need to manage WiFi access as well, shape WiFi traffic, and would prefer to do so in an intuitive way.
If your WiFi network can also ACT as a beacon and monitor the small fleet you have set up in your hotel lobby, say, then you’re getting two for the price of one: an intuitive WiFi management tool, a beacon, and the ability to monitor any additional beacons you place in your space.
Where Technologies Intersect
But there might be something more profound at play.
Because as beacons have shifted into larger deployments, they’ve also shifted into being just one of several technologies being used to ‘digitize physical space’. And it intrigues me to think about a future in which beacon detection can be combined with network monitoring and access management and then be used to shape new kinds of experiences in a location.
Today, you drop by a Starbucks and hop on a WiFi network. But in the future, a combination of beacon interactions and WiFi access might be combined to create new kinds of experiences.
We call beacons the “gateway drug to the Internet of Things”. They’ve been easy to understand. And they open our eyes to a world in which physical space is a new digital touch point. As they start to intersect with other technologies their management will become more complex but the types of interactions we can enable will also become more elegant, more innovative, and hopefully more useful to the end user.
Meraki has shown us one way that beacon technology will start to intersect with others. As we create the digital fabrics of physical space, it’s an early indicator that the beacon era is just getting started.
Share Your Thoughts
Join our e-mail list for more on iBeacons and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.
What other technologies will beacons intersect with? What are the use cases for WiFi and beacon monitoring and where do you see Meraki fitting into your plans? Drop a line below.
BEEKn 