Methods and apparatus for communication of multi-AP coordination frames
Patent Information
- Application Number
- PCT/CN2025/132820
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-03-12
- Filing Date
- 2025-11-05
- Publication Date
- 2026-09-03
Smart Images

Figure CN2025132820_03092026_PF_FP_ABST
Abstract
Description
METHODS AND APPARATUS FOR COMMUNICATION OF MULTI-AP COORDINATION FRAMES
[0001] This application claims the priority to U.S. Provisional Application No. 63 / 764,374, filed on February 27, 2025, U.S. Provisional Application No. 63 / 766,235, filed on March 3, 2025, and U.S. Provisional Application No. 63 / 770,801, filed on March 12, 2025, the disclosures of which are incorporated herein, in their entirety, by reference.TECHNICAL FIELD
[0002] The present disclosure relates to the communication technologies, and in particular, to methods and apparatus for communication of multi-AP coordination frames.BACKGROUND
[0003] The Multi-AP Coordination (MAPC) framework is designed to enhance wireless network efficiency through optimized resource sharing and coordination among multiple Access Points (APs) . This framework supports both Transmission Opportunity (TXOP) -based coordination schemes, such as Coordinated Spatial Reuse (Co-SR) , Coordinated Beamforming (Co-BF) , and Coordinated Time Division Multiple Access (Co-TDMA) , as well as Service Period (SP) -based coordination schemes like Coordinated Restricted Target Wake Time (Co-r-TWT) . The 802.11bn Specification Framework Document (SFD) , as outlined in Motion #51, introduces a common framework for Multi-AP Coordination (MAPC) . This framework enables key procedures that are fundamental for MAP operations, including the MAPC Discovery Procedure, which facilitates the identification of potential APs capable of participating in coordinated activities, and the MAPC Agreement Negotiation Procedure, which supports negotiation mechanisms between APs to establish coordination agreements.
[0004] One of the most important coordination schemes defined in the MAPC framework is Coordinated Spatial Reuse (Co-SR) . Co-SR aims to improve spectrum efficiency and capacity by enabling APs to share the same frequency channel simultaneously while minimizing OBSS interference. This is particularly important in high-density environments, where multiple APs and devices may operate within overlapping coverage areas. Co-SR uses techniques such as Transmit Power Control (TPC) to dynamically manage the transmission power of APs to minimize interference and optimize the use of the radio spectrum.
[0005] According to Motion #252, 11bn defines two modes for Co-SR transmission. Mode 1 involves a trigger with the same L-SIG contents, but potentially different U-SIG contents. This mode supports UHR+EHT, EHT+UHR, or EHT+EHT Co-SR transmission, provided no changes are needed for non-UHR EHT non-AP STAs. Mode 2, on the other hand, includes a trigger with the same L-SIG contents and the same U-SIG contents, intended specifically for UHR+UHR Co-SR transmission. For both modes, the two PPDUs will start and end at the same time. The UHR PPDU for Co-SR transmission will be used for either mode when UHR transmission is involved. An indication within the U-SIG field will specify whether the UHR PPDU is intended for Co-SR transmission.
[0006] Coordinated Beamforming (Co-BF) is another key coordination technique that improves the performance of downlink (DL) transmissions. By coordinating the transmission beams of multiple APs, Co-BF can improve signal strength and reduce interference for non-AP STAs (Stations) . In a typical Co-BF setup, the "Sharing AP" and the "Shared AP" synchronize their transmissions to create a coordinated beam, nullifying signals toward each other's served STAs. This strategy mitigates interference and enhances network performance, especially in dense environments.
[0007] 802.11bn has agreed to define the pre-UHR portion of the MU PPDU with Co-BF and Co-SR mode 2 enabled as non-beamformed mode. Both two APs need to send the MU Co-BF DL PPDU with same content in L-SIG, RL-SIG, U-SIG and UHR-SIG.
[0008] The present invention aims to address several technical challenges faced in current wireless communication systems, particularly in the context of multi-AP coordination (MAPC) and trigger frame utilization. These challenges include:
[0009] Current trigger frames, such as Buffer Status Report Poll (BSRP) and Multi-User Request-to-Send (MU-RTS) , suffer from space limitations, which hinder their ability to support the full range of required information for MAPC. The existing formats are insufficient for accommodating essential data for coordinated transmission phases, including Co-BF, Co-SR, Co-TDMA, and Co-OFDMA. This limitation restricts the capacity to exchange critical MAPC information such as invitations, responses, and synchronization frames.
[0010] Existing trigger frame structures fail to optimally utilize the available fields, particularly the Common Info and Special User Info fields, to carry the full spectrum of data necessary for MAPC. This inefficiency results in underutilization of the trigger frame's potential, impacting the overall performance and scalability of multi-AP coordination.
[0011] Current frame formats do not provide the flexibility needed to support the dynamic requirements of advanced MAPC features such as Co-BF and Co-SR. For instance, the ability to include additional control information, U-SIG, UHR-SIG Common, and UHR-SIG User fields within these frames is not straightforward, and any attempt to introduce such features requires significant modifications to the existing structures.
[0012] By addressing these issues, the present invention seeks to provide a more efficient, flexible, and scalable framework for multi-AP coordination, ensuring that the trigger frames can support the necessary information for advanced coordination schemes while maintaining compatibility with existing systems.SUMMARY
[0013] In this disclosure, developers of the present technology propose to reuse existing trigger frame formats, e.g., BSRP or MU-RTS, for Co-BF / Co-SR frame sequences to carry all the essential information for L-SIG, U-SIG, UHR-SIG, UHR-SIG Common, and UHR-SIG User Field along with other necessary control information in Co-BF / Co-SR frame sequences with some minor changes. This includes the Co-BF / Co-SR Invite ICF and Sync. Frames. This can also be applied to other MAPC schemes, e.g., Co-TDMA Invite ICF frame. One of the reserved bits (B61–B62) in the UHR variant Common Info field or one of the reserved bits (B37–B39) in the UHR variant Special User Info field is repurposed to indicate an extended Type subfield or a MAPC Flag subfield. Other extended type Indication values or bits within the UHR variant Common Info or Special User Info field may also be used. Following this, all unnecessary fields in the UHR variant Common Info or Special User Info fields, e.g., B22, B26, B37–B52, B53, B54, and B63 in the UHR variant Common Info field and B17-B38 or B17-B39 in the UHR Variant Special User Info field are repurposed to include a 2–4-bit Type subfield along with Type-specific parameters–43 or 44 bits are made available to carry other necessary information, e.g., additional Control, U-SIG, UHR-SIG Common, and / or UHR-SIG User information.
[0014] By addressing these key points, the present invention provides a more efficient, scalable, and flexible solution for multi-AP coordination in wireless communication systems, ensuring that advanced MAPC features can be supported without disrupting existing operations.
[0015] In a first aspect of the invention, a method is disclosed at an access point (AP) for multi-AP coordination (MAPC) in a wireless local area network, the method comprising transmitting a coordinated beamforming (Co-BF) invite frame, the Co-BF invite frame being a first trigger frame with a first trigger type value, the first trigger frame comprising a set of one, two, or three station IDs of served stations; transmitting a coordinated beamforming (Co-BF) sync frame, the Co-BF sync frame being a second trigger frame with a second trigger type value, the second trigger frame comprising a User Info List comprising one or more UHR Variant User Info Fields, each User Info Field containing a 1-bit flag to assign a station one of two possible BSS colors.
[0016] In some embodiments of the first aspect, each of the first and second trigger frames comprises one and only one special user info field; and a 1-bit subfield indicating that the respective trigger frame is an extended format supporting MAPC or AP-AP communication features.
[0017] In some embodiments of the first aspect, the first and second trigger type values are each equal to 4 or 3 and correspond to a BSRP or a MU-RTS trigger frame format.
[0018] In some embodiments of the first aspect, the first and second trigger type values are each equal to 4 correspond to a BSRP Guard Interval (GI) 3 trigger frame format with the GI and HE / UHR-LTF type sub-field having a value of 3, indicating that a Physical Layer Protocol Data Unit (PPDU) to be received in response to the BSRP is to be in a non-High Throughput (non-HT) format and contain a Multi-station (Multi-STA) Block Acknowledgement (ACK) .
[0019] In some embodiments of the first aspect, the first and second trigger type values are each equal to 4 correspond to a BSRP trigger frame format. The first trigger frame has the GI and HE / UHR-LTF type sub-field in the Common Info field is set to a value of 3, indicating that a Physical Layer Protocol Data Unit (PPDU) to be received in response to the BSRP is to be in a non-High Throughput (non-HT) format and contain a Multi-station (Multi-STA) Block Acknowledgement (ACK) . The second trigger frame has the GI and HE / UHR-LTF type sub-field in the Common Info field is set to any value of 0-2, indicating the value of GI and HE / UHR-LTF type.
[0020] In some embodiments of the first aspect, the response to first trigger frame can be a Multi-station (Multi-STA) Block Acknowledgement (ACK) frame.
[0021] In some embodiments of the first aspect, the first and second trigger type values are greater than 8 and correspond to a dedicated MAPC trigger frame format.
[0022] In some embodiments of the first aspect, each of the first and second trigger frames comprises a two-, three-, or four-bit MAPC Type subfield to signal that the MAPC function being executed is Co-BF.
[0023] In some embodiments of the first aspect, the second trigger frame comprises a Block Ack type bit and resource allocation field for Block Ack.
[0024] In some embodiments of the first aspect, the second trigger frame comprises a 6-bit BSS Color subfield.
[0025] In a second major aspect of the present invention, a method at an access point (AP) is disclosed for multi-AP coordination (MAPC) in a wireless local area network, the method comprising transmitting a coordinated spatial re-use (Co-SR) invite frame, the Co-SR invite frame being a first trigger frame with a first trigger type value, the first trigger frame comprising a 5-bit punctured channel info field; transmitting a coordinated spatial re-use (Co-SR) sync frame, the Co-SR sync frame being a second trigger frame with a second trigger type value, the second trigger frame comprising a 1-bit flag signaling a Co-SR mode, wherein each of the first and second trigger frames comprises one and only one special user info field and a 1-bit subfield indicating that the respective trigger frame is an extended format supporting MAPC or AP-AP communication features.
[0026] In some embodiments of the second aspect, the first and second trigger type values are less than or equal to 8 and correspond to a BSRP or a MU-RTS trigger frame.
[0027] In some embodiments of the second aspect, the first and second trigger type values are each equal to 4 correspond to a BSRP trigger frame format with the GI and HE / UHR-LTF type sub-field having a value of 3, indicating that a Physical Layer Protocol Data Unit (PPDU) to be received in response to the BSRP is to be in a non-High Throughput (non-HT) format and contain a Multi-station (Multi-STA) Block Acknowledgement (ACK) .
[0028] In some embodiments of the second aspect, the first and second trigger type values are each equal to 4 correspond to a BSRP trigger frame format. The first trigger frame has the GI and HE / UHR-LTF type sub-field in the Common Info field is set to a value of 3, indicating that a Physical Layer Protocol Data Unit (PPDU) to be received in response to the BSRP is to be in a non-High Throughput (non-HT) format and contain a Multi-station (Multi-STA) Block Acknowledgement (ACK) . The second trigger frame has the GI and HE / UHR-LTF type sub-field in the Common Info field is set to any value of 0-2, indicating the value of GI and HE / UHR-LTF type.
[0029] In some embodiments of the second aspect, the response to first trigger frame can be a Multi-station (Multi-STA) Block Acknowledgement (ACK) frame.
[0030] In some embodiments of the second aspect, the first and second trigger type values are greater than 8 and correspond to a dedicated MAPC trigger frame type.
[0031] In some embodiments of the second aspect, each of the first and second trigger frames comprises a two-, three-, or four-bit MAPC Type subfield to signal that the MAPC function being executed is Co-SR.
[0032] In some embodiments of the second aspect, the second trigger frame comprises a Block Ack type bit and resource allocation field for Block Ack.
[0033] In some embodiments of the second aspect, the second trigger frame comprises a 6-bit BSS Color subfield.
[0034] In a third major aspect of the invention, a method is disclosed at an access point (AP) for multi-AP coordination (MAPC) in a wireless local area network, the method comprising transmitting a MAPC invite frame, the MAPC invite frame being a first trigger frame with a first trigger type value, the first trigger frame comprising a 5-bit punctured channel info subfield; transmitting a MAPC sync frame, the MAPC sync frame being a second trigger frame with the first trigger type value, the second trigger frame comprising 6-bit BSS color subfield; wherein each of the first and second trigger frames comprises: a Trigger Dependent Common Info field, and a two-, three-, or four-bit MAPC Sub-type subfield to signal a MAPC function of the first and second trigger frames from a set of functions including coordinated beamforming, coordinated spatial re-use, and coordinated time division multiple access; the first trigger type value being selected from a set of values including 8, representing a Ranging Trigger Frame type, and a value greater than 8, representing a dedicated MAPC trigger frame type.
[0035] In embodiments of any of the first to third aspects, an electronic apparatus is configured as a wireless access point with a processor, memory, and instructions for executing any of the aforementioned methods.BRIEF DESCRIPTION OF THE DRAWINGS
[0036] FIG. 1 schematically illustrates a basic service Set (BSS) based multi-AP environment.
[0037] FIG. 2 is a schematic diagram of a device that may perform any or all operations of the above methods and features explicitly or implicitly described herein, according to different embodiments of the present invention.
[0038] FIGs. 3 and 4 together show a matrix of control information and information to be carried in a downlink multi-AP coordination PPDU.
[0039] FIG. 5 is a roster of UHR Variant Common Info and Special User Info fields which can be repurposed to indicate essential information for use in Co-BF / Co-SR.
[0040] FIG. 6A is a map of a previously proposed UHR Variant Common Info and Special User Info Field format with locations identified to carry analogous MAPC information.
[0041] FIGs. 6B and 6C illustrate two different arrangements of UHR Variant Common Info field and Special User Info Field enhanced for carrying Co-BF or Co-SR information according to embodiments of the present invention.
[0042] FIG. 7 shows an allocation of Trigger Type values including a new value for all MAPC trigger frames according to an embodiment of the present invention.
[0043] FIG. 8 shows a UHR Variant Common Info field format associated with the MAPC trigger frame type having trigger dependent common info, according to an embodiment.
[0044] FIG. 9 shows the format of the trigger dependent common info field in the MAPC type trigger frame, according to an embodiment.
[0045] FIG. 10 lists an allocation of Ranging Trigger Subtypes including a new value dedicated to MAPC, according to an embodiment of the present invention.
[0046] FIG. 11 shows the format of the trigger dependent common info field in the MAPC subtype of Ranging-type trigger frame, according to an embodiment.
[0047] FIG. 12 is a roster of new control and preamble info which the present invention is designed to carry in a Co-BF Sync Frame, according to embodiments.
[0048] FIGs. 13A to 13C show three different arrangements of UHR Variant Common Info field and Special User Info Field (s) of a Co-BF Sync Frame according to embodiments of the present invention.
[0049] FIG. 14 lists new information the present invention is designed to carry in each User Info Record in the Co-BF Sync Trigger Frame User Info List, according to an embodiment.
[0050] FIGs. 15A and 15B are Co-BF Sync Trigger Frame User Info Record formats with different means of indicating the BSS Color according to embodiments of the present invention.
[0051] FIG. 16 lists new information the present invention is designed to carry in the Co-BF Invite frame according to an embodiment.
[0052] FIGs. 17A to 17C show three arrangements of UHR Variant Common Info field and Special User Info Field (s) of a Co-BF Invite Frame according to embodiments of the present invention.
[0053] FIG. 18 lists new information the present invention is designed to carry in the Co-SR Invite frame according to an embodiment.
[0054] FIGs. 19A to 19C show three different arrangements of UHR Variant Common Info field and Special User Info Field (s) of a Co-SR Invite Frame according to embodiments of the present invention.
[0055] FIG. 20 lists new information the present invention is designed to carry in the Co-SR Sync frame, according to embodiments.
[0056] FIGs. 21A to 21C shows various arrangements of UHR Variant Common Info field and Special User Info Field (s) of a Co-SR Sync Frame according to embodiments of the present invention.
[0057] FIGs. 22A and 22B list Co-BF Acceptance related subfields with the accept or decline bit explicit, or incorporated into MAPC type, respectively.
[0058] FIGs. 23A and 23B list Co-BF Decline related subfields with the accept or decline bit explicit, or incorporated into MAPC type, respectively.
[0059] FIG. 24 lists the interpretation of the values of the Co-BF Decline Info subfield.
[0060] FIGs. 25A and 25B list Co-SR Acceptance related subfields with the accept or decline bit explicit, or incorporated into MAPC type, respectively.
[0061] FIGs. 26A and 26B list Co-SR Decline related subfields with the accept or decline bit explicit, or incorporated into MAPC type, respectively.
[0062] FIG. 27 lists the interpretation of the values of the Co-SR Decline Info subfield.
[0063] FIG. 28 is a table of interpretation of ACK Type and TID subfields in a Multi-STA BA type ICR frame.
[0064] FIG. 29 is a table of interpretation of the 4-bit Type field placed into space taken from the Starting Sequence Number sub-field.
[0065] FIGs. 30A and 30B show versions of the encoding of the Sub-type field in Starting Sequence Control wherein the 1-bit Accept or Decline indicator is explicit, or incorporated into Sub-type, respectively.
[0066] FIG. 31 is an encoding table of the 4-bit Type field inside Starting Sequence Number, which differentiates between various MAPC schemes.
[0067] FIG. 32 illustrates a possible format for the Per MAPC’s response AID TID Info field within the Multi-STA BA ICR frame.DETAILED DESCRIPTION
[0068] In a wireless local area network (WLAN) system, a basic service set (BSS) serves as a fundamental organizational unit for wireless access. For example, a BSS may include an access point (AP) and one or more associated stations (STAs) . FIG. 1 schematically illustrates a BSS based multi-AP environment. In FIG. 1, multiple APs (e.g., an AP 30A, an AP 30B, and an AP 30C) and multiple STAs (e.g., a STA 10A, a STA 10B, and a STA 10C) are present. For example, a BSS 20A includes: the AP 30A, the STA 10A, the STA 10B, and the STA 10C. A BSS 20B includes: the AP 30B, the STA 10B and other STAs. A BSS 20C includes: the AP 30C, the STA 10C and other STAs. Although FIG. 1 illustrates a possible BSS based multi-AP environment, it is not meant to be restrictive, and a number of devices in FIG. 1 is not limited thereto.
[0069] In this case, multiple APs may jointly participate in coordinated transmission or reception operations, such as Co-BF and Co-SR. To enable such cooperation, efficient signaling mechanisms are required to exchange necessary coordination information among the APs. One aspect of such mechanisms lies in the design of a trigger frame, which serves as the control frame to initiate and manage the coordinated transmission procedures among multiple APs.
[0070] Designing an optimum trigger frame for MAPC / Co-BF / Co-SR involves determining what is the minimum information set that must be transmitted by the trigger frame in order for the shared AP to be able to generate a complete DL MAPC PPDU. This information is enumerated in FIGs. 3 and 4. A Y for Yes in the rightmost matrix indicates that such information is necessary to include in an ICF / Invite frame, an ICR / Response frame, or a Trigger / Sync frame, for the respective cases of Co-BF and Co-SR. The “to be added or exist” column shows whether the information requires a new space allocation or names an analogous field where similar information is already carried in a BSRP or MU-RTS trigger frame. Table rows which lack any Y values are information which is not required of a MAPC frame and therefore will not be added to the format, and any space they currently take up in a legacy trigger frame format can be repurposed.
[0071] In an embodiment, the BSRP or MU-RTS trigger frame is used as the container and framework for the Co-BF / Co-SR Invite (ICF) and Sync (Trigger) frames to accommodate all their required information indicated in FIGs. 3 and 4. In another embodiment, a new top-level trigger frame type for MAPC may also proposed by utilizing one of the reserved values of the trigger type (e.g., 9-15) subfield in the UHR-Variant Common Info of the trigger frame. Regardless of the selected trigger type, several subfields within the UHR Variant Common Info and Special User Info fields can be repurposed to indicate the essential information for inclusion in Co-BF / Co-SR sequences, as shown in FIG. 5.
[0072] FIG. 5, which in most respects corresponds to the “exist” rows in FIGs. 3 and 4, lists pieces of information which have either already been carried in pre-existing trigger frame formats, or are analogous to and use the same storage space as similar pieces of information from pre-existing trigger frame formats. The Control or Preamble column indicates whether the information is MAPC control information only, or whether it is to be passed into a SIG field of the preamble of the DL Co-BF / Co-SR PPDU generated by the Sharing and Shared APs, as is known for trigger frames that provide such preamble information for solicited UL MU PPDUs.
[0073] FIG. 6A is related to FIG. 5 in that it lists the analogous existing locations of some required information for the Co-SR / Co-BF trigger and / or invite frames according to their bit positions in already-proposed UHR Variant Common Info and Special User Info Fields. Such existing analogous subfields are denoted in bold type.
[0074] Other additional Control, U-SIG, UHR-SIG Common, and / or UHR-SIG User information can be conveyed also within the UHR variant Common Info and Special User Info fields. One of the UHR reserved bits (B61–B62) in the UHR-Variant Common Info field or one of the reserved bits (B37–B39) in the UHR-Variant Special User Info field with AID = 2007 can be repurposed to indicate an extended Type subfield (e.g., extended BSRP, extended MU-RTS, ..., etc. ) or MAPC support subfield or AP-to-AP communications support subfield. This single-bit flag, a 1-bit subfield indicating that the respective trigger frame is an extended format supporting MAPC or AP-AP communication features, serves as a signal to the receiver to interpret certain fields differently, as they will not contain expected info for BSRP or MU-RTS.
[0075] Other reserved subfields or unnecessary subfields for the MAPC process within UHR-Variant Common Info field or the UHR-Variant Special User Info field may also be repurposed to indicate an extended Type subfield or MAPC support subfield or AP-to-AP communications support subfield.
[0076] In a preferred embodiment, B39 in the Special User Info field with AID = 2007 indicates an extended Type subfield or MAPC support subfield or AP-to-AP communications support subfield. For instance, if B39 = 1 in the UHR-Variant Special User Info field, B22, B26, B37–B54, and B63 in the UHR Variant Common Info field and B17-B38 in the UHR Variant Special User Info field are repurposed to include a 2–4-bit Type subfield along with Type-specific parameters.
[0077] As a result, 43 bits are made available to carry other additional Control, U-SIG, and UHR-SIG Common information, and / or UHR-SIG User Field Info. FIG. 6B is another representation of the UHR Variant Common Info field and Special User Info Field enhanced for carrying Co-BF or Co-SR information according to embodiments of the present invention.
[0078] Alternatively, if B62 = 0 in the UHR-Variant Common Info field, B22, B26, B37–B54, and B63 in the UHR Variant Common Info field and B17-B39 in the UHR Variant Special User Info field are repurposed to include a 2–4-bit Type subfield along with Type-specific parameters. As a result, 44 bits are made available to carry other additional Control, U-SIG, and UHR-SIG Common information, and / or UHR-SIG User Field Info. This alternate embodiment is pictured in FIG. 6C, the main difference being the location of the single-bit flag indicating the extended format for supporting MAPC and AP to AP communications.
[0079] It is also conceived by the developers to repurpose B56-B59 and B60 (5 bits) in the UHR-Variant Common Info field to carry additional Type-Specific parameters in cases where the trigger frame is addressed only to the Shared AP, rather than both non-AP STAs and the Shared AP. This would free up more space to accommodate future or TBD parameters that may need to be added. Such cases where the trigger frame is addressed only to the Shared AP may include when non-AP STAs do not require Block Ack scheduling information, that information being sent instead in MU-BAR trigger frames to poll stations for BA after they receive the DL PPDU.
[0080] The 2 to 4 bit MAPC Frame Type field in bits B37-B39 of UHR Variant Common Info will now be discussed. With the fact that the frame is a novel multi-AP coordination frame established either by the extended format 1-bit flag in a MU-RTS or BSRP trigger frame, or a new global Trigger Frame type of value 9 or greater, dedicated to MAPC, there are several subtypes of MAPC frame which may be differentiated. The encoding of the MAPC Frame Type field is given in Table 1: Table 1: MAPC Frame Type Encoding
[0081] The location of the 2 to 4 bit MAPC Frame Type field may changed to any other location within the UHR variant Common Info or UHR variant Special User Info field.
[0082] Based on the selected MAPC Frame type, it is possible to utilize one or more of B22, B26, B37–B54, B56-B59, and B63 in the UHR Variant Common Info field and B17-B38 or B39 in the UHR Variant Special User Info field to include Type-specific parameters. The size of the MAPC Frame Type subfield may be extended to 4 bits should the need arise for more than 8 MAPC frame types.
[0083] In the event that repurposing the UL Spatial Reuse subfield (16 bits) for other MAPC functions may lead to compatibility issues with legacy HE devices (due to future engineering changes) , the developers recommend to keep B37-B52 in the Common Info field unchanged.
[0084] In one of the embodiments, an additional Special User Info field (with Special AID > 2007 or Shared AP AID) may be required to accommodate other necessary parameters for MAPC (e.g., Co-BF / Co-SR) Invite or Sync. frames. The format of this additional Special User Info field for MAPC is as follows:
[0085] The 4 bit MAPC Frame Type field in bits B12-B15 (also can be located in the Common Info or Special User Info field with AID = 2007) of MAPC additional Special User Info field will now be discussed. With the fact that the frame is a novel multi-AP coordination frame established either by the extended format 1-bit flag in a MU-RTS or BSRP trigger frame, there are several subtypes of MAPC frame which may be differentiated. The encoding of the MAPC Frame Type field is given in Table 2: Table 2: MAPC Type Encoding
[0086] As has been stated earlier in the application, alternatively to providing an extended format for the BSRP or MU-RTS trigger frame, a new main Trigger Type of trigger frame can be defined by using a reserved value of Trigger Type (indicated in B0-B3 of Common Info) from those listed in FIG. 7. Values 0 to 8 are already allocated, and in a preferred embodiment value 9 may be used to denote trigger frames dedicated to Multi-AP Coordination. In this embodiment, sub-types of MAPC frames may still be defined by the 3 or 4 bit MAPC type field.
[0087] In contrast to a MAPC frame format reusing MU-RTS or BSRP trigger frame, which lack Trigger Dependent Common Info fields, a newly defined MAPC trigger frame type does have Trigger Dependent Common Info, in an embodiment of the present invention. The UHR Variant Common Info field would thus be formatted as in FIG. 8 with a custom-length field beyond B64 for containing MAPC-related control info. It will be appreciated that the format of FIG. 8 does not have the MAPC subtype in the main body of Common Info because it can now be moved into the Trigger Dependent Common Info, a possible format of which is illustrated in FIG. 9.
[0088] The MAPC Trigger Subtype subfield value in the Trigger Dependent Common Info field of the MAPC Trigger frame, values of which are enumerated in Table 3, signals the MAPC Trigger frame subvariants, which can be one of the following frame types: Co-BF Invite ICF, Co-BF Sync. Co-BF Sounding, Co-SR Invite, Co-SR Sync., other subvariants for other MAPC schemes. Table 3: MAPC Trigger Frame Subtypes, 4-bit
[0089] A third embodiment of the MAPC general trigger frame definition is the repurpose of a subtype of the Ranging trigger frame, which has ranging and sensing variants, to have a MAPC variant as well. FIG. 10 lists the as-yet allocated variants and type values of the Ranging trigger frame. In a preferred embodiment, Ranging type 5 is allocated to define a new variant as the MAPC variant. Similar to allocating a new global Trigger Frame type, but actually using type 8 (Ranging) , the MAPC trigger frame would have access to the Ranging trigger frame’s defined amount of Trigger Dependent Common Info, which is allocated as in FIG. 11. The first four bits signal the Ranging subtype as MAPC, and the second four bits, using definition from Table 3, signal the MAPC frame subtype.
[0090] For embodiments 2 and 3, which have trigger dependent common info, The User Info field format of the MAPC Trigger frame will follow the UHR-Variant User Info field for the Basic trigger frame, except for Co-BF Sync. Trigger frame which will be formatted as in FIG. 15A or 15B, as discussed later in the disclosure.
[0091] General formats for the family of MAPC-related trigger frames have been described in terms of what trigger frame types they may comprise and what kinds of indicators may be used to show that they are repurposed or that they are new dedicated frames, and that they may belong to a specific MAPC frame type. Attention will now be given to specific designs of Co-BF Sync Trigger frames, Co-BF Invite frames, Co-SR Invite frames, and Co-SR Sync Trigger frames, with explicit description of their type specific info, according to embodiments of the invention.
[0092] FIG. 12 lists Additional control, U-SIG, UHR-SIG Common info to be included in the Co-BF Sync. Trigger Frame. MAPC Frame Type is for differentiating between MAPC functions as listed in Tables 1 and 2. BA type signals a trigger-based or sequential block acknowledgement. RU Allocation indicates RU usage of STAs if the block ack type is trigger based. A PS160 bit is also required for block ack to indicate a primary or secondary 160MHz of a 320MHz PPDU. Information to be copied into U-SIG and UHR-SIG of the DL PPDU including BSS Color, TXOP duration, channel puncture info, UHR-SIG symbol number, and number of Co-BF users follows. Altogether, 40 bits of new information is desired to be incorporated into a Co-BF Sync Frame.
[0093] Some of the information in FIG. 12 may not be necessary or could be sufficiently conveyed in the Co-BF Invite, such as Punctured Channel Info, Number of UHR-SIG Symbols, and Number of Co-BF users. In such cases, the sharing AP could replace one of these fields with an indication for Data Symbols (5 bits) , which might be required (but not necessary) if the BA Type is Trigger-based ACK or BA.
[0094] If B39 = 1 in the Special User Info field is repurposed to indicate “Extended Type (e.g., MAPC) ” , the additional Control, U-SIG, UHR-SIG Common for the Co-BF Sync. Trigger frame can be conveyed within B22, B26, B37–B54, and B63 in the UHR variant Common Info and B25-B38 in the Special User Info fields. B56-B59 and B60 in the UHR Variant Common Info field can also be optionally repurposed (if needed) .
[0095] If B62 = 0 in the Common Info field is repurposed to indicate “Extended Type (e.g., MAPC) ” , the additional Control, U-SIG, UHR-SIG Common for the Co-BF Sync. Trigger frame can be conveyed within B22, B26, B37–B54, and B63 in the UHR variant Common Info and B25-B39 in the Special User Info fields. B56-B59 and B60 in the UHR Variant Common Info field can also be optionally repurposed (if needed) .
[0096] It will be appreciated that only one Special User Info field is required in this embodiment of the invention. This lowers complexity relative to other proposals for MAPC trigger frames comprising a second Special User Info Field.
[0097] FIG. 13A demonstrates one possible arrangement of the UHR Variant Common Info Field and Special User Info field for the Co-BF Sync Frame that according to embodiments provide the at least 40 bits of repurposed space for the information of FIG. 12. The location of the additional Control, U-SIG, UHR-SIG Common for the Co-BF Sync. Trigger frame conveyed within the above UHR Variant Common Info and Special User Info fields may be changed.
[0098] In some embodiments, the Co-BF / Co-SR Sync. trigger type value is set to 4 corresponding to a BSRP trigger frame format with the GI and HE / UHR-LTF type sub-field having a value of 3. In this case the value of the GI and HE / UHR_LTF type to be included in the U-SIG of the subsequent downlink transmission can be included as one (e.g., GI and HE / UHR_LTF type (2 bits) ) of the fields to be added within the MAPC-Type specific related Info.
[0099] In one of the embodiments, an extended Special User Info field (with Special AID > 2007 or Shared AP AID) may be required to accommodate other necessary parameters for Co-BF Sync. frame. FIG. 13B demonstrates one possible arrangement of the UHR Variant Common Info Field, Special User Info field, and the additional Special User Info field dedicated for the Co-BF Sync Frame that according to embodiments provide the at least 40 bits of repurposed space for the information of FIG. 12. The location of the additional Control, U-SIG, UHR-SIG Common for the Co-BF Sync. Trigger frame conveyed within the above UHR Variant Common Info, Special User Info, additional Special User Info field fields may be changed.
[0100] Alternatively, the Co-BF Sync Frame may be implemented according to an embodiment as a new dedicated Trigger Type, a value between 9 and 15, for all MAPC trigger frames, with a MAPC subtype field indicating that the MAPC trigger frame is a Co-BF Sync Frame. The new dedicated trigger type allows Trigger dependent common Info, and within the MAPC Trigger Dependent Common Info field, the value of the MAPC Sub-type variant is set to indicate Co-BF Sync. Trigger frame, then the frame can accommodate all Additional control, U-SIG, UHR-SIG Common info in the MAPC Subtype Specific parameter field. FIG. 13C demonstrates one possible arrangement of the UHR Variant Common Info Field, Special User Info field, and the Trigger Dependent Common Info field for the Co-BF Sync Frame.
[0101] A third embodiment of the Co-BF Sync Frame involves repurpose of one of the reserved values of the Ranging trigger frame variants for MAPC trigger frame, e.g., 5. Within the Ranging Trigger Dependent Common Info field, the Ranging Trigger Sub-type can be set to MAPC , the value of the MAPC Sub-type variant can be set to indicate Co-BF Sync. Trigger frame, then the Sync frame can accommodate all Additional control, U-SIG, UHR-SIG Common info in the MAPC Subtype Specific parameter field.
[0102] The Co-BF Sync / Trigger Frame of the present invention also has a UHR Variant User Info Field for conveying UHR-SIG user information listed in FIG. 14. The number of UHR variant User Info fields within the User Info List may indicate the number of Co-BF (non-OFDMA) users per BSS. Regarding the 1-bit flag of BSS Color indication, this serves as a pointer to either the 6-bit BSS color of the Shared AP, or of the Sharing AP, rather than carrying the full BSS color in 6 more bits. FIGs. 15A and 15B illustrate two embodiments of the UHR Variant User Info field for the Co-BF Sync Frame and demonstrate that this 1 bit may be located as the MSB of the AID12 or as a repurpose of B20 UL FEC Coding Type.
[0103] Other information, such as RU Allocation, UL Target Receive Power, and PS160, within the UHR variant User Info field, may be required for other purposes, such as BA scheduling (e.g., indicating the number of Data Symbols for TB-ACK / ACK) .
[0104] The second subtype of MAPC trigger frame to be discussed, according to embodiments of the invention, is the Co-BF Invite ICF Frame. Additional control, U-SIG, UHR-SIG Common, and UHR-SIG User Field info to be included in the Co-BF Invite ICF Frame are included in FIG. 16. As in the Co-BF Sync frame, the MAPC frame type is specified in a Type field of 2, 3, or 4 bits. The Sync Reference / Follower bit is for assigning the role of providing carrier frequency reference for the carrier frequency offset (CFO) correction. A bit is designated for declaring the presence of eMLSR or DPS stations in the MAPC to indicate whether there is a need to check the availability of non-AP STAs to be served before starting the actual DL transmission. Punctured channel info may be carried in the Invite ICF frame if there is insufficient room for it in a Sync frame according to embodiments. UHR-SIG info is supplied such as number of users in a BSS and the STA IDs and spatial stream counts for served stations. Altogether, 49 bits of new Co-BF information may be desired to carry in a Co-BF ICF / Invite frame, according to embodiments of the present invention.
[0105] If B39 = 1 in the Special User Info field is repurposed to indicate “Extended Type (e.g., MAPC) ” , the additional Control, U-SIG, UHR-SIG Common, and UHR-SIG User Field for the Co-BF Invite ICF frame can be conveyed within B22, B26, B37–B54, and B63 in the UHR variant Common Info and B25-B38 in the Special User Info fields. B56-B59 and B60 in the UHR Variant Common Info field can also be optionally repurposed (if needed) .
[0106] if B62 = 0 in the Common Info field is repurposed to indicate “Extended Type (e.g., MAPC) ” , the additional Control, U-SIG, UHR-SIG Common for the Co-BF Invite ICF frame can be conveyed within B22, B26, B37–B54, and B63 in the UHR variant Common Info and B25-B39 in the Special User Info fields. B56-B59 and B60 in the UHR Variant Common Info field can also be optionally repurposed (if needed) .
[0107] It will be appreciated that, advantageously, no additional special user info fields are needed beyond the first one, and no UHR-variant User Info Fields are required in this format. An arrangement of the UHR Variant Common Info Field and single Special User Info Field is presented in FIG. 17A. If it is required to add the Punctured channel Info to the format of FIG. 17A, B56-B59 and B60 in the UHR Variant Common Info field may be repurposed for this function.
[0108] The location of the additional Control, U-SIG, UHR-SIG Common, and UHR-SIG User Field for the Co-BF Invite ICF frame conveyed within the above UHR Variant Common Info and Special User Info fields may be changed.
[0109] In some embodiments, the Co-BF / Co-SR invite ICF trigger type value is set to 4 correspond to a BSRP trigger frame format with the GI and HE / UHR-LTF type sub-field having a value of 3. In this case the value of the GI and HE / UHR_LTF type to be included in the U-SIG of the subsequent downlink transmission can be included as one (e.g., GI and HE / UHR_LTF type (2 bits) ) of the fields to be added within the MAPC-Type specific related Info.
[0110] In one of the embodiments, an additional Special User Info field (with Special AID > 2007 or Shared AP AID) may be required to accommodate other necessary parameters for Co-BF Invite ICF frame. FIG. 17B demonstrates one possible arrangement of the UHR Variant Common Info Field, Special User Info field, and the additional Special User Info field dedicated for the Co-BF Invite ICF Frame that according to embodiments provide the at least 49 bits of repurposed space for the information of FIG. 16. The location of the additional Control, U-SIG, UHR-SIG Common, and UHR-SIG User Field for the Co-BF Invite ICF frame conveyed within the above UHR Variant Common Info, Special User Info, additional Special User Info field fields may be changed.
[0111] As discussed above for the Co-BF Sync frame, the Co-BF Invite / ICF frame can also be defined by allocating a new Trigger Frame type with Trigger Dependent Common Info, and store all additional Control, U-SIG, UHR-SIG Common, and UHR-SIG User Field for the Co-BF Invite ICF frame in the MAPC Subtype Specific parameter field. FIG. 17C demonstrates one possible arrangement of the UHR Variant Common Info Field, Special User Info field, and the Trigger Dependent Common Info field for the Co-BF Invite ICF Frame.
[0112] Also as discussed above for the Co-BF Sync frame, a reserved value of the Ranging trigger frame variants can be allocated for MAPC trigger frame, e.g., 5. Within the Ranging Trigger Dependent Common Info field, Sharing AP can set Ranging Trigger Sub-type to MAPC , the value of the MAPC Sub-type variant to indicate Co-BF Invite ICF frame, then all additional Control, U-SIG, UHR-SIG Common, and UHR-SIG User Field for the Co-BF Invite ICF frame can be accommodated in the MAPC Subtype Specific parameter field.
[0113] The third type of MAPC trigger frame to be disclosed according to embodiments of the present invention is the Co-SR Invite / ICF Frame. It is desired to incorporate in this frame all of the information described in FIG. 18. As in all of the other MAPC frame types, there is a 2, 3, or 4-bit type field to differentiate MAPC frame functions from one another. There are two possible Co-SR modes, distinguished by the Co-SR mode bit. The Sharing AP announces its transmit power and Shared AP’s transmit power limit in a Co-SR invite and also announces whether there are eMLSR / DPS stations invited to the coordinated spatial reuse session to indicate whether there is a need to check the availability of non-AP STAs to be served before starting the actual DL transmission. The three-bit PHY identifier is used, as it is in UHR trigger frames, to solicit a particular PHY version of DL PPDU from the Shared AP. The U-SIG punctured channel is also desired to be carried in the Co-SR Invite / ICF frame. Altogether, 20 bits are desired to be carried in a Co-SR Invite ICF Frame according to embodiments of the present invention. Some of the information mentioned above may not be necessary or could be sufficiently conveyed in the Co-SR Sync. Trigger Frame, such as Punctured Channel Info, in alternate embodiments.
[0114] If B39 = 1 in the Special User Info field is repurposed to indicate “Extended Type (e.g., MAPC) ” , the additional Control, U-SIG, UHR-SIG Common, and UHR-SIG User Field for the Co-SR Invite ICF frame can be conveyed within B22, B26, B37–B54, and B63 in the UHR variant Common Info and B25-B38 in the Special User Info fields. B56-B59 and B60 in the UHR Variant Common Info field can also be optionally repurposed (if needed) .
[0115] If B62 = 0 in the Common Info field is repurposed to indicate “Extended Type (e.g., MAPC) ” , the additional Control, U-SIG, UHR-SIG Common for the Co-SR Invite ICF frame can be conveyed within B22, B26, B37–B54, and B63 in the UHR variant Common Info and B25-B39 in the Special User Info fields. B56-B59 and B60 in the UHR Variant Common Info field can also be optionally repurposed (if needed) .
[0116] Advantageously, no additional Special User Info Field or UHR-Variant Info Field is needed to be included, reducing complexity over prior proposals.
[0117] A format for the UHR-Variant Common Info and Special User Info Field is given in FIG. 19A according to an embodiment of the present invention.
[0118] The location of the additional Control, U-SIG, and UHR-SIG Common for the Co-SR Invite ICF frame conveyed within the above UHR Variant Common Info and Special User Info fields may be changed.
[0119] In some embodiments, the Co-BF / Co-SR Invite ICF type value is set to 4 correspond to a BSRP trigger frame format with the GI and HE / UHR-LTF type sub-field having a value of 3. In this case the value of the GI and HE / UHR_LTF type to be included in the U-SIG of the subsequent downlink transmission can be included as one (e.g., GI and HE / UHR_LTF type (2 bits) ) of the fields to be added within the MAPC-Type specific related Info.
[0120] In one of the embodiments, an additional Special User Info field (with Special AID > 2007 or Shared AP AID) may be required to accommodate other necessary parameters for Co-SR Invite ICF frame. FIG. 19B demonstrates one possible arrangement of the UHR Variant Common Info Field, Special User Info field, and the additional Special User Info field dedicated for the Co-SR Invite ICF Frame that according to embodiments provide the at least 20 bits of repurposed space for the information of FIG. 18. The location of the additional Control, U-SIG, and UHR-SIG Common for the Co-SR Invite ICF frame conveyed within the above UHR Variant Common Info, Special User Info, additional Special User Info field fields may be changed.
[0121] The aforementioned embodiments applied to Co-BF Invite and Co-BF Sync of creating a new trigger frame type with trigger type dependent info, or repurposing a subtype of the Ranging trigger frame, also apply to the Co-SR ICF / Invite frame, the details of which do not necessarily bear repeating.
[0122] FIG. 19C demonstrates one possible arrangement of the UHR Variant Common Info Field, Special User Info field, and the Trigger Dependent Common Info field for a new-type trigger frame used for Co-SR Invite ICF Frame.
[0123] The fourth MAPC frame type to discuss in detail is the Co-SR Sync Trigger Frame, and the new control and U-SIG info desired to be carried in this frame is represented in FIG. 20. The type of information is similar to much of what is needed for the Co-BF Sync frame with the exception of the Co-SR mode bit and the Shared AP’s TX Power Limit, which are not applicable to Co-BF. Altogether, 44 new bits are desired to fit into the format of the Co-SR Sync Trigger Frame.
[0124] Some of the information mentioned above may not be necessary or could be sufficiently conveyed in the Co-SR Invite, such as Punctured Channel Info, Number of UHR-SIG Symbols. In such cases, we could replace one of these fields with an indication for Data Symbols (5 bits) , which might be required (but not necessary) if the BA Type is Trigger-based ACK or BA.
[0125] If B39 = 1 in the Special User Info field is repurposed to indicate “Extended Type (e.g., MAPC) ” , the additional Control, U-SIG, UHR-SIG Common for the Co-SR Sync. Trigger frame can be conveyed within B22, B26, B37–B54, and B63 in the UHR variant Common Info and B25-B38 in the Special User Info fields. B56-B59 and B60 in the UHR Variant Common Info field can also be optionally repurposed (if needed) .
[0126] If B62 = 0 in the Common Info field is repurposed to indicate “Extended Type (e.g., MAPC) ” , the additional Control, U-SIG, UHR-SIG Common for the Co-SR Sync. Trigger frame can be conveyed within B22, B26, B37–B54, and B63 in the UHR variant Common Info and B25-B39 in the Special User Info fields. B56-B59 and B60 in the UHR Variant Common Info field can also be optionally repurposed (if needed) .
[0127] It will be appreciated that, advantageously, in this embodiment, no additional special user info fields are needed beyond the first one, and no UHR-variant User Info Fields are required in this format. An arrangement of the UHR Variant Common Info Field and single Special User Info Field for the Co-SR Sync / Trigger Frame is presented in FIG. 21A.
[0128] The location of the additional Control, U-SIG, UHR-SIG Common, and UHR-SIG User Field for the Co-SR Sync frame conveyed within the above UHR Variant Common Info and Special User Info fields may be changed.
[0129] In some embodiments, the Co-BF / Co-SR Sync. trigger type value is set to 4 correspond to a BSRP trigger frame format with the GI and HE / UHR-LTF type sub-field having a value of 3. In this case the value of the GI and HE / UHR_LTF type to be included in the U-SIG of the subsequent downlink transmission can be included as one (e.g., GI and HE / UHR_LTF type (2 bits) ) of the fields to be added within the MAPC-Type specific related Info.
[0130] In one of the embodiments, an additional Special User Info field (with Special AID > 2007 or Shared AP AID) may be required to accommodate other necessary parameters for Co-SR Sync. Trigger frame. FIG. 21B demonstrates one possible arrangement of the UHR Variant Common Info Field, Special User Info field, and the additional Special User Info field dedicated for the Co-SR Sync. Trigger Frame that according to embodiments provide the at least 44 bits of repurposed space for the information of FIG. 20. The location of the additional Control, U-SIG, and UHR-SIG Common for the Co-SR Sync. Trigger frame conveyed within the above UHR Variant Common Info, Special User Info, additional Special User Info field fields may be changed.
[0131] As discussed above for the Co-BF Sync frame, the Co-SR Sync frame can also be defined by allocating a new Trigger Frame type with Trigger Dependent Common Info, and store all additional Control, U-SIG, UHR-SIG Common, and UHR-SIG User Field for the Co-SR Sync frame in the MAPC Subtype Specific parameter field. FIG. 21C demonstrates one possible arrangement of the UHR Variant Common Info Field, Special User Info field, and the Trigger Dependent Common Info field for a new-type trigger frame used for Co-SR Sync. Trigger Frame.
[0132] Also as discussed above for the Co-BF Sync frame, a reserved value of the Ranging trigger frame variants can be allocated for MAPC trigger frame, e.g., 5. Within the Ranging Trigger Dependent Common Info field, Sharing AP can set Ranging Trigger Sub-type to MAPC , the value of the MAPC Sub-type variant to indicate Co-SR Sync / Trigger frame, then all additional Control, U-SIG, UHR-SIG Common, and UHR-SIG User Field for the Co-BF Invite ICF frame can be accommodated in the MAPC Subtype Specific parameter field.
[0133] In a fourth major aspect of the invention, an Initial Control Response (ICR) frame format is disclosed for Co-BF or Co-SR. The Response frame or ICR may have a format of a Multi-Station (STA) Block Acknowledgment (ACK) frame, the format having a block ACK information field that includes: a first Association Identifier (AID) Traffic Identifier (TID) Info field configured to indicate, optionally, to the sharing AP that the shared AP acknowledges receiving the Co-BF or Co-SR Invite ICF frame; and a second AID TID Info field configured to indicate, to the sharing AP, that the shared AP accepts the invitation or declines the invitation to participate in the Co-BF or Co-SR transmission phase.
[0134] If the shared AP accepts the sharing AP’s invitation to participate in the Co-BF or Co-SR transmission phase, it will respond with Multi-STA BA frame indicating that it is available to participate in the Co-BF or Co-SR transmission phase) and list and requirements of the shared AP to participate in the Co-BF or Co-SR transmission phase.
[0135] In case of Co-BF Acceptance, the shared AP needs to list the Co-BF Acceptance’s related-subfields, tabulated in FIG. 22A, within the Multi-STA Block ACK frame. The MAPC Type and the Accept or Decline subfields can be merged in one field to indicate Co-BF Acceptance in one field as shown in FIG. 22B, in which Acceptance or Declination is moved from a dedicated bit to a state of the MAPC type.
[0136] If the Shared AP declines the Sharing AP’s invitation to participate in the Co-BF transmission phase, it will respond with a Multi-STA BA frame, specifying the reason for declining, either unavailability or unreadiness for the Co-BF transmission phase or a failure in the Co-BF sounding phase with the Sharing AP. Alternatively, the Shared AP may choose not to provide a reason for declining the invitation. The Shared AP may also declare the desired parameters’ values that may not align with the parameters included in the Co-BF Invite ICF frame, if the reason of the decline is Co-BF parameters misalignment.
[0137] In case of Co-BF decline, the shared AP needs to list the Co-SR decline’s related-subfields, tabulated in FIG. 23A, within the Multi-STA Block ACK frame. Similar to the acceptance case of the response frame, the MAPC Type and the Accept or Decline subfields can be merged in one field to indicate Co-BF Decline in one field as indicated in FIG. 23B.
[0138] The encoding of the 1-3-bit Co-BF Decline Info subfield is given in FIG. 24.
[0139] In case of Co-SR Acceptance, the shared AP needs to list the Co-SR Acceptance’s related subfields, tabulated in FIG. 25A, within the Multi-STA Block ACK frame. Again, the MAPC Type and the Accept or Decline subfields can be merged in one field to indicate Co-SR Acceptance in one field by using separate values of MAPC Type for accepting and declining, as shown in FIG. 25B.
[0140] If the Shared AP declines the Sharing AP’s invitation to participate in the Co-SR transmission phase, it will respond with a Multi-STA BA frame, specifying the reason for declining, either unavailability or unreadiness for the Co-BF transmission phase or the minimum and maximum transmit power values listed in the Co-SR Invite ICF frame. Alternatively, the Shared AP may choose not to provide a reason for declining the invitation. The Shared AP may also declare the desired parameters’ values that may not align with the parameters included in the Co-SR Invite ICF frame, if the reason of the decline is Co-SR parameters misalignment.
[0141] In case of Co-SR decline, the shared AP needs to list the Co-SR decline’s related-subfields, tabulated in FIG. 26A, within the Multi-STA Block ACK frame. The MAPC Type and the Accept or Decline subfields can be merged in one field to indicate Co-SR Decline in one field as in FIG. 26B.
[0142] The encoding of the 1-3-bit Co-SR Decline Info subfield is given in FIG. 27.
[0143] In some embodiments, the Multi-STA Block Ack (Multi-STA BA) includes an Per AID TID Info field, which may include a 16-bit AID TID Info field having: an 11-bit AID identifying the sharing AP; ; a 1-bit ACK Type sub-field and a 4-bit TID sub-field having values that together indicate that the Multi-STA BA is an initial control response (ICR) to the sharing AP’s invitation to participate in an MAPC transmission phase (e.g., Co-BF, Co-SR, Co-TDMA, …., etc. ) . The encoding of the ACK Type and TID subfields are given in FIG. 28.
[0144] In some embodiments, the 1-bit ACK Type sub-field may have a value of 0 and the 4-bit TID sub-field has a value of 13, a combination which heretofore is reserved but may indicate in an embodiment an ICR / Response frame.
[0145] In some embodiments, other reserved values of the 1-bit ACK Type sub-field and the 4-bit TID sub-field may also utilized to indicate Shared AP’s initial control response (ICR) to the sharing AP’s invitation to participate in an MAPC transmission phase (e.g., Co-BF, Co-SR, Co-TDMA, …., etc. ) .
[0146] In some embodiments, the per AID TID Info field may include a Block ACK Starting Sequence Control sub-field and a Block ACK bitmap sub-field. Such sub-fields would be marked as Present for any combination of Ack Type and TID in FIG. 28 which may be repurposed from Reserved to identify a frame as Response / ICR.
[0147] In some embodiments, the Block ACK Starting Sequence Control sub-field may include: a 4-bit fragment number sub-field indicating a length of a Block Ack Bitmap configured to carry one or more control or feedback parameters; and a Starting Sequence Number sub-field that can be repurposed to include a 4-bit Type sub-field; and a 8-bit Type-Specific Common Control Info subfield.
[0148] The encoding of the 4-bit Type field can be as tabulated in FIG. 29.
[0149] In some embodiments, the Block ACK Starting Sequence Control sub-field may include a Starting Sequence Number sub-field that has: a 3 or 4-bit Sub-Type sub-field and a 1-bit accept or decline within the Type-Specific Common Control Info subfield, the Type sub-field having a value indicating that the Per AID TID Info field includes the MAPC Response or feedback, the encoding of the Sub-Type sub-field can be as given in FIG. 30A.
[0150] The Sub-Type sub-field and the 1-bit accept or decline may in some embodiments be merged together in one field as given in FIG. 30B.
[0151] Referring back to FIG. 29 and the Starting Sequence Number 4-bit Type sub-field, Different MAPC responses for different MAPC schemes (e.g, Co-BF, Co-SR, Co-TDMA, …, etc. ) can in an embodiment be listed in the 4-bit Type field as shown in FIG. 31, which can be considered an expansion of FIG. 29.
[0152] The Block Ack Bitmap subfield will carry the MAPC Response ICR related parameters, based on the MAPC type subfield, such as Co-BF Acceptance’s related subfields, Co-BF Acceptance’s related subfields, Co-BF Decline’s related subfields, Co-SR Acceptance’s related subfields, Co-SR Decline’s related subfields, Co-TDMA Acceptance’s related subfields, Co-TDMA Decline’s related subfields, etc.
[0153] One possible format for the Per MAPC’s response AID TID Info field within the Multi-STA BA frame is illustrated in FIG. 32.
[0154] FIG. 2 is a schematic diagram of device 200 that may perform any or all of operations of the above methods and features explicitly or implicitly described herein, according to different embodiments of the present invention. For example, a computer equipped with network function may be configured as device 200. As may be appreciated by a person skilled in the art, the device 200 can represent one or more entities described herein, for example, an AP, a STA, or the like.
[0155] As shown, the device 200 may include a processor 210, such as a central processing unit (CPU) or specialized processors such as a graphics processing unit (GPU) or other such processor unit, memory 220, non-transitory mass storage 230, input-output interface 1040, network interface 250, and a transceiver 260, all of which are communicatively coupled via bi-directional bus 270. According to certain embodiments, any or all of the depicted elements may be utilized, or only a subset of the elements. Further, device 200 may contain multiple instances of certain elements, such as multiple processors, memories, or transceivers. Also, elements of the hardware device may be directly coupled to other elements without the bi-directional bus. Additionally, or alternatively to a processor and memory, other electronics, such as integrated circuits, may be employed for performing the required logical operations.
[0156] The memory 220 may include any type of non-transitory memory such as static random access memory (SRAM) , dynamic random access memory (DRAM) , synchronous DRAM (SDRAM) , read-only memory (ROM) , any combination of such, or the like. The mass storage element 230 may include any type of non-transitory storage device, such as a solid state drive, hard disk drive, a magnetic disk drive, an optical disk drive, USB drive, or any computer program product configured to store data and machine executable program code. According to certain embodiments, the memory 220 or mass storage 230 may have recorded thereon statements and instructions executable by the processor 210 for performing any of the aforementioned method operations described above.
[0157] Embodiments of the present invention can be implemented using electronics hardware, software, or a combination thereof. In some embodiments, the invention is implemented by one or multiple computer processors executing program instructions stored in memory. In some embodiments, the invention is implemented partially or fully in hardware, for example using one or more field programmable gate arrays (FPGAs) or application specific integrated circuits (ASICs) to rapidly perform processing operations.
[0158] It will be appreciated that, although specific embodiments of the technology have been described herein for purposes of illustration, various modifications may be made without departing from the scope of the technology. The specification and drawings are, accordingly, to be regarded simply as an illustration of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present invention. In particular, it is within the scope of the technology to provide a computer program product or program element, or a program storage or memory device such as a magnetic or optical wire, tape or disc, or the like, for storing signals readable by a machine, for controlling the operation of a computer according to the method of the technology and / or to structure some or all of its components in accordance with the system of the technology.
[0159] Acts associated with the method described herein can be implemented as coded instructions in a computer program product. In other words, the computer program product is a computer-readable medium upon which software code is recorded to execute the method when the computer program product is loaded into memory and executed on the microprocessor of the wireless communication device.
[0160] Further, each operation of the method may be executed on any computing device, such as a personal computer, server, PDA, or the like and pursuant to one or more, or a part of one or more, program elements, modules or objects generated from any programming language, such as C++, Java, or the like. In addition, each operation, or a file or object or the like implementing each said operation, may be executed by special purpose hardware or a circuit module designed for that purpose.
[0161] Through the descriptions of the preceding embodiments, the present invention may be implemented by using hardware only or by using software and a necessary universal hardware platform. Based on such understandings, the technical solution of the present invention may be embodied in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM) , USB flash disk, or a removable hard disk. The software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to execute the methods provided in the embodiments of the present invention. For example, such an execution may correspond to a simulation of the logical operations as described herein. The software product may additionally or alternatively include number of instructions that enable a computer device to execute operations for configuring or programming a digital logic apparatus in accordance with embodiments of the present invention.
[0162] Although the present invention has been described with reference to specific features and embodiments thereof, it is evident that various modifications and combinations can be made thereto without departing from the invention. The specification and drawings are, accordingly, to be regarded simply as an illustration of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present invention.
Claims
A method at an access point (AP) for multi-AP coordination (MAPC) in a wireless local area network, the method comprising:transmitting a coordinated beamforming (Co-BF) invite frame, the Co-BF invite frame being a first trigger frame with a first trigger type value, the first trigger frame comprising a set of one, two, or three station IDs of served stations;transmitting a coordinated beamforming (Co-BF) sync frame, the Co-BF sync frame being a second trigger frame with a second trigger type value, the second trigger frame comprising a User Info List comprising one or more UHR Variant User Info Fields, each User Info Field containing a 1-bit flag to assign a station one of two possible BSS colors; wherein each of the first and second trigger frames comprises:one and only one special user info field; anda 1-bit subfield indicating that the respective trigger frame is an extended format supporting MAPC or AP-AP communication features.The method of claim 1 wherein the first and second trigger type values are each equal to 4 or 3 and correspond to a BSRP or a MU-RTS trigger frame format.The method of claim 1 wherein the first and second trigger type values are greater than 8 and correspond to a dedicated MAPC trigger frame format.The method of any one of claims 1 to 3 wherein each of the first and second trigger frames comprises a two-, three-, or four-bit MAPC Type subfield to signal that the MAPC function being executed is Co-BF.The method of any one of claims 1 to 4 wherein the second trigger frame comprises a Block Ack type bit and resource allocation field for Block Ack.The method of any one of claims 1 to 5 wherein the second trigger frame comprises a 6-bit BSS Color subfield.A method at an access point (AP) for multi-AP coordination (MAPC) in a wireless local area network, the method comprising:transmitting a coordinated spatial re-use (Co-SR) invite frame, the Co-SR invite frame being a first trigger frame with a first trigger type value, the first trigger frame comprising a 5-bit punctured channel info field;transmitting a coordinated spatial re-use (Co-SR) sync frame, the Co-SR sync frame being a second trigger frame with a second trigger type value, the second trigger frame comprising a 1-bit flag signaling a Co-SR mode; wherein each of the first and second trigger frames comprises:one and only one special user info field; anda 1-bit subfield indicating that the respective trigger frame is an extended format supporting MAPC or AP-AP communication features.The method of claim 7 wherein the first and second trigger type values are less than or equal to 8 and correspond to a BSRP or a MU-RTS trigger frame.The method of claim 7 wherein the first and second trigger type values are greater than 8 and correspond to a dedicated MAPC trigger frame type.The method of any one of claims 7 to 9 wherein each of the first and second trigger frames comprises a two-, three-, or four-bit MAPC Type subfield to signal that the MAPC function being executed is Co-SR.The method of any one of claims 7 to 10 wherein the second trigger frame comprises a Block Ack type bit and resource allocation field for Block Ack.The method of any one of claims 7 to 11 wherein the second trigger frame comprises a 6-bit BSS Color subfield.An electronic apparatus configured as a wireless access point with a processor, memory, and instructions for executing the method of any one of claims 1 to 6.An electronic apparatus configured as a wireless access point with a processor, memory, and instructions for executing the method of any one of claims 7 to 12.A method at an access point (AP) for multi-AP coordination (MAPC) in a wireless local area network, the method comprising:transmitting a MAPC invite frame, the MAPC invite frame being a first trigger frame with a first trigger type value, the first trigger frame comprising a 5-bit punctured channel info subfield;transmitting a MAPC sync frame, the MAPC sync frame being a second trigger frame with the first trigger type value, the second trigger frame comprising 6-bit BSS color subfield; wherein each of the first and second trigger frames comprises:a Trigger Dependent Common Info field, anda two-, three-, or four-bit MAPC Sub-type subfield to signal a MAPC function of the first and second trigger frames from a set of functions including coordinated beamforming, coordinated spatial re-use, and coordinated time division multiple access; and the first trigger type value is selected from a set of values including 8, representing a Ranging Trigger Frame type, and a value greater than 8, representing a dedicated MAPC trigger frame type.An electronic apparatus configured as a wireless access point with a processor, memory, and instructions for executing the method of claim 15.A method at an access point (AP) for multi-AP coordination (MAPC) in a wireless local area network, the method comprising:receiving a MAPC invite frame, the MAPC invite frame being in the format of a BSRP trigger frame, the invite frame comprising a 5-bit punctured channel info subfield;transmitting a MAPC ICR or Response frame, the MAPC ICR or Response frame being in the format of a Multi-Station Block Ack frame, the MAPC ICR or Response frame comprising a 1-3-bit Decline Info subfield; wherein each of the invite frame and response frame comprises:a two-, three-, or four-bit MAPC Sub-type subfield to signal a MAPC function of the respective frame from a set of functions including coordinated beamforming, coordinated spatial re-use, and coordinated time division multiple access.The method of claim 17 wherein the MAPC invite frame has a Guard Interval type of 3.The method of claim 17 or 18 further including transmitting a MAPC Sync frame with a Guard Interval type of between 0 and 2 inclusive.A computer-readable storage medium having instructions stored thereon which, when executed by one or more apparatuses, cause the one or more apparatuses to perform the method of any one of claims 1 to 6, or any one of claims 7 to 12, or claim 15, or any one of claims 17 to 19.A computer program product for storing instructions which, when executed, cause an apparatus to perform the method of any one of claims 1 to 6, or any one of claims 7 to 12, or claim 15, or any one of claims 17 to 19.