STABLE BALANCING OF MULTI-LINK OPERATION (MLO) USAGE IN CROWDED SPACE

Balancing Multi-link Operation (MLO) usage may be provided. A list of a plurality of Access Points (APs) for each of a plurality of Multi-link Operation (MLO) types indicating availability of each of the plurality of APs may be received. A first request indicating an MLO type associated with the first request is a first MLO type may be received. In response to the first request, a first subset of the list of the plurality of APs that support the MLO type associated with the first request may be sent. A second request indicating that an MLO type associated with the second request is the first MLO type may be received. In response to the second request, a second subset of the list of the plurality of APs that support the MLO type associated with the second request may be sent. The first subset is different from the second subset.

TECHNICAL FIELD

The present disclosure relates generally to stable balancing of Multi-link Operation (MLO) usage in crowded space.

BACKGROUND

In computer networking, a wireless Access Point (AP) is a networking hardware device that allows a Wi-Fi compatible client device to connect to a wired network and to other client devices. The AP usually connects to a router (directly or indirectly via a wired network) as a standalone device, but it can also be an integral component of the router itself. Several APs may also work in coordination, either through direct wired or wireless connections, or through a central system, commonly called a Wireless Local Area Network (WLAN) controller. An AP is differentiated from a hotspot, which is the physical location where Wi-Fi access to a WLAN is available.

Prior to wireless networks, setting up a computer network in a business, home, or school often required running many cables through walls and ceilings in order to deliver network access to all of the network-enabled devices in the building. With the creation of the wireless AP, network users are able to add devices that access the network with few or no cables. An AP connects to a wired network, then provides radio frequency links for other radio devices to reach that wired network. Most APs support the connection of multiple wireless devices. APs are built to support a standard for sending and receiving data using these radio frequencies.

DETAILED DESCRIPTION

Overview

Balancing Multi-link Operation (MLO) usage may be provided. A list of a plurality of Access Points (APs) for each of a plurality of Multi-link Operation (MLO) types indicating availability of each of the plurality of APs may be received. A first request indicating an MLO type associated with the first request is a first MLO type may be received. In response to the first request, a first subset of the list of the plurality of APs that support the MLO type associated with the first request may be sent. A second request indicating that an MLO type associated with the second request is the first MLO type may be received. In response to the second request, a second subset of the list of the plurality of APs that support the MLO type associated with the second request may be sent. The first subset is different from the second subset.

EXAMPLE EMBODIMENTS

Wi-Fi 7 Multi-link Operation (MLO) may enable devices to simultaneously transmit and receive across different bands and channels by establishing two or more links to two or more AP radios. Wi-Fi 7 may seek to enhance these links by increasing throughput, which may be the measurement of data between devices in a local network. MLO may also lower latency (e.g., network server to client device time), and improve reliability.

In the initial version of MLO, the links were established to two radios of a single AP. However, the industry direction may be to establish links to multiple APs, either with a Multi-link Single Radio (MLSR) mode, where one link may be used for Transmit (Tx) and the other for Receive (Rx) or Multi-Link Multi-Radio (MLMR), where each link is used to Tx and Rx.

The choice to form an MLO may be on the client device side, but based on elements obtained from the AP (e.g., load or other performance parameters on the radio, short neighbor report with list of potential other radios, etc.) At any time, the client device may refresh its awareness of the AP environment and conditions to continue its MLO operations, switch to single radio mode, or move any MLO link to other radios.

FIGS.1A,1B,1C, and1Dillustrate pendular roaming of a set of client devices105between APs (e.g., first AP110, second AP115, and third AP120). In large contiguous venues, this design may result in pendular inefficiencies. As shown inFIG.1A, client devices may implement different roaming processes, but they may be based on overlapping sets of metrics (where, for example, the slope of the degradation in Tx/Rx efficiency is associated with a trigger to roam). In this scenario, set of client devices105may query for AP neighboring information, switch one of their links to the best available reported radio (e.g., third AP120) as shown inFIG.1B. This naturally may not happen at once, but over time. Yet, at some point, third AP120may become saturated, causing performance degradation on set of client devices105, and causing all client devices with similar chipset logic to go query again at the same time as shown inFIG.1C. An AP now announced as being the least loaded (e.g., second AP115) receives a burst of associations within a short interval, while set of client devices105flee the overloaded third AP120as shown inFIG.1D. Second AP115soon becomes overloaded. After a short interval, the process repeats in the other direction.

The same phenomenon may be expected in most high-density settings (e.g., classrooms etc.) The issue may be mitigated if each client had a different roaming algorithm and different thresholds (and thus if clients would attempt to find a better link at different times). Client devices may converge to the same types of metrics and thresholds values, where saturation of resources of an AP may cause a wave of client devices to simultaneously attempt to find better APs within a short interval. In the current single-link operation, the issue may be limited by the fact that roaming may comprise a disruptive process, and different chipsets may implement different delays and thresholds (after the initial “better link” discovery phase) before making a jump from one AP to another. However, in the “make-before-break” logic of MLO, where the client device may join another radio without needing to break its current connection, the wave of discoveries may be accompanied with waves of second link setups as described above. Accordingly, embodiments of the disclosure may provide a process that takes the MLO link establishment away from the local level to organize the link establishment at a larger floor level (e.g., a form of Radio Resource Management (RRM) for MLO).

FIG.2shows an operating environment200for providing Multi-link Operation (MLO) usage balancing. As shown inFIG.2, operating environment200may comprise a controller205and a coverage environment210. Coverage environment210may comprise, but is not limited to, a Wireless Local Area Network (WLAN) comprising a plurality of Access Points (APs) that may provide wireless network access (e.g., access to the WLAN) for devices. The plurality of APs may comprise a first AP215, a second AP220, and a third AP225. WhileFIG.2shows three APs, the plurality of APs may comprise any number of APs and is not limited to three. Each of the plurality of APs may be compatible with specification standards such as, but not limited to, the Institute of Electrical and Electronics Engineers (IEEE) 802.11 specification standard for example.

A plurality of client devices230may be deployed in coverage environment210. The plurality of APs may provide wireless network access to plurality of client devices230as the plurality of client devices move within coverage environment210. Coverage environment210may comprise an outdoor or indoor wireless environment for Wi-Fi or any type of wireless protocol or standard.

Plurality of client devices230may comprise a first client device235, a second client device240, a third client device245, a fourth client device250, a fifth client device255, and a sixth client device260. Ones of first plurality of devices230may comprise, but are not limited to, a smart phone, a personal computer, a tablet device, a mobile device, a telephone, a remote control device, a set-top box, a digital video recorder, an Internet-of-Things (IoT) device, a network computer, a router, or other similar microcomputer-based device.

Controller205may comprise a Wireless Local Area Network controller (WLC) and may provision and control coverage environment210(e.g., a WLAN). Controller205may allow plurality of client devices230to join coverage environment210. In some embodiments of the disclosure, controller205may be implemented by a Digital Network Architecture Center (DNAC) controller (i.e., a Software-Defined Network (SDN) controller) that may configure information for coverage environment210in order to provide MLO usage balancing.

The elements described above of operating environment200(e.g., controller205, first AP215, second AP220, third AP225, first client device235, second client device240, third client device245, fourth client device250, fifth client device255, and sixth client device260) may be practiced in hardware and/or in software (including firmware, resident software, micro-code, etc.) or in any other circuits or systems. The elements of operating environment200may be practiced in electrical circuits comprising discrete electronic elements, packaged or integrated electronic chips containing logic gates, a circuit utilizing a microprocessor, or on a single chip containing electronic elements or microprocessors. Furthermore, the elements of operating environment200may also be practiced using other technologies capable of performing logical operations such as, for example, AND, OR, and NOT, including but not limited to, mechanical, optical, fluidic, and quantum technologies. As described in greater detail below with respect toFIG.6, the elements of operating environment200may be practiced in a computing device600.

FIG.3is a flow chart setting forth the general stages involved in a method300consistent with an embodiment of the disclosure for providing MLO usage balancing. Method300may be implemented using one of the plurality of APs as described in more detail above with respect toFIG.2. Ways to implement the stages of method300will be described in greater detail below.

Method300may begin at starting block305and proceed to stage310where one of the plurality of APs (e.g., first AP215) may receive a list of a plurality of APs for each of a plurality of Multi-link Operation (MLO) types indicating availability of each of the plurality of APs. For example, controller205may determine the available radio budget on each AP in the plurality of APs. The radio budget may be used to organize the allocation of resources for MLO client devices (e.g., plurality of client devices230). The MLO client types may comprise Multi-link Single Radio (MLSR), Enhanced MLSR (eMLSR), Non-simultaneous TX and RX Multi-link Multi Radio (NSTR MLMR), and Simultaneous TX and RX (STR) MLMR. MLSR may have one radio and be able to RX and TX over one radio at a time. eMLSR may have one radio and may enhance MLSR with a reduced function radio to choose a best link. NSTR MLMR may have two or more radios and may be able to simultaneously RX and TX over the two or more radios, but under certain constraints (e.g., freq. separation, aligned TX/RX). STR MLMR may be able to simultaneously RX and TX over the two or more radios.

Controller205may evaluate capabilities of the MLO devices that broadly fall into, MLSR, eMLSR, NSTR MLMR and, STR MLMR. MLSR radios may be treated similarly to non-MLO devices. Based on the MLO device type, controller205may calculate potential active links supported by these various MLO device types.

Next, for each AP in the plurality of APs, controller205may determine the availability of radios on neighboring APs. Controller may send to the plurality of APs a sorted list (e.g., top n neighbor APs of a given AP with largest availability to smallest).

From stage310, where one of the plurality of APs (e.g., first AP215) receives the list of the plurality of APs for each of the plurality of MLO types indicating availability of each of the plurality of APs, method300may advance to stage320where one of the plurality of APs (e.g., first AP215) may receive a first request indicating that an MLO type associated with the first request is a first MLO type. For example, first client device235may send a probe request (or any other management frame expecting a reduced or standard neighbor list) to first AP215. This first request (e.g., probe request) my indicate that first client device235is an MLO device and which MLO type it may support.

Once one of the plurality of APs (e.g., first AP215) receives the first request indicating that the MLO type associated with the first request is the first MLO type in stage320, method300may continue to stage330where one of the plurality of APs (e.g., first AP215) may send, in response to the first request, a first subset of the list of the plurality of APs that support the MLO type associated with the first request. For example, first AP215may return to first client device235a first subset of the neighbors that were selected by controller205and reported to first AP215(e.g., the first subset may comprise top neighbor1,3, and5).

After the one of the plurality of APs (e.g., first AP215) sends, in response to the first request, the first subset of the list of the plurality of APs that support the MLO type associated with the first request in stage330, method300may proceed to stage340where the one of the plurality of APs (e.g., first AP215) may receive a second request indicating that an MLO type associated with the second request is the first MLO type. For example, second client device240may send a probe request (or any other management frame expecting a reduced or standard neighbor list) to first AP215. This second request (e.g., probe request) my indicate that second client device240is an MLO device and which MLO type it may support.

From stage340, where the one of the plurality of APs (e.g., first AP215) receives the second request indicating that an MLO type associated with the second request is the first MLO type, method300may advance to stage350where the one of the plurality of APs (e.g., first AP215) may send, in response to the second request, a second subset of the list of the plurality of APs that support the MLO type associated with the second request. The first subset is different from the second subset. For example, first AP215may return to second client device240the second subset of the neighbors that were selected by controller205and reported to first AP215. This second subset may be slightly different from the first subset (e.g., the second subset may comprise top neighbor2,6, and7).

Controller205may run an optimization process intended to distribute the list of neighbors so as to limit the overload on a given AP. This distribution of neighbors list also considers MLO type. The distribution of neighbors list may be biased based on the number of active links from the MLO client devices. Because MLSR and eMLSR only supports Tx/Rx functions over a single radio, they may be less tolerant compared to NSTR MLMR and STR MLMR that may be more lenient towards some amount of Wi-Fi interference or higher channel utilization. Once the one of the plurality of APs (e.g., first AP215) sends, in response to the second request, the second subset of the list of the plurality of APs that support the MLO type associated with the second request in stage350, method300may then end at stage360.

FIG.4is a flow chart setting forth the general stages involved in a method400consistent with an embodiment of the disclosure for providing MLO usage balancing. Method400may be implemented using one of the plurality of APs as described in more detail above with respect toFIG.2. Ways to implement the stages of method400will be described in greater detail below.

Method400may begin at starting block405and proceed to stage410where one of the plurality of APs (e.g., first AP215) may receive a request from a client device (e.g., first client device235) indicating an MLO type associated with the request. For example, first client device235may send a direct probe to first AP215.

From stage410, where the one of the plurality of APs (e.g., first AP215) receives the request from the client device (e.g., first client device235) indicating the Multi-link Operation (MLO) type associated with the request, method400may advance to stage420where the one of the plurality of APs (e.g., first AP215) may determine an availability of an Access Point (AP) and may reserve resources that would be consumed by the client device based on the MLO type. For example, when responding to a direct probe, first AP215may modulate its availability parameters to modulate its availability based on the number of requesting client devices. In one embodiment, first AP215may consider a rolling percentage of its Channel Usage (CU) to be taken by each client device's number of active links. Each of these links may contribute to some amount of TxUtil (Downlink Utilization) and RxUtil (Uplink Utilization). First AP215may indicate in its response its availability (e.g., CU load 22%).

Then, first AP215may compute a probability that first client device235may associate and consume the reserved resources along with its number of supported active links, and temporarily accounts for this potential consumption by locking (i.e., reserving) a potentially consumed percentage of its remaining resources. For example, if an associated MLO client device is STR MLMR, then announcing CU load may be 22+5+5=32% (e.g., assuming 5% per link), however for eMLSR or MLSR, revised CU load may be 27% only for the next probing MLO client as a short term reservation. After a short interval, if the resources are not consumed (i.e., first client device235has not started the association process), first AP215may release the reserved resources back into its availability pool.

Once the one of the plurality of APs (e.g., first AP215) determines the availability of the AP and reserves resources that would be consumed by the client device based on the MLO type in stage420, method400may continue to stage430where the one of the plurality of APs (e.g., first AP215) may respond to the request with the determined availability. For example, first AP215may indicate in its response its availability (e.g., CU load 22%). Once the one of the plurality of APs (e.g., first AP215) responds to the request with the determined availability in stage430, method400may then end at stage440.

FIG.5is a flow chart setting forth the general stages involved in a method500consistent with an embodiment of the disclosure for providing MLO usage balancing. Method500may be implemented using one of plurality of client devices230(e.g., first client device235) as described in more detail above with respect toFIG.2. Ways to implement the stages of method500will be described in greater detail below.

Method500may begin at starting block505and proceed to stage510where one of plurality of client devices230(e.g., first client device235) may receive a list of a plurality of Access Points (APs). For example, controller205may compile the list of the plurality of APs and transmit it to first client device235.

From stage510, where first client device235receives the list of the plurality of APs, method500may advance to stage520where first client device235may choose a subset of the plurality of APs from the list. For example, embodiments of the disclosure my solve a load-balancing problem with multiple load-balancers (e.g., the N radios in a Multi-link Device (MLD)) that may take advantage of a randomized approaches if a local (e.g., client device) solution is sought.

Embodiments of the disclosure may exploit “the-power-of-two-choices” and have client devices choose N random or pseudo-random APs in the list that controller205provides. The choice may be skewed/polarized towards the least loaded APs, or it may be uniform, and it may use a hash algorithm (e.g., on any client identifier such as its Media Access Control (MAC) address). Furthermore, this load balancing process may also associate priority among these MLO client devices by ensuring MLSR and eMLSR stations may be given preferred links with cleaner channels. Load balancing may also consider MLO's historical Service Level Agreement (SLA)/throughput requirements bias selection of the appropriate radios.

Once first client device235chooses the subset of the plurality of APs from the list in stage520, method500may continue to stage530where first client device235may monitor the performance of each AP in the subset of the plurality of APs. For example, first client device235may associates an MLD link to each of the selected APs in the subset and may monitor performances (e.g., the latency of the transmit queues and the time to grab the channel). To achieve this, first client device235may place a background load on all APs in the subset at a partially randomized period. To avoid network synchronization, first client device235may decide when to start its own beat on its own (e.g., pseudo randomly), or based on a trigger by controller205that may be voluntarily offset from the other client devices. The background load may be selected based on Quality-of-Service (QoS) values for example.

After first client device235monitors the performance of each AP in the subset of the plurality of APs in stage530, method500may proceed to stage540where first client device235may determine a best performing AP of the subset of the plurality of APs based on the performance of each AP in the subset of the plurality of APs. For example, second AP220may have the best performance and first client device235may select second AP220.

From stage540, where first client device235determines the best performing AP of the subset of the plurality of APs based on the performance of each AP in the subset of the plurality of APs, method500may advance to stage550where first client device235may associate with the best performing AP. For example, with second AP220having the best performance results, first client device235may place its main load on second AP220. If the least loaded among N random choices is used to measure the load from M number of clients with T active links, then log TMLO_Links/log NAP+O(1) may become the max load on all APs with high probability.

Consistent with embodiments of the disclosure, by randomizing the choice of N elements, biasing all clients to the least loaded AP may be avoided. Then, by choosing the least loaded ones among those N APs, the best decision among the reduced set that was randomly created may be made. It may be unlikely for all clients to choose the same N random APs, hence avoiding the problem. Furthermore, in order to avoid performance starvation of the single radio client devices, eMLSR and MLSR may be allowed first in this sequence. Controller205may still compute sub lists of all the neighbor APs in order to affect client devices to groups of APs. Once first client device235associates with the best performing AP in stage550, method500may then end at stage560.

FIG.6shows computing device600. As shown inFIG.6, computing device600may include a processing unit610and a memory unit615. Memory unit615may include a software module620and a database625. While executing on processing unit610, software module620may perform, for example, processes for providing MLO usage balancing as described above with respect toFIG.3,FIG.4, andFIG.5. Computing device600, for example, may provide an operating environment for controller205, first AP215, second AP220, third AP225, first client device235, second client device240, third client device245, fourth client device250, fifth client device255, and sixth client device260. Controller205, first AP215, second AP220, third AP225, first client device235, second client device240, third client device245, fourth client device250, fifth client device255, and sixth client device260may operate in other environments and are not limited to computing device600.

Computing device600may be implemented using a Wi-Fi access point, a tablet device, a mobile device, a smart phone, a telephone, a remote control device, a set-top box, a digital video recorder, a cable modem, a personal computer, a network computer, a mainframe, a router, a switch, a server cluster, a smart TV-like device, a network storage device, a network relay device, or other similar microcomputer-based device. Computing device600may comprise any computer operating environment, such as hand-held devices, multiprocessor systems, microprocessor-based or programmable sender electronic devices, minicomputers, mainframe computers, and the like. Computing device600may also be practiced in distributed computing environments where tasks are performed by remote processing devices. The aforementioned systems and devices are examples and computing device600may comprise other systems or devices.