Radius Networks has launched a new open standard for beacons today called AltBeacon, and with it is laying down a protocol that may become a de facto standard for developers who want their proximity beacons to do more than just work with iOS devices.
While initially targeted to Android devices, AltBeacon is an open specification and will generate innovation across a variety of platforms. It will go a long way in bringing parity to beacon development…an issue right now because Apple clearly has a head start with its iBeacon specification.
The company, which recently removed its “Android iBeacon libraries” (possibly under pressure from Apple, or at least the Apple licenses) is setting out to establish a set of tools that will make it easy for beacons to communicate with Android, Apple, Windows and other customer devices.
In a post about the move, CEO Marc Wallace explains the launch of AltBeacon:
Currently, no open, interoperable specification for BLE proximity beacons exists. Only proprietary specifications exist, which favor one vendor over another. We hope that AltBeacon solves this problem. We also believe we have created a specification that is more flexible and can accommodate different types of proximity beacon implementations and solutions that can benefit by not being locked into a specific format, such as rigid identifier lengths and additional payload space for critical information.
Released under a Creative Commons license, AltBeacon sets out to do two things: define a robust specification for device transmission (the packets that a beacon sends) and a suite of tools and references to make it easier to develop apps that “listen” for beacons.
Better than iBeacon?
The AltBeacon specification will leave developers who use Apple’s iBeacon specification drooling.
While Apple has made Bluetooth LE proximity easy to develop for and deploy, and while devices carrying the iBeacon name can be assured that iOS apps will run seamlessly with the beacon, there are limits. In particular, Apple limits how much of a beacon’s “packet” can be used with the iBeacon SDK.
But the power of Bluetooth LE is in its flexibility and simplicity. A device that broadcasts a BLE “packet” with a proximity profile can do a lot more than just transmit its TX power, UUID and major/minor values. Its advertisement packet can be customized to all kinds of use cases, making fleet management incredibly flexible and even embedding vendor or retailer-specific data that could be used client-side to refine the experience for the user.
But on Apple devices, you need to use CoreBluetooth to dive ‘deeper’ into the BLE packet. Developers therefore need to dance around using iBeacon, because of its ability to detect beacons even when the app is closed, and CoreBluetooth because of its ability to pull out and respond to additional data. As well, the beacons themselves can be certified as iBeacon or simply BLE, complicating the ‘stack’ for an iOS developer.
Going Deep with BLE and AltBeacon
AltBeacon brings greater transparency to what a beacon transmits and how that data can be used by Android, Windows and other devices. By helping to shift towards a shared standard for non-iOS devices, AltBeacon will empower developers to truly take advantage of what a BLE proximity beacon can do.
As Marc commented to me this morning: “Our real challenge is to evolve our tools to minimize the confusion and impact on the development effort. If beacons easily speak multiple transmission types and development tools painlessly integrate them across the respective multiple mobile platforms, everyone will benefit.”
So AltBeacon will stand confidently beside iBeacon as a new way to accelerate beacon adoption for non-iOS devices and will, it’s hoped, bring greater parity to the two platforms.
The release is accompanied with a new Android Beacon library on Github and some great tools, resources and examples.
Share Your Thoughts
Join our weekly e-mail list for more on iBeacons. Join the conversation on Twitter, or connect with me on LinkedIn.
What do you think? Will an open standard like AltBeacon help bring parity between Android and iOS?
BEEKn 
This is good news, and I think the guys at Radius Networks have a good chance of making this work.
For me, critical success factors include keeping the API simple (while undoubtedly constrained, the iBeacon spec is at least simple enough that most can easily engage with it), and getting support from hardware vendors.
I wish the team luck, and will certainly be looking at embracing the spec within my own applications.
LikeLike
It is not the first BLE advertising effort to propose something that is different from iBeacon. All the players in the field before the announcement of iBeacon had their own standard, some of them being more or less open. The problem is that the iOS ecosystem is more or very much controlled by Apple and although the number of devices in Android are raising rapidly, the share of active users on IOS for most brands and retailers for instance is much larger on iOs than the current market share of Apple on Smartphones. Therefore for these companies iOS is strategic and I would be super surprised that anybody can achieve on IOs something that works better than iBeacon for BLE advertisement because is it really well integrated at system level and this is what gives the cool features of waking up a closed app for instance….
BLE advertisement size is pretty limited. An advertising packet can be up to 31 bytes of data. Each field (i.e. appearance, name, service UUID or similar) have a header of 2 bytes (length and type), meaning that the maximum user payload is 29 bytes.
I think iBeacon is using 21 or 22 bytes in total so you would have in theory maybe 8 more bytes…Which could give some extra flexibility but it is not like a huge “game changer” IMHO.
BTW you can do cool things by playing with the major/ minor and UUID in IOS and linking that to a database on the phone.
At ubudu we did a couple of cool things for instance while still sticking to i-beacon format :
– Broadcast battery levels alerts
– Rotating minor/ major with symmetric cipher to provide a time sensitive anti-replication iBeacon advertisement mechanism for enhanced security.
Of course if we had the 8 extra bytes we could have sophisticated a bit these approaches which we had to engineer taking into account the limitations of the format but as a matter of fact, iBeacon format was not more and hurdle than having only 29 bytes to advertise.
I am pretty sure that BTW some Apple competitors on Android will come up with their own advertising format. Let’s see if they adopt AltBeacon or something on their own.
CoreBluetooth or the equivalent on Android is the only way to connect to the beacons which you need to be able to program them for instance or trigger other functionalities.
In our experience on IOS when using it for advertisement, in background mode (in foreground it works more consistently well), it is not as good as the iBeacon framework which is handled at system level. On Android in 4.3 you needed to manage scanning of BLE advertisement on your own. While you can build bootable services in Android, working in the background on IoS, for the good and the bad, in IoS is much more tricky as Apple tends to limit somehow your CPU and access to ressources time.
In conclusion, good luck for alt-beacon, but to achieve true interoperability something that works as well on IOs and Android, I would stick for now to the iBeacon format which could also evolve btw.
If others had different and more positive experiences while working in the background on IOS with other BLE advertisement formats please share, i would be interested to know.
LikeLike
Great post Francois – thanks for sharing your experiences and analysis. 🙂
LikeLike
Sir, What you want to say about Eddystone ?
LikeLike
Hi Joginder,
So in a way Eddystone is another reshuffle of the 23 bytes of BLE advertisement. It provides a way to standardise a way to encrypt a short URL in a BLE advertisement frame (Eddystone URL) and also provide a standard to broadcast TLM (Battery level etc…).
The new good ideas comes from not broadcasting only 1 format of advertisement (especially until the data available is still 23 bytes => that will change a lot with BLE 4.2 where the packet frame will be 270 bytes) but mix several formats as there are several needs that need to be taken into account. It is a pity btw that Apple is not making its iBeacon format evolve a bit…
The other game changer is the support of Chrome of Eddystone which gives a way to take advantage of beacons proximity (although in a quite limited manner) for a very large user base to point to an URL (e.g. the install page of an application for instance).
It fails for now to provide answers on the security part (not everyone one want to have its proximity signals to be available to anyone not authorised or faked e.g. the battery levels).
At Ubudu we implemented the Eddystone URL which cohabits with the iBeacon advertisement format (the only one that can wake up on IOS App), the TLM part was already handled by us with some signed advertisements that can not be fake. We follow the evolution closely, when Eddystone will support the security features we need and that we built on top of iBeacon we might consider moving there.
Our retail clients are not “fans” to have Google store their beacon data…as they are trying to limit its omnipotence in the advertisement and customer data knowledge field. The positive effect on Eddystone was that it confirmed that BLE beacon was a major trend that will last beyond Apple iBeacon format and that it is big enough that players such as Google invest in it.
So my recommendation would still be :
– For a consumer app : stick with iBeacon format for interactions with Apps (unless you want to use the new Google Beacon API or near by API). It will works on any system and provide the more extended range of features on IOs.
– Add Eddystone URL (to cover clients without an APP) => possibly with the same beacon so that you can better leverage the HW investment
– If you want to leverage the Google Beacon API => consider also beacons supporting Eddystone UUID and Eddystone TLM
@ubudu we thing the next frontier is more interacting within the venue as there are many connectivity issues that make lot of compelling use cases difficult to deploy in venues networks. This is where the mesh feature that we developed really matters. It provides bi-directional messaging with users and remote maintenance (i.e. each beacon can report or be reconfigured with a gateway, without having necessarily a star network topology).
I hope I answered to your questions,
BR,
François
LikeLike
Thank you sir for your reply.
LikeLike
As a provider of services based on BLE with customers using all brands of devices, not only iOS-driven, we can not cope with the seemingly beginning closeout of other OSs by Apple. At best we could have a standard open enough to serve all worlds, but I am afraid we will end up with dual, triple or even more implementations across the various apps.
I understand the intention of Apple, but it will not be tolerable on the service providers’ side.
LikeLike
I can confirm that migration from the now withdrawn Android iBeacon Library to the new AltBeacon centric version is relatively quick and painless.
I downloaded the provided tar file, imported it into Eclipse (ADT), changed the relevant method calls and indulged in a little light refactoring. From start to getting the migrated version of the app up and running took a couple of hours.
The app handled AltBeacons by default, and getting it to recognise iBeacons was just a matter of passing the correct parameter when instantiating a BeaconParser (instructions for doing this can be easily found via a quick google search).
I’ve published the hybrid iBeacon/AltBeacon compatible version of my Beacon Scanner & Logger app to Google Play and source code is available on gitub (links to both are available via my blog – click my name above to visit)
Thanks to the team at Radius Networks for making this library available so soon after the withdrawal of the iBeacon version – well done on another quality product guys. 😉
LikeLike
I wouldn’t advise people to invest in AltBeacon. It seems like a diversion that should be avoided.
While I commend Radius for their production of compact USB powered beacon hardware and their http://www.wikibeacon.org beacon registry, which provides interesting sample data of beacon deployments around the world, this particular effort doesn’t seem destined for success.
An announcement of this kind should be accompanied by at least a few heavy hitters in the industry to be credible. Ideally the OS vendors or failing that some set of otherwise competitive hardware providers (see what Motorola Solutions did http://mpact.motorolasolutions.com with their announcement of MPact along with Swirl, Digby, Phunware …) or failing that maybe a major developer or retailer.
Wait until everyone gets back from their summer holidays (when something like this should have been announced) and I would expect more from the OS vendors that would be relevant. Having one beacon API standard that works across OSes is desirable but unrealistic at this stage.
1. Means – The OS vendors own the success of standards in this space, they have to – As has been pointed out on this site the role of iOS is critical in controlling the process scheduling, privacy management, alerting and power management integral to the success of beacon applications. Not only are the OS vendors gatekeepers they have significant work to do so that the interests of all the stakeholders (beacon vendors, app developers, brands, users and themselves as purveyors of phones) are balanced. Just because Google has been in catch-up mode in terms of its support of BluetoothSmart beacons doesn’t mean that it is going to permanently abdicate involvement.
2. Circumstance – The standards in this space will change, but it will be the OS vendors who must address the short comings, important things like configuration management, battery status and obfuscation/conditional access to beacons (public and private) should be included in future revisions of iBeacon and whatever Google may announce soon.
3. Motive – The mobile OS vendors have core businesses that rest on these standards as they evolve – indoor mapping and the beacon and advertising networks that goes with that which they won’t abandon for the sake of open source efforts
While I applaud the goal of AltBeacon, the approach seems flawed in timing, execution, the stakeholders involved and the scope of the standard itself.
In the interest of full disclosure (and self promotion), I used to work at Qualcomm as head of Strategy and then Solution Management for the group that spun out Gimbal. I left at the time of the spin out. My personal opinions expressed here don’t reflect those of my past employer or ex-colleagues. I now provide beacon training courses independent of that team and work collaboratively with other beacon vendors.
LikeLike
Whether or not the AltBeacon spec itself ultimately becomes widely used, we now have an open source library that allows Android devices to interact with iBeacons. So I’m personally extremely happy that Radius didn’t wait for the end of the summer holiday season to announce AltBeacon and make the library available. For developers looking to provide Android versions of their iBeacon apps, the AltBeacon library is basically the only game in town right now.
Your analysis is very interesting and I’m broadly aligned with your thinking, but let’s not overlook the role the developer community plays in the success of a technology (and I’m conscious of the fact success can be a relative concept): the OS vendors may have provided their app stores, but it was developers that populated them with compelling products that drove users to embrace them.
It’ll be fascinating to see how this all plays out.
LikeLike
[…] [Note: An animal version of this "opinion" was originally posted on http://www.beekn.net as a response to Doug Tompson's discussion of AltBeacon ] […]
LikeLike
I had integrate Altbeacon sdk in android project in eclipse.
But Can not detect Beacon.
please rid out from this problem. Give me proper step by step guidance.
Your Guidance will be appreciated.
Thanks in advance.
LikeLike
I’m afraid you’re looking in the wrong place for technical support, try one of the resources listed on the AltBeacon.org project site or maybe search Stack Overflow for similar issues. Good luck with your project.
LikeLike
[…] detection through standards like Radius Networks and its AltBeacon open specification allows app developers to create proximity-based experiences. Deploy a few […]
LikeLike
[…] Physical Web is also interesting because it serves to mark a potential strategic direction for Google as a device platform ecosystem player in a post-app world. iBeacon, though superficially similarly based on BTLE, does not require an ecosystem intermediary – it’s quite possible to build simple iBeacon triggered “indoor GPS” services which don’t involve Apple backends. However, the technology is relatively limited and proprietary to Apple devices which has already resulted in a forked version called AltBeacon for Android. […]
LikeLike
Great Article!!!
I have one question concerning AltBeacon…. Do all devices support AltBeacon automatically?
Kind regards
LikeLike