Architecture

High-level architecture and workflow

Access Points transmit the RSSI of wireless devices and neighboring Access Points to the CLE an integral component of Central, through HTTPS on port 443. CLE processes the RSSI information from Access Points to calculate device locations. Subsequently, RSSI is distributed to the Presence Analytics dashboard within Central and the computed device location data is sent to the APIs and the data store. The architecture that supports the functionality of the Central Location Engine resides primarily within the cloud, specifically Central, at a high level for location engine operations.

Workflow

By following this workflow, the location engine can effectively handle changes in Access Point placement and new floor plans, and provide accurate client location information for various applications, including real-time tracking and visualization through the Floor Plan manager.

Floorplan The floorplan manager on Central allows the user to upload the map file and provide information to accurately scale the map.

APs placed on the map Once Access Points are placed on the map, APs will transmit RSSI data to the Location Engine.

Central Location Engine The Location Engine processes the incoming RSSI data and calculates the location of the clients.

APIs CLE publishes the location data to streaming services that can be used by third-party applications and systems for gaining contextual insights.

Hazelcast CLE efficiently writes data into Hazelcast, a real-time data platform, ensuring data integrity and accessibility.

VisualRF VisualRF initiates a query to Hazelcast for location data upon receiving an API call from the UI in the backend.

Floor Plan View (UI) The Floor Plan View (UI) elevates user experience and displays client locations on the floorplan.

Security

Central places a strong emphasis on security, ensuring that administrators have a wide range of protective features to keep their networks safe and sound. The platform delivers robust security measures. For detailed insights into Central’s security features, refer to the Central Security Overview page.

One of Central’s security approaches involves addressing the evolving landscape of device security. Central employs anonymization by facilitating the hashing of client MAC addresses. When enabled, anonymization ensures the anonymity of client identities by employing a one-way hash function. It is important to note that the same hash will consistently correspond to the same client, maintaining a unique yet secure identifier. For added flexibility and privacy, administrators can configure the system to change the “secret key” used for generating hashes at customizable intervals, such as weekly or monthly.

Data retention

Central is not designated to store historical location data. The database is specifically designed to provide an instantaneous view rather than an aggregated perspective, showcasing the current distribution of associated clients on the floorplan. It is important to note that the time-to-live (TTL) for any location data related to a device is approximately 17 minutes.

Accuracy

The client’s location is determined by analyzing the RSSI detected by Access Points, considering the maximum four strongest RSSI values on the same channel.

Considering the prerequisites are met, the typical accuracy of location calculations is in the range of 5-7 meters.

Impact of MAC address randomization

Most mobile device vendors use random MAC addresses during probe requests as a privacy-enhancing feature to protect the user’s identity and location while scanning for Wi-Fi networks.

Central excludes unassociated devices that use random MAC address data from the data analysis. Central, however, does monitor and record data for associated clients using random MAC addresses.

Before AOS 8.7.1.5, all clients using randomized MAC addresses were subject to monitoring, and their data was recorded. However, starting from AOS 8.7.1.5 onwards, and in AOS 10, random MAC addresses are handled at the AP as follows:

• AP filters random MAC addresses seen from probe request frames and discards them. As a result, location-based services do not have visibility for these MAC addresses.
• Random MAC addresses & legitimate MAC addresses seen from management frames other than probe requests will be stored and forwarded by AP.
• Random MAC addresses & legitimate MAC addresses coming from data frames and control frames such as Block ACK will be stored and forwarded by AP. These frames typically indicate connected clients.

The analytics trends and metrics from client devices using MAC address randomization are still relevant for customers to leverage. Since the focus of Presence Analytics is on aggregate trends and insights and not on individual clients, the impact would be minimal for trends observed over some time. There is close to zero impact of MAC address randomization on trends involving associated/connected client devices.

MAC randomization will not impact the insights provided by Presence Analytics. Only metrics such as dwell time, visitor, and passer-by may be minimally impacted.

In the case of an iPhone, the device needs to meet these four conditions for using a randomized MAC address while probing:

• Wi-Fi must be turned on, but the device is not associated with an actual Wi-Fi service.
• The phone needs to be in sleep mode. iPhones go into sleep mode when all the services in the phone are inactive, and not just when the screen is turned off.
• Location Services set to off in the Privacy & Security settings.
• Cellular data must be turned off.

As all these conditions need to be met, there may be a much lower percentage of devices using randomized MAC addresses on the network.