AltBeacon vs. iBeacon, isn't this just fragmenting things further? #iBeaconWebinar

  • 1
  • Question
  • Updated 3 years ago
  • Answered
First, thanks to everyone at Aerohive and Radius Networks for taking the time to provide the webinar.  I have been following iBeacons casually for some time and am looking forward to seeing Matthew Gast's book on the subject.

The subject line above comes from an article I read awhile back.  I don't think this is the exact article, but it covers the same material basically:

And straight from the horse's mouth:

Now it seems that Apple has been clamping down on who can use the term 'iBeacon", and it does feel like they're trying to keep things a bit to themselves vs. making an open standard of it all.  (And I say this as I type on my iMac with my iPhone in my pocket and iPad Mini on my desk.  So while I'm no Apple hater, it doesn't mean I approve of everything they do.)  And I don't get the concern that another company like Radius Networks would like to provide beacons or even toolkits/dev tools to help folks write software for same.  Why should this bother Apple?  Isn't "the more the merrier"?

However, while I admire Matthew Gast's take on it all, that it's based on Bluetooth LE which is a well-established open standard and so hopefully it will all just work, I am a little concerned by the disconnect I see here.  Radius Networks, once apparently blocked from using the "iBeacon" name, opted to rebrand their toolkit as AltBeacon.  However, they didn't just rebrand.  They changed the specification, making it "more flexible and [able to] 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."

However, if Radius Networks is successful in getting folks to use AltBeacons (both their hardware and software), they will have effectively done no different than Apple.  They will "break" iBeacons, instead replacing it with their offering.  I honestly don't see a difference.

Or at the least it will create two markets, one for Apple users with iBeacons and another for Android/non-iOS users with RadBeacons.  Don't we have enough fragmentation as it is?  What if a retail chain wanted to provide proximity based services to all its customers, regardless of what phone they have?  Are these chains going to have to deploy 2 sets of beacons at each location?  From a customer perspective, I hate seeing when a market gets fragmented.  It doesn't do me ANY good, and the only ones who benefit are the various vendors.

If Radius Networks was truly about interoperability, why not simply use the iBeacon specification, just name it RadBeacons?  Why on top of changing the name alter the specification?  I don't recall Apple having a patent or copyright on the particular specification they're using.  And as Matthew pointed out, it's all BLE which is an open standard, so again, why the change?

However, maybe I'm seeing this wrong.  Truth is, I am interested in tinkering in this area to fully grasp what might be possible, but I haven't had as much time to do so as I'd like.  And maybe Radius is onto something.  Maybe their specification offers more flexibility, I honestly don't know.  What I do know is that when the dust settles, ideally there should be a single OPEN standard, preferably with an open source implementation, and those in the market compete on features.  (Sue me, I'm a pragmatic idealist.  I believe in open source and open standards over anything proprietary, resorting to the latter only when absolutely necessary.)

Photo of Frank


  • 15 Posts
  • 8 Reply Likes

Posted 3 years ago

  • 1
Photo of David Helms

David Helms, Champ

  • 34 Posts
  • 4 Reply Likes
Hi Frank!

First, let me thank you for investing so much of your time and personal thought into this issue. While I won't speak to Apple's intention with iBeacon, it is a technology that we and all other authorized providers license from Apple. It is their technology to take forward in whatever way they think best.

Having said that, I AGREE WITH YOU on the potential problems with market fragmentation. That is why we put a lot of thought into AltBeacon before we introduced it and we designed it to specifically avoid fragmentation. The way we did that is to make sure that the AltBeacon specification could be implemented along-side of the iBeacon implementation in the same beacon so that beacons could do interleaved advertising of both beacon advertisement formats. This new class of beacons is something we call the Multi-Beacon.

That is also why we published AltBeacon as an open-specification with a Creative Commons share-alike license and why we have been actively assisting other beacon vendors to implement support for AltBeacon.

We thinK Multi-Beacon is the smartest way to get the benefits of iBeacon for the iOS world and simultaneously provide the same experience for non-iOS devices. The RadBeacon USBs that Aerohive will be using with their APs are the same that we are providing as promos for people on this forum and that we ship today and they all implement Multi-Beacon support for iBeacon and AltBeacon.


David Helms
CPO Radius Networks
Photo of Matthew Gast

Matthew Gast

  • 284 Posts
  • 63 Reply Likes
I'll build a little bit on David's comment here.  I've read the iBeacon spec (obviously), and I read the AltBeacon spec when Radius released it.  If you compare the two, they're very similar, which facilitates interoperability.  As a programmer, you can use AltBeacons in the same way that you use iBeacons because both beacons transmit the same information.

The big things that AltBeacon gives you above iBeacon is that you can be much more flexible about how you define a proximity ID.  Instead of being just UUID+major+minor, AltBeacon lets you vary how much of the ID is devoted to major and minor.  (It's sorta like the difference between class-based addressing and netblock addressing in IP; AltBeacon lets you "subnet" anywhere in the major+minor number space.)  AltBeacon also includes a field for vendor extensibility that can be ignored by iBeacon.

Where I expect AltBeacon to stand or fall is based on its developer support.  iBeacon has a strong supporting framework in CoreLocation.  Radius will have to develop a similar framework for Android, or plug into a forthcoming standard framework from Google.  Radius already developed a CoreLocation work-alike for Android, so I think they're in tune with what developers want and need!
Photo of Kathy Yang

Kathy Yang

  • 1 Post
  • 0 Reply Likes
iBeacon development kit CAN-BUS shield: