We recently installed IAP-505 and IAP-504 in 126.96.36.199_84926 version for one of our customers.<o:p></o:p>
This customer is using a software (SOTI MobiControl) to locate his android devices (Zebra TC52/TC53/TC28). This software is just getting location from devices.<o:p></o:p>
When he tries to locate his devices which are connected to Wi-Fi, he gets an odd location.<o:p></o:p>
It works fine when he tries with devices which are connected to cellular network.<o:p></o:p>
He ensures me that was working fine with its old access points.<o:p></o:p>
The question is: Are there special settings on Aruba access points that could impact device location?<o:p></o:p>
Thank in advance for your help.<o:p></o:p>
I don't think there is a setting for that. I'm not sure how SOTI is derriving the location, but what I have seen in the past is that if you move around APs to different locations, one of the methods for location is to use a database of wireless networks. More specific the BSSID, or the MAC address that an AP uses to broadcast an SSID. This is one of these databases, and it may take some time if you used APs in one place, move them to another place, to get that database updated.
Are your APs used in a different place, probably the 'odd location' in the past? I think if you login to Wiggle, you can search for the BSSID (and you can get the BSSID by running 'show ap bss-table' on Instant AP command-line.
The BSSID-based databases with both Google and Apple operating systems are kind of a black box with regards to how they work and the sanity checking involved on the back end to determine if a BSSID's location needs to be updated. From what I've been able to determine through observation is that there is some sort of quorum approach that looks at the IP location, satellite, cellular, and existing BSSID information, and from there it makes a determination about whether to update the BSSID's information in the database.
Early on, these databases were built on Skyhook's technology, which had the ability for integrators and operators to upload a list of BSSIDs and their corresponding locations (much like you can with MaxMind and other IP location databases), but when Apple and Google went proprietary with their tech, and Skyhook was subsequently acquired by Qualcomm (and eventually faded away), that capability was removed in favor of algorithms.
Where these algorithms go completely off the rails is when the entire network is aboard moving vessels such as ships, aircraft, or land vehicles. The sanity checking and algorithms for updating the data simply do not know how to handle that particular corner case. It's become problematic on cruise ships where device usage has increased dramatically in the last decade, and it makes for some amusing (and annoying!) failure modes for things like AirTags.
I'd really like to see 802.11 be able to provide AP latitude/longitude/elevation/floor in the beacons, and then the client devices refine their location based on FTM, but we're not quite there yet... 802.11mc is a big step in the right direction, and hopefully 802.11bc can also augment this capability. But we also need to get the major device OS manufacturers to get on board with it. My understanding is that Android already supports FTM, and we make use of it with the UXI agent for Zebra scanners.
You are right. I prepared access points at my office before installing it on customer's site.<o:p></o:p>
Everything is working fine now. The database which you are talking about should be up to date.<o:p></o:p>
Thank you for your help.<o:p></o:p>
© Copyright 2023 Hewlett Packard Enterprise Development LPAll Rights Reserved.