Patent Description:
Radio chipsets are often used in wireless access points such as Wi-Fi access points (AP). While the chipsets greatly simplifying the design and construction of wireless APs, the inner states of the chipsets is often difficult to assess because the counters which are exposed by the chipset are often corrupted by interference from neighboring APs. As such the information provided by the inner chipset counters provides noisy data that conveys unreliable and at times misleading information.

Thus, it can be difficult to assess if a radio transmitter is experiencing operational difficulties (e.g. stuck or has stopped transmitting). Detecting operational problems or faults can be important in resolving issues promptly. For example, if a beacon radio (or any other radio) of an access point stops transmitting, the access point is not visible to neighboring mobile wireless terminals (WT). As a result, a neighboring WT would not be able to associate or otherwise communicate with the AP. The earlier we detect that an issue occurred, the faster a technician may be notified, and / or an automated recovery mechanism may be invoked to remedy the situation. Thus, improved methods of providing reliable health status of a network component may be useful, even when built in diagnostics of the network counter are providing noisy and at times misleading information.

<CIT> relates to management system implemented in a cloud computing environment for automatically managing a plurality of Wi-Fi access points in a network that can receive information from each of the plurality of Wi-Fi access points. <NPL>, relates to Client Conduit, which enables bootstrapping and fault diagnosis of disconnected clients. <CIT> relates to an AP based intelligent fog agent that manages fog computing to connect loT devices and enhance interoperability.

The invention is defined with particular reference to <FIG>.

Many network devices include diagnostic capabilities. These diagnostic capabilities typically maintain statistics regarding performance of the network device. These statistics may convey information relating to, for example, an amount of network traffic processed by the network device, (e.g. counts of received messages or packets, counts of transmitted messages or packets, latencies, or throughput). In some cases, these statistics rely on hardware-based analysis of network traffic. For example, a network interface chip of the network device may maintain one or more data values to support generation of these diagnostic statistics. However, these diagnostic capabilities are sometimes unreliable. For example, some network interface chips are vulnerable to interference generated by other wireless devices, which may cause corruption of their internal counters that support the diagnostics capabilities. To reduce uncertainty, and increase reliability of diagnosis of network devices, the disclosed embodiments incorporate information from neighboring (peer) devices to derive a more accurate determination about the health of a given device.

In accordance with one, non-limiting, example, a beacon radio of an AP transmits beacon messages at a particular rate (e.g. <NUM> beacons per second). When a wireless device receives the beacon message, it can assess the signal strength of the beacon and based on the strength of the signal to determine whether to associate with that AP. Some embodiments of an access point include a wireless radio chipset that maintains one or more counters that characterize operation of the wireless radio. In some of these embodiments, an internal counter in the radio chipset, Rx, counts the number of messages the AP receives in response to sending the beacon signal. However the count indicated by the Rx counter may be affected by messages from other neighboring WTs and as such is not reliable. Additionally, the Rx counter included in the chipset provides a cumulative count of various other parameters. This can present challenges when assessing the health of the AP solely based on the internally managed statistics of the wireless radio.

Since the internal diagnostics provided by the network device can be unreliable and thus convey little or sometimes misleading information regarding the health of the AP, a system implementing one or more of the disclosed embodiments uses a predetermined threshold to map a receive (Rx) count provided by the internal diagnostics into a binary value (e.g. either <NUM> or <NUM>). When the number indicated by the Rx counter falls below a predetermined threshold, the system maps the Rx count to a first value (e.g. zero (<NUM>)) and when the number is equal or greater than the threshold, the Rx count is mapped to a second value (e.g. one (<NUM>)).

Implementations that rely on diagnostic data provided by a single AP can experience challenges. For example, implementations that make control determinations for a networked system based on data provided by a single AP, be it either raw unprocessed receive counts from internal diagnostics of an access point (e.g. the Rx counter discussed above), or the binarized value of the receive count as also described above, can detect a large number of false positives or fail to detect some AP failures. This results in sub-optimal control determinations.

To improve the accuracy of these determinations, at least some of the disclosed embodiments utilize information from neighboring (peer) APs. Some embodiments place a limit on the number of neighbor or peer devices relied upon when making a determination about a particular network device. For example, some embodiments may limit the number of peer devices considered to five (<NUM>), six (<NUM>), seven(<NUM>), eight (<NUM>), nine (<NUM>), or ten (<NUM>) devices.

Some of the disclosed embodiments receive signal strength measurements from wireless terminals to determine which APs are within a predefined proximity to each other. In some embodiments, two APs, AP1 and AP2, are said to be peers if there exists a client WTi which meets the condition defined by Equation <NUM> below:
<MAT> Where:.

Alternatively, in some embodiments APs identify each other's beacon signals and define an AP as a peer neighbor if a signal strength of a signal received from the other AP is greater than a predetermined threshold. Specifically, APi and APj are considered to be neighbors if <MAT> where:.

In other embodiments, peers of a first AP are identified as those candidate peer APs with signal strengths, as experienced at the first AP, that are above a threshold. Some embodiments rank candidate peer APs by the signal strength, and then selects N highest ranked number of candidate APs as peer APs of the first AP. (e.g. N may be any number between one and one hundred).

To incorporate the information from the peer APs, some of the disclosed embodiments collect operational statistics from the neighboring APs. These operational statistics may include, for example, a number of clients associated with or in communication with the peer AP, or a receive counter of the peer AP. The receive counter may count a number of packets received, an amount of data received, or other metrics that quantify receive activity on the peer AP. Some embodiments store the collected operational statistics in memory. Some organize the collected operational statistics in a table, such as the example Table <NUM> below:.

APi of Table <NUM> above denotes an AP whose health is being analyzed. AP<NUM> through AP<NUM> represent peers of APi as defined by, in some embodiments, either equation <NUM> or equation <NUM> above. The number of associated wireless devices indicates a time-correlated number of WTs associated with each one of the peer APs as well as the number of WTs associated with the AP whose health is being assessed. The Rx counter is indicative of a number of received messages tracked by a receive counter (Rx) of each one of the said peer APs within a predetermined time window (e.g., one minute). In some embodiments, the receive counter is implemented in hardware, software or firmware of the respective network component.

Relating a first predetermined threshold (e.g., ten (<NUM>)) to the number of wireless devices associated with each AP, and a second predetermined threshold (e.g., fifty (<NUM>)) for the receive counter(s), the values in table <NUM> are mapped to either an active state or a non-active state or into one of two binary values as illustrated by table <NUM> below:.

The conversion of data as represented in table <NUM> to data as represented in table <NUM> is performed in accordance with the following in some embodiments: If the AP was active during a specific period of time, the method marks the AP state to be zero for the said time window. However, if the AP is determined to be inactive during the specific time period the method maps the state of the AP to a binary value of <NUM> for the said time window. (e.g. in this example, active=> <NUM>; non-active=> <NUM>).

The information in table <NUM>, is collected periodically in at least some embodiments e.g., every <NUM> seconds. The periodically collected information is then mapped to binary values as described above. This periodic processing generates time series of binarized data for each AP monitored.

Data within the time series is grouped into time periods that may include data collected over more than one periodic collection interval. For example, while data is collected every N seconds, data for a time period of Z seconds is grouped for further processing (with Z > N) in some embodiments.

An illustrative example of the time series for the number of clients observed by the AP whose health is assesses and by its peers is provided in table <NUM> below. Since each column represents a single collection event, the multiple columns represent multiple collection events over some period of time.

Similarly, Table <NUM> below illustrates an example mapped time series for Rx counts of the monitored network component (APi) and its peers.

To determine whether a subject AP is active within a given time window (time period), the system analyzes the number of activity indications within each time period. For example, the method may use a first criterion (e.g. threshold of > <NUM> (e.g., > <NUM>%) for the subject AP whose health is being assessed (e.g., APi). Some embodiments determine an activity state of the subject AP using a window size of W (e.g. <NUM>) minutes. If the percentage of data values indicating activity within the time window is greater than the first threshold, the subject AP is determined to be active during that time window. A second threshold, (e.g., > <NUM> { > <NUM>%}), may be used for the peer APs of the subject AP. Specifically, peer APs are considered to be active if the percentage of activity indications (e.g. zero in this example) in a given time period is greater than the second threshold.

In the Table <NUM> example above, during a first time window, APi is active during two (<NUM>) often (<NUM>) samples and as such is determined to be non-active during that time window (<NUM> is less than or equal to the first threshold, discussed above). During a second time window (also ten minutes in this example), APi is also active for two out of <NUM> samples and as such it is assumed to be non-active. In a third example time period of ten minutes APi is active four (<NUM>) out of the ten (<NUM>) samples and as such it is determined to be active. Using a value of one (<NUM>) to represent inactive and zero (<NUM>) to represent active, the three determinations above can be represented in a vector as {<NUM>, <NUM>, <NUM>} or (inactive, inactive, active).

For neighboring APs, a second threshold is used in some embodiments (e.g., <NUM>). Using the second threshold, for the illustrated three time periods a state of peer AP<NUM> is mapped to {active, active, active} or equivalently to {<NUM>, <NUM>, <NUM>}. Similarly, AP<NUM> is mapped into { active, non-active, active} or equivalently to {<NUM>, <NUM>, <NUM>}.

A maximum duration of APi being non-active during contiguous time periods is then determined. For example, if APi is non-active for a duration of five consecutive one minute periods (a total duration of five minutes), APi is determined to be non-active for a duration of five. Referring back to the example of table <NUM>, the short activity series is indicative of APi being inactive for a duration of two (non-active in the first and second time periods). This duration is stored for later use.

Next the system uses the mapping of the active states and non-active states (e.g., within the <NUM> minutes windows) to calculate a moving window average of the APi active state (e.g. in this example, the active state being represented as zero). For example, assuming that the active state of the APi is given by the series {<NUM>, <NUM>, <NUM>, <NUM> , <NUM>, <NUM>, <NUM>, <NUM>, <NUM>}, using a moving window of size two (<NUM>) results in moving window average values of {<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>}. This moving window average is stored for further use. An average of peer APs state values is also determined. This average of peer APs state is then used to generate a moving average of the averaged peer state.

The average peer state value is given by Equation <NUM> below: <MAT> where:.

As an example, if the time series for states of two peer APs of APi e.g., APj and APk is given by <MAT> <MAT>.

The averages of the peer AP values, via equation <NUM> above, are: <MAT>.

Using a moving window of length two (<NUM>) the moving average for the above series is given by <MAT>.

Similar calculations are performed on data of table <NUM> to obtain the moving average of the percentage of non-active states as judged by the Rx counter of the peers.

Based on the discussion above, a combination of one or more of the following statistics are used to derive an indication of whether APi is operative:.

Some of the disclosed embodiments utilize a machine learning model to assess whether the APi is running / operational, or down/non-operational. One or more criterion for determining the APi is operational may vary by embodiment. The following example criterion are used in some embodiments:.

In general, R1-R3 above are indicative that APi is non-active and as such may be experiencing an operational fault. R4 and R5 examine whether the peer APs of APi are active. Some embodiments determine that APi is faulty only if it is found to be non-active and its neighbors are active.

The five rules (R1 through R5) articulated above define a five dimensional "cube" volume. A more complicated volume, rather than a simple cube, can be defined in the five-dimensional space and the determination of whether APi is experiencing an operational fault is based on whether a combined activity vector is within the said more complicated volume. Where the combined activity vector is defined by <MAT> where:.

While the description above includes reference to four specific activity measurements when assessing health of an AP, some embodiments may rely on one or more additional parameters not discussed above.

<FIG> illustrates an example system 100a implemented in accordance with an embodiment. Example system 100a includes a plurality of access points (AP1 <NUM>,. , AP X <NUM>, AP <NUM>' <NUM>,. , AP X' <NUM>), a plurality of Authentication, Authorization and Accounting (AAA) servers (only one AA server <NUM> is shown), a plurality of Dynamic Host Configuration Protocol (DHCP) servers (only one DHCP server <NUM> is shown), a plurality of Domain Name System (DNS) severs (only one DNS server <NUM> is shown), a plurality of Web servers (only one Web server <NUM> is shown), and a network management system (NMS) <NUM>, e.g., an access point management system, which are coupled together via network <NUM>, e.g., the Internet and/or an enterprise intranet. Network communications links (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) couple the access points (AP1 <NUM>, AP X <NUM>, AP <NUM>' <NUM>, AP X' <NUM>), respectively, to network <NUM>. Network communications link <NUM> couples the AA servers (only AA server <NUM> is shown) to network <NUM>. Network communications link <NUM> couples the DHCP servers (only one DHCP server <NUM> is shown) to network <NUM>. Network communications link <NUM> couples the DNS servers (only one DNS server <NUM> is shown) to network <NUM>. Network communications link <NUM> couples the Web servers (only one Web server <NUM> is shown) to network <NUM>. Example system <NUM> further includes a plurality of clients or user equipment devices (UE <NUM><NUM>,. , UE Z <NUM>, UE <NUM>' <NUM>,. , UEZ' <NUM>. At least some of the UEs (<NUM>, <NUM>, <NUM>, and <NUM>) are wireless devices which may move throughout system <NUM>.

In example system <NUM>, sets of access points are located at different customer premise site(s). Customer premise site <NUM><NUM>, e.g., a mall, includes access points (AP <NUM><NUM>,. , AP X <NUM>). Customer premise site <NUM><NUM>, e.g., a stadium, includes access points (AP <NUM>' <NUM>,. , AP X' <NUM>). As shown in <FIG>, UEs (UE <NUM><NUM>,. , UE Z <NUM>) are currently located at customer premise site <NUM><NUM>; UEs (UE <NUM>' <NUM>,. , UE Z' <NUM>) are currently located at customer premise site <NUM><NUM>.

The network management system (NMS), <NUM>, continuously collects SLE statistics related to the performance experienced by a portion or all of the clients or UEs described above. Whenever SLE degradation is experienced, the network management system, <NUM>, and especially the automated fault analyzer module, triggers injecting action into the system, such as restarting a device or alerting an IT technician.

<FIG> illustrates an example system 100b implemented in accordance with an embodiment. Example system 100b includes a plurality of access points (AP1 <NUM>, AP2 <NUM>. , AP <NUM><NUM>), and the wireless links between these APs.

The links represent the N strongest RSSI signals to neighboring APs. In the example of <FIG> the number N = <NUM>. Based on the RSSIs, the peer neighbors for AP1 are AP2, AP3, AP7, and AP6. The peer neighbors for AP2 are AP1, AP3, AP4, AP7, and AP2. The peer neighbors for AP3 are AP1, AP2, AP8, AP4, and AP5. Similarly, the other peer neighbors can be determined for the other APs. It should be noted that while the number of peers for the above APs was limited by the predetermined parameter N=<NUM>. In contrast AP8 has only two neighboring peers, AP3 and AP4, since the strength of RSSIs from the other APs is below an RSSI threshold e.g., -75dBm.

<FIG> illustrates an example access point <NUM> (e.g., access points AP <NUM><NUM>,. , APX <NUM>, AP <NUM>' <NUM>,. , APX' <NUM>, of <FIG>) in accordance with an embodiment. Access point <NUM> includes wired interfaces <NUM>, wireless interfaces <NUM>, <NUM>, a processor <NUM>, e.g., a CPU, a memory <NUM>, and an assembly of modules <NUM>, e.g., assembly of hardware module, e.g., assembly of circuits, coupled together via a bus <NUM> over which the various elements may interchange data and information. Wired interface <NUM> includes receiver <NUM> and transmitter <NUM>. The wired interface couples the access point <NUM> to a network and/or the Internet <NUM> of <FIG>. First wireless interfaces <NUM> may support a Wi-Fi interface, e.g. IEEE <NUM> interface, includes receiver <NUM> coupled to receive antenna <NUM>, via which the access point may receive wireless signals from communications devices, e.g., wireless terminals, and transmitter <NUM> coupled to transmit antenna <NUM> via which the access point may transmit wireless signals to communications devices, e.g., wireless terminals. Second wireless interface <NUM> may support Bluetooth® interface which includes receiver <NUM> coupled to receive antenna <NUM>, via which the access point may receive wireless signals from communications devices, e.g., wireless terminals, and transmitter <NUM> coupled to transmit antenna <NUM> via which the access point may transmit wireless signals to communications devices, e.g., wireless terminals.

Memory <NUM> includes routines <NUM> and data/information <NUM>. Routines <NUM> include assembly of modules <NUM>, e.g., an assembly of software modules, and an Application Programming Interface (API) <NUM>. Data/information <NUM> includes configuration information <NUM>, message event stream capture <NUM> and collection of remedial actions <NUM> to be taken in case of discovery of abnormal message flows.

<FIG> illustrates an example network management and fault detection system <NUM>, e.g., a wireless system monitoring and fault detection server, in accordance with an embodiment. In some embodiments, network monitoring and fault detection system <NUM> of <FIG> is network management system (NMS) <NUM> of <FIG>. Network management system <NUM> includes a communications interface <NUM>, e.g., an Ethernet interface, a processor <NUM>, an output device <NUM>, e.g., display, printer, etc., an input device <NUM>, e.g., keyboard, keypad, touch screen, mouse, etc., a memory <NUM> and an assembly of modules <NUM>, e.g., assembly of hardware module, e.g., assembly of circuits, coupled together via a bus <NUM> over which the various elements may interchange data and information. Communications interface <NUM> couples the network monitoring and fault detection system <NUM> to a network and/or the Internet. Communications interface <NUM> includes a receiver <NUM> via which the network monitoring system can receive data and information, e.g., including RSSIs from the various APs, the number of WTs associated with each AP, counts from internal counters of APs etc., and a transmitter <NUM>, via which the network monitoring system <NUM> can send data and information, e.g., including configuration information, and confirm receipt of information from other devices of the network.

Memory <NUM> includes routines <NUM> and data/information <NUM>. Routines <NUM> include assembly of modules <NUM>, e.g., an assembly of software modules.

Memory <NUM> includes routines <NUM> and data/information <NUM>. Routines <NUM> include assembly of modules <NUM>, e.g., an assembly of software modules, and Application Programming Interface (API) <NUM>. Data/information <NUM> includes configuration information <NUM>, peer neighbors for each AP <NUM>, count of WT associated with each AP <NUM>, count of internal counters Rx for each AP, and a other activity indicators, e.g., number of bytes sent by each AP <NUM>.

Memory module <NUM> includes also activity statistics module <NUM>. Module <NUM> includes also multiple activity time series <NUM>,. <NUM>, of historical recorded activity measurements. For example, activity measurements can include but are not limited to number of clients associated with each AP, count of Rx counter from each AP, number of bytes received by each AP from associated WTs, etc. The configuration model <NUM> includes, among other, parameters that are used to map the time series e.g., 351a,. , 353a into activity indication series e.g., 351b,.

Routine <NUM> use the time series and the activity time series associated with each AP and its peers to determine whether AP inactivity is indicative of faulty AP or just an indicator of low network activity, e.g., wireless activity, in the vicinity close to the AP whose health is being assessed.

<FIG> illustrates an example node server <NUM>, e.g., AA server, DHCP server, DNS server, Web server, etc. In some embodiments, node server <NUM> of <FIG> is server <NUM>, <NUM>, <NUM>, <NUM>, of <FIG>. Node server <NUM> includes a communications interface <NUM>, e.g., an Ethernet interface, a processor <NUM>, an output device <NUM>, e.g., display, printer, etc., an input device <NUM>, e.g., keyboard, keypad, touch screen, mouse, etc., a memory <NUM> and an assembly of modules <NUM>, e.g., assembly of hardware module, e.g., assembly of circuits, coupled together via a bus <NUM> over which the various elements may interchange data and information. Communications interface <NUM> couples the network monitoring system <NUM> to a network and/or the Internet. Communications interface <NUM> includes a receiver <NUM> via which the node server can receive data and information, e.g., including operation related information, e.g., registration request, AA services, DHCP requests, Simple Notification Service (SNS) look-ups, and Web page requests, and a transmitter <NUM>, via which the node server <NUM> can send data and information, e.g., including configuration information, authentication information, web page data, etc..

Memory <NUM> includes routines <NUM> and data/information <NUM>. Routines <NUM> include assembly of modules <NUM>, e.g., an assembly of software modules and data information <NUM>.

<FIG> illustrates an example client such as UE <NUM> (e.g., user equipment UE <NUM><NUM>,. , UE Z <NUM>, UE <NUM>' <NUM>,. , UE Z' <NUM>) in accordance with an embodiment.

UE <NUM> includes wired interfaces <NUM>, wireless interfaces <NUM>, a processor <NUM>, e.g., a CPU, a memory <NUM>, and an assembly of modules <NUM>, e.g., assembly of hardware modules, e.g., assembly of circuits, coupled together via a bus <NUM> over which the various elements may interchange data and information. Wired interface <NUM> includes receiver <NUM> and transmitter <NUM>. The wired interface couples the UE <NUM> to a network and/or the Internet <NUM> of <FIG>.

The example wireless interface <NUM> can include cellular interface <NUM>, first wireless interface <NUM>, e.g., IEEE <NUM> WiFi interface, and a second wireless interface <NUM>, e.g., Bluetooth® interface. The cellular interface <NUM> includes a receiver <NUM> coupled to receiver antenna <NUM> via which the access point may receive wireless signals from access points, e.g., AP <NUM><NUM>,. , APX <NUM>, AP <NUM>' <NUM>,. , APX' <NUM>, and transmitter <NUM> coupled to transmit antenna <NUM> via which the access point may transmit wireless signals to APs, e.g., AP <NUM><NUM>,. , APX <NUM>, AP <NUM>' <NUM>,. , APX' <NUM>. First wireless interfaces <NUM> may support a Wi-Fi interface, e.g. IEEE <NUM> interface, includes receiver <NUM> coupled to receive antenna <NUM>, via which the UE may receive wireless signals from communications devices, e.g., APs, and transmitter <NUM> coupled to transmit antenna <NUM> via which the UE may transmit wireless signals to communications devices, e.g., APs. The second wireless interface <NUM> may support Bluetooth® which includes receiver <NUM> coupled to receive antenna <NUM>, via which the UE may receive wireless signals from communications devices, e.g., APs, and transmitter <NUM> coupled to transmit antenna <NUM> via which the UE may transmit wireless signals to communications devices, e.g., APs.

Memory <NUM> includes routines <NUM> and data/information <NUM>. Routines <NUM> include assembly of modules <NUM>, e.g., an assembly of software modules. Data/information <NUM> may include configuration information as well as any additional information required for normal operations of UE <NUM>.

<FIG> is illustrative example of data structures used to determine peer neighbors.

Data <NUM> is a data structure that stores RSSI observations by an AP. Field <NUM> stores an identifier of an AP receiving signals from other APs. Field <NUM> stores a number of RSSI measurements stored in the data structure <NUM>. Field <NUM> stores an identifier of an AP generating signals received by the receiving AP (e.g. <NUM>). Field <NUM> stores a RSSI value of the signals received from the AP identified by <NUM>. Fields <NUM> and <NUM> repeat within the data structure <NUM> for each AP from which signals are received.

Data structure <NUM> provides the list of peer neighbors for each AP. Data <NUM> indicates the AP whose peers are being assessed. Data <NUM> provides the number of peers associated with AP1. In some cases, the number is limited by the number of APs whose RSSI greater than a predetermined threshold, e.g., -75dBm. In other cases, the number is limited, for sake of reducing the amount of computation, to a predetermined threshold, e.g., <NUM>. In this case the system determines the peers APs to be the APs from which the RSSI is the strongest. Data <NUM> provides a list of "Count <NUM>" (e.g. indicated by <NUM>) APs that have the strongest RSSIs.

<FIG> is a diagram showing processing of operational parameters values in some of the disclosed embodiments. <FIG> shows a time series <NUM> of operational parameter measurements or values V1-V24 of a network device over a sequence of corresponding time periods <NUM> identified as times T1-T24. The operational parameter may indicate a number of wireless devices associated with or otherwise in communication with the network device, or indicate a count of a packets or messages received and/or transmitted by the network device. In some embodiments, the processing of network parameter values illustrated in <FIG> is repeated for multiple types of operational parameter values (e.g. count of associated devices and receive counts, and/or additional operational network parameters).

Some of the disclosed embodiments determine activity indications of the network device. As discussed in more detail below, the determination of activity indications is based on a criterion. In some embodiments, if a value (e.g. any of V1-V24) is below a threshold, the activity indication indicates a first state of the network device (e.g. "active") and otherwise the activity indication is set to indicate a second state of the network device (e.g. "inactive). These activity indications are illustrated in <FIG> via activity indication time series <NUM>, including indications I1-I24. Each numbered activity indication is derived from a corresponding equivalently numbered operational parameter measurement (e.g. I24 derived from V24, etc.). Some of the disclosed embodiments then quantify a plurality of the activity indications to generate a single quantified activity indication. Quantified activity indications are shown as a time series <NUM>, including QI1-QI4. Each quantified activity indications represents activity of the network device during a period of time, represented in <FIG> as QT1-QT4. Note that each of the quantization periods QT1-QT4 include multiple operational parameter values. Thus, <FIG> illustrates that a sampling frequency of operational parameter values exceeds the quantization time period, at least in some embodiments. While <FIG> shows the quantization of activity indications from time series <NUM> to series <NUM>, some embodiments do not quantify a plurality of activity indications into a single indication. In these embodiments, characterizations of the operational parameter values are based on time series <NUM>.

As discussed above, some embodiments characterize the operational parameter of the device based on the activity indications <NUM> or quantized activity indications <NUM>. For example, some embodiments generate a moving average of either activity indications <NUM> or <NUM>. Example moving averages are illustrated by MA1-MA3 in <FIG>. MA1 is based on QI1 and QI2. MA2 is based on QI2 and QI3. MA3 is based on QI3 and QI4. The moving averages illustrated in <FIG> are provided to a machine learning model is some embodiments. Some embodiments determine a maximum contiguous duration in which the activity indications indicate inactivity. In some embodiments, the maximum contiguous duration is determined based on indications <NUM>. In other embodiments, the maximum contiguous duration is determined based on indications <NUM>. Some embodiments provide the maximum contiguous duration to the machine learning model.

<FIG> is a flowchart illustrating an example embodiment of process <NUM> by which a behavior model is established and used. In some embodiments, one or more of the functions discussed below with respect to <FIG> are performed by hardware processing circuitry (e.g. <NUM>). In some embodiments, instructions (e.g. <NUM>) stored in a memory (e.g. <NUM>) that when executed, configure the hardware processing circuitry (e.g. <NUM>) to perform one or more of the functions discussed below.

The process starts in step <NUM> and proceeds to step <NUM> where the system identifies a device, e.g., an AP, whose health is at question. For example, the system attempts to identify whether the transmitter of an AP if operational, determine whether the activity within the network is properly distributed among neighboring devices/APs, etc. The method continues to step <NUM> wherein measurements are collected by the device whose health is being assessed; the measurements are then sent to the network management system, such as server <NUM> of <FIG>, for storage and further assessment.

The process proceeds to step <NUM> wherein the network management system identifies the peer devices, e.g., peer APs, of the AP whose health is being assessed. The peer devices are devices that the AP under assessment receives their signal with RSSI greater than a predetermined RSSI. Once the peer devices are identified, the system, in step <NUM>, collects measurements of indicators related to activity of these peer devices.

The process proceeds to step <NUM> wherein the activity related measurements collected in step <NUM> are compared against predetermined thresholds resulting in statistics indicative of the estimated level of activity of AP whose health is being assessed. Similarly, in step <NUM> the activities related measurements collected in step <NUM> are compared against predetermined thresholds resulting in statistics indicative of the estimated level of activity of the peers of the AP whose health is being assessed.

The process proceeds to step <NUM> wherein the system analyzes the time series related to the activities of the AP whose health is being assesses as well as the time series of its peers, resulting in additional estimators of the levels activities of these devices.

The process proceeds to step <NUM> wherein a set of rules is used to process the activity related statistics for the AP whose health is estimated as well as the activity related statistics of the peers of the said AP. In accordance with first embodiment, each one of the different activity indicators is compared against an associated threshold resulting in activity indicators for the AP whose health is being assessed as well as activity indicators for its peers (e.g., see rules <NUM> through rule <NUM>). In accordance with a second embodiment, the ruled are examined collectively to against a specific threshold. In accordance with a third embodiment, the estimated level of activity level of the device whose health is measured is compared against the level of activity of its peers. If the level of a specific device is much different than the level of activities of its peers, the system flags this as an issue with the balancing algorithms, e.g., roaming algorithms, and changes the roaming criteria between the device whose health is being assessed and its peers.

The process proceeds to step <NUM> wherein the system determined whether the conditions examined in step <NUM> are met. If the method in step <NUM> determines that the rules R1through R5 have been met, or in other words the AP whose health is examined is not active while its peers show activity, the system in step <NUM> deems the AP to be faulty. Otherwise, the process moves to step <NUM> where the AP is deemed to be functional. Similarly, in accordance with a second embodiment, step <NUM> determines whether the combined vector of the activity statistics of the AP whose health is being assessed and the activity statistics of its peers is within a predetermined volume. If the system determines that the combined activity vector is within the predefined volume, the said AP is declared to be faulty in step <NUM>. Otherwise, in step <NUM> the said AP is declared to be operational.

Returning to step <NUM>, in addition to marking the AP as faulty, the method proceeds to step <NUM> wherein the fault detection server and/or the network management server, e.g., <NUM> of <FIG>, invokes a corrective action such as restarting the faulty AP in an attempt to mitigate the issue, notifying a technician, etc..

<FIG> is a flowchart of a process for determining whether a network component is operational. In some embodiments, one or more of the operations discussed below with respect to <FIG> are performed by hardware processing circuitry (e.g. <NUM>). For example, instructions (e.g. <NUM>) stored in a memory (e.g. <NUM>) configure the hardware processing circuitry to perform one or more of the operations discussed below with respect to <FIG> and process <NUM>. In some embodiments, process <NUM> is performed by the network management system <NUM>. In operation <NUM>, first indications of activity are determined for a subject device. Operation <NUM> includes, in some embodiments, obtaining operational parameter values of the subject device. For example, the operational parameter values may be received via a network connection between the operational device and a network management device. As discussed above, the operational parameters may include one or more of a count of a packets or messages received by the subject device during a predetermined time period, or a number of wireless devices in communication with, or associated with (e.g. association between a station and an access point) with the subject device during the predetermined time period.

The operational parameter values are characterized in various embodiments. In some embodiments, the operational parameter values are binarized into indications of whether the subject device is active (or operational) or inactive (or non-operational) during a time period. The binarization is based on a threshold specific to the operational parameter (e.g. receive count or # of associated devices). Since the operational parameter values are periodically collected over time, operation <NUM> generates a time series of binarized indications of activity or inactivity. In some aspects, the time series is further quantized to reduce the number of activity indications included in the time series. For example, in some embodiments, process <NUM> is applied to the generated time series of operation <NUM>.

A moving average of these activity indications are determined in some embodiments. A maximum contiguous period or duration of inactivity indications within the collection time period is also determined in some embodiments.

In operation <NUM>, second indications of activity are determined for one or more neighboring devices of the subject device. Operation <NUM> includes, in some embodiments, obtaining operational parameter values of each of the neighboring devices. For example, in some embodiments, the operational parameter values are received via a network connection between each neighboring device and a network management device. As discussed above, in some embodiments, the operational parameter values represent one or more of a count of a packets or messages received by each of the neighbor (peer) device(s) during a predetermined time period, or a number of wireless devices in communication with, or associated with (e.g. association between a station (e.g., WT or UE) and an access point) the respective neighboring device during the predetermined time period.

Similar to the first operational parameter values, the second operational parameters are characterized in various embodiments. In some embodiments, the second operational parameters are used to determine indications of whether the respective neighboring device is active (or operational) or inactive (or non-operational). The determination is based on a criterion specific to the operational parameter (e.g. receive count or # of associated devices). Since, in some embodiments, the second operational parameter values are periodically collected over time. In these embodiments, operation <NUM> generates a time series of indications of activity or inactivity for each neighboring device. In some embodiments, each of these generated time series is quantized to reduce the number of, or summarize, the individual activity determinations that are each based on a single operational parameter value. For example, in some embodiments, operation <NUM> utilizes process <NUM>, described below, to quantize each time series of activity indications for a neighboring device, thus reducing the number of activity indications representing the neighboring device for a time period.

In some embodiments, when there are multiple time series of activity indications for corresponding multiple peer/neighboring devices, the multiple time series are averaged or otherwise aggregated in some embodiments into a single time series collectively representing the neighboring devices of the subject device. A moving average of these aggregated binarized time series are determined in some embodiments. This results in another time series of moving averages.

Operation <NUM> determines whether the subject device is operational. The determination is made based on the first and second indications. In some embodiments, this determination is based on one or more of the characterizations of the first operational parameters and one or more of the characterizations of the second operational parameters discussed above. In some embodiments these characterizations are provided to a machine learning model, and the determination is based on an output of the machine learning model, as described above.

In operation <NUM>, the subject device is conditionally controlled based on the determination of operation <NUM>. In some embodiments, if the subject device is operational, no control inputs are provided to the subject device. In some embodiments, if the subject device is determined to be non-operational, the subject device may be restarted, powered down, or reset. In some embodiments, the subject device is conditionally controlled by installing a different version of firmware, bios, or software to the subject device (e.g. different than a previous version installed on the subject device when the operational parameters were determined). In some embodiments, if the subject device is determined to be non-operational one or more alerts are generated. The alerts may be generated via any means known in the art, including email, text, pager, or other messaging technology. In some embodiments, an alert generated by operation <NUM> functions to notify a human IT technician, who may provide manual intervention to return the device to an operable status.

<FIG> is a flowchart of a process <NUM> for determining whether a network component is operational. In some embodiments, one or more of the operations discussed below with respect to <FIG> are performed by hardware processing circuitry (e.g. <NUM>). For example, instructions (e.g. <NUM>) stored in a memory (e.g. <NUM>) configure the hardware processing circuitry to perform one or more of the operations discussed below with respect to <FIG>. The operations of <FIG> below are discussed with respect to a single operational parameter. However, one of skill would understand that process <NUM> could be repeated in some embodiments for multiple different types of operational parameters. For example, some embodiments perform process <NUM> for at least a counter of received packets or messages and a count of a number of wireless devices associated with or in communication with a subject device (e.g. APi as discussed above). Process <NUM> may be further repeated for additional operational parameters considered by the disclosed embodiments.

After start operation <NUM>, process <NUM> moves to operation <NUM>. In operation <NUM>, a first time series of operational parameters values of a device are determined. For example, as discussed above, a network device can include diagnostic capabilities that provide for collection of various statistics, including, for example, a count of a number of packets or message received and/or transmitted, a number of devices in communication with or associated with the network device, memory usage, CPU utilization, or other operational parameters. The operational parameters are collected multiple times from the network device, in some embodiments, periodically, so as to create a time series of operational parameter values.

In operation <NUM>, a second time series of activity indications are generated. The second time series is generated based on the first time series and based on a criterion. For example, in some embodiments, the criterion compares each value in the first time series to a threshold. Based on the comparison, in some embodiments, each value in the first time series in binarized into one of two possible values. One of the values indicates activity of the device, while a second of the binary values indicates a lack of activity by the device. As one example, a low number of received packets may indicate, in some embodiments, that a device is not active. In some embodiments, a very high number of received packets can also indicate inactivity or a faulty device. The values of the second time series generated in operation <NUM> indicate inactivity or activity of the device during the time period in which the corresponding operational parameter value in the first time series was collected.

Operation <NUM> determines a maximum duration of contiguous inactivity indications in the values of the second time series. The maximum duration can be represented in number of indications or elapsed time of the contiguous inactivity.

Operation <NUM> determines a percentage of activity indications in the second time series that indicate activity. Alternative embodiments determine a percentage of activity indications in the second time series that indicate inactivity.

Operation <NUM> determines a moving average of the second time series of activity indications. The moving average relies on a window of indications used to compute the moving average, which may be any number of indications between e.g., two (<NUM>) and one hundred (<NUM>) measurements, or any number. The moving average also relies on a number of measurements that overlap between sequential moving average computations. The number of overlapping measurements (or non-overlapping measurements) can also vary by embodiment. For example, one non-overlapping measurement may exist between sequential moving average measurements in some embodiments, but other numbers are contemplated.

In operation <NUM>, a determining is made as to whether the device is operational or not. The determination is based on one or more of the duration, percentage of activity indications (percentage of inactivity indications), or the moving average. As discussed above, one or more of these characterizations of the operational parameter are provided to a machine learning model in some embodiments, and the determination of operational status of the device is based on an output of the machine learning model. After operation <NUM>, process <NUM> moves to end state <NUM>.

<FIG> is a flowchart of a process <NUM> for determining whether a network component is operational. In some embodiments, one or more of the operations discussed below with respect to <FIG> are performed by hardware processing circuitry (e.g. <NUM>). For example, instructions (e.g. <NUM>) stored in a memory (e.g. <NUM>) configure the hardware processing circuitry to perform one or more of the operations discussed below with respect to <FIG>.

After start operation <NUM>, process <NUM> moves to operation <NUM>. In operation <NUM>, a first plurality of time series of operational parameters values for a corresponding plurality of peer devices of a subject device are determined. For example, as discussed above, a device subject to a determination of operability (e.g. APi) may be within a proximity of other devices (peer or neighboring devices). This proximity is determined, in various aspects, based on visibility of signals emitted by the neighboring device(s) and received at the subject device (or vis-versa). Operational parameters are collected from those peer devices in operation <NUM>. The operational parameters may include counter(s) of a number of packets received and/or sent by each of the respective peer devices, and/or a number of wireless devices associated with each of the peer devices. Other operational parameters are also contemplated, such as a number of packet errors, network jitter measurements, latency, throughout, or other statistics. This statistical information about each of the peer devices can be obtained, in at least some embodiments, from diagnostic capabilities built into each of the peer devices. In some cases, the peer devices include hardware that maintains such statistical information. In other embodiments, the information is maintained via firmware or software-based implementations. In some embodiments, the operational parameters of each peer device are collected multiple times from the peer device, in some embodiments, periodically, so as to create a time series of operational parameter values (e.g. a single time series in the first plurality of time series).

In operation <NUM>, a second plurality of time series corresponding to each of the peer or neighboring devices discussed above with respect to operation <NUM> is generated. Each of the time series in the second plurality is comprised of values that indicate activity of the respective neighboring device. Each time series in the second plurality is based on a corresponding time series in the first plurality. (e.g. a first time series of operational parameter values of a first peer device is used to generate a corresponding second time series in the second plurality). In some embodiments, the indications of activity are determined by applying one or more criterion to the values of the corresponding first time series of operation <NUM>. For example, operation <NUM> may compare each of the values in a time series of the first plurality to a predetermined threshold and based on the results of the comparison, sets a corresponding value in a time series of the second plurality of time series. In some embodiments, operation <NUM> binarizes, based on the one or more criterion, values in the first plurality of time series to generate the second plurality of time series.

In operation <NUM>, corresponding values in the second plurality of time series are aggregated to generate a third time series. In some embodiments, the aggregation averages the corresponding values. Alternatively, a median of the corresponding values may be used for aggregation.

In operation <NUM>, a moving average of the third time series of activity information is determined. The moving average window size and/or overlap size (within the window) may vary by embodiments. Some embodiments use a window size of two activity indications. In other words, two activity indications are used to define each moving average in these embodiments. Some embodiments use an overlap size of (window size - <NUM>).

Operation <NUM> determines whether the subject device is operational based on the moving average. As discussed above, in some embodiments, one or more characterizations of the peer AP operational parameters may be used to make the determination. In some embodiments, these characterizations are provided to a machine learning model, and an output of the machine learning model is used to make the operational determination.

<FIG> is a flowchart of a process <NUM> for quantizing operational parameter measurements. In some embodiments, one or more of the operations discussed below with respect to <FIG> are performed by hardware processing circuitry (e.g. <NUM>). For example, instructions (e.g. <NUM>) stored in a memory (e.g. <NUM>) configure the hardware processing circuitry to perform one or more of the operations discussed below with respect to <FIG>. Process <NUM> of <FIG> is used in some embodiments to reduce a first number of operational parameter measurements to a smaller number of activity indications.

After start operation <NUM>, process <NUM> moves to operation <NUM>, which obtains a plurality of activity indications of a device over a first time period. For example, as discussed above with respect to operations <NUM> and <NUM>, some embodiments determine a plurality of activity determinations based on a corresponding plurality of operational parameter values. Each of these pluralities can represent a time series in at least some embodiments, in that each operational parameter measurement and/or activity determination represents a state of the network device within a discrete period of time, and the pluralities are organized by time in at least some embodiments. Thus, operation <NUM> obtains the plurality of activity indications from, in some embodiments, operations <NUM> or <NUM>.

In operation <NUM>, the plurality of activity indications include a plurality of portions. Each portion represents an equivalent amount of elapsed time (e.g. ten minutes). Thus, collectively the plurality of activity indications of operation <NUM> represent a period of time that is an aggregation of elapsed times represented by each portion. Each of the portions is quantized into a single indicator of activity. The quantization is based on a criterion. In some aspects, the criterion compares a number of activity indications in the portion that indicate a particular activity value (e.g. active or inactive), and set the single indicator based on the number. In some embodiments, if the number meets a criterion (e.g. greater than a quantization threshold), the single indicator is set to a first value and otherwise is set to a second value.

In operation <NUM>, a second plurality of quantized activity indications is generated based on the plurality of portions. The second plurality includes a single activity indicator for each portion included in the first plurality of activity indications. In some embodiments, the second plurality of quantized activity indications are used by process <NUM> of <FIG>, process <NUM> of <FIG>, and/or process <NUM> of <FIG>.

<FIG> shows an example machine learning module <NUM> according to some examples of the present disclosure. Machine learning module <NUM> utilizes a training module <NUM> and a prediction module <NUM>. Training module <NUM> inputs historical information <NUM> into feature determination module 1250a. The historical information includes information derived from one or more network devices. In various embodiments, the historical information includes one or more of operational parameter values as discussed above. The historical information <NUM> may be labeled. Labels may indicate whether a subject network device was operational or not during the time in which operational parameter values or characterizations of same, associated with the label, were measured or otherwise recorded.

In some embodiments, the machine learning module <NUM> described below with respect to <FIG> is invoked as part of process <NUM>, discussed above with respect to <FIG>. In some embodiments, the prediction module <NUM> is performed as part of process <NUM>, and the training module <NUM> is performed prior to execution of process <NUM>. In some embodiments, one or more functions discussed below with respect to the machine learning module <NUM> are executed by the network management system <NUM>.

Feature determination module 1250a determines one or more features <NUM> from this historical information <NUM>. Stated generally, features <NUM> are a set of the information input and is information determined to be predictive of a particular outcome. For example, the features can include, in various embodiments, one or more characterizations of the operational parameter values included in the historical information. This may include, for example, such as activity indications, quantized activity indications, moving averages of the activity indications, and/or maximum continuous durations of inactive indications. The machine learning algorithm <NUM> produces a model <NUM> based upon the features <NUM> and the associated labels.

In the prediction module <NUM>, current information <NUM> may be input to the feature determination module <NUM>. For example, operational parameter values and/or characterizations of same of a subject network device and/or neighbor or peer devices of the subject network device are included in the current information. Feature determination module 1250b may determine the same set of features or a different set of features (e.g. characterizations of operational parameter values) from the current information <NUM> as feature determination module 1250a determined from historical information <NUM>. In some examples, feature determination module 1250a and 1250b are the same module. Feature determination module 1250b produces feature vector <NUM>, which is input into the model <NUM> to generate an indication of operational status of the subject network device <NUM>. The training module <NUM> may operate in an offline manner to train the model <NUM>. The prediction module <NUM>, however, may be designed to operate in an online manner. It should be noted that the model <NUM> may be periodically updated via additional training and/or user feedback.

The machine learning algorithm <NUM> may be selected from among many different potential supervised or unsupervised machine learning algorithms. Examples of supervised learning algorithms include artificial neural networks, Bayesian networks, instance-based learning, support vector machines, decision trees (e.g., Iterative Dichotomiser <NUM>, C4. <NUM>, Classification and Regression Tree (CART), Chi-squared Automatic Interaction Detector (CHAID), and the like), random forests, linear classifiers, quadratic classifiers, k-nearest neighbor, linear regression, logistic regression, hidden Markov models, models based on artificial life, simulated annealing, and/or virology. Examples of unsupervised learning algorithms include expectation-maximization algorithms, vector quantization, and information bottleneck method. Unsupervised models may not have a training module <NUM>. In an example embodiment, a regression model is used and the model <NUM> is a vector of coefficients corresponding to a learned importance for each of the features in the vector of features <NUM>, <NUM>. To calculate a score, a dot product of the feature vector <NUM> and the vector of coefficients of the model <NUM> is taken in some embodiments.

While the above-described flowcharts have been discussed in relation to a particular sequence of events, it should be appreciated that changes to this sequence can occur without materially effecting the operation of the embodiment(s). Additionally, the various techniques illustrated herein are not limited to the specifically illustrated embodiments but can also be utilized with the other examples and embodiments and each described feature is individually and separately claimable.

The above-described system can be implemented on a wireless telecommunications device(s)/system, such an IEEE <NUM> transceiver, or the like. Examples of wireless protocols that can be used with this technology include IEEE <NUM>. 11a, IEEE <NUM>. 11b, IEEE <NUM>, IEEE <NUM>. 11n, IEEE <NUM>. 11ac, IEEE <NUM>. 11ad, IEEE <NUM>. 11af, IEEE <NUM>. 11ah, IEEE <NUM>. 11ai, IEEE <NUM>. 11aj, IEEE <NUM>. 11aq, IEEE <NUM>. 11ax, Wi-Fi, LTE, <NUM>, Bluetooth®, WirelessHD, WiGig, WiGi, 3GPP, Wireless LAN, WiMAX, DensiFi SIG, Unifi SIG, 3GPP LAA (licensed-assisted access), and the like.

Additionally, the systems, methods and protocols can be implemented to improve one or more of a special purpose computer, a programmed microprocessor or microcontroller and peripheral integrated circuit element(s), an ASIC or other integrated circuit, a digital signal processor, a hard-wired electronic or logic circuit such as discrete element circuit, a programmable logic device such as PLD, PLA, FPGA, PAL, a modem, a transmitter/receiver, any comparable means, or the like. In general, any device capable of implementing a state machine that is in turn capable of implementing the methodology illustrated herein can benefit from the various communication methods, protocols and techniques according to the disclosure provided herein.

Examples of the processors as described herein may include, but are not limited to, at least one of Qualcomm® Snapdragon® <NUM> and <NUM>, Qualcomm® Snapdragon® <NUM> and <NUM> with <NUM> LTE Integration and <NUM>-bit computing, Apple® A7 processor with <NUM>-bit architecture, Apple® M7 motion coprocessors, Samsung® Exynos® series, the Intel® Core™ family of processors, the Intel® Xeon® family of processors, the Intel® Atom™ family of processors, the Intel Itanium® family of processors, Intel® Core® i5-<NUM> and i7-<NUM> <NUM> Haswell, Intel® Core® i5-<NUM> <NUM> Ivy Bridge, the AMD® FX™ family of processors, AMD® FX-<NUM>, FX-<NUM>, and FX-<NUM><NUM> Vishera, AMD® Kaveri processors, Texas Instruments® Jacinto C6000™ automotive infotainment processors, Texas Instruments® OMAP™ automotive-grade mobile processors, ARM® Cortex™-M processors, ARM® Cortex-A and ARM926EJ-S™ processors, Broadcom® AirForce BCM4704/BCM4703 wireless networking processors, the AR7100 Wireless Network Processing Unit, other industry-equivalent processors, and may perform computational functions using any known or future-developed standard, instruction set, libraries, and/or architecture.

Furthermore, the disclosed methods may be readily implemented in software using object or object-oriented software development environments that provide portable source code that can be used on a variety of computer or workstation platforms. Alternatively, the disclosed system may be implemented partially or fully in hardware using standard logic circuits or VLSI design. Whether software or hardware is used to implement the systems in accordance with the embodiments is dependent on the speed and/or efficiency requirements of the system, the particular function, and the particular software or hardware systems or microprocessor or microcomputer systems being utilized. The communication systems, methods and protocols illustrated herein can be readily implemented in hardware and/or software using any known or later developed systems or structures, devices and/or software by those of ordinary skill in the applicable art from the functional description provided herein and with a general basic knowledge of the computer and telecommunications arts.

Moreover, the disclosed methods may be readily implemented in software and/or firmware that can be carried by a computer readable medium, such as transmitted by a carrier medium or stored on a storage medium to improve the performance of: a programmed general-purpose computer with the cooperation of a controller and memory, a special purpose computer, a microprocessor, or the like. In these instances, the systems and methods can be implemented as program embedded on personal computer such as an applet, JAVA. or CGI script, as a resource residing on a server or computer workstation, as a routine embedded in a dedicated communication system or system component, or the like. The system can also be implemented by physically incorporating the system and/or method into a software and/or hardware system, such as the hardware and software systems of a communications transceiver.

Claim 1:
A method to determine whether a network device is operational, the method comprising:
determining (<NUM>), by one or more hardware processors of a network management system, first operational parameter values of the network device;
determining, by the one or more hardware processors, one or more neighboring network devices of the network device;
determining (<NUM>), by the one or more hardware processors, second operational parameter values of the one or more neighboring network devices, wherein the second operational parameter values of the one or more neighboring network devices indicate a count of messages received at a respective neighboring network device or a number of wireless terminals associated with the respective neighboring network device;
determining (<NUM>), by the one or more hardware processors, whether the network device is operational based on the first operational parameter values of the network device and the second operational parameter values of the one or more neighboring network devices; and
conditionally controlling (<NUM>), by the one or more hardware processors, the network device based on whether the network device is determined to be operational.