CN107820253B

CN107820253B - Method and apparatus for simultaneous use of multiple channels in a dynamic frequency selective band in a wireless network

Info

Publication number: CN107820253B
Application number: CN201710824448.9A
Authority: CN
Inventors: K·T·蔡; T·F·K·努; S·B·李; E·库尔尼亚阮
Original assignee: CHENGDU SKSPRUCE TECHNOLOGY Inc
Current assignee: CHENGDU SKSPRUCE TECHNOLOGY, Inc.
Priority date: 2016-09-13
Filing date: 2017-09-13
Publication date: 2022-01-14
Anticipated expiration: 2037-09-13
Also published as: CN107820253A

Abstract

The present invention relates to wireless networks, and more particularly to a system and method for selecting an available channel from a plurality of 5GHz radio frequency channels that is free of radar signals. In non-limiting embodiments, exemplary systems, methods, and apparatus are provided that may facilitate reducing error detection and/or network downtime in an exemplary mesh network employing Dynamic Frequency Selection (DFS) channels. In a non-limiting aspect, radar information including location information may be communicated between example mesh nodes to facilitate reducing false detections and/or network downtime in an example mesh network. Additionally, in further non-limiting aspects, exemplary embodiments may send signals for stopping discrimination and false detection of one or more DFS channels and/or cooperative grid node identification and/or radar signals, in addition to other non-limiting aspects provided.

Description

Method and apparatus for simultaneous use of multiple channels in a dynamic frequency selective band in a wireless network

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part application filed on day 22/10/2015 AND entitled U.S. patent application No. 14/920,568 entitled METHOD AND APPARATUS FOR USE OF simple SELECTION BAND IN WIRELESS network, filed on day 10/2015, which in turn claims priority to U.S. provisional patent application No. 62/200,764 entitled METHOD AND APPARATUS FOR simple SELECTION BAND IN WIRELESS network filed on day 4/2015, the entire disclosure OF which is incorporated herein by reference. This application is also a continuation-in-part application AND claims priority from U.S. patent application No. 15/171,911 entitled "METHOD AND APPARATUS FOR INTEGRATING radiation AGENT DATA IN METHOD AND No. DYNAMIC CHANNEL SELECTION IN WIRELESS NETWORKs," filed on day 6, month 2, 2016, U.S. patent application No. 15/214,437 entitled "CLOUD DFS SUPER MASTER SYSTEMS AND METHODS," filed on day 6, month 2, 2016, AND/or their corresponding provisional applications, the entire disclosures OF which are incorporated herein by reference. In addition, this application is a continuation-in-part application AND claims priority from U.S. patent application 15/259,359, entitled "METHOD AND APPARATUS FOR PROVIDING SPECTRUM ACCESS IN PEER-TO-PEER WIRELESS NETWORKS", filed on 8.9.2016, which in turn claims priority from U.S. provisional patent application 62/314,042, entitled "METHOD AND APPARATUS FOR PROVIDING DYNAMIC FREQUENCY SELECTION SPECTRUM ACCESS IN PEER-TO-PEER WIRELESS NETWORKS", filed on 28.3.2016, the entire disclosure of which is incorporated herein by reference.

Technical Field

The present invention relates to wireless networks, and more particularly to a system and method for selecting an available channel of unoccupied signals from among a plurality of radio frequency channels.

Background

Embodiments of the present invention provide methods and systems for utilizing licensed and unlicensed frequency bands requiring radar detection and other occupied signal detection, such as Dynamic Frequency Selection (DFS) channels in unlicensed national information infrastructure (U-NII) bands, to achieve additional bandwidth for 802.11ac/n and LTE in unlicensed spectrum (LTE-U) networks employing wireless flexible proxies.

Wi-Fi networks are vital to today's portable modern life. Wi-Fi is the preferred network in the growing internet of things (IoT). However, the technology behind Wi-Fi has at present changed little over the past decade. Wi-Fi networks and associated unlicensed spectrum are currently managed in an inefficient manner. For example, there is little or no coordination between personal networks and devices from different manufacturers. Such networks typically employ basic control algorithms that assume that the network consists of "self-managed islands", which is a concept originally intended for use in low-density and low-traffic environments. The situation is worse with home networks, which are combined in a completely chaotic ad hoc fashion. Furthermore, as more and more connected devices become more prevalent, the end result is more and more congestion and network connection speeds becoming slower.

Similarly, LTE-U networks operating in the same or similar unlicensed frequency bands as 802.11 ac/n Wi-Fi suffer from similar congestion and unreliable connection problems, and will often create congestion problems for existing Wi-Fi networks sharing the same channel. The additional bandwidth and better and more efficient utilization of the spectrum are key to maintaining the usefulness of a rapidly growing wireless network connecting Wi-Fi and LTE-U networks in the world.

Devices operating in certain portions of the 5GHz U-NII-2 band (referred to as DFS channels) require active radar detection. This function is assigned to a device capable of detecting radar, called a DFS master device (usually an access point or router). After the channel availability check, the DFS master actively scans the DFS channels and performs Channel Availability Check (CAC) and periodic in-service monitoring (ISM). The channel availability check lasts 60 seconds as required by FCC part 15 subsection E and the ETSI 301893 standard. The DFS master device sends signals to other devices (typically client devices) in the network by sending DFS beacons indicating that the channel is radar-free. While the access point can detect radar, the wireless client is typically not. Therefore, the wireless client must first passively scan the DFS channel to detect the presence of a beacon on that particular channel. During passive scanning, the client device switches through the channel and listens for beacons transmitted by the access point at regular intervals on the available channel.

When a beacon is detected, the client is allowed to actively scan the channel. If the DFS master detects radar in the channel, the DFS master no longer transmits beacons, and all client devices that do not perceive beacons for a specified time must immediately leave the channel and keep the channel closed for 30 minutes. For clients associated with the DFS master network, additional information in the beacon (i.e., channel switch notification) may trigger a fast and controllable vacation of the channel. In general, a DFS master is an access point with only one radio and is able to provide DFS master services for only a single channel. A significant problem with this approach is that in the event of a radar event or more commonly false detection, a single channel must be vacated and the ability to use the DFS channel is lost. The present invention, in at least some embodiments, identifies and solves the problem of current devices for detecting occupancy signals including current DFS devices.

Disclosure of Invention

The present invention relates to wireless networks, and more particularly, to a system and method for selecting an available channel such that a signal does not occupy multiple radio frequency channels. The present invention employs a wireless flexible proxy to access additional bandwidth for wireless networks, such as IEEE 802.11ac/n and LTE-U networks. The additional bandwidth is derived from channels that need to be avoided with channels that occupy the signal. For example, the additional bandwidth is derived from a special compliance channel (e.g., DFS channel of U-NII-2 band) that needs to employ radar detection by multi-channel radar detection and in-service monitoring and activate channel selection control.

In an embodiment, the present invention utilizes a flexible proxy employing proprietary embedded radio technologies including continuous multi-carrier spectrum monitoring, embedded computing elements employing proprietary real-time spectrum analysis algorithms, and proprietary signaling and control protocols to provide detection and continuous real-time monitoring of multiple radar types and patterns and other signals (e.g., interferers) and measurements of congestion and traffic across simultaneous multiple channels.

The present invention may also utilize cloud-based computing and control elements that, along with the wireless flexible proxy, form a separate intelligent architecture. In this architecture, embedded sensor information from flexible agents (e.g., radar detection channel availability checks and in-service monitoring along with interference, traffic, identification of neighbor devices, and other spectrum and location information) is passed to the cloud intelligence engine and integrated over time within the cloud intelligence engine. Further, embedded sensor information from a flexible agent may be fused with information from other flexible agents distributed in the space, filtered, and post-processed. The embedded sensor information from the flexible agent may be further merged with other data from other sources to provide improvements to important signal measurements and network reliability issues (e.g., augmented radar sensitivity, reduced false detection rates, and reliable discovery of hidden nodes).

In other non-limiting embodiments, exemplary systems, methods, and apparatus are provided that may employ Dynamic Frequency Selection (DFS) channels to facilitate reducing false detections and/or network downtime in an exemplary mesh network. In a non-limiting aspect, radar information including location information may be transmitted between example mesh nodes to facilitate reducing false detections and/or network downtime in an example mesh network. Further, in other non-limiting aspects, among other provided non-limiting aspects, exemplary embodiments can transmit signals to facilitate muting one or more DFS channels and/or joint grid node identification and/or differentiation of valid radar signals from false detections.

For example, an exemplary method may comprise: the method includes receiving an indication of a suspected radar event on one or more Dynamic Frequency Selection (DFS) channels in a mesh network, determining whether the suspected radar event is a valid radar event based on the suspected radar event, and transmitting radar information about the suspected radar event or the valid radar event in the mesh network to another mesh node or a cloud intelligence engine associated with the mesh network. In other non-limiting aspects, the exemplary method further comprises: sending a Clear To Send (CTS) signal or a hold signal on the DFS channel based on receiving an indication of a suspected radar event to facilitate joint identification or differentiation between valid radar signals and false detections; and/or receiving additional radar information from another mesh node or cloud intelligence engine, determining whether a suspected radar event is a valid radar event or an invalid radar event, and transmitting the information in the mesh network.

As another non-limiting example, an exemplary system may comprise: one or more radar detectors configured to receive an indication of a suspected radar event on one or more DFS channels in a mesh network; a multi-channel DFS master device configured to determine whether a suspected radar event is a valid radar event based at least in part on the suspected radar event; and one or more communication components, associated with the multi-channel DFS master device, configured to transmit radar information about a suspected radar event or a valid radar event in the mesh network to another mesh node or cloud intelligence engine associated with the mesh network. In other non-limiting aspects, the multi-channel DFS master device may be further configured to: determining whether the suspected radar event is a valid or invalid radar event (e.g., false detection) based, for example, in part, on additional radar information including location information associated with other mesh nodes or cloud intelligence engines associated with the mesh network.

Other embodiments and various examples, scenarios, and implementations are described in more detail below. The following description and the annexed drawings set forth in detail certain illustrative embodiments of the specification. These embodiments are indicative, however, of but a few of the various ways in which the principles of the specification may be employed. Other advantages and novel features of the described embodiments will become apparent from the following detailed description of the specification when considered in conjunction with the drawings.

Drawings

The above objects and advantages of this invention, and additional objects and advantages thereof, will be more fully understood herein after from the following detailed description of the preferred embodiments of the invention taken in conjunction with the accompanying drawings, in which:

FIG. 1 shows that the 5GHz Wi-Fi spectrum includes portions that require active monitoring of radar signals.

Fig. 2 illustrates how such an exemplary autonomous DFS master device can interact with a conventional hosting access point, a cloud-based smart engine, and a client device in accordance with the present invention.

Fig. 3 illustrates how an exemplary autonomous DFS master device can interact with a client device and cloud intelligence engine independent of any access point in a point-to-point network in accordance with the present invention.

Fig. 4 illustrates a method of implementing a channel availability check phase and an on-line monitoring phase in a DFS scanning operation with an autonomous DFS master using time division multiplexed sequential channel availability check followed by continuous on-line monitoring to enable simultaneous use of multiple DFS channels in the 5GHz band in accordance with the present invention.

Fig. 5 illustrates a method of implementing a channel availability check phase and an online monitoring phase in a DFS scanning operation with an autonomous DFS master using continuous sequential channel availability check followed by continuous online monitoring to enable simultaneous use of multiple DFS channels in the 5GHz band in accordance with the present invention.

Fig. 6A illustrates a method of implementing a channel availability check phase and an online monitoring phase in a DFS scanning operation using an autonomous DFS master device to enable simultaneous use of multiple DFS channels of a 5GHz band in accordance with the present invention.

Fig. 6B illustrates an exemplary beacon transmission duty cycle and an exemplary radar detection duty cycle.

Fig. 7 illustrates an embodiment of the present invention in which a flexible proxy is connected to a hosting device and to a network via the hosting device.

FIG. 8 illustrates another embodiment of the present invention in which a flexible agent connects to a host device and connects to a network and a cloud intelligence engine via the host device.

FIG. 9 illustrates another embodiment of the present invention in which a flexible agent connects to a host device and connects to a network and a cloud intelligence engine via the host device.

Fig. 10 illustrates a method of channel availability checking and online monitoring that implements the present invention.

Fig. 11 illustrates another method of implementing the channel availability check and online monitoring of the present invention.

Fig. 12 illustrates another method of channel availability checking and online monitoring that implements the present invention.

FIG. 13 illustrates a system including a cloud intelligence engine, a flexible proxy, a hosting access point, and a data source in accordance with the present invention.

Fig. 14A and 14B illustrate logical interfaces between a wireless flexible proxy, a cloud intelligence engine, and an access point (or similarly a small cell LTE-U base station).

Fig. 15 illustrates a method of determining operating channels of a plurality of multi-channel DFS masters using a cloud intelligence engine in accordance with the present invention.

Fig. 16 also illustrates an additional method of determining operating channels for a plurality of multi-channel DFS masters using a cloud intelligence engine in accordance with the present invention.

Fig. 17 shows how multiple flexible agents provide an overlapping view of the geographic distribution of radar radiation sources.

Fig. 18 shows how the cloud intelligence engine acquires spectrum data from each flexible agent in a control loop diagram and, after storing and filtering the data, combines it with similar data from multiple other flexible agents and cloud data from other sources.

Figure 19A illustrates the hidden node problem of hiding an access point or small cell base station from view from other access points or small cell base stations by terrain, obstacles, distance, or channel conditions.

Fig. 19B illustrates a hidden radar problem where the radar source is not visible to the agile agent due to terrain or obstructions.

Fig. 19C illustrates the hidden radar problem of the flexible proxy not seeing the radar source due to distance.

Fig. 20 illustrates an exemplary embodiment of a cloud DFS super-host system communicatively coupled to a plurality of sensors that detect radar signals in a DFS frequency band and detect wireless traffic information and to one or more client devices.

Figure 21 illustrates a point-to-point network for a standard non-DFS implementation.

Fig. 22 illustrates a point-to-point network and system of an exemplary DFS implementation of the invention.

Fig. 23 illustrates a point-to-point network and system of an exemplary DFS implementation of the invention.

Fig. 24 illustrates a point-to-point network and system of an exemplary DFS implementation of the invention.

Fig. 25 illustrates a point-to-point network and system of an exemplary DFS implementation of the invention.

Fig. 26 also illustrates the type of DFS peer-to-peer network implemented by the present invention.

Fig. 27 also illustrates the type of DFS peer-to-peer network implemented by the present invention.

Fig. 28 illustrates an exemplary method for providing DFS spectrum access in a peer-to-peer wireless network in accordance with the present invention.

Fig. 29 illustrates additional optional steps in a method for providing DFS spectrum access in a peer-to-peer wireless network according to the present invention.

Fig. 30 illustrates an exemplary functional block diagram of a mesh network in accordance with various non-limiting aspects described herein.

Fig. 31 illustrates another exemplary functional block diagram of a mesh network in accordance with other non-limiting aspects described herein.

Fig. 32 illustrates another exemplary functional block diagram of a mesh network in accordance with yet another non-limiting aspect described herein.

Fig. 33 illustrates an example method for reducing error detection and/or network downtime in an example mesh network employing DFS channels, in accordance with various non-limiting aspects.

Fig. 34 illustrates further non-limiting aspects of an example method for reducing error detection and/or network downtime in an example mesh network employing DFS channels.

Fig. 35 illustrates other example methods for reducing error detection and/or network downtime in an example mesh network employing DFS channels, in accordance with various non-limiting aspects.

Fig. 36 illustrates further non-limiting aspects of an example method for reducing error detection and/or network downtime in an example mesh network employing DFS channels.

Fig. 37 illustrates further non-limiting aspects of an example method for reducing error detection and/or network downtime in an example mesh network employing DFS channels.

Fig. 38 illustrates other example methods for reducing error detection and/or network downtime in an example mesh network employing DFS channels, in accordance with various non-limiting aspects.

Fig. 39 illustrates further non-limiting aspects of an example method for reducing error detection and/or network downtime in an example mesh network employing DFS channels.

Fig. 40 illustrates other exemplary methods for reducing error detection and/or network downtime based on transmitting radar and location information in an exemplary mesh network employing DFS channels, in accordance with various non-limiting aspects.

Fig. 41 illustrates other example methods for reducing error detection and/or network downtime based on employing control, management, and/or data frames in an example mesh network employing DFS channels, in accordance with various non-limiting aspects.

Fig. 42 illustrates yet another example method of reducing error detection and/or network downtime based on employing a hold signal and/or a continue signal in an example mesh network employing DFS channels, in accordance with various non-limiting aspects.

Fig. 43 illustrates other example methods for reducing error detection and/or network downtime in an example mesh network employing DFS channels, in accordance with various non-limiting aspects.

FIG. 44 illustrates a functional block diagram of an exemplary non-limiting apparatus or system suitable for use with aspects of the disclosed subject matter.

FIG. 45 illustrates an exemplary non-limiting apparatus or system suitable for implementing various aspects of the disclosed subject matter.

FIG. 46 is a block diagram representing an exemplary non-limiting network environment in which various embodiments described herein can be implemented.

FIG. 47 is a block diagram representing an exemplary non-limiting computing system or operating environment in which one or more aspects of various embodiments described herein can be implemented.

Fig. 48 illustrates a schematic diagram of an exemplary mobile device (e.g., a mobile handset, a peer device, a mesh node, etc.) that can cause various non-limiting aspects of the disclosed subject matter in accordance with embodiments described herein.

Detailed Description

The present invention relates to wireless networks, and more particularly to a system and method for selecting an available channel of unoccupied signals from among a plurality of radio frequency channels. As used herein, a channel that is "free" of occupied signals may include a channel that is occupied with signals below a signal threshold (including signal strength, number, or traffic). The present invention employs a wireless flexible proxy to access the additional bandwidth of wireless networks such as IEEE 802.11ac/n and LTE-U networks. The additional bandwidth is derived from the channel that needs to avoid occupying the signal. For example, by employing multi-channel radar detection and in-service monitoring and active channel selection control, additional bandwidth is obtained from special compliance channels that require radar detection (e.g., DFS channels of the U-NII-2 band). The DFS master actively scans the DFS channels and performs channel availability checks and performs periodic in-service monitoring after channel availability checks.

FIG. 1 shows a portion of a 5GHz Wi-Fi spectrum 101. Fig. 1 shows frequencies 102 and channels 103 that form part of a 5GHz Wi-Fi spectrum 101. The U-NII band is the FCC regulatory domain for 5GHz wireless devices and is part of the radio spectrum used by IEEE 802.11ac/n devices and many wireless ISPs. It operates over four ranges. The U-NII-1 band 105 covers the range of 5.15-5.25 GHz. The U-NII-2A band 106 covers the range of 5.25-5.35 GHz. The U-NII-2A band 106 is limited by DFS radar detection and avoidance requirements. The U-NII-2C band 107 covers the range of 5.47-5.725 GHz. The U-NII-2C band 107 is also limited by DFS radar detection and avoidance requirements. The U-NII-3 band 109 covers the range of 5.725 to 5.850 GHz. The use of the U-NII-3 band 109 is limited in some areas of the European Union, Japan, and the like.

The agility agent (agility agent) of the present invention acts as an autonomous DFS master when used in an 802.11ac/n or LTE-U wireless network. In contrast to conventional DFS master devices, the flexible proxy is not an access point or router, but rather is a standalone wireless device that employs the scanning techniques of the invention described herein, which provide DFS scanning capabilities across multiple channels, thereby enabling one or more access point devices and point-to-point client devices to utilize multiple DFS channels simultaneously. The standalone autonomous DFS master device of the present invention may be incorporated into another device, such as an access point, LTE-U host, base station, cell or small cell, media or content streamer, speaker, television, mobile phone, mobile router, software access point device, or point-to-point device, but does not itself provide network access to the client devices. In particular, enabled access points and clients or wireless devices can automatically, predictively, and quickly move to another DFS channel in the event of a radar event or false detection.

FIG. 2 provides a detailed illustration of an exemplary system of the present invention. As shown in fig. 2, a flexible proxy 200 in the role of an autonomous DFS master may control at least one access point, host access point 218, to indicate channel selection primarily by: (a) signaling the availability of one or more DFS channels by simultaneously transmitting one or more beacon signals; (b) transmitting authorized available DFS channels (herein referred to as whitelists) and forbidden DFS channels (herein referred to as blacklists) that have detected a potential radar signal along with control signals and timestamp signals (herein referred to as dead-band-switch timers) via associated non-DFS channels; (c) transmitting the same signal as (b) through a wired medium such as ethernet or a serial cable; and (d) receive control, coordination, and authorization and preferred channel selection guidance information from the cloud intelligence engine 235. The flexible proxy 200 communicates a time stamp signal or a dead-band switch timer to ensure that the access points 218, 223 do not use the information (including the white list) beyond the useful life of the information. For example, the white list is only valid for a certain period of time. The time stamp signal avoids the use of non-compliant DFS channels by ensuring that the access point does not use the white list beyond its useful life. The present invention allows currently available 5GHz access points (which cannot operate in a DFS channel) that do not require radar detection to operate in the DFS channel by providing the radar detection required by the FCC or other regulatory body.

The host access point 218 and any other access point devices 223 under the control of the autonomous DFS master device 200 typically have

control agent portions

219, 224 installed within their communication stacks.

Control agents

219, 224 are agents that act under the direction of flexible agent 200 to receive information and commands from flexible agent 200. The

control agents

219, 224 act on information from the flexible agent 200. For example, the

control agents

219, 224 listen for information such as white lists or black lists from the flexible agents. If the flexible agent 200 detects a radar signal, the flexible agent 200 passes it to the

control agents

219, 224 and the

control agents

219, 224 act to immediately evacuate the channel. The control agent may also obtain commands from flexible agent 200. For example, host access point 218 and network access point 223 may offload DFS monitoring to flexible proxy 200 as long as they can listen to flexible proxy 200 and obtain information about available DFS channels from the flexible proxy.

Host access point 218 is connected to a wide area network 233 and includes an access point control agent 219 to facilitate communications with flexible proxy 200. Access point control agent 219 includes a security module 220 and agent protocol 221 to facilitate communication with flexible agent 200, and a group communication protocol 222 to facilitate communication between the flexible agent, the access point, the client device, and other devices in the network. Flexible agent 200 is connected to cloud intelligence engine 235 via host access point 218 and wide area network 233. The access point sets up a secure tunnel to communicate with the cloud intelligence engine 235 through, for example, an encrypted control API in the host access point 218. Flexible agent 200 sends information to cloud intelligence engine 235 such as white lists, black lists, status information, location information, time signals, scan lists (e.g., showing neighboring access points), congestion (e.g., number and type of retry packets), and traffic information. Cloud intelligence engine 235 communicates information such as access point location (including neighboring access points), access point/cluster current state and history, statistics (including traffic, congestion, and throughput), white lists, black lists, authentication information, associated customer information, and regional and regulatory information to flexible proxy 200 via a secure communication tunnel. The flexible proxy 200 uses information from the cloud intelligence engine 235 to control access points and other network devices.

Flexible proxy 200 may communicate with other network components via a wired connection or wirelessly. In the illustrated example, flexible proxy 200 includes a primary radio 215 and a secondary radio 216. The master radio 215 is used for DFS and radar detection and is typically a 5GHz radio. Flexible agent 200 may receive radar signals, traffic information, and/or congestion information via primary radio 215. The flexible proxy 200 may send information such as DFS beacons via the master radio 215. The second radio 216 is a secondary radio for sending control signals to other devices in the network, and is typically a 2.4GHz radio. Flexible proxy 200 may receive information such as network traffic, congestion, and/or control signals using secondary radio 216. Flexible proxy 200 may send information, such as control signals, with secondary radio 216. The host radio 215 is connected to a fast channel switch generator 217, the fast channel switch generator 217 comprising a switch and allowing the host radio 215 to switch fast between the radar detector 211 and the beacon generator 212. Channel switch generator 217 allows radar detector 211 to switch fast enough as if on multiple channels at a time.

In one embodiment, an independent multi-channel DFS master device comprises: a beacon generator 212 for generating a beacon in each of a plurality of 5GHz radio channels; a radar detector 211 for scanning radar signals in each of a plurality of 5GHz radio channels; a 5GHz radio transceiver 215 for transmitting beacons in each of a plurality of 5GHz radio channels and receiving radar signals in each of a plurality of 5GHz radio channels; and a fast channel switch generator 217 coupled to the radar detector, the beacon generator and the 5GHz radio transceiver. The fast channel switch generator 217 switches the 5GHz radio to a first channel of the plurality of 5GHz radio channels and then causes the beacon generator 212 to generate a beacon in the first channel of the plurality of 5GHz radio channels. Fast channel switch generator 217 then causes radar detector 211 to scan for radar signals in a first channel of the plurality of 5GHz radio channels. The fast channel switch generator 217 then repeats these steps for each other of the plurality of 5GHz radio channels during the beacon transmission duty cycle, and in some examples, during the radar detection duty cycle. The beacon transmission duty cycle is the time between successive beacon transmissions on a given channel, and the radar detection duty cycle is the time between successive scans on a given channel. Because flexible agent 200 cycles between beaconing and scanning in each of multiple 5GHz radio channels in the time window between a first beaconing and scanning in a given channel and subsequent beaconing and scanning of the same channel, it may equivalently provide simultaneous beaconing and scanning for multiple channels.

Flexible proxy 200 may also contain Bluetooth radio 214 and 802.15.4 radio 213 for communicating with other devices in the network. Flexible proxy 200 may include various radio protocols 208 to facilitate communication via the included radios.

Flexible agent 200 may also include a location module 209 to geo-locate or determine the location of flexible agent 200. As shown in fig. 2, flexible proxy 200 may include a scanning and signaling module 210. The flexible agent 200 includes embedded memory 202, including, for example, flash memory 201 and embedded processor 203. Cloud agents 204 in flexible agents 200 facilitate aggregating information from cloud agents 204 over the cloud and include group communication protocols 205 to facilitate communication between the flexible agents, access points, client devices, and other devices in the network. Cloud proxy 204 also includes a security module 206 to secure and secure flexible proxy 200 cloud communications and proxy protocol 207 to facilitate communications with access

point control agents

219, 224.

As shown in FIG. 2, in addition to host access point 218, flexible proxy 200 may control other access points, such as networked access point 223. Flexible proxy 200 may communicate with other access points 223 via wired or

wireless connections

236, 237. Other access points 223 include access point control agents 224 to facilitate communication with the flexible proxy 200 and other access points. The access point control agent 224 includes a security module 225, an agent protocol 226, and a group communication protocol 227 to facilitate communications with other agents on the network, including other access points and client devices.

Cloud intelligence engine 235 includes a database 248 and memory 249 for storing information from flexible agents 200, other flexible agents (not shown) connected to intelligence engine 235, and external data sources (not shown). Database 248 and memory 249 allow cloud intelligence engine 235 to store information received from flexible agents and external data sources for months and years.

Cloud intelligence engine 235 also includes a processor 250 to perform cloud intelligence operations described herein. The roaming and guest agent manager 238 in the cloud intelligence engine 235 provides optimized connection information for devices connected to the flexible agent that roam from one access point to another or from one access point to another network. The roaming and guest agent manager 238 also manages guest connections with the network for flexible agents connected to the cloud intelligence engine 235. The external data fusion engine 239 provides integration and fusion of information from the flexible agent with information from external data sources (e.g., GIS information, other geographic information, FCC information about radar transmitter location, FCC blacklist information, NOAA database, DOD information about radar transmitter, and DOD request) to avoid transmission in the DFS channel for a given location. The cloud intelligence engine 235 also includes an authentication interface 240 for authenticating received communications and authenticating devices and users. Radar detection calculation engine 241 aggregates radar information from flexible agents and external data sources and calculates the location of the radar transmitter from these data to facilitate identifying false positive radar detections or hidden nodes and hidden radars. Radar detection calculation engine 241 may also direct or guide multiple flexible agents to dynamically adjust detection parameters and/or methods to further increase detection sensitivity. The location calculation and agent manager 242 determines the location of the flexible agent 200 and other connected devices by way of a Wi-Fi look-up table in a Wi-Fi location database, a query passing device, a scan list of flexible agents, or geometric inferences.

The spectral analysis and data fusion engine 243 and the network optimization ad hoc engine 244 utilize information from flexible agents and external data sources to facilitate dynamic spectrum optimization. Each flexible agent connected to the cloud intelligence engine 235 has scanned and analyzed the local spectrum and passed this information to the cloud intelligence engine 235. The cloud intelligence engine 235 also knows the location of each flexible agent and the location of access points near the flexible agent that do not have a control agent, and the channel on which each of these devices is operating. With this information, the spectrum analysis and data fusion engine 243 and the network optimization ad hoc engine 244 can optimize the local spectrum by informing the flexible agents to avoid channels facing interference. The group communication manager 245 manages communications between the flexible agents, access points, client devices, and other devices in the network. The cloud intelligence engine includes a security manager 246. The control agent manager 247 manages all connected control agents.

Independent of host access point 218, a flexible proxy 200 in the role of an autonomous DFS master may also provide channel indication and channel selection control to one or more point-to-

point client devices

231, 232 within the coverage area by: (a) signaling the availability of one or more DFS channels by simultaneously transmitting one or more beacon signals; (b) transmitting a list of authorized available DFS channels (herein referred to as whitelists) and forbidden DFS channels (herein referred to as blacklists) for which potential radar signals have been detected, and control signals and timestamp signals (herein referred to as dead-band-switch timers) via associated non-DFS channels; and (c) receive control, coordination and authorization and preferred channel selection guidance information from the cloud intelligence engine 235. Flexible proxy 200 sends a time stamp signal or dead-band switching timer via communication to ensure that the device does not use the information (including the white list) beyond the useful life of the information. For example, the white list is only valid for a certain period of time. The time stamp signal avoids using the non-compliant DFS channel by ensuring that the device will not use the white list beyond its useful life.

These point-to-point devices may have a user control interface 228. The user control interface 228 includes a user interface 229 to allow the

client devices

231, 232 to interact with the flexible agent 200 via the cloud intelligence engine 235. For example, the user interface 229 allows a user to modify network settings, including approving and revoking network access, via the flexible proxy 200. The user control interface 228 also includes a security element 230 to ensure that communications between the

client devices

231, 232 and the flexible agent 200 are secure. The

client devices

231, 232 are connected to a wide area network 234, for example, over a cellular network. A point-to-point wireless network is used for direct communication between devices without access points. For example, a camera may be directly connected to a computer to download a video or image file using a peer-to-peer network. Furthermore, device connections to external monitors and device connections to drones currently use peer-to-peer networks. Conventional point-to-point networks cannot use DFS channels because there is no access point to control DFS channel selection and tell the device what DFS channel to use. The present invention overcomes this limitation.

Fig. 3 illustrates how a flexible proxy 200 acting as an autonomous DFS master in a point-to-point network 300 (e.g., a local area network) interfaces with

client devices

231, 232, 331 and cloud intelligence engine 235 without relying on any access points, in accordance with the present invention. As shown in fig. 3, cloud intelligence engine 235 may be connected to a plurality of networked flexible agents 200, 310. The flexible agent 200 in the peer-to-peer network 300 may connect to the cloud intelligence engine 235 through one of the

networked client devices

231, 331 by, for example, piggybacking a message to the cloud intelligence engine 235 on a message sent to the

client device

231, 331, or augmenting the

client device

231, 331 connection to the wide area network 234. In the point-to-point network 300, the flexible proxy 200 sends over-the-air control signals 320 to the

client devices

231, 232, 331, including an indication of channels without occupied signals (e.g., DFS channels without radar signals). Alternatively, the flexible proxy communicates with only one client device 331, which then acts as a group owner to initiate and control peer-to-peer communications with the other client devices 231, 223. The

client devices

231, 232, 331 have point-to-point links 321 through which they communicate with each other.

The flexible agent may operate in multiple modes that employ different algorithms to perform multiple DFS scanning methods. Two of these methods are shown in fig. 4 and 5.

Fig. 4 illustrates a first DFS scanning method 400 for a multi-channel DFS master of the present invention. The method uses a time-division sequential CAC 401 followed by a continuous ISM 402. The method starts in step 403: the multi-channel DFS master is after startup or reset. At step 404, the embedded radio is set to receive (Rx) and tuned to the first DFS channel (C ═ 1). In one example, the first channel is channel 52. Next, because this is the first scan after startup or reset, and the DFS master has no information about radar-free channels, the DFS master performs a continuous CAC 405 scan for a period of 60 seconds (meeting FCC Part 15 sub-Part E and ETSI 301893 requirements). In step 406, the DFS master determines whether a radar pattern is present in the current channel. If a radar pattern is detected (407), the DFS master marks the channel in a blacklist. The DFS master may also send additional information about the detected radar including signal strength, radar pattern, radar type, and detection timestamp.

On the first scan after startup or reset, if a radar pattern is detected in the first channel scanned, the DFS master may repeat the above steps until a channel without radar signal is found. Alternatively, after startup or reset, the DFS master may be provided with a white list indicating one or more channels that have been determined to be radar signal free. For example, the DFS master may receive messages from the cloud intelligence engine 235 that the channel 52 is radar-free and information that is fused with other sources.

If at step 406 the DFS master does not detect a radar pattern (410), the DFS master marks the channel in the white list and switches the embedded radio to transmit (Tx) at the channel (not shown in fig. 4). The DFS master may include additional information (including a timestamp) in the white list. The DFS master then transmits (not shown in fig. 4) a DFS master beacon signal for a minimum required period n (this is the period of beacon transmission defined by IEEE 802.11 requirements, which is typically very short, on the order of a few microseconds). A common SSID can be used for all beacons of our system.

For finding none at DFS masterThe next channel scan after the radar's channel, the DFS master sets the radio to receive and tunes the radio to the next DFS channel 404 (e.g., channel 60). The DFS master then performs a discontinuous CAC radar detection scan 405 for a period of X, which is the maximum Period (PM) between beacons that allows the client device to remain associated with the network minus the period n required for fast radar scanning and transmission of the beacon itself (X ═ P) _M-n) 408. At 411, the DFS master saves the state of the current discontinuous channel State (SC) from the discontinuous CAC scan so that the DFS master can later resume the current discontinuous channel scan at the location where the DFS master left off. Then, at step 412, the DFS master switches the radio to transmit and tunes to the first DFS channel (CH 52 in this example), performing a fast receive radar scan 413 (for a period D called dwell time) to detect radar 414. If a radar pattern is detected, the DFS master marks the channel to blacklist 418. When marking channels to a blacklist, the DFS master may also include additional information about detected radar patterns, including signal strength, radar type, and timestamp of detection. If no radar pattern is detected, the DFS master again transmits 415 a DFS master beacon for the first channel (channel 52 in this example). Next, the DFS master determines the current channel (C)_B) Whether it is a white list (W)_L) 416. In the current example, the current channel (channel 52) is now the only channel in the white list. The DFS master then restores 417 the channel to the state saved from step 411 and switches the radio back to receive mode and tunes the radio back to the current non-continuous CAC DFS channel (channel 60 in the example) 404. The DFS master then resumes the discontinuous CAC radar scan 405 for a period of X, again accommodating the period n required for fast scan and beacon transmission. This process is repeated until 60 seconds of non-continuous CAC scans 409 have accumulated (in this case, the channel is marked in the white list 410) or until a radar pattern is detected (in this case, the channel is marked in the black list 407).

Next, the DFS master targets the nextThe process in the previous paragraph is repeated for each DFS channel (e.g., channel 100). The DFS master periodically switches 412 to the previously whitelisted DFS channels for a fast scan 413 (for a period D called dwell time) and if no radar pattern is detected, a beacon 415 is transmitted in each previously CAC scanned and whitelisted DFS channel for a period n. The DFS master then returns 404 to recover the non-continuous CAC scan 405 of the current CAC channel (CH 100 in this case). For each of the previously whitelisted CAC scan channels, the time period X available for non-continuous CAC scanning is reduced by n, approximately X ═ P, before switching to transmission and sequentially beaconing the previously whitelisted CAC scan channels_M-n*(W_L) Wherein W is_LIs the number of previously whitelisted CAC scan channels. This process is repeated until 60 seconds of non-continuous CAC scans accumulate for the current channel 409. If no radar pattern is detected, the channel is marked in a white list 410. If a radar pattern is detected, the channel 407 is marked in the black list and the radio can immediately switch to the next DFS channel for CAC scanning.

The steps in the previous paragraph are repeated for each new DFS channel until all desired channels in the DFS band have been scanned by the CAC. In fig. 4, step 419 checks to see if the current channel is the last channel to CAC scan R. If the last channel to CAC scan R has been reached, the DFS master signals 420 that CAC phase 401 is complete and begins ISM phase 402. The white list and black list information may be passed to a cloud intelligence engine where it is integrated over time and fused with similar information from other flexible agents.

During the ISM phase, the DFS master does not scan channels in the blacklist 421. The DFS master switches 422 to the first channel in the white list and transmits 423 a DFS beacon on that channel. The DFS master then scans 424 the first channel in the white list for D_ISMTime period (ISM dwell time) 425, which may be approximately P_M(may allow the client device to remain withMaximum time period between beacons of network association) minus n times the number of white-listed channels, divided by the number of white-listed channels (D)_ISM＝(P_M-n*W_L) N)). The DFS master then transmits 423 a beacon and scans 424 each channel in the white list for the dwell time, then repeats the start 422 on the first channel in the white list in a round-robin fashion for each respective channel. If radar pattern 426 is detected, the DFS main beacon 427 of the corresponding channel is stopped and the channel is marked 428 in the blacklist and removed from the whitelist (and no longer ISM scanned). The DFS master device sends 429 an alert message and new whitelists and blacklists to the cloud intelligence engine. The alert message may also be sent to other access points and/or client devices in the network.

Fig. 5 illustrates a second DFS scanning method 500 for a multi-channel DFS master of the present invention. The method uses a sequential order CAC 501 followed by a sequential ISM 502. The method starts in step 503: the multi-channel DFS master is after startup or reset. At step 504, the embedded radio is set to receive (Rx) and tuned to the first DFS channel (C ═ 1). In this example, the first channel is channel 52. The DFS master performs a continuous CAC scan 505 for a period 507 of 60 seconds (compliant with FCC part 15, subsection E and ETSI 301893 requirements). If a radar pattern is detected at step 506, the DFS master marks 508 that channel in a blacklist.

If the DFS master does not detect a radar pattern, it marks the channel in the white list 509. The DFS master determines in step 510 whether the current channel C is the last channel to be scanned R by the CAC. If not, the DFS master tunes 504 the receiver to the next DFS channel (e.g., channel 60). The DFS master then performs a continuous scan 505 for a full period 507 of 60 seconds. If a radar pattern is detected, the DFS master marks the channel in a blacklist 508 and the radio can immediately switch to the next DFS channel 504 and repeat the steps after step 504.

If no radar pattern is detected 509, the DFS master marks the channel in the white list 509, then tunes the receiver to the next DFS channel 504 and repeats the subsequent steps until all DFS channels for which CAC scanning is desired. Unlike the method shown in fig. 4, during the CAC scan phase, no beacons are transmitted between CAC scans of sequential DFS channels.

The ISM phase 502 in fig. 5 is the same as described above in fig. 4.

Fig. 6A shows how a plurality of channels in a DFS channel of a 5GHz band can be simultaneously made available by using the present invention. Fig. 6A shows the process of fig. 5, where the autonomous DFS master performs a DFS scan CAC phase 600 over multiple channels and after the CAC phase is complete, the autonomous DFS master performs an ISM phase 601. In accordance with the present invention, during the ISM phase, the DFS master device transmits multiple beacons to indicate the availability of multiple DFS channels to nearby host and non-host (normal) access points and client devices.

Fig. 6A shows frequencies 602 and channels 603 that make up part of the DFS 5GHz Wi-Fi spectrum. U-NII-2A 606 covers the range of 5.25-5.35 GHz. U-NII-2C 607 covers the range of 5.47-5.725 GHz. The first channel undergoing the CAC scan is shown at element 607. Subsequent CAC scans of other channels are shown at element 608. And the final CAC scan before ISM phase 601 is shown at element 609.

In ISM phase 601, the DFS master switches to the first channel in the white list. In the example of fig. 6A, each channel 603 on which CAC scanning is performed has no radar signal during CAC scanning and is added to the white list. The DFS master then transmits 610 a DFS beacon on the channel. The DFS master then scans 620 the first channel in the white list for the dwell time. The DFS master then transmits 611 a beacon and scans every other channel in the white list for the dwell time, then repeats the start 610 at the first channel in the white list in a round-robin fashion for each respective channel. If a radar pattern is detected, the DFS primary beacon for the corresponding channel is stopped and the channel is marked in the blacklist and removed from the whitelist (and no longer ISM scanned).

Fig. 6A also shows an exemplary waveform 630 of multiple beacon transmissions from a DFS master device to indicate the availability of multiple DFS channels to nearby host and non-host (normal) access points and client devices.

Fig. 6B shows a beacon transmission duty cycle 650 and a radar detection duty cycle 651. In this example, channel a is the first channel in the channel white list. In fig. 6B, a beacon transmission 660 in channel a is followed by a fast scan 670 of channel a. Next, a beacon transmission 661 in the second channel (channel B) is followed by a fast scan 671 of channel B. The sequence is repeated for the channel: channel C662,672; channel D663,673; channel E664,674; channel F665,675; channel G666,676 and channel H667,677. After the fast scan 677 of channel H, the DFS master switches back to channel a and performs a second beacon transmission 660 in channel a, followed by a second fast scan 670 for channel a. The time between the start of the first beacon transmission in channel a and the start of the second beacon transmission in channel a is the beacon transmission duty cycle. The time between the start of the first fast scan in channel a and the start of the second fast scan in channel a is the radar detection duty cycle. To maintain a connection with a device on the network, the beacon transmission duty cycle should be less than or equal to a maximum period between beacons that allows the client device to remain associated with the network.

One embodiment of the present invention provides an independent multi-channel DFS master device, comprising: a beacon generator 212 for generating a beacon in each of a plurality of 5GHz radio channels; a radar detector 211 for scanning radar signals in each of a plurality of 5GHz radio channels; a 5GHz radio transceiver 215 for transmitting beacons in each of a plurality of 5GHz radio channels and receiving radar signals in each of a plurality of 5GHz radio channels; and a fast channel switch generator 217 and embedded processor 203 coupled to the radar detector, the beacon generator, and the 5GHz radio transceiver. The fast channel switch generator 217 and embedded processor 203 switch the 5GHz radio transceiver 215 to a first channel of the plurality of 5GHz radio channels and cause the beacon generator 212 to generate a beacon in the first channel of the plurality of 5GHz radio channels. The fast channel switch generator 217 and embedded processor 203 also cause the radar detector 211 to scan for radar signals in a first channel of the plurality of 5GHz radio channels. The fast channel switch generator 217 and embedded processor 203 then repeat these steps for each other of the plurality of 5GHz radio channels. The fast channel switch generator 217 and embedded processor 203 perform all steps on all of the plurality of 5GHz radio channels during a beacon transmission duty cycle (which is the time between successive beacon transmissions on a particular channel), and in some embodiments, during a radar detection duty cycle (which is the time between successive scans on the particular channel).

In the embodiment illustrated in fig. 7, the present invention comprises a system and method for selecting an available channel of unoccupied signals from among a plurality of radio frequency channels. The system includes a flexible proxy 700 that acts as an autonomous frequency selection master with both an embedded radio receiver 702 for detecting an occupied signal in each of a plurality of radio frequency channels and an embedded radio transmitter 703 for transmitting an indication of available channels and an indication of unavailable channels that are not unoccupied signals. Flexible agent 700 is programmed to connect to host device 701 and control selection of operating channel selection for the host device by sending an indication of available channels and an indication of unavailable channels to the host device. Host device 701 is in wireless communication with client device 720 and acts as a gateway for the client device to network 710 (e.g., the internet, other wide area network, or local area network). Under the control of the flexible proxy 700, the master device 701 tells the client device 720 which channel or channels to use for wireless communication. Further, flexible proxy 700 may be programmed to send an indication of available channels and an indication of unavailable channels directly to client device 720.

Flexible agent 700 may operate in the 5GHz band, and the plurality of radio channels may be in the 5GHz band, and the occupancy signal is a radar signal. The host device 701 may be a Wi-Fi access point or an LTE-U host device.

In addition, flexible agent 700 may also be programmed to transmit an indication of available channels by transmitting multiple beacon signals simultaneously. And flexible proxy 700 may be programmed to send an indication of available channels by sending a channel white list of available channels and an indication of unavailable channels by sending a channel black list of unavailable channels. In addition to storing the channel in the channel blacklist, the flexible proxy 700 may be programmed to determine and store information about detected occupied signals, including signal strength, traffic and type of occupied signal, in the channel blacklist.

As shown in fig. 8, in some embodiments, flexible agent 700 connects to a cloud-based intelligence engine 855. Flexible agent 700 can connect to cloud intelligence engine 855 directly or through host device 701 and network 710. Cloud intelligence engine 855 integrates the time-distributed information from flexible agents 700 and combines the information from multiple other flexible agents 850 distributed in space and connected to cloud intelligence engine 855. Flexible agent 700 is programmed to receive control and coordination signals and authorization and preferred channel selection guidance information from cloud intelligence engine 755.

In another embodiment, shown in fig. 9, the present invention comprises a system and method for selecting an available channel of an unoccupied signal from a plurality of radio channels, wherein a flexible agent 700 acting as an autonomous frequency selection master comprises an embedded radio receiver 702 and an embedded radio transmitter 703, the embedded radio receiver 702 being configured to detect an occupied signal in each of the plurality of radio frequency channels, the embedded radio transmitter 703 being configured to indicate the available channel and an unavailable channel that is not an unoccupied signal. Flexible proxy 700 contains a channel white list 910 of one or more channels that are scanned and determined to not contain an occupied signal. Flexible agent 700 may receive whitelist 910 from another device including cloud intelligence engine 855. Alternatively, flexible proxy 700 may have a white list 910 previously obtained through successive CACs for one or more channels. In this embodiment, the flexible proxy 700 is programmed to cause the embedded radio receiver 702 to discontinuously scan each of the plurality of radio frequency channels with intervening channels periodically switched to the channel white list 910 to perform a fast occupancy signal scan in each channel of the channel white list 910. The flexible proxy 700 is also programmed to cause the embedded radio transmitter 703 to send a first beacon transmission in each channel in the channel white list 910 during the fast occupancy signal scan, and to track channels in the channel white list 910 that were scanned during the discontinuous scan and the fast occupancy signal scan and determined to contain no occupancy signals. Flexible agent 700 is also programmed to track channels in channel blacklist 915 that are scanned and determined to contain occupied signals during discontinuous scanning and fast occupied signal scanning, and then perform in-service monitoring on occupied signals, including continuously and sequentially transmitting a second beacon for each channel in channel whitelist 910.

Fig. 10 illustrates an exemplary method 1000 for selecting an operating channel from a plurality of radio frequency channels in a flexible proxy acting as an autonomous frequency selection master in accordance with the present invention. The method comprises the following steps: a channel white list 1010 of one or more channels that are scanned and determined to not contain an occupied signal is received. Next, the flexible proxy performs channel availability checks 1005 in a time-division manner on the plurality of radio frequency channels. The time division channel availability check includes: discontinuously scanning 1010 each of a plurality of radio frequency channels with an embedded radio receiver in a flexible agent with intervening: periodically switching to a channel in a channel white list to perform a fast occupancy signal scan; and sending 1020 a first beacon in each channel in the channel white list during the fast occupancy signal scan with an embedded radio transmitter in the flexible proxy. The flexible proxy also tracks 1030 channels that were scanned and determined at step 1010 as not containing an occupied signal in a channel white list, and tracks 1040 channels that were scanned and determined at step 1010 as containing an occupied signal in a channel black list. Finally, the flexible proxy performs in-service monitoring of the occupancy signal and performs a second beacon transmission continuously and sequentially for each channel in the channel white list.

Fig. 11 illustrates another example method 1100 for selecting an operating channel from a plurality of radio channels in a flexible proxy acting as an autonomous frequency selection master. The method 1100 comprises: a channel availability check is performed on each of the plurality of radio frequency channels by successively scanning 1101 each of the plurality of radio frequency channels with an embedded radio receiver in the flexible proxy for a scanning period. Then, the flexible agent tracks 1110 channels in a channel white list that are scanned and determined to not contain an occupied signal, and tracks 1120 channels in a channel black list that are scanned and determined to contain an occupied signal. The flexible proxy then performs in-service monitoring of the occupancy signal and continuously and sequentially transmits a beacon for each channel in the channel white list with an embedded radio transmitter in the flexible proxy.

Fig. 12 illustrates another example method 1200 for selecting an operating channel from a plurality of radio channels in a flexible proxy acting as an autonomous frequency selection master. The method 1200 includes: a channel availability check is performed 1210 for each of the plurality of radio frequency channels and in-service monitoring and beaconing is performed 1250 for each of the plurality of radio frequency channels. The channel availability check 1210 includes tuning an embedded radio receiver in the autonomous frequency selection master to one of a plurality of radio frequency channels and initiating a continuous channel availability scan in the one of the plurality of radio frequency channels with the embedded radio receiver 1211. Next, the channel availability check 1210 includes: during the continuous channel availability scan 1212, it is determined whether an occupancy signal is present in the one of the plurality of radio frequency channels. If there is an occupied signal in the one of the plurality of radio frequency channels during the continuous channel availability scan, the channel availability check 1210 includes: the one of the plurality of radio frequency channels is added to the channel blacklist and the continuous channel availability scan 1213 ends. If there is no occupancy signal in the one of the plurality of radio frequency channels during the successive channel availability scans, the channel availability check 1210 includes: the one of the plurality of radio frequency channels is added to the channel white list and the continuous channel availability scan is ended 1214. Next, the channel availability check 1210 includes:

steps

1211 and 1212 and either 1213 or 1214 are repeated for each of the plurality of radio frequency channels.

In-service monitoring and beaconing 1250 for each of a plurality of radio frequency channels includes: determining whether the one of the plurality of radio frequency channels is in a channel white list, if so, tuning the embedded radio receiver in the autonomous frequency selection master to the one of the plurality of radio frequency channels, and transmitting a beacon 1251 in the one of the plurality of radio frequency channels with the embedded radio transmitter in the autonomous frequency selection master. Next, in-service monitoring and beaconing 1250 includes: a discrete channel availability scan (fast scan as previously described) 1252 is initiated in the one of the plurality of radio frequency channels with the embedded radio receiver. Next, in-service monitoring and beaconing 1250 includes: it is determined during the discrete channel availability scan whether an occupancy signal 1253 is present in the one of the plurality of radio frequency channels. If an occupancy signal is present, in-service monitor and beaconing 1250 includes: ceasing transmission of the beacon, removing the one of the plurality of radio frequency channels from the channel white list, adding the one of the plurality of radio frequency channels to the channel black list, and ending the discrete channel availability scan 1254. If, for the second scan period, there is no occupancy signal in the one of the plurality of radio frequency channels during the discrete channel availability scan, in-service monitoring and beaconing 1250 comprises: the discrete channel availability scan 1255 ends. Thereafter, in-service monitoring and beaconing 1250 includes:

steps

1251, 1252 and 1253 and either 1254 or 1255 are repeated for each of a plurality of radio frequency channels.

Fig. 13 illustrates a system that includes a cloud intelligence engine 235, a flexible proxy 200, and a host access point 218. The flexible proxy 200 may be directed by a cloud intelligence engine 235 (e.g., a cloud-based data fusion and computing element) to enable adaptive control of dynamic channel selection by the host access point 218 and/or other functionality associated with the host access point 218 (e.g., dynamic configuration of radio parameters, etc.). As disclosed herein, in an aspect, flexible proxy 200 includes cloud proxy 204. For example, cloud proxy 204 may enable flexible proxy 200 to communicate with host access point 218. Cloud proxy 204 may additionally or alternatively communicate with one or more other devices (not shown), such as a base station (e.g., a small cell base station), a DFS slave device, a peer-to-peer group owner device, a mobile hotspot device, a wireless access node device (e.g., an LTE small cell device), a software access point device, and/or another device. In an implementation, cloud agent 204 includes cloud control 1302. Cloud control 1302 may also enable flexible agent 200 to communicate with cloud intelligence engine 235. Further, cloud control 1302 can facilitate selection of radio channels and/or other radio parameters for host access point 218. For example, flexible proxy 200 may analyze multiple 5GHz radio channels (e.g., multiple 5GHz radio channels associated with 5GHz Wi-Fi spectrum 161) for host access point 218. Additionally or alternatively, flexible proxy 200 may analyze multiple 5GHz radio channels (e.g., multiple 5GHz radio channels associated with 5GHz Wi-Fi spectrum 161) for a DFS slave device, a peer-to-peer group owner device, a mobile hotspot device, a wireless access node device (e.g., an LTE small cell device), a software access point device, and/or another device. In an aspect, flexible agent 200 may actively scan multiple 5GHz radio channels (e.g., multiple 5GHz radio channels associated with 5GHz Wi-Fi spectrum 161) during the CAC phase and/or during the ISM phase.

Flexible proxy 200 may then generate spectral information based on an analysis of the multiple 5GHz radio channels (e.g., multiple 5GHz radio channels for host access point 218, a DFS slave device, a peer-to-peer group owner device, a mobile hotspot device, a wireless access node device, a software access point device, and/or another device). For example, the flexible agent 200 may provide information (e.g., spectrum information) to the cloud intelligence engine 235 indicating a set of channels from the plurality of 5GHz radio channels that are free of radar and therefore available for use by nearby devices (e.g., host access point 218). The spectrum information may include information such as a white list (e.g., a white list of each of the plurality of 5GHz radio channels that do not contain radar signals), a black list (e.g., a black list of each of the plurality of 5GHz radio channels that include radar signals), scan information associated with scanning of radar signals in the plurality of 5GHz radio channels, status information, location information associated with flexible proxy 200 and/or host access point 218, a time signal, a scan list (e.g., a scan list showing neighboring access points, etc.), congestion information (e.g., a number of retry packets, a type of retry packet, etc.), traffic information, other channel condition information, and/or other spectrum information. The cloud control 1302 may send the spectrum information to the cloud intelligence engine 235. In an aspect, flexible agent 200 may send the spectrum information to cloud intelligence engine 235 via a wide area network. Additionally or alternatively, the flexible proxy 200 can send spectrum information to the cloud intelligence engine 235 via a set of DFS slave devices in communication with the flexible proxy 200 (e.g., via a backhaul of the DFS slave devices in communication with the flexible proxy 200). In another aspect, flexible proxy 200 may communicate with master access point 218 via a local area network (e.g., a wireless local area network). Additionally or alternatively, flexible proxy 200 may communicate with host access point 218 via a wide area network (e.g., a wireless wide area network), an ad hoc network (e.g., an IBSS network), a point-to-point network (e.g., an IBSS point-to-point network), a short range wireless network (e.g., a bluetooth network), another wireless network, and/or another wired network.

The cloud intelligence engine 235 may integrate the spectral information with other spectral information (e.g., other spectral information associated with the flexible agent 251) to generate integrated spectral information. For example, cloud intelligence engine 235 may receive other spectrum information from flexible agent 251. Other spectrum information may be generated by flexible agent 251 through analysis of multiple 5GHz radio channels (e.g., analysis similarly performed by flexible agent 200). In an aspect, cloud intelligence engine 235 may include cloud-based data fusion and computing elements that intelligently adapt network organization, optimization, planning, configuration, management, and/or coordination based on spectral information and other spectral information. The cloud intelligence engine 235 may geotag, filter, and/or process the aggregated spectrum information. In an implementation, the cloud intelligence engine 235 may combine the aggregated spectrum information with regulatory information associated with the data source 252. For example, regulatory information (e.g., non-spectral information) 252 associated with the data source may include information such as, but not limited to, Geographic Information System (GIS) information, other geographic information, FCC information regarding the location of the radar transmitter, FCC blacklist information, National Oceanographic and Atmospheric Administration (NOAA) databases, department of defense (DOD) information regarding the radar transmitter, DOD requests to avoid transmission in a DFS channel at a given location, and/or other regulatory information. Based on the aggregated spectrum information and/or regulatory information associated with the data source 252, the cloud intelligence engine 235 may select a radio channel from a plurality of 5GHz radio channels for the host access point 218 associated with the flexible proxy. Additionally or alternatively, the cloud intelligence engine 235 may select other radio frequency parameters for the host access point 218 based on the aggregated spectrum information and/or regulatory information associated with the data source 252.

The cloud control 1302 may receive control information and/or coordination information (e.g., authorization and/or preferred channel selection guidance) from the cloud intelligence engine 235. For example, the cloud control 1302 may receive a radio channel selected by the cloud intelligence engine 235. Additionally or alternatively, the cloud control 1302 may receive other no-wire frequency parameters selected by the cloud intelligence engine 235. Flexible agent 200 (e.g., cloud agent 204) can communicate control information and/or coordination information (e.g., control information and/or coordination information received from cloud intelligence engine 235) to host access point 218 (and/or any other access point within a distance from flexible agent 200) such that cloud intelligence engine 235 can directly control host access point 218. For example, flexible proxy 200 (e.g., cloud proxy 204) may then configure host access point 218 to receive data via a radio channel selected by cloud intelligence engine 235 and/or based on other radio frequency parameters selected by cloud intelligence engine 235. In alternative implementations, control agent 1302 may be used in an access point that is not directly connected to flexible agent 200, or in a peer-to-peer capable mobile device, to enable faster and/or improved access to the DFS channel.

Flexible agent 200 may generate spectrum information based on an analysis of a plurality of 5GHz radio channels associated with 5GHz Wi-Fi spectrum 161. For example, flexible agent 200 may switch a 5GHz transceiver (e.g., primary radio 215) of flexible agent 200 to a channel of a plurality of 5GHz radio channels associated with a 5GHz Wi-Fi spectrum 161, generate a beacon 5GHz Wi-Fi spectrum 161 in the channel of the plurality of 5GHz radio channels associated with the Wi-Fi spectrum 161, and scan for radar signals in the channel of the plurality of 5GHz radio channels associated with the 5GHz Wi-Fi spectrum 161. Additionally, flexible agent 200 may switch a 5GHz transceiver (e.g., primary radio 215) of flexible agent 200 to another channel of the plurality of 5GHz radio channels associated with 5GHz Wi-Fi spectrum 161, generate a beacon in the other channel of the plurality of 5GHz radio channels associated with the plurality of 5GHz radio channels, and scan for radar signals in the other channel of the plurality of 5GHz radio channels associated with 5GHz Wi-Fi spectrum 161. Flexible agent 200 may repeat this process for each of a plurality of 5GHz radio channels associated with 5GHz Wi-Fi spectrum 161. The cloud intelligence engine 235 may receive the spectrum information via a wide area network. Further, the cloud intelligence engine 235 may integrate the spectrum information with other spectrum information generated by the flexible agent (251) (e.g., to generate integrated spectrum information). The cloud intelligence engine 235 may then determine a radio channel from the plurality of 5GHz radio channels based at least on the aggregated spectrum information. In certain implementations, the cloud intelligence engine 235 can receive regulatory information from the data source 252. Accordingly, the cloud intelligence engine 235 may determine a radio channel from the plurality of 5GHz radio channels based on the aggregated spectrum information and regulatory information associated with the data source 252.

FIG. 14A illustrates the interface between a cloud intelligence engine 235, a flexible proxy 200, and a host access point 218 according to the present invention. For example, signaling and/or messages may be exchanged between cloud intelligence engine 235 and flexible proxy 200. Signaling and/or messages between the cloud intelligence engine 235 and the flexible proxy 200 may be exchanged during DFS scanning operations, during ISM operations, and/or when radar events occur that cause radio channel changes. In an aspect, signaling and/or messages between cloud intelligence engine 235 and flexible agent 200 can be exchanged via a WAN (e.g., WAN 234) and/or a secure communication tunnel.

Authentication registration process 1402 of cloud intelligence engine 235 may be associated with message a. Message a may be exchanged between cloud intelligence engine 235 and flexible proxy 200. Further, message a may be associated with one or more signaling operations and/or one or more messages. Message a may facilitate initialization and/or authentication of flexible proxy 200. For example, the message may include information associated with flexible proxy 200, such as, but not limited to, an element identification, credentials 200 associated with a flexible agent, a nearest neighbor scan list associated with a set of other flexible agents within a distance of flexible agent 200, a service set identifier, a received signal strength indication associated with flexible agent 200 and/or host access point 218, a manufacturer identification associated with host access point 218, a measured location (e.g., a global positioning system location) associated with flexible agent 200 and/or host access point 218, a derived location (e.g., derived via a nearby AP or nearby client) associated with flexible agent 200 and/or host access point 218, time information, current channel information, state information, and/or other information associated with flexible agent 200 and/or host access point 218. In one example, message a may be associated with a channel availability check phase.

Data fusion process 1404 of cloud intelligence engine 235 can facilitate computation of a location associated with flexible proxy 200 and/or host access point 218. Additionally or alternatively, the data fusion process 1404 of the cloud intelligence engine 235 can facilitate computation of a set of DFS channel lists. Data fusion process 1404 may be associated with message B and/or message C. Message B and/or message C may be exchanged between cloud intelligence engine 235 and flexible proxy 200. Further, message B and/or message C may be associated with one or more signaling operations and/or one or more messages. Message B may be associated with spectrum measurements and/or environment measurements associated with flexible proxy 200. For example, message B may include information such as, but not limited to, a scanned DFS white list, a scanned DFS black list, scanned information measurements, scanning statistics, congestion information, traffic count information, time information, status information, and/or other measurement information associated with flexible proxy 200. Message C may be associated with a granted DFS, a list of DFS, and/or a channel change. For example, message C may include information such as, but not limited to, a directed (e.g., approved) DFS whitelist, a directed (e.g., approved) DFS blacklist, a current time, a list validity time, a computed location associated with flexible proxy 200 and/or host access point 218, a network heartbeat, and/or other information associated with channel and/or dynamic frequency selection.

Network optimization process 1406 of cloud intelligence engine 235 can facilitate optimization of a network topology associated with flexible proxy 200. The network optimization process 1406 may be associated with message D. Message D may be exchanged between cloud intelligence engine 235 and flexible proxy 200. Further, message D may be associated with one or more signaling operations and/or one or more messages. The message D may be associated with a change of radio channel. For example, message D may be associated with a radio channel of host access point 218 for communicating with flexible proxy 200. Message D may include information such as, but not limited to, a radio channel (e.g., a command to switch to a particular radio channel), an effective time of a list, a network heartbeat, and/or other information for optimizing network topology.

Network update process 1408 of cloud intelligence engine 235 can facilitate an update of the network topology associated with flexible proxy 200. Network update procedure 1408 may be associated with message E. Message E may be exchanged between cloud intelligence engine 235 and flexible proxy 200. Further, message E may be associated with one or more signaling operations and/or one or more messages. Message E may be associated with a network heartbeat and/or a DFS grant. For example, message E may include information such as, but not limited to, a nearest neighbor scan list associated with a set of other flexible agents within a distance of flexible agent 200, a service set identifier, a received signal strength indication associated with flexible agent 200 and/or host access point 218, a manufacturer identification associated with host access point 218, a measured location update associated with flexible agent 200 and/or host access point 218 (e.g., a global positioning system location update), a derived location update associated with flexible agent 200 and/or host access point 218 (e.g., derived via a nearby AP or nearby client), time information, current channel information, state information, and/or other information. In one example, message B, message C, message D, and/or message E may be associated with an ISM phase.

Managing the DFS list process 1410 of the flexible agent 200 can facilitate storage and/or updating of the DFS list. Manage DFS list process 1410 may be associated with message F. Message F may be exchanged between flexible proxy 200 and host access point 218. In one example, the message F may be exchanged via a local area network (e.g., a wired local area network and/or a wireless local area network). Further, message F may be associated with one or more signaling operations and/or one or more messages. Message F may facilitate a change in the radio channel for host access point 218. For example, message F may include information such as, but not limited to, the following: a closest neighbor scan list associated with other flexible agent sets within a particular distance from flexible agent 200, a service set identifier, a received signal strength indication associated with flexible agent 200 and/or host access point 218, a manufacturer identification associated with host access point 218, a measured location update (e.g., a global positioning system location update) associated with flexible agent 200 and/or host access point 218, a derived location update (e.g., derived via a nearby AP or a nearby client) associated with flexible agent 200 and/or host access point 218, time information, current channel information, state information, and/or other information. In one example, the message F may be associated with a cloud-directed operation (e.g., a DFS channel-enabled cloud-directed operation).

FIG. 14B also shows the interfaces between the cloud intelligence engine 235, the flexible proxy 200, and the host access point 218 in accordance with the present invention. For example, FIG. 14B may provide additional detail in conjunction with FIG. 14A. As shown in fig. 14B, signaling and/or messages may be exchanged between cloud intelligence engine 235 and flexible proxy 200. Signaling and/or messages may be exchanged between the cloud intelligence engine 235 and the flexible agent 200 during DFS scanning operations, during ISM, and/or when radar events result that change radio channels. In an aspect, signaling and/or messages can be exchanged between cloud intelligence engine 235 and flexible agent 200 via a WAN (e.g., WAN 234) and/or a secure communication tunnel.

As shown in fig. 14B, network update process 1408 of cloud intelligence engine 235 can facilitate updates regarding the network topology associated with flexible proxy 200. Network update procedure 1408 may be associated with message E. The DFS list update process 1414 of the cloud intelligence engine 235 can then facilitate the update of one or more DFS channel lists. DFS list update process 1414 can be associated with message G. Message G may be exchanged between cloud intelligence engine 235 and flexible proxy 200. In one example, message G may be exchanged via a WAN (e.g., WAN 234) and/or a secure communication tunnel. Further, message G may be associated with one or more signaling operations and/or one or more messages. Message G may be associated with a radar event. For example, message G may signal a radar event. Additionally or alternatively, message G may include information associated with a radar event. For example, message G may include, for example and without limitation, the following information: a radar measurement channel, a radar measurement pattern, a time associated with a radar event, a status associated with a radar event, other information associated with a radar event, and the like. The radar event may be associated with one or more channels from among a plurality of 5GHz communication channels (e.g., a plurality of 5GHz communication channels associated with a 5GHz Wi-Fi spectrum 161). In one example, message G may be associated with an ISM phase. DFS list update process 1414 can be associated with message C.

Further, as also shown in FIG. 14B, manage DFS list process 1410 can be associated with message F. Message F may be exchanged between flexible proxy 200 and host access point 218. Radar detection process 1416 of flexible proxy 200 may detect and/or generate radar events. Further, the radar detection process 1416 may notify the host access point 218 to change radio channels (e.g., switch to an alternate radio channel). The message F may be updated and/or the DFS list process 1412 may be managed accordingly in response to the change in radio channel. In an aspect, signaling and/or messages may be exchanged between the cloud intelligence engine 235 and the host access point 218 during DFS scanning operations, during ISM operations, and/or when radar events result in a change of a radio channel for the host access point 218.

Fig. 15 illustrates an exemplary method 1500 in accordance with the present invention for determining a communication channel to be used in a plurality of multi-channel DFS masters. First, at 1510, the cloud intelligence engine receives, via one or more network devices, spectrum information associated with a plurality of 5GHz communication channels from a plurality of multi-channel DFS master devices. Optionally, at 1511, receiving the spectrum information includes: scanning information associated with scanning for radar signals is received in a plurality of 5GHz radio channels. A flexible proxy device (e.g., flexible proxy 200 or flexible proxy 700) may be used to generate spectrum information based on an analysis of multiple 5GHz communication channels. The analysis of the plurality of 5GHz communication channels comprises: switching a 5GHz radio transceiver of a flexible proxy device to a channel of a plurality of 5GHz communication channels, generating a beacon in the channel of the plurality of 5GHz communication channels, and scanning the channel of the plurality of 5GHz communication channels for radar signals. The spectrum information may include, for example, but is not limited to, the following: white lists (e.g., a white list of each of a plurality of 5GHz communication channels that do not contain radar signals), black lists (e.g., a black list of each of a plurality of 5GHz communication channels that do contain radar signals), scan information associated with scanning for radar signals in the plurality of 5GHz communication channels, status information, location information associated with flexible proxy devices and/or access point devices, time signals, scan lists (e.g., a scan list showing neighbor access points, etc.), congestion information (number of retry packets, type of retry packets, etc.), traffic information, and/or other spectrum information. Next, at 1520, the cloud intelligence engine integrates the spectral information with other spectral information to generate integrated spectral information. At least one other flexible proxy device may generate other spectrum information. In one example, the spectral information may be integrated with other spectral information via one or more data fusion processes.

Then, at 1530, the cloud intelligence engine determines communication channels for the plurality of multi-channel DFS master devices from the plurality of 5GHz communication channels based at least on the aggregated spectrum information. For example, a communication channel may be selected from a plurality of 5GHz communication channels based at least on the integrated spectral information. In an aspect, a cloud smart device may receive regulatory information associated with a plurality of 5GHz communication channels and/or stored in at least one database. Moreover, the communication channel may be determined further based on the regulatory information. In another aspect, an indication of the communication channel may be provided to the flexible proxy device and/or the access point device.

Fig. 16 illustrates an exemplary method 1600 in accordance with the present invention for determining a communication channel to be used in a plurality of multi-channel DFS master devices. The method shown in fig. 16 includes the steps described above in connection with fig. 15, but also includes the following optional additional steps. At 1610, the method comprises: a white list of each of a plurality of 5GHz radio channels that do not contain radar signals is sent to a plurality of multi-channel DFS master devices via one or more network devices. At 1620, the method comprises: a blacklist of each of a plurality of 5GHz radio channels containing radar signals is transmitted to a plurality of multi-channel DFS master devices via one or more network devices. At 1630, the method includes: regulatory information stored in at least one database is received. Regulatory information may include, but is not limited to, GIS information, other geographic information, FCC information regarding the location of the radar transmitter, FCC blacklist information, NOAA database, DOD information regarding the radar transmitter, DOD requests to avoid transmissions in the DFS channel with respect to a given location, and/or other regulatory information. At 1640, the method may comprise: a communication channel is determined based on the integrated spectral information and regulatory information.

As discussed herein, the disclosed system differs significantly from the current prior art in that: (a) the disclosed wireless flexible proxy enables multiple simultaneous dynamic frequency channels, which is significantly more bandwidth than that provided by a traditional standalone DFS master access point or small cell base station; (b) the additional DFS channel can be shared with nearby access points (suitably equipped with control agents) or small cells, so that the network as a whole can benefit from the additional bandwidth; and (c) a centralized network organization element (cloud intelligence engine) may coordinate the selection of operating channels by access points and/or small cell base stations to avoid overlapping channels, thus avoiding interference and alleviating congestion.

(a) The capabilities and functionality in (a) to (c) are enabled by a centralized cloud intelligence engine that collects and combines DFS radar and other spectral information and geo-tags from each flexible agent, stores, filters and integrates the data over time, and combines it with information from multiple other flexible agents distributed in space through data fusion techniques, and performs filtering and other post-processing on the collection through proprietary algorithms and merges with other data from vetted sources (e.g., GIS, Federal Aviation Administration (FAA), FCC and DoD databases, etc.).

Specifically, the cloud intelligence engine performs the following operations: continuously collecting from all wireless flexible agents spectrum, location and network congestion/traffic information that grows rapidly in number and density as more access points and small cell base stations are deployed; continuously applying complex filtering, spatial and temporal correlation and integration operations, and novel array combining techniques and pattern recognition, etc., on the data set; the network analysis and optimization techniques of the present invention are applied to computational network organizational judgments to jointly optimize dynamic channel selection of access points and small cell base stations on the network; and directing, via the wireless flexible proxy, dynamic channel selection and adaptive control of radio configuration for an 802.11a/n/ac access point and/or an LTE-U small cell base station.

Flexible agents are deployed by nature over wide geographic areas that are in varying densities and generally have overlapping coverage due to their attachment to Wi-Fi access points and LTE-U small cell base stations. Thus, the spectrum information collected by the flexible proxy (in particular, the signature of the DFS radar and the congestion condition of the local network) similarly represents a multipoint coverage measure of the radio spectrum over a wide area, or viewed differently, represents spectrum measurements made by random irregular sensor arrays measuring radar and sources of interference and/or congestion from different angles.

Fig. 17 shows how multiple

flexible agents

1711, 1712, 1713, 1714 (e.g., each attached to an 802.11a/n/acWi-Fi network) provide geographically distributed overlapping views (sets of sensor data) of a radar transmitter 1750. The figure also shows that by reporting to the centralized cloud intelligence engine 235, how the joint multiple views data, when patched together by the cloud intelligence engine 235, appear can thus be encouraged to generate attributes for both spatial diversity (different ranges and fading/

reflection channel conditions

1721, 1722, 1723, 1724) and angular diversity (e.g.,

viewing angles

1731, 1732, 1733, 1734) of the pseudo-synthetic aperture views of the target radar 1750 or any other transmitter source with significantly greater effective gain and sensitivity than represented by any single view from a single access point or small cell base station. Due to different fading and reflected channel conditions,

different positions

1721, 1722, 1723, 1724 and look-up

angles

1731, 1732, 1733, 1734 produce different timing offsets of the received radar pulse series and different distortions of the received signal. Subsets of the

flexible agents

1711, 1712, 1713, 1714 may form a pseudo-synthetic antenna array that provides improved sensitivity to radar signals due to effective higher gain, and robustness in radar detection due to redundancy. Data from

flexible agents

1711, 1712, 1713, 1714 is sent to cloud intelligence engine 235, which performs data correlation and integration to determine the location of target radar 1750.

A cloud intelligence engine with significant processing power and infinite scalable memory/storage can store time stamped spectral information from each flexible agent over a very long period of time, thus enabling the cloud intelligence engine to integrate and correlate signatures of DFS radars and congestion conditions of local networks also over time and geospatially. Given a sufficient number of flexible agents that continuously acquire spectral information over time, the cloud intelligence engine may construct increasingly accurate and reliable spatial mappings of spectral information, including the presence or absence of radar signals, in the 5GHz band. The spectral information may be location tagged and/or time stamped. The device may be, for example, an access point device, a DFS slave device, a peer-to-peer group owner device, a mobile hotspot device, a radio access node device, or a dedicated sensor node device. With this information, the client device can directly query the cloud intelligence engine to find out what DFS channels are available and no radar at the location of the client device. With this system, the client device no longer needs to wait for beacons that would otherwise be provided by the access point or flexible proxy, as the client device can communicate with the cloud intelligence engine via the network connection to determine the available channels. In this case, the cloud intelligence engine becomes a cloud DFS super master because it can provide DFS channel selection information for multiple client devices distributed over a wide geographic range.

In addition, the cloud intelligence engine can also access and combine data (data fusion) from other sources (e.g., terrain and map information from GIS (geographic information system) servers, FCC databases, NOAA databases, etc.), enabling the cloud intelligence engine to further compare, correlate, overlay, and retouch baseline spectral data from flexible agents, and augment network ad hoc algorithms to further improve the overall accuracy and robustness of the present invention.

A cloud intelligence engine with detailed pictures of the dynamic spectral conditions of the 802.11a/n/ac and LTE-U networks thus formed can use this data to compute a selection of optimal network configurations, in particular, operating channels (in both DFS and non-DFS bands) and radio parameters of individual access points and/or small cell base stations to avoid overlapping with other nearby access points or base stations, interferers, noisy or congested channels. The overall system so implemented can therefore be viewed as a large wide area closed control system, as shown in fig. 18.

In one example, the system of the present invention includes a cloud DFS super master and a plurality of radar detectors communicatively coupled to the cloud DFS super master. The radar detector is programmed to scan for radar signals in each of a plurality of 5GHz radio channels, send results of the scanning for the radar signals to the cloud DFS super master, and send geographical location information about each of the plurality of radar detectors to the cloud DFS super master. The cloud DFS super master is programmed to receive results of the scan for radar signals and geographic location information about the plurality of radar detectors from each of the plurality of radar detectors and determine whether a first radar detector of the plurality of radar detectors detects a radar signal in a first channel of the plurality of 5GHz radio channels. If the cloud DFS super master determines that a radar signal is present in the first channel, the cloud DFS super master is programmed to determine one or more radar detectors (e.g., a second radar detector) of the plurality of radar detectors to estimate detection of the radar signal by the first radar detector in the first channel based on the geographic location information about the first radar detector and the geographic location information about the second radar detector. In one example, the cloud DFS super master is programmed to cause one or more second radar detectors to switch to a first channel and scan for radar in the first channel. And in another example, the cloud DFS super master is programmed to cause one or more second radar detectors to increase dwell time in the first channel. In these examples, the cloud DFS super master may coordinate radar detectors when either detector sees radar. The network of cloud DFS super-masters and radar detectors act like a large synthetic aperture array, and the cloud DFS super-masters can control the radar detectors to take action. Some of the actions include: the radar detector or detectors are moved to the channel where radar is detected and either seek radar or are made to dwell longer in the channel where radar is detected. The more radar signals the sensor sees, the better the radar signals can be characterized. Further, by geographic location, the cloud DFS super master may determine that there are other detectors in a better location to measure or characterize the radar, and may use data from one or more detectors (e.g., fuse data from multiple detectors). This operation can be driven by historical data or by knowing the type/model of the detector. In fact, as sensors are upgraded, their sensitivity can be better than previous generations of products. The cloud DFS super master can track what detectors (and their capabilities) are deployed in a given area and optimally select which detectors will provide an adjunct validation radar scan.

Fig. 18 shows in a control loop diagram how the cloud intelligence engine takes spectral data (radar lists and patterns, whitelists, blacklists, RSSIs, noise floor, nearest neighbors, congestion & traffic signatures, etc.) from a network of flexible agents (e.g., each of the global network of flexible agents 1810) and, after storing and filtering the data (in storage 1825), combines them with similar data from flexible agents 1811, cloud data 1820 from other sources (e.g., GIS, FCC, FAA, DoD, NOAA, etc.), and user input 1835. The data is then applied to a network ad hoc computation process 1826, and the control loop performs optimized dynamic channel selection 1855 for each of the 802.11a/n/ac access points or LTE-U small cell base stations in the network under the control of the system implemented by the present invention. In this way, the cloud intelligence engine tells agile agent 1811 to change from current channel 1856 (the channel previously used by the access point) (using access point control 1812) to the selected channel 1855 for the access point. In contrast, traditional access points and small cell base stations behave as open control loops with limited single source sensor input and without the benefits of a cloud intelligence engine closed control loop.

Information from flexible agents 1811 (including spectrum and location information) is used for information from location database 1851 to resolve the location 1850 of flexible agents 1811 and 802.11a/n/ac access points or LTE-U small cell base stations in the network and under the control of flexible agents 1811. Lookup 1841 accesses the stored data from flexible agent 1810. This information may be combined with information from the resolve location step 1850 for geometric extrapolation 1842 of the spectral conditions applicable to the flexible proxy 1811 of an 802.11a/n/ac access point or LTE-U small cell base station in the network and under control of the flexible proxy 1811.

As shown in FIG. 18, the control loop includes temporal integration 1845 of data from flexible agent 1811, spatial integration 1844 of data from flexible agent 1811, and fusion 1830 with data from other sources and user inputs 1835 to make operational channel selection 1855 for flexible agent 1811. The control loop may also include buffers 1847, 1849 (time), 1843 (space), 1846 (time), and filters 1848 as desired, as shown. Other flexible agents 1810 may also have their own control loops similar to those shown in fig. 18.

As previously discussed, the flexible agent sends information to the cloud intelligence engine that includes information about the detected radar pattern (including signal strength, type of radar, and timestamp for detection). The type of radar detected includes, for example, the following information: burst duration, number of bursts, pulses per burst, burst period, sweep pattern, pulse repetition rate and spacing, pulse width, chirp width, beam width, sweep rate, pulse rise and fall times, frequency modulation, frequency hop rate, hop sequence length, and pulses per hop. The cloud intelligence engine uses this information to improve its false detection algorithm. For example, if a flexible agent detects that a particular radar type it knows is unlikely to occur in a particular location, the cloud intelligence engine may use this information in a probabilistic algorithm for evaluating the validity of the signal. The flexible agent may send the information to the cloud intelligence engine via the access point or via the client device, as shown in fig. 2.

Because the cloud intelligence engine has location information about the attached radar sensor, when the cloud intelligence engine receives a radar detection signal from one sensor, the cloud intelligence engine can use the location information about that sensor to verify the signal. The cloud intelligence engine may determine nearby sensors that are proximate to a first sensor that detected a radar signal, and search for a white/black list channel history among other sensors, and if the nearby sensors have current and sufficient information, the cloud intelligence engine may validate or invalidate initial radar detection from the first sensor.

Alternatively, the cloud intelligence engine or first sensor may instruct nearby sensors (either through the cloud or locally) to focus on the detected channels and report their whitelists and blacklists back to the cloud. If the nearby sensor has current and sufficient information, the cloud intelligence engine may validate or invalidate the initial radar detection from the first sensor. Further, based on the location information about the first sensor, the cloud intelligence engine may direct other nearby sensors to modify their scan times or characteristics or signal processing to better detect the signals detected by the first sensor.

As described above, fig. 14A and 14B illustrate the logical interface between a wireless flexible proxy, a cloud intelligence engine, and an access point (or similarly, a small cell LTE-U base station). In particular, fig. 14A-14B also illustrate examples of signaling and messages that may be exchanged between the flexible agent and the cloud intelligence engine and (via the flexible agent) between the cloud intelligence engine and the access point during phases of the DFS scanning operation, in-service monitoring (ISM), and when a radar event that forces a channel change occurs. In addition to traditional infrastructure network topologies (e.g., host access points and clients and point-to-point networks or Wi-Fi direct), the present invention also applies to extended infrastructure network topologies (e.g., mesh networks). For example, the host access point discussed herein may be a mesh peer that participates in a mesh network and simultaneously provides infrastructure connectivity.

Fig. 19A illustrates the hidden node problem, where an access point or small cell base station 1930 is hidden from view other access points or small cell base stations 1931 due to terrain, blockage, distance, or channel conditions 1945. The hidden node problem is a particularly difficult problem for mesh networks or point-to-point sessions where these access points are communicating with each other; hidden node 1930 may not detect the frame and will not be able to synchronize its Network Allocation Vector (NAV). In the event of such damage, the hidden node 1930 transmissions may potentially collide and interfere with communications between the other two

nodes

1931, 1932. As shown in fig. 19A, flexible agent 1950 reports the scan list to cloud intelligence engine 1935, but cannot detect hidden node 1930. Accordingly, flexible agent 1950 does not report hidden node 1930 to cloud intelligence engine 1935 in the reported scan list. Flexible agent 1951 associated with access point 1932 in the neighbor network also reports the scan list to cloud intelligence engine 1935. Because flexible agent 1951 may detect hidden node 1930, the reported scan list includes hidden node 1930. Cloud intelligence engine 1935 collects a scan list including geographic information about flexible agents 1950, 1951 from all flexible agents 1950, 1951. Cloud intelligence engine 1935 then determines the presence of hidden node 1930 and reports the presence of hidden node 1930 to flexible agents 1950, 1951.

Fig. 19B illustrates a hidden radar problem, where radar transmitters 1960 are not visible to agile agents 1953 due to terrain or obstructions 1955. Because flexible proxy 1953, acting as a DFS master for access point 1934, but not seeing hidden radar 1960, may generate unintentional interference, the hidden radar problem is a very serious concern of the FCC (and other regulators). For example, flexible agents 1952 near the exposed node 1933 detect radar from radar transmitter 1960 and report to cloud intelligence engine 1935 via an uplink blacklist message. For example, cloud intelligence engine 1935 notifies flexible agents 1953 near hidden node 1934 of the radar via a downlink blacklist message.

In some embodiments, a flexible proxy may be linked to multiple host access points. In one such possible configuration, significant problems arise when the networking connection between the flexible proxy on the ethernet and the access point is long. Fig. 19C illustrates the hidden radar problem of the flexible proxy not seeing the radar transmitter due to distance. The

networked nodes

1990, 1991, 1992 are remote from the radar transmitter 1975 and therefore do not detect the presence of radar signals.

Nodes

1990, 1991, 1992 pass this information to flexible broker 1970. The flexible proxy 1970 enables the corresponding whitelists and blacklists to be broadcast wirelessly and over wired connections. Hidden node 1980 receives the list from flexible agent 1970, but in front of the radar from radar transmitter 1975. For example, hidden node 1980 is separated from flexible agent 1970 by a long distance and is connected to the flexible agent by a very long ethernet connection 1981.

Because hidden node 1980 is a distant flexible agent 1970, its signature 1982 is not on the scan list of flexible agents 1970. Furthermore, because hidden node 1980 is too distant from flexible agent 1970, hidden node 1980 cannot receive a wireless white list and/or black list from flexible agent 1970, or the timestamps of the wireless list do not match the timestamps received via the ethernet when received by hidden node 1980. To address this problem, the whitelist and/or blacklist broadcast over the wired ethernet network must be matched to the list and timing broadcast over the wireless so that node 1980 uses the DFS channel. In addition, flexible proxy 1970 may broadcast a list of authorized access points (e.g., 1990, 1991, 1992), and the proxy in the controlling access point must see its SSID in the authorization list to use the DFS channel. The flexible agent 1970 authorizes only access points that it sees through the scan list and that are above a certain RSSI threshold (e.g., 1990, 1991, 1992). Access points 1980 that are not seen or have had RSSI too low are deemed too far away to use the white list of flexible agents 1970.

19A-19C illustrate how a cloud intelligence engine collecting data from multiple wireless flexible agents in proximity to a hidden node or hidden radar can discover the hidden node or hidden radar. It is now appreciated that any access point or small cell base station that has a hidden node to another access point on the same channel can now function with the hidden node and similarly any (and all) access points or small cells within detectable range of the radar signal can be directly prevented from using the radar occupied channel even if hidden to some nodes.

In one embodiment of a system using a cloud DFS super master, the cloud DFS super master receives information from a plurality of flexible proxies and/or access points. Furthermore, because the cloud DFS super master provides DFS channel information about client devices, some flexible proxies and access points will no longer need to send beacons that identify available channels. In this case, a system using a cloud DFS super master may include sensors that are radar detectors that perform the radar sensing functions of the flexible proxy described herein but do not send beacons to identify available channels.

The cloud DFS super master may provide DFS super master functionality for areas where the cloud DFS super master has sufficient information. For example, if flexible proxies and/or radar detection sensors are distributed with sufficient density in a given region, and the cloud DFS super master has received sufficient information about the region for sufficient time to determine, with sufficient certainty, a radar signal signature for the region to meet FCC or other applicable requirements, the cloud DFS super master can provide DFS master services for devices located in the region.

With the cloud DFS super-master system, traditional DFS masters and flexible proxies can eliminate or operate as sensors that continue radar detection but do not tell the client device what channel to use. In this system, the client device need not look for beacons, but instead can query the cloud DFS super master to determine what channels are available for use.

The cloud DFS super master system solves a plurality of problems inherent in the DFS master system in the prior art. For example, the cloud DFS super master system may receive information from an external source (e.g., terrain and map information from GIS servers, FCC databases, NOAA databases, dods, databases) that the cloud DFS super master uses to geo-fence an area against DFS communications in one or more channels. In one example, the DoD indicates that the cloud DFS super master prevents communication in the DFS spectrum in a given area for a certain period of time. When the device is in this area, the cloud DFS super master system will instruct the client device not to use the DFS spectrum. In another example, a cloud DFS super master is programmed to receive a request from a priority user to vacate one or more 5GHz radio channels. The priority user may be a radar manufacturer of a system that includes a radar manufacturing entity (e.g., an airport or military entity), or the priority user may be a government or emergency entity that requires priority access to the DFS spectrum. In this example, the cloud DFS super master is also programmed to send a message to client devices within the affected area of the request to empty the 5GHz radio channel instructing the client devices in response to the request from the priority user. Using this system, an aircraft or airport may request that the cloud DFS super master block the 5GHz channel along its way as it takes off. In another embodiment, the request to vacate one or more 5GHz radio channels may originate from a governmental, regulatory, or emergency system. For example, an ambulance or other emergency vehicle may send a real-time request to the cloud DFS super master to block 5GHz channels along its route to optimize communications for the emergency vehicle. Unlike the disclosed cloud DFS super master, current beaconing systems do not efficiently address this issue. The cloud DFS super master may further receive and use location information about priority users to dynamically change the area where the DFS super master instructs the device to vacate a channel requested by a priority user. This allows the DFS super-master to geo-fence a limited area to maximize the availability of DFS channels to other devices while still complying with requests for vacation from priority users.

Further, the cloud DFS super master system addresses current usage limitations of the DFS spectrum. Currently, many DFS master devices are private access points that provide access to the DFS spectrum only to member client devices. Accordingly, most users in an area cannot utilize the available DFS spectrum because they are not members of a group that has access to an access point acting as a DFS master. In this case, even if the DFS spectrum is unlicensed and generally available for public use, only select groups with access to private access points may use the DFS spectrum. The cloud DFS super master addresses this inefficiency by providing DFS channel availability information directly to client devices in any area where the cloud DFS super master has sufficient spectral information.

In addition, the cloud DFS super master system solves the problems of proliferation of LTE-U devices and interoperability of LTE-U devices and Wi-Fi devices. The LTE-U device uses the same band as the Wi-Fi device. However, Wi-Fi devices cannot detect LTE-U devices, and LTE-U devices cannot detect Wi-Fi devices. Thus, signals from LTE-U and nearby Wi-Fi devices collide with each other and interfere. The cloud DFS super master may control the timing and frequency of the connected devices. And because the cloud DFS super master can see all client devices (including LTE-U and Wi-Fi devices), the cloud DFS super master can coordinate traffic to mitigate collisions, e.g., ensure that two devices in the same area are not on the same channel. The cloud DFS super master solves the problem of nearby LTE-U and Wi-Fi devices without the LTE-U and Wi-Fi devices telling each other.

Furthermore, as discussed above, the cloud DFS super master solves the hidden node problem. And the cloud DFS super master can coordinate traffic between the client devices.

In one embodiment of the cloud DFS super master system, the cloud DFS super master connects to an access point that receives channel selection information (e.g., white list or black list) from the cloud DFS super master and transmits beacons according to the received channel selection information. In this case, the cloud DFS super master still controls channel selection with respect to the access point.

Fig. 20 illustrates an exemplary embodiment of the cloud DFS super master system 2000 with the cloud intelligence engine 2035 operating as a cloud DFS super master. In the system 2000, the cloud DFS super master 2035 is communicatively coupled to a plurality of sensors 2050, 2051, 2052 that detect radar signals in the DFS zone and detect wireless traffic information. The multiple sensors 2050, 2051, 2052 may be in a flexible agent or may be stand-alone sensors. In one example, a stand-alone sensor includes a power source and is self-contained in a housing and includes a self-contained plug-in device. The communication of the sensors with the cloud DFS super master 2035 may be continuous or intermittent. The sensors send information about the detected radar signals, traffic information, and geographic location information about the sensors to the cloud DFS super master 2035. The cloud DFS super master 2035 may also be connected to external data sources 2060 (e.g., terrain and map information from GIS servers, FCC databases, NOAA databases, DoD databases). The cloud DFS super master 2035 uses information from the sensors 2050, 2051, 2052 and the external database 2060 to determine available DFS channels for areas where the cloud DFS super master has sufficient information. Then, as shown in fig. 20, the

client devices

2080, 2081 then connect to the cloud DFS super master 2035 to request authorized DFS channels according to the location of the

client devices

2080, 2081. The

client devices

2080, 2081 send the geographic location information to the cloud DFS super master 2035 so that the cloud DFS super master 2035 can determine the appropriate channel based on the location information.

In one embodiment, a cloud DFS super master system is a system for detecting radar signals and avoiding interference with radar signals, including a cloud DFS super master, a plurality of radar detectors, and at least one client device. A plurality of radar detectors (or radar sensors) are communicatively coupled to the cloud DFS super master and programmed to scan for radar signals in each of a plurality of 5GHz radio channels, send results of the scanning for the radar signals to the cloud DFS super master, and send geographical location information about each of the plurality of radar detectors to the cloud DFS super master. A client device (or client device) is communicatively coupled to the cloud DFS super master device and programmed to send geographic location information about the client device and a request for an available 5GHz radio channel to the cloud DFS super master device. The cloud DFS super master is programmed to receive results of the scan for radar signals from each of the plurality of radar detectors, geolocation information about the client device, and a request for available 5GHz radio channels, and is programmed to determine one or more 5GHz radio channels that have no radar signals within range of the client device from results of the scan for radar signals from each of the plurality of radar detectors, geolocation information about the plurality of radar detectors, and geolocation information about the client device, and to send the one or more 5GHz radio channels to the client device that have no radar signals within range of the client device.

In another embodiment, the cloud DFS super master is programmed to receive information from an external data source and is programmed to determine one or more 5GHz radio channels without radar signals within range of the client device from the information from the external data source and results of the scan for radar signals from each of the plurality of radar detectors, geolocation information about the plurality of radar detectors, and geolocation information about the client device. For example, the external data source may be a GIS, FAA radar database, DoD radar database, FCC database, or NOAA database.

Along with the radar detection information, the plurality of radar detectors can be programmed to send wireless spectrum information (e.g., traffic, congestion, channels used by nearby access points) to the cloud DFS super master, and the cloud DFS super master is programmed to coordinate transmissions by the client devices. In this way, the cloud DFS super master may coordinate traffic with several devices including access points to reduce congestion and collisions from using the same channel at the same time. The cloud DFS super master device may apply time or frequency division coordination to improve the performance of the client device.

Fig. 21 provides an illustration of a standard point-to-point network 2190. As shown in fig. 21, an access point 2101 (e.g., a wireless access point) is connected to a Wide Area Network (WAN) 2110. The access point 2101 provides wireless access to the wide area network 2110 to

client devices

2120, 2121, 2122, 2123. The

client devices

2120, 2121, 2122, 2123 also form a point-to-point network 2100 through which the

client devices

2120, 2121, 2122, 2123 can communicate with one another without utilizing the access point 2101. Note that in this configuration,

client devices

2120, 2121, 2122, 2123 cannot use the DFS channels to communicate with each other because they do not have sufficient information about available DFS channels to allow for DFS communications that comply with regulatory standards.

Fig. 22 illustrates an embodiment of the invention where a DFS master device 2200 is coupled to a cloud intelligence engine 2255 and provides available DFS channels to

client devices

2220, 2221, 2222, 2223. As shown in this illustration, the DFS master device 2200 includes a receiver 2202 and a transmitter 2203. The DFS master device 2200 provides the spectrum information to the cloud intelligence engine 2255. Further, cloud intelligence engine 2255 is coupled to other DFS master devices 2250 that provide additional spectrum information to cloud intelligence engine 2255. The DFS master device 2200 may broadcast beacons to the

client devices

2220, 2221, 2222, 2223 to inform the

client devices

2220, 2221, 2222, 2223 of the available DFS channels. Further, the DFS master device 2200 may connect to one or more of the

client devices

2220, 2221, 2222, 2223 via installed applications on the

client devices

2220, 2221, 2222, 2223, e.g., to communicate available DFS channels. Further, cloud intelligence engine 2255 may connect to one or more of

client devices

2220, 2221, 2222, 2223 via installed applications on

client devices

2220, 2221, 2222, 2223, e.g., to deliver available DFS channels. Using the available DFS channels, the

client devices

2220, 2221, 2222, 2223 may communicate directly with each other in a point-to-point network 2290.

Fig. 23 illustrates another embodiment of the invention where the DFS master 2300 is not directly coupled to the cloud intelligence engine 2355. As shown in this illustration, the DFS master device 2300 includes a receiver 2302 and a transmitter 2303. The DFS master 2300 provides the spectrum information to the cloud intelligence engine 2355. Further, cloud intelligence engine 2355 is coupled to other DFS master 2350, which provides additional spectrum information to cloud intelligence engine 2355. The DFS master device 2300 is connected to and communicates with the cloud intelligence engine 2355 via a network connection in the

client devices

2321, 2322. In this illustration, the DFS master 2300 is connected to and in communication with the cloud intelligence engine 2355 via a network connection in two

client devices

2321, 2322, but the DFS master 2300 may be connected to and in communication with the cloud intelligence engine 2355 via a network connection in one or more client devices. Via this connection, DFS master 2300 sends spectrum information to cloud intelligence engine 2355 and receives DFS channel availability information from cloud intelligence engine 2355. The DFS master device 2300 may broadcast a beacon to the

client devices

2320, 2321, 2322, 2323 to inform the

client devices

2320, 2321, 2322, 2323 of the available DFS channels. Further, the DFS master device 2300 may be connected to one or more of the

client devices

2320, 2321, 2322, 2323 via an installed application on the

client devices

2320, 2321, 2322, 2323, e.g., to communicate available DFS channels. Further, cloud intelligence engine 2355 may connect to one or more of

client devices

2321, 2322 via an installed application on

client devices

2321, 2322, e.g., to communicate available DFS channels. Using the available DFS channels,

client devices

2320, 2321, 2322, 2323 may communicate directly with each other in a point-to-point network 2390.

FIG. 24 provides a more detailed illustration of an exemplary system of the present invention. As shown in fig. 24, the cloud intelligence engine 2435 can be connected to a plurality of DFS master devices 2400 and client or user devices 2431, 2432 forming a peer-to-peer network. The point-to-point devices 2431, 2432 may have a user control interface 2428. User control interface 2428 includes user interface 2429 to allow client devices 2431, 2432 to interact with DFS master device 2400 via cloud intelligence engine 2435. For example, the user interface 2429 can allow a user to modify DFS master device 2400 settings. The user control interface 2428 also includes a secure element 2430 to ensure that communications between the client devices 2431, 2432 and the DFS master device 2400 are secure. For example, client devices 2431, 2432 are connected to wide area network 2434 via a cellular network.

Cloud intelligence engine 2435 includes a database 2448 and a memory 2449 for storing information from DFS master 2400, one or more other DFS master connected to cloud intelligence engine 2435, and/or one or more external data sources (e.g., data source 2452). Database 2448 and memory 2449 allow cloud intelligence engine 2435 to store information associated with DFS master device 2400, other DFS master devices, and/or data source 2452 over a particular period of time (e.g., days, weeks, months, years, etc.). The data source 2452 can be associated with a database collection. Further, the data source 2452 may include regulatory information such as, but not limited to: GIS information, other geographical information, FCC information regarding the location of the radar transmitter, FCC blacklist information, NOAA database, DOD information regarding the radar transmitter, DOD requests to avoid transmissions in the DFS channel with respect to a given location, and/or other regulatory information.

Cloud intelligence engine 2435 also includes a processor 2450 to perform cloud intelligence operations described herein. In an aspect, the processor 2450 can be communicatively coupled to a memory 2449. The coupling may include various communications including, but not limited to, direct communications, indirect communications, wired communications, and/or wireless communications. In particular implementations, the processor 2450 can be operable to execute or facilitate the execution of one or more of the computer-executable components stored in the memory 2449. For example, according to an aspect, the processor 2450 may be directly involved in the execution of the computer-executable components. Additionally or alternatively, the processor 2450 may be indirectly involved in the execution of the computer-executable components. For example, the processor 2450 may direct one or more components to perform operations.

The cloud intelligence engine 2435 also learns the location of each DFS master and the access points near the DFS master that do not have a control agent and the channel on which each of these devices is operating. With this information, the spectrum analysis and data fusion engine 2443 and the network optimization ad hoc engine 2444 can optimize the local spectrum by telling the DFS master to avoid channels that are subject to interference. The group communication manager 2445 manages communications between the DFS master device, access points, client devices, and other devices in the network. The cloud intelligence engine includes a security manager 2446. The control agent manager 2447 manages all connected control agents.

The cloud intelligence engine 2435 can combine the spectrum information with other spectrum information (e.g., other spectrum information associated with the DFS master device) to generate combined spectrum information. The cloud intelligence engine 2435 can then determine one or more particular communication channels (e.g., a particular communication channel associated with the 24GHz Wi-Fi spectrum 291), and can communicate the particular communication channels to the DFS master device 2400 (e.g., via a secure communication tunnel through the client devices 2431, 2432). The DFS master device 2400 and/or the cloud intelligence engine 2435 use information from the cloud intelligence engine 2435 to determine a DFS channel to make available to the client devices 2431, 2432.

Independent of any host access point, the DFS master 2400, in the role of an autonomous DFS master, can provide channel indication and channel selection control to one or more point-to-point client devices 2431, 2432 within the coverage area by: (a) signaling availability of one or more DFS channels through simultaneous transmission of one or more beacon signals; (b) transmitting a list of authorized available DFS channels (referred to herein as a white list) and a list of forbidden DFS channels for which potential radar signals have been detected (referred to herein as a black list) via an associated non-DFS channel along with a control signal and a timestamp signal (referred to herein as a dead zone switching timer); and (c) receive control, coordination, and authorized and preferred channel selection guidance information from cloud intelligence engine 2435.

(a) The capabilities and functionality in (a) to (c) are enabled by a centralized cloud intelligence engine that collects and combines DFS radar and other spectral information and geo-tags from each DFS master, stores, filters and integrates the data over time, and combines it with information from multiple other DFS masters distributed in space through data fusion techniques, and performs filtering and other post-processing on the collection through proprietary algorithms and merging with other data from the vetted sources (e.g., GIS — geographic information systems, FAAs, FCC, and DoD databases, etc.).

Specifically, the cloud intelligence engine performs the following operations: (a) continuously collecting from all wireless DFS master devices spectrum, location and network congestion/traffic information that grows rapidly in number and density as more access points and small cell base stations are deployed; (b) continuously applying complex filtering, spatial and temporal correlation and integration operations, and novel array combining techniques and pattern recognition, etc., on the data set; (c) the network analysis and optimization techniques of the present invention are applied to computational network organizational judgments to jointly optimize dynamic channel selection of access points and small cell base stations on the network; and (d) directing adaptive control of radio configuration and dynamic channel selection of the wireless DFS master.

In the illustrated example, the DFS primary device 2400 includes a primary radio 2415 and a secondary radio 2416. The primary radio 2415 is used for DFS and radar detection. The primary radio 2415 is typically a 24GHz radio. In one example, the primary radio 2415 may be a 24GHz transceiver. DFS master device 2400 may receive radar signals, traffic information, and/or congestion information via master radio 2415. And the DFS master device 2400 may transmit information (e.g., DFS beacons) via the master radio 2415. Secondary radio 2416 is a secondary radio for sending control signals to other devices in the network. Secondary radio 2416 is typically a 21.4GHz radio. The DFS master device 2400 may receive information (e.g., network traffic, congestion, and/or control signals) via the secondary radio 2416. And DFS master device 2400 may send information (e.g., control signals) via secondary radio 2416. The primary radio 2415 is connected to a fast channel switch generator 2417, which includes a switch and allows the primary radio 2415 to quickly switch between the radar detector 2411 and the beacon generator 2412. Fast channel switch generator 2417 allows radar detector 2411 to switch fast enough to appear to be on multiple channels at once.

The independent multi-channel DFS master may include: a beacon generator 2412 for generating a beacon in each of a plurality of 24GHz DFS radio channels (e.g., a plurality of 24GHz DFS radio channels associated with the 24GHz Wi-Fi spectrum 291); a radar detector 2411 for scanning for radar signals in each of a plurality of 24GHz DFS radio channels; a 24GHz radio transceiver (e.g., primary radio 2415) for transmitting beacons in each of the plurality of 24GHz DFS radio channels and receiving radar signals in each of the plurality of 24GHz DFS radio channels; and a fast channel switch generator 2417 coupled to the radar detector, the beacon generator, and the 24GHz radio transceiver. The fast channel switch generator 2417 switches the 24GHz radio to a first channel of the plurality of 24GHz DFS radio channels and then causes the beacon generator 2412 to generate a beacon in the first channel of the plurality of 24GHz DFS radio channels. Then, fast channel switch generator 2417 causes radar detector 2411 to scan for radar signals in a first channel of the plurality of 24GHz DFS radio channels. The fast channel switch generator 2417 then repeats these steps for each other channel of the plurality of 24GHz DFS radio channels during the beacon transmission duty cycle and in some examples during the radar detection duty cycle. The beacon transmission duty cycle is the time between successive beacon transmissions on a given channel and a radar detection common duty cycle that is the time between successive scans on the given channel. Because the DFS master device 2400 cycles between beaconing and scanning in each of multiple 24GHz DFS radio channels in the time window between a first beaconing and scanning in a given channel and a subsequent beaconing and scanning in the same channel, it can provide efficient simultaneous beaconing and scanning for multiple channels.

DFS master device 2400 may also include a bluetooth radio 2414 and/or an 802.15.4 radio 2413 for communicating with other devices in the network. The DFS master device 2400 can include various radio protocols 2408 to facilitate communications via the included radios.

The DFS master device 2400 can further include a location module 2409 to geo-locate or determine a location of the DFS master device 2400. Further, DFS master device 2400 can determine the location of DFS master device 2400 by querying client devices 2431, 2432, which can have GPS or other location determining capabilities.

As shown in fig. 24, the DFS master device 2400 may include a scanning and signaling module 2410. The DFS master device 2400 includes an embedded memory 2402 (including, for example, a flash memory 2401), and an embedded processor 2403. A cloud agent 2404 in the DFS master device 2400 facilitates aggregation of information from the cloud agent 2404 through the cloud and includes a group communication protocol 2405 to facilitate communication between the DFS master device, access points, client devices, and other devices in the network. Cloud agent 2404 also includes: a security module 2406 for securing and securing cloud communications of the DFS master device 2400; and a proxy protocol 2407 for facilitating communication with access point control proxies 2419, 2424.

The roaming and guest agent manager 2438 in the cloud intelligence engine 2435 provides optimized connection information for devices connected to DFS master devices that are roaming from one access point to another (or from one access point to another network). The roaming and guest agent manager 2438 also manages guest connections to the network for the DFS master connected to the cloud intelligence engine 2435. The external data fusion engine 2439 provides integration and fusion of information from the DFS host with information from the data source 2452. For example, external data fusion engine 2439 may integrate and/or use information such as, but not limited to: GIS information, other geographical information, FCC information regarding the location of the radar transmitter, FCC blacklist information, NOAA database, DOD information regarding the radar transmitter, DOD requests to avoid transmissions in the DFS channel with respect to a given location, and/or other regulatory information. The cloud intelligence engine 2435 also includes an authentication interface 2440 for authentication of received communications and for authenticating devices and users. Radar detection calculation engine 2441 aggregates radar information from DFS master 2400, DFS master 2451, and/or data source 2452. Among other things, radar detection calculation engine 2441 also calculates the location of the radar transmitter from those data to facilitate false positive radar detection or identification of hidden nodes and hidden radars. The radar detection calculation engine 2441 may also direct or master the DFS master to dynamically adapt the detection parameters and/or methods to further improve detection sensitivity. The location calculation and proxy manager 2442 determines the location of the DFS master 2400 and other connected devices (e.g., DFS master 2151) by Wi-Fi lookup in a Wi-Fi location database, querying past devices, scan lists from the DFS master, or geometric extrapolation.

The spectrum analysis and data fusion engine 2443 and the network optimization ad hoc engine 2444 facilitate dynamic spectrum optimization through information from the DFS master 2400, other DFS masters, and/or the data source 2452. Each of the DFS master devices (e.g., DFS master device 2400 and/or other DFS master devices) connected to cloud intelligence engine 2435 has scanned and analyzed the local spectrum and passed this information to cloud intelligence engine 2435.

The DFS master device 2400 communicates a time stamp signal or a dead-band switching timer to ensure that the device does not use information including the white list beyond the useful time-to-live of the information. For example, the white list will only be valid for a particular time period. The time stamp signal avoids using the non-compliant DFS channel by ensuring that the device will use the white list without exceeding its useful time-to-live.

Fig. 25 illustrates how a cloud intelligence engine 2535 will interface with

client devices

2531, 2532, 2533 in a peer-to-peer network 2590 and a DFS master 2500 that acts as an autonomous DFS master independent of any access point. As shown in fig. 25, cloud intelligence engine 2535 can be connected to multiple (either directly or via a network-enabled device) network-connected DFS master 2500, 2510. The DFS master device 2500 in the peer-to-peer network 2500 may connect to the cloud intelligence engine 2535 through one of the network connected client devices 2531, for example, by piggybacking messages to the cloud intelligence engine 2535 when the messages are sent to the client devices 2531 or in coordination with the connection of the client devices 2531 to the wide area network 2534. In the point-to-point network 2500, the DFS master 2500 sends control signals 2520 including an indication of a channel that is not occupied (e.g., a DFS channel that is not radar signal) over the air to the

client devices

2531, 2532, 2533. Alternatively, the DFS master communicates with only one client device 2531 (e.g., a single client device 2531), the client device 2531 then acting as a group owner to initiate and control peer-to-peer communications with the

other client devices

2532, 2533.

Client devices

2531, 2532, 2533 have point-to-point links 2521 that they communicate with each other. The DFS master 2500 may operate in multiple modes that employ different algorithms to perform multiple DFS scanning methods.

Fig. 26 and 27 further illustrate DFS point-to-point networks implemented by the present invention. As shown in fig. 26, computer client devices 2621 may be coupled to a wide area network 2634. The coupling may be through an access point such as an access point. Independent of any access point, computer client device 2621 communicates with television client device 2622 via DFS channels and forms a peer-to-peer network 2690. The DFS master device 2600 communicates with at least one of the

client devices

2621, 2622 to communicate available DFS channels for peer-to-peer communication. Fig. 27 illustrates another example point-to-point network. In fig. 27, a mobile client device 2731 may be coupled to a wide area network 2734. The coupling may be through an access point such as an access point. Independent of any access point, the mobile client device 2731 communicates with the television client device 2722 and another mobile client device 2733 via DFS channels and forms a peer-to-peer network 2790 with the computer client device 2721 and the wearable client device 2732. As shown in fig. 27, each client device may communicate with one or more other client devices in a peer-to-peer network 2790. DFS master 2700 communicates with at least one of

client devices

2721, 2722, 2731, 2732, 2733 to transmit available DFS channels for point-to-point communication.

In view of the subject matter described herein, methodologies that may be implemented in accordance with the present invention will be better appreciated with reference to the flow charts of FIGS. 28-29 and with reference to FIGS. 33-43. While, for purposes of simplicity of explanation, the methodologies are shown and described as a series of blocks, it is to be understood and appreciated that the illustrated or corresponding descriptions are not limited by the order of the blocks, as some blocks may occur in different orders and/or concurrently with other blocks from what is depicted and described herein. In the case of non-sequential or branched flow illustrated by flowcharts, it is to be understood that various other branches, flow paths, and sequences of blocks may be implemented which achieve the same or similar results. Moreover, not all illustrated blocks may be required to implement the methodologies described hereinafter. Moreover, it should be further appreciated that the methodologies and/or functions disclosed hereinafter and throughout this specification are capable of being stored on an article of manufacture to facilitate transporting and transferring such methodologies to computers, e.g., as further described herein. The terms computer-readable medium, article of manufacture, and the like as used herein are intended to encompass a computer program accessible from any computer-readable device or media, such as a tangible computer-readable storage medium.

Fig. 28 illustrates an exemplary method 2800 for providing DFS spectrum access in a point-to-point wireless network in accordance with the present invention. First, at 2801, the independent multi-channel DFS master device generates spectrum information associated with a plurality of 24GHz DFS radio channels for the independent multi-channel DFS master device. The spectrum information may include information such as, for example, a white list (e.g., a white list of each of the plurality of 24GHz DFS communication channels that do not contain radar signals), a black list (e.g., a black list of each of the plurality of 24GHz DFS communication channels that contain radar signals), scan information associated with scanning of radar signals in the plurality of 24GHz DFS communication channels, status information, location information associated with the DFS master and/or client devices, time signals, scan lists (e.g., a scan list showing neighboring access points, etc.), congestion information (e.g., a number of retry packets, a type of retry packets, etc.), traffic information, and/or other spectrum information. Next, at 2802, the standalone multi-channel DFS master device transmits the spectrum information to the cloud intelligence engine through the first client device. The first client device is a network-enabled device, such as a cellular device, that can connect to a wide area network and provide connectivity to a standalone multi-channel DFS master device. The cloud intelligence engine can also receive, via one or more network devices, spectrum information associated with a plurality of 24GHz DFS communication channels from a plurality of multi-channel DFS master devices. Optionally, receiving the spectral information comprises receiving scanning information associated with scanning radar signals in a plurality of 24GHz DFS radio channels. The analysis of the plurality of 24GHz DFS communication channels may include switching a 24GHz radio transceiver of the DFS master to a channel of the plurality of 24GHz DFS communication channels, generating a beacon in the channel of the plurality of 24GHz DFS communication channels, and scanning for radar signals in the channel of the plurality of 24GHz DFS communication channels.

Next, at 2803, the method of fig. 28 includes a cloud intelligence engine generating aggregated spectrum information by aggregating spectrum information with other spectrum information. The additional spectral information may be generated by at least one other DFS master device. In one example, the spectral information may be integrated with other spectral information via one or more data fusion processes. Then, at 2804, the cloud intelligence engine determines a set of available DFS radio channels for the multi-channel DFS master device from the plurality of 24DFS GHz radio channels based at least on the integrated spectral information. For example, a communication channel may be selected from a plurality of 24GHz DFS communication channels based at least on the integrated spectral information. In an aspect, regulatory information associated with a plurality of 24GHz DFS communication channels and/or stored in at least one database may be received by a cloud intelligence engine. Further, the communication channel may be further determined based on the regulatory information. In another aspect, an indication of a communication channel can be provided to a DFS master and/or a client device.

Fig. 29 illustrates an exemplary method 2900 for providing DFS spectrum access in a point-to-point wireless network in accordance with the present invention. The method shown in fig. 29 includes the steps described with respect to fig. 28, but also includes the following optional additional steps. At 2910, the method includes the first client device receiving an available DFS radio channel and initiating communication with the second client device using the available DFS radio channel. In this step, the first client device initiates a peer-to-peer communication network using the available DFS radio channel. At 2920, the method includes the independent multi-channel DFS master device sending a beacon to the first client device indicating available DFS radio channels. In 2930, the method includes sending, via the first client device, a white list of each of the plurality of 24GHz DFS radio channels that do not contain radar signals to the cloud smart engine, and sending, via the first client device, a black list of each of the plurality of 24GHz DFS that contain radar signals to the cloud smart engine. At 2940, the method includes a cloud intelligence engine receiving regulatory information stored in at least one database. And at 2950, the step of determining the DFS radio channel includes determining which DFS radio channel to use based on the integrated spectral information and regulatory information.

As described above, the present invention is applicable to extended infrastructure network topologies (e.g., mesh networks) in addition to traditional infrastructure network topologies (e.g., host access points and clients and point-to-point networks or Wi-Fi-Direct). For example, the host access point discussed herein may be a mesh peer that participates in a mesh network and simultaneously provides infrastructure connectivity. For example, while a peer-to-peer network is described herein as including client devices that communicate with each other, and in a non-limiting aspect, through access point-to-wide area network communications, a wireless mesh network may include a communication network consisting of wireless nodes organized in a mesh configuration. For example, an exemplary wireless mesh network as described herein may include mesh clients, routers, access points, and/or gateways. In a non-limiting aspect, the wireless mesh client may comprise any of the various wireless devices described herein with reference to a point-to-point network, for example, when a router and/or access point may forward other communications for the wireless mesh client and/or a gateway that may be connected to one or more wide area networks, such as the internet. Thus, for example, as described herein, fig. 30-45 depict various systems, devices, and methods for reducing error detection and/or network downtime in an exemplary mesh network using DFS channels.

For example, fig. 30 depicts an exemplary functional block diagram of a mesh network 3000 according to various non-limiting aspects described herein. In a non-limiting aspect, the example mesh network 3000 can include any number of host devices 3002 (e.g., routers, access points, etc., configured as DFS masters (e.g., multi-channel DFS masters), as described herein, in a mesh network configuration employing DFS channels, communicating with one another, e.g., as described herein, e.g., with respect to fig. 13, 24, etc.). In conventional implementations of DFS, when a potential radar event is detected on the DFS channel, a device communicating on the DFS channel must vacate the DFS channel and remain on the DFS channel for 30 minutes within 200 milliseconds (ms). It should be noted that when the DFS channel must be vacated within 10 seconds after a radar detection event (e.g., a valid radar event), the 200ms limit is derived from a test specification that limits aggregate data transmission data within 10 seconds at 17% channel load. As a result, as described herein, a device that previously communicated on the DFS channel cannot use the DFS channel after the 10 second specification and until the 30 minute duration has expired, so the device needs to monitor the DFS channel for radar signals for 1 minute before updating the communication on the DFS channel. Generally, a DFS master is an access point with only one radio and is capable of providing a DFS master service for only one channel. As mentioned above, a significant problem with this approach is that in the event of a radar event or more commonly false detections, a single channel must be vacated and the ability to use the DFS channel is lost.

However, as shown in fig. 30, for a host device 3002 (e.g., a router, access point, etc., configured as a DFS master (e.g., a multi-channel DFS master), as described herein), communicating in the presence of various sources of interference (e.g., random noise 3004, adjacent channel leakage and/or interference from other channels, etc.), the host device 3002 can receive and/or detect 3006 such sources of interference (e.g., random noise 3004, adjacent channel leakage and/or interference from other channels, etc.), which are invalid radar events, but can be misdiagnosed as valid radar events (e.g., false radar detection or false detection), thereby causing mesh network communications to unnecessarily lose the DFS channel. Fig. 30 further depicts an example mesh network 3000 that includes any number of host devices 3002 (e.g., routers, access points, etc. configured as DFS master devices (e.g., multi-channel DFS master devices), as described herein, e.g., with respect to fig. 13, 24, etc.), which may be configured for radar information transmission 3008 in accordance with various aspects described herein. As used herein, random noise 3004 refers to any source of interference that may be misdiagnosed as a valid radar event, such as at exemplary host device 3002, or otherwise, including but not limited to noise, random or other adjacent channel interference or leakage, transient, attenuated, weak and/or transient radar pulses, and so forth.

Fig. 31 depicts another exemplary functional block diagram of a mesh network 3100 in accordance with further non-limiting aspects described herein. It should be noted that while central grid node host device 3002 is depicted as receiving 3006 random noise 3004 in fig. 30, other exemplary grid node host devices 3002 are not subject to random noise 3004. Also, fig. 31 depicts an exemplary mesh network 3100 that experiences radar 3102 (e.g., an actual radar source that can result in a detected valid radar event). While three-fifths of the example grid node host devices 3002 are shown as receiving 3104 radar 3102 in example mesh network 3100, other example grid node host devices 3002 are not. For example, as described above, an exemplary mesh node host device 3002 may be hidden, blocked from radar, and/or subject to different interference, referring to fig. 19A-19C, which illustrate hidden node or hidden radar issues (e.g., hidden node or radar from view through terrain, obstacles, distance, or channel conditions, etc.). Accordingly, in various non-limiting embodiments of the disclosed systems, methods, and devices, redundant and/or collision information, as well as related information (e.g., location information, etc.) associated with an exemplary mesh network, an exemplary mesh network node device, and so forth, may be communicated and/or utilized in order to reduce error detection and/or network downtime in an exemplary mesh network utilizing DFS channels, as described herein. Accordingly, various embodiments as described herein may include systems, methods, and devices that may use inferences and/or algorithms to distinguish random noise 3004 from radar 3102 in order to reduce error detection and/or network downtime in an exemplary mesh network using DFS channels, as described herein.

Fig. 32 depicts other exemplary functional block diagrams of a mesh network 3200 according to yet another non-limiting aspect described herein. For example, fig. 32 depicts a set of exemplary mesh network node host devices 3202, one or more of which include a host device 3206 configured as a DFS master (e.g., a primary DFS master, e.g., a multi-channel DFS master)) and an embedded flexible proxy 3208 configured as a DFS master (e.g., a secondary DFS master such as a multi-channel DFS master), as described herein, e.g., with respect to fig. 2, 13, 24, etc. Fig. 32 also depicts an exemplary mesh network node host device 3206 configured as a DFS master (e.g., a primary DFS master) and a set 3204 of distributed flexible proxies 3208 (configured as secondary DFS masters as described herein), e.g., with respect to fig. 2, 13, 24, etc. Note that as described herein, using an embedded flexible proxy 3208 configured as a secondary DFS master, e.g., with respect to fig. 2, 13, 24, etc., or using a set of distributed flexible proxies 3208 configured as a secondary DFS master, e.g., with respect to fig. 2, 13, 24, etc., both of which can provide information regarding redundancy and/or collision of radar/noise detection, as well as related information (e.g., location information, channel switch information, etc.), in order to reduce error detection and/or network downtime in an exemplary mesh network using DFS channels, as described herein, while employing a set of distributed flexible proxies 3208 can also provide other information (e.g., location information, channel switch information, etc.), whereas radar information transfer 3008 in the case of embedded flexible agent 3208 may be facilitated internally by device communication functionality. Note that radar information transfer 3008 may also employ embedded communication channels, wired communication channels, wireless communication, whether in DFS channels or otherwise, out-of-band communication channels (e.g., Bluetooth, etc.), and the like. Additionally, while figures 30-32 depict various configurations of exemplary mesh networks, exemplary mesh network nodes, and combinations thereof for purposes of illustration and not limitation, it is to be understood that the arrangement of the exemplary mesh networks employing the various non-limiting systems, methods, and apparatus is not actually limiting.

For example, although not shown in fig. 30-32, an exemplary mesh network may include various other devices or mesh nodes, such as non-DFS master nodes, client devices, routers, access points, gateways, etc., as well as other devices and systems, such as cloud intelligence engines, or portions thereof, that may employ aspects of the exemplary methods described herein, or send or receive communications or other transmissions accompanying or with aspects of using the exemplary methods described herein, e.g., with respect to fig. 2, 13-14, 24, etc.

Thus, in a non-limiting aspect, an exemplary mesh node may be configured to store one or more of its location, distance, proximity, etc., relative to other mesh nodes in the mesh. According to further aspects described herein, an example mesh node may be configured to detect radar 3102 (e.g., an actual radar source that can result in a detected valid radar event), communicate radar events in an example mesh network (e.g., radar info transmission 3008, regarding suspicious radar events, verified radar events, etc.), communicate radar events to the cloud, and/or communicate radar events to nearby devices, whether mesh network devices or otherwise, e.g., radar info transmission. According to further aspects described herein, an example mesh node, cloud intelligence engine, nearby device, etc. may be configured to vote based on whether similar radar events (e.g., suspicious radar events, etc.) are also detected, and may be configured to communicate the vote back to the originating mesh network node or device. Based on voting, inference, and algorithms from other mesh nodes or devices in the mesh network, the initiating mesh node or device may then perform an inference or algorithm configured to generate a determination of whether the radar event detected by itself and/or other combinations of voting devices is a valid radar event (e.g., radar 3102 from an actual radar source), as described herein.

Thus, in an exemplary mesh network, if one mesh node of the exemplary mesh network detects radar, various embodiments as described herein may compare such information to radar information transmitted by neighboring mesh nodes in the mesh network. Referring again to fig. 30 and 31, for

example mesh networks

3000, 3100 in which each example mesh node host device 3002 is aware of its location, distance, proximity, etc., relative to other example mesh node host devices 3002 in the mesh network, if the central mesh node host device 3002 detects radar (e.g., which may be the result of receiving 3006 random noise 3004 in fig. 30), then at least some of the neighboring mesh nodes are also likely to also detect radar. In this non-limiting example, since other example mesh node host devices 3002 in the mesh network do not detect radar (e.g., as a result of not receiving or experiencing random noise 3004 in fig. 30), it may be inferred that the central mesh node host device 3002 or others may determine that the detected signal is not a valid radar event (e.g., false radar detection or false detection) according to further non-limiting aspects based on one or more algorithms, votes, locations, distances, and/or proximities, etc., in the mesh network relative to the other example mesh node host devices 3002. As a result, rather than unnecessarily vacating the DFS channel according to the central mesh node host device 3002 that detected the suspect radar event (e.g., which may be the result of receiving 3006 random noise 3004 in fig. 30), various embodiments as described herein may determine whether such suspect radar event is a valid radar event, e.g., from radar 3102 (e.g., an actual radar source that can result in a detected valid radar event), based on radar information transmissions 3008 and/or other information, inferences, and/or algorithms in exemplary neighboring mesh nodes in an exemplary mesh network.

In another non-limiting example, an example embodiment may include an example apparatus configured for DFS detection, as described herein. For example, as described above, a standalone autonomous DFS master or flexible proxy may be incorporated into another device, such as an access point, LTE-U host, base station, cell or small cell, media or content stream distributor, speaker, television, handset, mobile router, software access point device, or peer device, but is not limited to such. In another non-limiting aspect, after a suspicious radar event is detected, instead of vacating all DFS channels and listening only, appropriately configured example devices may be directed, e.g., by a flexible agent, DFS master, etc., to focus on listening on the same DFS channel with the suspicious radar event to create redundant radar event information. Thus, in another non-limiting aspect, such redundant radar event information can be transmitted throughout a network (e.g., an exemplary mesh network) in order to further reduce instances of false radar detection and resulting network downtime associated with false detections.

In another non-limiting example, given multiple devices on a network using DFS detection, various embodiments may employ inferences and algorithms that employ this redundant radar event information, as described herein, in order to further reduce instances of false radar detection. For example, in an exemplary mesh network of five nodes, each of which includes an exemplary DFS detector, as described above with respect to fig. 30-31, for example, if the central mesh node host device 3002 detects radar (e.g., which may be the result of receiving 3104 radar 3102 in fig. 31), then it is likely that at least some neighboring mesh node host devices 3002 also detect radar. Various non-limiting embodiments may infer that the radar event sensed by central grid node host device 3002 is a valid radar event if one or more of the other four neighboring grid node host devices 3002 also detect that radar also senses radar events. Thus, by utilizing knowledge of location, distance, proximity, etc., relative to other mesh nodes in the exemplary mesh network, various embodiments described herein may further ensure that spurious interference (e.g., noise, etc.) on the DFS channel is a radar signal that is not mistaken for a true, thereby further reducing the likelihood of false detection and/or redundant network downtime.

In a non-limiting aspect, exemplary embodiments as described herein may be configured to do one or more of the following: performing radar information transfer 3008 (e.g., including sending a call for verification from a neighboring grid node of a detected radar event), performing voting (e.g., receiving a call for verification of a radar event detected by a neighboring grid node, determining and transferring its vote for radar detection and/or voting status), and receiving voting results prompted by a neighboring grid node that detected a radar event. In another non-limiting aspect, radar information transmission 3008 may be by employing one or more action frames (limited by 200 ms) and/or using coded beacons, e.g., as further described herein. In another non-limiting aspect, the voting can be performed by employing one or more data frames that are limited by 200ms after the detected radar event and/or by employing a subsequent coded beacon, e.g., as further described herein.

Returning to fig. 32, in another non-limiting aspect, one or more exemplary grid nodes may embed one or more flexible agents and/or radar detectors or sensors, e.g., as described further herein with respect to fig. 2, 20, 32, etc. To reduce the likelihood of false detections, an example grid node (e.g., a host device 3206 configured as a DFS master, an embedded flexible agent 3208 configured as a DFS master, etc.) may use multiple radar detectors or sensors (e.g., a primary DFS master, e.g., a multi-channel DFS master, a secondary DFS master, e.g., a multi-channel DFS master) to validate detected radar events. In another non-limiting aspect, one or more flexible agents and/or radar detectors or sensors (whether embedded or distributed) can have different priorities (e.g., primary DFS master, secondary DFS master, etc.) and/or characteristics, and the ultimate decision of whether a detected radar event is valid can be determined by data fusion of the plurality of flexible agents and/or radar detectors or sensors, e.g., as described herein with respect to fig. 2, 14A, 14B, etc. As non-limiting examples, an exemplary grid node may include two radar detectors or sensors, e.g., as further described herein with respect to fig. 2, 20, 32, etc., e.g., a sensor on the primary radio 215 interface, and another sensor on a dedicated radar sensing device, such as an embedded flexible agent 3208, a DFS master configured as fig. 20, etc., a standalone flexible agent and/or a radar detector or sensor. An exemplary inference for validating a detected radar event may include a conclusion that the detected radar event is valid in the event that both sensors detect the same radar event, where the probability that the detected radar event is a true radar (e.g., radar 2102) event may be presumed to be high. Another example inference for validating detected radar events may include a conclusion that the detected radar events are probabilistically valid (e.g., two of three radar sensing grid nodes detected, three of five radar sensing grid nodes detected, two of ten radar sensing grid nodes detected in a geographically dispersed radar sensing mesh network, above a predetermined threshold, etc.). In an alternative non-limiting aspect, another predetermined threshold may be employed, wherein if the number of radar sensing grid nodes that detect a radar event is below the predetermined threshold, the example grid node may determine that a longer period of time is to be employed to determine whether more radar signals may be detected. According to a further non-limiting aspect, the exemplary mesh node may further determine and temporarily suspend its transmitter in order to focus on radar detection and collection of further radar signals.

Fig. 33 depicts an example method 3300 for reducing error detection and/or network downtime in an example mesh network employing DFS channels, in accordance with various non-limiting aspects. Fig. 33 depicts a portion of an exemplary mesh network 3200 that includes an exemplary mesh network node host device 3206 configured as a DFS master (e.g., a primary DFS master) and a set 3204 of distributed flexible proxies 3208 configured as secondary DFS masters, as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc. Fig. 33 also depicts an exemplary mesh network 3200 in which there is a burst of radar 3102, which includes a series of radar pulses (e.g., radar pulses of a Pulse Repetition Interval (PRI)). In a non-limiting aspect, fig. 33 depicts an exemplary mesh network node host device 3206 of a DFS master device (e.g., a master DFS master device) configured to detect a first radar pulse 3302 in a series of radar pulses of a radar 3102 burst. As further described herein, an exemplary mesh network node host device 3206 configured as a DFS master device (e.g., a master DFS master device) may make an independent determination, e.g., as shown, that a suspicious radar event has been detected, with respect to fig. 2, 13, 14, 24, etc. Subsequently, fig. 33 depicts the first of the set 3204 of distributed flexible agents 3208 configured as a secondary DFS master detecting the third radar pulse 3302 of the series of radar pulses of the radar 3102 burst, whereupon the first of the set 3204 of distributed flexible agents 3208 may engage in radar information transfer 3008, as further described herein. It should be noted that the radar information transfer 3008 may be conducted in response to a call from an exemplary mesh network node host device 3206 that is configured as a DFS master (e.g., a primary DFS master) based on its own detection and signaling of suspicious radar events or a first one of a set 3204 of distributed flexible proxies 3208 based on a secondary DFS master configured to detect a third radar pulse 3302, as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc. Fig. 33 depicts a second one of the set 3204 of distributed flexible agents 3208 (configured as a secondary DFS master) detecting a sixth radar pulse 3302 of the series of radar pulses of the radar 3102 burst, whereupon the second one of the set 3204 of distributed flexible agents 3208 may also perform radar information transfer 3008, as further described herein. In various non-limiting embodiments, a suspected radar event detected by an exemplary mesh network node host device 3206 configured as a DFS master device (e.g., a master DFS master device), a first one of the set 3204 of distributed flexible agents 3208 may make a radar information transfer 3008, a second one of the set 3204 of distributed flexible agents 3208 configured as a secondary DFS master device may be validated according to inferences, algorithms, voting, and/or data fusion, etc., described further herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc. Note that as shown in fig. 33, exemplary inferences for validating detected radar events include: the conclusion that the detected radar event is valid is determined based on the probability of exceeding a threshold (e.g., three of the three radar sensing grid nodes detected a suspicious radar event within a predetermined time period, e.g., a small digital multiple of the PRI after the suspicious radar event was first detected, etc.).

Thus, at 3304, fig. 33 depicts an example method 3300 that includes a host device of an example mesh network 3200 (e.g., an example mesh network node host device 3206 configured as a DFS master, e.g., a primary DFS master) operating on channel X (e.g., transmitting and sensing DFS channels), as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc. At 3306, the example method 3300 may include any DFS master (e.g., primary DFS master, secondary DFS master, multi-channel DFS master, standalone DFS master, flexible agent 3208, whether embedded or distributed, etc.) detecting a suspicious radar event, as further described herein. In contrast to FIG. 33, FIG. 34 depicts that the first of a set 3204 of distributed flexible agents 3208 may perform radar messaging 3008 after a suspicious radar event is first detected. Moreover, exemplary method 3300 can further include, at 3308, collecting radar information from a plurality of DFS masters (e.g., a primary DFS master, a secondary DFS master, a multi-channel DFS master, a standalone DFS master, a flexible agent 3208, whether embedded or distributed, etc.), as further described herein. As described herein, the radar information conveyance 3008 may be in progress in response to a call from an exemplary mesh network node host device 3206 that is configured as a DFS master (e.g., a primary DFS master) based on its own detection and signaling of suspicious radar events or a first one of a set 3204 of distributed flexible proxies 3208 based on a secondary DFS master configured to detect a third radar pulse 3302, such as described with respect to fig. 2, 13, 14, 24, etc., and may be collected among the exemplary mesh network 3200 mesh nodes, whether employing a cloud intelligence engine or otherwise. The example method 3300 may further include, at 3310, processing the collected radar information to facilitate determining validity with respect to one or more detected radar events or lack thereof among the example mesh nodes of the example mesh network 3200. As shown in fig. 33, an exemplary inference at 3312 verifying that one or more detected radar events result in the detected radar event being valid may be based on a probability of exceeding a threshold (e.g., three of the three radar sensing grid nodes detecting a radar event within a predetermined time period, such as a small digital multiple of the PRI after a first detection of a suspect radar event, etc.).

Fig. 34 depicts further non-limiting aspects of an example method 330 for reducing error detection and/or network downtime in an example mesh network employing DFS channels. It will be appreciated that the non-limiting embodiment of FIG. 34 can represent the following: an exemplary mesh network node host device 3206 configured as a DFS master device (e.g., a master DFS master device) may be hidden, blocked from radar 3102, and/or subject to different interference, as described above with respect to fig. 31 and 19A-19C, where hidden node or hidden radar issues are illustrated (e.g., hidden node or radar from view through terrain, obstacles, distance, or channel conditions, etc.). As with fig. 33, fig. 34 depicts a portion of an exemplary mesh network 3200 that includes an exemplary mesh network node host device 3206 configured as a DFS master (e.g., a master DFS master) and a set 3204 of distributed flexible proxies 3208 configured as secondary DFS masters, as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc. Fig. 34 also depicts an exemplary mesh network 3200 in which there is a burst of radar 3102, which includes a series of radar pulses (e.g., radar pulses of a PRI). In a non-limiting aspect, fig. 34 illustrates an exemplary mesh network node host device 3206 configured as a DFS master (e.g., a master DFS master) that is unable to detect any radar pulse 3302 in a series of radar pulses of a radar 3102 burst. Meanwhile, fig. 34 depicts the first of a set 3204 of distributed flexible agents 3208 configured as a secondary DFS master detecting the third radar pulse 3302 of a series of radar pulses of a radar 3102 burst, whereupon the first agent 3208 of the distributed flexible set 3204 may engage in radar information transfer 3008, as further described herein. As described above, radar information communication 3008 may be based on a first one of the set 3204 of distributed flexible agents 3208 configured as a secondary DFS master, which detects a third radar pulse 3302, as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc. Fig. 34 also depicts a second one of the set 3204 of distributed flexible agents 3208 configured as a secondary DFS master device that detects the sixth radar pulse 3302 of the series of radar pulses of the radar 3102 burst, whereupon the second one of the set 3204 of distributed flexible agents 3208 may also perform radar information transfer 3008, as further described herein. In various non-limiting embodiments, a suspicious radar event detected by the set 3204 of distributed flexible agents 3208 can perform radar information transfer 3008, and a second one of the set 3204 of distributed flexible agents 3208 configured as a secondary DFS master can be validated according to inferences, algorithms, voting, and/or data fusion, etc., as further described herein, e.g., with respect to FIGS. 2, 13, 14, 24, 30-32, etc. Note that as shown in fig. 34, exemplary inferences for validating detected radar events include: the conclusion that the detected radar event is valid is determined based on the probability (e.g., that two of the three radar sensing grid nodes detected a suspicious radar event within a predetermined time period, such as a small digital multiple of the PRI after the suspicious radar event was first detected, etc.).

Accordingly, at 3304, fig. 34 depicts an example method 3300 that includes a host device of an example mesh network 3200 (e.g., an example mesh network node host device 3206 configured as a DFS master, e.g., a master DFS master) operating on channel X (e.g., transmitting and sensing DFS channels) as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc. At 3306, the example method 3300 may include any DFS master (e.g., primary DFS master, secondary DFS master, multi-channel DFS master, standalone DFS master, flexible agent 3208, whether embedded or distributed, etc.) detecting a suspicious radar event, as further described herein. Moreover, exemplary method 3300 can further include, at 3308, collecting radar information from a plurality of DFS masters (e.g., a primary DFS master, a secondary DFS master, a multi-channel DFS master, a standalone DFS master, a flexible agent 3208, whether embedded or distributed, etc.), as further described herein. As described herein, radar information transmission 3008 may be based on a first one of the set 3204 of distributed flexible agents 3208 configured as a secondary DFS master, detecting a third radar pulse 3302, etc., as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc., and may be collected among the exemplary mesh network 3200 mesh nodes, whether employing cloud intelligence engines or otherwise. The example method 3300 may further include, at 3310, processing the collected radar information to facilitate determining validity with respect to one or more detected radar events or lack thereof among the example mesh nodes of the example mesh network 3200. As shown in fig. 34, the determination that verifying that the one or more detected radar events is valid for the radar event detected at 3312 may be based on a probability of exceeding a threshold (e.g., two of the three radar sensing grid nodes detected a suspect radar event within a predetermined time period, such as a small digital multiple of the PRI after the first detection of the suspect radar event, etc.).

Fig. 35 depicts other example methods 3500 for reducing error detection and/or network downtime in an example mesh network employing DFS channels in accordance with various non-limiting aspects. Fig. 35 depicts a portion of an exemplary mesh network 3200 that includes an exemplary mesh network node host device 3206 configured as a DFS master (e.g., a primary DFS master) and a set 3204 of distributed flexible proxies 3208 configured as secondary DFS masters, as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc. Fig. 35 also depicts an exemplary mesh network 3200 that is not a valid radar event but may be misdiagnosed as a valid radar event (e.g., false radar detection or false detection) in the presence of an interference source (e.g., random noise 3004, adjacent channel leakage from other channels, and/or interference from other channels, etc.). As described above, random noise 3004 refers to any interference source that may be misdiagnosed as a valid radar event, e.g., at the example mesh network node host device 3206, or otherwise, including but not limited to noise, random or adjacent channel interference or leakage, transient, decaying, weak and/or transient radar pulses, and so forth. In a non-limiting aspect, fig. 35 depicts an exemplary mesh network node host device 3206 configured as a DFS master (e.g., a master DFS master) that detects a first pulse (e.g., a radar pulse of a PRI) that may occur as radar pulse 3302 in a series of radar pulses of a radar 3102 burst that is not present in the environment of the exemplary mesh network 3200 as shown in fig. 35. As further described herein, an exemplary mesh network node host device 3206 configured as a DFS master device (e.g., a master DFS master device) may independently determine that it has detected a suspicious radar event, as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc. Subsequently, fig. 35 depicts the first and second of the set 3204 of distributed flexible agents 3208 configured as secondary DFS masters not detecting any subsequent expected radar pulse 3302 in the series of radar pulses (e.g., a radar pulse of a radar 3102 burst, which is not present in the environment of the exemplary mesh network 3200), and thus the first and second of the set 3204 of distributed flexible agents 3208 do not perform radar information transmission 3008, as further described herein. It should be noted that as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc., the radar information conveyance 3008 of one or more of the first or second of the set 3204 of distributed flexibility agents 3208 configured as secondary DFS masters may be considered an indication of: the first pulse detected, which may be detected by the example mesh network node host device 3206 configured as a DFS master (e.g., a master DFS master), as a radar pulse 3302 of a series of radar pulses (e.g., of a PRI) of the radar 3102 burst, either alone or in conjunction with an independent analysis of the example mesh network node host device 3206 configured as a DFS master (e.g., a master DFS master), is a null detected radar event. In non-limiting aspects, the determination of the invalidity of the detected first pulse may be made passively (e.g., by waiting and noting the lack of radar information transmission 3008 from one or more of the first or second of the set 3204 of distributed flexible agents 3208, which is configured as a secondary DFS master, independent analysis of the detected first pulse, etc.) or actively (e.g., radar information transmission 3008 may be made in response to a call from the exemplary mesh network node host device 3206, which is configured as a DFS master (e.g., a primary DFS master), where the radar information transmission 3008 includes the lack of negative acknowledgement of radar on the DFS channel, etc.). In various non-limiting embodiments, suspected radar events (e.g., first detected pulses) detected by the example mesh node host device 3206, which is configured as a DFS master (e.g., a master DFS master), can be validated according to inferences, algorithms, voting, and/or data fusion, etc., as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc. Note that as shown in fig. 35, an exemplary inference for invalidating a detected radar event (e.g., a first detected pulse) includes based on a probability that the detected radar event is invalid being below a threshold (e.g., one of the three radar sensing grid nodes detects a suspect radar event within a predetermined time period, e.g., after the first detection of the suspect radar event, such as a small digital multiple of the PRI, etc.).

Accordingly, at 3502, fig. 35 depicts an example method 3500 that includes a host device of an example mesh network 3200 operating on channel X (e.g., an example mesh network node host device 3206 configured as a DFS master, e.g., a master DFS master) (e.g., transmitting and sensing DFS channels), as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc. At 3504, exemplary method 3500 can include any DFS master (e.g., primary DFS master, secondary DFS master, multi-channel DFS master, standalone DFS master, flexible agent 3208, whether embedded or distributed, etc.) detecting a suspicious radar event, as further described herein. Moreover, exemplary method 3500 can further include collecting radar information 3506 from a plurality of DFS master devices (e.g., a primary DFS master device, a secondary DFS master device, a multi-channel DFS master device, a standalone DFS master device, a flexible agent 3208, whether embedded or distributed, etc.), as further described herein. As described herein, the radar information conveyance 3008 may be conducted in response to a call from an example mesh network node host device 3206 that is configured as a DFS master device (e.g., a master DFS master device) based on its own detection and signaling of a suspect radar event (e.g., a first detected pulse) or another of the first or second set 3204 of distributed flexible agents 3208 based on a secondary DFS master device configured to detect a suspect radar event (e.g., a first detected pulse), etc., such as described with respect to fig. 2, 13, 14, 24, etc., and may be collected among example mesh network 3200 mesh nodes, whether employing a cloud intelligence engine or otherwise. It is further noted that the lack of radar information transmission 3008 by other example mesh network 3200 mesh nodes during a time frame of interest may be used to infer that no other example mesh network 3200 mesh node experienced a suspected suspicious radar event (e.g., a detected pulse). Example method 3500 may further include processing the collected radar information, or lack thereof, at 3508 to facilitate determining a validity, or lack thereof, of one or more detected radar events among the example mesh nodes of mesh network 3200. As shown in fig. 35, an exemplary inference to invalidate a detected radar event (e.g., a first detected pulse) results in determining that the detected radar event is invalid at 3510 based on a probability below a threshold (e.g., one of the three radar sensing grid nodes detects a suspect radar event within a predetermined time period, such as a small digital multiple of the PRI after the suspect radar event is first detected, etc.).

Fig. 36 depicts further non-limiting aspects of an example method 3300 for reducing error detection and/or network downtime in an example mesh network employing DFS channels. Fig. 36 depicts an example method 3300 for reducing error detection and/or network downtime in an example mesh network employing DFS channels, in accordance with various non-limiting aspects. Fig. 36 depicts a portion of an exemplary mesh network 3200 that includes an exemplary mesh node host device 3206 configured as a DFS master device (e.g., a master DFS master device), and an exemplary secondary DFS master device 3208, which may include an embedded or distributed flexibility agent configured as a secondary DFS master device, as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc. Fig. 36 further depicts an exemplary mesh network 3200 that includes a series of radar pulses (e.g., radar pulses of a PRI) in the presence of a radar 3102 burst. In a non-limiting aspect, fig. 36 illustrates an exemplary secondary DFS master 3208 that detects a third radar pulse 3302 in a series of radar pulses of a radar 3102 burst. As further described herein, an exemplary secondary DFS master 3208, which may include an embedded or distributed flexible proxy configured as a secondary DFS master, may independently determine that it has detected a suspicious radar event, as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc. Subsequently, fig. 36 does not show an exemplary mesh network node host device 3206 configured as a DFS master device (e.g., a master DFS master device) nor an exemplary secondary DFS master device 3208 to detect a subsequent burst of radar pulses 3302 in a series of radar pulses of radar 3102, the exemplary secondary DFS master device 3208 to perform radar information transfer 3008, as further described herein. It should be noted that the radar information transfer 3008 may be conducted in response to a call from the example mesh network node host device 3206, which is configured to detect the third radar pulse 3302 based on a DFS master device (e.g., a primary DFS master device) (not shown) that is itself signaling and suspicious radar events or based on the example secondary DFS master device 3208, as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc. In various non-limiting embodiments, suspicious radar events detected by the example secondary DFS master device 3208 can be validated based on inferences, algorithms, voting, and/or data fusion, etc., as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc. It should be noted that exemplary inferences for validating a detected radar event include determining a conclusion that the detected radar event is valid based on a probability that a threshold is exceeded (e.g., any radar sensing grid node detecting a suspicious radar event having a particular radar-related characteristic, etc.). It should be noted that fig. 36 may be appropriate in particular instances of embodiments of the operation of the disclosed embodiments. As a non-limiting example, the example secondary DFS master device 3208 may be associated with highly sensitive and accurate radar detection in a DFS channel, e.g., regulatory information available through a cloud intelligence engine may indicate a lower threshold or higher flexibility for operation in the DFS channel in the context of radar in a particular geographic area, a particular time, a special case, etc.

Thus, at 3304, fig. 36 depicts an example method 3300 that includes a host device of an example mesh network 3200 (e.g., an example mesh network node host device 3206 configured as a DFS master, e.g., a master DFS master) operating on channel X (e.g., transmitting and sensing DFS channels), as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc. At 3306, the example method 3300 may include any DFS master (e.g., primary DFS master, secondary DFS master, multi-channel DFS master, standalone DFS master, flexible agent 3208, whether embedded or distributed, etc.) detecting a suspicious radar event, as further described herein. In contrast to fig. 33, fig. 36 illustrates that an exemplary secondary DFS master device 3208 may perform radar information transfer 3008 after first detecting a suspicious radar event. Moreover, exemplary method 3300 can further include, at 3308, collecting radar information from a plurality of DFS masters (e.g., a primary DFS master, a secondary DFS master, a multi-channel DFS master, a standalone DFS master, a flexible agent 3208, whether embedded or distributed, etc.), as further described herein. As described herein, the radar information transmission 3008 may be in response to a call from the example mesh network node host device 3206, which is configured to detect a third radar pulse 3302, etc., based on its own DFS master (e.g., a primary DFS master) (not shown) that detects suspicious radar events and signaling thereof, or based on the example secondary DFS master 3208, as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc., and may be collected among the example mesh network 3200 mesh nodes, whether employing a cloud smart engine or otherwise. The example method 3300 may further include, at 3310, processing the collected radar information to facilitate determining validity with respect to one or more detected radar events or lack thereof among the example mesh nodes of the example mesh network 3200. As shown in fig. 36, the determination at 3312 that an exemplary inference that verifying one or more detected radar events results in the detected radar event being valid may be based on a probability of exceeding a threshold (e.g., any radar sensing grid node detecting a radar event suspected of having a particular radar-related characteristic, etc.).

Fig. 37 depicts further non-limiting aspects of an example method 3500 for reducing error detection and/or network downtime in an example mesh network using DFS channels. Fig. 37 depicts portions of an exemplary mesh network 3200 that includes an exemplary mesh network node host device 3206 configured as a DFS master (e.g., a primary DFS master) and an exemplary secondary DFS master 3208, which may include an embedded or distributed flexible proxy configured as a secondary DFS master, as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc. Fig. 37 also depicts an exemplary mesh network 3200 in the presence of an interference source (e.g., random noise 3004, adjacent channel leakage from other channels, and/or interference from other channels, etc.), which is not a valid radar event, but may be misdiagnosed as a valid radar event (e.g., false radar detection or false detection). As described above, random noise 3004 refers to any interference source that may be misdiagnosed as a valid radar event, e.g., at the example mesh network node host device 3206, or otherwise, including but not limited to noise, random or adjacent channel interference or leakage, transient, decaying, weak and/or transient radar pulses, and so forth. In a non-limiting aspect, fig. 37 depicts an example mesh network node host device 3206 configured as a DFS master (e.g., a master DFS master) that detects a series of radar pulses (e.g., pulses of a PRI) that may occur a radar pulse 3302 in a series of radar pulses of a radar 3102 burst, which is not present in the environment of an example mesh network 3200, as shown in fig. 37. As further described herein, an exemplary mesh network node host device 3206 configured as a DFS master device (e.g., a master DFS master device) may independently determine that it has detected a suspicious radar event, as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc. Fig. 37 depicts an exemplary secondary DFS master 3208 that detects that a subsequent pulse of radar pulses 3302 may occur in a series of radar pulses (e.g., a radar pulse of a radar 3102 burst that is not present in the environment of the exemplary mesh network 3200), so the exemplary secondary DFS master 3208 may perform radar information transmission 3008, as further described herein. It should be noted that, for example, as shown with respect to fig. 2, 13, 14, 24, etc., radar information transmission 3008 of the exemplary secondary DFS master 3208 may be considered an indication of: an independent preliminary determination or analysis of detected pulses (e.g., votes) or associated information, which may be considered pulses detected at the exemplary secondary DFS master 3208, which may be radar pulses 3302 (e.g., radar pulses of a PRI) in a series of radar pulses of a radar 3102 burst, detected by the exemplary secondary DFS master 3208, is an invalid detected radar event, either independently or in conjunction with an independent analysis of a mesh network node host device 3206, which is exemplary configured as a DFS master (e.g., a primary DFS master). Further, in a further non-limiting aspect, the determination of the invalidity of the detected first pulse may be made passively (e.g., by waiting and noticing a burst of a series of radar pulses (e.g., radar pulses of a PRI) of the radar 3102 of the radar pulses 3302 in the series of radar pulses, noticing a lack of radar information conveyance 3008 (not shown) from the example secondary DFS master 3208, based on an independent analysis of the detected first pulse, etc.) or actively (e.g., radar information conveyance 3008 may be made in response to a call from the example mesh network node master 3206, which is configured as a DFS master (e.g., a primary DFS master), where the radar information conveyance 3008 includes radar on the lack of negative acknowledgement DFS channels, etc.). In various non-limiting embodiments, a suspicious radar event (e.g., a first detected pulse) detected by the example mesh node host device 3206 configured as a DFS master device (e.g., a master DFS master device) may be invalidated based on inference, algorithms, voting, and/or data fusion, etc., as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc. Note that as shown in fig. 37, exemplary inferences for invalidating detected radar events (e.g., first detected pulse) include detecting pulse characteristics that do not satisfy predetermined characteristics based on detected radar events (e.g., PRI after first detecting a suspect radar event, etc.) and/or voting.

Accordingly, at 3502, fig. 37 depicts an example method 3300 that includes a host device of an example mesh network 3200 (e.g., an example mesh network node host device 3206 configured as a DFS master, e.g., a master DFS master) operating on channel X (e.g., communicating and sensing DFS channels), as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc. At 3504, exemplary method 3500 can include any DFS master (e.g., primary DFS master, secondary DFS master, multi-channel DFS master, standalone DFS master, flexible agent 3208, whether embedded or distributed, etc.), detecting suspicious radar events, as further described herein. Moreover, exemplary method 3500 can further include collecting radar information 3506 from a plurality of DFS master devices (e.g., a primary DFS master device, a secondary DFS master device, a multi-channel DFS master device, a standalone DFS master device, a flexible agent 3208, whether embedded or distributed, etc.), as further described herein. As described herein, the radar information transfer 3008 may be in response to a call from the example mesh network node host device 3206, which is configured to detect a suspected radar event based on its own detection (e.g., a primary DFS master), a DFS master (e.g., a primary DFS master), a first detection pulse) and signaling thereof, or based on the example secondary DFS master 3208 detecting a suspected radar event (e.g., a detected pulse), etc., as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc., and may be collected among the example mesh network 3200 mesh nodes, whether using a cloud intelligence engine or otherwise. It is further noted that the lack of radar information transmission 3008 by other example mesh network 3200 mesh nodes during a time frame of interest may be used to infer that no other example mesh network 3200 mesh node experienced a suspected suspicious radar event (e.g., a detection pulse). Example method 3500 may further include processing the collected radar information, or lack thereof, at 3508 to facilitate determining a validity, or lack thereof, of one or more detected radar events among the example mesh nodes of mesh network 3200. As shown in fig. 37, an exemplary inference that invalidating a detected radar event (e.g., a first detected pulse) results in a determination that the detected radar event is invalid at 3510 based on detected pulse characteristics that do not conform to predetermined characteristics (e.g., absence of subsequently detected pulses within a multiple of a PRI after a first detection of a suspect radar event, etc.) and/or voting.

As described herein, a conventional DFS master device may transmit devices in a DFS network (typically client devices) by transmitting a DFS beacon, which is considered an indication that the channel is free of radar. While the access point can detect radar, the wireless client is typically not. Therefore, the wireless client must first passively scan the DFS channel to detect the presence of a beacon on that particular channel. During passive scanning, the client device switches through the channel and listens for beacons transmitted at regular intervals by the access point on the available channel. Once a beacon is detected, the client is allowed to actively scan the channel. Typically, when the DFS master detects radar in the channel, the DFS master no longer transmits beacons, and all client devices that do not perceive beacons for a specified time must immediately leave the channel and remain closed for 30 minutes. For clients associated with the DFS primary network, additional information in the beacon (e.g., channel switch notification) may trigger a rapid and controllable evacuation of the channel.

However, in an exemplary mesh network (e.g., exemplary mesh network 3200) that includes a plurality of exemplary mesh network node host devices 3206 configured as DFS masters (e.g., master DFS masters) and/or flexible proxies 3208, waiting for a DFS channel switch based on a beacon that is periodically scanned, as a secondary DFS master, will result in the mesh network devices transitioning to new or available DFS channel transitions and/or unnecessary network downtime. Additionally, with each of a plurality of conventional mesh network node host devices configured as DFS masters discovering (e.g., detecting) radar independently in a DFS channel (and may not be correct or complete), the mesh network transitioning to a new DFS each DFS master independently discovers radar, suspends its beacon, the client device vacates a DFS channel, moves to another DFS channel, passively scans, etc., or is unnecessary (e.g., as a result of false detections).

As a non-limiting example, as described above, when radar is detected in a conventional DFS network, the device must vacate the DFS channel (e.g., subject to 200 ms-limited data transmission limitations) and stay on the channel for 30 minutes. As a result, the device cannot use the DFS channel for any other information (e.g., disallow data transmission) than its beacon for the duration. In a mesh network, there are a plurality of mesh network nodes. As a result, it may not be possible for all nodes in the mesh network to vacate DFS channels within 200ms, particularly if the mesh network topology is large and/or complex. However, because beacon transmissions may still be allowed for a specified amount of time (e.g., 10 seconds) on the DFS channel, various non-limiting embodiments described herein may employ beacon signals encoded with information in order to identify radar events and/or other mesh network nodes from which at least one of the next or new channels begins transmitting.

As a result, rather than transmitting it to a 200ms data transmission for transmission of the next channel or other information to various nodes of the mesh network, such information may be facilitated to be transmitted for a specified amount of time (e.g., 10 seconds) as compared to the example embodiments described herein. Thus, in further non-limiting embodiments, an exemplary mesh node as described herein may be configured to indicate one or more of radar events (e.g., suspected radar events, verified detected radar events, etc.), such as radar information transmission 3008, and next or new channel information in its beacons, such that all neighboring exemplary mesh nodes in an exemplary mesh network may receive an indication of a radar event (e.g., suspected radar event, verified detected radar event, etc.), and the next or new channel information. Thus, in a non-limiting aspect, an exemplary mesh node as described herein may be configured to indicate a radar event (e.g., a suspicious radar event, a verified detected radar event, etc.) and next or new channel information to facilitate effectively moving the mesh network to another channel when radar (e.g., a suspicious radar event, a verified detected radar event, etc.) is detected. In another non-limiting aspect, an exemplary mesh node in an exemplary mesh network may be further configured to update its own beacon (e.g., a suspicious radar event, a verified detected radar event, etc.) and the next or new channel information from neighboring exemplary mesh node beacons using the same information (e.g., radar event and next or new channel information) in response to receiving a radar event to facilitate rapid communication of information throughout the exemplary mesh network. In another non-limiting aspect, an exemplary mesh node as described herein may be configured to encode a countdown tick or timestamp inside a beacon such that each successive beacon decreases the countdown or timestamp as information is transmitted through the exemplary mesh node. As a result, the example mesh node of the example mesh network may be further configured to: when the countdown or timestamp reaches a final time, its channel switch to the next or new channel value is coordinated based on the next or new channel information regarding the countdown or timestamp. In other non-limiting implementations as described herein, an example mesh node as described herein may be configured to indicate one or more of radar events (e.g., suspicious radar events, verified detected radar events, etc.), e.g., radar information transmission 3008, and next or new channel information of a neighboring example mesh node using other mechanisms (e.g., data, actions, management frames) or using an out-of-band mechanism such as another radio, bluetooth, or via an example cloud intelligence engine.

As a non-limiting example, for radar events detected by example mesh nodes of an example mesh network (e.g., suspicious radar events, verified detected radar events, etc.), the radar events may pass through the example mesh nodes of the entire example mesh network configuration by encoding such information or other information in beacon signals (e.g., information elements of the beacon signals) of the example mesh nodes. In contrast, the information elements of the beacon signal of the legacy node for channel switching are only used for devices (e.g., client devices of the access point) to which it is immediately connected. For example, if a legacy access point switches to a different DFS channel, the access point will indicate a Channel Switch Announcement (CSA) in the beacon signal that will communicate to the connected devices that the next or new channel is in the CSA. Conventionally, however, there is no mechanism to communicate such channel switch information to other access points (e.g., nodes in a mesh network) where a packet storm may occur, except for the use of 200 ms-limited data frames of data transmissions after a radar event, where each mesh node sends such data frames (e.g., via channel switch information communication of the data frames) to each other node in the network.

Thus, in various embodiments, an example mesh node as described herein may be configured to indicate one or more of a radar event (e.g., a suspicious radar event, a verified detected radar event, etc.), e.g., radar messaging 3008, and next or new channel information in its beacons, such that all neighboring example mesh nodes in an example mesh network may receive an indication of a radar event (e.g., a suspicious radar event, a verified detected radar event, etc.), and the next or new channel information. Thus, according to various non-limiting embodiments as described herein, for radar events (e.g., suspicious radar events, verified detected radar events, etc.) detected by an exemplary mesh node of an exemplary mesh network, the radar may transmit events (e.g., suspicious radar events, verified detected radar events, etc.) throughout the mesh network by encoding such information or other information in a beacon signal (e.g., in an information element of the beacon signal) of the exemplary mesh node, which beacons are synchronized for all exemplary mesh nodes participating in the mesh network. Thus, each example mesh node receiving an information-encoded beacon may be configured to indicate one or more of a radar event (e.g., a suspicious radar event, a verified detected radar event, etc.) and the next or new channel information in its beacon such that all neighboring example mesh nodes receive the radar event (e.g., the suspicious radar event, the verified detected radar event, etc.) and the next or new channel information. As described herein, an example mesh node may be configured to update its own beacon with the same information from its neighboring example mesh nodes upon receiving a radar event (e.g., a suspicious radar event, a verified detected radar event, etc.) and the next or new channel information.

In other disclosed embodiments, various non-limiting implementations as described herein may be configured to use an out-of-band mechanism such as another radio, bluetooth, LTE, etc., or to communicate radar information 3008, or to communicate other information such as channel switch information, via an exemplary cloud intelligence engine, and may be configured to employ other mechanisms, e.g., data, actions, management frames, to facilitate communicating radar and/or other information, e.g., as described herein with respect to fig. 2, 21-24, 30-32, etc. As a non-limiting example, for another device that is not part of the exemplary mesh network (e.g., peer device, etc.), which may or may not be able to detect the ability of radar to operate on the same DFS channel, as described herein, various non-limiting embodiments may facilitate the transmission or transfer of radar information, such as channel switch information, using an out-of-band mechanism, such as another radio, bluetooth, LTE, etc., or by an exemplary cloud intelligence engine, and may employ other mechanisms, such as data, actions, management frames, to facilitate the transmission of radar information transfer 3008 and/or other information. Accordingly, various non-limiting embodiments as described herein may facilitate the communication of radar information and the communication of other information, such as channel switch information beyond devices participating in an exemplary mesh network, e.g., peer devices, etc. For example, conventionally, when an access point leaves a DFS channel, a peer device operating on the same DFS channel must vacate the DFS channel. As described herein, without the benefit of radar messaging 3008 and channel switch messaging, a peer must scan the next DFS channel for 1 minute before switching to it.

Fig. 38 depicts an example method 3800 for reducing error detection and/or network outages in

example mesh networks

3000, 3100, 3200, etc., using DFS channels, in accordance with various non-limiting aspects. Fig. 38 depicts a portion of an exemplary mesh network 3200 that includes an exemplary mesh node host device 3206 configured as a DFS master (e.g., a multi-channel DFS master), and a set of neighboring or neighboring exemplary mesh node host devices 3206 configured as DFS masters, as described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc. Fig. 38 also depicts an exemplary mesh network 3200 that includes a series of radar pulses (e.g., radar pulses of a PRI) in the presence of a radar 3102 burst. In a non-limiting aspect, fig. 38 depicts an exemplary mesh network node host device 3206 configured as a DFS master (e.g., a multi-channel DFS master) that detects the first radar pulse 3302 in a radar 3102 series of radar pulses. As further described herein, an exemplary mesh network node host device 3206 configured as a DFS master device may independently determine that it has detected a suspicious radar event, as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc. Subsequently, fig. 38 depicts a first one of a set of exemplary mesh node host devices 3206 configured as a DFS master (e.g., a multi-channel DFS master), detecting a third radar pulse 3302 of a series of radar pulses of a radar 3102 burst, the first one of the exemplary mesh node host devices 3206 configured as a DFS master (e.g., a multi-channel DFS master) may perform radar information transmission 3008, as further described herein. It should be noted that the radar information transmission 3008 may be in response to a call from the example mesh network node host device 3206 that is configured to detect the third radar pulse 3302 or the sixth radar pulse 3302 based on the DFS master device itself (e.g., the master DFS master device) that is suspicious of radar events and signaling or based on the first or second of a set of example mesh network node host devices 3206 that are configured as DFS master devices (e.g., multi-channel DFS master devices), as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc. Thus, fig. 38 depicts a second of a set of exemplary mesh network node host devices 3206 configured as a DFS master (e.g., a multi-channel DFS master), detecting a sixth radar pulse 3302 of a series of radar pulses of a radar 3102 burst, and a second of a set 3204 of distributed flexible proxies 3208 may also perform radar information transfer 3008, as further described herein. In various non-limiting embodiments, the example mesh node host device 3206 configured as a DFS master device (e.g., a multi-channel DFS master device), the first 3206 of the set of example mesh node host devices configured as a DFS master device (e.g., a multi-channel DFS master device), and the second detected suspicious radar event of the set of example mesh node host devices 3206 configured as a DFS master device (e.g., a multi-channel DFS master device) may be verified according to inference, algorithms, voting, and/or data fusion, etc., as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc. It should be noted that, as shown in FIG. 38, exemplary inferences for validating a detected radar event include: a conclusion that the radar event is valid is detected based on a probability of exceeding a threshold (e.g., three of the three radar sensing mesh nodes detecting a suspicious radar event within a predetermined time period, e.g., a small number multiple of the PRI after a first detection of the suspicious radar event, etc.), and the radar sensing mesh node (configured as a DFS master) is selected based on location information associated with the set of nearby or neighboring example mesh network node host devices 3206.

Accordingly, at 3802, fig. 38 depicts an example method 3800 that includes a host device (e.g., an example mesh network node host device 3206 configured as a DFS master, e.g., a multi-channel DFS master, of an example mesh network 3200 (e.g., to communicate and sense DFS channels thereon) operating on channel X, as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc. At 3804, the example method 3800 can include any DFS master (e.g., primary DFS master, secondary DFS master, multi-channel DFS master, standalone DFS master, flexible agent 3208, whether embedded or distributed, etc.), detecting a suspicious radar event, as further described herein. Moreover, exemplary method 3800 can also include collecting or receiving radar information from a plurality of DFS masters (e.g., a primary DFS master, a secondary DFS master, a multi-channel DFS master, a standalone DFS master, a flexible agent 3208, whether embedded or distributed, etc.) at 3806, as further described herein. As described herein, the radar information conveyance 3008 may be in response to a call from the example mesh network node host device 3206, which is configured to detect a suspicious radar event and signaling thereof based on a DFS master device (e.g., a primary DFS master device, a multi-channel DFS master device, etc.) itself, or a third radar pulse 3302 or a sixth radar pulse, respectively, based on a first or second DFS master device in the vicinity or neighboring example mesh network node host device 3206 configured as a DFS master device (e.g., a secondary DFS master device, multi-channel), as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc., and may be collected between example mesh network 3200 mesh nodes, whether employing cloud intelligence engines or otherwise. The example method 3800 may also include processing the collected radar information at 3808 to make a determination between the example mesh network 3200 mesh nodes regarding validity of one or more detected radar events or lack thereof a set of example mesh network node host devices 3206 configured as neighbors or neighbors of the DFS master device based on location information associated with the radar information. As shown in fig. 38, the determination that verifying that an exemplary inference of one or more detected radar events results in the radar event detected at 3810 being valid may be based on a probability of exceeding a threshold (e.g., three of the three radar sensing mesh nodes detected a suspicious radar event within a predetermined time period, e.g., a small digital multiple of the PRI after the first detection of the suspicious radar event, etc.) and selecting the radar sensing mesh node (configured as a DFS master) based on location information associated with the set of nearby or neighboring exemplary mesh network node host devices 3206.

Fig. 39 depicts further non-limiting aspects of an example method 3900 for reducing error detection and/or network downtime in an

example mesh network

3000, 3100, 300, etc., employing DFS channels. Fig. 39 depicts a portion of an exemplary mesh network 3200 that includes an exemplary mesh network node host device 3206 configured as a DFS master (e.g., a multi-channel DFS master) and a set of nearby or neighboring exemplary mesh network node host devices 3206 configured as DFS masters, as described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc. Fig. 39 further depicts an exemplary mesh network 3200 that is not a valid radar event but may be misdiagnosed as a valid radar event (e.g., false radar detection or false detection) in the presence of an interference source (e.g., random noise 3004, adjacent channel leakage from other channels, and/or interference from other channels, etc.). As described above, random noise 3004 refers to any interference source that may be misdiagnosed as a valid radar event, e.g., at the example mesh network node host device 3206, or otherwise, including but not limited to noise, random or adjacent channel interference or leakage, transient, decaying, weak and/or transient radar pulses, and so forth. In a non-limiting aspect, fig. 39 depicts an exemplary mesh network node host device 3206 configured as a DFS master (e.g., a multi-channel DFS master) that detects a series of radar pulses (e.g., radar pulses of a PRI of a radar 3102 burst) in which radar pulses 3302 may occur. As further described herein, an exemplary mesh network node host device 3206 configured as a DFS master device may independently determine that it has detected a suspicious radar event, as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc. Fig. 39 depicts a first and second of an exemplary set of nearby or neighboring mesh node host devices configured as a DFS master (e.g., a multi-channel DFS master) not detecting a series of subsequent expected radar pulses 3302 radar pulses (e.g., radar pulses of a radar 3102 burst that are not present in the environment of the exemplary mesh network 3200), thus a first and second of the set of neighboring or neighboring exemplary mesh node host devices 3206, configured as DFS masters, not performing radar information transmission 3008, as further described herein. It should be noted that the absence of radar information transmission 3008 by one or more of the first or second groups of nearby or neighboring exemplary mesh network node host devices 3206 configured as DFS masters, as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc., may be considered an indication of: the first pulse detected, which may be detected by the example mesh network node host device 3206 configured as a DFS master (e.g., a master DFS master), as a radar pulse 3302 of a series of radar pulses (e.g., of a PRI) of the radar 3102 burst, either alone or in conjunction with an independent analysis of the example mesh network node host device 3206 configured as a DFS master (e.g., a master DFS master), is a null detected radar event. In non-limiting aspects, the determination of the invalidity of the detected first pulse may be made passively (e.g., by waiting and noticing one or more of the first or second ones of the radar information transmissions 3008, a nearby or neighboring exemplary mesh network node host device 3206 configured as a DFS master, an independent analysis of the detected first pulse, etc.) or actively (e.g., the radar information transmissions 3008 node host device 3206 may be configured as a DFS master (e.g., a multi-channel DFS master) in response to a call from the exemplary mesh network, where the radar information transmissions 3008 include negative acknowledgements of lack of radar on the DFS channel, etc.). In various non-limiting embodiments, suspicious radar event (e.g., first detected pulse) algorithms, voting and/or data fusion, etc., detected by the example mesh node host device 3206, which is configured as a DFS master (e.g., a multi-channel DFS master), can be verified based on inference, as described further herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc. Note that as shown in fig. 39, an exemplary inference (e.g., a first detected pulse) for invalidating a detected radar event includes based on a probability of the detected radar event being invalid being below a threshold (e.g., one of the three radar sensing mesh nodes detects an event of the suspect radar within a predetermined time period, such as a small digital multiple of the PRI after a first detection of the suspect radar event, etc.) and selecting such radar sensing mesh node exemplary mesh network node host device 3206, configured as a DFS master, based on location information associated with the vicinity or neighborhood of the group.

Accordingly, at 3902, fig. 39 depicts an example method 3300 that includes a host device of an example mesh network 3200 (e.g., an example mesh network node host device 3206 configured as a DFS master, e.g., a multi-channel DFS master) operating on channel X (e.g., transmitting and sensing DFS channels), as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc. At 3904, the example method 3900 can include any DFS master (e.g., a primary DFS master, a secondary DFS master, a multi-channel DFS master, a standalone DFS master, a flexible proxy 3208, whether embedded or distributed, etc.), detecting a suspicious radar event, as further described herein. Moreover, exemplary method 3900 can further include collecting or receiving radar information from a plurality of DFS master devices (e.g., a primary DFS master device, a secondary DFS master device, a multi-channel DFS master device, a standalone DFS master device, a flexible agent 3208, whether embedded or distributed, etc.) at 3906, as further described herein. As described herein, the radar information conveyance 3008 may be in response to a call from the example mesh network node host device 3206, which is configured to detect a suspicious radar event (e.g., a master DFS master), a DFS master (e.g., a master DFS master), a first detected pulse, a multi-channel DFS master, etc.) and signaling based on its own detection of the suspicious radar event, or based on another of the first or second of the neighboring or neighboring example mesh network node host devices 3206 being configured as a DFS master, detecting the suspicious radar event (e.g., a first detected pulse), etc., as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc., and may be collected between the example mesh network node 3200, whether using a cloud intelligence engine or otherwise. It is further noted that the lack of radar information transmission 3008 by other example mesh network 3200 mesh nodes during a time frame of interest may be used to infer that no other example mesh network 3200 mesh node experienced a suspected suspicious radar event (e.g., a detection pulse). The example method 3900 may also include processing, at 3908, the collected radar information, or lack thereof, to facilitate determining, among the mesh nodes of the example mesh network 3200, location information associated with a set of nearby or neighboring example mesh network node host devices 3206, configured as DFS master devices, based on determining validity of one or more detected radar events, or lack thereof, in the following manner. As shown in fig. 39, the determination that invalidating the detected radar event (e.g., the first detected pulse) results in invalidation of the radar event detected at 3910 may be based on a probability below a threshold (e.g., one of the three radar sensing mesh nodes detects a suspect radar event within a predetermined time period, such as a small digital multiple of the PRI after the first detection of the suspect radar event, etc.) and selecting the radar sensing mesh node (configured as a DFS master) based on location information associated with the set of nearby or neighboring exemplary mesh network node host devices 3206.

Thus, in a non-limiting aspect, an exemplary mesh network node (e.g., exemplary mesh network node host device 3206, etc.) may be configured to call or signal an exemplary mesh network node in its vicinity or proximity to facilitate radar detection based on the exemplary mesh network node (e.g., exemplary mesh network node host device 3206, etc.) detecting a suspicious radar event. As non-limiting examples, in response to receiving a call or signal to assist radar detection, one or more nearby or neighboring example mesh network nodes may be configured to temporarily suspend their transmissions (e.g., temporarily suspend their transmissions in one or more DFS channels, etc.), increase their receiver gain to facilitate focusing on radar detection, and/or transmit an example clear-to-send (CTS) frame to silent one or more DFS channels of interest, e.g., as further described herein. Moreover, the example mesh network node (e.g., example mesh network node host device 3206, etc.) may be further configured to vote on whether a radar signal (which is the subject of a suspicious radar event) is a real radar 3104 or a radar 3102 (e.g., an actual radar source, which can result in a valid and/or detected radar event).

As a non-limiting aspect, in further non-limiting embodiments of the

exemplary mesh networks

3000, 3100, 3200, etc., associated with a centrally or individually managed or controlled network using DFS channels (e.g., such as an enterprise or other network including a controller controlling multiple access points, other multi-node networks including a combination of wired or wireless links, whether with centralized management or control, or otherwise, etc.), the use of CTS frames may not be necessary or desirable. For example, an exemplary radar detector (e.g., primary DFS master, secondary DFS master, multi-channel DFS master, standalone DFS master, flexible proxy 3208, whether embedded or distributed) that detects suspicious radar signals may be configured to be wired or wirelessly connected to an enterprise network, and may be further configured to send signals by using a central or separately managed or controlled network of the DFS channel network to interrogate one or more other routers/access points or nodes in any other mesh network (e.g., itself, and/or via any other devices associated with the mesh network, etc.) to silence without having to send CTS frames (e.g., via an out-of-band method, such as via a secondary radio, such as a 2.4GHz WLAN, via a wired network segment, via direct ethernet frames, etc.) to facilitate transmission of messages/signals to mesh nodes in an exemplary mesh network employing DFS channels, without generating a signal on one or more DFS channels. As a result, in a non-limiting aspect, exemplary embodiments as described herein may be configured to transmit packets or data that signal nearby or neighboring devices on the same network, for which the nearby or neighboring devices may also be configured to turn off their transmitters for a predetermined period of time, request neighboring devices on the same network to assist in radar detection on a DFS channel, and so forth.

In another non-limiting example, consider an exemplary router that uses DFS detection (e.g., including or associated with a primary DFS master, a secondary DFS master, a multi-channel DFS master, a standalone DFS master, a flexible proxy 3208, whether embedded or distributed, etc.), as described herein, e.g., with respect to fig. 2, 13, 14, 20, 24, 30-32, etc. In a non-limiting aspect, instead of blocking or eliminating all DFS channels and listening only in response to suspected radar events, an exemplary router with DFS detection may be configured, e.g., directed by a flexible agent, to focus on listening to the same DFS channel with suspected radar signals, to produce redundant radar event information, etc., such as described with respect to fig. 2, 13, 14, 20, 24, 30-32, etc. Thus, in further non-limiting embodiments of the disclosed subject matter, redundant radar event information (e.g., radar information transmission 3008) may be transmitted throughout the exemplary network, helping to further reduce instances of false radar detection and/or network downtime caused thereby.

In another non-limiting example, assuming a plurality of exemplary devices (e.g., including or associated with: a primary DFS master, a secondary DFS master, a multi-channel DFS master, a standalone DFS master, a flexible agent 3208, whether embedded or distributed, etc.) on an exemplary network employing DFS detection, various embodiments may employ reasoning and algorithms employing this redundant radar event information, as described herein, e.g., with respect to FIGS. 2, 13, 14, 20, 24, 30-32, etc., in order to further reduce instances of false radar detection. For example, as described above, in an exemplary mesh network of five mesh nodes, where each mesh node includes or is associated with an exemplary DFS detector (e.g., includes or is associated with: a primary DFS master node, a secondary DFS master node, a multi-channel DFS master device, a standalone DFS master device, a flexible proxy 3208, whether embedded or distributed, etc.), if a mesh center node DFS detector senses a suspected radar event while the other four mesh node DFS detectors are not, various non-limiting embodiments may infer that the suspected radar event sensed by the center mesh node DFS detector is not a valid radar event. In contrast, in an exemplary mesh network of five mesh nodes, where each mesh node includes an exemplary DFS detector (e.g., including or associated with a primary DFS master, a secondary DFS master, a multi-channel DFS master, a standalone DFS master, a flexible agent 3208, whether embedded or distributed, etc.), if a central mesh node DFS detector senses a suspect radar event and one or more of the other four DFS detectors also sense a suspect radar event, various non-limiting embodiments may infer that the suspect radar event sensed by the central mesh node DFS detector is a valid radar event. Thus, as further described herein, for example, with respect to fig. 2, 13, 14, 20, 24, 30-42, etc., by utilizing knowledge of the location, distance, and proximity of other mesh nodes in an exemplary mesh network, various embodiments described herein may further ensure that spurious interference (e.g., noise) is not mistaken for a true radar signal, thereby further reducing the likelihood of false detections and/or network downtime.

Further, by employing radar information communication 3008 (or lack thereof by a particular exemplary mesh node) and information regarding device location, radar, and channel availability (e.g., whitelists, blacklists, etc.), voting, accuracy, history, as available in the exemplary network (e.g., exemplary mesh network) described herein, other derivative information regarding radar detection effectiveness (e.g., node trust information) may be generated and/or employed by various embodiments herein, such as by a cloud intelligence engine or otherwise, to facilitate employing reasoning and/or algorithms to distinguish random noise 3004 and radar 3102 in order to reduce error detection and/or network downtime in the exemplary network employing DFS channels (e.g., exemplary mesh network), as described herein. As a non-limiting example, consider a portion of some example mesh networks 3200 that includes an example mesh network node host device 3206 configured as a DFS master (e.g., a multi-channel DFS master) and a group of neighboring or neighboring example mesh network node host devices 3206 configured as DFS masters, as described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc. By way of non-limiting example, if a particular nearby or neighboring exemplary mesh network node host device 3206, configured as a DFS master device (or other device), has a voting history (e.g., stored, analyzed, etc. by a cloud intelligence engine or the like), which is always the opposite of the result of radar messaging 3008, votes, validates, and/or invalidates the suspected radar event, and then, making trust metrics on the signal the example mesh node host device 3206 (or other device) may be discarded, updated and/or otherwise annotated, such that inferences and/or algorithms of 3008 are communicated using radar information from the exemplary mesh node host device 3206 (or other device), the quality of radar detection in an exemplary network utilizing channels and/or exemplary network responses to valid radar signals may be improved in view of reduced false detections and/or network downtime.

Fig. 40 depicts other example methods 4000 for reducing error detection and/or network downtime in

example mesh networks

3000, 3100, 3200, etc., employing DFS channels based on communicating radar and location information, according to various non-limiting aspects. Thus, at 4002, fig. 40 depicts an example method 4000 that includes an example host device (e.g., an example mesh network node host device 3206, configured as a DFS master, e.g., a multi-channel DFS master) of operation of an example network (e.g., an example mesh network 3200) communicating and sensing on channel X (e.g., on a DFS channel), as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-39, etc. At 4004, the example method 4000 may include an example host device (e.g., an example mesh network node host device 3206 configured as a DFS master device, e.g., a multi-channel DFS master device) detecting a suspicious radar event, as further described herein. Further, radar information transmission 3008 including location information may detect suspicious radar events and/or signals thereof in response to an example host device (e.g., an example mesh network node host device 3206 configured as a DFS master, e.g., a multi-channel DFS master), which may be distributed among example mesh network 3200 mesh nodes, whether employing cloud smart engines or otherwise, as described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-39, etc.

In another non-limiting embodiment of an example method 4000 for reducing error detection and/or network outage based on transmitting radar and location information in

example mesh networks

3000, 3100, 3200 using DFS channels, the example method 4000 may include transmitting 3008 radar information including location information at 4008 a mesh network (e.g., example mesh network 3200) operating on channel X (e.g., communicating and sensing on DFS channels) on an example host device (e.g., an example mesh node host device 3206 configured as a DFS master, e.g., a multi-channel DFS master), as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-39, etc., that transmits radar and location information

Moreover, exemplary method 4000 may further include selecting from one or more DFS masters (e.g., a primary DFS master, a secondary DFS master, a multi-channel DFS master, a standalone DFS master, a flexible proxy 3208, whether embedded or distributed, etc.), as further described herein. As described herein, the radar information transmission 3008 may be conducted in response to a call from an exemplary host device (e.g., an exemplary mesh node host device 3206 configured as a DFS master device, e.g., a multi-channel DFS master device) based on its own detection of suspicious radar events and signaling thereof or based on one or more of a set of neighboring or neighboring exemplary mesh node host devices 3206 configured as a DFS master device (e.g., a multi-channel DFS master device), detecting the same or subsequent radar pulses 3302, etc., as described herein, e.g., with respect to fig. 2, 13, 14, 24, etc., and may be collected among exemplary mesh network 3200 mesh nodes, whether employing cloud intelligence engines or otherwise. Accordingly, the example method 4000 may further include, at 4010, processing the collected radar information to facilitate determining validity with respect to one or more detected radar events or lack thereof among the example mesh nodes of the example mesh network 3200 based on the associated location information and a set of nearby or neighboring example mesh network node host devices 3206 (e.g., configured as DFS master devices, etc.).

As described above, as shown in fig. 40, a determination that an exemplary inference of invalidating a detected radar event (e.g., a first detection pulse in an exemplary mesh network using DFS detection as described herein) results in invalidating a detected radar event (e.g., not radar) may select a radar sensing mesh node based on a probability below a threshold (e.g., one of the three radar sensing mesh nodes detects a suspicious radar event within a predetermined time period, such as a small digital multiple of the PRI after the suspicious radar event was first detected, etc.) and based on location information associated with a nearby or neighboring exemplary mesh network node host device 3206 configured as a DFS master device. As a result, the example method 4000 may further include, at 4012, radar information conveyance 3008 that includes location information, e.g., via one or more example mesh node host devices 3206 configured as DFS masters or the like, which may be carried as a result of invalidating suspected radar events, e.g., via a cloud intelligence engine, or otherwise through an example host device (e.g., an example mesh node host device 3206 configured as a DFS master, such as a multi-channel DFS master).

As further described above, as shown in fig. 40, a determination (e.g., "radar") that verifying that an exemplary inference of one or more detected radar events results in the detected radar event being valid may be based on a probability of exceeding a threshold (e.g., three of the three radar sensing mesh nodes detecting a suspect radar event within a predetermined time period, e.g., a small number multiple of a PRI after a first detection of the suspect radar event, etc.) and selecting an exemplary mesh network node host device 3206, configured as a DFS master device, near or adjacent to such radar sensing mesh node based on location information associated with the group. As a result, the example method 4000 may further include, at 4012, radar information transmission 3008, including location information, e.g., via one or more example mesh node host devices 3206 configured as DFS master devices or the like, which may invalidate the suspicious radar event as a result, or otherwise, e.g., by an example host device (e.g., the example mesh node host device 3206 configured as a DFS master device, such as a multi-channel DFS master device). Moreover, the example method 4000 may also include, at 4012, initiating a DFS channel change (e.g., including location information after radar information transmission 3008) via one or more example mesh network node master transmissions, e.g., via encoded beacon signals, through other mechanisms (e.g., data, actions, management frames) or using an out-of-band mechanism (e.g., another radio, bluetooth) and/or via an example cloud intelligence engine, etc., device 3206 configured as a DFS master device, as described above.

Fig. 41 depicts other example methods 4100 in

example mesh networks

3000, 3100, 3200, etc., employing DFS channels in accordance with various non-limiting aspects to reduce error detection and/or network downtime based on employing control, management, and/or data frames. In further non-limiting embodiments of the example mesh network node host device 3206 configured as a DFS master device (e.g., a multi-channel DFS master device), a group of nearby or neighboring example mesh network node host devices 3206 configured as DFS master devices (e.g., as described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc.) example DFS master devices (e.g., a primary DFS master device, a secondary DFS master device, a multi-channel DFS master device, a standalone DFS master device, a flexible proxy 3208, whether embedded or distributed, etc.) for detecting suspicious radar events (e.g., detecting that a number N of radar pulses 3302 is greater than or equal to a predetermined number X of radar pulses 3302), the example DFS master device may be configured to send example control, management, and/or data frames (e.g., CTS 4102) over one or more DFS channels, in order to silence one or more DFS channels. In another non-limiting aspect, the example DFS master device is after it sends the example control, management, and/or data frames (e.g., the example CTS frame 4102, etc.) on one or more DFS channels, and may be further configured to continue sensing radar 3102 signals, as further described herein. While in

exemplary mesh networks

3000, 3100, 300, etc. associated with a controlled network using DFS channels (e.g., an enterprise network including a controller controlling multiple access points, etc.), employing control, management and/or data frames (e.g., exemplary CTS frames 4102, etc. on one or more DFS channels) may not be necessary or desirable, as described above, exemplary radar detectors (e.g., primary DFS master, secondary DFS master, channel DFS master, standalone DFS master, flexible proxy 3208, whether embedded or distributed, etc.) associated with an uncontrolled network using DFS channels that detect suspicious radar events (e.g., detecting that the number N of radar pulses 3302 is greater than or equal to the predetermined number X of radar pulses 3302) may also be configured to connect to the network, wired or wirelessly, and may also be configured to send signals on the enterprise network to interrogate one or more other routers/access points, etc The point or any other mesh node in the mesh network is silent without having to send a CTS frame 4102 (e.g., out-of-band method, direct ethernet frame, etc.). However, in the case of a non-limiting embodiment of a non-controlling exemplary mesh network, including an exemplary mesh node host device 3206 configured as a DFS master (e.g., a multi-channel DFS master), a set of neighboring or proximate exemplary mesh node host devices 3206 configured as DFS masters, as described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc., exemplary DFS masters (e.g., a primary DFS master, a secondary DFS master, a multi-channel DFS master, a standalone DFS master, a mobility agent 3208, whether embedded or distributed, etc.) may be configured to transmit exemplary control, management, and/or data frames, e.g., exemplary CTS frames 4102, etc., on one or more DFS channels to facilitate, e.g., upon detection of a suspected radar event (e.g., the number N of radar pulses 3302 detected is greater than or equal to the predetermined number X of radar pulses 3302), muting one or more DFS channels (e.g., muting a transmitter on one or more DFS channels of a nearby or neighboring node to terminate or maintain transmissions on the one or more DFS channels, etc.), as further described herein. In another non-limiting aspect, exemplary embodiments of an exemplary mesh network mesh node may be configured to terminate or maintain its transmission on one or more DFS channels upon receipt of an exemplary control, management and/or data frame (e.g., exemplary CTS frame 4102, etc.), for example, when a suspected radar event (e.g., indicated by detecting a number N of radar pulses 3302 that is greater than or equal to a predetermined number X of radar pulses 3302) is verified or invalidated. As a non-limiting example, fig. 41 depicts an example Wi-Fi communication cycle in which an

example mesh network

3000, 3100, 3200, etc., including an example mesh node host device 3206 (configured as a DFS master (e.g., a multi-channel DFS master)) and a set of neighboring or neighboring example mesh node host devices 3206 (configured as DFS masters, as described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-32, etc.) and/or other network devices, wirelessly communicate while using one or more DFS channels. The communication session as shown in fig. 41 includes results from terminating or maintaining transmissions on one or more DFS channels upon receipt of an exemplary control, management and/or data frame, including a dirty period 4104 followed by a clean period 4106 for Wi-Fi traffic, such as an exemplary CTS frame 4102 or the like, for example, when a suspected radar event (e.g., as indicated by detection of a number N of radar pulses 3302 greater than or equal to a predetermined number X of radar pulses 3302) is verified or invalidated. Assuming that a suspected radar event (e.g., as indicated by detecting a number N of radar pulses 3302 that is greater than or equal to a predetermined number X of radar pulses 3302) is invalid (e.g., by failing to detect that a number M of radar pulse numbers 330 is greater than or equal to a second predetermined number Y of radar pulses 3302, within a predetermined time frame, etc.), fig. 41 also depicts restoring Wi-Fi traffic after expiration of a clean period 4106.

For example, as further described herein, on the DFS channel, whenever there is an indication of a suspected radar event (e.g., detecting that the number N of radar pulses 3302 is greater than or equal to the predetermined number X of radar pulses 3302), the example DFS master is true for the suspected radar event (e.g., detecting that the number N of radar pulses 3302 of the predetermined number X of radar pulses 3302 is greater than or equal to the predetermined number X of radar pulses 3302), or is false detection as a result of various sources of interference (e.g., a number M of radar pulses 3302 that is greater than or equal to the number M of the second predetermined number Y of radar pulses 3302 within a predetermined time frame that is not detectable), etc. (e.g., random noise 3004, adjacent channel leakage, and/or interference from other channels, etc.). Thus, at the example DFS master device, when there is an indication of a suspected radar event (e.g., a number N of detected radar pulses 3302 that is greater than or equal to the predetermined number X of radar pulses 3302), the example DFS master device may be configured to transmit (e.g., broadcast or otherwise) an example control, management, and/or data frame, e.g., a silence frame or packet, an example CTS frame 4102, etc., on one or more DFS channels in order to silence network transmissions or more DFS channels, e.g., two radar pulses 3302 (e.g., radar pulses 3032 of a PRI) on the one or more DFS channels, e.g., as shown in fig. 41. As a result of muting one or more DFS channels, any further indication of radar 3102 or subsequent indication of a suspected radar event (e.g., detection of a number M of radar pulses 3302 that is greater than or equal to the second predetermined number Y of radar pulses 3302, within a predetermined time range, etc.), on an example DFS master, another example DFS master, or any other radar detector associated with the

example mesh networks

3000, 3100, 3200, etc., the suspected radar event may be verified or invalidated during the muting or clean period 4106 without causing unnecessary interference to the one or more DFS channels.

In a non-limiting aspect, an exemplary control, management, and/or data frame (e.g., the exemplary CTS frame 4102, etc.) may be configured (e.g., generated and transmitted, etc.) between two consecutive radar pulses 3302 (e.g., generated and transmitted in less than about 1ms after the initial sensing indication of the suspect radar event and the duration of less than the PRI) so that it may be received by other radar detectors in the exemplary mesh network before the next expected radar pulse (e.g., based on the initial detection of the suspect radar event and the PRI). In another non-limiting example, in response to receiving the example control, management, and/or data frame (e.g., the example CTS frame 4102, etc.), one or more DFS channels may be muted in order for one or more other radar detectors in the example mesh network having sufficient time after receiving the example control, management, and/or data frame (e.g., the example CTS frame 4102, etc.) to receive a next expected, consecutive radar pulse 3302 (if to occur) without interfering with the one or more DFS channels.

In a non-limiting example, with respect to fig. 41, an exemplary non-limiting embodiment having five consecutive radar pulses 3302 (e.g., radar pulses 3302 of a PRI) may be configured to wait to detect a second radar pulse (e.g., configured to wait to detect a number N of radar pulses 3302 that is greater than or equal to a predetermined number X of radar pulses 3302, where N is 2 and X is 2) upon detection of a first radar pulse 3302 of the five radar pulses 3302, before determining that there is a possible radar 3102 or an indication of a possible valid radar event. Thus, various non-limiting embodiments may ensure that any single spurious interference (e.g., random noise 3004, adjacent channel leakage and/or interference from other channels, etc.) on one or more DFS channels is not mistaken for a possible indication of radar 3102 or a possible valid radar event, thereby reducing the likelihood of false detections and resulting in network downtime, as further described herein. As described above, the exemplary non-limiting embodiments can then transmit (e.g., broadcast or otherwise) an exemplary control, management and/or data frame, such as a silence frame or packet, an exemplary CTS frame 4102, etc., or more DFS channels, in one example, in order to silence network transmission for a predetermined time, such as two radar pulses 3302 (e.g., radar pulses 3032 of a PRI), on one or more DFS channels, such as shown in fig. 41.

In non-limiting aspects, example control, management, and/or data frames, such as silence frames or packets, example CTS frames 4102, and so forth, can be transmitted on one or more DFS channels (e.g., immediately after the second radar pulse 3302 is detected (e.g., within a specified time, such as less than about 1ms of time generated and sent after an initial sensing indication of a radar event) (e.g., detecting a number N of radar pulses 3302 greater than or equal to a predetermined number X of radar pulses 3302, where N is 2 and X is 2)). In another non-limiting aspect, example control, management, and/or data frames, such as silence frames or packets, example CTS frames 4102, and the like (e.g., broadcast or otherwise) may be transmitted over one or more DFS channels (e.g., within a specified time, such as a time generated and transmitted after an initial sensing indication of a radar event is less than about 120 microseconds (μ β) (e.g., a number N of detected radars) pulses 3302 is greater than or equal to a predetermined number X of radar pulses 3302, where N is 2 and X is 2)). In another non-limiting aspect, if no further pulses 3302 are detected or sensed on one or more DFS channels during clean period 4106 (e.g., by not detecting a number M of radar pulses 3302 that is greater than or equal to a second predetermined number Y of radar pulses 3302 within a predetermined time range (e.g., clean period 4106, etc.), where M is 2 and Y is 3), exemplary embodiments may resume transmission on one or more DFS channels after expiration of clean period 4106. Thus, various non-limiting embodiments may further ensure that spurious interference (e.g., random noise 3004, adjacent channel leakage and/or interference from other channels, etc.) on one or more DFS channels are not mistaken for a true radar pulse 3302, thereby further reducing the likelihood of false detections and resulting network downtime.

In another limiting aspect, various non-limiting embodiments can be further configured to stop transmissions on one or more DFS channels after a clean period 4106, for example, if additional radar pulses 3302 are detected or sensed on another DFS channel during the clean period 4106 (e.g., where N detected radar pulses 3302 are greater than or equal to a predetermined number X of radar pulses 3302, where N is 2 and X is 2, but where the number M of detected radar pulses 3302 is not greater than or equal to a second predetermined number Y of radar pulses 3302 within a predetermined time range, such as clean period 4106, etc.). In further non-limiting aspects, the exemplary embodiments can be further configured to: exemplary control, management, and/or data frames, e.g., silence frames or packets, exemplary CTS frames 4102, etc., are sent (e.g., broadcast or otherwise) on one or more DFS channels to silence network transmissions on the one or more DFS channels for a predetermined time, e.g., two radar pulses 3302 (e.g., radar pulses 3032 of a PRI), as shown in fig. 41, immediately (e.g., within a specified amount of time, e.g., within about 2ms, in another non-limiting aspect) after determining that there is an indication of a possible radar 3102 or a possible valid radar event, e.g., waiting for detection of N of a number N of radar pulses 3302 that is greater than or equal to a predetermined number X of radar pulses 3302, where N is 2 and X is 2. As a result, as described herein, various non-limiting implementations may facilitate determining whether a signal on one or more DFS channels is noise 3004 or actual radar 3102 while reducing the likelihood of false detections that may reduce DFS channel availability, and/or reducing network downtime, as described herein.

In another non-limiting aspect, exemplary control, management, and/or data frames transmitted on one or more DFS channels, e.g., silence frames or packets, exemplary CTS frames 4102, etc., can be configured to encode the duration of the clean period 4106. In another non-limiting aspect, the example CTS frame 4102 can include a NAV field, as described above with respect to fig. 1. The duration of the clean period 4106 may be encoded by various disclosed embodiments. In a further non-limiting aspect, the duration of the clean period 4106 encoded in the NAV field may include or be equal to the number of Pulse Repetition Intervals (PRI) equal to the number C equal to the pulses 3302 of the radar 3102. In another non-limiting aspect, an exemplary CTS frame 4102 or the like transmitted on one or more DFS channels can be (e.g., broadcast or otherwise) configured to be encoded such that the exemplary CTS frame 4102 is specific and can be identified as a specific exemplary DFS master device desiring to silence the one or more DFS channels. In further non-limiting aspects, other data can be provided by various non-limiting embodiments to facilitate radar information transmission 3008 associated with a suspected radar event (e.g., detecting a number N of radar pulses 3302 greater than or equal to X of a predetermined number of radar pulses 3302, detecting a number M of radar pulses 3302 greater than or equal to a second predetermined number Y of radar pulses 3302 within a predetermined time frame, etc.), such as, in a non-limiting example, a predetermined and/or special destination MAC specifying and indicating a device to communicate on one or more DFS channels, the example CTS frame 4102 being specific to radar detection purposes (e.g., from an example DFS master). In further non-limiting aspects, exemplary disclosed embodiments may be configured to transmit (e.g., broadcast or otherwise) an exemplary CTS frame 4102 or the like sent on one or more DFS channels, which may include an exemplary CTS-Self frame 4102 as a non-limiting example, if an exemplary radar detector suspects that it detects a suspected radar event, embodiments such as an exemplary DFS master device may be configured to send (e.g., broadcast or otherwise) an exemplary CTS-Self frame 4102, wherein may be further configured to encode a time field of the CTS-Self frame 4102 that specifies a duration for which an exemplary mesh network may direct mesh nodes to silence one or more DFS channels. In another non-limiting example, the time field of the CTS-Self frame 4102 may be employed by the various disclosed embodiments to identify a specified duration to silence the channel for a predetermined amount of time (e.g., 2 radar pulses of a PRI, etc.), otherwise not based on the predetermined amount or protocol-specific standard duration for receiving the CTS frame.

Accordingly, fig. 41 depicts an exemplary method 4100 for reducing error detection and/or network downtime based on employing control, management, and/or data frames in an

exemplary mesh network

3000, 3100, 3200, etc., employing DFS channels. For example, an exemplary non-limiting embodiment of an exemplary mesh network (e.g., exemplary mesh network 3200, etc.) such as a primary DFS master, a secondary DFS master, a multi-channel DFS master, a standalone DFS master, a flexible proxy 3208, whether embedded or distributed, may detect suspicious radar events (e.g., detect that the number N of radar pulses 3302 is greater than or equal to the predetermined number X of radar pulses 3302) at 4108. At 4110, the example method 4100 can further include transmitting an example control, management, and/or data frame, e.g., the example CTS frame 4102, etc., on the one or more DFS channels to facilitate muting the one or more DFS channels. As described above, the exemplary, non-limiting embodiment may continue to sense the radar 3102 signal. Accordingly, at 4112, exemplary method 4100 may further include further detecting the suspect radar event (e.g., detecting a number M of radar pulses 3302 that is greater than or equal to a second predetermined number Y of radar pulses 3302 within a predetermined time frame, a cleaning period 4106, etc.). In another non-limiting aspect, exemplary embodiments of exemplary mesh nodes may be configured to terminate or maintain their transmissions on one or more DFS channels upon receipt of an exemplary control, management and/or data frame, an exemplary CTS frame 4102, etc., e.g., when a suspected radar event (e.g., indicated by detecting that the number N of radar pulses 3302 is greater than or equal to the predetermined number X of radar pulses 3302) is verified or invalidated, as further described above. Assuming that the suspected radar event (e.g., indicated by detecting a number N of radar pulses 3302 that is greater than or equal to the predetermined number X of radar pulses 3302) is invalidated (e.g., indicated by failing to detect that the number M of radar pulse numbers 330 is greater than or equal to the second predetermined number Y of radar pulses 3302, within a predetermined time frame, etc.), fig. 41 further depicts at 4112 that Wi-Fi traffic is restored after expiration of a clean period 4106, and an exemplary embodiment of an exemplary mesh grid node may restore the exemplary method 4100 at 4108. Assuming that a suspect radar event (e.g., by detecting a number N of radar pulses 3302 that is greater than or equal to the predetermined number X of radar pulses 3302) is verified (e.g., by failing to detect a number M of radar pulses 3302 that is greater than or equal to the second predetermined number Y of radar pulses 3302, within a predetermined time range, etc.), fig. 41 further depicts at 4114 identification of a valid radar 3102, as described herein, communication on the DFS channel having the radar 3102 signal is disabled.

Fig. 42 depicts other example methods 4200 for reducing error detection and/or network downtime based on employing a retention signal 4202 and/or a recovery signal 4204 in

example mesh networks

3000, 3100, 3200, etc., employing DFS channels according to various non-limiting aspects related thereto. In contrast to the example method 4100, fig. 42 depicts an example method 4200 for reducing error detection and/or network downtime based on employing a retention signal 4202 and/or a recovery signal 4204 in an

example mesh network

3000, 3100, 3200, etc. For example, an exemplary non-limiting embodiment e.g., an exemplary mesh network (e.g., exemplary mesh network 3200, e.g., a primary DFS master, a secondary DFS master, a multi-channel DFS master, a standalone DFS master, a flexible proxy 3208, whether embedded or distributed), etc.) may detect a suspicious radar event (e.g., detect that the number N of radar pulses 3302 is greater than or equal to the predetermined number X of radar pulses 3302) at 4206. At 4210, exemplary method 4200 may further include transmitting an exemplary retention signal 4202 on the one or more DFS channels to facilitate muting the one or more DFS channels. As described above, radar events (e.g., detecting a number N of radar pulses 3302 that is greater than or equal to a predetermined number X of radar pulses 3302) such as detecting suspected radar events (e.g., primary DFS master, secondary DFS master, multi-channel DFS master, standalone DFS master, flexible proxy 3208, whether embedded or distributed) may also be configured to be wired or wirelessly connected to the exemplary mesh network, and may be further configured to send a signal (e.g., one or more of exemplary hold signal 4202 and/or exemplary recovery signal 4204) to interrogate one or more other routers/access points or any other mesh nodes in the mesh network through the enterprise network to silence without having to send a CTS frame (e.g., through an out-of-band method, direct ethernet frame, etc.). As a result, in a non-limiting aspect, exemplary embodiments as described herein may be configured to transmit packets or data (e.g., one or more of exemplary hold signal 4202 and/or exemplary resume signal 4204, etc.)) that signals nearby or neighboring devices on the same network for which they may also be configured to turn off their transmitters for a predetermined period of time, request neighboring devices on the same network to assist in radar detection or more DFS channels on one network, etc. As described above, the exemplary, non-limiting embodiment may continue to sense the radar 3102 signal. Accordingly, in 4210, exemplary method 4200 may further include further detecting a suspicious radar event (e.g., detecting M radar pulse numbers 330 of radar pulses 3302 greater than or equal to the second predetermined number Y within a predetermined time frame, a clean period 4106, etc.). In another non-limiting aspect, an exemplary embodiment of an exemplary mesh node may be configured to terminate or maintain its transmission on one or more DFS channels upon receipt of an exemplary hold signal 4202, e.g., verified or invalidated upon a suspected radar event (e.g., indicated by detection of a number of radar pulse numbers 330 that is greater than or equal to a predetermined number X of radar pulses 3302), as described above. Assuming that a suspected radar event (e.g., indicated by detecting a number N of radar pulses 3302 that is greater than or equal to a predetermined number X of radar pulses 3302) is invalid (e.g., indicated by a number M of radar pulse numbers 330 that is not detectable that is greater than or equal to a second predetermined number Y of radar pulses 3302, within a predetermined time frame, etc.), fig. 42 further depicts at 4210 recovering Wi-Fi traffic after an exemplary clean period 4206 expires, and an exemplary embodiment of an exemplary mesh node may recover at 4206 exemplary method 4200. Assuming that a suspect radar event (e.g., by detecting a number N of radar pulse numbers 330 of radar pulses 3302 that is greater than or equal to a predetermined number X) is verified (e.g., by failing to detect a number M of radar pulses 3302 that is greater than or equal to a second predetermined number Y, radar pulses 3302, within a predetermined time range, etc.), fig. 42 further depicts at 4212 identification of a valid radar 3102, as described herein, disabling communication on the DFS channel having the radar 3102 signal.

As described above, example embodiments may be configured to transmit signals or data of nearby or neighboring devices on the same network (e.g., example recovery signal 4204, etc.), which may also be configured to recover wireless communications on one or more DFS channels, etc. Subsequently, as an example radar detector (e.g., a primary DFS master, a secondary DFS master, a multi-channel DFS master, a standalone DFS master, a flexible proxy 3208, whether embedded or distributed, etc.) determines that a suspected radar event (e.g., indicated by detecting a number N of radar pulses 3302 that is greater than or equal to a predetermined number X of radar pulses 3302) no longer exists on one or more DFS channels (e.g., a number M of radar pulses 3302 that is greater than or equal to a second predetermined number Y of radar pulses 3302 cannot be detected within a predetermined time frame), and so forth. Fig. 42 further depicts that at 4214, Wi-Fi traffic is resumed (e.g., after expiration of the exemplary clean period 4206 after receipt of the exemplary resume signal 4204), and that an exemplary embodiment of an exemplary mesh grid node may resume the exemplary method 4200 at 4206.

In further non-limiting implementations, the example mesh network may include or be associated with an example standalone dedicated DFS sensor flexible proxy and/or DFS master, e.g., as further described herein with respect to fig. 2, 13-14, 20-29, etc. In non-limiting aspects, for example, a standalone dedicated DFS sensor flexible proxy and/or DFS master may be configured to attach directly to one or more exemplary mesh nodes. In another non-limiting aspect, an exemplary, standalone dedicated DFS sensor flexible proxy and/or DFS master (e.g., a multi-channel DFS master, etc.) can be configured as part of an exemplary mesh network, e.g., as further described herein with respect to

exemplary mesh networks

3000, 3100, 3200, etc. and/or fig. 2, 13, 14, 24, 30-32, etc. Thus, example non-limiting embodiments may be configured to continuously detect radar on multiple DFS channels, may be configured to provide whitelists and blacklists of channels for individual mesh nodes, and/or may be configured to provide whitelists and blacklists for an entire example mesh network, as described herein, by an example cloud intelligence engine or otherwise. In another non-limiting aspect, one or more exemplary grid nodes can be configured to receive one or more black/white channel lists from an exemplary standalone dedicated DFS sensor flexible agent and/or a DFS master. In another non-limiting aspect, the one or more exemplary grid nodes can be further configured to fuse black/white channel lists from the exemplary standalone dedicated DFS sensor flexible agent and/or the DFS master with local information of the grid nodes, such as by the exemplary cloud intelligence engine, or otherwise, in order to derive one or more radar-free channels and/or the exemplary channel preference list. In another non-limiting aspect, one or more exemplary mesh nodes may be further configured to employ one or more exemplary channel preference lists such that, in the event of an actual radar 3102 event, one or more exemplary mesh nodes and/or the entire mesh network may move to another DFS channel without first performing CAC on the new channel, thereby reducing the resulting network downtime as would be required by CAC, as further described herein.

In further non-limiting embodiments, one or more example grid nodes, one or more example DFS sensor flexible agents and/or DFS master devices, etc. can be configured to transmit their radar events (e.g., radar information transmission 3008, etc.) to an example cloud intelligence engine, e.g., as described further herein with respect to fig. 2, 13-14, 20-42, etc. In a non-limiting aspect, an exemplary cloud intelligence engine as described herein can be further configured to data-fuse one or more radar events (e.g., radar messaging 3008, etc.) against other information sources, as further described herein. In another non-limiting aspect, the example cloud intelligence engine as described herein can be further configured to use reasoning and/or algorithms to distinguish random noise 3004 from radar 3102 in order to reduce false detections and/or network downtime in the example grid for networks employing DFS channels, as described herein, and can also be configured to make one or more determinations regarding one or more radar events (e.g., radar info transmission 3008, etc.) as a probability of actual radar 3102. In another example, as described herein, the example cloud intelligence engine may be further configured to transmit one or more suggestions regarding one or more radar events (e.g., one or more example mesh nodes) to one or more example mesh networks regarding one or more radar events regarding channel switching, regarding updates to one or more of a blacklist, a whitelist, a favorites list, and/or the like, as further described herein.

As described above, in another non-limiting aspect, one or more exemplary mesh networks and/or portions thereof may operate in one or more exemplary groups of mesh nodes, e.g., based in part on one or more further grouping criteria. In a non-limiting aspect, it may be desirable to combine certain exemplary mesh nodes of an exemplary mesh network, e.g., from a network performance perspective, from a location perspective, from a quality of service perspective, and so forth, without limitation. Thus, example embodiments as described herein may employ one or more of a blacklist, a whitelist and/or a channel preference list, which may differ in at least one respect between different example groups of mesh nodes, which may be similar or substantially similar, in part, based on one or more grouping criteria, between example mesh nodes within an example group. In further non-limiting aspects, the one or more grouping criteria may include, but are not limited to, network performance, location information and/or device characteristics associated with one or more exemplary mesh nodes, or quality of service, regulatory information, spectrum information associated therewith, and the like. Thus, in a non-limiting aspect, one or more blacklists, whitelists and/or channel preference lists may be shared within an exemplary grid set. Thus, in another non-limiting aspect, an exemplary mesh node, e.g., an exemplary access point, an exemplary router, an exemplary mobility agent, an exemplary mesh network node host device 3206 configured as a DFS master device (e.g., a multi-channel DFS master device), etc., can be configured to separate the exemplary mesh node into two or more groups, and two or more exemplary mesh node criteria for a group within an exemplary group can be configured based in part on one or more of the groups, as described herein, e.g., by an exemplary cloud intelligence engine or otherwise.

Thus, an exemplary mesh node configured as a DFS master, e.g., an exemplary access point, an exemplary router, an exemplary mobility agent, an exemplary mesh node host device 3206 (e.g., a multi-channel DFS master), etc., may be configured as a radar sensor, which may be further configured to provide an exemplary cloud intelligence engine with DFS channel radar information (e.g., radar information transmission 3008), location information, spectrum information, etc. As further described herein, in another non-limiting aspect, the example cloud intelligence engine can be configured to data-fuse such information and with external sources described herein, and can be further configured to provide one or more blacklist, whitelist and/or channel preference list (e.g., one or more of group blacklist, group whitelist, group channel preference list, etc.) criteria to the example mesh network based in part on the one or more groupings. As a result, an exemplary mesh node, e.g., an exemplary access point, an exemplary router, an exemplary mesh network node host device 3206 configured as a DFS master (e.g., a multi-channel DFS master), etc. May be configured to employ one or more of a group blacklist, a group whitelist, a group channel preference list, etc., for two or more groups in communication with the example grid node, such as by the example cloud intelligence engine, or otherwise. As described herein, an example channel preference list may include a list of DFS channels, wherein if one DFS channel needs to be vacated, each example mesh node in an example mesh network having the example channel preference list may be configured to switch to a next DFS channel in the example channel preference list, which facilitates the example mesh network of example mesh nodes to be configured as a single mesh network group sharing a single example group channel preference list. Further non-limiting embodiments may be configured to employ similar shared exemplary blacklists and exemplary whitelists between individual mesh network groups of an individual exemplary group of individual exemplary mesh nodes, and/or may be configured to use two or more sets of blacklists, whitelists, and/or channel preference lists (e.g., one or more of a set blacklist, a set whitelist, a set channel preference list, etc.), as described herein.

Fig. 43 depicts other example methods 4300 for reducing error detection and/or network downtime in an example mesh network employing DFS channels, in accordance with various non-limiting aspects. Accordingly, at 4302, fig. 43 depicts an example method 4300 comprising receiving, in a mesh network (e.g., example mesh network 3200, etc.) including a host device of a processor (e.g., example mesh node host device 3206 configured as a DFS master, such as a multi-channel DFS master, etc.), an indication of a suspected radar event on one or more Dynamic Frequency Selection (DFS) channels, as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-42, etc.

Further, at 4304, the example method 4300 for reducing error detection and/or network outages may further include determining whether a suspicious radar event related to a host device (e.g., an example mesh node host device 3206 configured as a DFS master, such as a multi-channel DFS master, etc.) is a valid radar event based at least in part on the suspicious radar event, as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-42, etc. By way of non-limiting example, exemplary method 4300 may further include: a determination is made whether the suspicious radar event is a valid radar event based in part on the additional radar information (e.g., from another radar information, a nearby or neighboring grid node or host device (e.g., an exemplary mesh network node host device 3206 configured as a DFS master, such as a multi-channel DFS master, etc.).

In further non-limiting embodiments, at 4306, the example method 4300 may further include transmitting radar information (e.g., radar information transmission 3008, etc.) in a mesh network (e.g., example mesh network 3200, etc.) to relate one or more suspicious radar events or valid radar events to another host device (e.g., example mesh node host device 3206, configured as a DFS master, e.g., a multi-channel DFS master, etc.) or a cloud intelligence engine (e.g.,

cloud intelligence engine

235, 2435, etc.) associated with the mesh network (e.g., example mesh network 3200, etc.), as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-42, etc. In a non-limiting aspect, the example method 4300 may include transmitting location information associated with a host device (e.g., the example mesh network node host device 3206, configured as a DFS master, such as a multi-channel DFS master, etc.). In non-limiting aspects, the example method 4300 may further include transmitting to the next channel information identifying one or more of the other host devices (e.g., the example mesh node host device 3206 configured as a DFS master, e.g., a multi-channel DFS master, etc.) or a cloud intelligence engine (e.g., the

cloud intelligence engines

235, 2435, etc.) associated with the mesh network (e.g., the example mesh network 3200, etc.) a next one of the one or more DFS channels transmitting a communication based in part on the one or more suspicious radar events or valid radar events, and/or encoding the next channel information in one or more beacon signals of the host device (e.g., the example mesh node host device 3206 configured as a DFS master, e.g., a multi-channel DFS master, etc.), as further described herein, for example, with respect to fig. 2, 13, 14, 24, 30-42, etc.

At 4308 of fig. 43, the example method 4300 may further include receiving additional radar information (e.g., radar information transmission 3008, etc.) including, but not limited to, location information from one or more of another host device associated with the mesh network (e.g., the example mesh network 3200, etc.), e.g., the example mesh node host device 3206 configured as a DFS master (such as a multi-channel DFS master, etc.), or a cloud intelligence engine (e.g.,

cloud intelligence engine

235, 2435, etc.).

Additionally, fig. 43 depicts an example method 4300 that further includes determining, at 4310, whether the suspicious radar event is a valid radar event or an invalid radar event, and transmitting, at 4312, one or more of additional radar information (e.g., radar information transmission 3008, etc.), the valid radar event or additional location information to one or more of another host device (e.g., an example mesh node host device 3206 configured as a DFS master (such as a multi-channel DFS master, etc.) or a cloud intelligence engine (e.g.,

cloud intelligence engines

235, 2435, etc.) associated with the mesh network (e.g., an example mesh network 3200, etc.), as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-42, etc. By way of non-limiting example, exemplary method 4300 may include: a radar event that determines whether a suspected radar event is valid or invalid, for example, by utilizing two or more radar sensors or detectors (e.g., a primary DFS master, a secondary DFS master, a multi-channel DFS master, a standalone DFS master, a flexible proxy, whether embedded or distributed) associated with a host device (e.g., an exemplary mesh node host device 3206 configured as a DFS master, such as a multi-channel DFS master, etc.) to verify the radar event, and/or to verify the radar event based in part on additional radar information (e.g., radar information transmission 3008, etc.), additional location information, or from another host device (e.g., an exemplary mesh node host device 3206 configured as a DFS master, such as a multi-channel DFS master, etc.) associated with a mesh network (e.g., exemplary mesh network 3200, etc.) or a cloud intelligence engine (e.g.,

cloud intelligence engines

235, 2435, etc.).

In further non-limiting implementations, the example method 4300 may further include, based in part on receiving the indication of the suspected radar event, transmitting one or more of a CTS signal 4102 or a hold signal 4202 on the one or more DFS channels in a mesh network (e.g., the example mesh network 3200, etc.), encoding one or more of the CTS signal 4102 or the hold signal 4202 (where the information is associated with a predetermined time or duration that communications on the one or more DFS channels are to be muted), and/or transmitting a recovery signal 4204 in the mesh network (e.g., the example mesh network 3200, etc.), the communications on the one or more DFS channels to be recovered for the recovery signal 4204, as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-42, etc. Additionally, the exemplary method for 300 may further comprise: updating a channel blacklist, a channel whitelist or a channel preference list using a host device (e.g., an example mesh node host device 3206 configured as a DFS master, such as a multi-channel DFS master, etc.) based at least in part on one or more suspected or valid radar events, and/or updating a channel blacklist, a channel whitelist or a channel preference list of a group comprising at least the host device (e.g., an example mesh node host device 3206 configured as a multi-channel DFS master, such as a multi-channel DFS master, etc.) and another host device (e.g., an example mesh node host device 3206 configured as a DFS master, such as a multi-channel DFS master, etc.) based at least in part on one or more grouping criteria for the group, wherein the group comprises less than all mesh nodes in a mesh network (e.g., an example mesh network 3200, etc.) communicating on one or more DFS channels, as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-42, etc.

FIG. 44 depicts a functional block diagram illustrating an example non-limiting apparatus or system suitable for use with aspects of the disclosed subject matter. For example, fig. 44 illustrates an example non-limiting device or system 4400 (e.g., a primary DFS master, a secondary DFS master, a multi-channel DFS master, a standalone DFS master, a flexible proxy, whether embedded or distributed, etc.) adapted to perform various aspects of the disclosed subject matter in accordance with

example DFS masters

3206, 3208, etc., detecting a suspicious radar event, as further described herein. In non-limiting embodiments, the example device or system 4400 may include one or more radar sensors or detectors (e.g., a primary DFS master, a secondary DFS master, a multi-channel DFS master, a standalone DFS master, a flexible proxy, whether embedded or distributed, etc.) in communication with a host device (e.g., an example mesh node host device 3206 configured to receive an indication of suspected radar, such as a DFS master of a multi-channel DFS master, etc.) event on one or more DFS channels in a mesh network (e.g., the example mesh network 3200, etc.), as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-42, etc.

In further non-limiting embodiments, the example device or system 4400 may include one or more processors of a multi-channel DFS master (e.g., an example mesh network node host device 3206 configured as a DFS master, such as a multi-channel DFS master, etc.) configured to determine whether a suspected radar event is a valid radar event based at least in part on an indication of the suspected radar event, as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-42, etc. In non-limiting examples, example limitations of the device or system 4400 can include the multi-channel DFS master (e.g., the example mesh node host device 3206, configured as a DFS master, such as a multi-channel DFS master, etc.) being further configured to determine whether a suspected radar event is a valid or invalid radar event, e.g., via one or more radar detectors, e.g., as an example flexible proxy 3208, whether embedded or distributed, associated with the multi-channel DFS master (e.g., the example mesh node host device 3206 configured as a DFS master, e.g., a multi-channel DFS master, etc.), as further described herein, and whether by an example cloud intelligence engine (e.g., the

cloud intelligence engine

235, 2435, etc.) or otherwise.

In other non-limiting implementations of the example device or system 4400, the disclosed embodiments may include an example multi-channel DFS master (e.g., an example mesh network node host device 3206 configured as a DFS master, such as a multi-channel DFS master, etc.) further configured to update one or more of a channel blacklist, a channel whitelist, or a channel preference list based on one or more of the suspected radar events or valid radar events, as further described herein, e.g., with respect to figures in another non-limiting aspect, an example multi-channel DFS master (e.g., an example mesh network node host device 3206 configured as a DFS master, such as a multi-channel DFS master, etc.) may be further configured to update a channel blacklist for a group including at least the multi-channel DFS master and a mesh node, one or more of a channel whitelist or a channel preference list based, at least in part, on the group of one or more grouping criteria, wherein the group includes all mesh nodes in the mesh network (e.g., exemplary mesh network 3200, etc.) communicating over the one or more DFS channels.

Additionally, the example device or system 4400 can further include one or more communication components 4402 associated with the multi-channel DFS master device, configured to communicate, in the mesh network, a transmission of one or more suspicious or valid radar events to one or more of a mesh node (e.g., the example mesh node) or a cloud intelligence engine (e.g., the

cloud intelligence engines

235, 2435, etc.) associated with the mesh network. In a non-limiting aspect, the example communication component 4402 can include or be associated with one or more of the flexible proxy 200, the DFS master 2400, the host device 3002, an example mesh network node host device 3206 configured as a DFS master, such as a multi-channel DFS master, or the like, or portions thereof. In a non-limiting aspect, the one or more communication components 4402 can also be configured to communicate location information associated with a multi-channel DFS master (e.g., an exemplary mesh network node host device 3206 configured as a DFS master, such as a multi-channel DFS master, etc.). In another non-limiting aspect, the one or more communication components 4402 may also be configured to receive and/or transmit additional radar information (e.g., radar information transmission 3008)) from one or more of the mesh nodes (e.g., exemplary mesh nodes) or cloud intelligence engines (e.g.,

cloud intelligence engines

235, 2435, etc.) associated with the mesh network (e.g., exemplary mesh network 3200, etc.), and may be configured to transmit one or more of the additional radar information (e.g., radar information transmission 3008, etc.), valid or invalid radar events, or additional location information (e.g.,

cloud intelligence engines

235, 2435, etc.) to one or more of the mesh nodes (e.g., exemplary mesh nodes) or cloud intelligence engines associated with the mesh network (e.g., exemplary mesh network 3200, etc.), and/or the like.

In further non-limiting aspects, one or more communication components 4402 may also be configured to transmit CTS signals 4102 in a mesh network (e.g., exemplary mesh network 3200, etc.) or based at least in part on an indication of a suspected radar event, maintain signals 4202 on the one or more DFS channels, and may be configured to encode one or more of CTS signals 4102 or maintain signals 4204, wherein the information is associated with a predetermined time or duration for which communications on the one or more DFS channels are to be muted, as further described herein, e.g., with respect to fig. 1 and 2. Additionally, one or more communication components 4402 can be further configured to transmit a resume signal 4204 in a mesh network (e.g., exemplary mesh network 3200, etc.), wherein communications on one or more DFS channels are to be resumed, as further described herein.

In still other non-limiting aspects, one or more communication components 4402 can be further configured to communicate next channel information identifying a next channel to one or more DFS channels associated with a mesh node (e.g., an exemplary mesh node) or cloud intelligence engine (e.g., one or more DFS channels associated with an intelligent network (e.g., an exemplary mesh network 3200, etc.) to base in part on one or more suspected or valid radar events, and/or can be configured to encode a next channel information host, e.g., a multi-channel DFS host, etc., for one or more beacon signals of the multi-channel DFS host (e.g., an exemplary mesh node host device 3206 configured as a DFS), as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-42, etc.), for example

FIG. 45 depicts an example non-limiting device or system 4500, or portion thereof, suitable for performing various aspects of the disclosed subject matter. Device or system 4500, or portions thereof, can be a standalone device or portion thereof, a specifically programmed computing device or portion thereof (e.g., a memory-holding instructions of a technology coupled to a processor for executing a processor of the technology as described herein), and/or a composite device or system including one or more cooperating components distributed among several devices, as further described herein. By way of example, the example non-limiting device or system 4500, or portion thereof, can include the example devices and/or systems, or portions thereof, with respect to fig. 2, 24, etc., e.g., with respect to the flexible proxy 200, the DFS master 2400, a multi-channel DFS master (e.g., the example mesh node host device 3206 configured as a DFS master, such as a multi-channel DFS master, etc.), and/or the like. For example, fig. 45 depicts an example device 4500, e.g., an example mesh node, as further described herein, e.g., with respect to fig. 2, 13, 14, 24, 30-42, etc.

Thus, the device or system 4500 can include a memory 4502 that retains various instructions for facilitating various operations, such as: receiving a suspected radar event on one or more DFS channels in a mesh network (e.g., mesh network 3200, etc.); determining whether the suspicious radar event is a valid radar event based in part on the suspicious radar event; transmitting radar information (e.g., radar information transmission 3008, etc.) in a mesh network (e.g., mesh network 3200, etc.) regarding one or more suspicious radar events or valid radar events to one or more meshes (e.g., exemplary mesh nodes) or cloud intelligence engines (e.g.,

cloud intelligence engines

235, 2435, etc.) associated with the mesh network (e.g., exemplary mesh network 3200, etc.); for transmitting one or more of CTS signals 4102 or hold signals 4202 on one or more DFS channels in a mesh network (e.g., exemplary mesh network 3200, etc.) based in part on receiving a suspected radar event; means for transmitting, in a mesh network (e.g.)), a recovery signal 4202 to recover communications on at least one DFS channel; and/or the like.

Additionally, memory 4502 may retain further and/or alternative instructions for performing various functions and/or operations described herein, including instructions associated with performing the example methods described herein, e.g., as described further herein, e.g., with respect to fig. 2, 13, 14, 24, 30-43, etc. Thus, the above-described example instructions and other instructions suitable for the functions and/or operations described herein, e.g., with respect to FIGS. 2, 13, 14, 24, 30-43, etc., may be retained within the memory 4502, such as

memory

202, 2402, 249, 2449 and processor 4504, e.g.,

processors

203, 2403, 250, 2450, etc., may be employed with the execution of the instructions, without limitation.

Example network and distributed Environment

It will be appreciated by one of ordinary skill in the art that the various embodiments of the disclosed subject matter and related systems, devices, and/or methods described herein can be implemented in connection with any computer or other client or server device, which can be deployed as part of a communication system, computer network, and/or distributed computing environment, and which can be connected to any kind of data store. In this regard, the various embodiments described herein may be implemented in any computer system or environment having any number of memory or storage units, and any number of applications and processes that may occur across any number of storage units or volumes may use a communication system in connection using the techniques, systems, and methods of use in accordance with the disclosed subject matter. The disclosed subject matter may apply to server computers and client computers deployed in network environments or distributed computing environments with remote or local storage. The disclosed subject matter can also apply to a standalone computing device, having programming language functionality, and interpretation and execution capabilities for generating, receiving, storing and/or transmitting information related to remote or local services and processes.

Distributed computing provides sharing of computer resources and services through the exchange of communications between computing devices and systems. These resources and services may include information exchange, cache storage, and disk storage for objects such as files. These resources and services may also include sharing processing power across multiple processing units to achieve load balancing, resource expansion, processing specialization, and so forth. Distributed computing utilizes network connections, allowing customers to leverage their collective power to benefit the entire enterprise. In this regard, various devices may have applications, objects, or resources that may utilize the disclosed and related systems, devices, and/or methods described for various embodiments of the subject disclosure.

FIG. 46 provides a schematic diagram of an example networked or distributed computing environment. The distributed computing environment comprises computing

objects

4610, 4612, etc. and computing objects or

devices

4620, 4622, 4624, 4626, 4628, etc., which may include programs, methods, data stores, programmable logic, etc., such as

applications

4630, 4632, 4634, 4636, 4638. It is understood that the

objects

4610, 4612, etc. and computing objects or

devices

4620, 4622, 4624, 4626, 4628, etc. may comprise different devices, such as a PDA, an audio/video device, a cellular phone, an MP3 player, a personal computer, a notebook computer, etc

Each

object

4610, 4612, etc. and computing objects or

devices

4620, 4622, 4646, 4626, 4628, etc. may communicate with one or more

other objects

4610, 4612, etc. and with computing objects or

devices

4620, 4622, 4624, 4626, 4628, etc. over the communications network 4640, either directly or indirectly. Even though shown as a single element in FIG. 46, network 4640 may comprise other computing objects and computing devices that provide services to the system of FIG. 46, and/or may represent multiple interconnected networks, which are not shown. Each

object

4610, 4612, etc. or 4620, 4622, 4624, 4626, 4628, etc. may also include an application, such as

applications

4630, 4632, 4634, 4636, 4638, which may utilize APIs or other objects, software, firmware and/or hardware, suitable for communication with or implementation of the disclosed and related systems, devices, methods and/or functions provided in accordance with various embodiments of the present disclosure. Thus, while the depicted physical environment may show the connected devices as computers, such illustration is merely an example, and instead a physical environment comprising various digital devices, any of which may use various wired and/or wireless services, software objects such as interfaces, COM objects, and so forth, may be depicted or described.

There are a variety of systems, components, and network configurations that support distributed computing environments. For example, computing systems may be connected together by wired or wireless systems, local networks, or widely distributed networks. Currently, many networks are coupled to the internet, which may provide an infrastructure for widely distributed computing and may encompass many different networks, although any network infrastructure may be used, for example, to employ the disclosed and related systems, devices, and/or methods described in various embodiments in advance.

Thus, a large number of network topologies and network infrastructures, such as client/server, peer-to-peer or hybrid architectures, may be utilized. A "client" is a member of a class or group that uses the services of another class or group independent thereof. A client may be a process, such as an approximate set of instructions or tasks, that requests a service provided by another program or process. The client process utilizes the requested service without having to "know" any working details about the other program or the service itself.

In a client/server architecture, particularly a networked system, a client is typically a computer that accesses shared network resources provided by another computer (e.g., a server). As shown in FIG. 46 in the description of the figures,

computers

4620, 4622, 4624, 4626, 4628, etc. may be considered clients and

computers

4610, 4612, etc. may be considered servers of

servers

4610, 4612, etc. providing data services, such as receiving data from

client computers

4620, 4622, 4624, 4626, 4628, etc., storing the data, processing the data, sending the data to

client computers

4620, 4622, 4624, 4626, 4628, etc., as non-limiting examples, although any computer may be considered a client, a server, or both, depending on the circumstances. Any of these computing devices may be the task of one or more embodiments of processing data, forming metadata, synchronizing data or requesting services or related systems, devices and/or methods that may implicate the disclosure.

A server is typically a remote computer system accessible over a remote or local network, such as the internet or wireless network infrastructure. The client process may be active in a first computer system and the server process may be active in a second computer system, communicating with each other over a communications medium, providing distributed functionality and allowing multiple clients to take advantage of the functionality of the information-gathering server. Any software objects utilized in accordance with the disclosed and related systems, devices, and/or methods may be provided independently, or distributed across a plurality of computing devices or objects.

In a network environment in which the communications network/bus 4640 is the Internet, for example, Web servers such as

servers

4610, 4612, etc., which may be

clients

4620, 4622, 4624, 4626, 4628, etc., communicate via any of a number of known protocols such as the hypertext transfer protocol (HTTP).

Servers

4610, 4612, etc. may also serve as

clients

4620, 4622, 4624, 4626, 4628, etc., as may be characteristic of a distributed computing environment.

Example computing device

As mentioned, advantageously, the techniques described herein may be applied to devices or systems in which it is desirable to use the disclosed and related systems, devices, and/or methods. Accordingly, it should be understood that a variety of handheld, portable and other computing devices and a variety of computing objects are contemplated for use in various disclosed embodiments. Accordingly, the below general purpose remote computer described below in FIG. 47 is but one example of a computing device. In addition, the disclosed and related systems, devices, and/or methods may include one or more aspects of the following general-purpose computers, such as display, storage, analysis, control, and the like.

Although not required, the embodiments can be implemented in part via an operating system, for use by a developer for a device or object, and/or included within application software that operates to perform one or more functional aspects of the various embodiments. Software may be described in the general context of computer-executable instructions, such as program modules, being executed by one or more computers (such as client workstations, servers or other devices). Those skilled in the art will appreciate that computer systems have a variety of configurations and protocols that can be used to transfer data and, thus, any particular configuration or protocol should not be considered limiting.

Thus, fig. 47 illustrates an example of a suitable computing system environment 4700 in which one or aspects of the embodiments described herein can be implemented, although as made clear above, the computing system environment 4700 is only one example of a suitable computing environment and is not intended to suggest any limitation as to scope of use or functionality. Neither should the computing environment 4700 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the example operating environment 4700.

With reference to FIG. 47, an exemplary remote device for implementing one or more embodiments includes a general purpose computing device in the form of a computer 4710. Components of computer 4710 may include, but are not limited to, a processing unit 4720, a system memory 4730, and a system bus 4722 that couples various system components including the system memory to the processing unit 4720.

Computer 4710 typically includes a variety of computer readable media and can be any available media that can be accessed by computer 4710. The system memory 4730 may include computer storage media in the form of volatile and/or nonvolatile memory such as Read Only Memory (ROM) and/or Random Access Memory (RAM). By way of example, and not limitation, memory 4730 may also include an operating system, application programs, other program modules, and program data.

A user may enter commands and information into the computer 4710 through the input device 4740. A monitor or other type of display device is also connected to the system bus 4722 via an interface, such as output interface 4750. Computers other than monitors may also include other peripheral output devices such as speakers and printer, which may be connected through output interface 4750.

The computer 4710 may operate in a networked or distributed environment using logical connections to one or more other remote computers, such as a remote computer 4770. The remote computer 4770 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, or any other remote media consumption or transmission device, and may include any or all of the elements described above relative to the computer 4710. 47 includes a network 4772, such Local Area Network (LAN) or Wide Area Network (WAN), but may also include other networks/buses. Such networking environments are commonplace in homes, offices, enterprise-wide computer networks, intranets and the Internet.

As mentioned above, while example embodiments have been described in connection with various computing devices and network architectures, the underlying concepts may be applied to any network system and any computing device or system therein

Further, various manners of implementing the same or similar functionality, e.g., an appropriate API, tool kit, driver code, operating system, control, standalone or downloadable software object, etc., enable applications and services to utilize the disclosed and related systems, devices, methods, and/or functionality. Accordingly, embodiments herein are considered from the perspective of an API (or other software object) as well as software or hardware objects that implement one or more aspects of the disclosed and related systems, devices, and/or methods described herein. Thus, various embodiments described herein may have aspects that are wholly in hardware, partly in software, and in software.

Example Mobile device

Fig. 48 depicts a schematic diagram of an exemplary mobile device 4800 (e.g., a mobile handset) that can facilitate various non-limiting aspects of the disclosed subject matter, according to embodiments described herein. Although a mobile handset 4800 is shown here, it is understood that the other devices may be mobile devices, for example, as described herein, and that mobile handset 4800 is only shown to provide context for embodiments of the subject matter described herein. The following discussion is intended to provide a brief, general description of an example of a suitable environment 4800 in which various embodiments may be implemented. While the description includes a general context of computer-executable instructions embodied on a tangible computer-readable storage medium, those skilled in the art will recognize that the subject matter also can be implemented and software in combination with other program modules and/or hardware.

Generally, applications (e.g., program modules) can include routines, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the methodologies described herein may be implemented with other system configurations, including single-processor or multiprocessor systems, minicomputers, mainframe computers, as well as personal computers, hand-held computing devices, microprocessor-based or programmable consumer electronics, and the like, each of which may be operatively coupled to one or more associated devices.

Computing devices may typically include a variety of computer-readable media. Computer readable media can include any available media that can be accessed by the computer and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise tangible computer-readable storage and/or communication media. Tangible computer-readable memory may include volatile and/or nonvolatile, removable and/or non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. Tangible computer readable memory may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD ROM, Digital Video Disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer.

Communication media in contrast to tangible computer-readable memory typically embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable communication media, which can be distinguished from computer readable storage media.

The handset 4800 may include a processor 4802 for controlling and processing all on-board operations and functions. The memory 4804 interfaces with the processor 4802 for storing data and one or more application programs 4806 (e.g., communication application programs such as browsers, application programs, etc.). Other applications may support operation of communication and/or financial communication protocols. Application programs 4806 may be stored in memory 4804 and/or firmware 4808, and executed by processor 4802 from either memory 4804 or/and firmware 4808One or both. Firmware 4808 may also store boot code for initializing handset 4800. The communication component 4810 interfaces with the processor 4802 to facilitate wired/wireless communication with external systems such as cellular networks, VoIP networks, and the like. Here, the communications component 4810 can also include a suitable cellular transceiver 4811 (e.g., a GSM transceiver) and/or unlicensed transceiver 4813 (e.g., wireless fidelity (WiFi) for respective signals^TM) Worldwide interoperability for microwave access)

) And (4) communication. Handset 4800 can be a device such as a cellular phone, PDA with mobile communication capability, and message-centric device. The communications component 4810 also facilitates reception of communications from terrestrial radio networks (e.g., broadcast), digital satellite radio networks, and internet-based radio service networks.

The handset 4800 includes a display 4812 for displaying text, images, video, telephony functions (e.g., caller identification functions), setup functions, and for user input. For example, the display 4812 may also be referred to as a "screen" that may accommodate presentation of multimedia content (e.g., musical metadata, messages, wallpaper, graphics, etc.). The display 4812 may also display video and may facilitate the generation, editing, and sharing of video offers. A serial I/O interface 4814 is provided in communication with the processor 4802 to facilitate wired and/or wireless serial communication (e.g., Universal Serial Bus (USB) and/or Institute of Electrical and Electronics Engineers (IEEE)4894) hardwire connections and other serial input devices (e.g., keyboard, and mouse) in the following manner. This supports, for example, the updating and troubleshooting of the handset 4800. The audio function is provided with an audio I/O component 4816, which audio I/O component 4816 may comprise a speaker for outputting audio signals related to, for example, instructing the user to press the correct key or key combination to initiate a user feedback signal. The audio I/O component 4816 also facilitates the input of audio signals through the microphone to record data and/or telephone voice data and for the input of voice signals for telephone conversations.

The handset 4800 may include a timeslot interface 4818 for accommodating a SIC (subscriber identity component) in the form of a card Subscriber Identity Module (SIM) or a generic SIM 4820 and interfacing the SIM card 4820 with the processor 4802. However, it should be understood that the SIM card 4820 can be manufactured as a handset 4800 and updated by downloading data and software.

Handset 4800 can process Internet Protocol (IP) data traffic through communications component 4810 to accommodate IP networks from, for example, the internet, corporate intranets, home networks, private area networks, etc., through an ISP or broadband cable provider. Thus, VoIP traffic can be used by handset 4800 and can receive IP-based multimedia content in an encoded or decoded format.

A video processing component 4822 (e.g., camera and/or associated hardware, software, etc.) may be provided to decode the encoded multimedia content. The video processing component 4822 can help facilitate the generation and/or sharing of videos. The handset 4800 also includes a power supply 4824 in the form of a battery and/or an Alternating Current (AC) power subsystem, the power supply 4824 may interface (I/O) components 4826 with an external power system or charging device (not shown) via power input/output.

Handset 4800 can also include a video component 4830 for processing received video content and a video component 4830 for recording and transmitting video content. For example, video component 4830 can facilitate video generation, editing, and sharing. Location tracking component 4832 facilitates geolocation of handset 4800. User input component 4834 facilitates user input of data and/or selection as previously described. The user input component 4834 may also facilitate selection of perspective recipients for funds transfer, input the number of requested transfers, indicate account limits and/or restrictions, and combine messages and other user input tasks as context requires. User input component 4834 may include conventional input device technology such as a keyboard, mouse, stylus, and/or touch screen.

Referring again to application 4806, hysteresis component 4836 facilitates analysis and processing of hysteresis data that is utilized to determine when to associate with an access point. A software triggering component 4838 can be provided when WiFi is^TM Transceiver 4813 facilitate triggering of hysteresis component 4838 when a beacon of the access point is detected. SIP client 4840 enables handset 4800 to support the SIP protocol and register users with a SIP registrar. The application 4806 may also include a communication application or client 4846 that may, among other possibilities, transfer money plug-ins or targets user interface component functionality as described above.

As described above, the handset 4800 associated with the communications component 4810 includes the indoor network transceiver 4813 (e.g., WiFi)^TMA transceiver). This functionality supports an indoor radio link, such as IEEE 802.11, for a dual mode global system for mobile communications (GSM) handset 4800. Handset 4800 can be built into a single handset at least with a satellite radio service chip that can combine wireless voice and digital radio.

In this specification, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless specified otherwise, or clear from context, "X employs A or B" is intended to mean any of the natural inclusive permutations. That is, if X employs A; x employs B or X employs both A and B, then "X employs A or B" in any of the foregoing instances. In addition, the articles "a" and "an" as used in this specification and the drawings should generally be construed to mean "one or more" unless specified otherwise or clear from context to be directed to a singular form.

Furthermore, the terms "example" and "such as" are used herein to mean serving as an example or illustration. Any embodiment or design described herein as "exemplary" or associated with "such as" a clause is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, use of the terms "example" or "such as" are intended to present concepts in a concrete fashion. The terms "first," "second," "third," and the like as used in the claims and the specification are for clarity only and do not necessarily denote or imply any temporal order unless the context clearly dictates otherwise.

What has been described above includes examples of one or more embodiments of the disclosure. For the purposes of describing these examples, it is, of course, not possible to describe every conceivable combination of components or methodologies, and it is to be appreciated that many further combinations and permutations of the present embodiments are possible. Accordingly, the embodiments disclosed and/or claimed herein are intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the detailed description and the appended claims. Furthermore, if the term "includes" is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term "comprising" as "comprising" is interpreted when employed as a transitional word in a claim.

Claims

1. A method of selecting available channels, comprising:

in a mesh network, receiving, at a host device comprising a processor, an indication of a suspected radar event on at least one dynamic frequency selective, DFS, channel;

determining, by the host device, based at least in part on the suspicious radar event, whether the suspicious radar event is a valid radar event;

in a mesh network, communicating radar information regarding at least one of a suspicious radar event or a valid radar event to at least one of another host device or a cloud intelligence engine associated with the mesh network; and

In a mesh network, at least one of the following signals is transmitted:

sending a clear-to-send (CTS) signal based at least in part on receiving an indication of a suspect radar event;

transmitting a hold signal on the at least one DFS channel based at least in part on receiving an indication of a suspected radar event; or

Transmitting a recovered signal on the at least one DFS channel where communication is to be recovered.

2. The method of claim 1, wherein communicating radar information further comprises:

location information associated with the host device is transmitted.

3. The method of claim 1, further comprising:

receiving additional radar information from the at least one of the cloud intelligence engine or the another host device associated with the mesh network.

4. The method of claim 3, wherein determining whether the suspicious radar event is a valid radar event comprises:

determining whether the suspicious radar event is a valid radar event based at least in part on the suspicious radar event and the additional radar information.

5. The method of claim 3, wherein receiving additional radar information comprises:

additional location information associated with the other host device is received.

6. The method of claim 5, further comprising:

determining that the suspect radar event is a valid radar event; and

communicating at least one of the additional radar information, the valid radar event, or the additional location information to the at least one of another host device or a cloud intelligence engine associated with the mesh network.

7. The method of claim 6, wherein determining that the suspicious radar event is a valid radar event comprises:

determining that a suspicious radar event is a valid radar event based at least in part on the suspicious radar event and at least one of the additional radar information and the additional location information received from the at least one of the cloud intelligence engine or the another host device associated with the mesh network.

8. The method of claim 5, further comprising:

determining that the suspect radar event is an invalid radar event; and

transmitting at least one of the additional radar information, the invalid radar event, or the additional location information to at least one of another host device associated with a mesh network or the cloud intelligence engine.

9. The method of claim 1, wherein transmitting at least one of a CTS signal or a hold signal comprises:

Encoding information in the at least one of a CTS signal or a maintenance signal, wherein the information is associated with a predetermined time or duration for which communication over the at least one DFS channel is to be muted.

10. A system for selecting available channels, comprising:

at least one radar detector configured to: receiving an indication of a suspected radar event on at least one dynamic frequency selection, DFS, channel in a mesh network;

at least one processor of a multi-channel DFS master; and

at least one communication component associated with the multi-channel DFS master device configured to: in a mesh network, communicating information regarding at least one of a suspicious radar event or a valid radar event to at least one of a mesh node or a cloud intelligence engine associated with the mesh network, wherein the at least one communication component is further configured to: receive additional radar information from the at least one of the grid nodes or the cloud intelligence engine associated with a mesh network, and wherein the multi-channel DFS master is configured to: determining whether the suspicious radar event is a valid radar event based at least in part on the suspicious radar event or based at least in part on the suspicious radar event and the additional radar information,

Wherein the at least one communication component is further configured to:

11. The system of claim 10, wherein the at least one communication component is further configured to: transmitting location information associated with the multi-channel DFS master device.

12. The system of claim 10, wherein the at least one communication component is further configured to: additional location information associated with the mesh node is received.

13. The system of claim 12, wherein the multi-channel DFS master device is further configured to: determining that the suspicious radar event is a valid radar event based at least in part on the suspicious radar event and additional radar information and additional location information received from the at least one of a mesh node or a cloud intelligence engine associated with the mesh network, and wherein the at least one communications component is further configured to: communicating at least one of additional radar information, a valid radar event, or additional location information to the at least one of a mesh node or a cloud intelligence engine associated with the mesh network.

14. The system of claim 12, wherein the multi-channel DFS master device is further configured to: determining that a suspect radar event is an invalid radar event, and wherein the at least one communications component is further configured to: transmitting the additional radar information, the ineffective radar event, or the additional location information to the at least one of a mesh node or a cloud intelligence engine associated with the mesh network.