Wireless Access

Reply
Occasional Contributor I
Posts: 9
Registered: ‎09-20-2016

Access Point capability - Location awareness

[ Edited ]

Hi all,

 

As part of a feasibility study, I am currently looking at hardware limitations and particularly at Aruba APs limitation.

 

Brief explanation regarding this study, unlike Wifi common deployment we are looking here for a Wifi-based location tracking solution in outdoor/indoor venues. Purpose is to manage very big crowds (thousands/millions). People would be tracked thanks to a wristband embedded with a Wifi module.

 

In a standard 802.11 environment (auth process, data transmission etc...), an AP theoretically allows 255 clients simultenous connection, best practice is 30 clients. However, in a location tracking scenario only very light data would be transmitted at regular intervals just to beacon client location to APs. My guess is that an AP can process more clients if only their signals needs to be interprated.

 

My wonder is, how many signal a single Aruba AP would be able to treat/process succesfully at the same time ? Not an easy number I know...

 

If you may have similar use cases to share, please do not hesitate !

 

Thank you for your insight.

 

Sim

 

MVP
Posts: 1,357
Registered: ‎11-07-2008

Re: Access Point capability - Location awareness

For wifi, Each device would have a macaddr and it's generally a physical/PHY layer limitation of the chipsets (for all vendors) that supports up to 255 associated clients. So there's not much chance to go over 255 per client.

 

Better solution is something like Meridian where the tracking is done client-side and there's no receive-back PHY limitation on the receiver/radio.

Jerrod Howard
Sr. Techical Marketing Engineer
ryh
Occasional Contributor I
Posts: 9
Registered: ‎09-27-2015

Re: Access Point capability - Location awareness

I saw this question and I thought I should chime in to help you out.  From my experience your intuition was right.  I would read through this whole post, as it might clarify some things for your application and consideration of Aruba to fill this need. Periodically mapping the device locations seems like your intent. Aruba's ecosystem is actually really great for this, if you are willing to bring some work and coding to bear on it, or work with a partner who does this already.

 

The 255 limit is a chipset limit per radio, so a dual radio AP can have 255 max associated devices on 2.4GHz and 255 on the 5GHz band. Since your wifi bracelets are probably 2.4GHz only (for cost), or single band only at the least, it makes sense that the limit for associated devices would be the 255 limit.  However.....

 

Meridian would not be the right use-case for this deployment.  It doesn't currently support moving beacons, only moving client smartphone devices in a fixed constellation of location beacons deployed.  And it requires the app installed on the phone, with bluetooth on, the app active, and directly using it for the client to see where they are.  And while the Meridian location calculation yields more accurate positions (1-3m) than wifi due to power in the RF of the beacons, once that location is calculated it is trapped in the app... unless you use the SDK in an app to stream it out to another server.  The basic requirements to calculate location with Meridian translates to an unreasonable cost to get every person in the venue to that level.  Ultimately, this is like filling your gas tank with milk: sure, you can do it, but it isn't going to work like you were hoping and you're left with an expensive mess.  And you'll never forget the odor.

 

In terms of pure location tracking via wifi, I think you're looking for the Aruba product A.L.E. (Aruba Location Engine). with Aruba APs, it calculates location positions using the AP/IAP messages about heard stations (802.11 devices) & their RSSI in dBm, not just those associated to them, and then streams out these messages to *somewhere else* where you have a process to do something with that raw data.  This AP behavior of reporting detected devices is what enables the Aruba WIDS engine to classify other devices as rogue, interfering, etc, and is used to great effect in ALE or more commonly AirWave's VisualRF.  The AP has to hear the station beaconing or communicating - which means it has to be listening on that channel when it occurs - but this can be helped for your application by turning all APs into AMs (air monitors) and playing with some of the scanning parameters to cover the whole spectrum by multiple APs.  ALE's algorithm requires 3 or more APs that have heard that station in order to calculate the x,y position (and x_error) and place it on the map.  The location accuracy isn't as good (many meters instead of a few, and depending on # of APs and inter-AP distances) but it does calculate out many many devices.  Since it relies on hearing events, it does mean the wristbands need to be actively beaconing frequently, and many of these will be missed; Meridian/BLE gets around this by beaconing at about 10Hz, and calculating position every second or so.  ALE positions update every 30 seconds or so, if it has the data needed, but this might be tweakable in some way, probably from within the IAP/AP group configuration for its frequency of communication with ALE.  It can also notify if stations enter or leave definable geofenced regions, which may be helpful for managing flows.

 

Really curious: Why are you wanting to track potentially millions of people with wristbands?  When would this even be a possibility to have a captive audience of millions and their (hopeful) consent to be tracked?

 

Hope that helps you or others in some way.  Meridian is great for its particular use case - on smartphones at locations to deliver a pre-packaged experience to engaged customers - but stretching beyond this requires gymnastics.  Either you are looking at building your own BLE based solution from scratch, or you are looking for something that works in tandem with ALE.  Aruba would fit your needs with its APs and ALE.

 

Cheers!

Search Airheads
Showing results for 
Search instead for 
Did you mean: