Systems and Methods for a Virtual Network Assistant

This application is a continuation of US Patent Application No. 18/306,670, filed 25 Apr. 2023, which is a continuation of U.S. patent application Ser. No. 17/198,638, filed 11 Mar. 2021, now issued U.S. Pat. No. 11,677,612, which is a continuation of U.S. patent application Ser. No. 16/279,243, filed 19 Feb. 2019, now issued U.S. Pat. No. 10,985,969, the entire content of each application is incorporated herein by reference.

One exemplary aspect relates to monitoring wireless communications systems and, more particularly, methods and/or apparatus for determining the root cause of issues encountered by wireless network users.

Users of wireless complex networks, such as WiFi networks, may encounter degradation of system level experience (SLE) which can be a result of a variety of issues. When issues present themselves, to ensure high SLEs, it is critical to promptly identify the root cause of the issue and to initiate either manual or automated corrective measures. Given the fact that some of the mitigation actions may have an adverse impact on users that are experiencing proper a SLEs, it is important to ensure that the system has a high level of confidence that it has identified the root cause of the issue before invoking a corrective measure(s).

What is needed is a system that can determine with a high probability which components of the system are the key suspects in causing the SLE degradation and provide a measure or estimation for a level of confidence in the determination.

One exemplary aspect describes methods for determining the root cause(s) of SLE degradation experienced by a client(s) and/or the network. The methods identify a portion or all of the potential issues with a client and the network, rank the likelihood of the various potential root causes based on their importance in causing those issues, and find the scope similarity of likelihood for each feature contributing to those issues. Specifically, the exemplary method identifies the root cause of an issue by obtaining an indicator regarding the measure of the mutual dependence between the observed issue and the various potential root causes of the issue. Once the root cause is identified, corrective measures can take place while minimizing the impact to other clients which are using the network. The corrective measure can be automatically initiated such as sending a reboot instruction to one or more pieces of equipment in the system.

Each SLE measurement is associated with the specific client/terminal/user equipment (UE) which measured the SLE, as well as with the wireless local area network (WLAN) (e.g., service set identifier, SSID) used (or attempted to be used) by the client, the specific radio band used, and the specific access point used in that interaction, optionally with any other relevant information. In addition, in accordance with yet another embodiment, the SLE measurements may be associated with a specific server attached to the network such as an authentication, authorization, and accounting (AAA) server, a dynamic host configuration protocol (DHCP) server, etc. As such, when a poor SLE is detected, the methods below at least provide means for detecting which one of these system components is the root cause of the identified SLE deterioration.

A network management system in accordance with one exemplary aspect continuously or substantially continuously monitors indicators of SLE as well as monitors the system level experience of users. For example, the network management system may, and often does, monitor for each wireless device the connect time, throughput, coverage, capacity, roaming, success to connect, AP availability, etc. In accordance with one embodiment some of the parameters, e.g., level of received signal strength indicator (R SSI), are measured by each client and sent via an associated access point (AP) to the network management module over a local area network (LAN)/wide area network (WAN)/Internet. Other SLE parameters, e.g., failed attempts by a client to connect to the wireless network, are observed by an AP and reported to the network management module which keeps a count of the number of failed attempts of each specific client over a specific WLAN SSID and a specific AP. The count is measured over a predetermined time period, e.g., over a time window of an hour, three hours, a day, etc.

Some parameters are tracked as raw information. For example, the number of clients that fail to connect via a specific AP is monitored and continuously tracked. Other parameters such as the RSSI seen by a specific client may be compared to a predetermined threshold and the network management module tracks the number of RSSI occurrences below a predetermined threshold or above a predetermined threshold rather than track the actual value of the RSSI.

Each SLE observation is associated with the network component(s) over which the client attempted to associate with the network or successfully associated with the network. These network components can include one or more of clients/terminals/UEs, WLAN(s), radio band(s), AP, AAA server, DHCP server(s), etc. The processes described below construct for each one of the network components a measurement indicative of the probability that the identified component is the root cause of an observed poor SLE.

Specifically, for each one of the network components the method approximates the probability of the inetwork component (feature), fbeing problematic given the observation of failure, F, for a given client C:

The network management system maintains site level counters for each successful and failed SLE and the associated network components over which the corresponding UE is associated (or attempted to associate) with the network. These counters are then used to calculate the P(F|f) and the P (f, C) probabilities for each specific SLE. Specifically, the probability of failed SLE given a specific network component (feature) is estimated by:

Similarly, the probability that a specific network component ft is used when we observe a failure of a specific client, CF, is estimated by:

For example, when attempting to estimate the probability that a poor SLE experience by a specific client C was caused by a specific network component ft, the method first determines the number of failed SLEs of that specific client which involved the specific network component, n(f, F, C), and divides the resulting number by the total number of SLE attempts (both those which resulted in a good SLE and those that resulted in a poor SLE), n(C) made by that client over a specific time period. It should be noted that SLE attempts could be e.g., connection attempts, throughput attempts, or any other type of SLE attempt. In a specific illustrative example, equation 3 helps estimate how many times a specific client failed over different network routes/types, such as WLAN, AP and band.

Using the estimated probability values of equations 2 and 3 in equation 1 yields the following estimations for the probabilities/likelihood that a specific component e.g., WLAN, AP and band is the root cause of a failed (poor) SLE observed by a specific client.

The system utilizes the root-cause analysis to estimate for each network component the probability that each component caused the observed poor SLE. A corrective measure(s) can then be taken against the component that is most likely to be the perpetrator and/or contributor to the cause of the issue.

Some of the corrective actions may require automated restarting of a specific network component impacting other clients/terminals/UEs which utilize that network component for their normal operations. If the system were to mistakenly identify a properly functioning network component as being the root cause of the poor SLE, restarting the wrong network component would not fix the issue, and even worse, it would adversely impact other clients which depend of that network component for continued operation.

To reduce the risk of taking corrective action against a network component that has been erroneously identified as a root cause of poor SLE experienced by a specific client, the system in accordance with one exemplary aspect examines the level of certainty the system has in its root cause identification. For example, if one client attempts to connect over a network component, e.g., a specific radio band, and fails, there is little information about the functionality of that specific radio band. However, ifclients attempt to connect over the same radio band and all fail, there is a much higher confidence that the specific network component (e.g., radio band) is faulty.

To identify the root cause of poor SLEs, the system can observe various SLE measurements by each one of the clients that attempted (some successfully and some unsuccessfully) to connect to the network. Additionally, for each attempt the system can, and often does, monitor and record the network components which were involved in the connection attempts. Based on these measurements and observations, the system can determine the probability of each network component being the root cause for the SLE degradation. Next the system determines the significance of the information the system has leading to making the root cause determination.

One exemplary aspect uses the notion of mutual information to determine the significance of the information that is utilized in the process of determining the root cause of SLE deterioration. The mutual information of two discrete random variables X and Y is provided by:

Mutual information tells us how important the network feature fis at predicting the SLE random variable. However, mutual information doesn't tell us if the network feature is a predictor of success or failure. For that, an exemplary aspect uses the Pearson correlation as a sign operator to give polarity to the mutual information correlation. Pearson correlation is a measure of the strength and direction of association that exists between two variables. The Pearson correlation factor is a number between −1 and 1. A positive number indicates that when one variable increases, the other variable increases as well. A negative number indicates that when one variable increases, the value of the second variable decreases. A value of 0 indicates no linear correlation between two variables.

Network features that may contribute to failed SLEs have a negative Pearson correlation while those which may contribute to success SLEs would have a positive Pearson correlation.

For example, assume the system collected only three observations within a specific time period:

The probability that any of these network components including client C, access points AP1 and AP2 and channels Ch. 1 and Ch. 2 is the root cause of the failed connection can be calculated using equations 4 through 7 above:

The mutual information that these observations provide about the hypothesis that any one of the network components is the root cause of the failed connections can then be calculated by using equation 8. Specifically, the supporting mutual information for the hypothesis that the failure is caused by a failed APi is calculated by:

The supporting mutual information for the hypothesis that the failure is caused by a failed channel 1 (Ch) is calculated by:

The supporting mutual information for the hypothesis that the failure is caused by a failed APi is calculated by:

The supporting mutual information for the hypothesis that the failure is caused by a failed Channel 2 (Ch) is calculated by:

Referring to Table 1, it becomes clear that channel 1 is the most likely root cause of the issue as its likelihood is the highest and the mutual information is the most negative. As channel 1 always appears with failures, the mutual information correlation (scope of impact) has negative polarity (almost-1).

In accordance with one specific embodiment, the system may take an action such as automatically restarting a network component that has the highest probability of being the root cause of the issues experienced by users (such as not being able to connect over the network, experiencing slow connect time, experiencing low bit rate, etc.). To restart the offending network component, the network management system issues a control message to the offending component or to a network component associated with the offending network component, instructing it to restart the offending component.

In accordance with yet another embodiment, once the system identifies the component with the highest probability of being the root cause of the issues experienced by users, the system first examines the mutual information that supports the hypothesis that the component is the root cause of the issues experienced by the users. The system then compares the mutual information to a predetermined threshold, e.g., −0.20 (although any threshold can be used), and only if the mutual information correlation associated with the component is lower than the threshold, the system takes automated action such as restarting a component. In case the mutual information is greater than (or equal to) the threshold, the system waits to collect additional information or just alerts the system administrator and provides the system administrator with statistics such as those highlighted in table 1.

illustrates an exemplary systemimplemented in accordance with an exemplary embodiment. Exemplary systemincludes a plurality of access points (API, . . . , AP X, AP 1′, . . . , AP X′, AP 1″, . . . , AP X″, AP 1′″, . . . , AP X″), a plurality of Authentication, Authorization and Accounting (AAA) servers (only one AA serveris shown), a plurality of Dynamic Host Configuration Protocol (DHCP) servers (only one DHCP serveris shown), a plurality of Domain Name System (DNS) severs (only one DNS serveris shown), a plurality of Web servers (only one Web serveris shown), and a network management system (NMS), e.g., an access point management system, which are coupled together via network, e g., the Internet and/or an enterprise intranet. Network communications links (,,,,,,,) couple the access points (API, AP X, AP 1′, AP X, AP 1″, AP X″, AP 1″′, AP X″), respectively, to network. Network communications linkcouples the AA servers (only AA serveris shown) to network. Network communications linkcouples the DHCP servers (only one DHCP serveris shown) to network. Network communications linkcouples the DNS servers (only one DNS serveris shown) to network. Network communications linkcouples the Web servers (only one Web serveris shown) to network. Exemplary systemfurther includes a plurality of clients or user equipment devices (UE 1, . . . , UE Z, UE 1′, . . . , UEZ′, UE 1″, . . . , UEZ″, UE 1′″, UE Z″). At least some of the UEs (,,,,,,,) are wireless devices which may move throughout system.

In exemplary system, sets of access points are located at different customer premise site(s). Customer premise site 1, e.g., a mall, includes access points (AP 1, . . . , AP X). Customer premise site 2, e.g., a stadium, includes access points (AP 1′, . . . , AP X′). Customer premise site 3, e.g., an office, includes access points (AP 1″, . . . , AP X″). Customer premise siteNincludes access points (AP 1″′, . . . , AP X″). As shown in, UEs (UE 1, . . . , UE Z) are currently located at customer premise site 1, UEs (UE 1′, . . . , UE Z′) are currently located at customer premise site 2; UEs (UE 1″, . . . , UE Z″) are currently located at customer premise site 3; and UEs (UE 1″″, . . . , UE Z″) are currently located at customer premise site N.