iBeacons are certainly a trending topic recently. They allow indoor positioning, letting your phone know that you are in range of a beacon. This can have many applications: from helping you to find your car in a parking garage, through coupons and location-aware special offers in retail, to a whole lot of apps that we can’t imagine right now.
There are many posts about what iBeacons are and what can be done with them, but from a technical perspective, how do they work? The underlying technology is Bluetooth LE, so …
What is Bluetooth LE?
Bluetooth Low Energy (BLE, official page, wikipedia) is a part of the Bluetooth 4.0 specification, which was released back in 2010. It originated in 2006 in Nokia as Wibree, but has since been merged into Bluetooth. It is a different set of protocols than “classic” Bluetooth, and devices are not backwards-compatible. Hence you can now encounter three type of devices:
- Bluetooth: supporting only the “classic” mode
- Bluetooth Smart Ready: supporting both “classic” and LE modes
- Bluetooth Smart: supporting only the LE mode
Newer smartphones (iPhone 4S+, SG3+), laptops, tablets, are all equipped with full Bluetooth 4.0 and hence “Smart Ready”. Beacons, on the other hand, only support the low energy protocols (which allows them to work on a single battery for a really long time) and hence they implement “Bluetooth Smart”. Older devices, like peripherals, car systems, older phones usually support only the classic Bluetooth protocol.
The main focus in BLE is of course low energy consumption. For example, some beacons can transmit a signal for 2 years on a single cell battery (the batteries are usually not replaceable, you’ll probably just replace the beacon when they stop working). Both “classic” and LE Bluetooth use the same spectrum range (2.4 GHz – 2.4835 GHz). The BLE protocol has lower transfer rates, however it’s not meant to stream a lot of data, but rather for discovery and simple communication. In terms on range, both LE and “classic” Bluetooth signal can reach up to 100 meters.
How does BLE communication work?
BLE communication consists of two main parts: advertising and connecting.
Advertising is a one-way discovery mechanism. Devices which want to be discovered can transmit packets of data in intervals from 20 ms to 10 seconds. The shorter the interval, the shorter the battery life, but the faster the device can be discovered. The packets can be up to 47 bytes in length and consist of:
- 1 byte preamble
- 4 byte access address
- 2-39 bytes advertising channel PDU
- 3 bytes CRC
For advertisement communication channels, the access address is always
0x8E89BED6. For data channels, it is different for each connection.
The PDU in turn has its own header (2 bytes: size of the payload and its type – whether the device supports connections, etc.) and the actual payload (up to 37 bytes).
Finally, the first 6 bytes of the payload are the MAC address of the device, and the actual information can have up to 31 bytes.
BLE devices can operate in a non-connectable advertisement-only mode (where all the information is contained in the advertisement), but they can also allow connections (and usually do).
After a device is discovered, a connection can be established. It is then possible to read the services that a BLE device offers, and for each service its characteristics (this is also known as an implementation of a GATT profile). Each characteristic provides some value, which can be read, written, or both. For example a smart thermostat can expose one service for getting the current temperature/humidity readings (as characteristics of that service) and another service and characteristic to set the desired temperature. However, as beacons don’t use connections, I’ll skip the details. If you want to read more about connecting to BLE devices, Apple’s Core Bluetooth guideprovides a good overview, even if you are not an iOS developer. For articles which are even more technical, take a look at EE times (Introduction to BLE, Making the most out of BLE advertising mode).
How do beacons use BLE?
Beacons use only the advertisement channel. As the “beacon” name suggests, they transmit packets of data in regular intervals, and this data can be then picked up by devices like smartphones. Hence iBeacons are simply a specific usage of BLE advertisements, with some additional support on the iOS side.
If you try to intercept an iBeacon advertisement packet, for example coming from an Estimote beacon, you’ll see the following data:
02 01 06 1A FF 4C 00 02 15 B9 40 7F 30 F5 F8 46 6E AF F9 25 55 6B 57 FE 6D 00 49 00 0A C5
(to capture such data, if you have OSX, an additional XCode download contains a Bluetooth scanner and a packet logger. For Windows, see for example here)
The data above already has the preamble, fixed access address, advertisement PDU header and MAC address removed; it is only the advertisement data – 30 bytes, so it fits nicely in the 31 byte limit.
What makes a BLE advertisement an iBeacon one? The format is fixed by Apple. To break it down (see also SO):
02 01 06 1A FF 4C 00 02 15: iBeacon prefix (fixed)
B9 40 7F 30 F5 F8 46 6E AF F9 25 55 6B 57 FE 6D: proximity UUID (here: Estimote’s fixed UUID)
00 49: major
00 0A: minor
C5: 2’s complement of measured TX power
What follows is that if you want to experiment with beacons, you don’t really need any special devices. If you have a newer phone (e.g. iPhone 4S+, SG3+) or a Bluetooth 4 laptop (e.g. Retina MacBook), you can turn any of these devices into an iBeacon transmitter and receiver. For iPhones, see for example the “Locate iB” app in AppStore. For MacOS, see here. And of course, you can use Raspberry Pi as a beacon as well.
Breaking down the iBeacon format
Apart from the fixed iBeacon prefix (
02 01 ... 15), what is the meaning of the other components?
The proximity UUID (
B9 ... 6D in our example), is an identifier which should be used to distinguish your beacons from others. If, for example, beacons where used to present special offers to customers in a chain of stores, all beacons belonging to the chain would have the same proximity UUID. The dedicated iPhone application for that chain would scan in the background for beacons with the given UUID.
The major number (2 bytes, here: 0×0049, so 73) is used to group a related set of beacons. For example, all beacons in a store will have the same major number. That way the application will know in which specific store the customer is.
The minor number (again 2 bytes, here: 0x000A, so 10) is used to identify individual beacons. Each beacon in a store will have a different minor number, so that you know where the customer is exactly.
The final field, TX power, is used to determine how close you are to a beacon. This can be presented either as rough information (immediate/far/out of range) or as a more precise measurement in meters (you can convert to feet of course 😉 ). How is it done?
The TX power (here: 0xC5 = 197, 2’s complement = 256-197 = -59 dBm) is the strength of the signal measured at 1 meter from the device (RSSI – Received Signal Strength Indication). As the strength of the signal decreases predictably as we get further, knowing the RSSI at 1 meter, and the current RSSI (we get that information together with the received signal), it is possible to calculate the difference. iOS has this built-in, for other platforms, it needs to be hand-coded, see this SO answer for a specific algorithm.
Obstacles such as furniture, people or communication congestion can weaken the signal. Hence the distance is only an estimate.
iOS comes with some additional integration with iBeacons. Your app can receive notifications when a beacon comes into range – but not only when the app is in the foreground, also when it is in the background! An app can subscribe to region enter/exit events, so that it is partially woken up even if it isn’t running. In response to such events, the app can send e.g. a local push notification, prompting the user to open the app and see the in-store promotion (which can be for example fetched from the internet), or other relevant content.
More precisely, when the phone isn’t active, iOS goes into a low-power monitoring mode: only iBeacon region enter/exit events are detected. When the phone and app are active, you can enterranging mode, which enables you to detect the signal strength and estimate the distance more precisely.
Note that it can take some time for your phone to detect a beacon. Firstly, the beacons transmit the advertisements from time to time. Secondly, if your phone isn’t active, it monitors for bluetooth signals only sometimes as well. For a beacon to be detected, these two intervals must overlap. In practice, it can take up to 15 minutes to detect a beacon.
For a step-by-step guide to writing an iOS iBeacon application, see here. Beacon manufacturers also often provide dedicated SDKs which help in writing beacon-enabled applications. See for example Estimote’s iOS SDK and Android one.
How can I get some beacons?
Beacons are currently a scarce resource; you often have to wait a couple of weeks to get some; but certainly availability will become better and better.
Hence the fastest option is to build a “softbeacon”: turn your iPhone/Android/MacBook/other laptop/RaspberryPi into one (as described above).
Your second option is to try and order some beacons:
- pre-order Estimote beacons; 3 for $99
- Kontakt beacons come in a couple of packages; 4 for $99, 10 for $279
- RaspberryPi kits from RadiusNetworks: 1 for $99
- RedBearLab offers BLE shields for Arduino for $30
- Bleu sells USB-iBeacon dongles. 1 for $40, 5 for $150
iBeacons isn’t the only proximity BLE-based technology. Qualcomm is developing its own beacons,Gimbal, together with iOS and Android SDKs. They will offer a similar feature set, however the format of the BLE advertisement may be different. My developer kit is on its way, so I haven’t tested them yet, but the beacons certainly look interesting – especially because of the pricing – $5/basic beacon.