Oct 2014

Let’s Talk About Beacons

If you’ve been following the tech scene lately, you may have heard a thing or two about “Beacons”. What are Beacons?

Beacons are hardware devices emitting a unique signature that can be picked up by your smartphone. They are typically small and powered by coin-cell batteries, making them easy to stick almost anywhere.

What we call a Beacon today was originally invented and popularized by Apple way back in 2013 when they introduced the iBeacon API. In fact, referring to these devices as just “Beacons” is a bit funny, considering no one was talking about Beacons before iBeacons existed. It’s a lot like discussing the “tablet market” back when the tablet market consisted entirely of iPads.

How Beacons Work

Beacons are cutting-edge technology, made of space-age polymers and packed with the latest advancements in miniaturization and artificial intelligence.

Just kidding! Beacons are actually super dumb. They are literally just a radio strapped to a battery.

A single Beacon is like a tiny Walkman, set to repeat the same song over and over again until it runs out of juice and dies. Here’s an example of a “song” that a Beacon might play:

 "F67A60E4-27CE-4E9A-84CA-157694A29BD6, 1, 27"

That’s the whole thing. In total, exactly 20 bytes of relevant data, broadcast again and again every few milliseconds.

Nerd Alert

OK, if you are really curious, here’s how that song breaks down. Beacons broadcast data according to the iBeacon API, which boils down to this:

UUID Major Minor
F67A60E4-27CE-4E9A-84CA-157694A29BD6 1 27

These three fields, UUID, major and minor, are broadcast using a Bluetooth LE (a.k.a. Bluetooth Low-Energy or Bluetooth Smart) radio on the fixed “advertising channel” and include some other metadata related to the Bluetooth spec. If you were to simply listen with a Bluetooth scanner on that channel, you could easily see the whole thing.

When you set up your Beacon, you can choose whatever values you want for UUID, Major, and Minor. It’s completely arbitrary what you pick. Generally, it’s recommended that you generate a randomized shared UUID value for your “organization” and allocate a unique Major and Minor number that has meaning to you for each beacon.

So you might say, ok my company will use the UUID of F67A60E4-27CE-4E9A-84CA-157694A29BD6 and all my Beacons in Portland will have the Major number of 7 and all my Beacons in New York will have a Major of 13.

In this way, Beacons are like digital graffiti - meaningful to the artist but gibberish to almost everyone else.

Privacy Concerns

One problem with Beacons is that although the technology itself is stupid simple, understanding how phones and apps are using them can get a bit involved.

The situation is not helped by the current storyline in the media. To hear some recent articles tell it, Beacons are just another way for shadowy tech companies with names like Titan to spy on you and send you One Weird Trick ads on your way to the grocery store. (Also - “Titan”? really? Were you going for a real Lex Luthor vibe?)

The problem here is that the interest in Beacons by media and advertising companies is being attributed to some assumed-creepy aspect of the technology itself. When the reality is—surprisingly—that Beacons are extremely privacy-friendly, by design.

A good technology to compare Beacons to is GPS.

Our GPS system consists of dozens of satellites orbiting the planet, broadcasting signals to the earth’s surface. These signals are simply the current day and time, according to each satellite. It goes like this:

"The time is now 10:20am."
"The time is now 10:20am and 30 seconds."
"The time is now 10:21am."

When you get lost outdoors and want to know where you are, you ask your smartphone and it quietly listens for these timestamps, and deduces your location based on the known location of satellites and the minuscule differences in times that it hears from each one.

So although it may sound scary to have a bunch of Government Satellites in the air above us at all times, the reality is less controversial—we can see them, but they can’t see us.

The same is true for Beacons. When your iPhone is listening for beacons, it’s simply tuning in to that advertising channel. While it’s listening, it is completely silent, meaning that nothing about your presence is revealed to anyone, including other nearby smartphones, listening devices, and the beacons themselves.

That’s at the hardware level. At the software level, it’s up to your apps to behave like good citizens. Just as apps can attempt to share your location data as determined by GPS, so too can they attempt to share data about what beacons they see. Fortunately, apps have to request permission to get your location (which includes seeing beacons) in the first place, and if you don’t like what they’re doing, you can switch off those permissions or just delete the app entirely.

So now that we know Beacons aren’t inherently scary, what can we use them for?

Using Beacons for Proximity Notifications

Note: These examples center around the iOS platform, but most newer Android devices support beacons as well.

Proximity-based messaging is the highest-profile use case for Beacons today. The basic pitch goes like this: wouldn’t it be awesome if, say you’re shopping at MegaWorld and you innocently wander by the Shoe department (these examples always use the shoe department, it’s uncanny), and your phone suddenly buzzed in your pocket and pushed you something like:

How did that happen? Well the idea is that MegaWorld has placed a Beacon in the middle of the Shoe department ahead of time, and that Beacon is chirping out its little song over and over, and let’s say it’s encoded like this:

UUID Major Minor
(Shoe Dept)

Meanwhile, your phone was secretly monitoring for MegaWorld beacons in the background—and when you got close enough to the beacon, it picked up the signal, decoded the Major/Minor, and presented the appropriate offer as a notification.

Sounds great, right? Here’s the first thing I’d do if I received one of these notifications:

This is the other problem with Beacons: Everyone jumps to examples like “pushing generic coupons” that are easy to conceive and implement but provide little value to the user. If you wanted to give everyone passing the Shoe department the same “10% off!” message, you might as well just put up a physical sign. Remember signs? Buzzing my phone should be reserved for really important messages.

This is why the iOS platform in particular makes it very easy to opt out of this behavior. In order for that above experience to work at all, the user will have to get through a few dialogs:

So the burden is on the app developer to convince users they’ll get something of value in exchange for granting these permissions. That usually means knowing something about you as a user, versus an anonymous owner of a smartphone.

For example, if you were using an app for a grocery store and you had entered a shopping list, it might make sense to have a beacon in every department to remind you if you need to pick up anything while you’re there:

Or if you were logged into an app for your hospital and they had a beacon in every doctor’s office, you could get a reminder when exiting the office if there was some follow-up action required:

These experiences are much more compelling; but they typically require integration work between the beacon system, mobile app, and 3rd-party backend servers.

It’s important to note that beacon monitoring happens without the app running in the background all the time and draining your battery. Under the hood, the app has to ask the system to listen for a beacon on its behalf, and the system does all the work itself in an extremely low-power way.

Using Beacons for Location

One of the Meridian platform's flagship features is indoor mapping and navigation.

Outdoors, we can simply use GPS to get your location and put it on the map. Sadly, GPS doesn’t work indoors.

Previously, the only way to do indoor location on the iOS platform specifically was to tap into the Wifi network and figure out the locations of all Wifi-enabled devices, then tease out which one represents your device and pass the location back to you. It was a bit of a hack, and for very good unrelated privacy reasons, iOS has taken steps over the years that have made this technique much less effective.

Fortunately, it turns out that Beacons are great for finding your location indoors. iOS permits app developers to “range” for beacons while the user has your app open, and you can use the scan results to determine your relative location. All you need to do is remember where you’ve placed your beacons:

And interpolate from there. We’ve actually deployed this for the new Levi’s Stadium app which uses the Meridian SDK for maps and directions. All in all, they installed over 1,100 beacons to cover the entire stadium; the largest deployment we’ve heard of.

Managing Beacons

So how do you manage a deployment of 1,100 beacons? What if one stops working, or gets moved, or runs out of power and dies?

First you’ll need some kind of cloud dashboard to log into. But how do the beacons communicate essential data like their current battery level to the cloud? Remember that beacons are typically just dumb Bluetooth-based broadcasters.

One approach would be to make the beacons themselves do the work, by communicating with each other and forming a mesh network. Then they could send information about their state to a “master beacon” with an internet connection to the cloud.

The problem here is that now the beacon itself isn’t so simple; it needs to wake up into a high-power state frequently to communicate with other nearby beacons and synchronize clocks and that’s a battery killer. Additionally, you now have to make sure every beacon is in range of at least one other beacon—harder than it sounds in larger venues.

Another approach is to make your mobile app do the work. On Android, you could do some background scanning and try to passively collect data from the beacons and batch-send it to the cloud when the user’s phone has an internet connection. On iOS, you could do the same thing but only when the user is actively using your app.

This might work, as long as enough people in your venue are carrying devices with your app already installed, and regularly visit all parts of your venue where beacons are placed. It’s not the best peace of mind however.

One final approach is to use a network that the venue probably already has: Wifi. You could add Wifi to the beacons and make them connect to the network like other devices, but Wifi is a major battery drain.

So instead of making the beacons speak Wifi, why not make the Wifi speak Beacons?

This is the approach we’re taking at Aruba. By adding Bluetooth chips to our Wifi hardware, we’re enabling “remote management” of our beacons. The network simply listens for metadata broadcast by Aruba Beacons and relays it to the cloud. And having this essentially-direct connection to all of your thousands of beacons will enable lots of interesting features in the future.

It’s the Apps

Beacons are an important new technology with lots of exciting potential. But by themselves, they are useless. They only become interesting and powerful when apps take advantage of them.

This puts you, the user, in direct control as you should be. If an app is doing something you don’t like, such as secretly sharing your location from GPS or Beacons or anywhere else, simply vote with your Delete button.

The challenge, as always, is up to app developers and venues to build engaging experiences that delight users. And Beacon technology is a great way to do just that.

Notes (From Tumblr)

  1. whitengray reblogged this from nfarina
  2. sweng-easypairings reblogged this from nfarina
  3. marinintim reblogged this from nfarina
  4. lukrative reblogged this from nfarina
  5. fetzervalves reblogged this from nfarina
  6. lrvillarreal reblogged this from nfarina
  7. ihumanafterall reblogged this from nfarina
  8. mindofadeveloper reblogged this from nfarina
  9. centipedefarmer reblogged this from nfarina
  10. kiyokubo reblogged this from nfarina
  11. profanitylacedtirades reblogged this from nfarina
  12. leadchainsaw reblogged this from nfarina and added:
    So the burden is on the app developer to convince users they’ll get something of value in exchange for granting these...
  13. ozerdomktg reblogged this from nfarina
  14. nfarina posted this