In other words, enhancing the capabilities of beacon technology with bidirectional, two-way communication.
Both the development and implementation of beacon tech is growing exponentially. They’ve inspired numerous startups because of their great potential. However beacon technologies have been unevenly supported depending on the platform.
Apple has been using beacon technologies since the iPhone 4s, and because of this, they definitely has a head start. Android only recently released Lollipop (Android 5.0), which allows devices to act as beacons and advertise information over BLE. Only the nexus 6 and nexus 9 devices support this technology.
In this article, we want to clear out some confusion which may exist between Bluetooth, BLE, Beacons and more specific implementations of beacons such as iBeacon, estimote or AltBeacon. We will have a quick overview of how they function to help you realize their strengths and limitations.
And as a result, we have decided to combine PubNub’s data stream technology to create smarter beacon tech. This combination will open a wide horizon of possibilities for your apps!
We have full tutorials for iOS, Android, and Tessel, listed at the bottom of this blog post. Check them out!
Let’s dive right into it, shall we?
Beacon Tech: BLE, Beacons and iBeacon
Quick Overview of BLE
Bluetooth Low Energy (BLE) is a Bluetooth technology which was released into the main Bluetooth standard in 2010 along with the Bluetooth Core Specification Version 4.0.
Bluetooth devices had suffered from being extremely energy greedy, and the need for a better energy management was necessary. BLE solved this problem and has since been used on most modern devices (all apple iPhone since the 4S, samsung phones since the Galaxy SIII, and many more).
BLE allows us to use the bluetooth communication for small data exchanges and hence to avoid consuming as much energy.
Before we get into the description of how beacons work, let’s simply review a couple characteristics of Bluetooth devices:
- Servers vs. Clients: these definitions are fairly classic. The Client emits requests and receives responses while the Server listens for requests and sends responses.
- Central vs. Peripheral: The peripheral device has valuable information to share with central devices. The central device treats the received data to fulfill specific tasks.
There is a lot more to BLE obviously, we tried to keep it short. If you feel curious, this EE article is a great source!
Beacons
Beacons are fairly original BLE devices. In most cases, BLE devices are either central clients, or peripheral servers.
Beacon devices simply emit information using BLE technology. No connection is created with other devices. It’s one-way communication! It works the same way as a lighthouse that emits a bright spot to allow ships spot land. Beacons simply advertise a small piece of information. That’s all there is to it.
Common beacons advertise this information over a 230 feet (70 meters) radius. The great strength of beacons is the ability to constantly share a small piece of information while using minimal energy. The energy provided by a simple coin battery is sufficient for a BLE device to advertise for more than 2 years!
Fairly simple so far, right? At this point you might be wondering why so many people have been talking about it. Its functionalities seem limited.
Let’s get into the real stuff now, and talk about commercial implementations of beacons.
The Protocols: iBeacons, estimotes, AltBeacon
iBeacons, Estimotes, AltBeacon can all be considered protocols defining how one should structure the advertised data.
They all behave in a very similar way which we’ll describe immediately. If you are looking for some official documentation, try taking a look at: Apple official documentation, Estimote API documentation, or AltBeacon specifications.
The data advertised by these beacons basically contains 3 configurable pieces of information:
- a 16 byte UUID
- a 2 byte Major, which can be any integer you want between 0 and 65535
- a 2 byte Minor, which also can be any integer between 0 and 65535
Typically the UUID is used to identify a company. The major and the minor end up being the only information you really advertise. The UUID would allow your mobile application to recognize which beacons are related to him and the major and minor can represent a specific beacon.
This information is advertised along with a lot more information. The most important one is the reference RSSI. It’s a one byte packet of information that represents the signal strength one would receive a meter away from the beacon.
This is a key element to these beacon protocols. Because your phone can estimate the intensity of the signal received, it can compare this value with the reference RSSI and compute an estimation of the distance to the beacon.
Note that the intensity of the signal received depends vastly on the physical configuration of the room and as a result it is not a very reliable computation. Apple usually divides this information into 3 categories: immediate (<1m), near (~ 1 to 3 m) and far (>3m).
Perfect! Hopefully you are now able to tell the difference between BLE (the technology), beacons (any emitting device) and its various implementations (or protocols), and you know what information they share.
Enhancing Beacon Tech with Bidirectional Communication
If you are like us, you are probably thinking that's interesting, but also very limited. Beacons have a low energy consumption, but the one way communication is limiting. Using PubNub we are going to enhance the capabilities of beacons. Our goal is to keep a low energy consumption but still enable a two-way communication.
PubNub allows any device with an internet connection to communicate in a secure and rapid manner. Devices subscribe to a channel and listen for messages sent to the channel as well as presence events.
A Simple Use Case: Bidirectional Beacon in Retail
We will take advantage of this to create a simple application. This concept was inspired by an earlier bidirectional communication iBeacon tutorial on our blog.
In our example, the setting is a retail store. The store has a beacon near the entrance advertising the UUID of the store, and a major and a minor.
On the other side, we have a customer who already has the store’s app on his phone. As he walks past the store, his phone is scanning beacons with the store’s UUID only. Once the customer is near the door (less than 3 meters), his phone uses the major and the minor that are advertised to subscribe to a PubNub channel called: “Store_major_minor”.
The emitting beacon is listening for presence events on this same channel. So when the customer’s phone subscribes to the channel, the emitting beacon posts a message on the channel which is received on the customer’s phone!
Note: In this example, the beacon would be listening for events on the channel; though the listening device does not have to be a beacon. You can listen for events with any device that connects to the Internet.
We smartly designed our app so the message sent on the channel trigger a notification on the user’s phone: “Hey, it’s almost 4pm! Come in and get $2 off the warm drink of your choice!”
Wow! Notice how we only initiate a communication over internet when the phone is close enough to a beacon? We just created a system that allows a two-way communication while keeping the low energy advantage provided by the beacon!
Thanks to PubNub, devices that subscribe to a channel have their own ID. This allows us to have a personalized communication. If you know the customer is more of a tea person, you can tell him all about your new Earl Grey!
Not Just Apple: Cross-platform Beacon Implementations
We're not going to stop here. To help you start using beacon technologies, we decided to do a couple overviews of how to implement beacons on various platforms! We'll be rolling out these tutorials over the next month or so, so stay tuned!
**NOTE: Since we wrote this tutorial, we’ve released a new, completely-redesigned version of our iOS SDK (4.0). We rebuilt the entire codebase and took advantage of new features from Apple, simplifying and streamlining the SDK.
The code from this tutorial still works great, but we recommend checking out our new SDK. We've included a migration guide to help you move from 3.x to 4.0, and a getting started guide to help you create a simple Hello World application in minutes.**
Android
Tessel
