is a protocol developed by Apple Inc. in 2013. In short, iBeacon technology allows mobile applications to understand their position on a micro-local scale, and deliver location-specific contextual content to users based on their proximity. The underlying communication technology is Bluetooth Low Energy (BLE). The protocol takes advantage of the BLE technology to bring about very low-powered broadcasting devices that could alert users of its presence. By adding certain parameters to the advertising data packet, the broadcasting device can be used to transmit location specific information. The most common use case of such iBeacon devices would be in the brick and mortar shops, where business owners want to transmit location-specific promotions or to track their shoppers who have their shop-specific app installed on their smartphones. Of course, privacy is always a running concern for the user tracking implementation but with the latest mobile OS, users can prevent their privacy from being breached. The caveat is that the users have to be tech-savvy enough to know how to do that.
Several development projects that we've been involved in are requests for iBeacon-like attributes - implementing similar protocol but with varying levels of modifications. The good news is that you can implement the iBeacon on your own. There will be another article released soon, where we talk about EddystoneTM
– Google’s latest beacon protocol. Stay tuned for that.
For those really curious about the type of projects we have done using iBeacon and other Beacon protocols, I will just say that there are various combinations but mostly it boils down to users' behavioural monitoring based on location. We focused on product development, so our clients could remain focused on their customer's buy-in and marketing.
iBeacon advertising protocol
iBeacon is a one-way transmitting protocol. You have to set the device to be non-connectable and always stay in advertising mode. The reason for non-connectable should be a no-brainer because if you are connected, BLE will not advertise. To save power, you will want to broadcast in a longer time interval. You can try a 100ms broadcasting interval and slowly fine-tune it from there.
The above illustration describes the iBeacon protocol in the simplest way possible. All BLE SDKs should have provision to modify the advertising data, so make sure to arrange your advertising data as per the protocol or the iBeacon will not work. To officially work with iBeacon, you will need to license the technology from Apple. You can read Apple's beginner document for more information (source
Moving on to the more technical aspect.
The 4 most important components of this protocol are:
1. Proximity UUID
4. Measured power
This is the unique identifier that separates your device from the hundreds or thousands of iBeacon devices out there. Your app will have to white-list your UUIDs in order to prevent reading from the wrong device. By whitelisting, I mean your app should only read from devices with your authorized UUID. There are multiple avenues to generate UUID but one of the most common sources can be found here
If you are just testing out iBeacon using the AirLocate sample code located on the Apple Developer site (https://developer.apple.com/ibeacon/), you will need to use their predefined UUIDs
To define the location of the device, you declare the major and minor values. An example usage would be in a multi-storied departmental store, you will use major to define the level and minor to define the particular section within the level. Since it is a 2 bytes parameter for each value, you can define up to 65536 unique major locations and 65536 unique minor locations. If you do the sum, that’s a lot of unique locations.
Another aspect of the iBeacon is that it can tell how far the user is away from the iBeacon device. However, to achieve that, you need to calibrate the device. The way to calibrate is fairly straightforward. You need a mobile app that can measure RSSI, and you use that to measure the RSSI at a 1m distance from your device. I would also recommend you to do the calibration in multiple directions and compute the average as the measured power. Bear in mind that the measurement is in dBm.
The best time to calibrate is on actual deployment. Laboratory or factory calibration will usually net the best results but it doesn't reflect your actual environment as there are many factors to consider when it comes to RF, e.g. Fresnel zone, Dead zone and etc...
A little surprise to some but you can actually indicate the device's battery life in the advertising protocol. It is a little more advanced so I wouldn't recommend it to beginners. The reason why you can do that is that Apple protocol does not use up all of the available advertising bytes for BLE; you can squeeze in 1 more byte right after measured power. However, since it's only 0-15, you will need to include custom firmware code within your device to digitize the battery level into 16 levels.
Go forth and code away!