iBeacon is a specification for normal BLE devices in which they keep transmitting the same signal repeatedly which contains a UUID, Major, Minor and a power value which are used to identify the beacon and the distance from the beacon. This leads to devices with Bluetooth 4.0 to be able to detect these beacons and for developers to be able to take advantage of this by programming apps to react to these sort of situations.
What is BLE?
Bluetooth Low Energy (BLE) is exactly what the name suggests. It’s a standard for Bluetooth that lets you use the power of Bluetooth but without it relentlessly hogging your battery. BLE technology is found in all devices with Bluetooth 4.0 chips. In BLE, there are 2 roles. The peripheral role and the central role. The peripheral role is when the device is advertising or sending data while the central role is when the device is consuming data.
Now, What is an iBeacon?
Well, iBeacons are BLE devices that are able to perform the peripheral role (advertise data) and follow Apple’s specification for the data being advertised. Yes, that means any BLE device with such an ability can become an iBeacon as long as Apple’s specification is followed.
Are iBeacons just for Apple devices?
Apple has been pushing BLE technology very hard. And they have come up with the iBeacon specification. However, iBeacons are not just limited to Apple devices. Android provides support for the central role, but not for the peripheral role while Apple devices do both. So you can “reach” an Android device with your beacon (I’ll be using this to refer to BLE devices conforming to the iBeacon spec from now on) , but you cannot turn it into one while you can do both with Apple devices.
So, What is this iBeacon specification?
The iBeacon specification means that the BLE device that is advertising the data (a GATT server role, to be precise) will be transmitting the following fields in the advertisement packet:
1. UUID (128 bit integer)
2. Major value (16 bit integer)
3. Minor value (16 bit integer)
4. Tx Power (8 bit integer)
The first 3 fields are used to help identify the beacon while the last field is the value of the signal strength at 1m from the beacon. This helps to estimate the distance between the 2 devices. There are a few more technical details about the transmitted Bluetooth packet that can be found easily on the internet for the interested people, but these 4 fields are the important ones and should suffice from a developers perspective.
Misconceptions regarding beacons
1. Beacons can track people – Beacons are like lighthouses without any radar. All they do is to keep advertising their presence. It’s all upto the device that is receiving these signals to respond to their presence. Beacons are not aware if a device has picked up its signal or not. But the app on the device can recognize and hence track users.
2. Beacons push content to devices – As we said before, beacons only keep advertising their presence. The only data they transmit is regarding the identifiers of the beacon. It is the app which is responsible for identifying the beacon and providing relevant content to the user.
So how does my device interact with these beacons?
In iOS devices, Apple allows apps to detect only beacons whose UUID’s are registered by the app. There is a cap on a maximum of 20 “beacon regions” that can be registered by an app. These “beacon regions” are usually defined as the UUIDs to look for but can be extended to a finer granularity if required using the major and minor values. But lets stick with UUID’s for now. So once your app gets location permission from the user and is able to register the UUID’s to look for with iOS, then whenever the phone detects a beacon sending out that UUID, it wakes up your app and tells it that it has entered such a region. Then the app can execute whatever action
it has been programmed to do. Usually, we use this cue to start ranging for beacons. That is, we start to find all such beacons which are present in the region and the estimate distances from them and proximity. More on this soon!
Note : This call will occur only when the app has detected such a beacon from a state where it had no such beacons. As in, if it already thinks we are in a region, it won’t do the call again if a new beacon with such identifiers is encountered. The same occurs once we have exited such a region and again this call occurs only where there are no beacons to be found with the same identifiers from a state where at least one was present. But we are interested in what occurs in between these 2 events. The ranging part is what provides us with specific information to help us identify which beacon we are near and how close we are to it. Apple has provided 3 proximity zones of Immediate, Near and Far which are calculated by the Apple API and we can use to understand which zone we fall in and make the app respond to that.
Once we start ranging for beacons, we get a list of all beacons each of which has details on their identifiers and the proximity calculated by the Apple API. There is also an accuracy field that is an estimate of the distance between the beacon and the device. A developer can use all this information to design the logic for his application as required.
Beacons don’t push content? So then how do I get my message across?
Well, you can always hard code the actions you want your application to do inside your application logic. But then, that will mean updating your app every time you want to change a message. So, storing that information on the cloud with a CMS is the best option. Just make your app look up the message/action to be performed with the server and you’re all set!
The following diagram describes the process that is occurring in a typical app designed to deliver proximity based messages. It is a simplified version of the whole process.
Challenges to developing beacon solutions
? The distance estimate is just exactly that, an estimate. It is not a very accurate value.
? Interference from radio, computers etc can make the behavior of beacons unpredictable sometimes.
? Getting permission to use location services of the user. You get only one chance to ask for this. And with iOS 8 it becomes harder with 2 types of location privacy setting being introduced. A very clear explanation as to the purpose of the usage of location will help.
? Beacon hardware is required for testing. You can make a Mac with Bluetooth 4.0 and OSX Mavericks and above act as a beacon using apps like MactsAsBeacon but you cannot test apps using the iOS simulator but you require an iOS device with BLE and iOS 7.
What’s in store?
It’s an exciting time to be working on iBeacons for sure!
iBeacon Mobility Solutions Developer, RapidValue