Location services

• 1: Central location services deployment guide
• 1.1: Overview
• 1.2: Wi-Fi analytics solutions
• 1.3: Architecture
• 1.4: Design and deployment considerations
• 1.5: Partner integration
• 1.6: Troubleshooting
• 2: Open Locate deployment guide
• 2.1: Overview
• 2.2: Getting started
• 2.3: AP testing and verification
• 2.4: Partner integration
• 2.5: FAQ

1 - Central location services deployment guide

Location services and analytics are provided by the Central Location Engine (CLE), a service running within HPE Aruba Networking Central, and are commonly used in modern wireless networks to provide contextual insights into devices on the network based on their physical location. CLE consumes and processes raw Wi-Fi data sourced from HPE Aruba Networking Access Points managed by Central and running HPE Aruba Networking Wireless Operating System AOS 10 (AOS 10) or HPE Aruba Networking Instant Operating System AOS 8 (InstantOS 8). The CLE service is Aruba firmware-agnostic, ensuring consistent functionality across both the AOS 8 and AOS 10 firmware versions.

Notably, the HPE Aruba Networking Analytics and Location Engine (ALE) existing on-premises location analytics product, has laid a strong foundation by computing contextual data for associated and unassociated clients within defined areas. Building upon this legacy, CLE not only inherits the capabilities of ALE but elevates them through its cloud-centric architecture and enhanced precision.

1.1 - Overview

Use cases

Calculated data provided by CLE can be consumed by Central’s Presence Analytics application or by third-party analytics applications using Central’s rich set of contextual APIs.

The Presence Analytics dashboard provides insights into customer behavior and intent, showing a condensed overview of visitor behavior and patterns, data on dwell time, draw rate, loyalty, visitors, and browsing habits. Central also integrates with several solution partners to unlock various use cases. To learn more about our technology partner programs, refer to the partners portal.

• Tracking the Impact of Promotions: By monitoring foot traffic before, during, and after a promotion, businesses can determine if a particular campaign successfully increased user footprint.

• Identifying Returning Users: Presence Analytics can identify returning customers based on their device’s unique identifiers, such as MAC addresses. By recognizing repeat visitors, retailers can gain insights into customer loyalty and engagement.

• Dwell Time Analytics: In addition to foot traffic, presence analytics can provide insights into how long customers spend in different areas of a store. This data reveals which sections are more engaging and attract longer dwell times.

• Comparing Store Performance: Retailers can gather data and later use it to compare it to the other stores in terms of user footprint.

• Operational Efficiency: Real-time location and geofencing data can be utilized to construct traffic heatmaps or path-movement maps that could then be used to optimize staffing levels in high-density hotspots or to help redirect traffic flow for venue attendees or retail customers to reduce space congestion.

• Workplace Optimization: Analytics partners can use contextual data from the network and combine it with access card readers or HVAC systems to provide deeper insights into how workplaces are being utilized so businesses can make more informed decisions around upsizing or downsizing their workplaces.

Most of these use cases can either be enabled through Central’s Presence Analytics solution or by integrating with our analytics partners through a rich API set, some of the popular APIs being presence, station, location and geofence. For more details on available APIs and their usage, refer to the Partner Integration section. APIs allow third-party applications to access and utilize the data for various purposes, such as custom dashboards, integration with other software, or the development of new applications that leverage analytics.

APs send information to CLE for every associated and unassociated client within their range. CLE uses that information to perform two main functions:

• Calculating locations of associated and unassociated clients.

• Storing contextual information in its database that can be exposed to third-party applications through APIs.

CLE provides many advantages including:

• Ease of Installation – Eliminates the need for on-site hardware and infrastructure.

• Fast updates - Cloud-driven platforms enable consistent feature updates.

• Redundancy and Disaster Recovery - Uninterrupted service availability with built-in redundancy and disaster recovery strategies.

• Unified Third-Party Integration - Cloud-centric location services provide a unified interface for integrating seamlessly with third-party applications through APIs.

Understanding CLE, ALE and Meridian

1.2 - Wi-Fi analytics solutions

Presence analytics

This solution is designed to help businesses and organizations gain insights into how people move within physical spaces, such as retail stores, airports, offices, and other locations. By leveraging data from Wi-Fi networks, presence analytics offers a wealth of information that helps retailers answer important questions and make informed decisions.

Presence analytics functions by analyzing over-the-air data that is captured by HPE Aruba Networking Access Points. When a Wi-Fi-enabled device (such as a smartphone or tablet) comes within range of the access point, the client device sends out probe requests to discover available networks. These probe requests can be captured by CLE for Presence Analytics.

To learn more about Presence Analytics including how to monitor and configure metrics and thresholds, refer to the Presence Analytics Central page.

Location analytics

By using a trilateration algorithm, the Central Location Engine utilizes data from the APs to precisely determine the client’s location on the floor plan, enabling detailed location analytics.

1.3 - 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.

1.4 - Design and deployment considerations

Network design

Some network design considerations are essential for a location-ready network deployment. The detection of a wireless device (client) by a minimum of three access points is required for the computation of the X and Y coordinates of the client. The client’s location is established based on the RSSI (signal strength) detected by access points, using the four strongest RSSI values on the same channel.

In general, having a good density and proper placement of APs that detect the clients increases the likelihood of more precise device location. To learn more about the accuracy, refer to the Accuracy section.

AP placement

​Most non-location-ready deployments are designed such that APs are placed in the inner spaces of the floor plan. APs are generally not placed on the perimeters or corners since their coverage cells would bleed outside the floor, which may not be necessary as the WLAN, in most cases, is not required to serve clients outside the floor boundaries.

In a location-ready network, APs are not only placed in the center spaces but also spread across the perimeters and corners of the floor. This helps in improving location accuracy as it increases the likelihood that a device at any coordinate on the floor is seen by more than three APs for trilateration at better signal strength.

Distance between the access points

Utilize the grid line functionality within Central to optimize the AP layout, ensuring consistent spacing in all directions. Maintaining a recommended 10-15-meter gap between APs is advised, allowing the grid lines to be configured accordingly.

Minimum RSSI and AP separation

The distance between APs can impact the location accuracy of a wireless client. Radio signals are subject to the inverse square law, which for this purpose means that every time the distance between the signal generator (client) and the signal receiver (AP) doubles, the received signal power, sometimes referred to as received signal strength indicator (RSSI), will be quartered. Once the received signal has diminished to a certain point, typically around -65 dBm received at the AP, the ability to determine a specific distance based on the signal has diminished to the point of uselessness. Too much distance between access points means that accurately locating client devices will be difficult or result in incorrect positioning.

For accurate trilateration of a client within an area, the recommendation is for APs to be placed so that at least three APs can hear the client at -65dBm or better. This will usually correlate to the APs being separated by 40-50 feet but placed no more than 60 feet apart.

Air monitors

Air Monitors are APs deployed in a mode specifically dedicated to the purpose of listening to the Wi-Fi environment, allowing for more data to be collected.

An access point should be spending as many cycles as possible to serve WLAN clients, and so the AP may capture data frame RSSI from associated clients, as both the AP and clients exchange data on the same channel. However, for the same AP to capture data frame RSSI from clients associated with other APs, the AP must go off-channel to listen on the same channel where the clients are exchanging data frames. For instance, if AP1 serves client X on channel 1, and AP2 serves client Y on channel 11, the probability of AP1 switching to channel 11 simultaneously while client Y transmits data is statistically low. An Air Monitor scans channels more aggressively than an AP, and has a higher likelihood of picking up data frame RSSI from both channels 1 and 11, contributing more data to location computations.

For a deployment that demands analytics concerning associated devices, the incorporation of a combination of APs and AMs (for example, one AM for every four to five APs) is advised. For additional information on setting an AP to monitor mode, refer to AOS10 documentation for AOS10 APs and Instant AP Radio Mode - Monitor for Instant APs.

Best practice summary

In summary, the best practices for an installation that provides the best location results are:

• Deploy the APs with a sufficient density for trilateration within the entirety of the coverage area.

• Make sure to deploy APs at the edges of the coverage area.

• Deploy access points meant to be used in Air Monitor mode, in the prescribed ratio.

  • Using Air Monitors is especially important for analytics around associated devices that don’t have a high usage pattern.

• When testing Central Location Services, use enough devices to get accurate results.

  • When testing with only three APs, the data collected will almost certainly not show the minimum 3 APs needed for trilateration; insufficient data causes the location algorithm to attempt locations based on the Single AP method.

  • Better test results will be obtained by using seven to eight APs, with one or two of those deployed as an Air Monitor.

Pre-requisites

Before deploying and testing Central Location Services, ensure that the following prerequisites have been met:

1. Central account: An active Central account with online access points; Central serves as the management platform for various network services, including Presence Analytics and Floor Plan Manager. For more details on getting started with Central, visit the Central onboarding and provisioning.

2. Upload a floor plan to Central: A floor plan of the area to be tracked must be uploaded to Central and scaled correctly. For more details, refer to the Central documentation on creating, importing, and modifying floor plans.

3. Place access points on the map: Position the APs on the uploaded floor plan in Central. This step is crucial for the system to calculate the location of connected wireless devices. Refer to the Central documentation for more details on placing APs on the floor plan.

4. Connect clients to the APs from the floor: Connect clients (devices like smartphones, laptops, etc.) to visualize the devices on the Central floor plan. Refer to the Central documentation for more details on creating a WLAN SSID. This allows CLE to track and analyze the client device’s location based on signal strength and other factors.

Correctly following these prerequisites should allow for contextual information for clients including tracking their locations.

1.5 - Partner integration

Central offers two types of APIs: Polling APIs for querying specific information and Publish/Subscribe APIs for near real-time updates. The Polling API provides a current snapshot of the network environment. Thereafter, any real-time updates in the network are learned through Publish/Subscribe APIs. Publish/Subscribe APIs are recommended for location updates.

Polling or REST APIs

Among the many Polling APIs supported by Central are the Location, Presence, Geofence and Station REST APIs. These are some of the most commonly utilized APIs by analytics applications, and some of them are elaborated below.

Location API

The Location REST API can be used to access near real-time data around device location, status, and identity within a specific campus, building and its various floors. Customers can securely access the REST API using their credentials and an API key. They can make requests to specific endpoints on the API to retrieve data. For example, to retrieve the location of a specific client, the endpoint would be - /visualrf_api/v1/client_location/{macaddr}.

For more information on how to access the REST API using Central refer to the REST API developer docs.

The output for this message type displays the following information:

Example response for location REST API GET https://example.com/visualrf_api/v1/client_location/{macaddr}

{  
  "location": {  
    "x": "185.55978",  
    "y": "35.71597",  
    "units": "FEET",  
    "error_level": 61,  
    "campus_id":
"201610193176__1b99400c-f5bd-4a17-9a1c-87da89941381",  
    "building_id":
"201610193176__f2267635-d1b5-4e33-be9b-2bf7dbd6f885",  
    "floor_id":
"201610193176__39295d71-fac8-4837-8a91-c1798b51a2ad",  
    "associated": true,  
    "device_mac": "ac:37:43:a9:ec:10"  
  }  
}

Presence API

Retail customers can leverage the REST API data to create relevant applications by utilizing the various endpoints provided for Presence Analytics.

Visitor status

Endpoint: GET https://example.com/presence/v3/visitor_status

• Utilize this endpoint to retrieve the number of connected and non-connected visitors within a selected time range.

• If needed, filter data by passing the tag_id to retrieve information for a specific tag/site.

• Applications can display real-time visitor status, helping staff manage crowd control and understand store occupancy.

{  
  "data": {  
    "visitor_status": [  
      {  
        "count": 0,  
        "status": "Connected"  
      },  
      {  
        "count": 0,  
        "status": "Not Connected"  
      },  
      {  
        "total_visitors": 0  
      }  
    ]  
  }  
}

Visit frequency

Endpoint: GET https://example.com/presence/v3/visit_frequency

• Use this endpoint to get details for loyal visitors, including the number of visits made by a customer at a specific site or customer level.

• Applications can provide insights into customer loyalty, enabling targeted marketing campaigns or loyalty programs.

{  
  "result": [  
    {  
      "bucket": "2-10",  
      "count": 7  
    }  
  ],  
  "status": "success",  
  "unique_visitor_count": 0  
}

Analytics trends for loyal visitors

Endpoint: GET https://example.com/presence/v3/analytics/trends/loyal_visitors

• Retrieves discrete (samples) values for each time interval from start time to stop time, for presence indicators ( passerby, visitor, draw rate, dwell time) at a site or customer level based on input. The time interval depends on what timeframe is selected and if the sample value is aggregated value for that time interval. If 1 day is selected, the interval is 1 hour and the sample is aggregated value for each one hour.

• Applications can visualize trends in customer behavior, allowing retailers to optimize store layouts and offerings.

[  
  {  
    “allowed_frequency”: [  
      [  
        “hourly”,  
        “daily”,  
        “weekly”  
      ]  
    ],  
    “fields”: [  
      [  
        “time”,  
        “loyal_visitors”,  
        “unique_visitors”  
      ]  
    ],  
    “samples”: [  
      [  
        [  
          [  
            1590949800000,  
            0,  
            0  
          ],  
          [  
            1590953400000,  
            0,  
            0  
          ],  
          [  
            1590957000000,  
            0,  
            0  
          ],  
          [  
            1590962400000,  
            1,  
            1  
          ]  
        ]  
      ]  
    ]  
  }  
]

Analytics trends for passerby visitors

Endpoint: GET https://example.com/presence/v3/analytics/trends/passerby_visitors

• Similar to the endpoint for loyal visitors, retrieve discrete values for presence indicators for passerby visitors.
• Applications can analyze passerby trends to understand foot traffic and improve store marketing strategies.

{  
  "datapoints": [  
    {  
      "allowed_frequency": [  
        "hourly"  
      ],  
      "customer_id": "123456789",  
      "category": "visitor",  
      "xunits": "dwelltime",  
      "yunits": "visitor_count",  
      "data": {  
        "count": 35,  
        "sample": [  
          [  
            1591243200000,  
            2  
          ],  
          [  
            1591246800000,  
            2  
          ],  
          [  
            1591250400000,  
            4  
          ]  
        ]  
      }  
    }  
  ]  
}

Aggregate values for list of sites

Endpoint: GET https://example.com/presence/v3/insights/sites/aggregates

• Obtain aggregated/average values for various categories (passerby, visits, draw rate, dwell time, loyal visitors, visitors, connected visitors) at a site or customer level.

• Applications can present a comprehensive overview of key metrics, aiding in strategic decision-making for each site.

{  
  "category": "all",  
  "data": [  
    {  
      "drawrate_count": 76,  
      "dwelltime_count": 67,  
      "loyal_visitors": 45,  
      "new_visitors": 35,  
      "passerby_count": 35,  
      "site_id": 65,  
      "site_name": "c2cLab",  
      "store_id": 65,  
      "store_name": "c2cLab",  
      "total_connected": 55,  
      "visitor_count": 45,  
      "visits": 65  
    }  
  ],  
  "limit": 10,  
  "offset": 0,  
  "sort": "asc",  
  "total": 10  
}

Publish-subscribe or streaming APIs

These are also called “Streaming APIs” and serve as the primary tool for subscribing to and receiving real-time updates from Central. They operate on the publish-subscribe model, ensuring that any message published on a specific topic is promptly distributed to all subscribers interested in that topic. These types of APIs find versatile applications in event-driven architecture and real-time monitoring.

Central adopts the Web Socket Secure (WSS) protocol for the Streaming API. In this setup, the publisher is represented by Central, functioning as the WebSocket Server, while the subscriber is the WebSocket client application designed and used by end-point applications.

Streaming APIs are categorized into different topics, some of the most popular ones being the Presence, Location and Geofence topics.

Presence topic

The Presence topic contains details of all associated and unassociated clients detected by Access Points. Event updates for each device are sent once every 60 seconds.

Below are descriptions of crucial parameters contained within the Presence topic that help enable some of the Presence Analytics use cases:

• Proximity—The pa_proximity_event reports which AP hears the client at the strongest RSSI, indicating which AP is closest to the client/station, and this event will be provided for each device once every 60 seconds.

• RSSI—The pa_rssi_event contains a list of RSSI information of all unassociated and associated clients/stations, detected by an AP device, and this event will be provided for each device once every 60 seconds.

The streaming API delivers data updates containing the following information for each client device:

Example of an event from the Presence topic:

sta_eth_mac {
addr: "B827EBD9CEB2"
}
radio_mac {
addr: "B45D5062FCF0"
}
rssi_val: -66
noise_floor: 92
associated: false
device_id: "CNCFJSS4WF"
ap_eth_mac {
addr: "B45D50CE2FCE"
}

Location topic

A location event is generated when the location of a client (station) is computed using RSSI values periodically reported by the Access Points. The event message includes the coordinates of the client on the Floorplan Manager and geofence notification, which contains information on when a device enters or leaves a geofence region (if Geofence is enabled). Therefore, updating a floor plan with AP location mapping is a prerequisite for the Location Streaming Events.

The output for this message type displays the following information:

Example of the location message:

 sta_location_x: 333.671569824
 sta_location_y: 220.563110352
 error_level: 92
 loc_algorithm: ALGORITHM_TRIANGULATION
 unit: FEET
 sta_eth_mac {
 addr: "320323340262p"
 }
 campus_id_string: "77d249ac35b548cab35fb48a8a1e7dd5__default"
 building_id_string: "77d249ac35b548cab35fb48a8a1e7dd5__1"
 floor_id_string:
 "77d249ac35b548cab35fb48a8a1e7dd5__ee80edb6-0476-4c9e-93a4-d79acd2c6f7a"
 target_type: TARGET_TYPE_STATION
 associated: false

Geofence notify

The Geofence Notify message returns information when a device enters or leaves a geofence region. Geofence Notify events are only available under the Location topic on Central.

The output for this message type displays the following information:

Decode data for customer location  
{'customer_id': '416bc832bc6111ed961e6aa14dbf31f1',  
'data': {'associated': False,  
          'dwell_time': 172,  
          'geofence_event': 'ZONE_OUT',  
          'geofence_id':
'NDE2YmM4MzJiYzYxMTFlZDk2MWU2YWExNGRiZjMxZjFfXzU2OTE2ZGUxLTg0MzgtNDNhYi04NTZhLTNkY2QwNDkwNTRjOQ==',  
          'geofence_name':
'416bc832bc6111ed961e6aa14dbf31f1__Zone-1',  
          'sta_eth_mac': {'addr': 'IEwDTSRj'}},  
'msp_ip': '',  
'timestamp': 1699915771139221492,  
'topic': 'location'}

Useful resources

• Overview of Foundation and Advanced Licenses

• REST API- Get Started with REST API for Configuration, on-demand polling, and monitoring data via HTTP Requests.

• Streaming API- Get Started with Streaming API to subscribe to selected topics, get statistics, and state changes over Secure WebSocket (WSS).

• Webhook - Get Started with Webhooks to integrate external applications and implement actions based on real-time alerts.

1.6 - Troubleshooting

Listed below are some verifications that can be performed while testing the Central Location Services.

Clients not visible on the floor plan

• Ensure that the Clients field is selected.

Navigate to Central Global → Sites → choose the desired site for viewing → click on the displayed view.

• Use the REST API to further verify client information. For more details on REST APIs, refer to the Polling API section.

• Ensure that Access Point is sending RSSI messages to Central. Use the command show running-config | include rssi.

  AP-3-Loc# show running-config | include rssi
  report-rssi-to-central unassociated-and-associated-clients
  

• Ensure that the message length exceeds a couple of hundred bytes; otherwise, the IAP is transmitting RSSI for its BSSIDs. Use the command show log ap-debug | include rssi.

  AP-3-Loc# show log ap-debug | include rssi
  Nov 6 15:23:11 awc[6232]: [cloud] wsc: insert queue a message to
  websocket server, topic iap.rssi, msg_len=10714.
  
  Nov 6 15:24:10 awc[6232]: [cloud] wsc: receive a post request from
  application, topic rssi, data len 13123, ce_ctx , len 0.
  
  Nov 6 15:24:10 awc[6232]: [cloud] wsc: insert queue a message to
  websocket server, topic iap.rssi, msg_len=13136.
  
  Nov 6 15:25:10 awc[6232]: [cloud] wsc: receive a post request from
  application, topic rssi, data len 10629, ce_ctx , len 0.
  
  Nov 6 15:25:10 awc[6232]: [cloud] wsc: insert queue a message to
  websocket server, topic iap.rssi,
  

• Make sure that the AP has subscribed to RSSI reporting with Central. Use the command show ap debug msg-subscription.

  AP-3-Loc# show ap debug msg-subscription
  Subscription modules List
  -------------------------
  message type Central ALE
  ------------ ------- ---
  state FALSE FALSE
  stat FALSE FALSE
  rssi TRUE FALSE
  clarity TRUE FALSE
  apprf TRUE FALSE
  trap FALSE FALSE
  speedtest FALSE FALSE
  telemetry TRUE FALSE
  

Clients placed on top of APs

When this scenario is encountered there is a high likelihood that only one or two APs are present on the floor. This is expected behavior for this situation and the recommendation is to consider optimizing AP placement. A minimum of three APs is required for trilateration to work effectively. For more details on the AP placement, refer to the Network Design section.

2 - Open Locate deployment guide

HPE Aruba Networking Open Locate is an initiative designed to standardize and enhance indoor location services across enterprise environments, aiming to improve the accuracy, flexibility, and interoperability of location-based solutions by leveraging multiple positioning technologies. To ensure seamless integration across various platforms, Open Locate also focuses on enabling the HPE Aruba Networking Access Points to broadcast their location, also known as location coordination information (LCI), through APIs and standardized protocols, including Wi-Fi and Bluetooth Low Energy (BLE). This allows third-party applications and ecosystem partners to leverage real-time location data more effectively, driving innovation in asset tracking, indoor positioning, and other location-based services.

The current landscape of Wi-Fi location solutions requires manual placement of APs on a digitized floor plan for a location-aware infrastructure.  This can be time-consuming, resource-intensive, and prone to user error. Open Locate and HPE Aruba Networking Central delivers automatic placement of APs on a floor plan, empowering workplace owners to eliminate operational bottlenecks and enhancing their overall efficiency.

A key component of Wi-Fi-based locationing using the Fine Timing Measurement (802.11mc) protocol, which utilizes time-of-flight techniques to measure distances between access points and devices and enhance location accuracy. Support for FTM was introduced with the Wi-Fi 6 family of APs and is available with all AP models introduced since then. To explore use cases and understand how APs can auto-locate themselves to enable highly accurate indoor positioning using Open Locate, watch Delivering Accurate Indoor Location Services at Scale.

To support automatic AP placement the Central floorplan manager facilitates the seamless placement of APs on the floor plan. The floorplan manager forms the foundational layer by anchoring a digital floor plan to geo-referenced map services thereby automatically scaling the floor plan based on latitude and longitude coordinates.

2.1 - Overview

High-level design

When Fine Time Measurement (FTM) is enabled in a site with HPE Aruba Networking Access Points, the following process takes place -

1. The APs engage in the exchange of FTM information.

2. The APs transmit FTM telemetry to HPE Aruba Networking Central.

3. Central performs detailed calculations to determine the location coordination information (LCI).

4. Central pushes the calculated LCI to the APs.

5. If the Advertise Location feature is enabled, APs can broadcast this information, allowing client devices to perform their own location calculations.

Licensing

Open Locate is available to New Central customers using AOS-10 based APs with Foundation and/or Advanced AP licenses. Separate licenses are not required for Open Locate.

For more information on subscription licenses, refer to the licensing documentation.

2.2 - Getting started

Prerequisites

To successfully auto-place APs on the floor plan, ensure that the following prerequisite categories are met:

Hardware

• AP auto-placement is supported for 500, 600 & 700 series APs.

• A minimum of five APs that support FTM functionality are required to facilitate the auto-locate process, utilizing four anchor APs and requiring at least one additional AP for effective auto-placement.

• The usage of the 6 GHz band for AP-to-AP and STA-to-AP ranging is currently only supported on the AP-605H & AP-615.

Software

• Support for FTM is introduced with AOS-10 version 10.5.

• Support for FTM Monitor mode is introduced with AOS-10 version 10.7.1.

• Minimum AOS-10 version required for auto placing 700 series APs is 10.7.2.

Configuration

• Ensure that the APs are provisioned and belong to the same AP group and site on HPE Aruba Networking Central.

• Geo-Locate the floor on the map must be selected when creating a floorplan. For more details on how to scale the floor, refer to Creating Initial Floor and Building.

Operational

• Confirm that APs can detect neighboring APs to initiate FTM exchanges, a crucial step for accurate auto-locate functionality. For more details on verifying the FTM telemetry, refer to AP Testing and Verification.

• APs must operate for at least 24 hours to compute auto-locate data efficiently. During this time, APs scan the RF environment, send FTM requests to each other, and transmit telemetry data to Central.

• During the Open Locate provisioning phase, all APs must be able to operate on an 80 MHz bandwidth channel; currently, the AP-to-AP and STA-to-AP FTM data needed for location determination is most efficiently obtained using 80 MHz channels.

  • For environments where using 80 MHz channels in production is not feasible, FTM Monitor mode can be used.

Configuration steps

Open Locate operation requires two levels of configuration.

1. Enabling FTM functionality in Classic Central
2. Initiating the auto-locate process in New Central

Enabling FTM

Enable the FTM scan and FTM responder modes in Classic Central.

• FTM scan: To enable the FTM scan, follow the steps at Configuring Automatic Placement of an AP.

Checking the Enable Automatic Placement box activates FTM scanning, and configures the APs to handle FTM tasks 25% of the time reserved for off band channel scanning, that is only valid when no clients are connected and hence it takes up to 24-48 hours to collect FTM data if not using FTM Monitor mode.

• FTM Responder mode: To enable the FTM-responder mode, follow the steps at Configuring Advanced Settings for a WLAN SSID Profile.

Checking the Fine Timing Measurement (802.11 mc) Responder Mode enables FTM capability on the APs and enables FTM communication between APs and stations like phones or laptops.

• Additionally, set 80 MHz channel width: If the deployment does not allow usage of 80 MHz channels, fast forward to FTM Monitor mode configuration.

Otherwise, set the channel bandwidth to 80 MHz by following the steps at Configuring Radio Parameters.

Set the Minimum and Maximum bandwidth to 80 MHz. A wider bandwidth improves FTM exchanges and reduces multipath effects, leading to better accuracy in location-based applications.

Initiating auto locate

The floorplan manager serves as the starting point for initiating location-aware services within New Central. In this dashboard, site properties, including buildings and floors, can be created, and floor plans can be uploaded and configured. After creating the floors, devices can be assigned to the floors so the system can begin the process of auto-placing the APs. To access and create the floorplan, refer to New Central Floorplan Manager techdocs.

Once the floorplan is ready, we need to assign devices to the floorplan before we auto place the APs.

Assigning devices to floorplans

To assign devices to specific floorplans, complete the steps at Assigning Devices to Floorplans in Floorplan Manager.

Automatic AP deployment

To start placing APs automatically on the floorplan, follow the steps at Automatic AP Placement.

FTM monitor mode

FTM Monitor mode activates a special monitor mode on the 5 GHz band. While in FTM Monitor mode, the APs on the specified floor sequentially scan each 80 MHz channel within the 5GHz band to collect FTM ranging data. Once the required inter-AP ranging information is gathered, the APs are returned to their original bandwidth settings. This approach significantly reduces the time required to collect accurate location data, enhancing overall system efficiency in environments where continuous 80 MHz operation isn’t feasible.

Prerequisites for utilizing FTM Monitor mode:

• FTM Monitor mode currently only operates on the 5 GHz radio band. Support for 6 GHz radio is on the roadmap.

• APs on the given floor-id must be ‘ftm-monitor’ capable, running AOS 10.7.1 or greater.

• APs must be configured to support FTM and assigned to a floor in New Central.

• APs on the given floor-id must be configured in the same regulatory domain (ie. configured with the same country code).

• APs on the given floor must be synchronized with the same NTP server.

Configuration

Endpoint: POST https://example-central-server.com/network-monitoring/v1alpha1/sitemaps/{site-id}/floors/{floor-id}/ftm-scans/start

Parameters:

• site-id: Site ID where the FTM scan is required.
• floor-id: Starts an FTM scan for the given floor-id.

The site-id and floor-id can be found by navigating to the floor plan in new Central and inspecting the URL.

Example response of “Start FTM Monitor mode” POST API:

{
    "scanStartTime": "2024-12-11T22:17:33.574Z",
    "id": "2174534000",
    "result": "SUCCESS",
    "errorMessage": null
}

Description of the fields in the response:

The result returned will be one of the following:

• SUCCESS - Scan was successfully created and is now PENDING
• FTM_SCAN_ALREADY_ACTIVE - Scan already active on the given floor-id. Only one scan is allowed per floor at any given time. Scan cannot be started.
• NOT_ENOUGH_APS - There were not enough ftm-monitor enabled APs on the given floor-id. Scan cannot be started.
• REGULATORY_DOMAIN_MISMATCH - Not all APs are configured with the same country code. Scan cannot be started.
• NO_VALID_CHANNELS - Based on the user configured country code and channel selections, there are no available channels to run the FTM scan on. Scan cannot be started.
• ERROR - There was an error starting the scan, see errorMessage for details of the error.

Note down the id provided in the response to check the status using the next API call.

Verification

The scan typically takes between 15 to 30 minutes to complete. During this process, the APs sequentially scan each 80 MHz channel within the 5GHz band to collect FTM ranging data. Throughout the scan, all APs operate in monitor mode.

Use the following REST API to verify the scan process.

Endpoint: GET https://example-central-server.com/network-monitoring/v1alpha1/sitemaps/{site-id}/floors/{floor-id}/ftm-scans/{ftm-scan-id}

Parameters:

• site-id: Site ID where the FTM scan is required.
• floor-id: Starts an FTM scan for the given floor-id.
• ftm-scan-id: Retrieved from the ftm-scan-start API.

Example response of “Status of the FTM Monitor mode” GET API:

{
    "total": 1,
    "next": null,
    "items": [
        {
            "dwellTimeMillis": 90000,
            "updatedAt": "2024-12-11T22:12:32.682Z",
            "serialNumbers": [
                "CNMSKY0000",
                "CNMSKY0000",
                "PHPNKY0000",
                "PHPNKY0000",
                "PHPNKY0000",
                "PHPNKYJ000",
                "PHPNKYJ000",
                "PHPNKYJ000",
                "PHPNKYJ000"
            ],
            "errorMessage": null,
            "scannedChannels": [
                {
                    "primaryChannelList": [
                        36,
                        52,
                        100,
                        116,
                        132,
                        149
                    ],
                    "bandwidth": "CHANNEL_BW_80MHZ",
                    "band": "RADIO_BAND_5GHZ"
                }
            ],
            "estimatedCompletionTime": "2024-12-11T22:32:33.574Z",
            "floorId": "9f8ba9ee-c866-4654-82b1-xxxxxx",
            "siteId": "791830000",
            "status": "SCHEDULED",
            "scanStartTime": "2024-12-11T22:17:33.574Z",
            "id": "2174534000",
            "type": "FTM_SCAN",
            "createdAt": "2024-12-11T22:12:32.682Z"
        }
    ],
    "count": 1
}

Descriptions of the fields in the response:

The status returned will be one of the following:

• Pending: Scan request was accepted and awaiting scheduling by the system.
• Aborted: Scan request was delayed and could not be scheduled before the calculated start time.
• Scheduled: Scan request has been scheduled by the system and is awaiting the scan start time.
• Scanning: Scan is currently running (wifi network connectivity is currently unavailable).
• Complete: Scan has completed.

Once the FTM Monitor mode scan has completed, proceed with initiating the auto locate process.

2.3 - AP testing and verification

If there are telemetry or other FTM data issues, navigate to the AP and execute specific show commands to pinpoint the problem.

Verifying AP configuration

To verify that the configuration has been successfully pushed to the AP, run the command show running-config | include FTM. Ensure that both ftm-scan-enable and ftm-responder-enable are present, indicating that FTM is enabled and capable of facilitating FTM exchanges between APs.

Example:

AP-AOS10# show running-config | include ftm
ftm-scan-enable
ftm-responder-enable

Additionally, you can check if the GPS setting is enabled.

AP-AOS10# show running-config
gps
 state enable

Analyzing FTM details

To examine FTM data, use the command show ap range scanning-results. This command provides a display of all successful FTM measurements between peer APs within the last 20 minutes. The output includes the following information, which proves useful for debugging the channel:

• Average RTT: Presented in nanoseconds, to be later converted into meters.

• Average RSSI: If the RSSI increments, it indicates that the AP is farther away, resulting in higher RTT.

• Average STD: The standard deviation can indicate the quality of the results.

• Channel: The AP predominantly selects an 80 MHz channel, which is optimal for accurate FTM. Choosing 80 MHz provides more resolution and better accuracy, making it the recommended option for improved results.

Example:

AP-AOS10# show ap range scanning-results
Ranging results
---------------
Peer-bssid         Average RTT  Average rssi (dbm)  Average std (100ps)  Channel  Number of valid RTTs  Number of FTMs  Antenna  RTTs/Init-mask/Resp-mask                                                                                                         Time Stamp
----------         -----------  ------------------  -------------------  -------  --------------------  --------------  -------  ------------------------                                                                                                         ----------
74:9e:75:41:17:30  69           60                  10                   36E      15                    16              0        69,0,0 69,0,0 69,0,0 69,0,0 68,0,0 66,0,0 69,0,0 69,0,0 70,0,0 70,0,0 70,0,0 70,0,0 69,0,0 70,0,0 68,0,0                         2024-03-21 11:47:01
74:9e:75:41:4f:70  114          64                  4                    36E      16                    16              0        114,0,0 113,0,0 113,0,0 114,0,0 114,0,0 114,0,0 114,0,0 113,0,0 113,0,0 114,0,0 114,0,0 114,0,0 114,0,0 114,0,0 113,0,0 114,0,0  2024-03-21 11:47:15
74:9e:75:41:7c:70  137          61                  53                   36E      15                    16              0        127,0,0 141,0,0 141,0,0 138,0,0 139,0,0 140,0,0 139,0,0 126,0,0 141,0,0 140,0,0 126,0,0 140,0,0 141,0,0 140,0,0 138,0,0          2024-03-21 11:47:30
00:4e:35:e9:19:50  146          69                  14                   36E      13                    16              0        147,0,0 145,0,0 144,0,0 144,0,0 145,0,0 144,0,0 144,0,0 146,0,0 147,0,0 147,0,0 147,0,0 147,0,0 147,0,0                          2024-03-21 11:48:13
00:4e:35:e9:12:d0  143          64                  7                    36E      15                    16              0        142,0,0 143,0,0 142,0,0 142,0,0 144,0,0 143,0,0 144,0,0 142,0,0 142,0,0 144,0,0 143,0,0 143,0,0 144,0,0 142,0,0 142,0,0          2024-03-21 11:48:27
74:9e:75:41:0e:60  147          71                  3                    36E      14                    16              0        147,0,0 147,0,0 147,0,0 147,0,0 147,0,0 147,0,0 147,0,0 146,0,0 147,0,0 147,0,0 147,0,0 146,0,0 147,0,0 148,0,0                  2024-03-21 11:48:39
74:9e:75:41:4f:70  115          66                  3                    36E      16                    16              0        114,0,0 114,0,0 115,0,0 114,0,0 115,0,0 115,0,0 115,0,0 114,0,0 115,0,0 115,0,0 114,0,0 115,0,0 115,0,0 114,0,0 113,0,0 115,0,0  2024-03-21 11:48:56
74:9e:75:41:7c:70  138          62                  3                    36E      16                    16              0        138,0,0 138,0,0 138,0,0 138,0,0 138,0,0 138,0,0 138,0,0 137,0,0 138,0,0 137,0,0 137,0,0 137,0,0 137,0,0 138,0,0 138,0,0 138,0,0  2024-03-21 11:49:11
Total:8
About 20 mins to age out

Reading FTM summary

Run the command show ap range scanning-summary. This command can be used for debugging purposes, it allows you to determine if an AP is rejecting FTM data, providing insights into potential issues within the setup. For instance, if the Fail Scan counter continues to rise or matches the Scan counter, it indicates that the AP is unable to reach or communicate with the neighboring AP indicated by the Peer-bssid.

Example:

AP-AOS10# show ap range scanning-summary

Ranging History
---------------
Peer-bssid         Total Scan  Fail Scan
----------         ----------  ---------
74:9e:75:41:3d:d0  4877        4800
74:9e:75:41:17:30  9119        637
00:4e:35:e9:12:d0  8930        82
74:9e:75:41:27:20  6467        3289
74:9e:75:41:40:70  5524        4231
74:9e:75:41:4f:70  8838        919
00:4e:35:e9:19:50  8957        798
74:9e:75:41:7c:70  9068        687
74:9e:75:41:0e:60  8522        123
d0:d3:e0:ef:61:50  4914        4844
Total:10
AP-AOS10#

Analyzing FTM history

Use the command show ap range scanning-history, which provides the following fields:

• Peer-bssid: BSSID of neighboring APs.

• Last scan result, with possible values:

  • 0: Success
  • 1: AP driver is engaged in other tasks (busy), which occurs as the AP changes channels and requires time for detection.
  • 2: Unreachable target BSSID, indicating a lack of connection with the peer AP.

It is normal to observe occasional failures and achieving a 100% success rate may not always be possible.

Example:

AP-AOS10# show ap range scanning-history 

Ranging History
---------------
Peer-bssid         Last Scan Result  Time Stamp
----------         ----------------  ----------
00:4e:35:e9:12:d0  0                 2023-12-17 18:28:18
74:9e:75:41:27:20  0                 2023-12-17 18:28:51
74:9e:75:41:3d:d0  0                 2023-12-17 18:29:29
d0:d3:e0:ef:61:50  0                 2023-12-17 18:30:02
74:9e:75:41:27:20  0                 2023-12-17 18:30:33
74:9e:75:41:3d:d0  0                 2023-12-17 18:31:06
d0:d3:e0:ef:61:50  0                 2023-12-17 18:31:41
74:9e:75:41:0e:60  2                 2023-12-17 18:32:08
74:9e:75:41:0e:60  2                 2023-12-17 18:32:22
74:9e:75:41:0e:60  0                 2023-12-17 18:32:35
d0:d3:e0:ef:61:50  0                 2023-12-17 18:49:10
Total:11
For result, 0: success; 1: fail because of driver busy; 2: unreachable target BSSID

Verifying cloud telemetry

Activate the debug log by executing the command debug-log-to-cloud. Subsequently, wait for 5 minutes, as the AP sends the telemetry to the cloud every 5 minutes. Then use the command show log stats-to-cloud ftmscan to confirm that the AP is indeed sending the FTM telemetry. This command enables you to verify details such as the BSSIDs, radios and channels of peer APs, and whether the AP is actively engaging in FTM exchanges, providing additional diagnostic information.

Example:

AP-AOS10# debug-log-to-cloud

AP-AOS10# show log stats-to-cloud ftmscan

2023-12-17 19:07:07 T PeerFTMReport Stats: peer_mac[74:9e:75:41:3d:d0], radio_mac[74:9e:75:41:40:70], channel[124], band[1], bandwidth[1], ftm_avg_rssi[49]
2023-12-17 19:07:07 ... ftm_avg_rtt[73], ftm_min_rtt[70], ftm_max_rtt[74], ftm_std_dev[13], ftm_num_samples[16], ftm_valid_samples[16], chain_mask[0]
2023-12-17 19:07:07 ... time_stamp[1702867028]
2023-12-17 19:07:07 T FTMMeasurement Stats: ftm_rtt[70], init_mask[0], resp_mask[0]
2023-12-17 19:07:07 T FTMMeasurement Stats: ftm_rtt[74], init_mask[0], resp_mask[0]
2023-12-17 19:07:07 T FTMMeasurement Stats: ftm_rtt[74], init_mask[0], resp_mask[0]
2023-12-17 19:07:07 T FTMMeasurement Stats: ftm_rtt[74], init_mask[0], resp_mask[0]
2023-12-17 19:07:07 T PeerFTMReport Stats: peer_mac[00:4e:35:e9:12:d0], radio_mac[74:9e:75:41:40:70], channel[44], band[1], bandwidth[1], ftm_avg_rssi[79]
2023-12-17 19:07:07 ... ftm_avg_rtt[327], ftm_min_rtt[323], ftm_max_rtt[330], ftm_std_dev[21], ftm_num_samples[16], ftm_valid_samples[16], chain_mask[0]
2023-12-17 19:07:07 ... time_stamp[1702867066]
2023-12-17 19:07:07 T FTMMeasurement Stats: ftm_rtt[323], init_mask[0], resp_mask[0]
2023-12-17 19:07:07 T FTMMeasurement Stats: ftm_rtt[330], init_mask[0], resp_mask[0]
2023-12-17 19:07:07 T FTMMeasurement Stats: ftm_rtt[326], init_mask[0], resp_mask[0]
2023-12-17 19:07:07 T FTMMeasurement Stats: ftm_rtt[328], init_mask[0], resp_mask[0]

Verifying GPS telemetry

Confirm the availability of GPS telemetry for the 600 series APs by using the command show ap gps summary. This command displays GPS information on the AP, allowing you to assess whether the AP is obtaining GPS latitude and longitude values. In cases where the AP is situated indoors and may face challenges in acquiring GPS location, checking this information becomes particularly useful for the APs.

Example:

AP-AOS10# sh ap gps summary

GPS Information
---------------
Type    Position (Latitude,Longitude)  Altitude
----    ------------------------------  --------
$GNGGA  37.385870, -121.987549          34.2 M
$GNRMC  37.385870, -121.987549          N/A
$GNGLL  37.385870, -121.987549          N/A

GPS Configuration
------------------
Current Dynamic Model
---------------------
stationary
AP-AOS10#

If you do not observe any FTM or GPS data, ensure that the AP can detect neighboring APs by executing the command show ap monitor ap-list. This command provides a list of AP neighbors and indicates whether the AP is FTM capable or not in the FTM support column at the right most side.

Additionally, validate whether the AP is scanning different channels by using the command show ap arm scan-times.

Example:

AP-AOS10# show ap monitor ap-list

Monitored AP Table
------------------
bssid                 essid                        band/chan/ch-width/ht-type  ap-type                transition-type        confirmed  dos      dt/mt            ut/it    encr               nstas  avg-snr  curr-snr  avg-rssi  curr-rssi  wmacs  ibss  cl-delay  pathloss  bss-color  partial bss color  bss color disabled  FTM support  snr/rssi-age  snr/rssi-report-age 
-----                 -----                        --------------------------  -------                ---------------        ---------  ---      -----            -----    ----               -----  -------  --------  --------  ---------  -----  ----  --------  --------  ---------  -----------------  ------------------  -----------  ------------  -------------------  

74:9e:75:41:0e:60     Open-Locate-Network              5GHz/36E/80MHz/HE           valid                  valid                  no         disable  1280967/1280967  10/9    wpa2-psk-aes    0      25       25        70        70         0      no    0         0         21         false              false               yes          9             2                                       
74:9e:75:41:40:70     Open-Locate-Network              5GHz/36E/80MHz/HE           valid                  valid                  yes        disable  1280964/1280964  7/6     wpa2-psk-aes    0      12       12        82        83         0      no    256       96        25         false              false               yes          6             2                    
00:4e:35:e9:19:50     Open-Locate-Network              5GHz/36E/80MHz/HE           valid                  valid                  yes        disable  1280964/1280964  7/6     wpa2-psk-aes    0      34       34        60        61         0      no    256       76        37         false              false               yes          6             2                    
74:9e:75:41:27:20     Open-Locate-Network              5GHz/36E/80MHz/HE           valid                  valid                  yes        disable  1280964/1280964  7/6     wpa2-psk-aes    0      31       31        63        64         0      no    256       75        3          false              false               yes          6             2                    
00:4e:35:e9:12:d0     Open-Locate-Network              5GHz/36E/80MHz/HE           valid                  valid                  yes        disable  1280964/1280964  2/1     wpa2-psk-aes    0      32       33        62        62         0      no    256       78        45         false              false               yes          1             2                                       
74:9e:75:41:3d:d0     Open-Locate-Network              5GHz/36E/80MHz/HE           valid                  valid                  yes        disable  1280952/1280952  7/6     wpa2-psk-aes    0      7        7         87        88         0      no    244       99        26         false              false               yes          6             2                  

Additionally, validate whether the AP is scanning different channels by using the command show ap arm scan-times.

AP-AOS10# sh ap arm scan-times

Channel Scan Time
-----------------
channel  band    assign-time(ms)  scans-attempted  scans-rejected  scans-deferred  dos-scans  flags         timer-tick
-------  ----    ---------------  ---------------  --------------  --------------  ---------  -----         ----------
34       5GHz    19580            178              0               0               0          DYp           2261483
36       5GHz    1102671440       3604             0               0               0          DVACLYFETSp   2265270
38       5GHz    182270           1657             0               0               0          DYp           2261857
40       5GHz    377630           3433             0               0               0          DVACUYBPTSJp  2264996
42       5GHz    0                543              1086            0               0          DYp           0
44       5GHz    404030           3673             0               0               0          DVACLYFBTSMp  2265003
46       5GHz    202620           1842             0               0               0          DAYp          2265025
112      5GHz    348370           3167             0               0               0          DACUYXSJp     2265117
116      5GHz    402270           3657             0               0               0          DACLYXSMp     2265126
120      5GHz    402050           3655             0               0               0          DACUYXSJp     2265129
124      5GHz    375320           3412             0               0               0          DACLYXSMp     2265178
128      5GHz    356400           3240             0               0               0          DACUYXSJp     2265182
132      5GHz    365860           3326             0               0               0          DACLYXSMp     2265192
136      5GHz    345840           3144             0               0               0          DACUYXSJp     2265197
140      5GHz    317350           2885             0               0               0          DACLYXSMp     2265210
144      5GHz    345840           3144             0               0               0          DACUYXSp      2265238
149      5GHz    396110           3601             0               0               0          DACLYSp       2265222
153      5GHz    399520           3632             0               0               0          DACUYSJp      2265232
Channel Flags:
    D: All-Reg-Domain Channel,                C: Reg-Domain Channel,                        A: Activity Present,                      Z: Rare Channel
    V: Valid,                                 T: Valid 20MHZ Channel,                       F: Valid 40MHz Channel,                   P: Valid 40MHZ Channel Pair
    E: Valid 80/80+80MHz Channel (First 20M), B: Belongs to valid 80/80+80MHz channel,      G: Valid 160MHz Channel (First 20M),      Q: Belongs to valid 160MHz channel
    O: DOS Channel,                           K: DOS 40MHz Upper,                           H: DOS 40MHz Lower
    R: Radar detected in last 30 min,         X: DFS required,                              q: Zero Wait DFS,                         t: Zero Wait DFS Test Mode 
    N: Split Channel Scan                     J: Unconventional Scan 40MHz Above,           M: Unconventional Scan 40MHz Below,       L: Scan Secondary Above
    U: Scan Secondary Below,                  Y: Scan 80MHz,                                W: Scan 160MHz,                           b: Out-of-band scan Channel (valid only for dual 5GHz mode)
    p: Pooling Preference,                    S: Transmit Allowed,                          u: UTB filtered channel,                  x: Preferred Scan Channel (6GHz Only)

WIF Channel Scanning State. 
Current opmode: Default
-----------------------------------------------------
Scan mode  channel  current-scan-band  current-scan-channel  last-dos-channel  timer-milli-tick  next-scan-milli-tick (jitter)  scans (Tot:Rej:Eff(%):Last intvl(%))
---------  -------  -----------------  --------------------  ----------------  ----------------  -----------------------------  ------------------------------------
Moderate   36E      5GHz               161E                  0                 2265270000        2265273560 (166)               192086:2290:98:100
Moderate   6        2.4GHz             8+                    0                 2265270000        2265270560 (165)               449753:1:99:100
Default    69S      5GHz               0                     0                 2265270000        0 (0)                          1:0:100:0

UTB filter Info:
------------------
Type  Version A1  Version A2  Version A3  Version A4  Channel Spacing
----  ----------  ----------  ----------  ----------  ---------------
BAW   3           3           3           3           50 MHz

UTB filter results:
---------------------
Band selected  Last blocked channel
-------------  --------------------
6GHz           0

2.4 - Partner integration

Currently, New Central offers three REST APIs pertaining to Open Locate.

NBAPI for device locations

Endpoint: GET https://example.com/network-monitoring/v1alpha1/devices/with-location?

Parameter: filter=siteId eq ‘012931’

• This endpoint provides a list of devices with available location data, either in (x/y) coordinates or latitude/longitude or both. Use this endpoint to obtain the count of devices with longitude and latitude values for a given site.

• The filter requires at least the siteId parameter. Additionally, you can use floorId and buildingId as supported fields for more specific filtering.

• Using this endpoint, you can easily fetch a list of devices with precise location information, such as latitude and longitude, associated with a specific site. By specifying the site_id, you can focus on devices within a particular building or floor, streamlining your monitoring efforts and enhancing facility management.

{
    "data": {
        "listConsolidatedDeviceLocationsNBAPI": {
            "deviceLocationSummary": {
                "deviceLocations": [
                    {
                        "id": "CNXXXXXXXX",
                        "type": "ACCESS_POINT",
                        "createdAt": "2024-04-16T17:24:44.055Z",
                        "siteId": "791852196",
                        "floorId": "adbbb348-3c3f-4043-b10c-c7a01522c57f",
                        "buildingId": "8270en8z2xiwsljdkqlwi931ue",
                        "tenantId": "iwpmdowier03qrjasdklweifqiwdjw",
                        "ipv4": "x.x.x.x",
                        "ipv6": "",
                        "mac": "AA:BB:CC:DD:EE:FF",
                        "model": "AP-535",
                        "deployment": "Standalone",
                        "status": "ONLINE",
                        "consolidatedLocation": {
                            "source": "ADMIN_SPECIFIED",
                            "timestamp": "2024-04-24T16:35:09.087Z",
                            "cartesianCoordinates": {
                                "unit": "METERS",
                                "x_position": 4.133599281311035,
                                "y_position": 53.278629302978516
                            },
                            "center": {
                                "longitude": -121.98750299786495,
                                "latitude": 37.385833803552615
                            },
                            "lciUncertainty": null,
                            "altitude": null
                        }
                    }
                  ],
                "count": 1,
                "total": 1,
                "next": null
            }
        }
    }
}  

Retrieve data for all devices with no location on the mentioned site

Endpoint: GET https://example.com/network-monitoring/v1alpha1/devices/without-location?

Parameter: filter=siteId eq ‘012931’

• Utilize this endpoint to retrieve a list of devices lacking location data for a specified site.

• The filter requires at least the siteId parameter. Additionally, you can use floorId and buildingId as supported fields for more specific filtering.

• This endpoint is particularly useful for users troubleshooting issues related to devices without location information on a given site.

{
    "data": {
        "listConsolidatedDeviceLocationsNBAPI": {
            "deviceLocationSummary": {
                "deviceLocations": [
                    {
                        "id": "CNXXXXXXX",
                        "type": "GATEWAY",
                        "createdAt": "2024-04-19T20:27:53.566Z",
                        "siteId": "791852196",
                        "floorId": null,
                        "buildingId": null,
                        "tenantId": "416bc832bc6111ed961e6aa14dbf31f1",
                        "ipv4": "172.30.32.21",
                        "ipv6": "",
                        "mac": "AA:BB:CC:DD:EE:FF",
                        "model": "A7008",
                        "deployment": "Cluster",
                        "status": "ONLINE",
                        "consolidatedLocation": null
                    }
                  ],
                "count": 1,
                "total": 1,
                "next": null
            }
        }
    }
}  

Retrieve data for a particular device using serial number

Endpoint: GET https://cnx-apigw-internal2.central.arubanetworks.com/network-monitoring/v1alpha1/devices/<SERIAL>/location?siteId=<siteId>

• Utilize this endpoint to retrieve data for a particular device.

• This endpoint is particularly useful for users troubleshooting issues related to devices without location information on a given site.

{
    "data": {
        "getDeviceLocationDetails": {
            "id": "CNXXXXXXX",
            "type": "ACCESS_POINT",
            "createdAt": "2024-04-28T16:06:15.403Z",
            "siteId": "791852196",
            "floorId": "adbbb348-3c3f-4043-b10c-c7a01522c57f",
            "buildingId": "7695ba72-8663-474d-8979-bb567e9cf83d",
            "tenantId": "416bc832bc6111ed961e6aa14dbf31f1",
            "ipv4": "10.1.1.1",
            "ipv6": "",
            "mac": "AA:BB:CC:DD:EE:FF",
            "model": "AP-635",
            "deployment": "Standalone",
            "status": "ONLINE",
            "gpsLocation": null,
            "autoPlacedLocation": null,
            "adminSpecifiedLocation": {
                "source": "ADMIN_SPECIFIED",
                "timestamp": "2024-04-24T16:35:09.087Z",
                "cartesianCoordinates": {
                    "unit": "METERS",
                    "x_position": 4.133599281311035,
                    "y_position": 53.278629302978516
                },
                "center": {
                    "longitude": -121.98750299786495,
                    "latitude": 37.385833803552615
                },
                "lciUncertainty": null,
                "altitude": null
            },
            "consolidatedLocation": {
                "source": "ADMIN_SPECIFIED",
                "timestamp": "2024-04-24T16:35:09.087Z",
                "cartesianCoordinates": {
                    "unit": "METERS",
                    "x_position": 4.133599281311035,
                    "y_position": 53.278629302978516
                },
                "center": {
                    "longitude": -121.98750299786495,
                    "latitude": 37.385833803552615
                },
                "lciUncertainty": null,
                "altitude": null
            }
        }
    }
}

2.5 - FAQ

Are GPS enabled APs required for AP auto placement?

No, GPS enabled APs are not a requirement. AP auto placement can be achieved using FTM.

Is AP auto placement possible with 500 series APs?

500 series APs can be auto-placed on a floor plan. The integrated FTM radio in the AP helps to facilitate auto-locate. With the use of the Central floorplan manager and the anchor APs, 500 series APs can be auto-placed on a floorplan.

Will GPS enabled Anchor APs be automatically placed on the floor plan?

Currently, floorplan manager does not automatically place Anchor APs with GPS on floor plan.

Does my Central account need to be allow listed, to try open locate?

No additional allow list is required other than access to New Central.

How does the system auto place the APs on the correct floor?​

The user must manually assign the APs to the appropriate floor. ​

Does FTM work on a 6 GHz band?

That depends on the AP model. Currently AP-605H & AP-615 support AP-to-AP and STA-to-AP, with support for the 700 series APs coming soon.

Why is 80 MHz wide channel required for AP auto placement?

An 80MHz wide channel is essential because larger bandwidth enables efficient exchange of AP-to-AP or STA-to-AP FTM data, ensuring optimal performance and reliability.

How long does data collection take with FTM monitor mode?

FTM monitor mode takes between 15 – 30 minutes to gather the FTM data required for AP auto-placement.

Will FTM monitor mode disrupt Wi-Fi connectivity?

Enabling an FTM scan will temporarily disrupt Wi-Fi connectivity on the 5 GHz radio. During the scan, all connected Wi-Fi clients will experience an outage for the duration of the system-calculated scan. Once the scan is complete, the network will automatically restore connectivity.

Does an FTM Monitor mode scan need to be rerun after adding new APs to the floor plan?

Yes. However, if an AP is deleted, rerunning the FTM Monitor mode is not necessary, but the deleted AP should be unassigned from the floor plan.