Unified framework for multi-access point coordination in the transmission phase

Abstract

A unified framework for Multi-Access Point (MAP) coordination, during the transmission phase of a sharing access point (AP), is provided. The framework includes the sharing AP (an AP that has a transmission opportunity (TXOP)) sending a polling message to other APs to determine if any of the other APs would like to participate in the TXOP. The polling message includes specifics of the TXOP such as, a total duration of its TXOP, a portion of the duration the sharing AP 100 intends to share, an available bandwidth, the preferred Multi-AP coordination scheme (e.g., Co-SR, Co-BF, Co-TDMA, etc.) of the sharing AP 100 for the TXOP, a maximum allowed transmission power for the Shared APs, Number of non-AP STAs the sharing AP plans to serve within the TXOP, An indication of whether the Sharing AP will serve Enhanced Multi-Link Single Radio (eMLSR) or Dynamic Power Save (DPS) non-AP STAs within the TXOP. The other APs that are interested in participating the TXOP send a respective response message to the sharing AP, the response message including at least one of: an availability field set to indicate that the second AP is available to participate in the MAPC transmission phase; a requested duration field defining a duration needed by the second AP; a requested bandwidth field defining a bandwidth needed by the second AP; a low-delay field set to indicate low-latency traffic or not; a buffered data expiry field defining a lifetime of buffered data; a preferred multi-AP (MAP) coordination scheme; a minimum allowed or acceptable transmit power; an indication of whether the Shared AP will serve Enhanced Multi-Link Single Radio (eMLSR) or Dynamic Power Save (DPS) non-AP STAs within the TXOP; and a number of stations (STAs) to be served. Subsequently, the sharing AP sends, to the interested other APs, a MAP announcement frame that indicates to the second AP at least one supported coordination scheme; and defines the resources allocated to the second AP.

Description

UNIFIED FRAMEWORK FOR MULTI-ACCESS POINT COORDINATION IN THE TRANSMISSION PHASECROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to United States Provisional Patent Application No. 63 / 760, 380, filed February 19, 2025, the contents of which are incorporated herein by reference.TECHNICAL FIELD

[0002] The present application pertains to communications networks and in particular to methods, apparatus, and systems for access points in wireless communications networks.BACKGROUND

[0003] The Multi-Access Point Coordination (MAPC) Framework introduced by the 802.11bn Specification Framework Document (SFD) can enhance wireless network efficiency by optimizing resource sharing and coordination among multiple access points (APs) to the network. 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) schemes, as well as service period (SP) -based coordination schemes, such as coordinated restricted target wake time (Co-r-TWT) schemes. MAPC coordination can sequentially comprise: MAP discovery, which can involve identifying and discovering candidate APs that may be capable of participating in coordinated activities; MAP coordination negotiation and agreement setting, which can establish agreements on coordination mechanisms, including the roles and responsibilities of participating APs; and MAP coordinated transmission, where coordinated transmissions are executed based on the negotiated agreements. Although the MAPC Framework provides key procedures for MAPC discovery and MAP coordination negotiation and agreement setting, namely the MAPC Discovery Procedure and the MAPC Agreement Negotiation Procedure, the framework does not comprehensively address the MAP coordinated transmission phase, which is critical for optimizing real-time data transmission.

[0004] Current approaches to enabling MAPC coordinated transmission have explored employing various TXOP-based coordination schemes (e.g., Co-SR, Co-BF, and Co-TDMA schemes) and SP-based schemes (CR-TWT) . A common assumption in these approaches is that an AP with a sharing TXOP (i.e., the “sharing AP” ) pre-selects the MAPC scheme at the beginning of its TXOP, according to its specific requirements. The sharing AP can then poll other APs in the MAPC group to verify their availability and urgency, deciding which APs to include in the TXOP-sharing process. This assumption may not be universally valid. APs within the same MAPC group may agree to support multiple coordination schemes, which can then require flexible decision-making. Each MAPC scheme has inherent trade-offs that affect its performance and complexity, which influences its real-time applicability. Factors such as a limited TXOP duration, the number of coordinating APs, and the number of associated non-AP stations can affect the feasibility of particular coordination schemes. The pre-determined MAPC scheme may also not align with the dynamic needs of some APs in the MAPC group during the shared TXOP. In addition, certain MAPC schemes have predefined constraints. For example, Co-SR and Co-BF are limited to only two APs, and Co-BF can serve only a maximum of four non-AP STAs. Fluctuating traffic demands can furthermore lead to mismatches between allocated resources and actual requirements, reducing efficiency. Overall, the current approaches that pre-determine the MAPC and limit the MAPC transmission phase to a single scheme per shared TXOP are inherently rigid and inflexible, which can cause performance to be hampered and resources to be underutilized.

[0005] Therefore, there is a need for methods, systems, and apparatus for MAPC coordinated transmission that obviates or mitigates one or more limitations of the prior art.

[0006] This background information is provided to reveal information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.SUMMARY

[0007] In a first aspect, the present disclosure provides a method that comprises, at a first AP that has a transmission opportunity (TxOP) , the first AP being a sharing AP: sending a polling initial control frame (ICF) to a group of additional APs to poll the group of additional APs regarding an availability of the group of additional APs to participate in a multi access point coordination (MAPC) transmission phase. The polling ICF includes: a bandwidth field identifying a bandwidth available during the TxOP; a number of non-AP STAs the sharing AP plans to serve within the TXOP; an indication of whether the Sharing AP will serve Enhanced Multi-Link Single Radio (eMLSR) or Dynamic Power Save (DPS) non-AP STAs within the TXOP; a maximum allowed transmission power; and a duration field defining at least one of: a duration of the TxOP; and a portion of the duration of the TxOP attributed to the sharing AP. The method further comprises, also at the first AP: receiving, from a second AP, a polling initial control response frame (ICRF) , the second AP being an additional AP of the group of additional APs that is available to participate in the MAPC transmission phase. The polling ICRF has at least one of: an availability field set to indicate that the second AP is available to participate in the MAPC transmission phase; a requested duration field defining a duration needed by the second AP; a requested bandwidth field defining a bandwidth needed by the second AP; a low-delay field set to indicate low-latency traffic or not; a buffered data expiry field defining a lifetime of buffered data; a preferred multi-AP (MAP) coordination scheme; a minimum allowed or acceptable transmit power; an indication of whether the Shared AP will serve Enhanced Multi-Link Single Radio (eMLSR) or Dynamic Power Save (DPS) non-AP STAs within the TXOP; and a number of stations (STAs) to be served.

[0008] In some embodiments, the polling ICF may include a coordination field, the coordination field identifying a Multi-AP coordination scheme preferred by the sharing AP for the TxOP.

[0009] In some embodiments, the duration field may define Network Allocation Vector (NAV) protection parameters that define the time allotted for the additional APs of the group of additional APs to reply to the polling ICF.

[0010] In some embodiments, the polling ICF may have a trigger type subfield that has a value set to correspond to a Buffer Status Report Poll (BSRP) trigger frame variant.

[0011] In some embodiments, the polling ICF may have a Guard Interval (GI) and a High Efficiency (HE)  / Ultra High Reliability (UHR) Long Training Field (LTF) type sub-field (GI and HE / UHR-LTF type sub-field) . The GI and HE / UHR-LFT type sub-field may have a value indicating that a Physical Layer Protocol Data Unit (PPDU) to be received in response to the polling ICF is to be in a non-High Throughput (non-HT) format and contain a Multi-station (Multi-STA) Block Acknowledgement (ACK) .

[0012] In some embodiments, the polling ICF may be a Public Action Frame.

[0013] In some embodiments, the polling ICRF 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 to the sharing AP that the second AP acknowledges receiving the polling ICF; and a second AID TID Info field configured to indicate, to the sharing AP, that the second AP is available to participate in the MAPC transmission phase; and requirements of the second AP for the second AP to participate in the MAPC transmission phase.

[0014] In some embodiments, the first AID TID Info field may include a 16-bit AID TID Info field having a value that indicates to the sharing AP that the second AP is available to participate in the MAPC transmission phase.

[0015] In some embodiments, the second AID TID Info field 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, the 1-bit ACK Type sub-field and the 4-bit TID sub-field having values that together indicate that the second AID TID Info field having a value that indicates to the sharing AP that the second AP is available to participate in the MAPC transmission phase and includes the requirements of the second AP for the second AP to participate in the MAPC transmission phase.

[0016] 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.

[0017] In some embodiments, the second AID TID Info field may include a Block ACK Starting Sequence Control sub-field and a Block ACK bitmap sub-field.

[0018] In some embodiments, the Block ACK Starting Sequence Control sub-field may include: a 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 Type sub-field; and a Type-Specific Common Control Info subfield.

[0019] In some embodiments, the Block ACK Starting Sequence Control sub-field may include a Starting Sequence Number sub-field that has: a Sub-Type sub-field within the Type-Specific Common Control Info subfield, the Type sub-field having a value indicating that the second PER AID TID Info field includes the MAP Coordination control or feedback, the Sub-Type sub-field having a value indicating that the Block ACK bitmap sub-field includes the MAP Polling ICR parameters, e.g., the availability and requirements of the second AP for the second AP to participate in the MAPC transmission phase.

[0020] In some embodiments, the Block ACK bitmap sub-field may include the availability indication (e.g., accept or decline the MAPC invitation) and the requirements of the second AP for the second AP to participate in the MAPC transmission phase.

[0021] In some embodiments, the method may further comprise, at the sharing AP: determining that the second AP can share the TxOP with the sharing AP; and sending, to the second AP, a MAP announcement frame that: indicates to the second AP at least one supported coordination scheme; and defines the resources allocated to the second AP.

[0022] In some embodiments, the MAP announcement frame may be a Buffer Status Report Poll (BSRP) frame having: a 12-bit AID field identifying the shared AP, the shared AP being the second AP; a 4-bit Type field indicating the BSPR frame is a MAP announcement frame; a 3-bit field identifying the at least one supported coordination scheme; and a 21-bit field defining parameter of the at least one supported coordination scheme.

[0023] In some embodiments, the duration field may define NAV protection for the second AP, the NAV protection to define a time period during which the second AP can reply to the MAP announcement frame or during which the second AP can trigger associated non-AP stations to switch to a different channel.

[0024] In some embodiments, the 21-bit field may indicate, to the second AP, at least one of: an allocated shared TxOP duration; a start time of the allocated shared TxOP duration; a TxOP return indicator; and a bandwidth to be used during the allocated shared TxOP duration.

[0025] In some embodiments, the 21-bit field may indicate, to the second AP, at least one of: a duration of a downlink (DL) Physical Layer Protocol Data Unit (PPDU) ; a transmission start time; and transmit power control parameters.

[0026] In some embodiments, the 21-bit field may indicate, to the second AP, at least one of: an assigned RU Allocation; Co-OFDMA Duration; Co-OFDMA Switching start time; and Co-OFDMA trigger frame’s transmit power limit.

[0027] In some embodiments, the 21-bit field may indicate, to the second AP, at least one of: NPCA Duration; NPCA Switching start time; and NPCA trigger frame’s transmit power limit.

[0028] In some embodiments, the 21-bit field may indicate, to the second AP, at least one of: a duration of a downlink (DL) Physical Layer Protocol Data Unit (PPDU) ; a transmission start time; Non-AP STAs to be served; an indication of whether the Sharing AP will serve Enhanced Multi-Link Single Radio (eMLSR) or Dynamic Power Save (DPS) non-AP STAs within the TXOP; Sync. Follower / Sync. Reference Indicator; Precoder parameters (estimated during the Co-BF sounding phase) ; and CFO precorrection (estimated during the Co-BF sounding phase) .

[0029] In a second aspect, the present disclosure provides a method that comprises, at a first access point (AP) : receiving, from a second AP, a polling initial control frame (ICF) . The second AP is a sharing AP that has a transmission opportunity (TxOP) . The polling ICF has associated thereto a multi access point coordination (MAPC) transmission phase. The polling ICF includes: a bandwidth field identifying a bandwidth available during the TxOP; a number of non-AP STAs the sharing AP plans to serve within the TXOP; an indication of whether the Sharing AP will serve Enhanced Multi-Link Single Radio (eMLSR) or Dynamic Power Save (DPS) non-AP STAs within the TXOP; a maximum allowed transmission power; and a duration field defining at least one of: a duration of the TxOP; and a portion of the duration of the TxOP attributed to the sharing AP. The method also comprises sending, to the sharing AP, a polling initial control response frame (ICRF) to indicate to the sharing AP that the first AP is available to participate in the MAPC transmission phase, the polling ICRF having at least one of: an availability field set to indicate that the first AP is available to participate in the MAPC transmission phase; a requested duration field defining a duration needed by the first AP; a requested bandwidth field defining a bandwidth needed by the first AP; a low-delay field set to indicate low-latency traffic or not; a buffered data expiry field defining a lifetime of buffered data; a preferred multi-AP (MAP) coordination scheme; a minimum allowed or acceptable transmit power; an indication of whether the Shared AP will serve Enhanced Multi-Link Single Radio (eMLSR) or Dynamic Power Save (DPS) non-AP STAs within the TXOP; and a number of stations (STAs) to be served.

[0030] In some embodiments, the polling ICF may include a coordination field, the coordination field identifying a Multi-AP coordination scheme preferred by the sharing AP for the TxOP.

[0031] In some embodiments, the duration field may define Network Allocation Vector (NAV) protection parameters that define the time allotted for the additional APs of the group of additional APs to reply to the polling ICF.

[0032] In some embodiments, the polling ICF may have a trigger type subfield having a value set to correspond to a Buffer Status Report Poll (BSRP) trigger frame variant.

[0033] In some embodiments, the polling ICF may have a Guard Interval (GI) and a High Efficiency (HE)  / Ultra High Reliability (UHR) Long Training Field (LTF) type sub-field (GI and HE / UHR-LTF type sub-field) . The GI and HE / UHR-LFT type sub-field may have a value indicating that a Physical Layer Protocol Data Unit (PPDU) to be received in response to the polling ICF is to be in a non-High Throughput (non-HT) format and contain a Multi-station (Multi-STA) Block Acknowledgement (ACK) .

[0034] In some embodiments, the polling ICF may be a Public Action Frame.

[0035] In some embodiments, the polling ICRF 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 to the sharing AP that the first AP acknowledges receiving the polling ICF; and a second AID TID Info field configured to indicate, to the sharing AP, that the first AP is available to participate in the MAPC transmission phase; and requirements of the first AP for the first AP to participate in the MAPC transmission phase.

[0036] In some embodiments, the first AID TID Info field may include a 16-bit AID TID Info field having a value that indicates to the sharing AP that the first AP is available to participate in the MAPC transmission phase.

[0037] In some embodiments, the second AID TID Info field 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, the 1-bit ACK Type sub-field and the 4-bit TID sub-field having values that together indicate that the second AID TID Info field having a value that indicates to the sharing AP that the first AP is available to participate in the MAPC transmission phase and includes the requirements of the first AP for the first AP to participate in the MAPC transmission phase.

[0038] In some embodiments, the 1-bit ACK Type sub-field may have a value of 0 and the 4-bit TID sub-field may have a value of 13.

[0039] In some embodiments, the second AID TID Info field may include a Block ACK Starting Sequence Control sub-field and a Block ACK bitmap sub-field.

[0040] In some embodiments, the Block ACK Starting Sequence Control sub-field may include: a 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 Type sub-field; and a Type-Specific Common Control Info subfield.

[0041] In some embodiments, the Block ACK Starting Sequence Control sub-field may include a Starting Sequence Number sub-field that has: a Sub-Type sub-field within the Type-Specific Common Control Info subfield, the Type sub-field having a value indicating that the second PER AID TID Info field includes the MAP Coordination control or feedback, the Sub-Type sub-field having a value indicating that the Block ACK bitmap sub-field includes the MAP Polling ICR parameters, e.g., the availability and requirements of the first AP for the first AP to participate in the MAPC transmission phase.

[0042] In some embodiments, the Block ACK bitmap sub-field may include the availability indication (e.g., accept or decline the MAPC invitation) and the requirements of the first AP for the first AP to participate in the MAPC transmission phase.

[0043] In some embodiments, the method may further comprise, at the first AP: receiving, from the sharing AP, a MAP announcement frame that: indicates to the first AP at least one supported coordination scheme; and defines the resources allocated to the first AP.

[0044] In some embodiments, the MAP announcement frame may be a Buffer Status Report Poll (BSRP) frame having: a 12-bit AID field identifying the shared AP, the shared AP being the first AP; a 4-bit Type field indicating the BSPR frame is a MAP announcement frame; a 3-bit field identifying the at least one supported coordination scheme; and a 21-bit field defining parameter of the at least one supported coordination scheme.

[0045] In some embodiments, the duration field may define NAV protection for the first AP, the NAV protection to define a time period during which the first AP can reply to the MAP announcement frame or during which the first AP can trigger associated non-AP stations to switch to a different channel.

[0046] In some embodiments, the 21-bit field may indicate, to the first AP, at least one of: an allocated shared TxOP duration; a start time of the allocated shared TxOP duration; a TxOP return indicator; and a bandwidth to be used during the allocated shared TxOP duration.

[0047] In some embodiments, the 21-bit field may indicate, to the first AP, at least one of: a duration of a downlink (DL) Physical Layer Protocol Data Unit (PPDU) ; a transmission start time; and transmit power control parameters.

[0048] In some embodiments, the 21-bit field may indicate, to the first AP, at least one of: an assigned RU Allocation; Co-OFDMA Duration; Co-OFDMA Switching start time; and Co-OFDMA trigger frame’s transmit power limit.

[0049] In some embodiments, the 21-bit field may indicate, to the first AP, at least one of: NPCA Duration; NPCA Switching start time; and NPCA trigger frame’s transmit power limit.

[0050] In some embodiments, the 21-bit field may indicate, to the first AP, at least one of: a duration of a downlink (DL) Physical Layer Protocol Data Unit (PPDU) ; a transmission start time; Non-AP STAs to be served; an indication of whether the Sharing AP will serve Enhanced Multi-Link Single Radio (eMLSR) or Dynamic Power Save (DPS) non-AP STAs within the TXOP; Sync. Follower / Sync. Reference Indicator; Precoder parameters (estimated during the Co-BF sounding phase) ; and CFO precorrection (estimated during the Co-BF sounding phase) .

[0051] Embodiments have been described above in conjunctions with aspects of the present invention upon which they can be implemented. Those skilled in the art will appreciate that embodiments may be implemented in conjunction with the aspect with which they are described, but may also be implemented with other embodiments of that aspect. When embodiments are mutually exclusive, or are otherwise incompatible with each other, it will be apparent to those skilled in the art. Some embodiments may be described in relation to one aspect, but may also be applicable to other aspects, as will be apparent to those of skill in the art.BRIEF DESCRIPTION OF THE FIGURES

[0052] Further features and advantages of the present invention will become apparent from the following detailed description, taken in combination with the appended drawings, in which:

[0053] FIG. 1 shows a sequence of polling messages between a sharing AP and shared APs, according to embodiments of the present invention.

[0054] FIG. 2 shows an embodiment of a UHR variant Common Info field format, according to embodiments of the present disclosure.

[0055] FIG. 3A shows an Extended Special User field formatted according to an embodiment of the present disclosure.

[0056] FIG. 3B shows an Extended Special User field formatted according to another embodiment of the present disclosure.

[0057] FIG. 4 shows a sequence of polling messages between a sharing AP and shared APs, according to embodiments of the present invention.

[0058] FIG. 5 shows a MAP Polling ICR frame according to embodiments of the present disclosure.

[0059] FIG. 6 shows an AID TID info sub-field format according to embodiments of the present disclosure.

[0060] FIG. 7 shows a breakdown of a Per AID TID Info field according to embodiments of the present disclosure.

[0061] FIG. 8 shows an embodiment of a format of an Extended Special User Info field according to the present disclosure.

[0062] FIG. 9 shows another embodiment of a format of an Extended Special User Info field according to the present disclosure.

[0063] FIG. 10 shows another sequence of polling messages between a sharing AP and shared APs, according to embodiments of the present invention.

[0064] FIG. 11 shows a further sequence of polling messages between a sharing AP and shared APs, according to embodiments of the present invention.

[0065] FIG. 12 shows yet another sequence of polling messages between a sharing AP and shared APs, according to embodiments of the present invention.

[0066] It will be noted that throughout the appended drawings, like features are identified by like reference numerals.DETAILED DESCRIPTION

[0067] Table 1 shows a list of acronyms / abbreviations / initialisms used in the present disclosure. Table 1

[0068] The present disclosure proposes a unified framework for MAP Coordination during the transmission phase, designed to enhance flexibility and efficiency in TXOP-sharing processes. Features of the proposed framework may include adaptive scheme selection, where the Sharing AP prioritizes MAPC schemes that align with its transmission needs while considering the diverse requirements of Shared APs, ensuring optimal resource utilization. The framework may also support multiple schemes within a single TXOP, allowing the Sharing AP to employ different MAPC schemes with various Shared APs or one Shared AP within the same TXOP. For example, the framework can utilize Co-BF with one Shared AP for a specific duration of the TXOP and then switch to Co-TDMA with either the same or a different Shared AP for the remaining duration of the TXOP, based on specific needs, though it is important to note that Co-SR and Co-BF may not be supported simultaneously. The flexibility provided by the present disclosure increases the number of Shared APs that can participate in TXOP-sharing, significantly boosting the overall performance gains from MAP Coordination. The proposed framework aims to create a more adaptable and efficient MAP Coordination environment, addressing the limitations of current models and adding to the benefits of coordinated multi-AP transmissions.

[0069] The present disclosure sets forth various embodiments via the use of block diagrams, flowcharts, tables, and examples. Insofar as such block diagrams, flowcharts, tables, and examples contain one or more functions and / or operations, it will be understood by a person skilled in the art that each function and / or operation within such block diagrams, flowcharts, tables, and examples can be implemented, individually or collectively, by a wide range of hardware, software, firmware, or combination thereof. As used herein, the term “about” should be read as including variation from the nominal value, for example, a + / -10%variation from the nominal value. It is to be understood that such a variation is always included in a given value provided herein, whether or not it is specifically referred to.

[0070] The present invention aims to resolve some of the technical problems inherent in existing Multi-AP Coordination (MAPC) transmission phase. One significant issue is the rigidity of pre-determined MAPC schemes, which do not accommodate the dynamic and varying real-time requirements of Access Points (APs) within the same MAPC group. This inflexibility leads to suboptimal resource allocation and reduced network performance, especially in environments with fluctuating traffic demands. Additionally, the inability to support multiple coordination schemes within a single Transmission Opportunity (TXOP) restricts the potential for maximizing resource utilization and achieving higher efficiency gains.

[0071] Another technical problem is the limited scalability of current MAPC schemes, particularly when dealing with constraints such as the number of coordinating APs and non-AP Stations (STAs) that can be effectively managed. Existing solutions often fail to address resource constraints like TXOP duration limits, which can hinder the applicability of certain coordination schemes. Furthermore, the lack of a dynamic mechanism to evaluate and select the most suitable MAPC scheme in real-time based on current network conditions results in mismatches between allocated and required resources, thereby reducing overall network throughput and efficiency.

[0072] The present disclosure seeks to introduce a flexible, adaptive, unified framework that enables the Sharing AP to dynamically select and apply multiple MAPC schemes within a single TXOP. This approach considers both the Sharing AP's transmission requirements and the varying needs of Shared APs, optimizing resource distribution and enhancing network performance. By addressing these technical challenges, the present disclosure aims to improve the adaptability, scalability, and efficiency of MAP Coordination in complex wireless network environments.

[0073] The present disclosure introduces a unified Multi-AP Coordination (MAPC) framework, specifically designed for the transmission phase to improve the flexibility, scalability, and efficiency of coordinated wireless transmissions. An important innovation lies in the ability of the Sharing AP to support and manage multiple MAPC schemes within a single Transmission Opportunity (TXOP) , which is a significant departure from the rigid, pre-determined scheme selection prevalent in prior art. This adaptability allows the Sharing AP to choose coordination schemes that align with its real-time transmission needs while simultaneously considering the diverse requirements of Shared APs within the MAPC group.

[0074] Another feature of the present disclosure is the dynamic selection mechanism that enables the Sharing AP to evaluate network conditions in real-time and apply the most suitable MAPC schemes accordingly. This mechanism may enhance resource allocation, optimize throughput, and improve overall network performance, particularly in environments with fluctuating traffic demands. Additionally, the proposed framework may support hybrid coordination, where different MAPC schemes may coexist within a single TXOP-for instance, employing Co-BF with one Shared AP while using Co-TDMA with another. However, it is important to note that Co-SR and Co-BF may not be supported simultaneously. It is also noted that supporting multiple MAPC schemes with different shared APs within a single TXOP is possible, provided that both the sharing AP and the selected shared APs support these MAPC schemes and have already established an agreement for them during the MAPC negotiation phase.

[0075] By improving the participation of Shared APs in TXOP-sharing, the present disclosure may increase the potential performance gains from MAP Coordination. This flexible, multi-scheme approach may provide better resource utilization, reduce coordination overhead, and address the technical limitations of existing MAPC frameworks. Ultimately, the present disclosure introduces the way for more efficient, adaptable, and high-performing wireless networks, capable of meeting the demands of increasingly complex communication environments.

[0076] FIG. 1 shows a sequence of polling messages between a sharing AP 100 and shared APs 102, 104, and 106 in accordance with an embodiment of the present disclosure. The sequence in the embodiment of FIG. 1 takes place after the sharing AP 100 has obtained a TxOP. FIG. 1 also shows a MAP polling ICF frame 108, MAP polling ICR frames, 110, a MAP announcement frame 112, a Co-BF ICR frame 114, a MAP Polling &Agreement duration 116, and an AP1 TXOP duration 118.

[0077] When the Sharing AP obtains a TXOP, it sends a MAP polling ICF frame 108 to the other APs 102, 104, and 106 within the MAP coordination group to determine their willingness to participate in Multi-AP coordinated transmission and to gather information on their requested resources, provided they are ready.

[0078] Within the MAP Polling ICF frame, the Sharing AP may indicate one or more of the following MAP Polling ICF parameters in the MAP polling ICF frame: · a total duration of its TXOP, · a portion of the duration the sharing AP 100 intends to share, · an available bandwidth. · the preferred Multi-AP coordination scheme (e.g., Co-SR, Co-BF, Co-TDMA, etc. ) of the sharing AP 100 for the  TXOP. · a maximum allowed transmission power for the Shared APs. · Number of non-AP STAs the sharing AP plans to serve within the TXOP. · An indication of whether the Sharing AP will serve Enhanced Multi-Link Single Radio (eMLSR) or Dynamic  Power Save (DPS) non-AP STAs within the TXOP. · Other TBD info.

[0079] The Duration field of the MAP Polling ICF is set to provide short NAV protection for the Shared AP (s) to send their MAP Polling ICR frames to respond to the MAP Polling ICF frame.

[0080] MAP Polling ICF frame may be of any appropriate trigger frame type, such a multi-user block acknowledgement request (MU-BAR) trigger frame (e.g., by setting the Trigger Type subfield value to ‘2’ ) , as a multi-user request-to-send (MU-RTS) trigger frame (e.g., by setting the Trigger Type subfield value to ‘3’ ) , a new type trigger frame (for example, by setting the trigger type subfield value to one of the reserved values, e.g., ‘9-15’ ) , or a buffer status report poll (BSRP) trigger frame (Preferred) (e.g., by setting the Trigger Type subfield value to ‘4’ ) .

[0081] The Buffer Status Report Poll (BSRP) trigger frame may be a suitable candidate for this ICF frame, as its primary purpose aligns with the ICF's goal of assessing the resource needs of the polled APs (acore function of the BSRP) . The Guard Interval (GI) and UHR-LTF Type field of the Common Info field of the BSRP can take any value from 0 to 2 to represent the respective Guard Interval and UHR-LTF Type. Alternatively, these fields may be set to a value of 3 to indicate that the frame is a BSRP non-trigger-based frame (BSRP NTB) .

[0082] For instance, if the MAP Polling ICF format is set follow the buffer status report poll (BSRP) trigger frame (e.g., by setting the Trigger Type subfield value to ‘4’ ) , the polled AP (s) will send Buffer Status Report (BSR) or Multi-STA BA as MAP Polling ICR.

[0083] FIG. 2 shows a UHR variant Common Info field format. In embodiments where the MAP polling ICF frame 108 utilized this format, the Trigger Type sub-field 120 may be set to a value of 4 to indicate Buffer Status Report Poll. Table 2 shows an example of Trigger type frame variant encoding, where the value ‘4’ indicates BSRP. Table 2. Trigger type subfield encoding

[0084] In embodiments where the responding PPDU format is a non-HT (duplicate) PPDU format that contains a Multi-STA Block ACK, the Guard Interval (GI) and a High Efficiency (HE)  / Ultra High Reliability (UHR) Long Training Field (LTF) type sub-field 122 may be set to a value of 3, in accordance with Table 3. Table 3. GI and HE / UHR type subfield encoding

[0085] To allow multiple polled APs to respond simultaneously to the MAP Polling ICF frame, the Sharing AP can assign different RU allocations to each. This enables the polled APs (e.g., 102, 104, 106) to transmit their TB UL-PPDUs (e.g., MAP Polling ICR) concurrently.

[0086] The assigned RU allocation for each polled AP is specified in the RU Allocation subfield of its UHR Variant User Info field, identified by its assigned AP ID in the AID 12 subfield.

[0087] Another way to allow multiple shared APs to respond simultaneously to the MAP Polling ICF frame (if needed) , the Sharing AP may set a transmit power limit to each shared AP, following the same concept of Co-SR. This enables the shared APs to transmit their TB UL-PPDUs (e.g., MAP Polling ICR frames) concurrently, while managing the OBSS interference.

[0088] The present disclosure proposes enhancing the BSRP trigger frame by adding an Extended Special User Info field dedicated to ICF-type-specific Common information. This Extended Special User Info field may be formatted as shown in FIG. 3A.

[0089] Referring to FIG. 3A, the AID 12 sub-field has a fixed common value, which may be defined in the 11bn specification to identify this Extended Special User Info field. If this value falls within the range of 1-2006, the field will be placed immediately after the Special User Info field. If the value is greater than 2007 (e.g., 2008) (Preferred) , the field will be positioned following the User Info List.

[0090] Referring to FIG. 3A, the ICF Type sub-field may be used to specify the type of ICF, including options like MAP Polling ICF, Coordinated Beamforming (Co-BF) invite or ICF, Coordinated Spatial Reuse (Co-SR) invite or ICF, Coordinated TDMA (Co-TDMA) invite or ICF, Co-BF or Co-SR synchronization trigger, Coordinated Orthogonal Frequency Division Multiple Access (Co-OFDMA) invite or ICF, Coordinated Restricted Target Wake Time (Co-r-TWT) , In-device Coexistence (IDC) , Dynamic Sub-Band Operation (DSO) , Non-primary Channel Access (NPCA) , Dynamic Power Save (DPS) , and other types to be determined (TBD) . When the type-specific control info parameters exceed the length of the User Info field, it may be possible to utilize one bit in the field to indicate another extended User Info field is present.

[0091] Referring to FIG. 3A, in case where the type-specific common control info parameters exceed the length of the User Info field, it may be possible to utilize the one-bit Extended ICF info sub-field to indicate another extended User Info field is present.

[0092] For the MAP Polling ICF case, an objective of the Extended Special User Info field may be to carry the Common Info for the TXOP to be shared with other shared AP (s) , e.g., duration, bandwidth, preferred MAPC scheme, …, etc. The format of the Extended Special User Info field may be as shown in FIG. 3B.

[0093] If a new type of trigger frame is defined (for example, by setting the trigger type subfield value to one of the reserved values, e.g., ‘9-15’ ) , the UHR variant of the User Info field for this new trigger frame may be the same size (e.g., 5 bytes) as the enhanced BSRP trigger frame, or it may be larger than 5 bytes (e.g., 6-10 bytes) if we need to accommodate type-specific common control information within a single User Info field.

[0094] The present disclosure introduces a new Public Action Frame for MAP polling ICF, which may also be considered. The new Public Action Frame value for MAP polling ICF by repurposing one of the reserved values in the public Action field (e.g., 54-59 or 61-255) as shown in Table 4 Table 4. Public action field values

[0095] Table 5 shows a MAP Polling ICF Action field format Table 5. MAP polling ICF action field format

[0096] The MAP Polling ICF field or Element conveys the same information as in the MAP Polling ICF trigger frame.

[0097] APs that are not interested in participating in the MAP coordinated transmission may either respond to the MAP Polling ICF indicating their unwillingness to participate or simply not respond to the MAP Polling ICF. FIG. 4 shows an embodiment of the present disclosure where AP4 106 is not interested.

[0098] Shared APs that are interested in participating in the MAP coordinated transmission may respond to the MAP Polling ICF indicating their willingness and their requested resources.

[0099] One or more of the following information should be carried in the MAP Polling ICR: a. Readiness or availability indicator: The polled AP indicates its willingness or unwillingness to participate in  MAPC. b. Requested duration: the duration that the Shared AP requested to be allocated from the Sharing AP. c. Requested bandwidth: the BW that the Shared AP intends to be allocated based on its own / associated STA’s  capabilities. d. TID / AC: the TID / AC of the buffer e. One-bit Low-delay (low-latency traffic) indicator. f. Buffered data expire time: the shortest duration for which the buffered data remains valid before it expires. g. Traffic direction: Either DL (downlink) , UL (uplink) transmission, or both are required. Certain coordination schemes, such as Co-SR and Co-BF, support only concurrent DL transmissions, while others,  like Co-TDMA and NPCA, can support both UL and DL transmissions. h. Preferred MAP coordination scheme. i. Number of non-AP STAs to be served. j. An indication of whether the Shared AP will serve Enhanced Multi-Link Single Radio (eMLSR) or Dynamic  Power Save (DPS) non-AP STAs within the TXOP. k. Minimum allowed or acceptable transmit power l. Other UHR capabilities’s upport indication (e.g., NPCA, DPS, IDC unavailability, etc. ) and their associated  parameters. m. Other TBD Info.

[0100] In some embodiments, Multi-STA Block ACK may be used as a MAP Polling ICR. The Multi-STA BA frame has the following format that allows for multiple “Per AID TID Info” fields to be included in the “BA Information” field. FIG. 5 shows an embodiment of such a MAP Polling ICR.

[0101] The embodiment of FIG. 5 includes two "Per AID TID Info" fields-one field conveys the requested resources to the Sharing AP, while another is designated for acknowledging the MAP Polling ICF frame sent by the Sharing AP.

[0102] Each “Per AID TID Info” field can be further broken down as follows: 1. AID TID Info Subfield: a. 11 bits to indicate the AID b. 1 bit for Ack Type c. 4 bits for TID

[0103] FIG. 6 shows an AID TID info sub-field format according to embodiments of the present disclosure. In this embodiment: · The polled AP may set the value of the AID 11 subfield to the value of the Sharing AP ID agreed during  the MAPC negotiation phase. · The value of the 1 bit ACK Type and 4 bits TID combined maybe used to indicate if this Per AID TID  Info is sent for Ack, BA, or other feedback / control info. · According to the Draft P802.11bn / D0.1, Ack Type = 0 &TID Value = 13 are repurposed to indicate the  intended use of the "Per AID TID Info" field: for conveying feedback. · In accordance with the present disclosure, it may be possible to repurpose the same values of Ack Type  = 0 &TID Value = 13 to indicate the intended use of the "Per AID TID Info" field: for conveying control info or feedback as shown in Table 6 and Table 7. Table 6. Table 7.

[0104] Other reserved values for the Ack type &TID value may also be repurposed for carrying the MAPC control or feedback information.

[0105] Referring now to FIG. 7 and continuing with the “Per AID TID Info” field, it may be further broken down as follows: 2. Each “Per AID TID Info” field can be further broken down as follows: – Block ACK Starting Sequence Control (reuse to indicate the info control) : · Fragment Number: Indicating the length of the BlockAck Bitmap. – Re-use to indicate the length of the feedback or control info included in the  BlockAck Bitmap field. · Starting Sequence Number: Used to indicate the starting sequence number – We can use the first 4 bits to indicate the type of control / feedback info. Table 8  shows examples of values for the type. · Value 0: IDC Unavailability feedback (Coex. ) · Value 1: Multi-AP coordination Info (MAP) . · Values 2-15: Reserved for other control / feedback info, e.g., link adaptation,  NPCA, dynamic power saving (DPS) , Buffer Status Report (BSR) , Low-latency traffic indication, intermediate FCS (IFCS) , Multi-Link adaptation, Multi-Link power saving reporting, Multi-Link IDC Unavailability reporting, …, etc. – The remaining 8 bits may be reserved or used to provide type-specific common  control information, such as a sub-type indication or an indication of the presence of certain parameters to be included in the BlockACK Bitmap field. · If the type field indicates Multi-AP coordination control / feedback info, we  may utilize 3 or 4 bits out of the remaining 8 bits to indicate the sub-type of the MAP coordination info, e.g., MAP Polling ICR, Co-BF response ICR, Co-SR ICR, Co-NPCA) . Table 9 shows examples of values for the sub-type. · Another way of the MAP Info sub-type indication is to utilize the first 3 or  4 bits of the Block ACK Bitmap as sub-type subfield or MAP control ID. – Block ACK Bitmap (reuse to include the control info parameters for the selected control info type) . Table 8. Table 9. · In some embodiments, another format would be to keep the Starting Sequence Number as reserved or carry  common control / feedback info related to the feedback / control info carried the BlockAck Bitmap. · Within the BlockAck Bitmap field, the first 4 bits may be used to indicate the type of control / feedback info or  control / feedback ID. For example: · Value 0: IDC Unavailability feedback (Coex. ) · Value 1: Multi-AP coordination Info (MAP) · Values 2-15: Reserved for other control info, e.g., link adaptation, NPCA, dynamic power  saving (DPS) , Buffer Status Report (BSR) , Low-latency traffic indication, intermediate FCS (IFCS) , …, etc. · If the type field indicates Multi-AP coordination control info, we may utilize the next 3 or 4  bits to indicate the sub-type of the MAP coordination info, e.g., MAP Polling ICR, Co-BF response ICR, Co-SR ICR, Co-NPCA) . · The remaining bits of the Block ACK Bitmap (reuse to include the control info parameters for  the selected control / feedback info type) .

[0106] In some embodiments, a new Public Action Frame for MAP polling ICR may be introduced. The new Public Action Frame value for MAP polling ICR by repurposing one of the reserved values in the public Action field (e.g., 54-59 or 61-255) may be as shown in Table 4, shown above.

[0107] Table 10 shows MAP Polling ICR Action field format values and their associated information. Table 10. MAP polling ICF action field format

[0108] The MAP Polling ICR field or Element conveys the same information as in the MAP Polling ICR frame.

[0109] Based on feedback from the polled APs, the Sharing AP may determine which AP (s) to share its full or partial TXOP with, along with the appropriate coordination scheme (s) .

[0110] The Sharing AP may then send an MAP announcement frame 112 (See FIG. 1) to the selected Shared APs, indicating the supported coordination scheme (s) and allocating the necessary resources / parameters for the coordination.

[0111] The Duration field of the MAP Announcement Frame may be set to provide short NAV protection, enabling Shared APs to respond promptly to the Announcement Frame (as required in Co-BF) or to trigger their associated non-AP STAs to switch to a different channel (as in scenarios like NPCA or Co-OFDMA) .

[0112] For Co-TDMA, within the MAP Announcement frame, the Sharing AP may indicate to each selected Shared AP one or more of following information: a. The allocated Shared TXOP duration. b. The start time of the allocated Shared TXOP duration. c. BW to be used during the allocated Shared TXOP. This may also indicate if the BW expansion is  allowed. d. If Co-TDMA will be supported for more than 2 Shared APs, TXOP return indicator is included. e. Other TBD Info.

[0113] For Co-OFDMA, within the MAP Announcement frame, the Sharing AP may indicate to each selected Shared AP one or more of following information: a. Assigned RU Allocation. b. Co-OFDMA Duration. c. Co-OFDMA Switching start time. d. Co-OFDMA trigger frame’s transmit power limit. e. Other TBD Info.

[0114] For Co-NPCA, within the MAP Announcement frame, the Sharing AP may indicate to each selected Shared AP one or more of following information: a. NPCA Duration. b. NPCA Switching start time. c. NPCA trigger frame’s transmit power limit. d. Other TBD Info.

[0115] The information included in the MAP Announcement frame for a Co-OFDMA or NPCA-triggered shared AP will then be transmitted to its associated non-AP STAs within a Co-OFDMA or NPCA trigger frame, which is sent after receiving the MAP Announcement frame.

[0116] For Co-SR, within the MAP Announcement frame, the Sharing AP may send an announcement frame to one selected Shared AP as a synchronization reference signal to support concurrent DL transmission and may indicate: a. The duration of the DL PPDU transmission. b. Transmission start time. c. Transmit power control parameters. d. Other TBD Info.

[0117] For Co-BF, within the MAP Announcement frame, the Sharing AP may send an announcement frame, as a Co-BF invitation, to one selected Shared AP as a Co-BF ICF and may indicate: a. The duration of the DL PPDU transmission. b. Transmission start time. c. Non-AP STAs to be served. d. An indication of whether the Sharing AP will serve Enhanced Multi-Link Single Radio (eMLSR) or  Dynamic Power Save (DPS) non-AP STAs within the TXOP. e. Sync. Follower / Sync. Reference Indicator. f. Precoder parameters (estimated during the Co-BF sounding phase) g. CFO precorrection (estimated during the Co-BF sounding phase) h. Other TBD Info.

[0118] Note: Co-SR and Co-BF may not be supported by the Sharing AP at the same time.

[0119] MAP Announcement frame may be of any appropriate trigger frame type, such a multi-user block acknowledgement request (MU-BAR) trigger frame (e.g., by setting the Trigger Type subfield value to ‘2’ ) , as a multi-user request-to-send (MU-RTS) trigger frame (e.g., by setting the Trigger Type subfield value to ‘3’ ) , a new type trigger frame (for example, by setting the trigger type subfield value to one of the reserved values, e.g., ‘9-15’ ) , or a buffer status report poll (BSRP) trigger frame (Preferred) (e.g., by setting the Trigger Type subfield value to ‘4’ ) .

[0120] The Buffer Status Report Poll (BSRP) trigger frame is a strong candidate for this Announcement frame. The Guard Interval (GI) and UHR-LTF Type field of the Common Info field of the BSRP can take any value from 0 to 2 to represent the respective Guard Interval and UHR-LTF Type. Alternatively, these fields may be set to a value of 3 to indicate that the frame is a BSRP non-trigger-based frame (BSRP NTB) .

[0121] For instance, if the MAP Announcement format follows the buffer status report poll (BSRP) trigger frame (e.g., by setting the Trigger Type subfield value to ‘4’ ) , the shared AP (s) will send Multi-STA BA as MAPC scheme-specific ICR (if needed) .

[0122] MAPC scheme-specific ICR may be needed when Co-BF, Co-OFDMA, Co-NPCA are selected.

[0123] To allow multiple shared APs to respond simultaneously to the MAP Announcement frame (if needed) , the Sharing AP may assign different RU allocations to each shared AP. This enables the shared APs to transmit their TB UL-PPDUs (e.g., MAP-specific ICR) concurrently.

[0124] The assigned RU allocation for each polled AP may be specified in the RU Allocation subfield of its UHR Variant User Info field, identified by its assigned AP ID in the AID 12 subfield.

[0125] Another way to allow multiple shared APs to respond simultaneously to the MAP Announcement frame (if needed) , the Sharing AP may set a transmit power limit to each shared AP, following the same concept of Co-SR. This enables the shared APs to transmit their TB UL-PPDUs (e.g., MAP-specific ICR) concurrently, while managing the OBSS interference.

[0126] We also propose enhancing the BSRP trigger frame by adding an Extended User Info field dedicated to ICF-type-specific Common information. This Extended Special User Info field is formatted as shown in FIG. 8.

[0127] Referring to FIG. 8: a. AID 12: This is the STA ID or an assigned Shared AP ID during the MAPC negotiation phase. b. Type: This field may be used to specify the type of user-specific control info, including options like  MAP Polling ICF, MAP Announcement, Coordinated Beamforming (Co-BF) invite or ICF, Coordinated Spatial Reuse (Co-SR) invite or ICF, Co-BF or Co-SR synchronization trigger, Coordinated Orthogonal Frequency Division Multiple Access (Co-OFDMA) invite or ICF, Coordinated TDMA (Co-TDMA) invite or ICF, Coordinated Restricted Target Wake Time (Co-r-TWT) , In-device Coexistence (IDC) , Dynamic Sub-Band Operation (DSO) , Non-primary Channel Access (NPCA) , Dynamic Power Save (DPS) , and other types to be determined (TBD) . c. When the type-specific control info parameters exceed the length of the User Info field, it may be  possible to utilize one bit in the field to indicate another extended User Info field is present.

[0128] For the MAP Announcement case, the main objective of the Extended User Info field may be to carry the User / Shared AP-specific Info for the supported MAPC scheme and the TXOP to be shared with it, e.g., supported MAPC scheme, supported MAPC scheme-specific parameters, like duration, bandwidth, …, etc. The format of the Extended User Info field can be as shown in the embodiment FIG. 9.

[0129] Introducing a new Public Action Frame for MAP Announcement may also be considered. a. In some embodiments, a new Public Action Frame value for MAP polling ICF by repurposing one of the  reserved values in the public Action field (e.g., 54-59 or 61-255) as shown in Table 4 above and in Table 11. Table 11. MAP polling ICF action field format

[0130] The MAP Announcement Parameters field or Element conveys the same information as in the MAP Announcement frame.

[0131] MAP Scheme-specific ICR Frame: a. Some MAPC schemes, e.g., Co-BF, may require from the Shared AP (s) to respond promptly to the  Announcement Frame to indicate whether it accepts or decline this Co-BF invitation, and declare, in case the acceptance, the non-AP STAs it plans to serve using Co-BF, Sync. Follower / Sync. Reference Indicator, CFO precorrection (estimated during the Co-BF sounding phase) , an indication of whether the Shared AP will serve eMLSR or DPS non-AP STAs within the TXOP, Precoder parameters (estimated during the Co-BF sounding phase) , and other TBD Info. b. The Shared AP (s) may need to trigger their associated non-AP STAs to switch to a different RU or  channel as in scenarios like Co-OFDMA or NPCA, respectively. c. In case of Co-OFDMA, within this trigger frame, the Shared AP may indicate to its associated non-AP  STAs, new assigned RU allocation, switching start time, Co-OFDMA duration, switching enabled or disabled, …, and / or other TBD Info. d. In case of Co-NPCA, within this trigger frame, the Shared AP may indicate to its associated non-AP  STAs if NPCA switching enabled or disabled NPCA switching start time, NPCA duration, …, and / or other TBD Info. e. In case of the MAP scheme-specific ICR frame is a response to be transmitted to the Sharing AP, the  frame format can be Multi-STA BA frame or a new public Action frame. f. In case of the MAP scheme-specific ICR frame is a response to be transmitted to the Sharing AP and  also a trigger for the Shared AP’s associated non-AP, the frame can be Multi-STA BA frame. g. In case of the MAP scheme-specific ICR frame used as a trigger for the Shared AP’s associated non-AP,  the frame can be of any appropriate trigger frame type, such a multi-user block acknowledgement request (MU-BAR) trigger frame (e.g., by setting the Trigger Type subfield value to ‘2’ ) , as a multi-user request-to-send (MU-RTS) trigger frame (e.g., by setting the Trigger Type subfield value to ‘3’ ) , a new type trigger frame (for example, by setting the trigger type subfield value to one of the reserved values, e.g., ‘9-15’ ) , or a buffer status report poll (BSRP) trigger frame (Preferred) (e.g., by setting the Trigger Type subfield value to ‘4’ ) . The Buffer Status Report Poll (BSRP) trigger frame is a strong candidate. The Guard Interval (GI) and UHR-LTF Type field of the Common Info field of the BSRP can take any value from 0 to 2 to represent the respective Guard Interval and UHR-LTF Type. Alternatively, these fields may be set to a value of 3 to indicate that the frame is a BSRP non-trigger-based frame (BSRP NTB) .

[0132] Examples for the Unified MAPC Transmission Phase: a. Using the proposed Unified MAPC Transmission Framework, any combinations of the multi-AP  coordination schemes may be supported at the same shared TXOP. b. Co-SR and Co-BF cannot be supported concurrently at the same time, but they can be supported at  different time instances within a single TXOP when the TXOP duration is sufficient. c. The Sharing AP may coordinate with a shared AP using more than one MAPC scheme within a single  TXOP. For example, the Sharing AP may use Co-BF or Co-SR for a certain duration and then assign the remaining time to the shared AP using Co-TDMA. d. Example 1: Referring to FIG. 10, the Sharing AP1 100 is coordinating with Shared AP2 102 using Co- TDMA, while coordinating with Shared AP3 104 using Co-OFDMA. Both Co-TDMA and Co-OFDMA are carried out over different RU Allocations. e. Example 2: Referring to FIG. 11, the Sharing AP1 100 is splitting its TXOP duration by coordinating  with Shared AP2 102 using Co-SR in the first part, while assigning the remaining TXOP duration to the Shared AP3 104 using Co-TDMA. f. Example 3: Referring to FIG. 12, the Sharing AP1 100 is splitting its TXOP duration by coordinating  with Shared AP2 102 using Co-BF in the first part, while assigning the remaining TXOP duration to the Shared AP3 104 using Co-TDMA. g. Note that: in examples 2 and 3, the Sharing AP 100 may allow more shared APs to participate in this  MAP coordinated transmission by supporting Co-OFDMA. For instance, it may coordinate with Shared AP4 using Co-OFDMA.

[0133] Embodiments of the present disclosure provide a method for dynamic selection of MAPC schemes within a single TXOP that best align with the Shared AP transmission needs during the obtained TXOP. At the same time, the present disclosure considers the varying needs of Shared AP (s) within the MAPC group. Advantageously, this enhances resource allocation and improves throughput based on real-time conditions.

[0134] Embodiments of the present disclosure provides a method that supports multiple MAPC schemes within a single TXOP. Advantageously, this increases flexibility and addresses diverse AP requirements simultaneously.

[0135] Embodiments of the present disclosure provide an adaptive framework that considers both the Sharing AP and Shared APs. Advantageously, this balances transmission requirements and improves efficiency across all APs.

[0136] Embodiments of the present disclosure allow for scalability for more APs and STAs without compromising performance.

[0137] Embodiments of the present disclosure may be implemented using electronics hardware, software, or a combination thereof. In some embodiments, the invention may be implemented by one or multiple computer processors executing program instructions stored in memory. In some embodiments, the invention may be 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.

[0138] 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.

[0139] 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.

[0140] 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.

[0141] 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 may include 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.

[0142] The word “a” or “an” when used in conjunction with the term “comprising” or “including” in the claims and / or the specification may mean “one” , but it is also consistent with the meaning of “one or more” , “at least one” , and “one or more than one” unless the content clearly dictates otherwise. Similarly, the word “another” may mean at least a second or more unless the content clearly dictates otherwise. The phrase "at least one" means one or more, and "aplurality of" means two or more. In addition, "and / or" describes an association relationship of associated objects, and indicates that there may be three relationships. For example, A and / or B may indicate cases including “only A” , “both A and B” , and “only B” , where A and B may be singular or plural. The character " / " generally indicates that the associated objects are in an OR relationship. "At least one of the following items" or a similar expression thereof refers to any combination of these items, including any combination of a single item or a plurality of items. For example, “at least one of a, b, or c” may represent “a” , “b” , “c” , “aand b” , “aand c” , “b and c” , or “a, b and c” , where a, b, and c may be a single or multiple form.

[0143] The terms “coupled” , “coupling” or “connected” as used herein can have several different meanings depending on the context in which these terms are used. For example, as used herein, the terms coupled, coupling, or connected can indicate that two elements or devices are directly connected to one another or connected to one another through one or more intermediate elements or devices via an electronic element depending on the particular context. The term “and / or” herein when used in association with a list of items means any one or more of the items comprising that list.

[0144] Although a combination of features is shown in the illustrated embodiments, not all of them need to be combined to realize the benefits of various embodiments of this disclosure. In other words, a system or method designed according to an embodiment of this disclosure will not necessarily include all features shown in any one of the Figures or all portions schematically shown in the Figures. Moreover, selected features of one example embodiment may be combined with selected features of other example embodiments.

[0145] 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

1.A method, comprising:at a first access point (AP) , the first AP having a transmission opportunity (TxOP) , the first AP being a sharing AP:sending a polling initial control frame (ICF) to a group of additional APs to poll the group of additional APs regarding an availability of the group of additional APs to participate in a multi access point coordination (MAPC) transmission phase, the polling ICF including:a bandwidth field identifying a bandwidth available during the TxOP;a number of non-AP STAs the sharing AP plans to serve within the TXOP;an indication of whether the Sharing AP will serve Enhanced Multi-Link Single Radio (eMLSR) or Dynamic Power Save (DPS) non-AP STAs within the TXOP;a maximum allowed transmission power; anda duration field defining at least one of:a duration of the TxOP; anda portion of the duration of the TxOP attributed to the sharing AP; andreceiving, from a second AP, a polling initial control response frame (ICRF) , the second AP being an additional AP of the group of additional APs that is available to participate in the MAPC transmission phase, the polling ICRF having at least one of:an availability field set to indicate that the second AP is available to participate in the MAPC transmission phase;a requested duration field defining a duration needed by the second AP;a requested bandwidth field defining a bandwidth needed by the second AP;a low-delay field set to indicate low-latency traffic or not;a buffered data expiry field defining a lifetime of buffered data;a preferred multi-AP (MAP) coordination scheme;a minimum allowed or acceptable transmit power;an indication of whether the Shared AP will serve Enhanced Multi-Link Single Radio (eMLSR) or Dynamic Power Save (DPS) non-AP STAs within the TXOP; anda number of stations (STAs) to be served.2.The method of claim 1, wherein the polling ICF includes a coordination field, the coordination field identifying a Multi-AP coordination scheme preferred by the sharing AP for the TxOP.3.The method of claim 1 or claim 2, wherein the duration field defines Network Allocation Vector (NAV) protection parameters that define the time allotted for the additional APs of the group of additional APs to reply to the polling ICF.4.The method of any one of claims 1 to 3, wherein the polling ICF has a trigger type subfield having a value set to correspond to a Buffer Status Report Poll (BSRP) trigger frame variant.5.The method of claim 4, wherein the polling ICF has a Guard Interval (GI) and a High Efficiency (HE)  / Ultra High Reliability (UHR) Long Training Field (LTF) type sub-field (GI and HE / UHR-LTF type sub-field) , the GI and HE / UHR-LFT type sub-field having a value indicating that a Physical Layer Protocol Data Unit (PPDU) to be received in response to the polling ICF is to be in a non-High Throughput (non-HT) format and contain a Multi-station (Multi-STA) Block Acknowledgement (ACK) .6.The method of any one of claims 1 to 5, wherein the polling ICF is a Public Action Frame.7.The method of any one of claims 1 to 6, wherein the polling ICRF has 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 to the sharing AP that the second AP acknowledges receiving the polling ICF; anda second AID TID Info field configured to indicate, to the sharing AP, that the second AP is available to participate in the MAPC transmission phase; andrequirements of the second AP for the second AP to participate in the MAPC transmission phase.8.The method of claim 7, wherein the first AID TID Info field includes a 16-bit AID TID Info field having a value that indicates to the sharing AP that the second AP is available to participate in the MAPC transmission phase.9.The method of claim 7, wherein the second AID TID Info field includes a 16-bit AID TID Info field having:an 11-bit AID identifying the sharing AP;a 1-bit ACK Type sub-field; anda 4-bit TID sub-field, the 1-bit ACK Type sub-field and the 4-bit TID sub-field having values that together indicate that the second AID TID Info field having a value that indicates to the sharing AP that the second AP is available to participate in the MAPC transmission phase and includes the requirements of the second AP for the second AP to participate in the MAPC transmission phase.10.The method of claim 9, wherein the 1-bit ACK Type sub-field has a value of 0 and the 4-bit TID sub-field has a value of 13.11.The method of claim 9, wherein the second AID TID Info field includes a Block ACK Starting Sequence Control sub-field and a Block ACK bitmap sub-field.12.The method of claim 11, wherein the Block ACK Starting Sequence Control sub-field includes:a fragment number sub-field indicating a length of a Block Ack Bitmap configured to carry one or more control or feedback parameters; anda Starting Sequence Number sub-field that can be repurposed to include a Type sub-field; and a Type-Specific Common Control Info subfield.13.The method of claim 11, wherein the Block ACK Starting Sequence Control sub-field includes a Starting Sequence Number sub-field that has:a Sub-Type sub-field within the Type-Specific Common Control Info subfield, the Type sub-field having a value indicating that the second PER AID TID Info field includes the MAP Coordination control or feedback, the Sub-Type sub-field having a value indicating that the Block ACK bitmap sub-field includes the MAP Polling ICR parameters, e.g., the availability and requirements of the second AP for the second AP to participate in the MAPC transmission phase.14.The method of claim 12, wherein the Block ACK bitmap sub-field includes the availability indication (e.g., accept or decline the MAPC invitation) and the requirements of the second AP for the second AP to participate in the MAPC transmission phase.15.The method of any one of claims 1 to 14, further comprising, at the sharing AP:determining that the second AP can share the TxOP with the sharing AP; andsending, to the second AP, a MAP announcement frame that:indicates to the second AP at least one supported coordination scheme; anddefines the resources allocated to the second AP.16.The method of claim 15, wherein the MAP announcement frame is a Buffer Status Report Poll (BSRP) frame having:a 12-bit AID field identifying the shared AP, the shared AP being the second AP;a 4-bit Type field indicating the BSPR frame is a MAP announcement frame;a 3-bit field identifying the at least one supported coordination scheme; anda 21-bit field defining parameter of the at least one supported coordination scheme.17.The method of claim 16, the duration field defines NAV protection for the second AP, the NAV protection to define a time period during which the second AP can reply to the MAP announcement frame or during which the second AP can trigger associated non-AP stations to switch to a different channel.18.The method of claim 16, wherein the 21-bit field indicates, to the second AP, at least one of:an allocated shared TxOP duration;a start time of the allocated shared TxOP duration;a TxOP return indicator; anda bandwidth to be used during the allocated shared TxOP duration.19.The method of claim 17, wherein the 21-bit field indicates, to the second AP, at least one of:a duration of a downlink (DL) Physical Layer Protocol Data Unit (PPDU) ;a transmission start time; andtransmit power control parameters.20.The method of claim 16, wherein the 21-bit field indicates, to the second AP, at least one of:an assigned RU Allocation;Co-OFDMA Duration;Co-OFDMA Switching start time; andCo-OFDMA trigger frame’s transmit power limit.21.The method of claim 16, wherein the 21-bit field indicates, to the second AP, at least one of:NPCA Duration;NPCA Switching start time; andNPCA trigger frame’s transmit power limit.22.The method of claim 16, wherein the 21-bit field indicates, to the second AP, at least one of:a duration of a downlink (DL) Physical Layer Protocol Data Unit (PPDU) ;a transmission start time;Non-AP STAs to be served;an indication of whether the Sharing AP will serve Enhanced Multi-Link Single Radio (eMLSR) or Dynamic Power Save (DPS) non-AP STAs within the TXOP;Sync. Follower / Sync. Reference Indicator;Precoder parameters (estimated during the Co-BF sounding phase) ; andCFO precorrection (estimated during the Co-BF sounding phase) .23.A method, comprising:at a first access point (AP) :receiving, from a second AP, a polling initial control frame (ICF) , the second AP being a sharing AP, the sharing AP having a transmission opportunity (TxOP) , the polling ICF having associated thereto a multi access point coordination (MAPC) transmission phase, the polling ICF including:a bandwidth field identifying a bandwidth available during the TxOP;a number of non-AP STAs the sharing AP plans to serve within the TXOP;an indication of whether the Sharing AP will serve Enhanced Multi-Link Single Radio (eMLSR) or Dynamic Power Save (DPS) non-AP STAs within the TXOP;a maximum allowed transmission power; anda duration field defining at least one of:a duration of the TxOP; anda portion of the duration of the TxOP attributed to the sharing AP; andsending, to the sharing AP, a polling initial control response frame (ICRF) to indicate to the sharing AP that the first AP is available to participate in the MAPC transmission phase, the polling ICRF having at least one of:an availability field set to indicate that the first AP is available to participate in the MAPC transmission phase;a requested duration field defining a duration needed by the first AP;a requested bandwidth field defining a bandwidth needed by the first AP;a low-delay field set to indicate low-latency traffic or not;a buffered data expiry field defining a lifetime of buffered data;a preferred multi-AP (MAP) coordination scheme;a minimum allowed or acceptable transmit power;an indication of whether the Shared AP will serve Enhanced Multi-Link Single Radio (eMLSR) or Dynamic Power Save (DPS) non-AP STAs within the TXOP; anda number of stations (STAs) to be served.24.The method of claim 23, wherein the polling ICF includes a coordination field, the coordination field identifying a Multi-AP coordination scheme preferred by the sharing AP for the TxOP.25.The method of claim 23 or claim 24, wherein the duration field defines Network Allocation Vector (NAV) protection parameters that define the time allotted for the additional APs of the group of additional APs to reply to the polling ICF.26.The method of any one of claim 23 to 25, wherein the polling ICF has a trigger type subfield having a value set to correspond to a Buffer Status Report Poll (BSRP) trigger frame variant.27.The method of claim 26, wherein the polling ICF has a Guard Interval (GI) and a High Efficiency (HE)  / Ultra High Reliability (UHR) Long Training Field (LTF) type sub-field (GI and HE / UHR-LTF type sub-field) , the GI and HE / UHR-LFT type sub-field having a value indicating that a Physical Layer Protocol Data Unit (PPDU) to be received in response to the polling ICF is to be in a non-High Throughput (non-HT) format and contain a Multi-station (Multi-STA) Block Acknowledgement (ACK) .28.The method of any one of claims 23 to 27, wherein the polling ICF is a Public Action Frame.29.The method of claims 23 to 28, wherein the polling ICRF has 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 to the sharing AP that the first AP acknowledges receiving the polling ICF; anda second AID TID Info field configured to indicate, to the sharing AP, that the first AP is available to participate in the MAPC transmission phase; andrequirements of the first AP for the first AP to participate in the MAPC transmission phase.30.The method of claim 29, wherein the first AID TID Info field includes a 16-bit AID TID Info field having a value that indicates to the sharing AP that the first AP is available to participate in the MAPC transmission phase.31.The method of claim 29, wherein the second AID TID Info field includes a 16-bit AID TID Info field having:an 11-bit AID identifying the sharing AP;a 1-bit ACK Type sub-field; anda 4-bit TID sub-field, the 1-bit ACK Type sub-field and the 4-bit TID sub-field having values that together indicate that the second AID TID Info field having a value that indicates to the sharing AP that the first AP is available to participate in the MAPC transmission phase and includes the requirements of the first AP for the first AP to participate in the MAPC transmission phase.32.The method of claim 31, wherein the 1-bit ACK Type sub-field has a value of 0 and the 4-bit TID sub-field has a value of 13.33.The method of claim 31, wherein the second AID TID Info field includes a Block ACK Starting Sequence Control sub-field and a Block ACK bitmap sub-field.34.The method of claim 33, wherein the Block ACK Starting Sequence Control sub-field includes:a fragment number sub-field indicating a length of a Block Ack Bitmap configured to carry one or more control or feedback parameters; anda Starting Sequence Number sub-field that can be repurposed to include a Type sub-field; and a Type-Specific Common Control Info subfield.35.The method of claim 33, wherein the Block ACK Starting Sequence Control sub-field includes a Starting Sequence Number sub-field that has:a Sub-Type sub-field within the Type-Specific Common Control Info subfield, the Type sub-field having a value indicating that the second PER AID TID Info field includes the MAP Coordination control or feedback, the Sub-Type sub-field having a value indicating that the Block ACK bitmap sub-field includes the MAP Polling ICR parameters, e.g., the availability and requirements of the first AP for the first AP to participate in the MAPC transmission phase.36.The method of claim 34, wherein the Block ACK bitmap sub-field includes the availability indication (e.g., accept or decline the MAPC invitation) and the requirements of the first AP for the first AP to participate in the MAPC transmission phase.37.The method of any one of claims 23 to 36, further comprising, at the first AP:receiving, from the sharing AP, a MAP announcement frame that:indicates to the first AP at least one supported coordination scheme; anddefines the resources allocated to the first AP.38.The method of claim 37, wherein the MAP announcement frame is a Buffer Status Report Poll (BSRP) frame having:a 12-bit AID field identifying the shared AP, the shared AP being the first AP;a 4-bit Type field indicating the BSPR frame is a MAP announcement frame;a 3-bit field identifying the at least one supported coordination scheme; anda 21-bit field defining parameter of the at least one supported coordination scheme.39.The method of claim 38, the duration field defines NAV protection for the first AP, the NAV protection to define a time period during which the first AP can reply to the MAP announcement frame or during which the first AP can trigger associated non-AP stations to switch to a different channel.40.The method of claim 38, wherein the 21-bit field indicates, to the first AP, at least one of:an allocated shared TxOP duration;a start time of the allocated shared TxOP duration;a TxOP return indicator; anda bandwidth to be used during the allocated shared TxOP duration.41.The method of claim 39, wherein the 21-bit field indicates, to the first AP, at least one of:a duration of a downlink (DL) Physical Layer Protocol Data Unit (PPDU) ;a transmission start time; andtransmit power control parameters.42.The method of claim 38, wherein the 21-bit field indicates, to the first AP, at least one of:an assigned RU Allocation;Co-OFDMA Duration;Co-OFDMA Switching start time; andCo-OFDMA trigger frame’s transmit power limit.43.The method of claim 38, wherein the 21-bit field indicates, to the first AP, at least one of:NPCA Duration;NPCA Switching start time; andNPCA trigger frame’s transmit power limit.44.The method of claim 38, wherein the 21-bit field indicates, to the first AP, at least one of:a duration of a downlink (DL) Physical Layer Protocol Data Unit (PPDU) ;a transmission start time;Non-AP STAs to be served;an indication of whether the Sharing AP will serve Enhanced Multi-Link Single Radio (eMLSR) or Dynamic Power Save (DPS) non-AP STAs within the TXOP;Sync. Follower / Sync. Reference Indicator;Precoder parameters (estimated during the Co-BF sounding phase) ; andCFO precorrection (estimated during the Co-BF sounding phase) .

Images