Patent Application
20240381414
Embodiments presented in this disclosure generally relate to wireless communication networks. More specifically, embodiments disclosed herein relate to resource unit allocation for wireless communication.
In wireless systems with triggered uplink traffic, a wireless access point (AP) can begin a triggered uplink from a wireless station (STA) to the AP by polling the STA to determine how much data is in the STA's buffer. This poll from the AP to the STA is commonly called a Buffer Status Report (BSR) Poll (BSRP). The AP can then calculate how many resource units (RUs) to allocate to the STA and the duration of the next transmission opportunity (TXOP). This is a type of scheduled access (SA) that typically works well in wireless local area networks (WLANs) with a relatively small number of STAs. But there are many cases when this may not work as desired. For example, in a crowded WLAN with many STAs, the AP many not have enough RUs to allocate to the requesting STAs. Furthermore, an STA that urgently needs to send data may not want to wait for the next BSR, and an unsolicited BSR from the STA to the AP may go unanswered.
So that the manner in which the above-recited features of the present disclosure can be understood in detail, a more particular description of the disclosure, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate typical embodiments and are therefore not to be considered limiting; other equally effective embodiments are contemplated.
To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements disclosed in one embodiment may be beneficially used in other embodiments without specific recitation.
Embodiments include a method. The method includes identifying a first allocation of scheduled access (SA) and random access (RA) resource units (RUs) for uplink from one or more wireless stations (STAs) to a wireless access point (AP) in a wireless local area network (WLAN). The method further includes measuring one or more performance characteristics for the one or more STAs. The method further includes determining a second allocation of uplink SA and RA RUs in the WLAN based on the measured one or more performance characteristics. The method further includes advertising the second allocation of uplink SA and RA RUs to the one or more STAs.
Embodiments further include a system, including a processor and a memory having instructions stored thereon which, when executed on the processor, performs operations. The operations include identifying a first allocation of SA and RA RUs for uplink from one or more STAs to an AP in a WLAN. The operations further include measuring one or more performance characteristics for the one or more STAs. The operations further include determining a second allocation of uplink SA and RA RUs in the WLAN based on the measured one or more performance characteristics. The operations further include advertising the second allocation of uplink SA and RA RUs to the one or more STAs.
Embodiments further include a non-transitory computer-readable medium having instructions stored thereon which, when executed by a processor, performs operations. The operations include identifying a first allocation of SA and RA RUs for uplink from one or more STAs to an AP in a WLAN. The operations further include measuring one or more performance characteristics for the one or more STAs. The operations further include determining a second allocation of uplink SA and RA RUs in the WLAN based on the measured one or more performance characteristics. The operations further include advertising the second allocation of uplink SA and RA RUs to the one or more STAs.
As discussed above, in some scenarios (e.g., a WLAN with a large number of STAs or STAs with urgent transmission requirements) SA using a BSRP may not provide suitable results. One alternative is to have STAs attempt to transmit using a Random Access (RA) regime. RA allows STAs to revert to an unscheduled transmit modality. RA can be implemented using a variety of techniques, including explicit triggered allocation (e.g., uplink orthogonal frequency division multiple access (OFDMA) based random access (UORA)), implicit enhanced distributed channel access (EDCA), other implicit RA techniques (e.g. leaving TXOP space between scheduled TXOPs from a stream classification service (SCS)) or any other suitable RA technique. In an embodiment, the AP reserves a set of RUs specifically for the purpose of RA.
Considering that WLANs may support a mix of RA and SA on the same basic service set (BSS), and that performance may vary greatly depending on which media access modality a STA is using (e.g., RA or SA), providing a technique to help STAs choose between SA and RA for uplink would provide significant improvements. For example, on a crowded WLAN, as RU availability is diminished an AP may not have capacity to support a STA according to its service level agreement (SLA) contract (e.g. target wake time (TWT), SCS, traffic specification (TSPEC), and other criteria). In these circumstances, the STA might be better served using RA instead of SA.
For example, while encouraging a move from SA to RA does not necessarily provide more capacity (e.g., RA is generally less airtime efficient and can be inefficient with low aggregation and requisite long aggregation timers), an STA can get earlier access to the channel in RA and hence experience less latency for critical traffic identifiers (TIDs). A preferred solution will not encourage all STAs to jump to RA for all TIDs, but instead control RU allocation to improve performance (e.g., using per-TID wait times to allocate RUs between RA and SA). Controlling how an STA takes advantage of RA is critical in managing SLAs, and can be managed by the way the AP allocates space to SA versus. RA modes on the WLAN.
One or more techniques discussed below allow for prediction of RU allocation (e.g., SA vs RA for RU allocation) to control STA use of SA and RA. For example, performance characteristics can be continuously measured and used to train an ML model (e.g., a reinforcement learning ML model) to predict the RU allocation. A reinforcement learning ML model can quickly converge on a preferred (e.g., optimal) RU allocation based on repeatedly modifying RU allocation and measuring corresponding performance characteristics. This predicted RU allocation can then be advertised to STA and used to improve performance.
Each STA 120A-N can both receive data from the AP 110 (a downlink connection) and transmit data to the AP 110 (an uplink connection). In an embodiment, the AP 110 schedules both downlink communication (from the AP 110 to the respective STAs 120A-N) and uplink communication (from a given one of the STAs 120A-N to the AP 110). Further, in an embodiment, one or more of the 120A-N can communicate with each other (e.g., through the AP 110 or peer-to-peer).
In an embodiment, the AP 110 includes a modality selection service 112 which facilitates selection of an uplink modality (e.g., SA or RA) for uplink communication from the STAs 120A-N. For example, the modality selection service 112 can implement the one or more of the techniques discussed further below in regard to
In an embodiment, the STA 120A includes a modality selection service 122. In an embodiment, the modality selection service 122 manages selection of an uplink modality (e.g., SA or RA) for uplink data transmission from the STA 120A to the AP 110. This is discussed further below in regard to
The network components 220 include the components necessary for the AP 110 to interface with a wireless communication network, as discussed above in relation to
The memory 210 generally includes program code for performing various functions related to use of the AP 110. The program code is generally described as various functional “applications” or “modules” within the memory 210, although alternate implementations may have different functions and/or combinations of functions. Within the memory 210, the modality selection service 112 facilitates selection of an uplink modality (e.g., SA or RA) for uplink communication from STAs to the AP, as discussed further in relation to
The STA 120 includes a processor 252, a memory 260, and network components 270. In an embodiment, the STA 120 corresponds with any of the STAs 120A-N illustrated in
The network components 270 include the components necessary for the STA 120 to interface with a wireless communication network, as discussed above in relation to
The memory 260 generally includes program code for performing various functions related to use of the STA 120. The program code is generally described as various functional “applications” or “modules” within the memory 260, although alternate implementations may have different functions and/or combinations of functions. Within the memory 260, the modality selection service 122 manages selection of an uplink modality (e.g., SA or RA) for uplink data transmission from the STA 120A to the AP 110. This is discussed further below in regard to
In an embodiment, STAs (e.g., one or more of the STAs 120A-N) illustrated in
Alternatively, or in addition, the AP can keep statistics on how much buffer is left over after a triggered UL physical protocol data unit (PPDU) transmission. In an embodiment, the left over buffer represents the difference between the BSR and the amount of data the STA has to send at that point of UL PPDU transmission. For example, the AP can track the left over buffer in a new poll to the STA (e.g., the STA can track leftovers and respond to the poll).
As another example, the network can intermittently do a BSRP right after UL PPDU transmission, to determine statistics on left overs in the buffer. While the techniques discussed in association with block 302 (and subsequent blocks in
At block 304, the modality selection service modifies allocation of RUs to RA. In an embodiment, as the AP evaluates potential oversubscription of SA RU availability, it responds by gradually allocate more RU space to RA (e.g., triggered or un-triggered RA, as discussed above). Allocating more RU space to RA can allow more RU space for STAs to contend for access to the transmission medium, instead of waiting to be served by the next available SA period
At block 306, the modality selection service measures baseline performance characteristics. In an embodiment, there is a performance trade-off between making STAs wait longer for their next scheduled SA TXOP, as opposed to APs taking their chances using RA RUs (e.g., in an EDCA mode). The AP can take a measurement of performance characteristics of various SCS values, TID values, or both, as a baseline, along with overall WLAN throughput and any other suitable performance characteristics.
In an embodiment, this includes a measurement of aggregate throughput of the RA and SA groupings. Alternatively, or in addition, the AP monitors average wait times (e.g., for all TIDs), focusing on the higher priority TIDs. These measurements form the basis of key performance indicators (KPIs) that the AP can use to adjust RU allocation. This is discussed further, below, with regard to block 308.
At block 308, the modality selection service monitors performance and adjusts allocation. This is discussed further, below, with regard to
At block 310, the modality selection service advertises the RU allocation. In an embodiment, as RU oversubscription is encountered (and especially as the AP's ability to service high-priority TIDs changes), the AP will issue a beacon (e.g., an 802.11 beacon) to encourage STAs to take advantage of the expanded SA space. For example, the AP can transmit an information element (IE) to advertise changes to the RA allocation, the SA time left, and any other suitable information. This allows underserved STAs to make a decision whether to wait for the next available TXOP offered by the AP (e.g. restricted TWT (rTWT), SCS setup, renewal or update, or any other suitable TXOP) with a pre-determined allocation (time, bandwidth, or any other suitable allocation), or to take its chances in the expanded RA mode.
In an embodiment, as the AP begins to adjust the size of the SA vs. RA RU allocation space, it continually monitors performance characteristics outlined in the previous step. The goal is to find a suitable performance value (e.g., an optimal performance value) based on a variety of objective functions (e.g. total aggregate throughput, throughput per-TID, or any other suitable criteria). To accomplish this, the modality selection service first identifies the measured performance characteristics and the current resource allocation.
At block 404, the modality selection service uses reinforcement learning to modify an ML model based on performance. In an embodiment, a reward and penalty learning mechanism, such as reinforcement learning, can be used to prepare an ML model to predict a preferred SA vs RA allocation of RUs. As the AP adjusts the SA and RA RU allocation, the modality selection service continually monitors performance based on KPIs of the desired objective function (e.g. total aggregate throughput, throughput per-TID, or any other suitable criteria). When changes to the allocation either improve or degrade KPIs, the ML model is trained with a reward or a penalty, allowing the ML model to quickly converge on a preferred (e.g., optimal) balance of the SA vs RA RU allocation.
For example, if the AP allocates too many RUs to RA mode and it notices that excessive contention has unexpectedly degraded performance, the modality selection service can train the ML model to avoid this allocation based on the model's input values. In a short period of time the ML model will converge to a balance that optimizes performance. This evaluation is in constant re-evaluation as the WLAN dynamics change. Reinforcement learning is merely one example, and any suitable ML model and ML technique can be used (e.g., supervised learning, unsupervised learning, or any other suitable technique).
At block 406, the modality selection service predicts a next RU allocation using the ML model. In an embodiment, the ML model can be provided with the performance characteristics and RU allocation and can predict a next SA vs RA RU allocation. This is discussed further, below, with regard to
As discussed above in relation to
Further, reinforcement learning is merely an example. In an embodiment, reinforcement learning can be a suitable technique because WLAN characteristics vary significantly between implementation, and so training a supervised ML model to predict an RU allocation is likely to be extremely burdensome (e.g., a very large amount of training data and training compute resources could be required) and inaccurate. Reinforcement learning, by contrast and for example, can converge on a preferred allocation quickly based on the particular characteristics of the WLAN implementation at issue.
But reinforcement learning is merely one option, and for some implementations other techniques may be more suitable (e.g., supervised learning, unsupervised learning, semi-supervised learning, or any other technique). Further, using an ML model is not required. The modality prediction service 522 could use rule-based techniques, or any other non-ML model based technique to predict the RU allocation.
In the current disclosure, reference is made to various embodiments. However, the scope of the present disclosure is not limited to specific described embodiments. Instead, any combination of the described features and elements, whether related to different embodiments or not, is contemplated to implement and practice contemplated embodiments. Additionally, when elements of the embodiments are described in the form of “at least one of A and B,” or “at least one of A or B,” it will be understood that embodiments including element A exclusively, including element B exclusively, and including element A and B are each contemplated. Furthermore, although some embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the scope of the present disclosure. Thus, the aspects, features, embodiments and advantages disclosed herein are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Likewise, reference to “the invention” shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).
As will be appreciated by one skilled in the art, the embodiments disclosed herein may be embodied as a system, method or computer program product. Accordingly, embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, embodiments may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for embodiments of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments presented in this disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the block(s) of the flowchart illustrations and/or block diagrams.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other device to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the block(s) of the flowchart illustrations and/or block diagrams.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer, other programmable data processing apparatus, or other device provide processes for implementing the functions/acts specified in the block(s) of the flowchart illustrations and/or block diagrams.
The flowchart illustrations and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, each block in the flowchart illustrations or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
In view of the foregoing, the scope of the present disclosure is determined by the claims that follow.
This application claims benefit of co-pending U.S. provisional patent application Ser. No. 63/501,584 filed May 11, 2023. The aforementioned related patent application is herein incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63501584 | May 2023 | US |
