- January 15, 2014
- Posted by: admin
- Categories: Agile Applications, Blog
iBeacons is actually Apple’s BLE (Bluetooth Low Energy) beacon service. A beacon in and of itself is just a broadcasted signal that other BLE devices can pick up. What’s included in that transmission is a list of services provided by that BLE device. One of those advertised services could be Apple’s iBeacons.
iBeacons contain a data payload that is extremely basic – only an identification number. That number is broken into three parts; a UUID (128-bit unique ID), a major value and a minor value. This data is useless to anyone but the developer of the application and owner of the beacons. Meaning, without that developer’s app installed, these beacons are worthless and useless.
Apple has baked their iBeacons into their CoreLocation framework. For people that are afraid of receiving unsolicited notifications on their devices, there are actually four steps that must be taken for this to happen on an iOS device:
1. You have to have the app downloaded and installed.
2. You have to have Bluetooth on.
3. The app must be able to access location data.
4. The app must be able to receive notifications.
The developer programs the BLE device to advertise Apple’s iBeacons service. They also include their own identification information; UUID, major, minor values. (These values can be anything. As an example, we’ll go with a department store: The UUID would be a company wide number. The major value would be a specific store location and the minor value could be department, aisle, or even down to an item on a shelf.)
When the app runs (with bluetooth turned on and access to location data), it registers to receive proximity events from iBeacons with their UUID (the API does not allow an app to pick up EVERY iBeacon that’s transmitting – the developer must be specific). Once registered, the OS will begin to send these proximity events to the app when the iOS device picks up an iBeacon with the specified “signature”. At that point, the app collects the major and minor values. And it also gets the “distance” to the BLE device. (It’s actually just gets the volume of the signal, which gets stronger and stronger the closer you get.)
The app then uses all that information to determine how to proceed. If it’s the case of the department store, the app would use the major value to look up which store you’re in and use the minor value to determine where inside that store you are. Where that information comes from or how it is retrieved is beyond Apple’s iBeacon. It could be stored in a local database in the app itself, it could be queried from a server over the network. The app could also continue communicate with the BLE device through some other service.
All Apple provides here is a simple method of discovery, nothing more. It’s up to the developer to determine what happens next. That’s important to remember, because other beacon services want to take that a step further. Google’s implementation for instance, wants the data payload to contain other information so that their apps and OS (Android) can collect it as you pass by.
Which is extremely appealing from an advertising point of view.