As Apple releases iOS 7, iBeacons are now available for app developers to start incorporating into their applications. Our iOS app, Geohopper, allows you to trigger actions based on entering and exiting physical locations and we were very excited when iBeacons support was announced. iBeacon allows us to get a lot more granular with detecting a user’s location and do better detection indoors. When we started integrating iBeacon support into version 1.2 of Geohopper, there were no iBeacons to test with. We started testing against iOS devices acting as iBeacons, moved to some test setups to have a crude iBeacon setup, and then finally did some testing on devices based on how iBeacon is supposed to work. This post gives an overview of what iBeacons are, and some great stuff we learned on the way to supporting iBeacons in Geohopper.
Why do we even need iBeacons?
iBeacons solve a longstanding problem with GPS. GPS works great for apps that operate outdoors and road navigation is the primary consumer use. However, GPS doesn’t work as well indoors or for determining distances within 20 meters. iBeacons help solve this problem by providing an easy way for an app to determine how far the iOS device is from an iBeacon. But iBeacons don’t give out GPS coordinates. They provide identifiers, which help the iOS app to understand the context of the world around it. iBeacons are going to let you automatically turn on lights in your house, have patient charts automatically appear on a iPad as a doctor enters a hospital room, and even secure your environment around you. The retail and marketing sectors are already embracing iBeacons, but the potential goes far beyond that. However, before looking at current solutions and possible future applications, let’s look at how iBeacons solve a couple of very important problems.
Solution 1: They work indoors
It starts with the Global Positioning System (GPS). One of the limitations of GPS is the inability to accurately plot indoor locations, and since GPS requires listening to multiple satellites to figure out the current position, it can take a bit of time. Apple has done a great job of speeding up this process by using not just GPS, but also detecting WiFi networks in the vicinity, and determining your precise location. This helps speed up finding your location as well as locating you when indoors. iOS devices, like the iPod Touch that don’t have cellular radios, or GPS units can still find your approximate location by using WiFi network names. Your iOS device does not connect to these WiFi networks, but uses the wireless network’s name and signal strength to determine the approximate location.
However, while this helps reduce the time required to determine your location, it doesn’t help in areas with few or no WiFi networks and isn’t particularly precise. App developers and businesses are trying solve the close proximity problem in order to offer applications that depend on location accuracy, such as museum tours, personal location-based retail, and other applications that depend on the device having speedy and accurate location-awareness, even indoors.
Solution 2: Very low power
Another reason for iBeacon usage is battery life. Any time you use GPS, cellular, or WiFi, the radios on your iOS device are turned on. This has a major impact on battery life, and any solution that requires the device to be actively scanning will drain the battery quickly and negatively-impact the app’s usefulness.
This is where Bluetooth Low Energy (sometimes called BLE or Bluetooth Smart) comes into the picture. Bluetooth Low Energy is part of Bluetooth 4.0, and is different from the Bluetooth you use to connect to your Bluetooth headset or stereo headphones. Bluetooth Low Energy is about sensors and saving battery life. As you can see on the official Bluetooth Special Interest Group BLE profile page, Bluetooth Low Energy is focused on technology to monitor the environment for health, exercise, proximity, and alerts between devices. A Bluetooth Low Energy device can operate for a year or more on a single watch battery like the CRC-2032. You can still use AC power with Bluetooth Low Energy devices, but as they are designed for low bandwidth broadcast with only occasional transmission, they simply don’t need the kind of power required for high bandwidth streaming.
iBeacons support in iOS 7
Apple now supports iBeacon as a part of iOS 7. iBeacon is a Bluetooth Low Energy service that periodically sends out identifiers to devices like the iPhone 5(s,c). iBeacon is a not yet a standard Bluetooth Low Energy profile defined by the Bluetooth Low Energy Special Interest Group (SIG) as of this writing. It is a vendor specific profile, and none of the existing standard Bluetooth low energy profiles appear to meet Apple’s requirements that iOS can read the identifier without negotiating a connection to the beacon. This is important because an iPhone does not need to actively scan or connect to a bluetooth device to determine the iBeacon’s ID. Apple defined a new profile called iBeacon that is a very simple, yet powerful, service. Apple has announced plans on releasing the specification for iBeacon as a Bluetooth Profile, and we expect to see it shortly after iOS 7 ships.
An iBeacon simply sends out a 16 byte universal identifier (called a UUID). An example of a UUIDs is D8FF5C06-7D34-445B-B382-822E98849F18. An iBeacon also sends out two other values, a “major” and a “minor” number, and a transmissions power value. The UUID is specific to the company (“Twocanoes Labs”), and the major and minor numbers can be specific to the hardware beacon or beacons. UUIDs are not distributed by any specific authority. Since they are so large, people can generate themselves and the chance of conflict is very, very small. If you have a Mac, open up terminal and type “uuidgen” and you can have your very own UUID!
To illustrate how your would assign UUID, major and minor numbers, imagine you have 10 stores. You could code all the iBeacons to have the same UUID, and each beacon would have a major number from one to ten to identify each store. The minor number might be the position in the store, the department number, or some other identifier within the store.
The transmission power value is interesting as well. Since different iBeacons could transmit at different powers, you can only accurately figure out how far you are from the iBeacon if you have reference value (since a “low” signal level might mean close for a lower powered iBeacon, but far for a high powered one). The transmit power that is broadcast is the power level the device should read at 1 meter. So given that value and a detected signal strength, you can estimate how far you are from a specific iBeacon. This process is called ranging and helps the iOS device estimate how far it is from an iBeacon. Note that you don’t get an exact location from a beacon, just how far away you are. If you detect multiple iBeacons, you can figure out where you are based on the distance to each iBeacon. For most applications, this won’t matter since approximate distance might be all that you need. In other applications, however, you may want to leverage multiple iBeacons to help determine exact location. For example, if a Doctor enters a hospital room where each bed has an iBeacon, and the Doctor is a meter away from the first iBeacon, this could mean that she is on either side of the bed. By combining with the fact that the Doctor is 1 meter from one bed and 3 meters from another bed, the iPad could determine which side of the bed she is standing.
Ranging is not the only thing that helps an iOS device determine the proximity to an iBeacon. iOS has the concept of geofences. An app is able to register a geographic area with iOS, and when the iOS device enters or exits the defined area, the app is launched in the background and notified of the event. The app only has a few seconds to process this information before it is suspended (in our testing, the app is suspended after 5 to 10 seconds). This is plenty of time to notify the user, or in the case of our app Geohopper, the app then notifies our web service and triggers some external action. In iOS 7, geofences were extended to include iBeacons, so an app can register for notifications when an iBeacon is detected or when the signal is lost. If the user launches the app, the application can start ranging the distance from the iBeacon. The user can then launch another app, and the ranging app will continue to run in the background and the ranging can continue. Once the ranging completes, the app can’t start ranging again unless the user launches it again.
Another interesting part of geofencing with iBeacons is that an app can be notified with wildcards for the major and minor numbers. So an app can be notified when any iBeacon for a specific company is detected, or when a the iOS reaches a store or floor in a store. This makes it easy for app to support iBeacon. iOS will wake up the app when the requested iBeacon with the specified parameters is detected and the app can then take action.
Apps that the user is not currently interacting with are prevented from ranging until they are launched. This is part of Apple’s “user intent” model to help preserve battery life. The common interaction goes something like this: When a user launches an app, the app can request to be notified when entering or exiting a geographic region or when approaching an iBeacon and, if the user brings the app to the front, it can start ranging. Once in the background the app can complete the task, but needs the user to bring it to the front to start ranging again. Another interesting aspect of Apple’s “user intent” is that if the user removes the app from recently used app by double tapping on the home button, iOS stops any ranging activity for the app and won’t let the app start ranging again until the app is relaunched. This helps to prevent apps from draining the battery because the user is unaware that the app is running.
We discovered this when trying to get more exact distance from an iBeacon. Geohopper was set to trigger when an iBeacon with a specific UUID was in range, and this worked as expected. However, if Geohopper for iOS was notified in the background when the iBeacon was discovered, we couldn’t start ranging. It worked fine if the notification was received when Geohopper was in the foreground, and continued to work if another app was launched, but as soon as the ranging completed and a new notification arrived, Geohopper was blocked from actively trying to figure out the range to the iBeacon.
While this limits what an app can do in the background, it provides a balance between allowing the app to range in the background and conserving the battery life. It is also one of the few mechanisms where iOS will launch an app in the background once the phone has been restarted. We have tested background launching from geofence triggers in iOS 6, and iOS 7, and it works fine.
Real world iBeacon uses
As mentioned earlier, one of the first areas of interest is the retail space. Startups such as Estimote, Adomaly and Roximity Beacon are angling to provide frameworks and hardware so that apps can market directly to customers in a close proximity environment. For example, suppose you are shopping for a new washing machine at Sears. You enter the store, and the Sears app you installed from your last visit is notified that you entered the store. This is possible since the Sears app would define a fence for the iBeacon identifier. You would then open the app, and it would start ranging to nearby iBeacons with the Sears identifier. Your closest iBeacon might have a major number of 100, which might mean the Naperville store, and a minor number of 25, which might mean the front entrance. You would be presented with a store map to help you find the appliances. When you arrive at the appliance section, you open the Sears app again and the Sears app again automatically displays the specs for washers and dryers. This happens because the app detected an iBeacon with the Sears iBeacon identifier, a major number of the 3rd floor, and a minor number of the washer section.
PayPal is also jumping into the fray with their Beacon product, though it is unclear if it uses iBeacon technology. The PayPal Beacon may one day be opened to third party software developers, but currently only works with the PayPal app.
While retail is the first sector to adopt close proximity detection technology, it is only one of many future applications. When your iPhone knows its current location precisely, it can begin to see and react to the environment in interesting ways. You shouldn’t need to pull out your iPhone to turn on a light. The light app will be notified of your proximity to a light and it will turn on or off. When you walk away from your front door, it will lock. A device with precise location awareness means you don’t need to pull out your phone. Things just happen. Location-aware apps will anticipate your needs and prepare for your actions. Future apps will continue to move towards a user-centered model where the user directs the app to do something automatically, and the app takes it from there.
We did some testing with our iBeacons and the new webhooks feature in Geohopper 1.2. When I was in range of an iBeacon, the webhook would send an email to IFTTT and turn on a lava lamp sitting on the desk next to me:
The lamp would immediate turn on when I was nearby and would turn off once I departed (though that would take 30 to 45 seconds so that it was sure I was out of range).
Once an iOS device can detect close proximity and can understand context of where it is and what is around it, you can see other interesting applications as well, such as healthcare and education.
In hospitals, Doctors are already use iPads during their rounds to pull up patient information. Imagine if the iPad could be aware of its location inside the hospital, and automatically load the information for a patient based on room and bed location. Less time spent locating patient records and more focus on the patient.
Education is another area of interest as well. iOS devices are a staple in the classroom. Suppose an iPad is in room 101. An Apple Mobile Device Management Server (MDM) allows access to the room’s wireless network and disables wireless access when the iOS devices leave the room. Because the device knows it is located in the room, it will adapt to the context.
Although iBeacons are new, Bluetooth Low Energy has been around for a few years. As of the iPhone 4s, iOS started supporting Bluetooth Low Energy (http://www.bluegiga.com/show_news?id=24094915). Apple has not released the Bluetooth specifications that define how third party devices can become iBeacons. Apple did provide sample code from WWDC 2013 that shows both how a device can be a client and an iBeacon itself. The ability of an iOS device to act as an iBeacon is interesting, but it is not currently possible for an iOS device to broadcast as an iBeacon in the background. iBeacon capability is left either to apps that are in the foreground or for third party devices that act as hardware iBeacons. Image a point of sale (POS) iPad that will broadcast as an iBeacon.
Hardware iBeacons would implement the Apple Bluetooth Low Energy profile for iBeacons, once released, and iOS 7 should be able to recognize it and start triggering and ranging from it. Some folks have already sniffed the bluetooth packets (using something like this) and done some basic implementation.
We have done lots of testing in our labs as well, and using the RedBearLab mini and the custom firmware, we added support for iBeacon into Geohopper for iOS. The way triggers are handled for entering is different from exiting, although the reason for this is not surprising. When iOS 7 detects the iBeacon, Geohopper is launched in the background and triggers a notification. This happens when I am about ½ way up the stairs to our office (about 30 feet from the iBeacon). When exiting, however, I am able to exit the building and get ½ way down the block. I suspect that iOS 7 is making sure that the beacon is really out of range and not just temporarily undetected. This delay also helps if you are at the very edge of reception and potentially triggering multiple unwanted notifications. I also tested exiting the building and standing just beyond the area where the beacon was initially detected. If I wait in that area for 30 to 45 seconds, iOS will post an exit event. Overall, it works well and opens up some great ways to automate things with Geohopper that were not as effective when proximity was not this granular.
So what’s next? I suspect that we will start seeing lots of devices that have iBeacon built in. The chips that do Bluetooth Low Energy are relatively inexpensive. The chip itself is about $5 and final manufactured iBeacons are starting to sell in the $25-$40 price range. I expect the prices to drop with quantity and with time. iBeacon adoption is starting right now and while it initially will be looked upon as a technology that allows retailers to market to iPhone users based on location in the store, I am excited to see how it will be used to allow users to affect the world around them without pulling out their phones. Wearable computing with iBeacons might just mean that the phone stays in your pocket.