Resource need collection in a multi-ap context

Abstract

Multi-Access Point, MAP, technology collaboration between neighbouring APs is disclosed to share resources of a coordinating (sharing) AP with other coordinated (shared) APs during MAP coordination ba

Description

FIELD OF THE INVENTION The present invention generally relates to wireless communications and more specifically to coordination between basic service sets (BSSs) in multi-AP operations. BACKGROUND OF THE INVENTION Wireless communication networks are widely deployed to provide various communication services such as voice, video, packet data, messaging, broadcast, etc. These wireless networks may be multiple-access networks capable of supporting multiple users by sharing the available network resources. Examples of such multiple-access networks include Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, Orthogonal FDMA (OFDMA) networks, and Single-Carrier FDMA (SC-FDMA) networks. In dense multiple AP networks, co-channel interference between BSSs (Basic Service Sets) appears detrimental to network efficiency. Coordination between the APs may be profitable to improve the utilization of the limited radio resources. The IEEE (Institute of Electrical and Electronics Engineers - RTM) 802.11 be draft standard Task Group addresses a so-called Multi-Access Point (Multi-AP or MAP) technology which aims at providing some collaboration between neighbouring access points (APs) managing separate BSSs in order to have a more efficient utilization of time, frequency and spatial resources available. This is particularly important when the neighbouring APs operate over the same selected communication channel (or over channels sufficient close in frequency to generate interferences) in which interferences may occur. In that case, the BSSs are referred to as overlapping BSSs or OBSSs For example, in a dense deployment scenario where neighbouring BSSs corresponding to two or more APs overlap one each other, if one AP belonging to a MAP coordinated group (or “MAP group”, i.e., a MAP coordination set of APs) has an R-TWT (Restricted-Target Wake Time) schedule for which the corresponding scheduled STAs fall in a geographic area that overlaps a neighbour BSS (of the same MAP group), then the R-TWT scheduled STAs may face interferences with neighbouring BSS's operation. MAP mechanisms should allow two or more neighbouring APs to share resources in terms of frequency and / or time and, in this way, they should prevent interferences from occurring. The MAP topic is now addressed back in the UHR Study Group (Ultra High Reliability), a study group in charge of defining the scope of the successor of the 802.11 be Task Group, namely the 802.11 bn Task group. The scope of the MAP topic is extended to optimized coordination, not only regarding shared transmissions but also regarding alternative mechanisms forOBSS Interference reduction. In other words, MAP coordination becomes one of the emerging features for interference management in WLAN networks: multiple APs can cooperate together to enhance the performance of the network by smartly managing the interference due to OBSSs. Recent publications of the 802.11 bn group seek to coordinate MAP transmissions by sharing the medium in between the BSSs of the MAP group. An AP obtaining a transmission opportunity (TXOP) may allocate a portion of its TXOP to other APs. The sharing of the TXOP may be time-based or frequency-based. Most of the contributions focus on the time-based sharing, so called C-TDMA for “Coordinated TDMA”. In C-TDMA scenarios, an AP obtaining a TXOP (the “sharing AP”) occupies the medium during a part of the TXOP duration for its own BSS while another part of the TXOP is shared with other AP(s) (the “shared AP(s)” or “coordinated AP(s)”). Some publications also propose to coordinate MAP transmissions along with the R-TWT procedure, in order to obtain service periods offering OBSS interference avoidance and transmission sharing in between the BSSs of the MAP group. R-TWT and more generally the TWT procedures are highly advantageous to protect some periods of time (known as Service Periods) to prevent unexpected stations to access the medium during the service periods. Consequently, the MAP coordination is willing to optimize operations during the R-TWT service period to limit the issues related to OBSS. Other publications more generally describe the Multi APs coordination in successive phases: a discovery phase in which each AP discovers its surrounding APs, a group creation phase where the nearby APs willing to cooperate setup a MAP group and finally the MAP coordinated transmission where a sharing AP subleases a part of its TXOP to one or more shared / coordinated APs belonging to the same MAP group. The known publications fail to explain how an efficient MAP scheduling can be obtained, in particular regarding the bandwidth and time distribution between the sharing and shared APs in case of C-TDMA. An efficient resource allocation between the coordinated APs however appears crucial not to waste bandwidth, hence to reduce the overall efficiency of the MAP coordination mechanism. Improved coordination between different APs and their BSSs is therefore sought, with a view of the next 802.11 bn standard. SUMMARY OF INVENTION It is a broad objective of the present invention to overcome some of the foregoing concerns. The inventors have noticed that a need exists for the APs to report their resource needs - including the needs of their BSS - to other APs for better MAP cooperation. Indeed, thanks to those reported resource needs, an AP may more efficiently allocate appropriate resources to another BSS or AP. New ways to report resource needs in a Multi-APs system are proposed in the present disclosure. Embodiments provide a communication method in a wireless network, comprising at a first access point, AP, managing a first basic service set, BSS: receiving, from a second AP managing a second BSS, a Multi-AP, MAP, Resource Report frame reporting resource needs for the second BSS. Of course, multiple MAP Resource Report frames can be received from multiple APs, e.g., APs belonging to a MAP Group. In an implementation, the MAP Resource frame may be different from a Buffer Status Report Poll (BSR) frame. Correspondingly, a communication method is also proposed in a wireless network, that comprises at a second access point, AP, managing a second basic service set, BSS: sending, to a first AP managing a first BSS, a Multi-AP, MAP, Resource Report frame reporting resource needs for the second BSS. An AP may be a soft-AP of a BSS acting as a P2P Group Owner of a P2P Group (the BSS). An AP may also be an NSTR mobile AP such as described by draft IEEE P802.11 be(RTM) / D5.0 of November 2023. Optional features are defined below with reference to methods, while they can be transposed into device features. Thanks to the obtained MAP Resource Reports such as BSRs, the first AP may provide appropriate resources to other BSSs. In some embodiments, the MAP Resource Report frame is a BlockAck frame (i.e., an IEEE802.11 Medium Access Control frame having a Type value and Subtype value set respectively to ‘01’ and ‘1001’ in a Frame Control field) comprising an entry in a BA Information field, which entry reports the resource needs for the second BSS. Reusing an existing format to provide the MAP Resource reporting improves efficiency in implementing the 802.11 standards. The entry may be a Multi-STA BlockAck variant entry (BA Type subfield set to 11 in in BA Control field). In embodiments, the BA Information subfield comprises at least one additional entry which acknowledges at least one frame received from a non-AP station of the second BSS. The MAP Resource Report frame thus has multiple roles, thereby reducing signalling costs. In embodiments, the entry in the BA Information field comprises an AID TID Info subfield followed by an extension field, wherein the AID TID Info subfield is made of an AID11 subfield, an Ack Type subfield and a TID subfield, and the extension field includes the report of resource needs for the second BSS. This advantageously follows the existing Multi-STA BlockAck variant, thereby easing the implementation of the 802.11 standards. In embodiments, the Ack Type and TID subfields are set to respective values signalling the extension field includes a report of resource needs for a BSS. In embodiments, the BlockAck frame comprises a padding field located before the entry reporting the resource needs for the second BSS. This ensures the second AP has enough time to prepare the MAP Resource reporting, in particular when it additionally gathers individual BSRs from its associated stations before preparing the MAP Resource reporting. In embodiments, the BlockAck frame ends a transmission slot allocated by the first AP to the second AP in the MAP Resource Report frame. An efficient organized reporting of MAP Resource needs by multiple coordinated APs can thus be obtained. In embodiments, the method further comprises sending a MAP Trigger frame allocating resources to the second BSS (AP) in a gained TXOP, based on the received MAP Resource Report frame (e.g., BSR frame). An allocation may be performed using a Trigger frame for MAP cooperation as described above. Correspondingly, the second AP may then receive, from the first AP, a MAP Trigger frame allocating resources to the second BSS (AP) in a TXOP gained by the first AP. Also, the reception of MAP Resource Report frames may help the first AP to decide to create a MAP Group. Hence, the method may further comprise, responsive to receiving the MAP Resource Report frame, setting a MAP Group with at least the second AP. In some embodiments, the MAP Resource Report frame is received in response to a MAP Resource Report Request frame previously sent by the first AP to allocate resources to a station (e.g., second AP) of the second BSS and soliciting a MAP Resource Report response in the allocated resources. Correspondingly, sending the MAP Resource Report frame (at the second AP) is responsive to receiving, from the first AP, a MAP Resource Report Request frame allocating resources to the second AP and soliciting a MAP Resource Report response in the allocated resources. The MAP Resource Report Request frame may be one from a Buffer Status Report Poll, BSRP, Trigger frame (i.e., a Trigger frame having its Trigger type in the Common Info field set to 4), a Multi-User Request-To-Send, MU-RTS, Trigger frame (i.e., a Trigger frame having its Trigger type in the Common Info field set to 3), and a Generic Advertisement Service, GAS, frame. These frames may have a User Info field that includes an AID subfield set to an AID of the second AP. In some embodiments, the MU-RTS or BSRP Trigger frame has an enabled Triggered TXOP Sharing (TXS) mode. Typically, the TXS Type subfield in the Common Info field is set to 1 or 2 or 3 to initiate TXS procedure wherein a scheduled STA can transmit MPDU(s) addressed to its associated AP (optionally, or addressed to another STA). This allows the MAP Resource Reporting from multiple coordinated APs to be efficiently organized. In specific embodiments, the MU-RTS or BSRP Trigger frame having an enabled TXS mode allocates a time portion of an obtained TXOP to the second AP, wherein the MAP Resource Report frame is sent to the first AP within the allocated portion. In more specific embodiments, the second AP polls non-AP stations of the second BSS within the allocated portion, to obtain resource needs from the polled non-AP stations. This provides network efficiency since the local gathering of BSRs as well as the MAP Resource reporting are concentrated within the same TXS slot. Of course, in variants, the second AP may spontaneously send the MAP Resource Report (e.g., BSR) frame. “Spontaneously” means that the sending is not linked to a request from the addressee of the sending, here the first AP. The “spontaneity” may however rely on detecting triggering events at the second AP, including receiving individual reports (e.g., BSRs) from their associated non-AP stations in the second BSS, and / or setting or updating a SCS (Stream Classification Service) or r-TWT agreement within the second BSS, and / or detecting an internal (to the second AP) trigger, e.g., critical data or a critical amount of (UL, DL or any) data in a transmission buffer or a Beacon frame to be transmitted. In some embodiments, the method may further comprise, responsive to receiving the MAP Resource Report Request frame, polling non-AP stations of the second BSS to obtain resource needs from the polled non-AP stations. Up-to-date resource needs can therefore be provided to the sharing AP. In particular, polling the non-AP stations of the second BSS may include sending a Buffer Status Report Poll, BSRP, Trigger frame to the non-AP stations on a resource allocated by the first AP to the second AP within the received MAP Resource Report Request frame, and receiving BSR frames from the non-AP stations in response to the BSRP Trigger frame. Such BSRP Trigger frames may allocate sub-resources within the allocated resource for the non-AP stations to send their own BSR frames. This approach takes advantage of the existing BSRP / BSR scheme for the polling within the MAP framework. In some embodiments, the MAP Resource Report frame acknowledges the BSR frames received from the non-AP stations. The MAP Resource Report frame thus has multiple roles, thereby reducing signalling costs. The MAP Resource Report frame may be one from a Buffer Status Report, BSR, frame, a Clear-To-Send, CTS, frame, a Beacon frame, a Generic Advertisement Service, GAS, frame, and a MAP Trigger frame allocating resources in a gained TXOP to the first BSS. Preference may be given to those frames different from the BSR one which is not scalable and does not allow the AP receiving the BSR to carefully schedule the resource distribution. This is due to the dependency of the bandwidth and duration for resource allocation to the transmission parameters and not only to queue sizes reported by a BSR. Furthermore, providing the MAP Resource Report within a MAP Trigger frame optimizes the use of the network because the same frame performs two operations at the same time: on one hand, it provides resource sharing to the first AP and, on the other hand, it already informs the first AP about the resource needs of the second AP so that further resource sharing by the first AP is accelerated. In some embodiments, the resource needs in the MAP Resource Report frame include a duration and optionally a bandwidth, e.g., when the bandwidth is predefined with the first AP or within the MAP Group. A conversion of queue size to duration and bandwidth may be implemented by the second AP in case it received queue sizes from its associated non-AP stations. Such conversion can be based on parameters used during previous communications within the second BSS, e.g., time slot durations, transmission parameters (SNR, transmission power, modulation and coding schemes). The bandwidth and duration information may then be used directly by the first AP to easily compare the resource needs received from various APs and to allocate resource efficiently according to their needs. In particular embodiments, the MAP Resource Report frame includes, in addition to a duration field and a bandwidth field, at least one from: a TID field indicating a TID corresponding to data having the highest priority from amongst data for which resources are needed, a Link ID field indicating a link on which the second AP is requesting resources from amongst multiple links shared with the first AP, a Channel ID field indicating a channel on which the second AP is requesting resources. This may merely indicate the primary channel of the second AP. The Bandwidth field may in this case define, together with the channel identified by the Channel ID, the channels on which the second AP is requesting resources, a Direction field indicating a direction of transmission of data forwhich resources are needed. The field may be set to UL, DL, Direct Link (DiL), any or a combination thereof, a Lifetime field indicating a validity duration of the resource needs. The field may be set to 0 or any reserved value to indicate permanent (or static) needs; otherwise set to a value mirroring the lifetime of the specified needs. In some embodiments, the resource needs in the MAP Resource Report frame correspond to needs for traffic meeting some requirements defined by the first AP, for example within the MAP Resource Report Request or through previous frame exchanges. As examples, requirements may be based on traffic types, such as UL, DL, DiL, specific TID, specific stations (e.g. EHT or UHR -compliant stations), delay bound, and so on. In some embodiments, the MAP Resource Report frame cumulates resource needs obtained by the second AP from multiple non-AP stations of the second BSS. “Cumulate” means that the report reports an amount of resource needs that covers the needs from multiple (“cumulates”) non-AP stations, for example by summing all their individual needs into a single cumulated need. Those individual needs may include only uplink (UL) transmission needs for a station, or may include both UL needs and P2P needs forthat station. In specific embodiments, the MAP Resource Report also cumulates own resource needs of the second AP for downlink transmission within the second BSS. This is to provide an overall view of the second BSS’s resource needs. In embodiments, the cumulated resource needs include a duration and a bandwidth of a summation of the obtained resource needs. In some embodiments, the method further comprises determining a resource allocation scheduling allocating resources to the non-AP stations of the second BSS based on the obtained resource needs, wherein the MAP Resource Report frame reports resource needs corresponding to the resource allocation scheduling. Performing a resource allocation scheduling in advance has multiple advantages, including providing a more precise estimate of the resource needs that actually allows all the individual needs to be fulfilled and also including having the scheduling already ready when an opportunity to transmit occurs. In specific embodiments, the resource allocation scheduling is further determined based on own resource needs of the second AP for downlink transmission within the second BSS. This is to provide an overall view of the second BSS’s resource needs. In other specific embodiments, the resource needs corresponding to the resource allocation scheduling include a duration and a bandwidth of the resource allocation scheduling. A conversion of queue size to duration and bandwidth may be implemented, which can be based on parameters used during previous communications within the second BSS, e.g., to have time slot durations, transmission parameters (SNR, transmission power, modulation and coding schemes). In some embodiments, resource needs obtained from a non-AP station include peer-to-peer, P2P, resource needs of this non-AP station for P2P communication. This ensures the second BSS can be provided with enough resources to allow P2P communication to be performed within it. In specific embodiments, the P2P resource needs are P2P resource needs in P2P transmission from the non-AP station. It means only the data transmitted by this (peer) non-AP station are counted. This allows double reporting of P2P resource needs to be avoided in case both peers of the P2P communication belong to the second BSS. In other specific embodiments, the P2P resource needs include P2P resource needs in both P2P directions to and from the non-AP station. This allows full reporting of P2P resource needs to be made in case one of the peers of the P2P communication does not belong to the second BSS. As an example of P2P resource needs reporting, a non-AP station belonging to a P2P Group may report a P2P activity duration calculated as the complementary time portion to a Notice of Absence signalled in a Beacon frame of the P2P Group. In some embodiments, the MAP Resource Report frame is transmitted over an anchor or management link set up between the first and second APs. Alternatively, it may be transmitted over a link on which resources are needed. In some embodiments, the MAP Resource Report frame includes a Buffer Status Report, BSR, frame. A conventional 802.11 BSR frame can be used. It is known as an 802.11 frame in which the Control ID subfield in a Control subfield within the A-Control subfield of the HE variant HT Control field is set to 3. The Control subfield is known as a BSR Control subfield. The Control Information subfield associated with the Control ID subfield in the BSR Control subfield then contains buffer status information. A new BSR frame can be defined as a new Control frame (an IEEE802.11 frame having Type value ‘01’ and e.g. Subtype value ‘1110’ in the Frame Control field of the MAC header) or an Extension frame (an IEEE802.11 frame having Type value ‘11 ’ and a Subtype value taken from ‘0010’-‘1111 ’ in the Frame Control field of the MAC header). Defining a new Control frame allows a new Control field (e.g., UHR Control field) to be defined that no longer has the 26-bit limitation of the conventional Control Information subfield resulting from the 32-bit limitation of the HT Control field. Hence the Control Information subfield may be of any desired length. In that case, the Control ID subfield in the new Control field may take any value, preferably any of the reserved values 7-14 to allow the conventional values 0-6 and 15 to be reused to the same purposes. In some embodiments, a Control Information field in a BSR Control field of the BSR frame includes one or more of: a Downlink Traffic Identifier, DL TID, subfield specifying the highest TID (hence most prioritized TID) corresponding to a DL queue size, a DL Queue Size subfield specifying a quantity of DL data to transmit by the second AP to non-AP stations of the second BSS, an Uplink, UL, TID subfield specifying the highest TID corresponding to an UL queue size, an UL Queue Size subfield specifying a quantity of UL data that non-AP stations of the second BSS intend to transmit to the second AP, a Direct Link, DiL, Queue Size subfield specifying a quantity of peer-to-peer data that non-AP stations of the second BSS intend to transmit to other non-AP stations (of the first and / or second and / or other BSSs). With such information, the first AP may more easily schedule subsequent coordinated transmission while preventing simultaneous UL and DL transmissions that could lead to interferences. In other embodiments, the BSR frame includes a plurality of BSR Control fields corresponding to buffer status information of a respective plurality of stations (non-AP and AP) of the second BSS, each BSR Control field including an identifier of the respective station, a Traffic Identifier, TID, subfield specifying the highest TID corresponding to a queue size of the respective station, and a Queue Size subfield specifying a quantity of data the respective station intends to transmit. In yet other embodiments, the BSR frame includes a plurality of BSR Control fields corresponding to buffer status information of a respective plurality of stations (non-AP and AP) of the second BSS, each BSR Control field including an identifier of the respective station, a Traffic Identifier, TID, subfield specifying the highest TID corresponding to a queue size of the respective station, a Bandwidth subfield specifying a maximum operable bandwidth and a Medium Time subfield specifying a requested medium time. In specific embodiments, each BSR Control field further includes a linkID field identifying a preferred link requested for the buffer status information. Other aspects of the disclosure propose a communication method in a wireless network, comprises at a station: transmitting a BlockAck frame comprising an entry in a BA Information field, which entry reports resource on station side. Preferably, the BlockAck frame is a Multi-STA BlockAck frame. The BlockAck frame (of the Multi-STA BlockAck variant type) is therefore reused for other purposes than mere block acknowledgment. Other aspects of the disclosure propose an IEEE 802.11 BlockAck frame to be sent by a transmitting station, the BlockAck frame comprising a BA Control field and a BA Information field, the BA Information field comprising one or more entries, one of the entries reporting resource needs at transmitting station’s side. In embodiments, the entry includes an AID field set to a non-zero identifier of an access point addressee of the IEEE 802.11 BlockAck frame. In embodiments, the entry includes an Ack Type subfield and a TID subfield, set to respective values to signal the entry includes a report of resource needs at the transmitting station’s side. In embodiments, one of the entries acknowledges communication within a Basic Service Set managed by the transmitting station. Correlatively, the invention also provides a wireless communication device comprising at least one microprocessor configured for carrying out any method as described above. Another aspect of the invention relates to a non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform any method as described above. At least parts of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium. Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible carrier medium may comprise a storage medium such as a hard disk drive, a magnetic tape device or a solid-state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal. BRIEF DESCRIPTION OF THE DRAWINGS Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which: Figure 1 illustrates an exemplary network environment in which embodiments of the present disclosure can be implemented; Figure 2a describes a conventional MU UL communication triggered by an AP; Figure 2b describes another exemplary trigger-based communication scenario with TXOP sharing soliciting UL PPDU; Figure 2c describes yet another exemplary trigger-based communication scenario with TXOP sharing soliciting UL PPDU and / or DiL transmission; Figure 3a illustrates the format of an 802.11 Trigger frame, as defined in the standards IEEE P802.1 IREVme D4.1 (hereinbelow, the “REVme / D4.1 standard”); Figure 3b illustrates a format of a HE variant User Info field in the Trigger frame of Figure 3a; Figures 3c and 3d illustrate formats of respectively the HE variant and the EHT variant of a Common Info field in the Trigger frame of Figure 3a; Figure 3e illustrates the various values available for the Trigger Type subfield in a conventional Common Info field; Figure 3f illustrates the various values available for the Triggered TXOP Sharing Mode subfield in a conventional Common Info field; Figure 4a illustrates, using flowcharts, exemplary steps, at a sharing AP MLD (or AP) and at one of coordinated AP MLDs (or APs), of resource sharing through the sending of a MAP Trigger frame according to some embodiments; Figure 4b illustrates, using flowcharts, exemplary steps, at a sharing AP MLD (or AP) and at one of coordinated AP MLDs (or APs), of collecting resource needs from coordinated APs through the sending of a MAP Resource Report frame; Figure 5 illustrates an exemplary MAP Parameters element to include a MAP Resource Report, according to embodiments; Figure 6 illustrates an exemplary Channel Usage element to include a MAP Resource Report, according to embodiments; Figure 7a illustrates a first example of frame exchange with MAP cooperation, implementing resource need collection, according to embodiments; Figure 7b illustrates a second example of frame exchange with MAP cooperation, implementing resource need collection, according to embodiments; Figure 7c illustrates a third example of frame exchange with MAP cooperation, implementing resource need collection, according to embodiments; Figure 7c1 illustrates a fourth example of frame exchange with MAP cooperation, implementing resource need collection, according to embodiments; Figure 8 illustrates a fifth example of frame exchange with MAP cooperation, implementing resource need collection, according to embodiments; Figure 9 illustrates some fields of a MAP BSRP Trigger frame to define requirements for requested MAP BSRs, according to embodiments; Figure 10a illustrates a first exemplary format of a MAP BSR, according to embodiments; Figure 10b illustrates a second exemplary format of a MAP BSR, according to embodiments; Figure 10c illustrates an exemplary format of MAP Resource Report, according to embodiments; Figure 11a shows a schematic representation a communication device in accordance with embodiments of the present invention; Figure 11b shows a schematic representation of a wireless communication device in accordance with embodiments of the present invention; Figure 12 illustrates an exemplary format for reporting MAP Resource needs, based on a Multi-STA Block Ack format, according to embodiments; and Figure 13 illustrates a sixth example of frame exchange with MAP cooperation, implementing resource need collection, according to embodiments. DETAILLED DESCRIPTION OF EMBODIMENTS The techniques described herein may be used for various broadband wireless communication systems, including communication systems that are based on an orthogonal multiplexing scheme. Examples of such communication systems include Spatial Division Multiple Access (SDMA) system, Time Division Multiple Access (TDMA) system, Orthogonal Frequency Division Multiple Access (OFDMA) system, and Single-Carrier Frequency Division Multiple Access (SC-FDMA) system. An SDMA system may utilize sufficiently different directions to simultaneously transmit data belonging to multiple user terminals, i.e. wireless devices or stations. A TDMA system may allow multiple user terminals to share the same frequency channel by dividing the transmission signal into different time slots or resource units, each time slot being assigned to different user terminal. An OFDMA system utilizes orthogonal frequency division multiplexing (OFDM), which is a modulation technique that partitions the overall system bandwidth into multiple orthogonal sub-carriers or resource units. These sub-carriers may also be called tones, bins, etc. With OFDM, each sub-carrier may be independently modulated with data. An SC-FDMA system may utilize interleaved FDMA (IFDMA) to transmit on sub-carriers that are distributed across the system bandwidth, localized FDMA (LFDMA) to transmit on a block of adjacent sub-carriers, or enhanced FDMA (EFDMA) to transmit on multiple blocks of adjacent sub-carriers. The teachings herein may be incorporated into (e.g., implemented within or performed by) a variety of apparatuses (e.g., stations). In some aspects, a wireless device or station implemented in accordance with the teachings herein may comprise an access point (so-called AP) or not (so-called non-AP station or STA). An AP may comprise, be implemented as, or known as a Node B, Radio Network Controller (“RNC”), evolved Node B (eNB), 5G Next generation base station (gNB), Base Station Controller (“BSC”), Base Transceiver Station (“BTS”), Base Station (“BS”), Transceiver Function (“TF”), Radio Router, Radio Transceiver, Basic Service Set (“BSS”), Extended Service Set (“ESS”), Radio Base Station (“RBS”), or some other terminology. A non-AP station may comprise, be implemented as, or known as a subscriber station, a subscriber unit, a mobile station (MS), a remote station, a remote terminal, a user terminal (UT), a user agent, a user device, user equipment (UE), a user station, or some other terminology. In some implementations, a STA may comprise a cellular telephone, a cordless telephone, a Session Initiation Protocol (“SIP”) phone, a wireless local loop (“WLL”) station, a personal digital assistant (“PDA”), a handheld device having wireless connection capability, or some other suitable processing device connected to a wireless modem. Accordingly, one or more aspects taught herein may be incorporated into a phone (e.g., a cellular phone or smart phone), a computer (e.g., a laptop), a tablet, a portable communication device, a portable computing device (e.g., a personal data assistant), an entertainment device (e.g., a music or video device, or a satellite radio), a global positioning system (GPS) device, or any other suitable device that is configured to communicate via a wireless or wired medium. In some aspects, the non-AP station may be a wireless node. Such wireless node may provide, for example, connectivity for or to a network (e.g., a wide area network such as the Internet or a cellular network) via a wired or wireless communication link. An AP manages a set of STAs (registered to it or associated with it) that together organize their accesses to the wireless medium for communication purposes. The STAs (including the AP to which they register) form a service set, here below referred to as basic service set, BSS (although other terminology can be used). A same physical STA acting as an access point may manage two or more BSS (and thus corresponding WLANs): each BSS is thus uniquely identified by a specific basic service set identification, BSSID and managed by a separate virtual AP implemented in the physical AP. Each STA is identified within a BSS thanks to an identifier, AID, assigned to it by the AP upon registration. The 802.11 family of standards define various media access control (MAC) mechanisms to drive access to the wireless medium. For example, in order to address the issue of increasing bandwidth and decreasing latency requirements that are demanded for wireless communications systems in high-density environments, multi-user (MU) schemes have been developed to allow a single access point (AP) managing a Basic Service Set (BSS) to schedule MU transmissions, i.e. multiple simultaneous transmissions to or from non-AP stations of the BSS, in the wireless network. A MU scheme has been adopted in the 802.11 ax-2021 standard, published on May 2019. Thanks to the MU feature, a non-AP station has the opportunity to gain access to the wireless medium via two access schemes: the MU scheme and the conventional Enhanced Distributed Channel Access - EDCA (Single User) scheme. Each BSS defines a main elementary channel of the wireless medium (known as a primary channel, usually a 20 MHz channel or a multiple of 20 MHz channel) on which the stations (including the AP) perform EDCA contention using generally legacy EDCA parameters (defined in an EDCA Parameter Set provided by the AP). To increase bandwidth for the forthcoming transmission, the stations can simultaneously contend for additional 20 MHz channels, known as secondary channels. The communication channel thus granted for transmission comprises the primary channel and optionally secondary channels. The 802.11 ax standard allows a MU downlink (DL) transmission to be performed by the AP when gaining access to the wireless medium for a transmission opportunity (TXOP). During the MU DL transmission on the granted communication channel, the AP performs multiple simultaneous elementary transmissions, over so-called resource units (RUs), to various non-AP stations. As an example, the resource units split the communication channel of the wireless network in the frequency domain, based for instance on Orthogonal Frequency Division Multiple Access (OFDMA) technique. The assignment of the RUs to the non-AP stations is signalled at the beginning of the MU Downlink frame, by providing an association identifier (AID) of a non-AP station (individually obtained by each station during its association procedure with the AP) for each RU defined in the transmission opportunity. The 802.11 ax standard also allows a MU uplink (UL) transmission to be triggered by the AP when gaining access to the wireless medium. During the MU UL transmission, various non-AP stations can simultaneously transmit data to the AP over the resource units forming the communication channel. To control the MU UL transmission by the non-AP stations, the AP previously sends a control frame, known as a Trigger Frame (TF). The Trigger Frame allocates the resource units to the non-AP stations of the same BSS, using 16-bit Association IDentifiers (AIDs) assigned to them upon registration to the AP and / or using reserved AIDs designating a group of non-AP stations. The TF also defines the start of the MU UL transmission by the non-AP stations as well as the length thereof. After a non-AP station makes an MU UL transmission, it performs EDCA contention on the medium using temporarily a different (from the legacy ones) set of EDCA parameters, known as MU EDCA parameters (defined in a Multi-User (MU) EDCA Parameter Set provided by the AP). The current discussions in the task group 802.11 be, as illustrated by draft IEEE P802.11be(RTM) / D5.0 of November 2023 (below the “D5.0 standard”), introduce the Multi-Link Operation (MLO) when it comes to MAC layer operation. The MLO allows multi-link devices to establish or setup multiple links and operate them simultaneously. A communication link or “link” corresponds to a given channel (e.g. 20 MHz, 40 MHz, and so on) in a given frequency band (e.g. 2.4 GHz, 5 GHz, 6 GHz) between an AP affiliated with the AP MLD (multi-link device) and a non-AP STA affiliated with the non-AP MLD. The affiliated APs and non-AP STAs operate on their respective channels in accordance with one or more of the IEEE 802.11 standards (a / b / g / n / ac / ad / af / ah / aj / ay / ax / be / bn) or other wireless communication standards. Thanks to the multi-link aggregation, traffic associated with a single MLD can theoretically be transmitted across multiple parallel communication links, thereby increasing network capacity and maximizing utilization of available resources. The description below mostly concentrates on a single link for ease of explanation. However, similar considerations can be made with respect to each link forming a multiple link set for MLD devices. Therefore, the term STA or “station” may refer to one affiliated STA of a non-AP MLD (non-AP STAs of a non-AP MLD), and AP may refer to one affiliated AP of an AP MLD. Figure 1 illustrates an exemplary network environment in which embodiments of the present disclosure can be implemented. The illustrated wireless network environment comprises a multi-AP system 100 formed by a group of neighbouring wireless networks that operate over a common communication channel or wireless medium. The common communication channel may correspond to a part (e.g. 20 MHz) or all of an operating channel (e.g. 20 MHz, 40 MHz, 80 MHz, 160 MHz or 320 MHz). A first wireless network (or Basic Service Set) BSS1 comprises an access point (AP) 110 and three non-AP stations (STAs) 111,112 and 113 associated to the AP 110 (i.e., registered with it). A second wireless network BSS2 comprises an AP 120 and three associated non-AP STAs 121, 122 and 123. A third wireless network BSS3 comprises an AP 130 and three associated non-AP STAs 131,132 and 133. In the following, BSSx represents any of the wireless networks, while 1x1, 1x2 and 1x3 any of the non-AP stations. Of course, another number of wireless networks and any number of non-AP stations per wireless network can be contemplated. In the present disclosure, APs 110, 120 and 130 are also referred to, respectively, as AP1, AP2 and AP3. A device may act as an AP of one wireless network and at the same time may belong to another wireless network as an associated STA. In embodiments (not illustrated), a BSS may be a P2P Group managed by a Group Owner acting as a soft-AP. All or part of the APs may be affiliated APs to the same AP MLD. They also can be separate devices. Any AP broadcasts management frames, such as beacon frames, to share parameters to be used for the functioning of its BSS. The stations (AP and non-AP) of each wireless network exchange data frames over the communication channel 100, under the management of the AP. A primary channel, usually 20 MHz channel, is defined per wireless network on which the management frames are exchanged. The other 20 MHz channels of the communication channel, if any, are known as secondary channels. The APs can also communicate one with each other, either using a communication channel of their BSS that is common to the other BSSs or using separate communication links (such as a separate wireless network or channel, an Ethernet backhaul connecting all the APs, direct links, and so on). A main link (anchor link) or a link dedicated to management frame exchange (management link) may be used between two or more APs. Each non-AP STA 1x1-1x3 registers to the AP 1x0 of one wireless network BSSx during an association procedure. During the association procedure over the primary channel, the AP assigns a specific Association IDentifier (AID) to the requesting station. For example, the AID is a 16-bit value uniquely identifying the station. The stations (including the AP) compete one against each other over the communication channel (including the primary channel and optionally secondary channels to increase bandwidth) using EDCA (Enhanced Distributed Channel Access) contention to access the communication channel in order to be granted a transmission opportunity (TXOP). The TXOP may then be used to transmit (single-user, SU) data frames or to implement multi-user (MU) transmissions. In the MU scheme, a single station, usually the AP of the wireless network BSSx, is allowed to schedule a MU transmission, i.e., multiple simultaneous transmissions to or from other stations of the wireless network. One implementation of such a MU scheme has been for example adopted in IEEE 802.11 ax amendment standard, known as the Multi-User Uplink and Downlink OFDMA (MU UL and DL OFDMA) procedures. In the MU scheme, resources are defined over the 20 MHz channel or channels used, known as resource units. More generally, the resources may include space, frequency and time resources and may be obtained according to different multiplexing schemes. Examples of those schemes include Spatial Division Multiple Access (SDMA) system, Time Division Multiple Access (TDMA) system, Orthogonal Frequency Division Multiple Access (OFDMA) system, and Single-Carrier Frequency Division Multiple Access (SC-FDMA) system. In the IEEE 802.11 wireless local area networking standards, the multi-AP system 100 may correspond to an extended service set (ESS) and each of the wireless networks to a basic service set (BSS). Although the description of embodiments of the invention is given in the context of IEEE 802.11, the embodiments are not limited thereto and they may apply to other types of wireless networks and protocols. To meet low latency requirements in 802.11 be as well as to increase efficiency of the MU operation, existing mechanisms have been reused and improved, including the Target Wake Time (TWT) mechanism and the Triggered TXOP Sharing procedure. The Target Wake Time (TWT) mechanism enables wake time negotiation between an AP and an associated station (STA) to improve power efficiency. With TWT operation, a STA has only to wake up at a pre-scheduled time negotiated with another STA or AP in the network. The Restricted Target Wake Time (R-TWT) schedules dedicated (and protected) service periods (SPs) for stations (affiliated with a non-AP MLD) to convey their latency sensitive traffic(s) over their BSS. An R-TWT agreement is nothing more than a Broadcast TWT agreement negotiated between an AP and an associated non-AP station of the BSS of a given link. The non-AP station establishes with the AP membership in a Broadcast TWT (or R-TWT) schedule. The schedule may be defined for some TIDs. The R-TWT Service Periods SPs of the R-TWT schedule are advertised in broadcast management frames (e.g. beacons), using an R-TWT information about the negotiated R-TWT SPs, typically a Broadcast TWT ID (bTWT ID). Mechanisms like TWT or R-TWT are negotiated per link in case of ML operation, that is to say between an initiator affiliated STA of the non-AP MLD and the corresponding affiliated AP of the AP MLD. Negotiations to become a member of or to terminate membership in an R-TWT schedule (more generally a broadcast TWT) are performed through exchange of frames that carry TWT elements, having the Negotiation Type subfield set to 3 (Broadcast TWT). In particular, a non-AP STA may request to become a member of a TWT schedule by transmitting a TWT Setup frame to its associated AP that contains a TWT element for a given R-TWT schedule. The AP then advertises the scheduled broadcast TWT (or R-TWT) using broadcast TWT elements in its management frames, typically in the beacon frames, FILS Discovery frames and broadcast Probe Response frames. The Triggered TXOP Sharing procedure or Triggered TXS procedure is a TDMA-like procedure. It allows an AP to allocate a portion of an obtained TXOP to one of its associated non-AP STA for transmitting its own data. This time sharing is triggered by a (802.11ax) MU-RTS trigger frame that includes an additional TXOP Sharing mode subfield. This subfield informs whether the MU-RTS trigger frame is for conventional 802.11 ax use (Triggered TXOP Sharing Mode is set to 0) or for a new use related to the 802.11 be TXOP Sharing procedure (Triggered TXOP Sharing Mode is set to 1 or 2). In the latter, the TXOP Sharing is either limited to Uplink Traffic when the Triggered TXOP Sharing Mode is set to 1 or dedicated to Uplink and / or direct link traffic when the Triggered TXOP Sharing Mode is set to 2. Direct link means peer-to-peer (P2P). Therefore, with this new mechanism, the AP is now able to allocate its associated non-AP stations with frequency resource units (e.g. Basic Trigger Frame) or temporal resource units. As apparent from the above, the 802.11 standard has moved from a random-access mechanism, called EDCA, in which each station individually contends to get the medium and then transmit, to a trigger-based medium access mechanism largely controlled by the AP for its associated non-AP stations. This is to improve and optimize the medium access in terms of quality of service (QoS), compatibility of an access point (AP) protocol, security enhancement, radio measurement or radio resource measurement, wireless access in vehicular environment, fast roaming, and the like, given the constant increase of the number of wireless devices. The triggering procedure was introduced by the 802.11 ax amendment and refined in some parts in the 802.11 be amendment. It allows various non-AP stations to simultaneously transmit data over resource units of an operating channel, that are allocated to these stations by the AP through a control frame, known as a Trigger Frame (TF). The allocation is made using the Association IDentifiers (AIDs) assigned to the stations upon registration to the AP (for scheduled RUs) and / or using reserved AIDs designating a random access to an RU (for random RUs). The Trigger frame also defines the start of the MU transmission by the non-AP stations as well as the length thereof. The non AP stations can transmit data to the AP (MU UL transmission) or between them (DiL or P2P transmission). Exemplary trigger-based procedures include FDMA-like procedures such as the so-called MU (Multi User) operations defined in sections 26.5 and 35.5 of the “D5.0 standard”) and the TDMA-like procedures such as the so-called Triggered TXOP Sharing procedure (or “TXS”) defined in section 35.2.1.2 of the D5.0 standard. In the trigger-based procedures, the AP sends an IEEE802.11 Trigger frame (meaning an IEEE802.11 frame having Type value ‘01’ and Subtype value ‘0010’ in the Frame Control field of the MAC header) that allocates resources for and solicits one or more transmissions within its own BSS. Figures 2 to 3 illustrate trigger-based medium access procedures. Figures 2a, 2b and 2c present exemplary frame exchanges occurring in typical triggered procedure as defined in the 802.11 ax and 802.11 be standards. Figure 2a describes a Multi-User Uplink (MU UL) communication triggered by the AP. The frame exchange starts with an optional MU-RTS / CTS sequence procedure. This procedure allows the AP to initiate a TXOP (transmission opportunity) and to protect the TXOP frame exchange sequences thanks to the NAV. The AP may transmit an MU-RTS (Request-To-Send) Trigger frame to solicit simultaneous CTS (Clear-To-Send) frame transmissions from one or more non-AP STAs as illustrated by MU-RTS frame 210 sent by one of the APs 110, 120 or 130 in the example of Figure 1. MU-RTS Trigger frame is a Trigger frame in the meaning of the 802.11 standards, i.e., it is a MAC frame having Type value ‘01 ’ and Subtype value ‘0010’ in the Frame Control field of the MAC header. Furthermore, the MU-RTS Trigger frame has a ‘MU-RTS’ type in the Trigger Type subfield of the Common Info field. The format of an 802.11 Trigger frame is illustrated in Figure 3a, as defined in the REVme / D4.1 standard of October 2023 and the D5.0 standard. A Trigger frame (except MU-RTS trigger frame) allocates resources for and solicits one or more TB PPDU transmissions. An MU-RTS trigger frame allocates resources for one or more PPDUs (non-TB PPDU). The Trigger frame also carries other information required by the responding STA to send an HE TB PPDU. Trigger frame 300 is made up of the following fields: - Frame Control field 301 to indicate mainly the type of the frame. Type value ‘01’ and Subtype value ‘0010’ in this field identify a Trigger frame, - Duration field 302 to set a duration of the transmission, generally in ps (microseconds). This value allows the receivers to set their network allocation vector (NAV) which is an indication of the duration that a station prevents from accessing the medium, - RA (Receiver Address) field 303 to identify the addressee or addressees of the frame. It is set to the non-AP address of the station identified by the AID12 subfield 331 of the User Info field 330 when there is only one User Info field 330 in the User Info list 305. Otherwise if there are more than one User Info field 330 in the User Info list 305 or one User Info field 330 with the AID12 331 that allocates an RA-RU, RA field 303 is set to a broadcast address to target all stations, - TA (Transmitter Address) field 304 to identify the transmitting station. It is set to the address of the transmitting station if the frame is addressed to stations that belongs to the same BSS or is set to the transmitted BSSID if the frame is addressed to stations that belongs to several BSSs of a multiple BSSID set, - Common Info field 310 further described below with reference to Figures 3c and 3d for the HE and EHT variants respectively, - User Info List field 305 that contains zero or more User Info fields 330 to respectively define zero or more RU allocations. User Info field 330 is further described below with reference to Figure 3b, - Optional Padding field 306 to extend the frame length to give the recipient STAs enough time to prepare a response for transmission a SIFS after the Trigger frame is received, and - FCS field 307 to contain a 32-bit CRC. Figure 3b illustrates a format of the User Info field 330 (HE variant) in the Trigger frame format according to the 802.11 standard. The EHT variant of the User Info field format (not illustrated) is the same except that the EHT variant includes a PS160 subfield (in place of a reserved bit) which is used in complement to RU allocation and UL BW subfields for instance to handle 320MHz bandwidth channel. User Info field 330 includes the following subfields: - AID12 subfield 331 encoded as described in the following table: AID12 subfield Description 0 User Info field allocates one or more contiguous RA-RUs for associated STAs 1-2007 User Info field is addressed to an associated STA whose AID is equal to the value in the AID12 subfield 2008-2044 Reserved 2045 User Info field allocates one or more contiguous RA-RUs for unassociated STAs 2046 Unallocated RU 2047-4094 Reserved 4095 Start of Padding field - RU Allocation subfield 332 along with UL BW subfield 315 in Common Info field 310 to identify the size and the location of the RU allocated through the current User Info field. If the AID12 subfield is in the range 1 to 2007, then the RU Allocation subfield indicates the RU is allocated to the STA identified by the AID12 subfield. If the AID12 subfield is 0 or 2045, then the RU Allocation subfield indicates the starting RU of one or more contiguous RA-RUs (random access) allocated by the User Info field. If the AID12 subfield is 2046, then the RU Allocation subfield indicates an unallocated RU, - UL FEC Coding Type subfield 333 to indicate the code type of the solicited HE TB PPDU, - UL HE-MCS subfield 334 to indicate the HE-MCS of the solicited HE TB PPDU, - UL DCM subfield 335 (absent in the EHT variant) to indicate DCM (dual carrier modulation) of the solicited HE TB PPDU. - subfield 336 corresponding to the RA-RU Information subfield if the AID12 subfield is either 0 or 2045; otherwise corresponding to the SS Allocation subfield. The RA-RU information is made up of two subfields: o The Number Of RA-RU subfield (not shown bits 26 to 30) to indicate the number of contiguous RUs allocated for UORA (Uplink OFDM random-access). The value of the Number Of RA-RU subfield is equal to the number of contiguous RA-RUs minus 1. o The More RA-RU subfield (not shown bit 31) set to 1 to indicate that RA-RUs of the type indicated by the AID12 subfield in this User Info field are allocated in subsequent Trigger frames that are sent until the end of a TWT SP in which the Trigger frame carrying this field is sent, - UL Target Receive Power subfield 337 to indicate the expected receive signal power, measured at the AP. - Reserved bit B39 (PS160 bit in the EHT variant), and - Optional Trigger Dependent User Info subfield 339. Its presence depends on the value of the Trigger Type field 311 in Common Info field 310 (i.e., depends on the type of Trigger frame). Figures 3c and 3d illustrate formats of respectively the HE variant and the EHT variant of Common Info field 310 in the Trigger frame format according to the 802.11 standard. Common Info field 310 includes the following subfields (not exhaustive list for conciseness): - Trigger Type subfield 311 to identify the Trigger frame variant. The values available for this field, corresponding to the various variants or types, are shown in Figure 3e, - UL Length subfield 312 to indicate the value of the L-SIG LENGTH field of the solicited TB PPDU, - More TF subfield 313 to indicate whether or not a subsequent Trigger frame is scheduled for transmission, - CS Required subfield 314 to define specific rules for channel sensing, - UL BW subfield 315 to indicate bandwidth in the HE-SIG-A of the HE TB PPDU, - subfield 316 corresponding to the Triggered TXOP Sharing (or TXS) Mode subfield if the Trigger type 311 indicates an MU-RTS Trigger Frame (value 3); otherwise, subfield 316 is the Gl And HE-LTF Type subfield. The values available for the Triggered TXOP Sharing Mode subfield are shown in Figure 3f. Values ‘1’ and ‘2’ enable the TXS mode, whereas value ‘0’ disables it., - AP Tx Power subfield 321 to indicate the AP’s combined transmit power at the transmit antenna connector of all the antennas used to transmit the triggering PPDU in units of dBm / 20 MHz, - UL Spatial Reuse subfield 324 to carry the values to be included in the Spatial Reuse fields in the HE-SIG-A field of the solicited HE TB PPDUs, - Optional Trigger Dependent Common Info subfield 328. Its presence depends on the value of the Trigger Type field, hence of the type of Trigger frame. Common Info field 310 in the HE variant also includes Number Of HE / EHT-LTF Symbols subfield 318, LDPC Extra Symbol Segment subfield 320, Pre-FEC Padding Factor subfield 322, PE Disambiguity subfield 323 and Reserved bit B63 327. The HE variant also specifically carries MU-MIMO HE-LTF Mode subfield 317a, UL STBC subfield 319a, Doppler subfield 325a and UL HE-SIG-A2 Reserved subfield 326a, while the EHT variant carries Reserved bit B22 317b, Reserved bit B26 319b, Reserved bit B53 325b, HE / EHT P160 subfield 326b, Special User Info Field Flag subfield 350 and EHT Reserved bits B56-B62 351. These subfields are of less importance for the present invention. However, Special User Info Field Flag subfield 350is always set to 0 in an EHT-variant Common Info field, indicating that a Special User Info field is included in the Trigger frame that contains the EHT-variant Common Info field. Back to Figure 2a, when the stations received MU-RTS Trigger Frame 210 (Trigger Frame type field 311 set to 3) from their associated AP with a User Info Field 330 which is addressed to them (i.e., with the AID12 subfield 331 equal to the 12 LSBs of their AID), then the stations send back a CTS (Clear-to-send) frame to the transmitting AP. In the scenario shown, STA1 and STA2 send respectively CTS frames 211 and 212 to the AP. The CTS frame is sent on the channel indicated by the RU Allocation subfield 332 of the appropriate User Info field. This procedure allows the subsequent transmission to be protected. Indeed, all the neighbouring stations receiving either the MU-RTS frame from the AP or one of the CTS frames from the stations set their NAV to the duration indicated in the frame, which prevent the neighbouring stations from accessing the medium during the duration. Those durations computed by the AP corresponds to time to transmit the complete sequence of frames, i.e., Trigger frame, data and acknowledgement. Next, once access to the medium has been gained (confirmed by the CTS frames received), the AP sends a Trigger frame to solicit simultaneous immediate response frames from the stations addressed by the Trigger frame. In the scenario shown, the AP sends Basic trigger frame 213 (Trigger frame type set to 0) including User Info fields with the AID12 subfields 331 corresponding to STA1 and STA2 respectively. In response to Trigger frame 213, STA1 and STA2 send uplink data (214 for STA1 and 215 for STA2) to the AP on the channel allocated by the respective RU Allocation subfield 332 in the Basic trigger frame 213. Next, the AP may acknowledge the reception of the uplink data by sending a Multi-STA Block Ack frame 216 over the operating channel, that includes an acknowledgement for STA1 and STA2. Figure 2b describes another exemplary trigger-based communication scenario with TXOP sharing soliciting UL PPDU. In this example, an MU-RTS TXS Trigger frame with Triggered TXOP Sharing Mode subfield value equal to 1 (as defined in Table of Figure 3f) is used. This procedure allows an AP to initiate a TXOP and then to share its TXOP with an associated non-AP station before getting the medium back to send data to a non-AP station. This procedure may optionally be preceded by the sending of a CTS-to-self frame (not shown) by the AP to protect the TXOP frame exchange sequences. In the scenario, the AP sends MU-RTS Trigger Frame 220 (Trigger Frame Type field 311 set to value 3) having Triggered TXOP Sharing Mode field 316 set to value 1. It means the Trigger frame is a MU-RTS TXS Trigger frame that solicits Uplink transmission. Upon receiving Trigger frame 220, the scheduled station STA1 (i.e., identified in AID12 subfield 331 included in User Info field 330 (when RA field 303 is set to a broadcast address)) transmits to the AP a CTS response frame 221 and then starts to transmit uplink data (non-TB PPDU) 222 to the AP. Next, the AP may acknowledge the reception of the uplink data by sending a Block Ack frame 223 to STA1. STA1 may start transmitting other data 224 to the AP which acknowledges the other data with a subsequent Block Ack frame 225. After the sequence of UL transmission from STA1 (the AP finds out the sequence ends because the medium becomes idle, or STA1 indicates it has no more data to transmit to the AP), the AP may use the end of its TXOP for its own operation, e.g. to send data 230 to another station even before the end of the TXOP Sharing duration allocated to the scheduled station STA1. Figure 2c describes another exemplary trigger-based communication scenario with TXOP sharing soliciting UL PPDU and / or DiL transmission (i.e., to another station). In this example, an MU-RTS TXS Trigger frame with Triggered TXOP Sharing Mode subfield value equal to 2 (as defined in Table of Figure 3f) is used. This procedure allows an AP to initiate a TXOP and then share its TXOP with an associated non-AP station which uses it to indifferently perform UL transmissions to the AP or DiL transmissions with another non-AP station. The procedure may optionally be preceded by the sending of a CTS-to-self (not shown) to protect the TXOP frame exchange sequences. The scenario starts as in Figure 2b with the sending of MU-RTS TXS Trigger Frame 250, this time with Triggered TXOP Sharing Mode field 316 set to value 2, followed by CTS response frame 221, uplink data 222 and Block Ack frame 223. Then, scheduled station STA1 may decide to send DiL (or P2P) data 251 to another station (STA2 in the scenario). Upon receiving these DiL data from STA1, STA2 may acknowledge the reception of the data by sending a Block Ack frame 252 to STA1. At the end of the duration allocated to the scheduled station STA1, the AP may use the end of its TXOP for its own operation (not shown), e.g. to transmit a new MU-RTS TXS to share again its TXOP with other stations or to merely send data. Back to Figure 1 depicting multiple APs, a Multi-AP (MAP) technology has emerged where the APs 110, 120, 130 collaborate to share the common communication channel once one of them is granted access to it. To do so, the APs exchange messages one with each other to create a MAP group (MAP Coordination Set) and coordinate the MAP communications to avoid or reduce interference. MAP sharing of the common communication channel is resource-based. An amount of a shared resource can be measured in time units, frequency bandwidth, number of streams, amount of data or traffic (e.g. number of bytes) and / or any other suitable unit, depending on the type of resources as defined above. In this perspective, “shared resources”, “shared frequency band”, “shared channels”, “shared slots” and “shared resource units” are synonyms and designate those resources offered by one of the APs to any other AP or APs through the MAP technology. Time-based (C-TDMA) sharing is a privileged approach for MAP sharing. However other types of coordination may be contemplated such as coordinated OFDMA (frequency-based) or coordinated Spatial Reuse No details on how to make the MAP coordination effective in a multi-AP system are provided. For example, no mechanism is provided to coordinate the medium access among the APs to allow an efficient air time sharing by minimizing collisions and interferences. The former standard amendments have extensively described mechanisms developed to improve medium access with different triggering methods (such as described above) to either allocate frequencyresource or time-resource. These trigger-based procedures are the basis for all the MAP coordination mechanisms. However, all those procedures are limited to intra-BSS usage, i.e., to an usage between an AP and its associated stations. A need exists to extend the trigger-based mechanisms to MAP in an efficient way. Similarly, efficient coordination (of any type) to provide or share resources between the APs requires an efficient sharing of resource needs between the APs. Again, the known 802.11 standards are deficient in providing a way to share resource needs in MAP context. The present disclosure provides multiple procedures to overcome these lacks. As apparent from below, a communication method in the multi-AP context may involve for an AP managing a first BSS to send a first Trigger frame allocating resources to a second BSS (e.g. a second AP managing this second BSS) and soliciting a transmission from the second BSS within the allocated resources. Such a Trigger frame may be considered as a “MAP” Trigger frame as it allocates resources to another AP or BSS. The solicited transmission may include transmissions addressed to the AP by the second AP, e.g. to transmit a BSR, a CTS or a BlockAck (e.g. Multi-STA Block Ack) frame in response to a BSRP Trigger frame or an MU-RTS frame. Multiple of such Trigger frames (possibly with different Trigger Types) allocating resources to a second BSS may be cascaded to create efficient transmission scenarios: a MAP BSRP Trigger frame to obtain one or more BSRs, followed by a MAP MU-RTS Trigger frame to protect a TXOP and then a MAP Basic Trigger frame to share the medium with other APs based on the BSRs received. Coordination of several APs in a multi-AP context is therefore obtained, that enable triggering procedures. The first AP may be referred below as the “sharing” AP since it shares part of a TXOP it gained (or alternatively as “coordinating” or “requesting” AP), while the other APs benefiting from this sharing may be referred to as “coordinated” or “shared” APs (or alternatively as “coordinated” or “requested” AP). Similarly, a communication method in the multi-AP context may involve for an AP managing a second BSS to send, to a first AP managing a first BSS, a MAP Resource Report (e.g., BSR) frame reporting resource needs for the second BSS. Such a MAP Resource Report or BSR allows resource needs to be shared between the APs. Based on one or more of these MAP Resource Reports or BSRs, the first AP may therefore efficiently allocate resources in a gained TXOP to the other BSSs, by sending for instance a MAP Trigger frame. The MAP Resource Report may be spontaneously sent by an AP (this can be called an unsolicited or gratuitous MAP Resource Report) or in response to a MAP Resource Report Request frame previously sent by the first AP (this can be called a solicited or triggered MAP Resource Report). The MAP Resource Report Request frame, such as a BSRP Trigger frame or a MU-RTS Trigger frame or a mere GAS frame may allocate resources to the second AP, in which case the MAP Resource Report response is transmitted in the resources allocated to the second AP. Figures 4a and 4b illustrate, using flowcharts, exemplary steps at a sharing AP MLD (or AP) and at one of coordinated / shared AP MLDs (or stations) according to some embodiments. Figure 4a focuses on the sharing of resources through the sending of a MAP Trigger frame, while Figure 4b focuses on the collection or gathering of resource needs from coordinated APs and associated stations. The left part of Figure 4a represents steps at the sharing AP, while the right part represents steps at the coordinated AP for the management of the MAP Trigger frame. At step 400, the sharing AP gains a transmission opportunity TXOP using conventional medium access mechanisms (e.g. EDCA). Next at step 401, the sharing AP may perform the process of Figure 4b to get buffer status information or resource needs from the coordinated APs. The resource needs are provided by the coordinated AP through step 410 detailed in Figure 4b. Next, at step 402, the sharing AP prepares a resource allocation for the MAP cooperation. The resource allocation may be computed based on the resource needs obtained at step 401 (to adjust the resources to the needs reported by the various coordinated APs) or blindly with a statistical approach (e.g., resources are equitably shared between all coordinated APs). The resource allocation may depend on the type of MAP Trigger frame used in the next step 403. For a Basic Trigger frame sharing the operating channel on a C-OFDM approach, the overall operating channel (overall resources available) is allocated by sub-bands to different coordinated APs for instance on a 20MHz-band basis (see Figure 2a for example). For an MU-RTS TXS Trigger frame, the sharing of the operating channel is made on a time basis (C-TDMA approach - see Figure 2b or 2c for example). Other Trigger frame types such as BSRP or NFRP also provides a frequency-based sharing. In some embodiments, a mixed allocation with a frequency- and time-based sharing can be provided. The resource allocation may mix allocations of resources to coordinated APs and allocations of other resources (e.g. Resource Units that split a 20MHz band) to non-AP stations of the sharing BSS (i.e., associated to the sharing AP). Next, the sharing AP sends (step 403) a MAP Trigger frame including the resource allocation for the coordinated APs (and also some of its associated stations) that may be identified through a specific identifier AP ID. Such an AP ID may be provided to the APs when creating or joining a MAP group (MAP Coordination Set). In embodiments, a dedicated signalling that the Trigger frame is a MAP Trigger frame is provided. As an example, reserved bit B63 (327 on Figure 3c) may be used. Alternatively, new values for the Trigger Type subfield (Figure 3e) may be defined for MAP Trigger frames, optionally distinguishing between subtypes: MAP Basic, MAP MU-RTS, MAP BSRP, MAP NFRP, and / or MAP Ranging Trigger frames. Yet, another variant may rely on an additional Trigger Type Extension field (additional to those of Figure 3c) to convey appropriate signalling of the MAP Trigger frame and optionally of its subtype. Yet, a further variant may add a new value for the Triggered TXOP Sharing Mode field 316 (Figure 3f), e.g. value 3 to signal the TXOP sharing procedure is initiated by the sharing AP for one or more coordinated APs. Yet, a further variant may consider a combination of a Trigger Type subfield (e.g. MAP MU-RTS or MAP BSRP) along with an additional Trigger Type Extension field (additional to those of Figure 3c) to convey appropriate signalling of the MAP Trigger frame triggering MAP BSR in timing sequence (e.g. as shown in Figure 13).Yet other variants may rely on a Special User Info field level (which presence is signalled by Special User Info Field Flag bit B55 350 set to 0), in which all or part of reserved bits B37-B39 may signal the MAP Trigger frame and optionally of its subtype. Other signalling may be contemplated. For example, using an AP AID in AID12 field 331 of a User Info field is a sufficient indication that the Trigger frame is a MAP Trigger frame since an AP is addressed. Values 2049 to 4055 (of course any other range may be considered) may be reserved as AP Al Ds, which Al Ds are provided to the APs when creating the MAP Group. The MAP Trigger frame is received by the coordinated AP at step 411. The coordinated AP identifies the received Trigger frame as a MAP Trigger frame due to appropriate signalling. Next, at step 412, the coordinated AP determines whether the MAP Trigger frame is addressed to it, i.e., whether the MAP Trigger frame includes its identifier, be it an AP ID or AP group ID or the like corresponding to the identity of the coordinated AP. In the affirmative, the coordinated AP obtains, at step 413, its resource allocation from User Info field 330 of the Trigger frame corresponding to its identifier. As mentioned above, the resource allocation may be a time duration or a frequency band or both or a spatial stream. Once the allocated resource has been identified, the coordinated AP can operate at step 414 on this allocated resource according to the MAP Trigger frame type. The sharing AP may share the medium according to different ways, C-TDMA for instance by using a MU-RTS TXS Trigger frame, C-FDMA by using a MU-RTS and / or Basic Trigger Frame, in a similar way as those presented above with reference to Figures 2a, 2b and 2c. The sharing AP may also consider Spatial Reuse in between the APs of the MAP Group. For instance, the operation at step 414 may include responding with a CTS frame on the allocated resource in case of MAP MU-RTS Trigger frame, sending a BSR on the allocated resource in case of MAP BSRP Trigger frame, operating as the owner of the allocated resource in case of MAP MU-RTS TXS or Basic Trigger frame, sending a NDP feedback report in case of MAP NFRP Trigger frame. Finally, the sharing AP detects an end of the coordinated communication with the end of the TXOP, or the end of time duration allocated to the coordinated AP or by receiving a frame that shortens the sharing durations (e.g., a releasing frame from the coordinated AP). One example is illustrated below with reference to Figure 13, wherein the end of allocated duration or slot may be signalled through an enhanced Multi-STA Block Ack frame (variant format provided in Figure 12). The sharing of resource needs between APs may be based on such MAP Trigger frame when being of a MAP Resource Report Request type, such as a BSRP type. As mentioned above, an unsolicited MAP Resource Report, e.g. a BSR, may also be sent spontaneously by an AP to another AP. Figure 4b illustrates a triggered or solicited sharing of resource needs. The left part of the Figure represents steps at the sharing AP requesting resource needs from one or more coordinated APs, while the right part represents steps at any coordinated AP for the management of the bandwidth need exchange for MAP purpose. At step 400 already described, the sharing AP gains a transmission opportunity TXOP. Next at step 431, the sharing AP prepares and sends a MAP Resource Report Request Trigger frame to the coordinated APs, including a resource allocation for the coordinated APs (and optionally some of its associated stations) that may be identified through respective identifier AP IDs. The MAP Resource Report Request frame may be one or a combination of ones from a Buffer Status Report Poll, BSRP, Trigger frame, a Multi-User Request-To-Send, MU-RTS, Trigger frame, and a Generic Advertisement Service, GAS, frame. These frames have one or more User Info fields, each including an AID subfield set to the AP ID of the targeted coordinated AP. The MU-RTS or BSRP Trigger frame may have a TXS Mode field 316 set to 1, to enable the Triggered TXOP Sharing (TXS) mode. This offers a time portion (timeslot) of the obtained TXOP to one or more coordinated APs, for them to send their MAP Resource Report frame to the first AP (each within its allocated portion). The MAP Resource Report Request frame may include some constraints or requirements for the requested MAP Resource Reports (resource needs). In that case, the resource needs provided in the MAP Resource Report frame correspond to needs for traffic meeting some requirements defined by the first AP. As examples, requirements may be based on traffic types, such as UL, DL, DiL, specific TID, specific stations (e.g. EHT-compliant stations), delay bound, and so on. Figure 9 described below provides an exemplary signalling of some constraints. The MAP Resource Report Request frame is received by the coordinated AP at step 440, where it identifies the received Trigger frame as a MAP Resource Report Request frame and checks whether the frame is addressed to it. In the affirmative, at optional step 441, the coordinated AP may poll its associated stations to know their own resource needs. To do so, it sends a conventional BSRP Trigger frame to its associated stations on the allocated resource received from the sharing AP within the MAP Resource Report Request frame. The polling may take place within the portion allocated to the coordinated AP, e.g., through the above TXS mode, as shown in the scenario of Figure 13 for example. In response to this conventional BSRP Trigger frame, the coordinated AP receives BSRs from its associated stations at step 442. Conventional BSRs may be used to report resource needs of an associated station to the polling coordinated AP. They may report the station’s needs in terms of UL data only, or alternatively the station’s needs in terms of UL data and DiL (or P2P) data also. In other words, resource needs obtained from a non-AP station includes P2P resource needs of this non-AP station for P2P communication. A P2P BSR separated from a conventional BSR (for UL traffic) can be used; or resource needs for both P2P traffic and UL traffic can be conveyed within the same report. In embodiments, the resource needs for P2P traffic includes duration and bandwidth needs required to fulfil the P2P communication requirements. For example, the resource needs for P2P traffic may be built by the peer non-AP stations based on the information carried in the TDLS (Tunneled Direct Link Setup) Peer Traffic Indication frame exchanged between TDLS peers and more specifically the TPU Buffer Status Information which contains information regarding the traffic buffered at a TDLS station. Next, the buffer size information may be translated in bandwidth and duration information based on the transmission parameters that the peer station intends to use for P2P communication. If both peer stations involved in the P2P communication are part of the MAP Group, only the transmitter of the P2P communication reports its resource needs to avoid double reporting and over-allocating resources. In this case, the P2P resource needs are P2P resource needs in P2P transmission from the non-AP station sending the BSR. Two stations are part of the same MAP group in the following cases: the stations belong to the same BSS (e.g. in the TDLS case); the stations are associated to different APs of the MAP group; the softAP or the Group Owner (of the P2P group) is part of the MAP group. On the other hand, if only one of the peer stations is part of the MAP Group, this peer station reports all the P2P needs. In that case, the P2P resource needs (reported by the peer station) include P2P resource needs in both P2P directions to and from the peer station. BSRs usually report queue size, i.e., the size of the buffered data (UL data and optionally P2P data) in the transmission queue. In embodiments, the BSR from the associated stations may report a duration and optionally a bandwidth. As an example, a non-AP station associated to a coordinated AP and acting as group client in a P2P Group may report a P2P activity duration (hence P2P needs). The P2P activity duration can be computed from any Notice of Absence carried in the Beacon frame sent by the Group Owner, e.g. as the complement of the Notice of Absence duration. Also, in embodiments, an associated station may report P2P data based on a Traffic Indication Map (TIM) carried in the Beacon frame sent by the Group Owner. Indeed, the TIM specifies for each peer station of the P2P Group whether the Group Owner has buffered data waiting for it. Next, at step 443, the coordinated AP determines a resource allocation based on the resource needs received from its associated stations (either in response to the BSRP Trigger frame or spontaneously) that could define the next resource scheduling. In other words, the coordinated AP anticipates / prepares the resource allocation of its subsequent Trigger Frame: it determines a resource allocation scheduling allocating resources to its associated non-AP stations based on the obtained resource needs. In embodiments, the resource allocation scheduling may also be determined based on own resource needs of the coordinated AP for downlink transmission within the second BSS. Hence, a full resource allocation scheduling is obtained. The resource allocation scheduling can be prepared with a target bandwidth, which target bandwidth may be predefined for the MAP Group, be pre-agreed between the sharing AP and the coordinated AP, or be the maximum bandwidth compatible with the coordinated AP given the bandwidth used by the sharing AP (or defined for the MAP Group). In combination or as a variant, the resource allocation scheduling can be based on TSPEC / QoS characteristics elements specifying traffic flows with one or more associated non-AP stations. To be recalled that the TSPEC / QoS characteristics are exchanged and negotiated between the (here, coordinated) AP and its associated non-AP stations through the Stream Classification Service (SCS - section 11.25.2 of the D5.0 standard) or r-TWT (section 35.8) procedures. TSPEC / QoS characteristics for scheduled uplink traffic (traffic direction set to UL) can be taken into account. Hence, they can be combined with the own resource needs of the coordinated AP. Similarly, TSPEC / QoS characteristics for scheduled downlink traffic (traffic direction set to DL) can be taken into account. Hence, they can be combined with the BSRs received from the associated stations reporting their UL needs. Similarly, TSPEC / QoS characteristics for scheduled P2P traffic (traffic direction set to DiL) can be taken into account. They can be combined with the P2P BSRs received from the associated stations involved in P2P communication. Anticipating the resource allocation scheduling at step 443 first allows converting received resource needs (usually expressed as queue sizes) into bandwidth and duration information which are more suitable to appropriate sharing of resources by the sharing AP. Indeed, the information of the queue sizes as received from the associated stations is not adequate because the bandwidth and duration required to transmit a quantity of data is highly dependent on the transmission parameters. In embodiments, to determine the resource allocation scheduling, the coordinated AP thus uses, in addition to the above information, some parameters from previous communications within its BSS, such as the RU allocation, the time slot duration and the transmission parameters (e.g. MCS, transmission power, channel quality, SNR, and so on.). The obtained bandwidth and duration information may therefore be used directly by the sharing AP to easily compare the needs from all the coordinated APs and to allocate resource efficiently according to the resource needs of the coordinated APs. Secondly, anticipating the resource allocation scheduling provides a more precise estimate of the resource needs for the coordinated BSS given the distribution of resource needs between the associated stations. This is because the associated stations have their own individual transmission parameters to be applied to different amounts of data. Thirdly, it allows the coordinated AP to prepare in advance its Trigger frame to be used when it will be provided shared resources by the sharing AP. Step 443 is thus an example of operation to convert or translate resource needs expressed as queue sizes into resource needs expressed as bandwidth and duration information. During step 443, the resource needs obtained by the second AP from multiple non-AP stations of the second BSS are cumulated, optionally also cumulated with own resource needs of the second AP for downlink transmission within the second BSS. Cumulation may merely mean summing the resource needs (e.g. queue sizes before conversion, or individual duration and bandwidth). In some embodiments where constraints are specified by the sharing AP in the MAP Resource Report Request, the resource needs may be limited to a subpart of all the needs expressed by the associated stations. For example, only resource needs in relation to a given traffic type (UL, DL, DiL, specific TID, specific stations, delay bound) can be considered at step 443. Similarly, the coordinated AP may wish to prioritize some traffic type or types (independently to any constraint from the sharing AP) in which case it only considers the resource needs in relation to that traffic type or types at step 443. Next, at step 444, based on the resource allocation scheduling determined at step 443 or any gathering of resource needs for the coordinated BSS, the coordinated AP fills in the MAP Resource Report and sends it to the sharing AP at step 445 as a response to the MAP Resource Report Request frame. In these scenarios, the MAP Resource Report frame cumulates the resource needs identified by the coordinated AP, in particular the MAP Resource Report frame reports resource needs corresponding to the resource allocation scheduling, such as a duration and a bandwidth of the resource allocation scheduling. The MAP Resource Report frame may be one from a BSR frame, a CTS frame, a Beacon frame, a GAS frame, an (BlockAck, such as Multi-STA Block Ack) acknowledgment frame and a MAP Trigger frame allocating resources in a gained TXOP to the first BSS. In one embodiment, a MAP BSR (as MAP Resource Report frame) may be a sum of the individual BSRs received from the associated stations (and possible plus the needs of the coordinated AP). In variants, it may include multiple BSRs corresponding to the individual BSRs received from the associated non-AP stations respectively. In case steps 441 and 442 are omitted, the coordinated AP may fill in the MAP Resource Report with its own resource needs and / or with any BSR received spontaneously from its associated stations or from previous BSRP / BSR procedure or only based on the specification of the traffic flows negotiated with its associated stations. The sharing AP next receives BSRs from its associated stations (if any) at step 432 and the MAP Resource Report from the coordinated AP (APs if multiple) at step 433. The sharing AP is then aware of the resource needs from the coordinated APs in the MAP Resource Reports. It is now able to efficiently allocate new resources to the coordinated AP to meet the resource needs of the latter (or of its BSS), also given the resource needs of its own associated stations and of other BSSs. Steps 402 to 404 (already described) can then be performed by the sharing AP. Although the description above mainly concentrates on a solicited MAP Resource Report frame received in response to a MAP Resource Report Request frame, it may also be sent spontaneously by any AP to another AP or a group of other APs. In embodiments, the MAP Resource Report frame is broadcasted by an AP to all surrounded APs or multicast to all APs of a MAP Group formerly defined. “Spontaneously” means unsolicited, i.e., no request has been made by the sharing AP to receive the report. The spontaneous transmission of the report may rely on triggering events at the coordinated AP. One candidate event is the reception of individual reports (e.g., BSRs) from its associated non-AP stations. One candidate event is the setting or updating of a SOS (Stream Classification Service) or r-TWT agreement within its coordinated BSS. Yet another candidate event is the detection of an internal (to the coordinated AP) trigger, e.g., critical data or a critical amount of (UL, DL or any) data in a transmission buffer or a Beacon frame to be transmitted. Figures 7a-7c now illustrate exemplary scenarios of frame exchange using these signalling in a MAP context. Figures 7a-7c show cascaded multiple MAP Trigger frames from a sharing AP to two coordinated APs, usually to obtain resource needs using a MAP Resource Report Request frame (e.g., BSRP Trigger frame), followed by a MAP MU-RTS Trigger frame to gain access to the network and by a MAP Basic Trigger frame to actually share and thus allocate resources to the other BSSs. Figure 7a illustrates a first example of frame exchange starting with a MAP BSRP procedure to obtain the resource needs of coordinated APs in the surrounding of the sharing AP, followed by a MAP MU-RTS procedure to protect the subsequent coordinated communications that are triggered by a MAP Basic Trigger frame. The frame exchange starts when AP1 110 gains the medium and sends a MAP BSRP Trigger frame 701. This Trigger frame is identified as MAP BSRP using any signalling method as described above. RA field 303 of this MAP BSRP Trigger frame is set to the Broadcast address as it is addressed to several APs (AP2 120 and AP3 130 in the example of this Figure). The MAP BSRP Trigger frame also includes one User Info field 330 addressed to each solicited APs, AP2 and AP3. The APs are identified using any signalling method, e.g., an AID dedicated for AP (whatever the range) in AID12 field 331 of a User Info field 330; AP ID field in User Info field 330; AP ID field in Trigger Dependent User Info field 339 of User Info field 330. Additional information, e.g., constraints or requirements on the requested MAP BSRs, can be provided within the MAP BSRP Trigger frame 701, for example using a Trigger Dependent Common Info field 328 or Trigger Dependent User Info field 339 or a Special User Info field. The additional information may include one or more of the BSR requested information items 900 as shown in Figure 9 and including: - Direction field 901 to indicate the direction of data the requested MAP BSR has to report. The direction values could Downlink, Uplink, Direct link, Any, or even a combination thereof (e.g. UL and DiL), - TID field 902 to indicate a (or more) specific TID, if any, the requested MAP BSR has to report, - Delay bound field 903 to indicate a maximum expiration date for the data to be reported by the requested MAP BSR, - STA version field 904 to indicate one or more specific generations of stations (e.g. UHR) for which the requested MAP BSR is expected to be reported. This may for example allow the sharing AP to directly solicit specific stations associated to surrounding APs in subsequent Trigger frames. - Accurate field 905 to indicate whether the requested MAP BSR has to include BSRs of the non-AP stations associated to the addressed APs. Such indication may be used as a trigger for the addressed APs to responsively send a (conventional) BSRP Trigger frame to its own associated stations to obtain their individual BSRs. As a result, the MAP BSR reports more accurate buffer status information about the entire BSS, to the sharing AP. A variant to the Accurate field to signal the coordinated AP has to poll its associated stations may be based on the duration field of the MAC header in the MAP BSRP Trigger frame 701: if it is set to a value longer than the duration of the time required to transmit the MAP BSR (or more generally the MAP Resource Report), it signals to the coordinated AP that the latter has, in its turn, to send a (conventional) BSRP Trigger frame to its own associated stations to obtain their individual BSRs to build the MAP BSR reports. An exemplary scenario using the Accurate field is illustrated with reference to Figure 7c described below. Next, responsive to the MAP BSRP Trigger frame 701, the addressed APs (with one of the User Info fields carrying their identifier) send each a MAP BSR 702, 703 as a response to the sharing AP in the resource allocated in the respective User Info field. The MAP BSR informs the sharing AP about the addressed BSS’s needs in term of resource allocation. The MAP BSR may include an individual BSR of the addressed AP only, or overall needs corresponding to summed needs for the addressed BSS (sum of the needs of the stations in the addressed BSS). The MAP BSR is filled in following the requirements (Figure 9) defined by the sharing AP. The MAP BSR may have the same format as the (conventional) BSR defined in the REVme / D4.1 standard, Section 9.2.4.7.4. In a variant, a new format may be defined for the MAP BSR as for example shown in Figure 10a. This MAP BSR 1010 includes at least one of the following fields: - DL TID field 1011 to indicate the highest TID corresponding to the DL queue size, - DL Queue Size field 1012 to indicate the quantity of DL data to transmit by the addressed AP to its associated stations, - UL TID field 1013 to indicate the highest TID corresponding to the UL queue size, - UL Queue Size field 1014 to indicate the quantity of UL data that the stations associated with the addressed AP have to transmit, - DiL Queue Size field 1015 to indicate the quantity of DiL / P2P data that the stations associated to the addressed AP have to transmit in direct link transmission. In some embodiments, DiL Queue Size and UL Queue Size can be merged into a single field as it represents all the data the station has to transmit. In some embodiments, the Queue Size fields may be transmitted along with a Scaling factor (as an additional field) to virtually extend the maximum queue sizes that the BSR could transmit. With this kind of BSR, the sharing AP may more easily schedule further coordinated transmission and also prevent simultaneous UL and DL transmissions at the same time that could lead to interference when close stations operate one as receiver and another one as emitter. In that case, the emitter station may prevent the receiver station from correctly decoding its frame if the receiver station uses a high level of power for its transmission. In some embodiments distinguishing from individual BSR or summed BSRs, the MAP BSR may report a set (list) of one or more individual BSRs corresponding to one or more stations (including the addressed AP) of the addressed BSS. It may be noted that such individual BSRs may be obtained by the addressed AP upon specific (BSRP) request in the addressed BSS (as described below with reference to Figure 7c, possibly as a response to enabled Accurate field 905) or spontaneously from the individual stations. An exemplary individual BSR is shown in Figure 10b. The individual BSR includes AID12 field 1021 which identifies the station concerned (using its AID within the addressed BSS), TID field 1022 which indicates the highest TID corresponding to the queue size and Queue Size field 1023 which indicates the quantity of data that the station identified by AID12 field 1021 is pending for transmission. In variants (not shown), Queue Size field 1023 is replaced by a Medium Time field and a Bandwidth field. The Medium Time field contains an unsigned integer that specifies the medium time, in units of 256 microseconds, requested by the AP for MAP transmissions as the average medium time needed in each second, based on the bandwidth indicated in the Bandwidth field for MAP transmissions. The Bandwidth field specifies the maximum bandwidth the AP can operate for MAP transmissions. This field is used to compute the medium time requested in the Medium Time field. The total resource requested is the product of the medium time and bandwidth. The bandwidth may be the maximum bandwidth possible on the link / channel over which the individual BSR is transmitted by the respective station. In some embodiments, a linkID field may also be provided to identify a preferred link (in case of MLDs) on which the resource needs specified in the individual BSR are requested. The available links may be known by the stations, after the sharing AP has advised about them. Back to the example of Figure 7a, AP2 and AP3 then send each a MAP BSR respectively 702 for AP2 and 703 for the AP3 to sharing AP AP1. Phase 700a that represents a bandwidth requirement exchange (MAP BSRP / BSR frames exchange) may take place in the same or in a different TXOP than the TXOP used for data exchange. Once the bandwidth requirements are known by the sharing AP, a trigger-based data exchange involving MAP resource sharing may start as shown through reference 799. Sharing AP AP1 (TXOP owner) sends a MAP MU-RTS Trigger frame 710 addressed to AP2 and AP3 (surrounded APs or APs belonging to an already created MAP group). As for the MAP BSRP Trigger frame, the MAP MU-RTS Trigger frame 710 is identified using any signalling method as described above. Again, RA field 303 of this MAP MU-RTS Trigger frame is set to the Broadcast address as it is addressed to several APs. Upon reception to this MAP MU-RTS Trigger frame 710, addressed AP2 120 and AP3 130 respond with a CTS frame to the AP1. Any station receiving MAP MU-RTS Trigger frame 710 or CTS response frame 711 / 712 or both set their NAV. Thereby this MU-RTS / CTS procedure protects the medium to be accessed by unexpected stations and then protects the subsequent trigger-based transmission operates by the TXOP owner or solicited stations. The CTS response 711 / 712 by the addressed APs advantageously allows a larger area than the MU-RTS itself to be protected. Next, once the medium is protected, sharing AP AP1 sends a MAP Basic Trigger frame 720 to coordinated AP2 and AP3. This MAP Basic Trigger frame includes the definition of the resources allocated to different stations (coordinated APs or / and non-AP stations). Preferably, the resource allocation in the MAP Basic Trigger frame is based on the MAP BSR 702 / 703 received previously. In embodiments, the MAP Basic Trigger frame is based on the resource allocation scheduling determined at step 443 (the frame may have been built at the time of that step). As for the previous MAP Trigger frames, the MAP Basic Trigger frame 720 is identified using any signalling method as described above. Again, RA field 303 of this MAP Basic Trigger frame is set to the Broadcast address as it is addressed to several APs (AP2 120 and AP3 130 in the example of this figure). The MAP Basic Trigger frame 720 may allocate resources (hence trigger) to coordinated APs only, to non-AP stations of coordinated BSSs, to non-AP stations associated to the sharing AP, or a combination thereof. An appropriate signalling (of AID or AP IDs) in the User Info fields allows these various types of stations to be addressed / triggered in the same MAP Basic Trigger frame. Sharing AP AP1 may also include a User Info field to itself into the MAP Basic Trigger frame in order to indicate, to the other APs (and its associated stations), its intention to directly use part of the band unallocated to the other APs. Responsive to receiving this MAP Basic Trigger frame, the triggered stations (AP1, AP2 and AP3 in the example of the Figure) can communicate within their allocated resources as indicated in their respective User Info fields. As an example, a coordinated AP solicited by the MAP Basic Trigger frame may operate (721 for AP1, 722 for AP2 and 723 for AP3) within its allocated resource as if it was the TXOP owner on this resource, for the time defined in the MAP Basic Trigger frame. That means the coordinated AP may transmit DL data to its associated stations (SU or MU mode), trigger MU UL OFDMA transmissions, and so on. Any conventional communication scenario within the coordinated BSS may be used, as exemplified for instance by Figures 2a, 2b and 2c. Figure 7b illustrates a second example of frame exchange still starting with a MAP BSRP procedure to obtain resource needs, followed by a MAP MU-RTS procedure to protect the subsequent coordinated communications that are triggered by a MAP Basic Trigger frame. In the example of the Figure, the MAP BSRP Trigger frame 730 is addressed at the same time to stations (here station STA11) associated to the sharing AP sending the MAP BSRP Trigger Frame and to surrounded APs (AP2 and AP3). In that case, the MAP BSRP procedure solicits both associated stations and other APs. As mentioned above (scenario of Figure 7a), the MAP BSRP Trigger Frame may provide some constraints / requirements for the MAP BSRs. Responsive to this MAP BSRP Trigger frame, each station (associated station STA11 and coordinated APs AP2 and AP3) addressed by one User Info field responds with a conventional BSR (for STA11) and MAP BSR (for AP2 and AP3) to the sharing AP. The format of the MAP BSR is discussed above (scenario of Figure 7a). The content of the MAP BSR depends on the constraints / requirements set in the MAP BSRP Trigger frame. Thereby, if the BSRP only request needs for UL, the MAP BSR includes information related to Uplink (and potentially DiL). As for the scenario of Figure 7a, resource need collection phase 700b may take place in the same or in a different TXOP than the TXOP used for data exchange. Once the bandwidth requirements are known by the sharing AP, a trigger-based MAP coordination Bandwidth Sharing 799 may start. Figure 7b proposes the same trigger-based data exchange as Figure 7a described above. Figure 7c illustrates a third example of frame exchange starting with an enhanced MAP BSRP procedure to obtain more accurate resource needs, followed by a MAP MU-RTS procedure to protect the subsequent coordinated communications that are triggered by a MAP Basic trigger frame. This variant presents a different buffer status collection through the MAP BSRP procedure. In the example of the Figure, the MAP BSRP Trigger frame 730 is still addressed at the same time to stations (here station STA11) associated to the sharing AP sending the MAP BSRP Trigger Frame and to surrounded APs (AP2 and AP3), as in Figure 7b. In this scenario, the MAP BSRP Trigger frame 730 requires the addressed APs to solicit their associated stations for individual BSR collection. This may be done by setting Accurate field 905 to 1 (Figure 9). Furthermore, the MAP BSRP Trigger frame 730 may set a duration (NAV(BSRP)) to cover the whole procedure 700c (i.e., BSRP duration + BSR duration + MAP BSR duration). Responsive to this MAP BSRP Trigger frame, each station (associated station STA11 and coordinated APs AP2 and AP3) addressed by one User Info field responds with a conventional BSR (for STA11) and MAP BSR (for AP2 and AP3) to the sharing AP. The format of the MAP BSR is discussed above (scenario of Figure 7a). STA11 responds to AP1 with a conventional BSR 731. On their end, AP2 and AP3 which have been solicited by AP1 solicit in turn the stations of their own BSS by sending a respective conventional BSRP Trigger frame 740 / 750 addressing their associated stations. Upon reception of the BSRP Trigger frame 740 / 750 from their associated APs AP2 / AP3, the stations solicited by those BSRP Trigger frames respond with individual BSRs to their associated APs. In the example, STA21 and STA22 respond to AP2 respectively with BSR frames 741 and 742. Similarly, STA31 and STA32 respond to AP3 respectively with BSR frames 751 and 752. As a result, each solicited AP can respond to the sharing AP (AP1) with an up-to-date MAP BSR: AP2 responds to AP1 with MAP BSR 732 included the information gathered from its associated stations, while AP3 responds to AP1 with MAP BSR 733 included the information gathered from its associated stations. These MAP BSR frames 732 and 733 may take the conventional format or any other format (shown in Figures 10a and 10b) as described previously in the scenario of Figure 7a. They may provide the summed needs for each coordinated BSS or a list of individual needs of the stations of each coordinated BSS. As for the preceding scenarios, resource need collection phase 700c may take place in the same or in a different TXOP than the TXOP used for data exchange. The BSRs and MAP BSRs obtained from the different APs or stations presented in the procedure 700a, 700b and 700c using frequency-based allocation may also be collected using time-based allocation, in which case they are retrieved sequentially in a TDMA manner. Figure 13 below illustrates a scenario where the BSRs and MAP BSRs are collected using time-based allocation, in particular using the TXS mode. Once the bandwidth requirements are known by the sharing AP, a trigger-based MAP coordination Bandwidth Sharing 799 may start. The MAP MU-RTS / CTS exchange is similar to the scenarios of Figures 7a and 7b. Next, once the medium is protected, the sharing AP (AP1) sends a MAP Basic Trigger frame 780 addressed to stations of its own BSS (STA11) and stations of the coordinated BSSs (STA21 associated with AP2 and STA31 and STA32 associated with AP3). In other words, the sharing AP provides the whole resource allocation for the MAP group for the coordinated communication. This allows the sharing AP to directly control which stations will communicate and then prevent interference with this own intra-BSS communication. This trigger fame includes the definition of the resource allocated to the different stations. Following the reception of MAP Basic Trigger frame 780, the triggered stations communicate into their allocated resources with their respective APs (uplink data) or with peer stations (DiL or P2P data). In the example shown, STA11 sends uplink data 781 to AP1 on the channel allocated by the respective RU allocation subfield, STA21 sends uplink data 782 to AP2 on the channel allocated by the respective RU allocation subfield, and STA31 and STA32 send uplink data (783 for STA31 and 784 for STA32) to AP3 on the channels allocated by the respective RU allocation subfields. The receiving entities (here associated APs) can then acknowledge the data: AP1 acknowledges the reception of the uplink data from STA11 by sending Block Ack frame 785 including the acknowledgement for STA11, AP2 acknowledges the reception of the uplink data from STA21 by sending Block Ack 786 including the acknowledgement for STA21, and AP3 acknowledges the reception of the uplink data from STA31 and STA32 by sending Multi-STA Block Ack 787 including the acknowledgements for STA31 and STA32. Of course, although the sharing AP allocates resources to non-AP stations in this example, it is possible for it to allocate resources to non-AP stations (of its own BSS and / or of coordinated BSSs) and also to one or more coordinated APs for them to perform downlink transmission or to use the allocated resources as it was an own TXOP. Although the scenarios of Figures 7a, 7b and 7c are based on MAP BSRP and BSR frames, the same scenarios may be implemented with other types of MAP Resource Report Request frames and MAP Resource Report frames, such as a MAP MU-RTS Trigger frame followed by a MAP CTS frame in response. For example, Figure 7c1 illustrates another example of frame exchange starting with a MAP Resource Report procedure to obtain more accurate resource needs, followed by a MAP MU-RTS procedure to protect the subsequent coordinated communications. Figure 7c1 is based on Figure 7c with no solicitation of the stations (STA11) associated to the sharing AP. The same references correspond to the same items. In the example of the Figure, the MAP Resource Report Request frame 730 is addressed to surrounded APs (AP2 and AP3). AP2 and AP3 which have been solicited by AP1 solicit in turn the stations of their own BSS by sending a respective conventional BSRP Trigger frame 740 / 750 addressing their associated stations. Upon reception of the BSRP Trigger frame 740 / 750 from their associated APs AP2 / AP3, the stations solicited by those BSRP Trigger frames respond with individual BSRs to their associated APs, as explained above with reference to Figure 4b. In the example, STA21 and STA22 respond to AP2 respectively with BSR frames 741 and 742. Similarly, STA31 and STA32 respond to AP3 respectively with BSR frames 751 and 752. As a result, each solicited AP can respond to the sharing AP (AP1) with an up-to-date MAP Resource Report: AP2 responds to AP1 with MAP Resource Report frame 732 including the information gathered from its associated stations, while AP3 responds to AP1 with MAP Resource Report frame 733 including the information gathered from its associated stations. The resource needs for the coordinated AP (AP2 or AP3) may also be counted or included in the MAP Resource Report sent. The MAP resource reports obtained from the different APs using frequency-based allocation may also be collected using time-based allocation, in which case they are retrieved sequentially in a TDMA manner. Figure 13 below illustrates a scenario where the MAP Resource Reports are collected using time-based allocation, in particular using the TXS mode. Hence, responsive to the MAP Resource Report Request frame, each coordinated APs (AP2 and AP3) addressed by the sharing AP (for instance by one User Info field in frame 730) responds with a MAP Resource Report frame to the sharing AP in the resource allocated in the respective User Info field. The MAP Resource Report informs the sharing AP about the addressed BSS’s needs in term of resource allocation. The MAP Resource report may include the overall needs corresponding to summed needs forthe addressed BSS, i.e., the sum of the needs of the stations (optionally including the coordinated AP) in the addressed BSS and may also include needs for P2P communication. An exemplary format of the MAP Resource Report is shown in Figure 10c. The following fields may be embedded in an information element. This MAP resource report 1030 preferably includes a duration and a bandwidth using the following fields: - Bandwidth field 1034 to indicate the maximum supported bandwidth (20 / 40 / 80 / 160 / 320MHz). This field may however be optional if the link ID (described below) defines the maximum supported bandwidth or if a bandwidth for MAP operation has been defined previously, e.g. during a MAP group creation. In other words, if the bandwidth is already known by both coordinated and sharing APs by any means, there is no need to provide it again. - Duration field 1035 to indicate the duration, in units of 32 ps (or any other 2An unit), that the coordinated AP determines it needs for its next bandwidth sharing (for the specified TID described below, if any). Such field may be similar to the duration field of the MU-RTS TXS as described in section 9.2.4.5.7 of the REVme / D4.1 standard. This duration defines the time needed by the coordinated AP to operate in the next TXOP or on average, based on the bandwidth indicated in the Bandwidth field (or predefined bandwidth) for MAP transmissions. In more sophisticated embodiments, the MAP resource report 1030 also includes at least one of the following fields: - TID / SCSID field 1031 to indicate the highest TID of the data used to compute the resource report. It may be the TID corresponding to data having the highest priority from amongst data for which resources are needed. It may be used by the sharing AP to prioritize coordinated APs with the higher TID. SCSID may also be used to indicate a specific SCS stream used to compute the resource report. The SCSID definition can be shared formerly between the sharing and the coordinated AP. For instance, the value of the SCSID may be the value which identifies the traffic flow in the reporting AP’s BSS or an identifier used to identify a resource sharing agreement between the sharing AP and the coordinated AP. This identifier can be used to define and update an agreement responding to a static allocation need; - Link ID field 1032 to identify a link on which the coordinated AP is requesting resources from all setup links with the sharing AP. This field is present if the MAP Resource Report is sent on a management link. The Link ID may be negotiated during the creation of the MAP Group if the MAP Group has common links. The Link ID field may be replaced by Channel or Band indication if no link ID is defined by the MAP Group. For instance, the channel indication may indicate the primary channel on which the coordinated AP is requesting resources. The channel indication together with the Bandwidth field 1034 (e.g. set to the maximum supported bandwidth) can thus define all the channels on which the coordinated AP is requesting resources; - Direction field 1033 to indicate a direction of transmission of data for which resources are needed. The direction values could Downlink, Uplink, Direct link, Any, or even a combination thereof (e.g. UL and DiL). With this kind of information, the sharing AP can more easily schedule further coordinated transmission and also prevent simultaneous UL and DL transmissions at the same time that could lead to interference when close stations operate one as a receiver and another one as an emitter. In that case, the emitter station may prevent the receiver station from correctly decoding its frame if the receiver station uses a high level of power for its transmission. - Lifetime field 1036 to indicate the validity duration of the resource needs reported. This field may be built as the MSDU lifetime defined in section 9.4.2.316 of the D5.0 standard. A value set to 0 indicates a static allocation need, for instance corresponding to one or several traffic flows requirement coming from QoS characteristics and negotiated between the coordinated AP and its associated non-AP stations. In embodiments, a static allocation need is used as default requirement for MAP coordination (minimal requirement) to be set up at each bandwidth sharing opportunity (if possible) while a dynamic allocation need is used for limited duration, such as a limited number (1 or several) of bandwidth sharing opportunities. The full version of Figure 10c gives complete information to the sharing AP and let it decide which type of traffic or which coordinated AP to prioritize. In some embodiments not shown, the MAP Resource Request frame 730 is a MAP MU RTS Trigger frame for which the addressed APs have, in a first step, to respond with a CTS frame to protect the medium, the CTS frame being duplicated by all responding AP and occupying the complete bandwidth and then in a second step, to send their MAP Resource Report in their respective resource allocated by the MAP MU-RTS Trigger frame. In particular embodiments, the MAP Resource Report is included in the response CTS frame, which, in this case, is a new variant of the CTS itself to convey such report. In other particular embodiments, as shown in the scenario of Figure 13, the MAP Resource Report is embedded in an acknowledgment frame, such as an IEEE Multi-STA BlockAck frame. In those embodiments based on the MAP MU-RTS Trigger frame, the BSRP / BSR procedure to gather the individual needs of the associated stations may be omitted to ensure the CTS response is sent in appropriate time to protect the medium. In that case, the MAP Resource Report may be built using BSRs formerly received from the associated stations and / or using resource reservations negotiated by the coordinated AP with its associated stations (e.g. traffic characteristics defined by TSPEC or QoS characteristics) and / or based on the own resource needs (internal buffer) of the coordinated APs for downlink transmissions. More generally (i.e., for any type of MAP Resource Request frame), the coordinated AP may prepare the MAP Resource Report based on information it already has, without soliciting its associated stations to obtain their BSRs. This saves time. In most simplified embodiments, the MAP Resource Report is reduced to a single bit to binary indicate whether there are some data to transmit within the coordinated BSS or not. In that case, the sharing AP may allocate a fixed duration and bandwidth to the coordinated AP. Alternatively, the duration and bandwidth may be determined based on previous MAP Resource Report or Reports received from the same coordinated AP, which reports include static allocation (e.g. with Lifetime field 1035 set to 0). In some embodiments, rather than providing a specific frame to the sharing AP, the coordinated AP may include its MAP Resource Report in the Beacon frames it sends. For example, the MAP Resource Report may be included in the Traffic Indication Map (TIM) of the Beacon frame, for instance by setting the bit corresponding to the AID12 of the sharing AP to 1 to indicate that the coordinated AP has data to transmit to it or not. Such bit set to 1 thus means that the coordinated AP asks for a medium time in the subsequent MAP coordination to the sharing AP and is set to 0 in case it does not require medium time. In specific embodiments, policies / rules at an AP may allow an use of the (1 bit) TIM signalling to report resource needs only in specific cases, such as when the own Transmission Opportunities of the reporting AP are not enough to serve all its associated stations or when a critical traffic (e.g., low latency or high reliability or Emergency Preparedness Communications Service or EPCS - that needs a quick retransmission or access) is known within the BSS. Once the resource needs are known by the sharing AP, a trigger-based data exchange involving MAP resource sharing may start as shown through reference 799. The sharing AP (owner of the TXOP) sends a MAP Trigger frame to neighbouring APs, e.g. to those APs with which it intends to perform resource sharing. As mentioned previously, the decision on which coordinated AP to target is based on the MAP Resource Reports received from the various neighbouring APs (e.g. belonging to the same MAP Group), and possibly on sharing policies / rules the sharing AP (or MAP group) implements. In the example of the Figure, a MAP MU-RTS Trigger frame 710 is sent by sharing AP AP1 to AP2 and AP3. Upon reception to the MAP Trigger frame 710, addressed AP2 120 and AP3 130 respond with a CTS frame to sharing AP AP1. Any station receiving MAP Trigger frame 710 or CTS response frame 711 / 712 or both set its NAV. Thereby, the MU-RTS / CTS procedure protects the medium from any access by unexpected stations and then protects the subsequent triggerbased transmission operates by the TXOP owner or solicited stations. The CTS response 711 / 712 by the addressed APs advantageously allows a larger area than the MU-RTS itself to be protected. Next, once the medium is protected, the sharing AP (AP1) can efficiently allocate resources to the coordinated APs based on the resource needs as reported in the MAP Resource Report frames. The sharing AP may share the medium according to different ways, C-TDMA for instance by using a MU-RTS TXS Trigger frame, C-FDMA by using a MU-RTS and / or Basic Trigger Frame, in a similar way as those presented above with reference to Figures 2a, 2b and 2c. The sharing AP may also consider Spatial Reuse (SR) in between the APs of the MAP Group. The scenario of Figure 7c1 can be summarised as follows. A coordinated AP receives, from a sharing AP, a MAP Resource Report Request allocating resources to the coordinated AP and soliciting a MAP Resource Report response in the allocated resources. Responsive to receiving the request, the coordinated AP polls its associated stations to obtain individual needs, using the BSRP / BSR scheme. Based on the obtained needs and its own needs, the coordinated AP determines a resource allocation scheduling allocating resources to its associated stations. The resource allocation scheduling is converted into duration and bandwidth information. The latter are included in a MAP Resource Report that is sent to the sharing AP in response to the request. The scenario of Figure 7c and of Figure 7c1 can be slightly modified so that new frames are emitted after the BSR 741 / 742 (respectively 751 / 752) and the MAP-BSR reports 732 (respectively 733): as example a subsequent TF 730 is emitted by the sharing AP1 so that the MAP-BSR frames 732 and 733 are triggered in time. Figure 13 illustrates yet another exemplary scenario of frame exchange, that is TXS-based, to gather the MAP Resource Reports using time-based allocation provided by the sharing AP. This scenario also reuses an acknowledgment frame format, such as an IEEE Multi-STA BlockAck frame, to convey the MAP Resource Reports (or MAP BSRs) from the coordinated APs, within the timeslot (portion) allocated to them by the sharing AP through the TXS mode. This can be seen as an alternate of the scenario of Figure 7c concerning the obtaining of individual BSR(s) in a shared BSS in order to build the MAP BSR(s) towards the sharing AP. C-TDMA is used rather than FDMA to collect the BSRs. As shown, Trigger Frame 1330 initiates a slotted MAP BSRP procedure, that is to say TF 1330 enables the TXS mode for obtaining BSR information and reporting a MAP BSR to the sharing AP: each triggered (coordinated) AP successively uses a TXS timeslot. Once the bandwidth requirements of the coordinated APs (or BSSs) are known by the sharing AP, a trigger-based data exchange involving MAP resource sharing may start as shown through reference 799, as described before. This can be performed in the same TXOP or or any subsequent TXOP obtained by the sharing AP1 or any AP belonging to the MAP group including AP1. In more details, sharing AP AP1 (TXOP owner) sends Trigger frame 1330 addressed to AP2 and AP3 (surrounded APs or APs belonging to one or more already created MAP group(s)). As TF 1330 polls the coordinated APs and collects the MAP BSRs from them using the TXS mode, TF 1330 may be named ‘TXS-MAP BSRP’ or ‘MAP TXS-BSRP’ below. As for the MAP BSRP Trigger frame, the MAP TXS-BSRP Trigger frame 1330 is identified using any signalling method as described above. For example, the MAP TXS-BSRP Trigger frame 1330 is a MU-RTS Trigger frame (i.e., a Trigger frame having its Trigger type in the Common Info field set to 3) having the TXS Type subfield 316 in the Common Info field set to 3 to initiate a TXS procedure for MAP purposes. In another example, the MAP TXS-BSRP Trigger frame 1330 is a BSRP Trigger frame (i.e., a Trigger frame having its Trigger type in the Common Info field set to 4) having the Gl And HE / EHT / UHR-TLF Type (which can be renamed TXS Type) subfield 316 (bits B20-B21) in the Common Info field set to 3 (or 1 or 2) to initiate a TXS procedure for MAP purposes. Alternatively, the MAP TXS-BSRP Trigger frame 1330 may have a Trigger Type field 311 in the Common Info field that signals MAP purposes, e.g. any value 9-15 of the Trigger Type may define a MAP MU-RTS Trigger frame ora MAP BSRP Trigger frame. In that case, the Trigger frame 1330 has the TXS Type subfield 316 in the Common Info field set to 1 or 2 or 3 to initiate a TXS procedure, incidentally for MAP purposes. Trigger frame 1330 may include constraints / requirements for the MAP BSRs as described above, e.g., based on traffic types, such as UL, DL, DiL, specific TID, specific stations. RA field 303 of Trigger frame 1330 is set to the Broadcast address as it is addressed to several coordinated APs. As a result of the TXS procedure, multiple coordinated APs are provided by respective timeslots within the obtained TXOP. The scenario of the Figure shows two timeslots allocated to respectively AP2 and AP3. While not illustrated, one may easily understand that only one TXS slot is also supported. Trigger frame 1330 is addressed to surrounding APs (AP2 and AP3), as in Figure 7a / 7b. In the scenario shown, Trigger frame 1330 requires the addressed APs to poll, within their own TXS slot, their associated stations for individual BSR collection. As shown, a TXS slot is therefore formed of a BSRP trigger frame (to poll the stations of the BSS), the triggered BSRs from the polled stations and the MAP BSR to the sharing AP. While not illustrated, a CTS response frame (such as 711 / 712) may be contemplated in the TXS slot before the BSRP trigger frame, to acknowledge TF 1330. This procedure protects the medium access owned by the sharing AP and can be explicitly indicated by the value of CS required bit 314. Responsive to Trigger frame 1330, each coordinated AP (AP2 and AP3) addressed by one User Info field therein, solicits in turn the stations of their own BSS by sending a respective conventional BSRP Trigger frame 740 / 750 addressing their associated stations, within the allocated TXS slot. Upon reception of the BSRP Trigger frame 740 / 750 from their associated APs AP2 / AP3, the stations solicited by those BSRP Trigger frames respond with individual BSRs to their associated APs. In the example, STA21 and STA22 respond to AP2 respectively with BSR frames 741 and 742 (during the first TXS slot allocated to AP2). Similarly, STA31 and STA32 respond to AP3 respectively with BSR frames 751 and 752 (later, during the second TXS slot allocated to AP3). Thanks to the TXS procedure, each coordinated AP identified in TF 1330 and triggered in a non-TB format can use the Single User (SU) transmission mode. In other words, the PPDU sent in response to Trigger frame 1330 can be a non-HT PPDU that contains the MAP Resource Report (MAP BSR). Figure 12 illustrates an exemplary frame format for reporting MAP Resource needs, based on a Multi-STA Block Ack format, according to embodiments. This can advantageously be sent in SU transmission mode. The frame used to report MAP Resource needs is an acknowledgement frame. In particular, in the scenario of Figure 13, the MAP Resource Report frame acknowledges the BSR frames (741 and 742 for BSS2) received from the polled non-AP stations (STA21 and STA22 for AP2). Indeed, the sequence BSRP trigger frame 740 / triggered BSR frames 741 / 742 is usually terminated by an acknowledgment frame that concludes the sequence. As a result, the coordinated AP is provided a seamless way to send (step 445) its MAP Resource Report frame (e.g., obtained at step 443) to be used directly by the sharing AP. More generally, the format of Figure 12 can more broadly be used for steps 444 / 445, when considering the emission of MAP Resource Report frames 702 / 703, 732 / 733 (solicited cases) and / or 770 / 760 / 780 / 790 (unsolicited cases). Of course, this is not limitative and the MAP Resource Report frame with format 1200 may be sent by an AP to another AP at any time (that means without any triggering by the recipient AP). By extension, even if provided scenarios concern the sending of a BSR information in between APs, the proposed Multi-STA Block Ack is not limited to this embodiment and may be contemplated to report BSR information among any STAs, being AP or non-AP stations. Following description will explicit those possibilities. As shown in Figure 12, the MAP Resource Report frame is a BlockAck frame (i.e., an IEEE802.11 Medium Access Control frame having a Type value and Subtype value set respectively to ‘01’ and ‘1001’ in a Frame Control field) comprising an entry in a BA Information field, which entry reports the resource needs for the coordinated AP or BSS. In this context, a general communication method in a wireless network, comprises at a station: transmitting a BlockAck frame comprising an entry in a BA Information field, which entry reports resource on station side. The station may report its own needs or those of its BSS or both. Indeed, as apparent from below, the acknowledgment frame is enhanced to a new function for which it has not been created initially, namely to convey the BSRs. The BlockAck frame may still acknowledge some frames, or may not longer acknowledge frames in which case it can be used only for MAP Resource reporting. In embodiments, the BlockAck frame is a Multi-STA BlockAck frame. Such a frame format is defined in IEEE P802.11be / D7.0 as a BlockAck frame where the BA Type (signalling BlockAck frame variant) subfield is set to 11. Alternatives may however be contemplated, such as defining a new BlockAck frame variant (using any value from 12-15) to signal MAP Resource reporting. An exemplary enhanced format of BlockAck frame 1200 is depicted in Figure 12, wherein: The RA field of the BlockAck frame 1200 is set to the sharing AP to which the MAP Resource report is addressed, in particular when there is only one Per AID TID Info field 1202 addressed to that sharing AP. In embodiments, the transmitting coordinated AP may send a BlockAck frame 1200 with multiple Per AID TID Info fields 1202 addressed to more than one associated STA in addition to the sharing AP, in which case the RA field is set to the broadcast address. Also, in embodiments that allow a broad sharing the MAP Resource report, the RA field may set to the broadcast address so that all the APs of the MAP Group to which the transmitting coordinated AP belongs can become aware of the resource needs of the transmitting coordinated AP; The TA field is the address of the transmitting coordinated AP transmitting the BlockAck frame; The BA Control field 1201 of the BlockAck frame 1200 comprises at least BA Type field 1203. The BA Type field 1203 may be set to 11 to signal a BlockAck frame of the “Multi-STA” type in some embodiments, or to any reserved value (12-15) in other embodiments as described below; The BA Information field 1202 of the BlockAck frame 1200 comprises one or more Per AID TID Info subfields, each composed of an AID TID Info 1210 and an Extension field 1210a which may be either a legacy format 1220 (according to IEEE802.1 IREVme D7.0, comprising a Block Ack Sequence Control and Block Ack Bitmap subfields) or a MAP Resource report field 1230 according to embodiments. MAP Resource report field 1230 is dedicated to conveying (to the sharing AP) the various BSR variants (1010, 1020, 1030) illustrated above with regards to Figure 10a, 10b or 10c. One of preferred variant consists in providing Duration (Medium Time) field 1035 and Bandwidth field 1034, representative of the collected needs per coordinated BSS. We can note that the Bandwidth field can be optional if the bandwidth is predefined or formerly pre-agreed (e.g., between a set of APs belonging to one or several MAP groups), or if the bandwidth corresponds to the bandwidth used for the transmission of the BSRP frame or information carried in the BSRP frame (which bandwidth may be the same as TF 1330). The format of the Extension field 1210a (either 1220 or 1230) can be signalled in different ways. In embodiments, a dedicated BA Type (field 1203) value can be used (from 12 to 15). In variants, bits in the TIDJNFO subfield of the BA Control field 1201 could be used. More generally, any other bits in the BA Control field 1201 may be contemplated instead, such as reserved bits B5 to B8. In other embodiments, BA Type field 1203 is set to 11 to signal a BlockAck frame of the “Multi-STA” type. The (2-byte) AID TID Info subfield 1210 in the Multi-STA BlockAck frame 1200 can be used to signal the format of the Extension field 1210a. As shown, the AID TID Info subfield 1210 is made of (11-bit) AlD11 subfield 1211, (1-bit) Ack Type subfield 1212 and (4-bit) TID subfield 1213. The AID11 subfield 1210 carries the 11 LSBs of the AID of the station for which the Per AID TID Info subfield is intended. In embodiments, the format of the Extension field 1210a (hence of the Per AID TID Info subfield) depends on the value of the AID11 subfield. If the Multi-STA BlockAck frame 1200 is sent to an AP (e.g., sharing AP), the AID11 subfield 1210 is set to a non-zero identifier of the AP, APJD. This distinguishes from conventional use of the AID11 subfield 1210 either set to an identifier of a non-AP station or to 0 to signal the AP of the current BSS. In the present disclosure, there is an IEEE 802.11 BlockAck frame to be sent by a transmitting station, the BlockAck frame comprising a BA Control field and a BA Information field, the BA Information field comprising one or more entries, one of the entries reporting, to an access point (AP), resource needs at transmitting station’s side and having an AID11 subfield set to an identifier of the AP. Therefore, an APJD in the AID11 subfield 1210 may signal the Extension field 1210a is MAP Resource report field 1230. In a variant, a specific or dedicated value (e.g. 2008 or 2009) may be used in the AID11 subfield 1210 to signal the Extension field 1210a is MAP Resource report field 1230. In that case, the Extension field 1210a may include a subfield to carry an identifier (APJD) of the addressed AP, prior to the Resource report (BSR) information or into the BSR information (even if it is less efficient in term of decoding process). In other words, a specific value (e.g. 2008 or 2009) in the AID11 subfield is used to identify a Per AID TID Info field that carries a BSR intended to all recipient APs. In these embodiments, the Ack Type subfield 1212 and TID subfield 1213 are not used to determine the format of the Extension field 1210a. They, in particular TID subfield 1213, may be used to signal which traffic is reported in the MAP Resource Report 1230. For example, a TID-based reporting may be provided. In that case, more than one Per AID TID Info subfield 1202 with the same value in the AID11 subfield but with different values in the TID subfield 1213 can be present in the Multi-STA BlockAck frame 1200. The Extension fields 1210a in the multiple Per AID TID Info subfield 1202 may follow the same or different MAP Resource Report formats, such as formats 1010, 1020, 1030 but also bandwidth / duration format or duration-alone format. In alternative embodiments to the above, the specific value (e.g. 2008 or 2009) may be used merely to signal the entry (Per AID TID Info subfield 1202) is addressed to a group of APs, e.g. to all APs of one or more MAP groups. In that case, the proposed format allows the Multi-STA BA variant frame 1200 to also be addressed to several APs. Whatever the case of using the specific value or an APJD in the AID11 subfield 1211, the signalling of the Extension field format may be provided through the Ack Type-TID subfields 1212-1213. Table 1250 shows the remaining values currently reserved (unused) by the IEEE802.11 standard. Especially, TID values from 8 to 15 are not used in QoS Data frame (since HCCA protocol is now deprecated) and can be used to the above signalling. As an example, if the AID11 subfield of the AID TID Info subfield is not 2045 (used for unassociated stations), and if the Ack Type subfield is equal to 0 and the TID subfield is equal to 15 (or any reserved value) then the Per AID TID Info subfield 1202 carries a Resource Report entry. In a detailed example where the Ack Type subfield 1212 equals to 0 and the TID subfield 1213 equals to 15, the Per AID TID Info subfield 1202 includes BSR feedback information instead of Acknowledgement status; the AID11 subfield of the AID TID Info subfield is set to the APJD of the AP that is the intended receiver of the BSR feedback information or to 2008 if the BSR feedback information is intended to any receiving AP (e.g. the ones of the MAP set); and a BSR Feedback / report subfield 1230 is included in the Extension field 1210a of the Per AID TID Info field instead of a Block Ack Bitmap subfield; and the BSR subfield may take the format of either 1010, 1020, 1030 or bandwidth / duration information (1034 + 1035) or duration alone (1035). Thanks to the proposed signalling through the Ack Type-TID subfields 1212-1213, more than one Per AID TID Info subfield 1202 with the same value in the AID11 subfield but different formats (the legacy one 1220 and the new one 1230) can be provided in the same Multi-STA BlockAck frame 1200. For example, a non-AP station may report, in distinct Per AID TID Info entries 1202, an acknowledgment according to the legacy format 1220 in addition to reporting a BSR according to the new format 1230, both to its associated AP (value 0 as AID11). More generally, the BA Information subfield 1202 may comprise at least one additional (to the entry reporting resource needs) entry which acknowledges at least one frame received from a non-AP station of the second BSS. This is the case in the scenario of Figure 13 due to the BSR polling (frames 740-741 / 742). It also means that the entry reporting resource needs may not be accompanied by an acknowledging entry in the frame, in particular when there is no BSR polling at BSS level. Back to operations such as in the scenario of Figure 13, an AP (shared AP) receiving a MAP TXS-BSRP trigger frame 1330 from another AP (sharing AP) sends an “acknowledgment” frame 1200 as a response, which frame 1200 sets the Ack Type field 1212 to 0, AID11 subfield 1211 to the APJD of the AP, and TID field 1213 to 15 (or any reserved value) in the Per AID TID Info field (entry 1202) and sets the MAP BSR 1230 in the Extension subfield 1210a to indicate the collected BSR for its BSS. Individual BSRs in the BSS may be gathered through a BSR polling triggered by the MAP TXS-BSRP trigger frame 1330 as shown in Figure 13 or the BSRs may have been collected beforehand. The MAP BSR may be an aggregation (sum) of the individual BSRs from the non-AP stations of the BSS, optionally supplemented by the own needs of the reporting AP (for its own UL / DL transmissions). Frame format 1200 of Figure 12 provides the MAP BSR in the Extension field 1210a, to keep format compliant with the legacy target (acknowledgment). Of course, alternative formats may be contemplated such as providing the MAP BSR outside BA Information field 1202, typically in an addition field (not shown) located between BA Information field 1202 and the FCS field. To allow the reporting (coordinated) AP to process (compute at steps 443 and 444) individual BSRs received from its associated station before reporting to the sharing AP, the BlockAck frame 1200 comprises a padding field (not shown) located before the entry (MAP BSR) reporting the resource needs for the second BSS. Preferably, the padding field is included between a first entry 1202 (following the legacy format 1220) acknowledging the individual BSRs 741 / 742 and the entry reporting the MAP BSR 1230. In an implementation, a padding entry 1202 may be used, which is added as an entry between the first entry 1202 and the entry reporting the MAP BSR 1230. The padding entry 1202 may be identified through a dedicated AID value (e.g., 4095)inAID11 subfield 1211 or alternatively through one of the reserved values in TID subfield 1213. The padding entry 1202 may be predefined and repeated one or more times, depending on the time needed by the reporting AP to build its MAP BSR. Back to Figure 13, as a result, each solicited AP can compute an up-to-date MAP BSR intended to the sharing AP (AP1): AP2 responds to AP1 with MAP Resource Report frame 1332 including its MAP BSR gathered from its associated stations (STA21 and STA22), while AP3 responds to AP1 with a MAP Resource Report frame 1333 including its MAP BSR gathered from its associated stations (STA31 and STA32). By using format 1200 of Figure 12, the Multi-STA BlockAck (MAP Resource Report) frame advantageously: acknowledges the triggered-based communications (BSR polling) of its associated stations. Typically, an acknowledging entry 1202 (using the legacy format 1220) is used wherein the AID11 subfield 1211 in the Per AID TID Info field of the Multi-STA BlockAck frame is set to the 11 LSBs of the AID of the intended STA; transmits the MAP BSR towards the sharing AP. Typically, an entry reporting the resource needs (using the new format 1230) is used wherein the AID11 subfield 1211 in the Per AID TID Info field of the Multi-STA BlockAck frame is set to the 11 LSBs of the AP J D of the sharing AP; explicitly closes the TXS slot. In other words, the Multi-STA BlockAck frame ends a transmission slot allocated by the sharing AP to the reporting AP in the MAP Resource Report frame. It acts as a TXOP Return indication. One understands that the reporting (coordinated) AP cannot go beyond the limits of the allocated TXS slot. For instance, if the MAP TXS-BSRP Trigger frame 1330 is indicated via the TXS Mode subfield 316, then the reporting AP uses the time allocated by the sharing AP in the MAP TXS-BSRP Trigger frame 1330 with the TXS Mode subfield 316 different from 0 only for the transmission of one or more PPDUs that are addressed inside the reporting AP’s BSS. The reporting AP addressed by a User Info field in the MAP TXS-BSRP Trigger frame 1330 thus ensures that the PPDU transmission(s) within its BSS and any expected responses fit entirely within the allocated time of the TXS slot, including the time needed for sending the Multi-STA BlockAck frame 1332 or 1333 used as MAP Resource Report. Optionally, after receiving the MAP BSRs (e.g. 1332 / 1333) from a coordinated AP, the sharing AP may acknowledge the end of the TXS slot towards the coordinated AP, e.g. using acknowledgement frame 1310. Alternatively, any other frame format than an acknowledgment frame may be consider for 1310 (as no data is embedded in the MAP resource report, no acknowledgment is mandated). As an example, when the sharing AP has declared a “TXOP Return Support In TXOP Sharing Mode 3” (corresponding subfield in Capabilities set to 1), it can send a QoS_Null frame containing a Control Information (CAS Control field according to IEEE802.11-2021) with the RDG / More PPDU subfield equal to 0, in which case the next coordinated AP, specified in the list of User Info fields of the MAP TXS-BSRP Trigger frame 1330, takes the floor on the medium and can transmit a PPDU (for its BSS context) SIFS after frame 1310. Although the above scenarios of Figure 13 mainly include the polling (frames 740-741 / 742) by the coordinated APs of their associated stations, other scenarios may contemplate that one or more of coordinated APs provide BSS resource needs without polling their associated stations. It is up to the coordinated AP to poll its associated non-AP stations for obtaining an aggregated BSR (as in Figure 13) or to directly answer an already prepared collected MAP BSR (hence, no frame 740 / 742 or 750 / 752 is transmitted). In particular, it means that the Multi-STA BlockAck frame 1332 or 1333 can be sent without any acknowledgment entry 1202. Furthermore, as depicted in Figure 8 described below, the MAP Resource Report may be unsolicited, contrary to the other scenarios where a Trigger frame is sent by the sharing AP. The Multi-STA BlockAck frame 1332 or 1333 including an entry reporting a MAP BSR can therefore be sent in an unsolicited manner. While the format of Figure 12 is presented with a single entry 1202 reporting a MAP BSR, alternative embodiments may provide a Multi-STA BlockAck frame having multiple entries, each reporting a different MAP BSR. For example, MAP BSR may be provided for each type of traffic (e.g., based on UL, DL, DiL, specific TID). Figure 8 illustrates yet another example of frame exchange still with a resource need collection phase, however without specific request from the sharing AP. In this scenario, the APs spontaneously share their resource needs (MAP Resource Report) to surrounding APs (either belonging to the same MAP Group or all APs in their vicinity, including soft AP implementing a P2P Group or NSTR mobile AP). The timing for sending the MAP Resource Report is based on triggering events at the reporting AP. An example of triggering event includes receiving individual (resource needs) reports from the associated non-AP stations in its BSS, for instance receiving BSRs from the associated stations. Another example includes setting or updating a traffic flow within its BSS, such as detecting a new or updated SCS (Stream Classification Service) or r-TWT agreement (including the reception of TSPEC or QoS characteristic that defines a traffic flow). Yet another example includes detecting internal AP triggers such as critical data (UL, DL or any) to transmit or an increase in its internal buffer above a threshold (hence a critical amount of data) or the transmission of a Beacon frame that should carry the MAP Resource Report (in which case the reporting is periodic, based on beacon periodicity). In the figure, AP1 spontaneously sends its MAP Resource Report 760 to all the APs in its vicinity, i.e., AP2, AP3 and a P2P Group Owner (or soft AP). The MAP Resource Report frame 760 may be sent in multicast to each neighbouring AP (or AP belonging to a previously formed MAP Group) or in broadcast (RA field of the MAC header) to all surrounded stations in which case it is decoded only by AP stations that support the MAP coordination. Similarly, AP2 sends a MAP Resource Report 770 to all the APs in its vicinity, i.e., AP1, AP3 and a P2P GO (or soft AP). In the scenario, the sending of MAP Resource Report frame 770 is triggered at AP2 by the reception of BSRs from its associated stations respectively BSR 771 from STA21 and BSR 772 from STA22. In embodiments, upon or after the reception of the BSRs, AP2 translates the information received in the BSRs, mainly queue sizes (queue size for the highest AC and queue size for all ACs as defined in Section 9.2.4.7.4 of the REVme / D4.1 standard or a queue size for a given TID as defined in Section 9.2.4.5.6 of the REVme / D4.1 standard) into a duration and a bandwidth. This is to fill in the MAP Resource Report. The translation from queue size to duration and bandwidth information can be performed by considering the transmission parameters (e.g. MCS, RU allocation, transmission power, channel quality...) that the AP intends to use. The transmission parameters may be for instance the ones provided to the non-AP stations through the fields UL HE-MCS 334 and UL Target Receive Power 337 included in the User Info field (Figure 3b) or the AP Tx Power field 321 carried in the Trigger Frame (Figure 3c). As already mentioned above, the MAP Resource Report may also include the resource needs of AP2 itself. The translation from the unitary needs of all stations to a cumulated need to fill in the MAP Resource Report can be based on a resource allocation scheduling anticipated by AP2 for its next TXOP (see step 443 described above). As for AP2, AP3 sends a MAP Resource Report 780 to all the APs in its vicinity, i.e., AP1, AP2 and a P2P GO (or soft AP). In the scenario, the sending of MAP Resource Report frame 780 is triggered by the setting or updating of a traffic flow, here a SCS procedure exchange between AP3 and STA31 which lead to the exchange and the agreement on the characteristic of a traffic flow (TSPEC or QoS characteristic elements) represented by box 781. Alternatively, a r-TWT agreement may trigger the reporting. In this case, the MAP Resource Report may preferably fill in the SCSID of the traffic flow instead of the TID. The QoS characteristic element exchanged between the two stations carries several fields used to describe the traffic flow identified by a SCSID. For instance, the QoS characteristic element defined in Section 9.4.2.316 of the D5.0 standard contains the following fields: - Minimum Service Interval to contain an unsigned integer that specifies the minimum interval, in microseconds, between the start of two consecutive SPs for UL, DL or DiL (depending of the direction subfield), - Maximum Service Interval to contain an unsigned integer that specifies the maximum interval, in microseconds, between the start of two consecutive SPs for UL, DL or DiL (depending of the direction subfield), - Minimum Data Rate to contain an unsigned integer that specifies the lowest data rate specified at the MAC Service Access Point (SAP), in kilobits per second, for transport of MSDUs or A-MSDUs belonging to the traffic flow described by this element, - Mean Data Rate to indicate the average data rate specified at the MAC SAP rounded up to the nearest kilobit per second, in units of kilobits per second, fortransport of MSDUs or A-MSDUs belonging to the traffic flow described by this element, - Medium Time to contain an unsigned integer that specifies the medium time, in units of 256 microseconds per second, requested by the station as the average medium time needed in each second. This field is present only for DiL traffic, - other fields not described here for conciseness. The parameters of the QoS characteristic element are used to infer duration and bandwidth needs and / or to prepare a resource allocation scheduling, with a view of filling in the MAP Resource Report (e.g., the one of Figure 10c). In a variant, the MAP Resource Report may directly include a QoS characteristic element or part of the fields of the QoS characteristic element to define more precisely the resource needs of AP3 for its BSS. In other embodiments, the sending of MAP Resource Report frame 780 is triggered by the reception of P2P BSR 782 from STA 132 which acts as a non-AP station associated to AP3 but also as a P2P station (either as a TDLS station or as a Group Client in a P2P Group). As an example related to TDLS, P2P BSR 782 may be built by STA 132 based on information carried in the TDLS Peer Traffic Indication frame exchanged with the other TDLS peer, and more specifically on the TPU Buffer Status Information which contains information regarding the traffic buffered at the TDLS stations. The buffer size information may then be translated into bandwidth and duration according to the transmission parameters that the peer stations intend to use. As an example related to a P2P Group, P2P BSR 782 may be built based on the Notice of Absence (more precisely the activity time complementary to the time of absence notified in this Notice of Absence) or on the Traffic Indication Map carried in Beacon frame 791 broadcasted by the Group Owner of the P2P Group. For example, P2P BSR 782 may be based on the internal buffer size STA32 has to transmit to the P2P Group Owner as P2P peer. In the example of the Figure, STA32 only reports what it has to transmit to the Group Owner; this is because the Group Owner is also involved in the MAP coordination and can thus directly reports its own resource needs to the other APs through dedicated MAP Resource Report 790. As previously mentioned, P2P BSR 782 may also report all P2P resource needs should the Group Owner (or more generally the P2P peer) not being involved in the MAP coordination. Based on all the MAP Resource Reports exchanges, a MAP coordination Bandwidth Sharing 799 is triggered by any of the APs gaining a TXOP on the medium. This achieves an efficient resource allocation for the different APs according to their respective needs. In most wireless networks, a single medium / link is implemented in which case the MAP Resource Reports are transmitted over the same channel as the one shared during the MAP coordination Bandwidth Sharing 799. In variants relying on Multi-Link devices, the MAP Resource Reports may be transmitted over another link than the one shared during the MAP coordination Bandwidth Sharing 799. In yet other variants, the MAP Resource Reports may be sent on an anchor or a management link defined by the APs to communicate with each other. This may be an aside link fully dedicated to signalling only. Where information (e.g., bandwidth) required to know the resource needs from the MAP Resource Reports are defined within the MAP Group, the latter is created before the reports are sent. In other embodiments, the MAP Resource Reports may be sent prior to the creation of the MAP Group. This is helpful to trigger a TXOP bandwidth sharing without MAP Group creation, e.g., when bandwidth sharing is limited to one TXOP or a predefined number of TXOPs. The reports may also allow creating the MAP Group. In other words, a MAP Group may be set responsive to receiving MAP Resource Report frames. The MAP Group may then include all APs having reported their resource needs or, in variant, one of the APs may select a subset of them according to some criteria. Such approach is helpful to put in place a long-term coordination between APs. In the description above, the MAP Resource Report is embedded in frames such as (new variant) CTS frames or BSRs or GAS frames or, in some embodiments, as a one-bit signalling in a TIM element of a Beacon frame sent by the reporting AP. A dedicated MAP Parameters element can be used to convey the MAP Resource Report in these frames or as follows. Figure 5 illustrates an exemplary MAP Parameters element. The MAP Parameters element may be included in a (Reduced) Neighbour Report element. The (Reduced) Neighbour Report element may be included in a Beacon frame sent by the reporting AP. Figure 6 illustrates a case where the MAP Parameters element is included in a Channel Usage element. The Channel Usage element may be included in a Beacon frame sent by the reporting AP. Alternatively, the MAP Parameters element may be directly included as an element in the frame body of a Beacon frame sent by the reporting AP. As shown in Figure 5, an exemplary MAP Parameters element 560 can include any of the following fields / elements: - MAP ID field 561 to identify the MAP Group (MAP Coordination Set). The ID may be obtained from a previous MAP Group creation and / or may be used for subsequent coordinated communications for members of the MAP Group. In embodiments, the duration of a MAP Group may be limited to one TXOP or a predefined number of TXOPs, - MAP Coordination Type field 562 to indicate the type of coordination supported or currently in use in the MAP Group (e.g., C-TDMA, C-FDMA, C-SR). - AP ID field 563 to identify the reporting AP in the MAP Group. The AP ID may be an AID12, BSSID, short BSSID, BSS colour information, MAC address of the reporting AP or any combination thereof, - BSS Color field 564 to indicate the BSS color of the reporting AP or of the MAP Group. The colour may be informed by the coordinated AP to its associated stations to avoid unexpected filtering related to wrong colour bits, - Group Validity field 565 to indicate the lifetime of the MAP Group (TXOP based, long-term, and so on.), - Supported Resource Report field 566 to indicate which resource report is supported (included through CTS, TIM, RNR, GAS included in the MAP Parameters element), - Resource Report 567 to indicate the resource needs of the reporting AP. This element is optionally included according to the value of field 566. Resource Report 567 may follow any format explained above with reference to Figure 10c. As shown in Figure 6, the data payload 650 of a Channel Usage element is made up of four fields: an Element ID field 660, a Length field 670, a Usage Mode field 680 and a Channel Entry field 690. Five different values are defined for the Usage Mode field 680 in the REVme / D4.1 standard, namely value 0 for Non-infrastructure IEEE 802.11 network, value 1 for Off-channel TDLS direct link, value 2 for Non-infrastructure IEEE 802.11 network in which none of the APs belonging to the same ESS operate infrastructure BSSs, value 3 for Peer-to-peer link indication, value 4 for Non-infrastructure BSS channel switch request. In embodiments, a new usage mode with value 5 is introduced to signal MAP coordination, in which case the element 650 further include a MAP Parameters element 560. The remaining values 6 to 254 are reserved and value 255 keeps its conventional meaning, namely “unknown request”. Channel Entry field 690 includes zero or more Operating Class 691 and Channel 692 fields. Operating Class field 691 indicates an operating class value. The operating class (defining radio frequencies, channel center frequencies, maximum channel width and behavioral constraints) is interpreted in the context of the country specified in the Beacon frame. Channel field 692 indicates a channel number, which is interpreted in the context of the indicated operating class. Operating Class and Channel numbers are defined in Annex E in the REVme / D4.1 standard. Operating Class and Channel fields can be grouped together to identify a noncontiguous channel as described in Section 9.4.2.69.3 (Location Indication Channels subelement) of the REVme / D4.1 standard. In operation, an AP that supports Channel Usage may transmit a Probe Request or a Beacon frame including a Channel Usage element 650. An AP that transmits a Channel Usage element 650 sets the Usage Mode field of the Channel Usage element to value 5 if it requests assistance to setup a MAP coordination or proposes the receiving AP to join a MAP Group on the channel specify in the channel entry. The Channel Usage element 650 includes both Supported Operating Class(es) 691, Channel Usage element(s) 692. MAP Parameters element 560 (i.e., MAP Resource Report) may be included in Channel Usage element 650 to inform the receiving AP about the resource needs of the reporting AP for MAP coordination. In case of assistance request to setup a MAP Group, the reporting AP may only report its AP ID and its MAP Resource Report, the other fields of the MAP Parameters element 560 being undefined or ignored. In addition to the embodiments where the MAP Resource Report is included in (new variant) CTS frames, BSRs, GAS frames and Beacon frames, there may be embodiments where an AP reports about the resource needs of its BSS during a MAP coordination Bandwidth Sharing 799 initiated by another AP. It means the MAP Resource Report is included in a MAP Trigger frame allocating resources in a gained TXOP to the reporting AP. To make it short, AP1 (in Figures 7a to 7c1) may include its own MAP Resource Report in MAP Trigger frame 710 to inform the coordinated APs (AP2, AP3) about its resource needs (AP1) for a subsequent sharing. The sharing AP may thus act as a coordinated AP in the subsequent MAP coordination Bandwidth Sharing 799 initiated by another AP receiving frame 710. In that case, the MAP Resource Report may be included in a Special User Info field specifying the AID12 of the sharing AP and including the MAP Resource Report 1030 or MAP Parameters element 560 (or any other format such as a 1 -bit signalling). The MAP Resource Report 1030 or MAP Parameters element 560 may replace the other conventional fields of the Special User Info field (other than the AID12 field). Alternatively, the MAP Resource Report 1030 or MAP Parameters element 560 may be included in the Trigger Dependent User Info Field of the Special User Info field. Figure 11a schematically illustrates a communication device 1100 configured to implement at least one embodiment of the present invention, for instance any of AP or AP MLD shown in Figure 1. The communication device 1100 is an AP able to participate to a Multi-AP set. The communication device 1100 may preferably be a device such as a microcomputer, a workstation or a light portable device. The communication device 1100 comprises a communication bus 1113 to which there are preferably connected: a central processing unit 1101, such as a processor, denoted CPU; a memory 1103 for storing an executable code of methods or steps of the methods according to embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the methods; and at least one communication interface 1102 connected to a wireless communication network, for example a communication network according to one of the IEEE 802.11 family of standards or Wi-Fi alliance protocols, via transmitting and receiving antennas 1104. Preferably the communication bus provides communication and interoperability between the various elements included in the communication device 1100 or connected to it. The representation of the bus is not limiting and in particular the central processing unit is operable to communicate instructions to any element of the communication device 1100 directly or by means of another element of the communication device 1100. The executable code may be stored in a memory that may either be read only, a hard disk or on a removable digital medium such as for example a disk. According to an optional variant, the executable code of the programs can be received by means of the communication network, via the interface 1102, in order to be stored in the memory of the communication device 1100 before being executed. In an embodiment, the device is a programmable apparatus which uses software to implement embodiments of the invention. However, alternatively, embodiments of the present invention may be implemented, totally or in partially, in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). Figure 11b is a block diagram schematically illustrating the architecture of the communication device 1100, adapted to carry out, at least partially, the invention. As illustrated, device 1100 comprises a physical (PHY) layer block 1123, a MAC layer block 1122, and an application layer block 1121. The PHY layer block 1123 (here an 802.11 standardized PHY layer) has the task of formatting, modulating on or demodulating from any 20MHz channel or the common communication channel, and thus sending or receiving frames over the wireless radio medium used, such as 802.11 frames, for instance MAC data and management frames based on a 20MHz width to interact with legacy 802.11 stations (non-AP, AP, non-AP MLD, AP MLD), as well as of MAC data frames of OFDMA type having smaller width than 20MHz legacy (typically 2 or 5 MHz) to / from that radio medium. The MAC layer block or controller 1122 preferably comprises a MAC 802.11 layer 1124 implementing conventional 802.11 be MAC operations, and additional block 1125 for carrying out, at least partially, the invention. The MAC layer block 1122 may optionally be implemented in software, which software is loaded into RAM 1103 and executed by CPU 1101. The MAC 802.11 layer 1124 may implement an Upper-MAC stack along with a series of Lower-MAC modules. Preferably, the additional block 1125, referred to as multi-AP managing module which has different operations to implement parts of the invention, depending on the role played by the communication device 1100. As the same device can play different roles over time, the additional block 1125 is preferably designed to selectively perform the different operations relative to MAP. MAC 802.11 layer 1124 and multi-AP managing module 1125 interact one with the other in order to process accurately communications over the medium, e.g. over single-user or OFDMA RUs addressed to multiple stations according to embodiments of the invention. On top of the Figure, application layer block 1121 runs an application that generates and receives data packets, for example data packets such as a video stream. Application layer block 1121 represents all the stack layers above MAC layer according to ISO standardization. Although the present invention has been described hereinabove with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modificationswill be apparent to a skilled person in the art which lie within the scope of the present invention. Many further modifications and variations will suggest themselves to those versed in the art upon referring to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention, that being determined solely by the appended claims. In particular the different features from different embodiments may be interchanged, where appropriate. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Claims

1. A communication method in a wireless network, comprising at a second access point, AP, managing a second basic service set, BSS:sending, to a first AP managing a first BSS, a Multi-AP, MAP, Resource Report frame reporting resource needs for the second BSS.

2. The method of Claim 1, wherein sending the MAP Resource Report frame is responsive to receiving, from the first AP, a MAP Resource Report Request frame allocating resources to the second AP and soliciting a MAP Resource Report response in the allocated resources.

3. The method of Claim 2, further comprising, responsive to receiving the MAP Resource Report Request frame, polling non-AP stations of the second BSS to obtain resource needs from the polled non-AP stations.

4. The method of Claim 3, wherein polling the non-AP stations of the second BSS includes sending a Buffer Status Report Poll, BSRP, Trigger frame to the non-AP stations on a resource allocated by the first AP to the second AP within the received MAP Resource Report Request frame, and receiving BSR frames from the non-AP stations in response to the BSRP Trigger frame.

5. The method of Claim 4, wherein the MAP Resource Report frame acknowledges the BSR frames received from the non-AP stations.

6. The method of Claim 3, further comprising determining a resource allocation scheduling allocating resources to the non-AP stations of the second BSS based on the obtained resource needs, wherein the MAP Resource Report frame reports resource needs corresponding to the resource allocation scheduling.

7. The method of Claim 6, wherein the resource allocation scheduling is further determined based on own resource needs of the second AP for downlink transmission within the second BSS.

8. The method of Claim 6, wherein the resource needs corresponding to the resource allocation scheduling include a duration and a bandwidth of the resource allocation scheduling.

9. The method of Claim 3, wherein resource needs obtained from a non-AP station include peer-to-peer, P2P, resource needs of this non-AP station for P2P communication.

10. The method of Claim 1, wherein the step of sending the MAP Resource Report frame is responsive to detecting triggering events at the second AP, including receiving individual reports from their associated non-AP stations in the second BSS, and / or setting or updating a Stream Classification Service (SCS) or r-TWT agreement within the second BSS, and / or detecting an internal trigger, e.g., critical data or a critical amount of data in a transmission buffer or a Beacon frame to be transmitted.

11. The method of Claim 1, further comprising receiving, from the first AP, a MAP Trigger frame allocating resources to the second BSS in a TXOP gained by the first AP.

12. A communication method in a wireless network, comprising at a first access point, AP, managing a first basic service set, BSS:receiving, from a second AP managing a second BSS, a Multi-AP, MAP, Resource Report frame reporting resource needs for the second BSS.

13. The method of Claim 12, wherein the MAP Resource Report frame is received in response to a MAP Resource Report Request frame previously sent by the first AP to allocate resources to a station of the second BSS and soliciting a MAP Resource Report response in the allocated resources.

14. The method of Claim 12, further comprising, responsive to receiving the MAP Resource Report frame, setting a MAP Group with at least the second AP.

15. The method of Claim 12, further comprising sending a MAP Trigger frame allocating resources to the second BSS in a gained TXOP, based on the received MAP Resource Report frame.

16. The method of Claim 1 or 12, wherein the MAP Resource Report frame is a BlockAck frame comprising an entry in a BA Information field, which entry reports the resource needs for the second BSS.

17. The method of Claim 16, wherein the BA Information subfield comprises at least one additional entry which acknowledges at least one frame received from a non-AP station of the second BSS.

18. The method of Claim 16, wherein the entry in the BA Information field comprises an AID TID Info subfield followed by an extension field, wherein the AID TID Info subfield is made of an AID11 subfield, an Ack Type subfield and a TID subfield, and the extension field includes the report of resource needs for the second BSS.

19. The method of Claim 16, wherein the Ack Type and TID subfields are set to respective values signalling the extension field includes a report of resource needs for a BSS.

20. The method of Claim 16, wherein the BlockAck frame comprises a padding field located before the entry reporting the resource needs for the second BSS.

21. The method of Claim 16, wherein the BlockAck frame ends a transmission slot allocated by the first AP to the second AP in the MAP Resource Report frame.

22. The method of Claim 2 or 13, wherein the MAP Resource Report Request frame is one from a Buffer Status Report Poll, BSRP, Trigger frame, a Multi-User Request-To-Send, MU-RTS, Trigger frame, and a Generic Advertisement Service, GAS, frame.

23. The method of Claim 22, wherein the MU-RTS or BSRP Trigger frame has an enabled Triggered TXOP Sharing (TXS) mode.

24. The method of Claim 23, wherein the MU-RTS or BSRP Trigger frame having an enabled TXS mode allocates a time portion of an obtained TXOP to the second AP, wherein the MAP Resource Report frame is sent to the first AP within the allocated portion.

25. The method of Claim 24, wherein the second AP polls non-AP stations of the second BSS within the allocated portion, to obtain resource needs from the polled non-AP stations.

26. The method of Claim 1 or 12, wherein the MAP Resource Report frame is one from a Buffer Status Report, BSR, frame, a Clear-To-Send, CTS, frame, a Beacon frame, a Generic Advertisement Service, GAS, frame, and a MAP Trigger frame allocating resources in a gained TXOP to the first BSS.

27. The method of Claim 1 or 12, wherein the resource needs in the MAP Resource Report frame include a duration and optionally a bandwidth.

28. The method of Claim 27, wherein the MAP Resource Report frame includes, in addition to a duration field and a bandwidth field, at least one from:a TID field indicating a TID corresponding to data having the highest priority from amongst data for which resources are needed,a Link ID field indicating a link on which the second AP is requesting resources from amongst multiple links shared with the first AP,a Channel ID field indicating a channel on which the second AP is requesting resources,a Direction field indicating a direction of transmission of data for which resources are needed,a Lifetime field indicating a validity duration of the resource needs.

29. The method of Claim 1 or 12, wherein the resource needs in the MAP Resource Report frame correspond to needs for traffic meeting some requirements defined by the first AP.

30. The method of Claim 1 or 12, wherein the MAP Resource Report frame cumulates resource needs obtained by the second AP from multiple non-AP stations of the second BSS.

31. The method of Claim 30, wherein the MAP Resource Report also cumulates own resource needs of the second AP for downlink transmission within the second BSS.

32. The method of Claim 30, wherein the cumulated resource needs include a duration and a bandwidth of a summation of the obtained resource needs.

33. The method of Claim 1 or 12, wherein the MAP Resource Report frame is transmitted over an anchor or management link set up between the first and second APs.

34. A wireless communication device comprising at least one microprocessor configured for carrying out the method of Claim 1 or 12.

35. A non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform the method of Claim 1 or 1.

36. A communication method in a wireless network, comprises at a station: transmitting a BlockAck frame comprising an entry in a BA Information field, which entry reports resource on station side.

37. The method of Claim 36, wherein the BlockAck frame is a Multi-STA BlockAck frame.

38. An IEEE 802.11 BlockAck frame to be sent by a transmitting station, the BlockAck frame comprising a BA Control field and a BA Information field, the BA Information fieldcomprising one or more entries, one of the entries reporting resource needs at transmitting station’s side.

39. The IEEE 802.11 BlockAck frame of Claim 38, wherein the entry includes an AID field set to a non-zero identifier of an access point addressee of the IEEE 802.11 BlockAck frame.5 40. The IEEE 802.11 BlockAck frame of Claim 38, wherein the entry includes an AckType subfield and a TID subfield, set to respective values to signal the entry includes a report of resource needs at the transmitting station’s side.

41. The IEEE 802.11 BlockAck frame of Claim 38, wherein one of the entries acknowledges communication within a Basic Service Set managed by the transmitting station.

Images