System and method for access point coordination

Abstract

A coordinated multiple-AP system and method for alleviating AP overloading, sticky clients, and RF interference for use in a non-WLAN Controller (WLC) communication environment, such as a home network. In the present system and method AP periodically measure the communication environment and share the measured data with other APs in the same communication environment. The shared communication environment data is utilized to collaboratively determine best data transmission scenarios for supported clients. Best data transmission scenarios include but are not limited to optimized Client Link Management and Radio Resource Management.

Claims

1. A first access point (AP) operating on a first channel of a wireless environment, comprising: a receiving portion configured to measure the wireless environment at the first AP; a processing portion configured to generate a first client association report (CAR) based on the measured wireless environment at the first AP; a transmitting portion configured to transmit the first CAR to a second AP in communication with the first AP and the wireless environment, wherein the second AP is different from the first AP, and the second AP operating on a second channel of the wireless network environment different from the first channel; wherein the receiving portion is further configured to receive a second CAR from the second AP, wherein the second CAR is based on a measurement of the wireless environment at the second AP; wherein the processing portion is further configured to (i) jointly process the first and second CARs, (ii) reach a consensus decision for a cooperative action with the second AP, (iii) determine, based on the consensus decision, that the first AP is to change its operation from the first operating channel to the second operating channel, and (iv) cause the first AP to operate on the second operating channel.

2. The first AP of claim 1, wherein the processing portion is further configured to execute an algorithm shared with the second AP.

3. The first AP of claim 2, wherein the processing portion is further configured to execute the shared algorithm according to a predetermined schedule.

4. The first AP of claim 3, wherein the processing portion is further configured to execute the shared algorithm periodically.

5. The first AP of claim 1, further comprising a direct communication link with the second AP.

6. The first AP of claim 1, wherein the receiving portion is further configured to obtain a holistic view of a network within the wireless environment that includes the first and second APs.

7. The first AP of claim 6, wherein the processing portion is further configured to coordinate with the second AP to enable at least one of client link management and radio resource management of the network.

8. The first AP of claim 7, wherein the processing portion is further configured to avoid radio frequency interference while maintaining a high throughput of a fronthaul and a backhaul of the network.

9. The first AP of claim 7, wherein the processing portion is further configured to maintain the high throughput based on a change to one or more of (i) the first channel to the second channel, (ii) a network band, (iii) a channel width, and (iv) a transmit power.

10. The AP of claim 1, wherein the processing portion is further configured to distribute a client handover from the first AP to the second AP according to the cooperative action and the consensus decision reached through communication between the first AP and the second AP.

11. The first AP of claim 1, wherein the processing portion is further configured to utilize a predictive algorithm to generate predictive data based on the first and second CARs shared between the first and second APs.

12. The first AP of claim 1, wherein the processing portion is further configured to coordinate AP discovery between the first and second APs.

13. An upstream monitoring and management interface for a wireless environment of a plurality of access points (APs), the interface in operable communication with a first AP of the plurality of APs, the interface comprising: an upstream receiving portion configured to obtain (i) a first client association report (CAR) generated by the first AP based on a measurement of the wireless environment at the first AP, and (ii) a second CAR from a second AP of the plurality of APs; a processing portion to jointly process the first and second CARs and calculate a cooperative action between the first AP and the second AP based on the jointly processed first and second CARs, the calculated cooperative action including at least one of (i) that a first client in communication with the first and second APs is to be steered to the first AP from the second AP or to the second AP from the first AP, and (ii) the first AP is to change its operation from a first operating channel of the wireless environment to a second operating channel of the wireless environment different from the first operating channel, a downstream transmitting portion configured to direct the first AP to execute the calculated cooperative action, wherein the second CAR is based on a measurement of the wireless environment at the second AP, and wherein the second AP is in operable communication with at least one of the interface and the first AP.

14. The interface of claim 13, wherein the upstream receiving portion is further configured to obtain the second CAR directly from the second AP.

15. The interface of claim 13, wherein the upstream receiving portion is further configured to obtain the second CAR from the first AP in operable communication with the second AP.

16. The interface of claim 15, wherein the processing portion is further configured to utilize a predictive algorithm to generate predictive data based on a sharing of the first and second CARs between the first and second APs.

17. The interface of claim 13, wherein the processing portion is further configured to execute an algorithm shared with at least one of the first AP and the second AP.

18. The interface of claim 17, wherein the processing portion is further configured to execute the shared algorithm according to at least one of (i) a predetermined schedule, and (ii) a periodic timing scheme.

19. The interface of claim 13, wherein the upstream receiving portion is further configured to obtain a holistic view of a network within the wireless environment that includes the first and second APs.

20. The interface of claim 19, wherein the processing portion is further configured to coordinate with the second AP to enable at least one of client link management and radio resource management of the network.

Description

BRIEF DESCRIPTION OF THE INVENTION

(1) FIGS. 1A-1C show multi-AP system configured to steer a client between APs through AP coordination, in an embodiment.

(2) FIG. 2 is a timing diagram for a centrally controlled multi-AP system that includes a rootAP and two APs, in an embodiment.

(3) FIG. 3 is a timing diagram for a collaborative multi-AP system that includes three APs, in an embodiment.

(4) FIG. 4 shows a crowded Multi-AP environment with three APs, in an embodiment.

(5) FIG. 5 shows one exemplary multi-AP system with data utilized in one least cost routing calculus, in an embodiment.

DETAILED DESCRIPTION OF THE FIGURES

(6) There are current and emerging standards that specify information to be exchanged between APs and clients. This information allows clients to make better decisions about AP association, and provides information for APs to steer clients to better connections. Often there are clients in the home that do not support these standards. In such cases APs must force clients off an AP to steer them to other channels or bands. However, regardless of whether the clients have implemented these management standards, APs can better manage the network by coordinating efficient client handover and distribution among themselves. For example, a client's current AP can provide a recommendation to, or even force, the client to move to a different Basic Server Set (BSS) based on data describing the AP's own load conditions as well as that of the other APs in the ESS.

(7) In an enterprise environment, the WLAN Controller (WLC) is an essential part of the network and manages the inter-AP communication and coordination in a vendor-proprietary manner. In a home network, however, where there is no WLC, there are also no standards or even defined best practices about how multiple APs in a home ESS should communicate with each other. This is one problem the present invention solves. Other areas of network optimization (e.g., channel and TX power optimization) are also possible utilizing the present in-home AP-AP coordination.

(8) Table 1, below, presents a list of network issues, trigger events, information shared between APs to assist in resolving the network issue (called herein a “Client Association Report” or “CAR” for short), and the AP coordinated decision.

(9) TABLE-US-00001 TABLE 1 Information Shared AP Coordinated Network Issue Trigger Event(s) between APs Decision Sticky client on AP1 sees client TX rate goes Client MAC address; Each AP’s AP1 andAP2 AP1 below a predetermined low observed RSSI of the client; reach consensus limit client capabilities; client to move client AP1 registers a reduction in handoff/steering history; request to AP2 the overall network throughput and response to move client to due to the sticky client AP2 (BSS Transition consuming too much airtime Management Client #1 trying Overloaded AP1 received Client MAC address; Each APs’ AP1 andAP2 to join an ASSOC request from client observed client RSSI; each AP’s decide to steer overloaded AP1 load (e.g., 802.11k Channel Load client to when Report); client capabilities; client associate to AP2 underutilized handoff/steering history; request AP2 is also in and response to steer client to range AP2 AP1 is AP1’s number of associated Each of AP1’s client MAC AP1 and AP2 overloaded and clients is over a predetermined address; AP2’s observed client decide to move some clients limit or that its channel load is RSSI - for each client on AP1; clients #1 & #2 (e.g., #1 & #2) over a predetermined value each AP’s load (e.g., 802.11k to AP2 are within range Channel Load Report); client of AP2 capabilities; client handoff/steering history; request and response to move a set of clients to AP2 Roaming QoS AP2 sees QoS client MCS rate Client MAC address; client’s AP1, AP2 and client on AP2 going below some low limit QoS requirement (e.g., 802.11k AP3 decide QoS attempting to Transmit Stream/Category client should join an Measurement Report or TSPEC roam to AP3 overloaded AP1, submitted to AP1); Each AP’s instead of AP1 AP3 has observed client RSSI; each AP’s capacity and is load (e.g., 802. Ik Channel Load in range Report); client capabilities; client handoff/steering history; request and response to move client to AP3 AP3 AP3 observed noise on current Each AP’s or associated clients’, AP1 andAP3 experiencing channel exceeds some limit, or observed Noise Histogram (e.g., decide to each interference on a client on AP3 reports noise 802.11k Noise Histogram change channels channel from on channel above a certain Report) on current and other and AP2 neighbor AP limit possible channels; all current decides to ESS client channel capabilities; remain on the Neighbor report seen by each AP same channel (e.g. 802.11k Neighbor Report); request and response to change channels

(10) FIGS. 1A-1C show systems 100(1)-(3) configured to steer a client 120 between APs 110, 112, 114 through AP coordination.

(11) Systems 100(1)-(3) all include at least APs 110-114, and a client 120. Client 120 communicates with APs 110-114 via

(12) AP coordination is facilitated via the use of client association reports (CARs) 150(1), 150(2). CARs 150 are data reports populated with data collected by and distributed amongst each AP 110-114 such that all APs have the same data or substantially the same data. We say “substantially the same data” because, for example, a first AP may utilize a predictive algorithm to generate predictive data based on the shared data or new data has been generated since the last shared data distribution which will be shared in the next shared data distribution cycle. After distribution of the shared data it may be processed by either a shared algorithm such that consensus is substantially automatically generated through scheduled or periodic execution of that algorithm. Alternatively, consensus is each by cooperative and/or collaborative action by and between two or more of APs 110-114. Such cooperative or collaborative action requires inter AP communication for APs to reach consensus, one such exemplary system and process is described in FIGS. 1-4. Generically described, CARs 150(1), 150(2) include client 120 data, AP 110-114 data, and client-AP data for use in the coordinated client decision making processes described herein. Client data may include but is not limited to SNR of non-associated but probing clients, number of associated clients, associated client MAC address, associated client SNR, and associated client current PHY/MCS rate, client communication capability (e.g., band, channel width, number of spatial streams, MU-MIMO, 802.11 amendments, AP data rates, etc.), client-APs moment vector (spatial and temporal), identification of problematic client (e.g., a sticky client), a Deny MAC Access List, and a list of SSIDs the client may probing (e.g., to provide functionality for steering one or more clients between SSIDs). AP data includes number of clients associated with each AP, AP communication capability (e.g., band, channel width, number of spatial streams, MU-MIMO, 802.11 amendments, and AP data rates), AP specific spatial areas or volumes of problematic communication, and AP backhaul cost relating to throughput and latency. Client-AP data includes optimal and non-optimal protocol or capabilities matches between a client and an AP, and optimal and non-optimal coverage area overlap between a client and an AP. CAR data, which is collected, shared, and processed by the APs 110-114, may be used to at least steer clients between APs or even bands (Client Link Management), and may be used to resolve at least the problems detailed in Table 1, above. APs also handle local Radio Resource Management (RRM), for example channel planning, Tx power, noise, neighbor reports, and 802.11k client reports. APs may also cooperate or coordinate to handle AP discovery, AP configuration (and auto-configuration), security, and act as an interface for upstream monitoring and management.

(13) APs 110-114 may utilize CARs 150 data to control clients, such as client 120. For example, AP may disassociate a client based on processed CARs 150 data to initiate a client steering process. APs 110-114 may also implement and support a Deny MAC Access List to block connection or reconnection attempts by a client or disassociated client to further steer the client. In an embodiment 802.11v BSS Transition Management may also be utilized by APs to transition clients. Other possible protocols utilized by such a system and method include a simple UDP protocol, e.g., a combination of multicast and unicast messages and/or datagrams carried by datagram supporting protocols.

(14) In FIG. 1A, system 100(1) is shown with client 120 in communication with AP 110 via association 160(1), with AP 112 via probe 162(1), and with AP 114 via probe 162(2). CARs 150(1) and 152(2) data is shared amongst APs 110-114, which provides the APs with information (described at least in part above) to determine and coordinate the association of client 120 with an AP that best supports that client. In the instance of system 100(1), FIG. 1A, that AP is AP 110.

(15) In FIG. 1B, system 100(2) shows client 120 has moved away from AP 110 and toward AP 112, which illustratively represents AP 112 may be better situated to support client 120. Illustratively locating client 120 proximate AP 112 symbolically equates a reduced spatial distance with an increase in communication signal strength. One skilled in the art will appreciate that this representation is merely symbolic and may alternatively represent a non-spatial improvement in the communication situation between client 120 and AP 112 as compared to that of client 120 and AP 110 or AP 114. For example, this may represent an improved traffic load distribution by steering client 120 to AP 112, a better technology match between client 120 and AP 112, or something else.

(16) System 100(2) also shows a steering request 152 sent from AP 112 to AP 110 and a steering response 154 sent from AP 110 back to AP 112, which is AP 110's reply to the steering request 152. In an embodiment, steering request 152 was triggered by the change in the wireless environment, e.g., the change in proximity, and therefore the signal strength, of client 120 relative to APs 110-114. Such a change may cause a monitored value to exceed (or alternatively deceed) a threshold value resulting in the initialization of a steering request action, such as that initiate by AP 112. AP 112 may additionally include or transmit separately an updated CAR 150 such that AP 110 (and possibly AP 114) may utilize the same data for decision making.

(17) Steering request 152 is a request by AP 112 to AP 110 for AP 110 to handoff client 120 to AP 120 because AP 112 has determined that it can support client 120 better than AP 110. Upon receipt of steering request 152 AP 110 process the request (and possible the new CAR 150(1) if provided) to determine if AP 110 is in consensus with AP 112. If AP 110 is in consensus with AP 112 it will generate a steering reply 154 which coordinates the handover of client 120. If AP 110 is not in consensus with AP 112 it will generate a steering reply 154 rejects the handover of client 120. Examples in AP 110 may reject steering request 152 is where AP 110 has data not available or shared with AP 112 which informs AP 110 to rejected the request. Such data may include, for example, a history of failed steering attempts or may be AP 110's attempt to avoid client 120 from permanently blacklisting AP 110 in response to AP 110 temporarily blacklist client 120 to assist in steering the client to AP 112. In the example of FIGS. 1A-1C, AP 110 is in consensus with AP 112. System 100(3) of FIG. 1C shows client 120 now associated 160(2) with AP 112 and transmitting probes 162(3) and 162(4) to APs 110 and 114, respectively. System 100(3) also shows new CARs 150(3) and 150(4) shared amongst APs 110-114, which reflects changes to the wireless environment, namely client 120's association with AP 112 and disassociation with AP 110.

(18) FIG. 2 shows a timing diagram 200 for a centrally controlled multi-AP system that includes a rootAP 210 and two APs 212, 214. Timing diagram 200 includes a first client monitoring portion 220 and a second client steering portion 222.

(19) In client monitoring portion APs 212, 214 take AP measurements 230, 231 and generate AP information reports (also called herein “APInfoReports”), similar or the same as CARs 150 of FIG. 1, described above. APInfoReports 232, 233 are then transmitted to rootAP 210 which process the APInfoReports 232, 233 via a root AP CLM process 234. These steps may occur a plurality of times until root AP 210 produces a CLMSteeringNotification 235. CLMSteeringNotification 235 informs AP 214 that root AP 210 has determined to steer an AP 214 associated client to AP 212.

(20) RootAp 210 then transmits a CLMSteeringCommand 236 to AP 212, which directs AP 212 to initiate a steering request process which results in AP 212 transmitting a CLMSteeringResponse 237 to rootAP 210 and an APSteeringRequest 238 to AP 214. CLMSteeringResponse 237 is a response to rootAP 210's CLMSteeringCommand 236. APSteeringRequest 238 is a request made by AP 212 to AP 214 to cooperate to steer an AP 214 associated client to AP 212. AP 214 then optionally responds to the APSteeringRequest 238 by transmitting an APSteeringResponse 239 to AP 212 and steers client 240. In a separate example, AP 214 does not reach consensus with AP 212 (or rootAP 210) and rejects the steering request from AP 212. Rejecting the steering request from AP 212 may be by, for example, ignoring the request or may be by informing one or both of AP 212 and rootAP 210 that it will not disassociate the client.

(21) Returning to the example of FIG. 2, after AP 214 steers client 240, AP 212 associates client 241. AP 212 then provides AP 214 with an APSteeringResult 242. AP 214 then transmits a CLMSteeringResult 243 to rootAP 210 to finalize the process and restart the AP measurement and APInfoReport processes 230-234, as similarly described above.

(22) FIG. 3 shows a timing diagram 300 for exemplary system 100 of FIG. 1, which includes APs 110-114. Timing diagram 300 includes a first client monitoring portion 320 and a second client steering portion 322.

(23) APs 110-114 share AP Information reports APInfoReports 330-335. To simplify FIG. 3 AP measurements are not shown, but it will be understood that system 300 will periodically perform a measurement process, similar to the measurement process that generates AP measurement 230-231 of FIG. 2, of purposes of populating APInfoReport 330-335, 339-344. Each AP 110-114 the compares report with observed clients 336-338. APs 110-114 then again shares AP Information reports via APInfoReports 339-344 (also called CARs, such as CARs 150, herein).

(24) AP 112 then compares the report with observed client-action needed 345. AP 112 the sends a steering request 346 to AP 110. AP 110 process the steering request in the compare request with associated client data—action is needed 347. In the situation where AP 110 arrives at a consensus with AP 112 (as similarly described in FIG. 1, above), the AP 110 transmits a SteeringResponse 348 to AP 112, which is processed resulting in AP 110 Steering Client 349 and AP 112 Associating Client 350. Steering Client 349 may be, for example, AP 110 disassociating the client and entering the client on a Deny MAC Access List (not shown but discussed above) such that the client will not re-associate and will be steer to AP 112, where it associates. AP 112 then optionally sends a steering result 351 to AP 110 to inform AP 110 of the successful association. APs 110-114 then again share AP information Reports via APInfoReports 330-335.

(25) FIG. 4 shows a crowded Multi-AP environment 400 with three APs, APs 410, 412, and 414. Multi-AP environment 400 includes an office 410, a kitchen 420, a living room 430, two bedrooms 440, 450, and an exterior space 460. In living room 430 is Wi-Fi AP 412. In bedroom 450 is Wi-Fi AP 414. In office 410 is a Wi-Fi AP and router 410 (also called herein gateway AP 410 or just AP 410), and a modem 470 (which may also be ONT 470 if implemented in an optical communication environment) connected to data network, such as the internet, a local area network, a DOCSIS network, an optical network, or similar.

(26) Environment 400 is shown with both a wired backhaul 480, between an AP 412 and a gateway AP 410, and a wireless backhaul 490, between an AP 414 and gateway AP 410. In such a multi-AP environment a least-cost routing calculus may be performed to determine the best path for data to travel. One exemplary least cost routing calculus is represented in FIG. 5, below.

(27) Wireless clients within environment 400 have a plurality of connection options. As such APs may utilize a least-cost routing calculus to determine the best direct or indirect connection to gateway AP 410, and subsequently the internet. The least-cost routing calculus takes into consideration the time per gigabit (e.g., [seconds/Gb]) for wired transmission, wireless transmission, and data rate delays associated with internal processing delays. Internal processing delays may include but are not limited to time per gigabit for the transmission from a receiving side to a transmission side within an AP. Other internal delays may also exist, as will be known to one skilled in the art, but are not discussed here for sake of simplicity and brevity.

(28) For example, smart phone 402 in bedroom 440 may connect to one of AP 410, 412, or 414. Connection to AP 414 would require a first wireless transmission from smart phone 402 to AP 414 having a first wireless date rate, and a second wireless transmission via wireless backhaul 490 from AP 414 to gateway AP 410 having a second wireless data rate. There is also an internal delay, as discussed above. Thus, the least-cost routing calculus determines a first path data rate (from smartphone 402 to AP 414 then to gateway AP 410) by summing first wireless date rate, plus the internal delay, plus the second wireless data rate. Other communication paths are also available to the smart phone. One exemplary second communication path is from smartphone 402 straight to gateway AP 410. A third communication path is from smartphone 402 to gate AP 410 via a wireless transmission from smartphone 410 to AP 412 and wired backhaul 480 from AP 412 to gateway AP 410. Through environment 400 measurements, shared CAR data (e.g., CAR 150 and APInfoReport 232-233, 330-335), AP coordination, and the least-cost routing calculus APs 410, 412, 414 may determine that the communication path with the best data through-put is, for example, the third communication path due to great through put on wired backhaul 480.

(29) It will be understood that the above example is simplified and a plurality of variables may be utilized as inputs into the least-cost routing calculus when determining the best communication path. Some non-limiting examples of additional metrics includes inter AP compatibility, latency reduction mechanisms and protocols, technology and functionality matches and mismatches between clients and APs (including between a first AP and a second AP), etc.

(30) FIG. 5 shows one exemplary system 500 with data utilized in one least cost routing calculus. Other data that may be utilized in other least cost routing calculus include but are not limited to maximized throughput, maximized goodput (i.e., application-level throughput), and a guaranteed QoS (e.g, based on at least one or more of a minimum throughput, maximum latency, maximum jitter, etc.).

(31) System 500 includes a client 520, a gateway AP 510, and an extender AP 514. Client 520 is in two-way wireless communication with extender AP 514 via 1.5 Gbps wireless link 504 and gateway AP 510 via 2.5 Gbps wireless link 502. Extender AP 514 is in two-way wireless communication with Gateway AP 510 via 3 Gbps wireless link 506. The time per Gbit cost (hereinafter the “cost”) for 1.5 Gbps wireless link 504 is 0.633 s/Gbit. The cost for 2.5 Gbps wireless link 502 is ˜0.4 s/Gbit. The cost for 3 Gbps wireless link 506 is ˜0.33 s/Gbit. In addition the delay within extender AP 514 is ˜0.001 s/Gbit.

(32) A least cost routing calculus for association by client 520 with gateway AP 510 is therefore ˜0.633 s/Gbit. The least cost routing calculus for association with extender AP 514 is the sum of the costs of 2.5 Gbps wireless link 502, internal delay of extender AP 514, and 3 Gbps wireless link 506, which is 0.4 s/Gbit+0.01 s/Gbit+0.33 s/Gbit=0.74 s/Gbit. Thus, direct association by client 520 with gateway AP 510 results in the best performance for client 520.

(33) Other factors may contribute to the least cost routing calculus, including but not limited to available AP resources, throughput on the links (e.g., number of retries on the link, BER, etc.). The least cost routing calculus may advantageously rely on AP measured and shared data (e.g., CAR 150, APInfoReport 232-233, AP Measurements 230-231, APInfoReport 330-335, 339-344, etc.) and distributed through the system, e.g., system 100, 200 300, 400, and 500.

(34) Changes may be made in the above methods and systems without departing from the scope hereof. It should thus be noted that the matter contained in the above description or shown in the accompanying drawings should be interpreted as illustrative and not in a limiting sense. The following claims are intended to cover all generic and specific features described herein, as well as all statements of the scope of the present method and system, which, as a matter of language, might be said to fall there between.