Trigger-based communication in multi-ap context

Abstract

Multi-Access Point, MAP, technology provides some collaboration between neighbouring APs. Better MAP coordination is sought, in particular with respect to triggering procedures that trigger and allocate resources to other "coordinated" APs. A communication method in a wireless network is proposed that comprises, at a first AP managing a first BSS, sending a MAP Trigger frame allocating resources to a coordinated AP and soliciting a transmission within the allocated resources. A MAP BSRP TF collecting AP needs may precede a MAP MU-RTS TF to protect the medium and a MAP Basic TF to trigger communication for the coordinated APs. Various signalling are proposed to signal MAP type in the Trigger frames as well as to signal resource allocation to coordinated APs.

Description

[0001] TRIGGER-BASED COMMUNICATION IN MULTI-AP CONTEXT

[0002] FIELD OF THE INVENTION

[0003] The present invention generally relates to wireless communications and more specifically to coordination between basic service sets (BSSs) in multi-AP operations.

[0004] BACKGROUND OF THE INVENTION

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

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

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

[0008] For example, in a dense deployment scenario where neighbouring BSSs corresponding to two or more APs overlap each other, if one AP (belonging to a MAP coordinated group or MAP coordination set of APs) has an R-TWT schedule for which the corresponding scheduled ST As fall in a geographic area that overlap a neighbour BSS (of the same MAP group), then the R-TWT scheduled STAs possibly face interferences with neighbouring BSS's operation.

[0009] The proposed MAP mechanisms, no longer addressed by the Task Group, allow two or more neighbouring APs to share resources in terms of frequency and / or time and, in this way, they intend to prevent interferences from occurring.

[0010] 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 for OBSS Interference reduction. In other words, MAP coordination becomes one of 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.

[0011] Recent publications of the UHR group seek to coordinate MAP with the Restricted Target Wake Time (R-TWT) procedure, in order to obtain service periods offering OBSS interference avoidance and transmission sharing in between the BSSs of the MAP coordinated group, i.e. MAP coordination set of APs. The MAP coordination is willing to optimize operations during the R-TWT service period to limit those issues.

[0012] R-TWT and more generally the TWT procedures are highly advantageous when they are combined with trigger-based procedures, which are independent to the TWT procedures. This is because the TWT protects some periods of time (known as Service Periods) to prevent unexpected stations to access the medium during the service periods, while the trigger-based allocation of resources prevents the medium from collisions between stations involved in the service periods since the AP is managing the resource allocation through a trigger frame.

[0013] 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 IEEE802.11 be / D3.2 version (May 2023, below the “D3.2 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 D3.2 standard.

[0014] In the trigger-based procedures, the AP sends an IEEE802.11 Trigger frame (meaning an IEEE802.11 frame having Type value ‘0T 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.

[0015] Although the R-TWT has been declined to MAP coordination, the above mechanisms remain insufficient to ensure appropriate management between BSSs, because the trigger-based mechanisms govern intra-BSS communications.

[0016] Other situations exist where the existing mechanisms do not provide appropriate management between BSSs.

[0017] Improved coordination between different APs and their BSSs is therefore sought, with a view of the next 802.11 bn standard.

[0018] SUMMARY OF INVENTION

[0019] It is a broad objective of the present invention to overcome some of the foregoing concerns.

[0020] The inventors have noticed that the existing triggering procedures can be extended to APs for MAP purposes. New ways to coordinate a Multi-APs system, especially that trigger and allocate resources to other APs, are proposed in the present disclosure.

[0021] As apparent from below, new procedures can be defined on how sharing bandwidth (frequency-based or time-based sharing) to avoid concurrent transmission in the scope of MAP system, hence to ensure an efficient usage of the air time (reduction of the collisions) of the wireless medium.

[0022] Embodiments of the present disclosure provide a communication method in a wireless network, comprising at a first access point, AP, managing a first basic service set, BSS: sending a first Trigger frame allocating resources to a second BSS and soliciting a transmission from the second BSS within the allocated resources. Such a Trigger frame may thus be renamed multi-AP Trigger frame or MAP Trigger frame since it operates for MAP coordination. Resources may include Resource Units (RUs) made of one or more 20 MHz channels or of part thereof, as defined in the IEEE802.11 ax standard or D3.2 standard.

[0023] Correspondingly, a communication method is also proposed in a wireless network, that comprises at a second station in a second basic service set, BSS: receiving, from a first access point, AP, managing a first BSS, a first Trigger frame allocating resources to the second BSS and soliciting a transmission from the second BSS within the allocated resources, and responsive to the received first Trigger frame, sending a frame within the allocated resources.

[0024] The methods allow the APs (which may be organized in a MAP group of APs) to trigger transmissions of other APs or oftheir BSSs through bandwidth sharing to avoid concurrent transmission in between OBBs. Network efficiency is therefore increased.

[0025] Optional features are defined below with reference to methods, while they can be transposed into device features.

[0026] In some embodiments regarding the transmitting AP, the method may further comprise, receiving, at the first AP and within the allocated resources, a transmission (i.e., a frame) addressed to it by a second AP managing the second BSS. A response from the second AP is thus obtained. The method therefore allows the first AP to poll a second AP. An exemplary polling may include requesting a Buffer Status Report (BSR) such as a BSR of the second AP or of the second BSS or of multiple stations within the second BSS.

[0027] In other embodiments, the first AP cascades multiple Trigger frames allocating resources to at least the second BSS and soliciting a transmission from at least the second BSS within the respective allocated resources. This allows the first AP to drive a communication scenario that contributes to an improved network efficiency. Correspondingly from the second BSS perspective, the second station receives, from the first AP, multiple cascaded Trigger frames allocating resources to at least the second BSS and soliciting a transmission from at least the second BSS within the respective allocated resources.

[0028] For instance, an allocation of resources in a subsequent Trigger frame may be based on one or more Buffer Status Report, BSR, frames received in response to a preceding Trigger frame having a BSR Poll, BSRP, type. The first AP may therefore first poll other BSSs (or corresponding APs) to obtain their resource needs and then trigger them for communication in appropriate resources given the needs. An exemplary scenario includes a BSRP Trigger frame followed by an optional MU-RTS Trigger frame and a Basic Trigger frame that allocates resources to the other BSSs based on the BSRs received in response to the BSRP Trigger frame.

[0029] Various ways of reporting resource needs may be contemplated, e.g., the second AP of the second BSS may merely report its own needs. In a variant, it may report overall needs for its BSSs by summing individual needs from its associated stations. In some embodiments, a BSR frame received from a second AP managing the second BSS includes multiple BSRs corresponding to multiple non-AP stations of the second BSS. In that case, the allocation of resources in the subsequent Trigger frame may include directly allocating resources of non-AP stations of the second BSS. An inter-BSS or MAP cooperation is thus obtained where an AP directly triggers non-AP stations of another BSS.

[0030] In some embodiments, the method may further comprise at the first AP: receiving, from a second AP managing the second BSS, a releasing frame to release the allocated resources, and using the released resources to send a new frame. Improved communication in the wireless network can therefore be obtained since the resources can be reused as early as possible, when the second AP notifies the end of communication within its BSS using the resources. Correspondingly, from the second BSS perspective, the second station sends, to the first AP, a releasing frame to release the allocated resources once the transmission is done.

[0031] From the second BSS perspective, the second station may be a second AP managing the second BSS, and the transmission may be made from the second AP to the first AP. It means allocating resources to the second BSS includes allocating resources to a second AP managing the second BSS. The inter-BSS triggering mechanism thus allows the second AP to report to the first AP, e.g. to send a BSR or a CTS (Clear-To-Send) frame after respective BSRP and MU-RTS Trigger frames.

[0032] The first Trigger frame may trigger various behaviour in the second BSS, hence offering various ways for MAP cooperation.

[0033] In some embodiments, the second station is a second AP managing the second BSS, and the transmission includes another Trigger frame addressed by the second AP to stations of the second BSS. The second AP therefore drives communication for its BSS within the resources offered by the first AP through the first Trigger frame.

[0034] For instance, the first Trigger frame may be a Buffer Status Report Poll, BSRP, T rigger frame, and the other trigger frame may be a BSRP T rigger frame sent by the second AP to non-AP stations of the second BSS. This allows the second AP to gather BSRs (i.e., resource needs) from its associated stations before reporting to the first AP, in particular for future allocation of resources by the first AP through a subsequent Trigger frame. Indeed, the second AP may further receive one or more BSR frames from the non-AP stations in response to the other BSRP Trigger frame, and send, to the first AP, a response BSR frame based on the received BSR frames as a response to the first BSRP Trigger frame. In some embodiments, the response BSR frame includes multiple BSRs corresponding to the BSR frames received from the non-AP stations respectively. The first AP thus has a precise knowledge of the resource needs of each non-AP stations of the second BSS. This allows the first AP to efficiently allocate future resources individually to each of these non- AP stations. Improved network efficiency is thus obtained.

[0035] In some embodiments, the other Trigger frame is a duplicate of the first Trigger frame. In that way, the second AP repeats the Trigger frame from the first AP. This may be useful when the first AP directly allocates (through the first Trigger frame) resources to the stations of the second BSS, in particular when some of them can be out of range of the first AP.

[0036] In other embodiments, the other Trigger frame reproduces a resource allocation for non-AP stations of the second BSS as defined in the first Trigger frame. The second AP no longer only repeats the first Trigger frame but builds its own Trigger frame for its own (second) BSS conforming to the resource allocation provided by the first AP.

[0037] In some embodiments, the transmission is made within the second BSS. The Trigger frame thus triggers data exchange within the second BSS (Downlink transmission from an AP to a non-AP station, or the reverse, Uplink transmission, or peer-to-peer transmission between two non-AP stations).

[0038] In some embodiments, the second station is a non-AP station in the second BSS. That means the first AP directly allocates resources to non-AP stations of another BSS. This contributes to less signalling to trigger non-stations of multiple BSSs.

[0039] In some embodiments, the first Trigger frame is of one of the following types: BSRP Trigger frame, MU-RTS (Multi-User Ready-To-Send) Trigger frame with or without TXOP Sharing (TXS), Basic Trigger frame, NFRP (Null Data Packet - NDP - Feedback Report Poll) Trigger frame, Ranging Trigger frame. Corresponding solicited transmissions usually include a BSR frame for the BSRP Trigger frame, a CTS frame or directly a data frame (e.g. in case of TXS) for the MU-RTS Trigger frame, a second Trigger frame or a Data frame for the Basic Trigger frame, a NDP Feedback Report frame.

[0040] Signalling the first Trigger frame is dedicated to MAP can be performed using various configurations.

[0041] In some embodiments, a Common Info field ofthe first Trigger frame includes a multi- AP bit taking a first value when the first Trigger frame is a conventional 802.11 ax Trigger frame allocating resources to stations of the first BSS only and taking a second value when the first Trigger frame is a multi-AP Trigger frame allocating resources to another BSS than the first BSS. This allows the stations (AP or non-AP) to quickly identify whether or not they may be concerned with the Trigger frame. Furthermore, it allows all the existing Trigger frame types to be reused.

[0042] In specific embodiments, the multi-AP bit is bit 63 within the Common Info field of the first Trigger frame. Other variants may be used of course. In other embodiments, a Common Info field of the first Trigger frame includes a Trigger Type field whose value distinguishes between conventional 802.11 ax types of Trigger frames allocating resources to stations of the first BSS only and extended types of Trigger frames allocating resources to another BSS than the first BSS. Reserved values may be used to that end.

[0043] In particular, one or more of Trigger Type values from 9 to 15 (the reserved values) may include one or more of the following types: BSRP Trigger frame, MU-RTS Trigger frame, Basic Trigger frame, NFRP Trigger frame and Ranging Trigger frame, all allocating resources to another BSS than the first BSS.

[0044] The use of the Trigger Type field advantageously allows the stations to quickly (during the parsing of the frame, as it is the first field in the Common Info field) identify whether they are concerned the Trigger frame or not.

[0045] In yet other embodiments, a Common Info field of the first Trigger frame includes a Trigger Type field whose value is set to indicate multi-AP, that is resources are allocated to another BSS than the first BSS, and includes a second field defining a type of multi-AP Trigger frame. This approach advantageously uses only one value of the Trigger Type values available, hence keeping other values for other usages. On the other hand, any number of MAP Trigger frame types may then be defined using the second field, compared to a signalling through the Trigger Type field only where the number of values available is very limited.

[0046] In particular, the second field may include: one or more of bits B20, B21 , B56-B62 of the Common Info field, or a Trigger Dependent Common Info field within the Common Info field, or a Trigger Type Extension field after a Trigger Dependent Common Info field in the Common Info field.

[0047] In yet other embodiments, the first Trigger frame includes a Trigger Type field set to value 3 to define a MU-RTS type and a Triggered TXOP Sharing, TXS, Mode field is set to value 3 to define a TXOP sharing with another BSS. Specific to the TXOP Sharing, these embodiments advantageously do not modify the existing format of the Trigger frame. Only a reserved value in the Triggered TXS Mode field is reused.

[0048] In yet other embodiments, the first Trigger frame includes a Special User Info field that includes: a multi-AP bit taking a first value when the first Trigger frame is a conventional 802.11 ax Trigger frame allocating resources to stations of the first BSS only and taking a second value when the first Trigger frame is a multi-AP trigger frame allocating resources to another BSS than the first BSS. One or more of reserved bits B37-B39 of the D3.2 Special User Info field can be used, or a Trigger Type Extension field defining a type of multi-AP Trigger frame allocating resources to another BSS than the first BSS. Signalling MAP operation at the Common Info field level advantageously signals for the entire Trigger frame. However, there may be other situations where the first AP desires to trigger both own associated non-AP stations and other BSSs for MAP cooperation. A signalling at User Info field level (i.e., for each allocated resource) may be contemplated using technics like the above multi-AP bit. Such a bit may for instance by carried by the AID12 field, e.g. the MSB - most significant bit - of the User Info field.

[0049] More generally, an AID field in a User Info field of the first Trigger frame may include an AID dedicated to the second BSS, hence signalling the first Trigger frame is a multi-AP trigger frame allocating resources to the second BSS. A range of AIDs may be used for APs, hence providing the signalling. Range 2008-2044 can be used. Alternatively, range 2047-4055 allows the MSB of the AIDs to distinguish between AIDs for non-AP stations and AIDs for APs. Range 212-212-n to 4055 allows the n MSBs of the AIDs to distinguish between AIDs for non-AP stations and AIDs for APs. n may take value 1 , 2, 3, 4, 5 or 6.

[0050] In some embodiments, the first Trigger frame includes a MAP Group field describing a MAP group of APs. Providing such type of information to other APs improves the management of the MAP group.

[0051] For example, the MAP Group field may include an identifier of the MAP group and one or more from the following fields: a MAP Coordination Type field defining a type of coordination at resource level, a list of the APs belonging to the MAP group, a validity duration of the MAP group, a matching between MAC addresses of the APs and other identifiers of the APs, a BSS colour value providing colouring to the MAP group, a Direction indicating a transmission direction for the solicited transmission,

[0052] In particular, the MAP Group field may include the said following field or fields whose content has been modified since a previous Trigger frame allocating resources to a BSS of the MAP group or a creation of the MAP group. Thanks to this inheritance-like mechanism, the amount of data to be signalled for MAP Group management is reduced.

[0053] Such AID, but not only this type of information, may be used to identify the second BSS when allocating the resources within the first Trigger frame.

[0054] In this perspective, some embodiments provide that allocating resources to a second BSS includes identifying a second AP managing the second BSS within the first Trigger frame.

[0055] In some embodiments, an identification of the second AP includes one of an AID of the second AP, a MAC address of the second AP, an AP multi-link device, MLD, identifier of an AP MLD to which the second AP is affiliated, a BSS identifier of the second BSS, a short BSS identifier of the second BSS.

[0056] In particular, in case the second AP is a soft AP affiliated to a non-AP multi-link device, MLD, the AID of the second AP may be an AID of any station affiliated to the non-AP MLD. Indeed, with the association of an MLD, all the affiliated STA are provided with the same AID. This eases the management of the AIDs for soft APs.

[0057] In other embodiments, an identification of the second AP is included in a User Info field that defines the allocation of the resources to the second BSS in the first Trigger frame.

[0058] For example, the identification of the second AP may be an AID of the second AP provided in an AID12 field of the User Info field. As mentioned above, the AID may be taken from values 2008-2044 or 212-212-nto 4055, with n an integer between 1 to 6 to advantageously use the n MSBs of the AID to distinguish between MAP Trigger frames and conventional Trigger frames.

[0059] In variants, the identification of the second AP is included in an AP ID field that is provided in a Trigger Dependent User Info field of the User Info field or as an additional field in an 802.11 be / D3.2 User Info field. This applies for both the User Info field in the MU-RTS TXS Trigger frame and the User Info field in the other Trigger frames.

[0060] In particular, the AP ID field may be provided together with an ID Type field signalling the type of identifier the AP ID field includes. It may be any type mentioned above including an AID, a MAC address, an AP MLD ID, a BSSID, a short BSSID. Those types having various length, the ID Type field implicitly signals the length of the AP ID field.

[0061] In particular embodiments, the User Info field includes a multi-AP bit taking a first value when the User Info field signals an allocation of resources to a station of the first BSS only and taking a second value when the User Info field signals an allocation of resources to another BSS than the first BSS, hence signalling whether the Trigger Dependent User Info field is present in the User Info field.

[0062] In alternatives to signalling the second AP in the User Info field, an identification of the second AP may be included in a Receiver Address of a MAC header of the first trigger frame. This particularly applies when the first Trigger frame is addressed to a single (second) AP, hence allocating resources to that AP only.

[0063] In some embodiments seeking improved management of the BSSs, the first Trigger frame further allocates other resources to a non-AP station of the first BSS and solicits a transmission from the non-AP station within the allocated other resources. As a result, through the same Trigger frame, the first AP triggers own associated non-AP stations and also another BSS.

[0064] The above shows that various formats for a Trigger frame are proposed. Generally speaking, a Trigger frame is proposed that is sent by a first access point, AP, managing a first basic service set, BSS, the Trigger frame comprising an allocation of resources to a second BSS to solicit a transmission from the second BSS within the allocated resources.

[0065] The inventors have also noticed that a need exists for the APs to report their resource needs 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 also 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 Buffer Status Report, BSR, frame reporting resource needs for the second BSS.

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

[0067] A new BSR frame can be defined as a new Control frame (an IEEE802.11 frame having Type value ‘0T 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.

[0068] 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 Buffer Status Report, BSR, frame reporting resource needs for the second BSS.

[0069] Optional features are defined below with reference to methods, while they can be transposed into device features.

[0070] Thanks to the obtained BSRs, the first AP may provide appropriate resources to other BSSs. Hence, in embodiments, the method further comprises allocating resources in a gained TXOP to the second BSS based on the received 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, allocated resources in a TXOP gained by the first AP.

[0071] In some embodiments, the BSR frame is received in response to a BSR Poll, BSRP, Trigger frame previously sent by the first AP to allocate resources to a station (e.g., second AP) of the second BSS and solicit a BSR response in the allocated resources. It may be any BSRP Trigger frame as described above. Of course, in variants, the second AP may spontaneously send the BSR frame. Correspondingly, sending the BSR frame (at the second AP) is responsive to receiving, from the first AP, a BSR Poll, BSRP, Trigger frame allocating resources to the second AP and soliciting a BSR response in the allocated resources. 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).

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

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

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

[0075] In specific embodiments, each BSR Control field further includes a linkID field identifying a preferred link requested for the buffer status information.

[0076] Correlatively, the invention also provides a wireless communication device comprising at least one microprocessor configured for carrying out any method as described above.

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

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

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

[0080] BRIEF DESCRIPTION OF THE DRAWINGS

[0081] Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which:

[0082] Figure 1 illustrates an exemplary network environment in which embodiments of the present disclosure can be implemented;

[0083] Figure 2a describes a conventional MU UL communication triggered by an AP;

[0084] Figure 2b describes another exemplary trigger-based communication scenario with TXOP sharing soliciting UL PPDU;

[0085] Figure 2c describes yet another exemplary trigger-based communication scenario with TXOP sharing soliciting UL PPDU and / or DiL transmission;

[0086] Figure 3a illustrates the format of an 802.11 Trigger frame, as defined in the standards IEEE P802.11 REVme / D3.0;

[0087] Figure 3b illustrates a format of a HE variant User Info field in the Trigger frame of Figure 3a;

[0088] 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;

[0089] Figure 3e illustrates the various values available for the Trigger Type subfield in a conventional Common Info field;

[0090] Figure 3f illustrates the various values available for the Triggered TXOP Sharing Mode subfield in a conventional Common Info field;

[0091] Figure 4a illustrates, using flowcharts, exemplary steps, at a sharing AP MLD (or AP) and at one of coordinated AP MLDs (or stations), of resource sharing through the sending of a MAP Trigger frame according to some embodiments;

[0092] Figure 4b illustrates, using flowcharts, exemplary steps, at a sharing AP MLD (or AP) and at one of coordinated AP MLDs (or stations), of collecting resource needs from APs through the sending of a MAP BSR frame; Figure 5a illustrates a first augmented format of the Common Info field, according to embodiments;

[0093] Figure 5b illustrates the conventional Common Info field format for which the list of Trigger Types is augmented to MAP types, according to embodiments;

[0094] Figure 5c together with Figures 5c1 and 5c2 illustrate the conventional Common Info field format for which the Gl And HE-LTF Type / Triggered TXOP Sharing Mode subfield is extended to MAP Trigger Type extension indications, according to embodiments;

[0095] Figure 5d together with Figures 5d1 and 5d2 illustrate another augmented format of the Common Info field, according to embodiments;

[0096] Figure 5e together with Figures 5e1 and 5e2 illustrate yet another augmented format of the Common Info field, according to embodiments;

[0097] Figure 5f together with Figure 5f1 illustrate the conventional Common Info field format for which the list of Triggered TXOP Sharing Mode subfield values is augmented to one or more MAP types, according to embodiments;

[0098] Figure 5g together with Figures 5g1 and 5g2 illustrate two exemplary formats of a Special User Info field that can be used for MAP usage, according to embodiments;

[0099] Figure 6a illustrates a first augmented format of the HE variant of the User Info field, according to embodiments;

[0100] Figure 6b together with Figure 6b1 illustrate a second augmented format of the HE variant of the User Info field, according to embodiments;

[0101] Figure 6c illustrates a third augmented format of the HE variant of the User Info field in a MU-RTS TXS Trigger frame, according to embodiments;

[0102] Figure 6d illustrates a fourth augmented format of the User Info field, according to embodiments;

[0103] Figure 7a illustrates a first example of frame exchange with MAP cooperation, according to embodiments;

[0104] Figure 7b illustrates a second example of frame exchange with MAP cooperation, according to embodiments;

[0105] Figure 7c illustrates a third example of frame exchange with MAP cooperation, according to embodiments;

[0106] Figure 7d illustrates a fourth example of frame exchange with MAP cooperation, according to embodiments;

[0107] Figure 7e illustrates a fifth example of frame exchange with MAP cooperation, according to embodiments;

[0108] Figure 8a illustrates a first example of frame exchange based on the MAP MU-RTS TXS procedure, according to embodiments;

[0109] Figure 8b illustrates a second example of frame exchange based on the MAP MU- RTS TXS procedure, according to embodiments; Figure 8c illustrates a third example of frame exchange based on the MAP MU-RTS TXS procedure, according to embodiments;

[0110] Figure 8d illustrates a fourth example of frame exchange based on the MAP MU- RTS TXS procedure, according to embodiments;

[0111] Figure 8e illustrates a fifth example of frame exchange based on the MAP MU-RTS TXS procedure, according to embodiments;

[0112] Figure 9 illustrates some fields of a MAP BSRP Trigger frame to define requirements for requested MAP BSRs, according to embodiments;

[0113] Figure 10a illustrates a first format MAP BSR, according to embodiments;

[0114] Figure 10b illustrates a second format MAP BSR, according to embodiments;

[0115] Figure 11a shows a schematic representation a communication device in accordance with embodiments of the present invention; and

[0116] Figure 11 b shows a schematic representation of a wireless communication device in accordance with embodiments of the present invention.

[0117] DETAILLED DESCRIPTION OF EMBODIMENTS

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

[0119] 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).

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

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

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

[0123] The 802.11 family of standards define various media access control (MAC) mechanisms to drive access to the wireless medium.

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

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

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

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

[0128] 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).

[0129] The current discussions in the task group 802.11 be, as illustrated by draft IEEE P802.1 1 be / D3.2 of May 2023, 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.

[0130] A Multi-Link Device (MLD) is a logical entity and has more than one affiliated STA (STA) and has a single medium access control (MAC) service access point (SAP) to logical link control (LLC), which includes one MAC data service. An Access Point Multi-Link Device (or AP MLD) then corresponds to a MLD where each STA affiliated with the MLD is an AP, hence referred to as “affiliated AP”. A non-Access Point Multi-Link Device (or non-AP MLD) corresponds to a MLD where each STA affiliated with the MLD is a non-AP STA, referred to as “affiliated non-AP STA”. Depending on the literature, “multilink device”, “ML Device” (MLD), “multilink logical entity”, “ML logical entity” (MLE), “multilink set” and “ML set” are synonyms to designate the same type of ML Device.

[0131] Multiple affiliated non-AP STAs of a non-AP MLD can then setup communication links with multiple affiliated APs of an AP MLD, hence forming a multi-link channel. This is for instance done through the conventional association procedure: ML Discovery, followed by ML Authentication and finally by ML Setup where the non-AP MLD associates with the AP MLD (hence obtained an Association I Dentifier, AID) and sets up the ML links for its affiliated non-AP STAs with the APs affiliated with the AP MLD.

[0132] The links established (or “enabled links”) for MLDs are theoretically independent, meaning that the channel access procedure (to the communication medium) and the communication are performed independently on each link. Hence, different links may have different data rates (e.g. due to different bandwidths, number of antennas, etc.) and may be used to communicate different types of information (each over a specific link).

[0133] A communication link or “link” thus 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 and a non-AP STA affiliated with the non-AP MLD.

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

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

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

[0137] Figure 1 illustrates an exemplary network environment in which embodiments of the present disclosure can be implemented.

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

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

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

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

[0142] In the context of the invention, 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).

[0143] 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 I Dentifier (AID) to the requesting station. For example, the AID is a 16-bit value uniquely identifying the station.

[0144] The stations (including the AP) compete one against another 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.

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

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

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

[0148] The Target Wake Time (TWT) mechanism, originally defined in the IEEE 802.1 1 ah and 802.1 1 ax standards, has been adapted to be included in the 802.1 1 be D3.2 standard. TWT enables wake time negotiation between an AP and an associated station (STA) for improving 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.

[0149] An adaptation is known as the Restricted Target Wake Time (R-TWT) which 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).

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

[0151] For a given link, a non-AP station establishes membership in broadcast TWT schedules of the AP, while the AP delivers broadcast TWT parameter sets to the non-AP stations. The non-AP station is said to be the TWT scheduled station, while the AP is said to be the TWT scheduling station.

[0152] Negotiations to become a member of or to terminate membership in an R-TWT schedule (more generally a broadcast TWT) are performed with an exchange of frames that carry TWT elements, having the Negotiation Type subfield set to 3 (Broadcast TWT). In particular, a non-AP STA MLD may request to become a member of a TWT schedule by transmitting a TWT Setup frame to its associated AP MLD that contains a TWT element for a given R-TWT schedule.

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

[0154] 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 based on a MU-RTS trigger frame formerly defined by 802.1 1 ax but with a new TXOP Sharing mode subfield. This subfield informs whether the MU-RTS trigger frame is used according to its previous meaning defined by the 802.11 ax standard (Triggered TXOP Sharing Mode is set to 0) or for the new 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. 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.

[0155] Since its initial versions, the IEEE 802.11 has developed or is developing wireless communication technology to improve the 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.

[0156] With the constant increase of the number of wireless devices, the optimization of the medium access is an important factor to increase the useful bandwidth. Thereby, 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. The triggering procedure was introduced by the 802.11 ax amendment and refined in some parts in the 802.11 be amendment.

[0157] 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 multi-user (MU) transmission by the non-AP stations as well as the length thereof. The non-AP stations can transmit data to the AP (so-called MU UL transmission) or between them (so-called Direct Link or DiL or Peer-to-peer transmission).

[0158] Figures 2 to 3 illustrate trigger-based medium access procedures.

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

[0160] 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 (Ready-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.

[0161] 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 ‘0T and Subtype value ‘0010’ in the Frame Control field of the MAC header. The format of an 802.11 Trigger frame is illustrated in Figure 3a, as defined in the standards IEEE P802.11 REVme / D3.0, April 2023 and its amendment IEEE P802.11 be / D3.2, May 2023.

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

[0163] Trigger frame 300 is made up of the following fields:

[0164] - 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,

[0165] - 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,

[0166] - 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,

[0167] - 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,

[0168] - Common Info field 310 further described below with reference to Figures 3c and 3d for the HE and EHT variants respectively,

[0169] - 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,

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

[0171] - FCS field 307 to contain a 32-bit CRC.

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

[0173] User Info field 330 includes the following subfields:

[0174] - AID12 subfield 331 encoded as described in the following table:

[0175] - RU Allocation subfield 332 along with UL BW subfield 315 in Common Info field 310 identifies 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,

[0176] - UL FEC Coding Type subfield 333 to indicate the code type of the solicited HE TB PPDU,

[0177] - UL HE-MCS subfield 334 to indicate the HE-MCS of the solicited HE TB PPDU,

[0178] - UL DCM subfield 335 (absent in the EHT variant) to indicate DCM (dual carrier modulation) of the solicited HE TB PPDU.

[0179] - subfield 336 corresponds to the RA-RU Information subfield if the AID12 subfield is either 0 or 2045; otherwise this subfield corresponds 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) indicates 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) is 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,

[0180] - UL Target Receive Power subfield 337 to indicate the expected receive signal power, measured at the AP.

[0181] - 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).

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

[0183] Common Info field 310 includes the following subfields (not exhaustive list for conciseness):

[0184] - 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,

[0185] - UL Length subfield 312 to indicate the value of the L-SIG LENGTH field of the solicited TB PPDU,

[0186] - More TF subfield 313 to indicate whether or not a subsequent Trigger frame is scheduled for transmission,

[0187] - CS Required subfield 314 to define specific rules for channel sensing,

[0188] - UL BW subfield 315 to indicate bandwidth in the HE-SIG-A of the HE TB PPDU,

[0189] - subfield 316 corresponds to the Triggered TXOP Sharing Mode subfield if the Trigger type 311 indicates an MU-RTS Trigger Frame (value 3); otherwise field 316 is the Gl And HE-LTF Type subfield. The values available for the Triggered TXOP Sharing Mode subfield are shown in Figure 3f,

[0190] - 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,

[0191] - 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,

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

[0193] 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 RESIGN 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.

[0194] 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 12LSB 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.

[0195] This procedure allows the subsequent transmission to be protected. Indeed, all the 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 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.

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

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

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

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

[0200] 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 to the AP uplink data 222. Next, the AP may acknowledge the reception of the uplink data by sending a Block Ack frame 223 to STA1 . STA1 may starts again the transmission of a new non-TB PPDU toward AP 224 which acknowledges the data with a subsequent Block Ack frame 225.

[0201] After the sequence of UL transmission from STA1 (the AP finds out the sequence ends because the medium becomes idle), 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 .

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

[0203] 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 or DiL transmissions. The procedure may optionally be preceded by the sending of a CTS-to-self (not shown) to protect the TXOP frame exchange sequences.

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

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

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

[0207] 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, and thus to avoid interference.

[0208] MAP sharing of the common communication channel is resource-based. An amount of a shared resource can be measured in time units, frequency band width, 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” and “shared resource units” are synonyms and designate those resources offered by one of the APs to any other AP through the MAP technology.

[0209] However, even though the concept of MAP coordination has emerged, the known 802.11 standards remain silent about how to make the MAP coordination effective in a multi-AP system.

[0210] For example, no mechanism is provided to coordinate the medium access among the APs to allow an efficient airtime 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 coordination mechanisms such as coordinated OFDMA or coordinated TDMA, and so on. However, all those procedures are limited to intra-BSS usage, i.e., to an usage between an AP and its associated stations.

[0211] A need thus exists to extend these trigger-based mechanisms to multi-AP in an efficient way. Similarly, efficient coordination 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 sharing resource needs in MAP context.

[0212] The present disclosure provides multiple procedures to overcome these lacks.

[0213] As apparent from below, a new 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 or a CTS 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.

[0214] The first AP may be referred below as the “sharing” AP since it shares part of a TXOP it gained, while the other APs benefiting from this sharing may be referred to as “coordinated” APs.

[0215] Similarly, a new 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 BSR frame reporting resource needs for the second BSS. Such a “MAP” Buffer Status Report allows resource needs to be shared between the APs. Based on one or more of these MAP BSRs, the first AP may therefore efficiently allocate resources in a gained TXOP to the other BSSs. The MAP BSR may be spontaneously sent by an AP or in response to a MAP BSRP Trigger frame previously sent by the first AP.

[0216] Figures 4a and 4b illustrate, using flowcharts, exemplary steps at a sharing AP MLD (or AP) and at one of coordinated 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 APs through the sending of a MAP BSR frame.

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

[0218] 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 from the coordinated APs, i.e., information about their resource needs. 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 buffer status information 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).

[0219] The resource allocation may depend on the type of 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 APs for instance on a 20MHz-band basis. For an MU-RTS TXS Trigger frame, the sharing of the operating channel is made on a time basis (C-TDMA approach). 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.

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

[0221] Next, the sharing AP sends 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).

[0222] In embodiments, a dedicated signalling that the Trigger frame is a MAP Trigger frame is provided. Exemplary signalling is illustrated below with reference to Figures 5a to 5g.

[0223] In embodiments, a signalling dedicated to MAP resource allocation, i.e., resource allocation to one or more coordinated APs, is also provided. Exemplary signalling is illustrated below with reference to Figures 6a to 6d.

[0224] 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 as described below. Next at step 412, the coordinated AP looks to see 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.

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

[0226] 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. For instance, this 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).

[0227] The sharing of resource needs between APs may be based on such MAP Trigger frame when of the BSRP type. As mentioned above, a MAP BSR may also be sent spontaneously by an AP to another AP. Figure 4b illustrates a triggered sharing of resource needs.

[0228] The left part of the Figure represents steps at the sharing AP station requesting resource needs, while the right part represents steps at the coordinated AP for the management of the bandwidth need exchange for MAP purpose.

[0229] 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 BSRP 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 a specific identifier AP ID.

[0230] The MAP BSRP Trigger frame may include some constraints or requirements for the requested MAP BSRs, some of which, shown in Figure 9, are described below in relation to the scenario of Figure 7a.

[0231] The MAP BSRP Trigger frame is received by the coordinated AP at step 440, where it identifies the received Trigger frame as a MAP BSRP Trigger frame and checks whether the Trigger frame is addressed to it.

[0232] 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 BSRP Trigger frame. In response to this conventional BSRP Trigger frame, the coordinated AP receives BSRs from its associated stations at step 442.

[0233] Next, at step 443, based on the BSRs received at step 442 (or BSRs sent autonomously by the associated stations), the coordinated AP fills in the MAP BSR and sends it to the sharing AP at step 444 as a response to the MAP BSRP Trigger frame. The MAP BSR is filled in according to requirements provided by the sharing AP, e.g. UL, DL, DiL traffics, specific TID, delay bound.

[0234] The MAP BSR 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.

[0235] In case steps 441 and 442 are omitted, the coordinated AP may fill in the MAP BSR with its own resource needs and / or with any BSR received spontaneously from its associated stations.

[0236] Although the MAP BSR may have the same format as the (conventional) BSR defined in the IEEE P802.11-REVme / D3.0, April 2023 clause 9.2.4.7.4, other formats, shown in Figures 10a and 10b, are contemplated below in relation to the scenario of Figure 7a. The sharing AP next receives BSRs from its associated stations (if any) at step 432 and the MAP BSR 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 BSR. 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.

[0237] Turning now to the signalling of the MAP Trigger frames, Figures 5a, 5b, 5c associated with Figures 5c1 and 5c2, 5d associated with Figures 5d1 and 5d2, 5e associated with Figures 5e1 and 5e2, and 5f associated with Figure 5f 1 present format variants of Common Info field format 310 of Trigger frame 300 to signal whether it is a MAP Trigger frame to be used in the multi-AP context or a conventional Trigger frame.

[0238] These Figures use the EHT variant Common Info field (as in Figure 3d) as basis. However, similar MAP signalling can be achieved with the HE variant Common Info field illustrated by Figure 3c.

[0239] Figure 5a illustrates a first augmented format of the Common Info field that includes a multi-AP bit (or field) taking a first value when the Trigger frame is a conventional 802.11 ax Trigger frame allocating resources to stations associated with the transmitting AP only and taking a second value when the Trigger frame is a multi-AP Trigger frame allocating resources to another BSS or AP.

[0240] As shown in the example of the Figure, the exemplary frame format is augmented with one non-AP / AP field 501 (any other name can be used) in place of reserved B63 327. This field allows to discriminate between a MAP Trigger frame dedicated to Multi-AP triggering (inter- BSS) or a conventional Trigger frame inside the BSS to trigger the stations associated to the AP transmitting this Trigger frame.

[0241] If the field is set to 0, the Trigger frame solicits the stations associated to the transmitting AP (i.e., it is a conventional Trigger frame); otherwise the Trigger frame solicits AP(s) in its vicinity or stations associated to APs in its vicinity (i.e., it is a MAP Trigger frame in the meaning of the present disclosure).

[0242] This additional field advantageously allows all the existing Trigger frame types (as in Figure 3e) to be reused.

[0243] For example, a Trigger frame carrying Common Info field 310 with Trigger Type field 311 set to 0 and non-AP / AP field 501 set to 0 is interpreted as the existing Basic Trigger frame used e.g. in the scenario of Figure 2a to trigger MU transmissions within the same BSS. On the other hand, a Trigger frame carrying Common Info field 310 with Trigger Type field 311 set to 0 and non-AP / AP field 501 set to 1 is interpreted as a MAP Basic Trigger frame to trigger transmissions in another BSS. Exemplary scenarios of such behaviour are illustrated in Figures 7a, 7b and 7c discussed below: a coordinated AP receiving the frame, identifies it is a MAP Basic Trigger frame thanks to non-AP / AP field 501 , decodes it to get resource allocation information from User Info field addressed to it, and then use the allocated resource for its own operation (meaning it operates as it gained itself a TXOP for the allocated resource). Similarly, the other types of Trigger fames (MU-RTS, BSRP, NFRP...) are also extended to the MAP usage. The MAP MU-RTS Trigger frame may be used to solicit CTS frame from different APs or non-AP stations station in different BSSs and so to protect more widely (i.e., in a wider area) the subsequent communications. Exemplary uses of the MAP MU-RTS Trigger frame are illustrated in Figures 7a, 7b and 7c discussed below. The MAP MU-RTS Trigger frame may also be used for TXOP Sharing (TXS) procedure as illustrated in Figures 8a, 8b, 8c, 8d and 8e discussed below. The MAP BSRP Trigger frame may be used to trigger BSRs from surrounding APs or more generally stations (even the ones not associated with the AP transmitting the MAP BSRP Trigger frame) so as to collect needs in term of resource allocation from different APs (stations). This allows the sharing AP to better allocate the resources for the subsequent communications. The MAP NFRP Trigger frame may be use to get the needs in term of resource allocation of different APs (stations) but with a specific usage of the NFRP, i.e., the stations respond to the MAP NFRP Trigger frame by using energy in tone sets, instead of transmitting “real” data, to indicate their needs in bandwidth. The MAP Ranging Trigger frame may be used to obtain positioning.

[0244] Figure 5b illustrates the conventional Common Info field format for which the list of Trigger Types (as in Figure 3e) is augmented to MAP types. Such a Common Info field therefore includes a Trigger Type field whose value distinguishes between conventional 802.11 ax types of Trigger frames allocating resources to stations associated to the BSS of the transmitting AP only and extended types (MAP types) of Trigger frames allocating resources to another BSS or AP than the transmitting BSS or AP.

[0245] The Figure defines five new Trigger types dedicated to MAP in which one or more of Trigger Type values from 9 to 15 (formerly reserved values) include one or more of the following types: BSRP Trigger frame, MU-RTS Trigger frame, Basic Trigger frame, NFRP Trigger frame and Ranging Trigger frame, all allocating resources to another BSS than the first BSS.

[0246] In the example of the Figure, new value 9 corresponds to a MAP Basic Trigger frame type, value 10 corresponds to a MAP MU-RTS Trigger frame type, value 11 corresponds to a MAP BSRP Trigger frame type, value 12 corresponds to a MAP NFRP Trigger frame type, and value 13 corresponds to a MAP Ranging Trigger frame type. Values 14 and 15 remains reserved but may be used for further MAP trigger frame types. Of course, any other allocation of the Type values to the MAP types may be contemplated.

[0247] The sharing AP may use these new types of trigger frames to enable MAP coordination with different APs in its vicinity (as explained above with reference to Figure 5a).

[0248] Figures 5c, 5d and 5e illustrate other augmented formats of the Common Info field in which Trigger Type field 311 takes a specific value to indicate multi-AP, that is resources are allocated to another BSS / AP, and in which the type of multi-AP Trigger frame is defined in another field (which is different from one Figure to the other).

[0249] In the format of Figure 5c, a new trigger Type value is dedicated to MAP Trigger frame as illustrated with reference to Figure 5c1. In the example of the Figure, value 9 is used to signal MAP Trigger frame(s). In addition, subfield 316 made of bits B20 and B21 is used as a MAP Trigger Type extension to specify the type of MAP Trigger frame (e.g. amongst the above mentioned types MAP Basic, MAP BSRP, MAP MU-RTS, MAP MU-RTS TXS, MAP NFRP, MAP Ranging Trigger frames) and how the stations that receives this Trigger frame have to react.

[0250] An example of MAP Trigger Type extension, when Trigger Type subfield 311 is 9, is illustrated with reference to Figure 5c2. In the example shown, value 0 of the MAP Trigger Type extension subfield 316 indicates a MAP TXOP Sharing procedure; value 1 indicates a MAP Basic Trigger frame for coordinated OFDMA procedure. The other values 2 and 3 are reserved but may be used to define other MAP Trigger frame types such as MAP BSRP, MAP NFRP and so on.

[0251] Although the proposed field has two bits in the example, the MAP trigger Type extension subfield may have a different number of bits to define more than four MAP Trigger frame types and may take place in another set of unused bits, such as the EHT Reserved bits 351 (bits B56-62) or Trigger Dependent Common Info subfield 328.

[0252] In the format of Figure 5d, T rigger Type field 311 still takes a value (e.g. 9) dedicated to signal MAP Trigger frame(s). In addition, Trigger Dependent Common Info subfield 360 is used to specify the type of MAP Trigger frame and to provide additional MAP information, e.g. as illustrated by Figure 5d2.

[0253] Trigger Dependent Common Info subfield 360 may be used as a MAP Group field describing the MAP group as follows. It includes MAP Trigger Type field 361 , MAP Coordination type field 362, MAP ID field 363 and MAP group information field 370 as follows:

[0254] - MAP Trigger Type field 361 can be the same as MAP Trigger Type extension field 316 shown in Figure 5c2 or alternatively in Figure 5e2 discussed below. This field defines the type of Trigger frame for MAP purpose,

[0255] - MAP Coordination Type field 362 indicates the type of coordination used for the subsequent communication, e.g. C-OFDMA, C-TDMA, C-MIMO, C-SR, and so on,

[0256] - MAP ID field 363 indicates an ID of the MAP group (MAP Coordination Set). This ID may be obtained from a previous MAP creation and / or may be used for subsequent coordinated communications triggered by the current Trigger Frame for members of the MAC group defined in MAP group Information field 370. In embodiments, the duration of a MAP group may be limited to one TXOP,

[0257] - MAP group Information field 370 indicates the APs belonging to the MAP group identified by MAP ID 363, using for example field 373 described below. Field 370 may also contain the validity duration 371 of the MAP group (current TXOP, perpetual...). MAP group Information field 370 may also contain a list 373 of mapping between BSSIDs or MAC addresses of the APs belonging to the MAP group and (12 bit long) AP IDs. This allows the APs to know their respective AP IDs. The AP IDs may then be used in the AID12 subfield 331 of any User Info field 330 to the purpose of identifying APs for resource allocation. MAP group Information field 370 may also contain BSS color value 372 to use for MAP cooperation (the colour may be informed by the coordinated AP to its associated stations to avoid unexpected filtering related to wrong colour bits) and / or Direction field 374 to constrain or recommend a transmission direction (UL, DL, DiL) for the subsequent transmission, so to possibly 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 variants, the Direction field may be added in User Info field 330 to constrain only specific APs. All or part of the MAP group Information field 370 as well as all or part of the User Info field 330 which informs the RU allocation of the different users may be absent from the MAP Trigger frame in order to save bandwidth if the MAP ID (or other ID) that identifies a group of stations and their resource allocation is the same during successive MAP Trigger frames or during the validity of the group. In another variant, the MAP Group Information field 370 as well as User Info field 330 which informs the RU allocation of the different users may only contain the information that has been modified since the last MAP Trigger frame or a Trigger Frame identified by a session ID or since the creation of the group. Thereby, this could be seen as an inheritance mechanism as described in the 1 1 .1 .3.8.4 Inheritance of element values in the D3.2 standard but with temporal inheritance from MAP Trigger Frame to MAP Trigger Frame instead of or in complement to inheritance as defined in the REVme D3.0 standard. In addition, the MAP Trigger Frame may include information which indicates whether the Trigger Frame contains the complete information or only the difference.

[0258] The above description of how the amount of data to be signalled for MAP Group management is reduced by this inheritance-like mechanism usage has been made with respect to receiving a MAP Trigger Frame. It will however be appreciated that the amount of data to be signalled in any type of Trigger Frame may be reduced based on the above description (inheritance).

[0259] In the format of Figure 5e, Trigger Type field 311 still takes a value (e.g. 15 in the example shown in Figure 5e1) dedicated to signal MAP Trigger frame(s) or a Trigger Type Extension field 370 to specify the type of MAP Trigger frame, e.g. as shown in Figure 5e2. Trigger Type Extension field 370 is an additional element compared to the known 802.11 format of Common Info field 310. Although it is used in the present disclosure to define new MAP Trigger types, it could be used in the future to define any other new type of Trigger frame.

[0260] Figure 5f illustrates the conventional Common Info field format for which the list of Triggered TXOP Sharing Mode subfield values is augmented to one or more MAP types. Hence this applies for subfield 316 (Figure 3f in the conventional use) when Trigger Type 311 is 3, i.e., the Trigger frame is a MU-RTS Trigger frame.

[0261] In this variant, the reserved value ofthe Triggered TXOP Sharing Mode subfield, i.e., value 3 (see Figure 3f), is used to signal the MU-RTS TXS is adapted to MAP purposes. In this variant, MAP cooperation is limited to the usage of Coordinated Time Sharing (C-TXS) or C- TDMA, which advantageously have limited needs of synchronization between the stations contrary to frequency-based cooperation (e.g. coordinated OFDMA). In variants to a MAP signalling made in the Common Info field, the same signalling as above may be provided in Special User Info field, which presence is signalled by Special User Info Field Flag bit B55 350 set to 0. Special User Info Field is further described with reference to the figure 5g associated with Figures 5g1 and 5g2. The Special User Info field is a User Info field that does not carry user specific information but carries extended common information not provided in the Common Info field. The Special User Info field, if present, is located immediately after the Common Info field of the Trigger frame and carries information for the U-SIG field of a solicited EHT TB PPDU.

[0262] Figure 5g illustrates an exemplary format of a Special User Info field that can be used for MAP usage, and more generally for UHR operations. Special User Info field 550 as shown has the same fields as defined in the D3.2 standard. It includes:

[0263] - AID12 subfield 551 set to 2007,

[0264] - PHY Version Identifier subfield 552 to indicate the PHY version of the solicited TB PPDU that is not an HE TB PPDU. The PHY Version Identifier subfield is set to 0 for EHT. The PHY Version Identifier subfield is set to 1 (or any other reserved value such as 2-7) for UHR,

[0265] - UL Bandwidth extension subfield 553 to indicate, together with UL BW subfield 315 in Common Info field 310, the bandwidth of the solicited TB PPDU,

[0266] - EHT Spatial Reuse ‘n’ subfields 554 and 555 to carry values to be included in the corresponding Spatial Reuse ‘n’ subfield in the U-SIG field of the EHT TB PPDU,

[0267] - U-SIG Disregard And Validate subfield 556 to carry values to be included in the Disregard and Validate subfields of the U-SIG field of the solicited EHT TB PPDUs,

[0268] - Reserved bits B37-39 557,

[0269] - Trigger Dependent User Info subfield 558 whose presence and length depends on the variant / type of the Trigger frame. Trigger Dependent User Info subfield 558 is not present in Trigger frames other than BFRP or MU BAR. In embodiments of the present disclosure, Trigger Dependent User Info subfield 558 is also present in newly defined MAP Trigger frames. In that case, according to particular embodiments, Trigger Dependent User Info subfield 558 is similar to Trigger Dependent Common Info subfield 360 (Figure 5d2) described above. In other words, Trigger Dependent User Info subfield 558 is used to define a type of MAP Trigger frame allocating resources to another BSS / AP and may further provide information about the MAP group.

[0270] This exemplary format shows that, in a more general way, an 802.11 frame may include a Special User Info field having a PHY Version Identifier subfield set to a value from 1 to 7, preferably 1 , to signal UHR (Ultra High Reliability) or multi-AP cooperation.

[0271] MAP signalling may also (in combination or in variant) be provided using any reserved bit B37-B39 of field 557. For example, non-AP / AP subfield 501 described above (Figure 5a) may be provided in bit B37 as shown in Figure 5g1. Alternatively, Trigger Type Extension subfield 370 described above (Figure 5e2) may be provided using field 557 as shown in Figure 5g2. These examples of MAP signalling in Common Info field or Special User Info field are only examples. 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. An example is provided below where the MSB of AID12 field 331 can be used as a MAP signalling.

[0272] In addition to MAP signalling, resource allocation for MAP purposes also require some adaptations compared to conventional resource allocation signalling in the User Info fields. Basically, there is a need to identify another AP (than the transmitting one) within the Trigger frame. Various types of identifier may be used: an AID of the AP, a MAC address of the AP, an AP multi-link device, MLD, identifier of an AP MLD to which the AP is affiliated, a BSS identifier of the corresponding BSS, a short BSS identifier of the BSS.

[0273] A first example relies on the above AP AID with the use of a new range of AID12 field 331 (Figure 3b) to target the APs. The following table provides a first embodiment where values 2049 to 4055 are reserved as AP AIDs.

[0274] This particular range of values advantageously use the MSB (bit BO in field 331) to discriminate between the AIDs for the associated STAs and the AIDs used to address the APs for MAP purpose. In that case, the MSB bit plays the same role as then-AP / AP bit mentioned above to signal the MAP Trigger frame. In other words, if MSB = 0, the AID addresses an associated STA and if MSB = 1 , it addresses a coordinated AP.

[0275] The value of the AID of the AP may be obtained from the MAP group Information field 370 included in Trigger Dependent Common Info field 360 or 558 described above (Figure 5d or 5g). The AIDs for the APs could also be defined, for example, in a new association procedure dedicated to MAP. Range 2049-4055 is only an example. Range 3072-4055 may also be used where the two MSBs (bits BO and B1) if set to ‘11 ’ can be used to identify an AP AID. Similarly, range 3584-4055 may use the three MSBs. More generally range 212-212-nto 4055 use the ‘n’ MSBs (n an integerfrom 1 to 6). Another exemplary range is 2008-2044. Of course subsets ofthese ranges can also be used. In some embodiments, the APs may negotiate the range to be used (directly the start and end values of the range or value ‘n’), during the creation of the MAP group. The range may be adjusted dynamically as the number of APs in the MAP group varies.

[0276] In some embodiments where the Trigger frame is addressed to a single AP, the RA field 303 may be used to carry the MAC Address of the targeted AP, hence providing an identification of the coordinated AP that benefits from the MAP sharing.

[0277] Other examples of resource allocation signalling are shown in Figures 6 which illustrate various exemplary formats of the User Info field to address other BSSs or APs belonging to a MAP group or stations associated with these other APs (e.g. surrounding APs).

[0278] Figures 6a, 6b associated with Figure 6b1 , 6c and 6d present various variant formats of User Info field format 330 to define resource allocation in the multi-AP context. In these variants, the identification of an AP is included in an AP ID field that is provided in a Trigger Dependent User Info field of the User Info field (Figures 6b and 6c) or as an additional field in an 802.1 1 be / D3.2 User Info field (Figure 6a).

[0279] Figure 6a illustrates a first augmented format of the HE variant of User Info field 330 (or any other variant of the User Info field such as EHT or MU-RTS TXS...) of Trigger frame 300. As shown, User Info field 330 includes a new AP ID field 600 which carries any identifier of the AP addressed by the User Info field. As a result, any AP that receives this User Info field is able to identify, thanks to the identifier (for example its MAC address), the resources that are allocated to it by the sharing AP and that it can use for its own operation.

[0280] In this example, AID subfield 331 may be any reserved value to signal AP ID field 600. For example value 2047 or 2048 may be used. Any station reading this value in AID subfield 331 is therefore triggered to have a look to AP ID field 600.

[0281] Additional AP ID field 600 is therefore present if the Trigger Frame is signalled as being a MAP Trigger Frame (see above MAP signalling) and / or if AID12 subfield 331 uses a value specific for MAP (e.g. 2047 or 2048). In embodiments, it is also present if AID12 subfield 331 in a MAP Trigger frame uses a value for unassociated STAs (e.g. value 2045).

[0282] Figure 6b illustrates a second augmented format of the HE variant of User Info field 330 (or any other variant) of Trigger frame 300. This variant provides AP ID field 600 in Trigger Dependent User Info field 339.

[0283] As the AP ID may be of various types (AID, MAC address, an AP MLD ID, BSSID, short BSSID), embodiments provide that the AP ID field is provided together with an ID Type field 610 signalling the type of identifier the AP ID field includes. This is shown in Figure 6b1. For example, ID Type = 0 means the AP ID is a MAC address, ID Type = 1 means the AP ID is an AP MLD ID, ID Type = 2 means the AP ID is a BSSID and so on. Trigger Dependent User Info field 339 is present in the User Info field based on the same criteria as defined above for AP ID field 600 (Figure 6a).

[0284] Figure 6c illustrates a third augmented format of the HE variant of User Info field 330 (or any other variant) in MU-RTS TXS Trigger frame 300. It is then only used to trigger MU- RTS TXS.

[0285] In embodiments, User Info field 330 is made up of five fields: AID12 field 331 , RU Allocation field 332, Allocation Duration field 603 which indicates the time allocated to the stations to whom the User Info field is addressed (whatever the signalling through AID12 field and / or AP ID as defined above) within the TXOP obtained by the sharing AP, Reserved field made of bits B29-B39 (in the EHT variant, bit B39 is a PS160 bit) and Trigger Dependent User Info field 339.

[0286] Trigger Dependent User Info field 339 is used as defined above to carry AP ID field 600 and optionally ID Type field 610.

[0287] As shown in Figure 6c, in some embodiments, additional non-AP / AP field 501 is included in place of one reserved bit B29-B39, e.g. bit B29. Field 501 allows to discriminate if the User Info field 330 aims to trigger an AP or a non-AP station, as defined earlier in the present disclosure. Incidentally, this bit 501 indicates the presence of Trigger Dependent User Info 339 (if set to 1).

[0288] This bit has also an advantageous effect in case of hybrid MLD, i.e., an MLD that embeds some non-AP stations and some AP stations inside the same MLD. For example, a non- AP station that enables soft-AP functionalities becomes an AP (soft AP). In that case, two stations of a non-AP MLD, one being a soft AP and the other a non-AP station, share the same AID (the one provided by an AP MLD to the non-AP MLD when associating). The non-AP / AP bit 501 thus allows to distinguish between the two stations which one is effectively triggered by the Trigger frame. If field 501 is set to 0, the Trigger frame solicits the non-AP stations of the MLD; otherwise the Trigger frame solicits the (soft) AP part of the MLD.

[0289] Figure 6d illustrates a fourth augmented format for User Info field 330. This may define a new variant, e.g. UHR variant. This variant allows mixing frequency-based and timebased allocation, in other words a mix of OFDMA and TDMA.

[0290] This format combines the fields of the User Info field of Figure 3b to define frequency features of the allocation, with Allocation Duration field 603, Start Time field 604 (which indicates when the sharing starts forthe station) and AP ID field 600 to define time features of the allocation. The start time is useful to allocate successive timeslots to different stations within a single trigger frame. In a variant which avoids using the Start Time field, the User Info fields are considered in order and then the start time of the resource / time allocated to a station through a current User Info field corresponds to the sum of the allocated durations of the User Info fields preceding the current User Info field in the MAP Trigger frame.

[0291] Exemplary signalling of MAP type of the Trigger frame and signalling of MAP resource allocation have just been described with reference to Figures 5a to 5g and to Figures 6a to 6d respectively. Figures 7a-7e and 8a-8e now illustrates exemplary scenarios of frame exchange using these signalling in a MAP context.

[0292] Those of Figures 7a-7e show cascaded multiple MAP Trigger frames from a sharing AP to two other APs, usually to obtain resource needs using a MAP 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.

[0293] On the other hand, those of Figures 8a-8e are dedicated to the Triggered TXOP Sharing procedure (TXS), hence using MAP MU-RTS TXS Trigger frames.

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

[0295] 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: e.g., Trigger Type 311 set to BSRP (value 4) with non-AP / AP field 501 set to AP (value 1) (Figure 5a); Trigger Type 311 set to MAP BSRP (value 11) (Figure 5b); Trigger Type 311 set to MAP (value 9) with MAP Trigger Type Field 361 set to BSRP (value 4) in Trigger Dependent Common Info 360 (Figure 5d); Trigger Type 311 set to “Trigger Type extension” (value 15) with Trigger Type extension field 370 set to MAP BSRP (value 2) (Figure 5e); Trigger Type 311 set to BSRP (value 4) with non-AP / AP field 557 in Special User Info field 550 set to AP (value 1) (Figure 5g1); Trigger Type extension field 557 in Special User Info field 550 set to MAP BSRP (value 2) (Figure 5g2); Trigger Type 311 set to BSRP (value 4) with an AID dedicated for AP in AID12 field 331 of a User Info field 330.

[0296] 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 as described above: e.g., an AID dedicated for AP (whatever the range) in AID12 field 331 of a User Info field 330; AP ID field 600 in User Info field 330 (Figure 6a); AP ID field 600 in Trigger Dependent User Info field 339 of User Info field 330 (Figure 6b).

[0297] 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 Trigger Dependent Common Info field 360 or Trigger Dependent User Info field 339 or Special User Info field 550. The additional information may include one or more of the BSR requested information items shown in Figure 9:

[0298] - 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,

[0299] - Delay bound field 903 to indicate a maximum expiration date for the data to be reported by the requested MAP BSR,

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

[0301] - 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. An exemplary scenario using this field is illustrated with reference to Figure 7c described below.

[0302] 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 as a response to the sharing AP in the resource allocated in the respective User Info field.

[0303] The MAP BSR informs the sharing AP about the addressed BSS’s needs in term of resource allocation.

[0304] 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 IEEE P802.11-REVme / D3.0, April 2023 clause 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:

[0305] - DL TID field 1011 to indicate the highest TID corresponding to the DL queue size,

[0306] - DL Queue Size field 1012 to indicate the quantity of DL data to transmit by the addressed AP to its associated stations,

[0307] - UL TID field 1013 to indicate the highest TID corresponding to the UL queue size,

[0308] - UL Queue Size field 1014 to indicate the quantity of UL data that the stations associated with the addressed AP have to transmit,

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

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

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

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

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

[0314] The bandwidth may be the maximum bandwidth possible on the link / channel over which the individual BSR is transmitted by the respective station.

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

[0316] 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 be optional or may take place in a different TXOP than the TXOP used for data exchange.

[0317] Once the bandwidth requirements are known by the sharing AP, a trigger-based data exchange may start.

[0318] 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: e.g., Trigger Type 311 set to MU-RTS (value 3) with non-AP / AP field 501 set to AP (value 1) (Figure 5a); Trigger Type 311 set to MAP MU-RTS (value 10) (Figure 5b); Trigger Type 311 set to MAP (value 9) with MAP Trigger Type Field 361 set to MU-RTS (value 3) in Trigger Dependent Common Info 360 (Figure 5d); Trigger Type 311 set to “Trigger Type extension” (value 15) with Trigger Type extension field 370 set to MAP MU-RTS (value 1) (Figure 5e); Trigger Type 311 set to MU-RTS (value 3) with non-AP / AP field 557 in Special User Info field 550 set to AP (value 1) (Figure 5g1); Trigger Type extension field 557 in Special User Info field 550 set to MAP MU-RTS (value 1) (Figure 5g2); TriggerType 311 set to MU-RTS (value 3) with an AID dedicated for AP in AID12 field 331 of a User Info field 330.

[0319] Again, RA field 303 of this MAP MU-RTS Trigger frame is set to the Broadcast address as it is addressed to several APs.

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

[0321] 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 fame 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.

[0322] As for the previous MAP Trigger frames, the MAP Basic Trigger frame 720 is identified using any signalling method as described above: e.g., Trigger Type 311 set to Basic (value 0) with non-AP / AP field 501 set to AP (value 1) (Figure 5a); Trigger Type 311 set to MAP Basic (value 9) (Figure 5b); Trigger Type 311 set to MAP (value 9) with MAP Trigger Type Extension field 316 set to Coordinated OFDMA (value 1) (Figure 5c); Trigger Type 311 set to MAP (value 9) with MAP Trigger Type Field 361 set to Basic (value 0) in Trigger Dependent Common Info 360 (Figure 5d); Trigger Type 311 set to “Trigger Type extension” (value 15) with Trigger Type extension field 370 set to MAP Basic (value 0) (Figure 5e); Trigger Type 311 set to Basic (value 0) with non-AP / AP field 557 in Special User Info field 550 set to AP (value 1) (Figure 5g1); Trigger Type extension field 557 in Special User Info field 550 set to MAP Basic (value 0) (Figure 5g2); Trigger Type 311 set to Basic (value 0) with an AID dedicated for AP in AID12 field 331 of a User Info field 330.

[0323] 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).

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

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

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

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

[0328] In the example of the Figure, the MAP BSRP Trigger frame 730 is addressed in 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.

[0329] 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 be optional or may take place in a different TXOP than the TXOP used for data exchange.

[0330] Once the bandwidth requirements are known by the sharing AP, a trigger-based data exchange may start. Figure 7b proposes the same trigger-based data exchange as Figure 7a described above:

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

[0332] 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 in 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.

[0333] In this scenario, the MAP BSRP Trigger frame 730 may require 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 to cover the whole procedure 700c (i.e. BSRP duration + BSR duration + MAP BSR duration).

[0334] Responsive to this MAP BSRP Trigger frame, each station (associated station STA1 1 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.

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

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

[0337] As for the preceding scenarios, resource need collection phase 700c may be optional or may take place in a different TXOP than the TXOP used for data exchange.

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

[0339] Once the bandwidth requirements are known by the sharing AP, a trigger-based data exchange may start. The MAP MU-RTS / CTS exchange is similar to the scenarios of Figures 7a and 7b.

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

[0341] It may be noted in this embodiment where the sharing AP directly solicits the stations associated to the coordinated APs, AP ID field 600 in the User Info fields can be used by the stations in complement to AID12 subfield 331 to identify to which AP the station identified by the AID12 subfield must be associated and so to know whether the User Info field is addressed to them. Indeed, the same AID12 value can be allocated to several stations associated to different APs. It is a way to avoid AID12 collision with different stations using the same allocated resource.

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

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

[0344] Figure 7d illustrates a fourth example of frame exchange that enhances the scenario of Figure 7c. The resource need collection phase 700 is omitted before the trigger-based data exchange (hence phase 700 can be present or not).

[0345] In this scenario, each coordinated AP receiving MAP Basic Trigger frame 780 from the sharing AP extracts the resource allocation dedicated to its own BSS (i.e. the one or more User Info fields having for example an AP ID field 600 set to the coordinated AP) and then sends in turn a conventional Basic Trigger Frame to its own associated stations, that include the extracted resource allocations. In other words, the Basic Trigger frame reproduces a resource allocation for non-AP stations of the coordinated BSS as defined in the MAP Basic Trigger frame.

[0346] Coordinated AP2 therefore sends Basic Trigger frame 790a including the sole resource allocation (User Info field) for STA21 . Similarly, Coordinated AP3 sends Basic Trigger frame 790b including the resource allocations (User Info fields) for STA31 and STA32.

[0347] This Basic Trigger frame 790a / b allows to ensure that all stations (even the ones outside of the reach of AP1) correctly receive the resource allocation for the subsequent transmission. In response, their associated stations are able to send their uplink data (782 for STA21 , 782 for STA31 and 784 for STA32) as described above in scenario of Figure 7c.

[0348] Figure 7e illustrates a fifth example of frame exchange that also enhances the scenario of Figure 7c, as a variant to the one of Figure 7d. The resource need collection phase 700 is omitted before the trigger-based data exchange (hence phase 700 can be present or not).

[0349] Instead of retrieving the User Info fields of its own BSS, each coordinated AP addressed by the MAP Basic Trigger frame 780 retransmits a duplicate of this frame 780, again to ensure that all stations (even the ones outside of the reach of AP1) correctly receive the resource allocation for the subsequent transmission.

[0350] As shown in the Figure, coordinated AP2 and AP3 receiving MAP Basic Trigger Frame 780 repeat the same Trigger frame 780a / b. In response, their associated stations are able to send their uplink data (782 for STA21 , 782 for STA31 and 784 for STA32) as described above in scenario of Figure 7c.

[0351] In some embodiments, the partial or full trigger frame duplication presented in the variants of Figures 7d and 7e is requested by the sharing AP (with a dedicated field, e.g. in MAP Group Information field 370). In variants, it may be mandatory for the coordinated APs. In both cases, this trigger frame duplication is taken into account in the duration of the transmission.

[0352] In all the above scenarios, the resources allocated to stations of the same BSS preferably form one or more 20 MHz channels to ease any acknowledgment within the BSS and to reduce needs of synchronization between BSSs, hence interference.

[0353] In the above embodiments, the sharing AP that solicits the stations associated with the coordinated APs and the mechanisms of partial or full Trigger Frame duplication have been described with respect to a MAP Basic Trigger Frame. It is to be noted however that these embodiments are not restricted to a MAP Basic Trigger Frame, and any type of MAP Trigger Frame can be used, e.g., BSRP Trigger frame.

[0354] The scenarios of Figures 8a-8e make a focus on the MU-RTS TXS procedure in the multi-AP context. These scenarios omit the resource need collection phase 700 before the triggerbased data exchange (hence phase 700 can be present or not). In addition, the MU-RTS TXS procedure may optionally be preceded by the sending of a CTS-to-self (not shown) to protect the TXOP frame exchange sequences.

[0355] Figure 8a illustrates a first example of frame exchange based on the MAP MU-RTS TXS procedure wherein the sharing AP allocates some time of its TXOP to another AP: the sharing AP initiates a TXOP and then temporarily shares it with a surrounded AP or an AP belonging to a MAP group before the sharing AP gets back the medium to sending data to a non- AP station of its own BSS.

[0356] In the example of the Figure, the frame exchange starts when sharing AP1 110 gains the medium and sends MAP MU-RTS TXS Trigger frame 800 to coordinated AP2. The Trigger frame is identified as a MAP MU-RTS TXS Trigger frame using any signalling method as described above: e.g., Trigger Type 311 set to MU-RTS (value 3) with non-AP / AP field 501 set to AP (value 1) and Triggered TXOP Sharing field 316 set to enabled TXS mode (either value 1 or 2) (Figure 5a); Trigger Type 311 set to MAP MU-RTS (value 10) with Triggered TXOP Sharing field 316 set to enabled TXS mode (eithervalue 1 or 2) (Figure 5b); Trigger Type 311 set to MAP (value 9) with MAP Trigger Type Field 361 set to MU-RTS (value 3) in Trigger Dependent Common Info 360 and Triggered TXOP Sharing field 316 set to enabled TXS mode (either value 1 or 2) (Figure 5d); Trigger Type 311 set to “Trigger Type extension” (value 15) with Trigger Type extension field 370 set to MAP MU-RTS (value 1) and Triggered TXOP Sharing field 316 set to enabled TXS mode (either value 1 or 2) (Figure 5e); Trigger Type 31 1 set to MU-RTS (value 3) with Triggered TXOP Sharing field 316 set to MAP TXS (value 3) (Figure 5f); Trigger Type 31 1 set to MU-RTS (value 3) with non-AP / AP field 557 in Special User Info field 550 set to AP (value 1) and Triggered TXOP Sharing field 316 set to enabled TXS mode (either value 1 or 2) (Figure 5g1); Trigger Type extension field 557 in Special User Info field 550 set to MAP MU-RTS (value 1) and Triggered TXOP Sharing field 316 set to enabled TXS mode (either value 1 or 2) (Figure 5g2); Trigger Type 311 set to MU-RTS (value 3) with an AID dedicated for AP in AID12 field 331 of a User Info field 330 and Triggered TXOP Sharing field 316 set to enabled TXS mode (either value 1 or 2).

[0357] RA field 303 of this MAP MU-RTS TXS Trigger frame 800 is set to the address of addressed coordinated AP, here AP2. The Trigger frame also includes a User Info field 330 addressed to the solicited AP, here AP2. The solicited AP is identified using any signalling method as described above: e.g., an AID dedicated for the AP (whatever the range) in AID12 field 331 of a User Info field 330; AP ID field 600 in User Info field 330 (Figure 6a); AP ID field 600 in Trigger Dependent User Info field 339 of User Info field 330 (Figure 6b); RA field 303 as the MAP MU- RTS TXS Trigger Frame is only addressed to one AP.

[0358] Next, upon receiving the MAP MU-RTS TXS Trigger frame 800 addressed to it, coordinated AP2 operates on the allocated resource as it was the TXOP holder. In the scenario show, it starts transmitting DL data 810 to STA21 . STA21 may send a block acknowledgement 811 to AP2 to acknowledge the data received correctly. Next, AP2 may send other DL data 812 to another of its associated stations (STA22 in the example). Upon reception of these DL data from AP2, STA22 responds with a block acknowledgement 813 to AP2. Of course, multiple transmissions may take place during the allocated time (resource).

[0359] At the end of the duration allocated to coordinated AP2, the sharing AP (AP1) gets back the medium during the TXOP and thus may use the end of its TXOP for its own operations, e.g. transmission of data within its BSS or new coordinated trigger-based data exchange including transmitting a new MAP Trigger frame such as a MAP MU-RTS TXS Trigger frame to share again its TXOP with other stations (non-AP or AP).

[0360] In some embodiments as show in Figure 8a, the coordinated AP, here AP2, may send, to the sharing AP, a releasing frame to release the allocated resources once its transmission is done. In that way, AP2 can release the medium before the end of its allocated time, e.g. because there is no more data to be transmitted. The releasing frame 814 may be a QoS NULL frame or a CF-end frame. Upon reception of this releasing frame, the sharing AP may transmit its own data (230). The stations associated to AP2 that receive the releasing frame 814 do not try to access the medium to avoid to affect the sharing AP.

[0361] Figure 8b illustrates a second example of frame exchange based on the MU-RTS TXS procedure wherein the sharing AP allocates some time of its TXOP to another AP. In this scenario, the coordinated AP who is solicited by the sharing AP protects the subsequent communications by sending a CTS frame 801 before operating (802) on the allocated resource as it was the TXOP holder.

[0362] In the example of the Figure, the frame exchange starts when sharing AP1 110 gains the medium and sends MAP MU-RTS TXS Trigger frame 800 to coordinated AP2 as described above with reference to Figure 8a.

[0363] Upon reception of the MAP MU-RTS TXS Trigger frame 800, coordinated AP2 transmits a CTS response 801 to sharing AP1 and then, in state 802, operates on the allocated resource as it was the TXOP holder. Any conventional communication scenario may be used on the allocated resource, such as the one of Figure 8a (time-based sharing) or any operation shown in Figure 2a, 2b or 2c (frequency-based sharing).

[0364] Figure 8c illustrates a third example of frame exchange based on the MU-RTS TXS procedure wherein the sharing AP allocates some time of its TXOP to other APs.

[0365] In this example, the MAP MU-RTS TXS procedure mixes trigger-based time- and frequency-based sharing to multiple coordinated APs. Different frequency bands (preferably 20 MHz bands) are allocated to the coordinated APs, while offering a time-based resource. In other words, the resource allocated to the different APs includes time duration and frequency resources.

[0366] In some embodiments, the MAP MU-RTS TXS Trigger frame 820 includes one or more User Info fields according to the format of Figure 6d.

[0367] Figure 8d illustrates a fourth example of frame exchange based on the MU-RTS TXS procedure wherein the sharing AP allocates successive timeslots within its TXOP to different other APs.

[0368] In this example, the MAP MU-RTS TXS Trigger frame 820 includes resources allocated to different coordinated APs with an allocation duration and a start time of the time slot for each addressed coordinated AP.

[0369] In some embodiments, the MAP MU-RTS TXS Trigger frame includes multiple User Info fields according to the format of Figure 6d, in which field 603 carries the allocation duration and field 604 carries the start time of the slot. In the example shown, a first User Info field 330 allocating resources to coordinated AP2 (hence BSS2) in the Trigger frame 820 sets Allocation Duration field 603 to ‘TO’ and Start Time field 604 to ‘tO’, and a second User Info field 330 allocating resources to coordinated AP3 (hence BSS3) in the Trigger frame 820 sets Allocation Duration field 603 to ‘TT and Start Time field 604 to ‘t1 ’.

[0370] Any conventional communication scenario may then be used on the allocated resource of each coordinated BSS. Figure 8e illustrates a fifth example of frame exchange based on the MU-RTS TXS procedure wherein the sharing AP allocates some time of its TXOP to a coordinated soft AP or group owner (in the meaning of Wi-Fi Direct - RTM). The same scenario as Figure 8a is shown wherein the resource allocation is made to a soft AP.

[0371] This soft AP may be a station of an hybrid MLD as described above. In that case, the soft AP may have the AID of the MLD (common to its affiliated non-AP stations) as AP identifier to be used either in AID12 field 331 of the User Info field, or in AP ID field 600 in the User Info field (Figure 6a) or in AP ID field 600 in Trigger Dependent User Info field 339 of the User Info field (Figure 6b) or in RA field 303 if the MAP MU-RTS TXS Trigger Frame 860 is only addressed to the soft AP.

[0372] Any conventional communication scenario may then be used by the soft AP on the allocated resource.

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

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

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

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

[0377] 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 11 b 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.

[0378] 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.1 1 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.

[0379] 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.1 1 layer 1124 may implement an Upper-MAC stack along with a series of Lower- MAC modules.

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

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

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

[0383] Although the present invention has been described hereinabove with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications will be apparent to a skilled person in the art which lie within the scope of the present invention.

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

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

CLAIMS1. A communication method in a wireless network, comprising at a first access point, AP, managing a first basic service set, BSS: sending a first Trigger frame allocating resources to a second BSS and soliciting a transmission from the second BSS within the allocated resources.

2. The method of Claim 1 , further comprising, receiving, at the first AP and within the allocated resources, a transmission addressed to it by a second AP managing the second BSS.

3. The method of Claim 1 , wherein the first AP cascades multiple Trigger frames allocating resources to at least the second BSS and soliciting a transmission from at least the second BSS within the respective allocated resources.

4. The method of Claim 3, wherein an allocation of resources in a subsequent T rigger frame is based on one or more Buffer Status Report, BSR, frames received in response to a preceding Trigger frame having a BSR Poll, BSRP, type.

5. The method of Claim 4, wherein a BSR frame received from a second AP managing the second BSS includes multiple BSRs corresponding to multiple non-AP stations of the second BSS, and wherein the allocation of resources in the subsequent Trigger frame includes directly allocating resources of non-AP stations of the second BSS.

6. The method of Claim 1 , further comprising at the first AP: receiving, from a second AP managing the second BSS, a releasing frame to release the allocated resources, and using the released resources to send a new frame.

7. A communication method in a wireless network, comprising at a second station in a second basic service set, BSS: receiving, from a first access point, AP, managing a first BSS, a first Trigger frame allocating resources to the second BSS and soliciting a transmission from the second BSS within the allocated resources, and responsive to the received first Trigger frame, sending a frame within the allocated resources.

8. The method of Claim 7, wherein the second station receives, from the first AP, multiple cascaded Trigger frames allocating resources to at least the second BSS and soliciting a transmission from at least the second BSS within the respective allocated resources.

9. The method of Claim 7, wherein the second station sends, to the first AP, a releasing frame to release the allocated resources once the transmission is done.

10. The method of Claim 7, wherein the second station is a second AP managing the second BSS, and the transmission is made from the second AP to the first AP.

11. The method of Claim 7, wherein the second station is a second AP managing the second BSS, and the transmission includes another Trigger frame addressed by the second AP to stations of the second BSS.

12. The method of Claim 11 , wherein the first Trigger frame is a Buffer Status Report Poll, BSRP, Trigger frame, and the other trigger frame is a BSRP Trigger frame sent by the second AP to non-AP stations of the second BSS.

13. The method of Claim 12, further comprising receiving one or more BSR frames from the non-AP stations in response to the other BSRP Trigger frame, and sending, to the first AP, a response BSR frame based on the received BSR frames as a response to the first BSRP Trigger frame.

14. The method of Claim 13, wherein the response BSR frame includes multiple BSRs corresponding to the BSR frames received from the non-AP stations respectively.

15. The method of Claim 11 , wherein the other Trigger frame is a duplicate of the first Trigger frame.

16. The method of Claim 11 , wherein the other Trigger frame reproduces a resource allocation for non-AP stations of the second BSS as defined in the first Trigger frame.

17. The method of Claim 7, wherein the transmission is made within the second BSS.

18. The method of Claim 11 , wherein the second station is a non-AP station in the second BSS.

19. The method of Claim 1 or 7, wherein the first T rigger frame is of one of the following types: BSRP Trigger frame, MU-RTS Trigger frame with or without TXOP Sharing, Basic Trigger frame, NFRP Trigger frame, Ranging Trigger frame.

20. The method of Claim 1 or 7, wherein a Common Info field of the first Trigger frame includes a multi-AP bit taking a first value when the first Trigger frame is a conventional 802.11 ax Trigger frame allocating resources to stations of the first BSS only and taking a second value when the first Trigger frame is a multi-AP Trigger frame allocating resources to another BSS than the first BSS.

21. The method of Claim 20, wherein the multi-AP bit is bit 63 within the Common Info field of the first Trigger frame.

22. The method of Claim 1 or 7, wherein a Common Info field of the first Trigger frame includes a Trigger Type field whose value distinguishes between conventional 802.11 ax types of Trigger frames allocating resources to stations of the first BSS only and extended types of Trigger frames allocating resources to another BSS than the first BSS.

23. The method of Claim 22, wherein one or more of Trigger Type values from 9 to 15 (the reserved values) may include one or more of the following types: BSRP Trigger frame, MU- RTS Trigger frame, Basic Trigger frame, NFRP Trigger frame and Ranging Trigger frame, all allocating resources to another BSS than the first BSS.

24. The method of Claim 1 or 7, wherein a Common Info field of the first Trigger frame includes a Trigger Type field whose value is set to indicate multi-AP, that is resources are allocated to another BSS than the first BSS, and includes a second field defining a type of multi- AP Trigger frame.

25. The method of Claim 24, wherein the second field includes:one or more of bits B20, B21 , B56-B62 of the Common Info field, or a Trigger Dependent Common Info field within the Common Info field, or a Trigger Type Extension field after a Trigger Dependent Common Info field in the Common Info field.

26. The method of Claim 1 or 7, wherein a Common Info field of the first Trigger frame includes a Trigger Type field set to value 3 to define a MU-RTS type and a Triggered TXOP Sharing, TXS, Mode field is set to value 3 to define a TXOP sharing with another BSS.

27. The method of Claim 1 or 7, wherein the first Trigger frame includes a Special User Info field that includes: a multi-AP bit taking a first value when the first Trigger frame is a conventional 802.1 1 ax Trigger frame allocating resources to stations of the first BSS only and taking a second value when the first Trigger frame is a multi-AP trigger frame allocating resources to another BSS than the first BSS, or a Trigger Type Extension field defining a type of multi-AP Trigger frame allocating resources to another BSS than the first BSS.

28. The method of Claim 1 or 7, wherein an AID field in a User Info field of the first Trigger frame includes an AID dedicated to the second BSS, hence signalling the first Trigger frame is a multi-AP trigger frame allocating resources to the second BSS.

29. The method of Claim 1 or 7, wherein the first Trigger frame includes a MAP Group field describing a MAP group of APs.

30. The method of Claim 29, wherein the MAP Group field includes an identifier of the MAP group and one or more from the following fields: a MAP Coordination Type field defining a type of coordination at resource level, a list of the APs belonging to the MAP group, a validity duration of the MAP group, a matching between MAC addresses of the APs and other identifiers of the APs, a BSS colour value providing colouring to the MAP group, a Direction indicating a transmission direction for the solicited transmission,31. The method of Claim 29, wherein the MAP Group field includes the said following field or fields whose content has been modified since a previous Trigger frame allocating resources to a BSS of the MAP group or a creation of the MAP group.

32. The method of Claim 1 or 7, wherein allocating resources to a second BSS includes identifying a second AP managing the second BSS within the first Trigger frame.

33. The method of Claim 32, wherein an identification of the second AP includes one of an AID of the second AP, a MAC address of the second AP, an AP multi-link device, MLD, identifier of an AP MLD to which the second AP is affiliated, a BSS identifier of the second BSS, a short BSS identifier of the second BSS.

34. The method of Claim 33, wherein in case the second AP is a soft AP affiliated to a non-AP multi-link device, MLD, the AID of the second AP is an AID of any station affiliated to the non-AP MLD.

35. The method of Claim 32, wherein an identification of the second AP is included in a User Info field that defines the allocation of the resources to the second BSS in the first Trigger frame.

36. The method of Claim 35, wherein the identification of the second AP is an AID of the second AP provided in an AID12 field of the User Info field.

37. The method of Claim 36, wherein the AID is taken from values 2008-2044 or 212-212-nto 4055, with n an integer between 1 to 6.

38. The method of Claim 35, wherein the identification of the second AP is included in an AP ID field that is provided in a Trigger Dependent User Info field of the User Info field or as an additional field in an 802.11 be / D3.2 User Info field.

39. The method of Claim 38, wherein the AP ID field is provided together with an ID Type field signalling the type of identifier the AP ID field includes.

40. The method of Claim 38, wherein the User Info field includes a multi-AP bit taking a first value when the User Info field signals an allocation of resources to a station of the first BSS only and taking a second value when the User Info field signals an allocation of resources to another BSS than the first BSS, hence signalling whether the Trigger Dependent User Info field is present in the User Info field.

41. The method of Claim 32, wherein an identification of the second AP is included in a Receiver Address of a MAC header of the first trigger frame.

42. The method of Claim 1 or 7, wherein the first Trigger frame further allocates other resources to a non-AP station of the first BSS and solicits a transmission from the non-AP station within the allocated other resources.

43. The method of Claim 1 or 7, wherein allocating resources to the second BSS includes allocating resources to a second AP managing the second BSS.

44. A Trigger frame sent by a first access point, AP, managing a first basic service set, BSS, the Trigger frame comprising an allocation of resources to a second BSS to solicit a transmission from the second BSS within the allocated resources.

45. 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 Buffer Status Report, BSR, frame reporting resource needs for the second BSS.

46. The method of Claim 43, further comprising allocating resources in a gained TXOP to the second BSS based on the received BSR frame.

47. The method of Claim 43, wherein the BSR frame is received in response to a BSR Poll, BSRP, Trigger frame previously sent by the first AP to allocate resources to a station of the second BSS and solicit a BSR response in the allocated resources.

48. 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 Buffer Status Report, BSR, frame reporting resource needs for the second BSS.

49. The method of Claim 48, further comprising receiving, from the first AP, allocated resources in a TXOP gained by the first AP.

50. The method of Claim 48, wherein sending the BSR frame is responsive to receiving, from the first AP, a BSR Poll, BSRP, Trigger frame allocating resources to the second AP and soliciting a BSR response in the allocated resources.

51. The method of Claim 45 or 48, wherein 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 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.

52. The method of Claim 45 or 48, wherein the BSR frame includes a plurality of BSR Control fields corresponding to buffer status information of a respective plurality of stations 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.

53. The method of Claim 45 or 48, wherein, 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.

54. The method of Claim 52 or 53, wherein each BSR Control field further includes a linkID field identifying a preferred link requested for the buffer status information.

55. A wireless communication device comprising at least one microprocessor configured for carrying out the method of Claim 1 , 7, 45 or 48.

56. 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 , 7, 45 or 48.

57. An 802.11 frame including a Special User Info field having a PHY Version Identifier subfield set to a value from 1 to 7 to signal UHR (Ultra High Reliability) or multi-AP cooperation.

Images