For IT teams, good user experience is a moving target. Reliability and resiliency are crucial for good outcomes, and this is especially challenging with WLANs (wireless LANs). Built on an unlicensed and shared radio frequency (RF) spectrum, RF waves bounce, reflect and propagate differently through mobile and static objects, leading to a constantly morphing and shifting radio space. Unintended contention and uncontrollable interference can also make for a hostile playing field.
Depending on the business type, location and site, Day 0, Day 1 and Day 2+ often look radically different from an RF perspective, with fluctuations occurring at different times of the day and week. For WLAN designers and operators seeking to optimize user experience, the phrase “no plan survives contact with the enemy” speaks to the unpredictability of the medium and the myriad operational challenges with RF and WLAN access edges. Luckily, AI-driven radio resource management (RRM) doesn’t sleep; it continually learns and optimizes based on patterns invisible to humans and legacy RRM implementations.
From Auto-RRM to AI-driven RRM
Wireless LAN RRM has been steadily evolving. It now goes far beyond just channel and power selection for access point radios and leverages richer data combined with AI for IT operations (AIOps). Vendors originally championed “auto” RRM, but the algorithms and approaches were often too opaque and used only simple, limited statistics. This resulted in a lack of confidence and trust in RRM by WLAN professionals, which led to some still advocating a “low and slow” static approach.
Figure 1: A graph and time-series learning problem.
RRM is not simple by any means, and due to the dynamic nature of environments, it requires constant feedback loops to model, optimize and adjust each unique site’s characteristics for an optimal user experience. RRM also requires longer-term “site” memory and an ability to see beyond RF fundamentals by using a wider set of metrics, such as service level expectations (SLEs), to optimize for distinct populations and spaces. Modern RRM requires enhanced observability, better distributed situational awareness and a form of higher-order intelligence that can continually learn and make decisions to positively and definitively impact user experience.
This is where Juniper Mist’s cloud-based AI-driven RRM excels. With its advanced use of blended machine learning (ML) models that learn and adapt to specific and unique site characteristics while also understanding time-based patterns. This results in not just smarter and more trustworthy automation but WLANs that can go beyond channel and power settings to select the best channel widths, disable or re-purpose radios and differentiate between quiet and busy times, all the while learning, adapting, troubleshooting and continually optimizing.
Six New AI-Driven RRM Enhancements
Let’s take a brief look at six new AI-driven RRM features that are coming. The dual goal of making network operators’ lives easier and improving user experience requires intimate knowledge of each unique site. By leveraging a range of SLEs across the stack, Juniper Mist’s AI-driven RRM delivers on the promise of AIOps.
When optimizing for operations in any dynamic environment, it’s critical not to assume all sites and spaces are equal. Although many offices share common traits, different operating environments, such as warehouses, retail, hospitality and healthcare, serve different populations throughout the day and night. Each is subject to a diverse range of devices, densities and fluctuating demands. This is where AI-driven RRM rises to the challenge and goes beyond heuristics and basic feedback loops to intelligently combine time-series and graph learning problems for superior performance and operational outcomes.
Better Baselining and Learning for Maintenance Hours
The first step for AI-driven RRM involves establishing baselines. There are two tiers used by Juniper Mist’s RRM in this approach, with both applied on a per-site basis. Initially, a first-tier “global” level view is taken to baseline a site’s “quiet” times. Then, a more dynamic and localized second tier uses ongoing events, data and metrics (including deviations from the baseline) to trigger updates based on reinforcement learning and SLEs. The per-site baselining used to happen at approximately 3 a.m. local time each day, but it was found too restrictive for certain environments based on their operations and business type.
By recognizing this and then evolving and adapting the ML model, Juniper Mist’s AI-driven RRM now continually learns from the last four weeks of time-series and graph data. It looks at weekly patterns using a one-day sliding window to determine the most optimal day and time to baseline against. By challenging assumptions, improving observability and following the data, AI-driven RRM can now better optimize RF spaces irrespective of seasonality and type of business. The AI-driven RRM effectively learns about your specific operating model and optimizes around it.
Auto-bandwidth Selection
During the planning and design stages of a WLAN, it’s difficult to discern whether a busy space could, or indeed should, support 20MHz, 40MHz, 80MHz or even 160MHz channel widths across 5GHz and 6GHz frequencies.
Figure 2: Site average available channel per AP
WiFi-6E may be a game changer, but everything still depends on device populations and the surrounding RF environment. Can your specific site and device types happily provide an optimal user experience using wider channel widths, or are narrower channels required for a cleaner and more robust channel plan? Post-deployment validation surveys are still point-in-time, and environments can and do substantially change over time. The ability for a WLAN’s RRM to optimize not just a site’s channels and power but channel widths then becomes a game changer.
Figure 3: Site utilization and co-channel contention/interference
Not only does Juniper Mist’s RRM continually learn about the RF space using a range of inputs from APs, scan data, clients and application metrics, but with the aforementioned better baselining and continuous reinforcement learning based on SLEs, the AI-driven wireless edge can now empirically determine, and automatically configure, the optimal channel width. This means maximizing ongoing coverage, capacity and user experience just got a whole lot easier.
For those who want to stick with operator-determined channel widths, it’s just a simple policy override away, but when an AI-driven RRM follows the data, and combines additional improvements like “Radar Punishment” (below), auto-bandwidth selection is set to answer one of the most challenging and divisive “it depends” questions in WLAN design and operations.
Radar Punishment
The use of dynamic frequency selection (DFS) channels is another challenging topic in WLAN design and operations. It relates to radar avoidance and detection. DFS can cause an AP to change channels when using auto-RRM implementations. Whereas some operators take a binary approach in relation to either the spectrum’s use or non-use, the decision can be highly dependent upon a site’s proximity to ports, military bases and satellite or weather stations. Radar patterns can also change in relation to their channel use and cadence over time. This leads to further uncertainty and wariness surrounding the use of such valuable spectrum.
Previously, limited localized intelligence was used to determine which APs could move to alternate candidate channels due to radar “hits”. With this latest enhancement, the AI-driven RRM uses a mix of historical site radar “hit” data (gathered over a trailing four-week period) and combined with general channel utilization to then update and rank a candidate list of potential alternate channels, a list that is then available to nearby APs also.
Figure 4: Surface events for radar detection and channel updates.
The AI-driven RRM now effectively demotes and “punishes” certain candidate channels based on explicit times and days, leading to more of the spectrum being available and less overall channel churn. When this intelligence is gathered and then distributed on a site-by-site basis, it bolsters confidence in the use of available DFS spectrum and channels, no matter the location.
Zero and Low Client Detection Anomalies
Why does this AP have a very low number of clients, is this normal?
This is not just an interesting but difficult question to solve without visibly checking a space. Is there a problem with the AP or location? Is there normally a greater number of clients connected to this AP on this day of the week and at this time?
Determining whether there is a low usage anomaly on an AP is a very useful feature to have. It’s possible to flag certain APs for further troubleshooting and diagnostics by making predictions based on forecasts of an AP’s normal usage. This is done initially using a form of “inclusive detection,” which looks at the previous few weeks of daily data, including relevant metrics like client dwell time, send and receive traffic, and peer AP comparisons, to flag an anomaly.
Once an AP with anomalously low usage is detected, it’s added to a problematic AP pool where a form of “exclusive detection” is used to look for system-level errors, physical errors, interference events, noise floor etc. If a problem is indeed found, and an attempt to reset and restart the AP does not address the issue, the AP is queued for a return merchandise authorization (RMA). A mixture of techniques like scope analysis and clustering are also used to identify issues and thus accelerate operations, again delivering on the promise of AIOps and an AI-driven enterprise.
Increased Intelligence in Marvis Actions
Marvis Actions are one of the primary user interfaces for both observing and engaging with Juniper’s AI-driven enterprise. There are two varieties of actions, those that Marvis carries out automatically, and those that are recommended but require a “human in the loop” to initiate the next step. As this Marvis Actions explainer notes, one mode is akin to full self-driving whereas the other is likened to driver-assist.
From an RRM perspective, once any global policy, site, or device limitations are configured, Marvis Actions for RRM are then fully automated (self-driving). If Marvis detects an AP experiencing issues, such as one failing to beacon, Marvis will try to “unstick” the AP and radio automatically. Previously Marvis would try to locally reset the radio or change channels and this triage didn’t factor into the global AI-driven RRM, but now it does and it also leverages the intelligent real-time candidate channel ranking, while also updating and contributing to it. Should an issue not be resolved, then the radio may be disabled and the AP flagged for deeper automated analysis which could lead to an RMA if hardware issues are found.
Auto Conversion and Cancellation
The Juniper Mist AP24 is an entry-level tri-band access point (AP) that’s limited to dual-band concurrent operation. This means it can operate in all three bands (2.4GHz, 5GHz, 6GHz), but only two of them concurrently. One of the active radios can operate in either (i.e. switch between) 2.4GHz or 6GHz frequencies.
The Juniper Mist AP45 is also a tri-band AP(Access Point), but it can run concurrently in all three bands (2.4GHz, 5GHz, 6GHz). However, due to two of its radios being dual-band (2.4GHz and 5GHz) radios, it can operate in an optimized 5GHz mode where the 2.4GHz radio adopts a 5GHz operating mode.
The question then becomes when to use 5GHz or 6GHz exclusively and when to keep a diminished 2.4GHz presence or remove it entirely, i.e. when to turn off a 2.4GHz radio on a select few APs or throughout a site. This is where the new AI-driven RRM enhancements deliver unprecedented flexibility for design, deployment and ongoing operations. With auto-conversion and cancellation, the AI-driven RRM learns from specific sites and environments what works best for the devices using empirical and fresh data.
Evolving with AIOps (AI for IT Operations)
Figure 5: Graph of access points that can hear one another.
Rather than staying stuck in the past with static algorithms, stale data and lumbered with out-of-date assumptions, it’s time to embrace better tools, ones that learn, predict, recommend and action what’s best in real-time for your specific RF space. You can still define the policies and boundaries that the AI-driven RRM will adhere to (or can opt out of features), but for dynamic environments like RF, there’s no time like the present to lessen your team’s operational load, improve your users experience and frictionlessly accelerate your goals with AIOps.
Join us for a live demo of the AI-Driven enterprise here or read more about AI-powered Zoom Troubleshooting and ChatGPT natural language Marvis integrations.
Statement of Product Direction. Juniper Networks may disclose information related to development and plans for future products, features or enhancements, known as a Statement of Product Direction or Plan of Record (“POR”). These details provided are based on Juniper’s current development efforts and plans. These development efforts and plans are subject to change at Juniper’s sole discretion, without notice. Except as may be set forth in a definitive agreement, Juniper Networks provides no assurances and assumes no responsibility to introduce products, features or enhancements described in this website, presentation, meeting, or publication, nor is Juniper liable for any loss arising out of reliance on the POR. Purchasing decisions by third-parties should not be based on this POR, and no purchases are contingent upon Juniper Networks delivering any feature or functionality described in this website, presentation, meeting, or publication.
