Patent Description:
Work of the inventors hereof, to the extent the work is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted to be prior art against the present disclosure.

When operating in an infrastructure mode, wireless local area networks (WLANs) typically include an access point (AP) and one or more client stations. These WLANs operate in either a unicast mode or a multicast mode. In the unicast mode, the AP transmits information to one client station at a time. In the multicast mode, the same information is concurrently transmitted to a group of client stations. Development of WLAN standards such as the Institute for Electrical and Electronics Engineers (IEEE) <NUM>. 11a, <NUM>. 11b, <NUM>, and <NUM>. 11n Standards has improved data throughput by allowing transmitting across frequency bandwidth. Thus, a scheduling mechanism is needed to schedule data frames transmitted between the AP and multiple client stations. For example, the AP and/or the client station needs to know which channel a data frame is being transmitted, how much bandwidth out of a channel is allocated to a specific user, and/or the like.

<CIT> relates to generating and subsequently transmitting OFDMA packets of various OFDMA packet structures from one communication device to at least one other communication device. One example of an OFDMA packet includes common SIG for two or more other wireless communication devices modulated across all sub-carriers of the OFDMA packet. The common SIG is then followed by a first SIG and first data for a first other wireless communication device modulated across a first subset of the sub-carriers of the OFDMA packet and is also followed by a second SIG and a second data for a second other wireless communication device modulated across a second subset of the sub-carriers of the OFDMA packet. The novel OFDMA packet structures presented in <CIT> allow for support for a flexible number of OFDMA and MU allocations in downlink (DL) and uplink (UL) packets. Also, efficient signaling allows for a different number of co-scheduled users to be accommodated. Packets that support more users can have a relatively larger SIG, i.e. the number of bits can grow with the number of allocations.

It is the object of the present application to provide an efficient scheduling mechanism to schedule data frames transmitted between an access point and multiple clients.

Further features of the disclosure, its nature and various advantages will become apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:.

This disclosure describes methods and systems for a cross-channel scheduling mechanism for transmitting HE MU frames within an <NUM> wireless network. In some embodiments, a wireless network device such as an access point (AP) of a wireless local area network (WLAN) simultaneously transmits data to multiple client stations and/or receives data simultaneously transmitted by multiple client stations. Such data includes header information that provides the channel scheduling information (e.g., which channels are covered by which data fields, etc.) and resource allocation information (e.g., how bandwidth of a channel is shared among client stations transmitting on the respective channel, etc.). The header information may signal the schedule information in a specific data field such that, upon decoding header information at a receiver, the receiver (e.g., either the AP or a client station) obtains configuration information of the subsequently transmitted payload data.

<FIG> is a block diagram of an example wireless WLAN <NUM> that the cross-channel scheduling for MU frames can be operated within, according to some embodiments described herein. A wireless access point <NUM> (AP) includes a host processor <NUM> that may be configured to process or assist in data operation, such as encoding/decoding, encryption/decryption, and/or the like. A network interface device <NUM> is coupled to the host processor <NUM>, which is configured to interface with an outer network. The network interface device <NUM> includes a medium access control (MAC) processing unit <NUM> and a physical layer (PHY) processing unit <NUM>. The PHY processing unit <NUM> includes a plurality of transceivers <NUM>, and the transceivers <NUM> are coupled to a plurality of antennas <NUM>.

The WLAN <NUM> includes a plurality of client stations 120a-c. Although three client stations 120a-c are illustrated in <FIG>, the WLAN <NUM> can include different numbers (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc.) of client stations 120a-c in various scenarios and embodiments. Each client station, e.g., 120a-c, may have a similar structure as that of an AP <NUM>. For example, the client station 120c can include a host processor <NUM> coupled to a network interface device <NUM>. The network interface device <NUM> includes a MAC processing unit <NUM> and a PHY processing unit <NUM>. The PHY processing unit <NUM> includes a plurality of transceivers <NUM>, and the transceivers <NUM> are coupled to a plurality of antennas <NUM> to receive or transmit data from or to the wireless communication channel.

Two or more of the client stations 120a-c may be configured to receive data, such as an <NUM>. 11ax multi-user (MU) frame <NUM>, that are transmitted simultaneously by the AP <NUM>. Additionally, two or more of the client stations 120a-c can be configured to transmit data to the AP <NUM> such that the AP <NUM> receives the data. For example, different client stations 120a-c may share available bandwidth and/or communication channels to communicate with the AP <NUM>. Thus, the header information of data frames being transmitted (e.g., the MU frame <NUM>) will contain scheduling information (e.g., which channel to use to transmit data to a specific client, etc.), resource allocation information (e.g., how much bandwidth of the channel is allocated to data transmission to a specific client, etc.), and/or the like. The AP <NUM>, or reversely the client station 120c, may thus decode (e.g., via the host processor <NUM> or <NUM>, respectively) a received data packet to retrieve the scheduling/resource allocation information such that the data payload can be received accordingly, e.g., from which channel data from a specific user is expected, etc. In some implementations, transmissions from multiple client stations 120a-c may be scheduled across the frequency bandwidth and/or spatial domain in the <NUM>. 11ax MU frame. An example data structure of the MU frame is illustrated in <FIG>.

<FIG> provides an example block diagram illustrating an example MU frame at <NUM>, according to some embodiments described herein. The MU frame may include a high efficiency (HE) preamble portion containing an HE signal field A (SIGA) and an HE signal field B (HE-SIGB). Specifically, the SIGB is used to signal the resource unit (RU) signaling and physical layer (PHY) configuration for each station. For example, at more than <NUM>, two SIGBs can be constructed and each carries different scheduling information. The two SIGBs, e.g., SIGB-<NUM> and SIGB-<NUM>, can each be transmitted at a frequency of over <NUM>, and may be duplicated over other channels at <NUM>. As shown in <FIG>, the field SIGB-<NUM>201a can include scheduling information for data for stations on channel A (203a), and another field SIGB-<NUM>202a can include scheduling information for data for stations on channel B (203b). The fields SIGB-<NUM> and SIGB-<NUM> can be duplicated (201b and 202b) for scheduling information for data for stations on additional channels, such as channels C and D (203c-d), respectively.

<FIG> provides an example block diagram illustrating exemplary data information carried by two SIGB fields, according to some embodiments described herein. Each SIGB <NUM> or <NUM> may include a not-fully-duplicated common block 303a or 303b, respectively, e.g., the common block 303a or 303b may each carry RU signaling (resource allocation) information for the channels that the respective SIGB covers. For example, if SIGB-<NUM><NUM> covers information for channel A and SIGB-<NUM><NUM> covers information for channel B, common block 303a may carry RU signaling information for channel A (e.g., if there are two client stations on channel A, each may be allocated to <NUM>), and common block 303b may carry RU signaling information for channel B (e.g., if there are two client stations on channel B, one may be allocated <NUM> and the other may be allocated <NUM>, etc.). The user blocks 305a and 305b may carry PHY configuration information for each scheduled station that chooses the respective SIGB to carry its information. Thus, a scheduling mechanism that adopts the two SIGBs needs to provide a SIGB and station mapping scheme that identifies whose information is to be carried in which SIGB.

<FIG> provides an example block diagram illustrating an exemplary SIGB and station mapping scheme for a bandwidth of <NUM>, according to some embodiments described herein. The fields SIGB-<NUM><NUM> and SIGB-<NUM><NUM> may each cover a <NUM> channel, e.g., SIGB-<NUM><NUM> carries scheduling information relating to transmitting data <NUM> for stations on channel A, and SIGB-<NUM><NUM> carries information relating to transmitting data <NUM> for stations on channel B. Each SIGB <NUM> or <NUM> contains a common block <NUM> including resource allocation information for the respective channel the SIGB is transmitted on, e.g., SIGB-<NUM><NUM> includes a common block storing information for channel A, and SIGB-<NUM><NUM> includes a common block storing information for channel B. Each common block <NUM> is followed by the associated user blocks <NUM> that include user data transmitted to/from the multiple stations on the respective channel.

<FIG> provides an example block diagram illustrating an exemplary SIGB and station mapping scheme for data transmission at a bandwidth greater than <NUM>, according to some embodiments described herein. When two SIBGs <NUM> and <NUM> are used, each SIGB may cover a set of channels. For example, each SIGB <NUM> or <NUM> contains a common block <NUM> or <NUM> including RU signaling information for a set of a few channels, and the STAs scheduled on the respective set of channels may have their user blocks <NUM> or <NUM> also in the respective SIGB. In this way, a single SIGB may cover different channels, and thus cross-channel scheduling is realized via the data structure shown in <FIG>. The channel-to-SIGB mapping is flexible, e.g., the SIGB-<NUM><NUM> or SIGB-<NUM><NUM> can be mapped to different channels. The numbers of channels covered by each SIGB <NUM> or <NUM> may not be necessarily the same, e.g., SIGB-<NUM><NUM> may cover two channels, and SIGB-<NUM><NUM> may cover four channels. The channel-SIGB mapping information may be signaled in the SIGA field.

<FIG> provides an example block diagram illustrating an exemplary SIGB and station mapping scheme for data transmission at <NUM>, according to some embodiments described herein. In this example, four channels A, B, C and D of <NUM> can be divided into two sets, e.g., SIGB-<NUM> covers channel set <NUM> = {A, C, D}, and SIGB-<NUM> covers channel set <NUM> = {B}. For example, when there are three users on channel B, and each of channels A, C and D only has one user, the grouping of {A, C, D} and {B} can have a balanced payload for each SIGB. Thus, while on PHY the data for channel D 602d is transmitted following a SIGB-<NUM><NUM> (as SIGB-<NUM> and SIGB-<NUM> fields are transmitted or received alternatively in a sequence), resource allocation information for channel D is carried by SIGB-<NUM><NUM>, and thus the scheduling is cross-channel.

<FIG> provides a logic flow diagram illustrating aspects of cross-channel scheduling mapping and signaling, according to a claimed embodiment. At <NUM>, the AP (e.g., <NUM> in <FIG>) retrieves channel information and user/client information such as the available bandwidth for data transmission (e.g., <NUM>, <NUM>, <NUM>, or more, etc.), the number of available channels (e.g., two <NUM> channels, four <NUM> channels, etc.), the number of clients/stations for data transmission with the AP, client-channel mapping information, and/or the like. At <NUM>, the AP starts SIGBs at a default setting, e.g., each SIGB covers the channel(s) in the same frequency. For example, for a bandwidth of <NUM> with channels A, B, C and D (as shown in <FIG>), SIGB channel set <NUM> = {A,C} and set <NUM> = {B, D}.

At <NUM>, the AP determines , e.g., via the host processor <NUM> in <FIG>, whether the payload for each SIGB is balanced. For example, if each channel A, B, C and D has two client/stations transmitting thereon, the data load for SIGB-<NUM> and SIGB-<NUM> may be similar, and thus the channel-SIGB mapping is considered balanced. In a different example, if channel A has five clients/stations, but each of the channels B, C and D has only one client/station, the SIGB that carries information for the channel set {A,C} may have an unbalanced higher data load compared to the other SIGB that carries information for the channel set {B,D}. Rebalancing of the channel-SIGB mapping is performed.

When the channel-SIGB mapping is balanced at <NUM>, the AP maintains the current channel-SIGB (e.g., the default setting) mapping for data transmission at <NUM>. Otherwise, the AP may re-map the channels to SIGB. For example, for a bandwidth of <NUM>, the number of channels in each channel set covered by each SIGB can be {<NUM>, <NUM>}, {<NUM>, <NUM>}, {<NUM>, <NUM>}. When rebalancing occurs, one channel may be moved from one SIGB to another SIGB, e.g., the channel sets can be moved from {A, C}, {B, D} to {A}, {B, C, D}.

The updated channel-SIGB mapping information is configured in the SIGA bits, at <NUM>. In one implementation, one signaling method can be: <NUM> bits (channel bitmap for two channels in each set) + <NUM> bit (moving from SIGB-<NUM> to SIGB-<NUM> or from SIGB-<NUM> to SIGB-<NUM>) = <NUM> bits in SIGA. Here, any "<NUM>" in the bitmap indicates the corresponding channel to be mapped to another SIGB. For example, "<NUM>" represents that a first channel from the set is to be moved to the other set, and "<NUM>" represents that a second channel from the set is to be moved to the other set. A bitmap "<NUM>" means that the rebalance is off. In the above signaling methods for SIGA, the order of bits can be arbitrary as long as it is pre-defined.

In another implementation, the signaling method with SIGA can be <NUM> bit (which channel to be mapped) + <NUM> bit (moving from SIGB-<NUM> to SIGB-<NUM> or from SIGB-<NUM> to SIGB-<NUM>) + <NUM> bit (cross-channel-scheduling on/off) = <NUM> bits in SIGA. For example, when the default channel-SIGB mapping is SIGB-<NUM> for {A, B}, and SIGB-<NUM> for {C, D}, the <NUM> bits of "<NUM>" in SIGA may indicate that the second bit "<NUM>" represents a move from SIGB-<NUM> to SIGB-<NUM>; the first bit "<NUM>" represents the first channel of the channel set to be moved from; and the third bit "<NUM>" represents that the cross-channel-scheduling is on. Then in this example, "<NUM>" means channel C is moved from set <NUM> to set <NUM> for cross-channel scheduling. In the above signaling methods for SIGA, the order of bits can be arbitrary as long as it is pre-defined.

In another example, for a bandwidth of <NUM> with eight channels (labeled from A to H), the number of channels in channel set <NUM> and set <NUM> covered by each SIGB, respectively, can be {<NUM>, <NUM>}, {<NUM>, <NUM>}, {<NUM>, <NUM>}, {<NUM>, <NUM>}, {<NUM>, <NUM>}, {<NUM>, <NUM>}, {<NUM>, <NUM>}. At <NUM>, at most one channel is moved from one SIGB to another SIGB; thus, the numbers of channels in each channel set may change from the default {<NUM>, <NUM>} to {<NUM>, <NUM>}, {<NUM>, <NUM>} or {<NUM>, <NUM>}. Thus, one example signaling method in SIGA can be <NUM> bit (cross-channeling on/off) + <NUM> bits (which channel of the four channels in each channel set to move) + <NUM> bit (moving from SIGB-<NUM> to SIGB-<NUM> or from SIGB-<NUM> to SIGB-<NUM>) = <NUM> bits in SIGA. Another example signaling method in SIGA can be used when any channel in one SIGB can be moved to another SIGB: <NUM> bits (channel bitmap for four channels in each set) + <NUM> bit (moving from SIGB-<NUM> to SIGB-<NUM> or from SIGB-<NUM> to SIGB-<NUM>) = <NUM> bits.

Alternatively, a codebook or table can be used to list the channel mapping. When there are additional channel sets not covered by moving channels from one SIGB to another based on the original default setting, an additional rebalancing method can be incorporated. For example, options with more than one channel to be moved can be added at <NUM>. Or, options with channel swapping can be added.

For example, for a bandwidth of <NUM> (four channels A, B, C, D), when only one channel can be moved from one SIGB to the other, and the first channel mapped to the one respective SIGB cannot be moved, the codebook/table can be constructed as shown in Table <NUM>:.

When B0B1=<NUM>, a channel swapping occurs to move from "<NUM>" to "<NUM>". "<NUM>" and "<NUM>" shows the scenarios when only one channel is moved from one SIGB to the other SIGB from "<NUM>" (the underlined channel is the channel that has been moved from another SIGB).

If three bits are used for <NUM>, the codebook/table can be constructed as shown in Table <NUM>:.

When three bits are used, all options of channel sets for <NUM> can be included.

In another example, for a bandwidth of <NUM> (eight channels A-H), when only one channel can be moved from one SIGB to the other, and the first channel mapped to the one respective SIGB cannot be moved, the codebook/table can be constructed as shown in Table <NUM>:.

The underlined channels in Table <NUM> are the channels that have been moved from another SIGB.

Other alternative implementations for configuring SIGA bits for channel-SIGB mapping can be used at <NUM>. In some implementations, the channel-SIGB mapping can be designed such that SIGB can cover all the channels. For example, the signaling in SIGA can include a bitmap of N bits, where N denotes the number of channels (e.g., four for <NUM>, and eight for <NUM>). A "<NUM>" in the bitmap in the corresponding channel belongs to one SIGB (e.g., "<NUM>" can be designated to denote SIGB-<NUM>, and "<NUM>" can be designated to denote SIGB-<NUM>; or vice versa), and the "<NUM>" indicates the corresponding channel belongs to the other SIGB. For example, for the four channels A, B, C, D, a four-bit string XXXX can be used in the bitmap, e.g., "<NUM>" represents that channels A and C are carried by SIGB-<NUM> and B and D are carried by SIGB-<NUM>; and "<NUM>" represents channel A, B, C are carried by SIGB-<NUM>, and channel D is carried by SIGB-<NUM>, and/or the like.

Other signaling methods in SIGA at <NUM> can include designating a subfield in SIGA to indicate how many channels are covered by one SIGB. For example, <NUM> bits for <NUM> (eight channels) to indicate how many channels are covered by SIGB-<NUM>, and implicitly the remaining channels are covered by SIGB-<NUM>. In addition, some special values of this subfield can be used to indicate the load balancing is on or off. For example, if the <NUM> bits = <NUM>, no load balancing is used. A channel identification subfield can be added in each SIGB's common block (e.g., common blocks 303a or 303b in <FIG>). The identification subfield can include a K-bit channel index for each channel covered in this SIGB, where K is determined based on the number of channels (e.g., K=<NUM> for <NUM>, eight channels). Or alternatively, an M-bit bitmap to indicate which channel belongs to this SIGB, where M is equivalent to the number of channels for each SIGB at a default setting (e.g., M=<NUM> for <NUM>, M=<NUM> for <NUM>, etc.). In another example, when no identification subfield is used in the SIGA field, the channels in one SIGB can be assigned successively from a predefined order. For example, if three channels are covered by SIGB-<NUM>, then they are channels A-C from the four channels of <NUM>. Or the channels can be alternatively assigned to each SIGB. Once one SIGB is filled (per the number of channels for each SIGB), the rest of the unassigned channels go to the unfilled SIGB. For example, if three channels are covered by SIGB-<NUM>, then channels A, C and E are covered by SIGB-<NUM>, and channels B, D, F, G and H go to SIGB-<NUM>.

At <NUM>, the AP transmits data to the multiple stations on the respective channel based on the SIGA and SIGB information. When the channel condition or client condition changes, e.g., available bandwidth changes or more clients are added for transmission, the AP starts at <NUM> for possible rebalancing of channel-SIGB mapping again.

While this specification contains many specifics, these should not be construed as limitations on the scope of what may be claimed, but, rather, as descriptions of particular implementations of the subject matter. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can, in some cases, be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

While operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve the desirable results. Moreover, the separation of various system components in the aspects described above should not be understood as requiring such separation in all aspects, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Claim 1:
A method for cross-channel scheduling of high efficiency, HE, multi-user, MU, frame transmission, the method comprising:
obtaining (<NUM>) channel information and client station information for data transmission;
configuring (<NUM>) an MU frame containing a data field of a first type and two data fields of a second type to carry scheduling information relating to which channel from one or more channels is to be used for the MU frame transmission, wherein a first data field of the two data fields of the second type covers a first set of channels from the one or more channels, and a second data field of the two data fields of the second type covers a second set of channels from the one or more channels;
determining (<NUM>) that a current scheduling setting of the two data fields of the second type leads to unbalanced payload between the one or more channels;
adjusting (<NUM>) the two data fields of the second type by remapping channels from the first data field to the second data field for a balanced channel mapping;
adjusting (<NUM>) the data field of the first type to reflect the balanced channel mapping by designating a plurality of bits in the data field of the first type to represent a changing pattern from the current scheduling setting; and
transmitting (<NUM>), via the one or more channels, data based on the adjusted data field of the first type and the adjusted two data fields of the second type.