Tag Archives: iBeacons

A Little More on Beacons- Promise and Frustrations

Last week, Beacon Fever bit me, as I described here. Since then, I’ve made little progress in actually doing anything of real-world value with the three Qualcomm Gimbal beacons that I have on hand. But that doesn’t mean I haven’t gained a bit of an education in the few hours I’ve noodled around with them as I’ve consorted with The Google on where to go next. Allow me to share just a little more on Beacons, then I’ll likely put the topic away for a while.

What I’ve Learned:

  • There is a good variety of beacon hardware out there. Here’s another list
  • If you don’t want to $pend, Android and iDevices can be configured to act as beacons for testing
  • There are lots of mobile beacon management and scanning apps out there- some from the beacon manufacturers and some from 3rd party developers
  • The entire proximity paradigm with beacons is built on leveraging “degrees of nearby-ness” like near, far, immediate vicinity, out of range
  • Beacons can be USB powered, or battery powered. If using battery, there will be administrative burden of battery upkeep in large deployments over time
  • Beacons don’t just magically come to life, you have to activate them and do a basic config
  • Every beacon maker seems to have their own management console
  • You can see where heavy beacon use would very much be “another thing to manage”, despite having really cool real-world use cases
  • A “UUID” gets assigned to all beacons in an organization that will be part of the same “system”
  • Each beacon can make use of a Major and Minor field to further segment/identify them
  • Without an application to use with them, beacons aren’t real exciting
  • To leverage beacons, SOMEBODY has to do some coding, and there are a number of frameworks to do that in
  • For people like me, who are definitely not endowed with coding skills, some companies are trying to make “getting started” a little easier
  • There are a lot of beacon videos on YouTube, and blogs from others’ efforts to be had online
  • It doesn’t look like all vendors beacons are welcome in each other’s development environments
  • Connected users “opt in” by enabling Bluetooth on their smartphones, tablets, etc.

That’s the short of it for me, so far, on actual knowledge gained. I also tried to do more with my Gimbal beacons, but found some frustrations- like simply setting the UUID, Major and Minor fields. It looks like other vendors make this a lot more intuitive, but perhaps my lack of experience is the problem here. On my Gimbal developer account, I understand each individual word but get foggy when you put it all together in phrases and sentences. There is a Gimbal iOS management app, but none for Android that I have found yet.

I did discover a couple of promising leads for myself in learning more, as a mental-midget when it comes to programming. Estimote makes a popular kit that comes with three beacons, and from what I can tell their app-building tools seem to have folks like me in mind. But… each kit is $99, and indoor location requires two kits (for some unspecified reason). I’m not ready to drop $200 on beacons yet, but maybe at some point.  And… Meridian (An Aruba HP company) also seems to understand that some of us need all the help we can get. They put a very friendly face on getting started, and I hope to learn more about this product set/application framework in the months to come.

So… that’s all on beacons from me for now. If anyone reading gets further with these fascinating little transmitters, please share what you learn.

Aerohive and AirTight Announce IoT “Firsts”

There aren’t too many opportunities in life to claim “we’re the first to _____!”  There’s a bit of a glow that comes with being first to market, even if the first whatever isn’t really monumental or exactly disruptive.  In the last couple of weeks, both Aerohive and Airtight (cloud-managed WLAN vendors for those of you late to the party) made a “We’re first!” announcement, each with Internet of Things (IOT) implications. Let’s take a look at both.

Aerohive- First Integration of WLAN and iBeacons

Here’s the official news from Aerohive. The nuts of it is that Aerohive and beacon-maker Radius Networks are pals, and Aerohive APs can directly host ibeacons via USB port on the access point. The notion of ibeacons (and altbeacons) is really just getting started, so this could become big and will likely ripple out far beyond it’s infancy in retail spaces. Though the companies are partners on the initiative, there’s really no changes per se to Hive Mananager that goes with having RadBeacons attached to APs.

Here’s my own coverage of the story at Network Computing. If you’d like to further the iBeacon discussion, please post comments over there.

Then there’s this:

AirTight- First Access Point with ‘IoT-ready’ WiPS

I’ll admit to being underwhelmed when I saw the press for Airtight’s new C-65 access point. Sure, any new 11ac AP is worth noting, but the up-play of it’s “IoT readiness” seemed to be a stretch. So, I asked- what makes this one so special versus the competition?

Here’s what AirTight says about the C-65 in their own words:

Two key things in IoT readiness for WIPS are system scalability andoperation scalability because of increasing device volume and diversity and growing attack variants.

 
1.     System scalability
o    AirTight increased the ability to monitor active wireless devices from 500 to 2000 per AP/sensor
o    On the cloud side, we increased the ability to scale to hundreds of thousands of devices being monitored across multiple geographies and customers
 
Scalability bottleneck in IoT will be coming from neighborhood devices that you need to track for threat detection, compliance reporting, etc, rather than your own APs that you manage in the cloud.
 
AirTight’s tests and customer POCs have shown that because the competition does not have this scalability today, device history is not maintained long enough; alerts are quickly purged to maintain scalability; reporting and forensics are thin; and threat detection is slow.
 
This happens today; what will happen tomorrow with hundreds of IoT devices in your wireless neighborhood?
 
2.     Operation scalability
o    The detection is behavioral based rather than signature-, rules or MAC heuristics- based
o    “Zero day protection”: no learning or adding of signatures is required
o    Minimal human intervention required
o    False alarm free
o    Reliable automated prevention without neighbor disruption
 
Our detection algorithm has matured over the years because of our focus on WIPS and is able to handle nuanced protocol implementations. So AirTightWIPS is better suited to handle device diversity. Other vendors are mostly doing MAC heuristics to detect rogues and have not invested in detecting all variants of threats and attacks.
 
Again, we have seen the impact of this in POCs and internal tests. We have seen competition raising false alarms (false positives and false negatives), along with creating large number of alerts for the administrator to sort through. Some products even discourage users from turning on automated prevention via product messages and technical documentation.
And there you have it.  Neither of these announcements is mind-blowing yet at the same time they serve as examples of where WLAN vendors’ heads are regarding IoT at this stage.
In case it isn’t obvious, we’re likely to hear a lot more about how the Internet of Things will shape wireless solutions, and how vendors think we should be preparing for the IoT onslaught. It’s gonna continue to come at us in little chunks as the seeds of IoT take root, so keep your eyes open or you’re going miss something.